Update Q and deprecated Promise patterns and methods

[Jaifroid]

Implements #588 for almost all of the deprecated methods and patterns. I have not touched the patterns in abstractFilesystemAccess.js because they are FFOS-specific, and I guess this code will not be transferred to any ES6-webkit-npm version. I have kept Q, however, for backwards compatibility with old devices. To dispense with Q, we would simply need to change Q.Promise() patterns to new Promise().

I have standardized on using Q with a capital letter (we have some variation).

There is one case of a Q.when which is not in the Promise spec. I haven't touched it (yet?) because I don't know what the difference is between when and then in Q.

[mossroy]

It's cool to clean up the code like that.
But the Travis build seems to fail (even after a re-run).

Maybe it's because of the refactoring of function readRemoteArchive, that is only used in the case of UI tests on Travis (through nightwatch)

[Jaifroid]

Yes, I think you're probably right about which function is causing the problem, though I did seem to notice it working on some browsers which would be odd. Maybe a timing issue. Will check.

[Jaifroid]

With the new commit, it's passing tests on all browsers except IE11... The previous one was failing on all browsers, so it's an improvement at least.

[Jaifroid]

With Q updated to 1.5.1, the standard Promisify pattern for XHR (as recommended by Mozilla, for example) now works on all browsers except IE11. I think the problem is the interaction between callbacks inside a Promise and Q.all. I'll try a few more things, but it may be necessary to revert back to the Q.defer() antipattern in this case, and then try again with babel if/when we achieve #554 (npm and webpack).

[Jaifroid]

Although IE11 tests are now passing, IE11 is failing to load more than three pages in succession with this PR - it seems to have a major memory leak. Clearly IE11 does not do too well with standard Promises implemented by Q...

Working on FFOS, FF, Edge Legacy. But I will need to debug the further IE11 issues before this will be ready to merge.

[Jaifroid]

The noted issue with IE11 seems to exist on master also (see #594), and may not be a problem with this PR, though it appeared to be exacerbated by using Promise/A+ patterns especially those that are iterated with Q.all. It needs careful testing.

[Jaifroid]

I have rebased this PR on master, as it had got out of hand with many reverts, and master had changed from the base used to set up the PR.

[Jaifroid]

OK, @mossroy, this code is now ready for final review.

Please note that I've included an update to the latest version of the Q library (v1.5.1) . Our copy was copyright 2012, the new one is copyright 2017.

The latest commits are passing Travis. The CodeFactor issues are all from the Q library itself, and these will disappear once merged, as we have that file marked as a library file (to be ignored in master once merged).

Where it was not possible to convert a function to the Promise/A+ spec patterns due to blocking by IE11, I have left a comment to explain. I expect that when we achieve #554, we will use babel or typescript, or both, to provide minimal polyfills, and will no longer need Q. Similarly, I have not touched the promises in the functions that are only currently used by FFOS, as I imagine these may not be merged into #554.

The latest commit 3fa47b0 has been tested in jQuery and SW modes (where appropriate) on: Edge Chromium, Edge Legacy, Internet Explorer 11, Firefox LTS, FFOS.

[mossroy]

I like this clean up, many thanks! (even if IE11 prevented you from doing everything)
The code looks good to me.
I don't have my Firefox OS device with me, and would like to test on it, in case of...
I should have it this weekend : I'll test and approve this PR if it works on it.
Maybe you can rebase/squash?

[Jaifroid]

Thanks, no rush @mossroy. It's a good idea to check it on a physical device. I'll squash once you've approved (since I already rebased recently on master).

Incidentally, I've been thinking we may have enough for a new release, since you had signalled end of February for the next release. The main addition is dark mode, but I think it's a big-enough and requested feature to be worth a release. I guess it could be discussed under an issue rather than here.

[mossroy]

There is a regression on the search feature : the search results are not displayed any more.
I see that on any browser.

Apart from that, it seems to work well on my Firefox OS device

[Jaifroid]

I saw that and was sure I'd fixed it... Let me check!

[mossroy]

Maybe I did not update the branch properly, I'll check too

[mossroy]

Sorry, it was certainly my mistake.
I'll test again with your updated branch

[mossroy]

I was testing a wrong state of the branch.
It's working fine on my Firefox OS device, and I did not see any problem with some quick tests on Firefox and Chromium (jQuery and SW modes)

[Jaifroid]

OK, thanks @mossroy . Yes, I had rebased the branch precisely because of that issue, but the comment about that is buried somewhere above.