Bug 1490493 - 2. Add tests for GeckoView saving/restoring state; r=droeh Add some tests for all scenarios that GeckoView encounters when it is saving/restoring state. Differential Revision: https://phabricator.services.mozilla.com/D5607

Bug 1490493 - 1. Return early if same session is being restored; r=droeh Restoring the same session that's already managed by the GeckoView instance should be a no-op. Differential Revision: https://phabricator.services.mozilla.com/D5606

Bug 1485810 - 2. Add GeckoViewAutoFill support in browser.js; r=petru Make auto-fill work for the main Fennec activity by making calls to GeckoViewAutoFill. Differential Revision: https://phabricator.services.mozilla.com/D4804

Bug 1485810 - 1. Move auto-fill code to GeckoViewAutoFill.jsm; r=droeh Move all auto-fill code to GeckoViewAutoFill.jsm, so they can be shared between GeckoView and Fennec. Differential Revision: https://phabricator.services.mozilla.com/D4803

Merge mozilla-central to inbound. a=merge CLOSED TREE

Bug 1480293 - Basic Memory Reporting for WebRender. r=jrmuizel Reviewers: jrmuizel, gw Tags: #secure-revision Bug #: 1480293 Differential Revision: https://phabricator.services.mozilla.com/D5719 MozReview-Commit-ID: 1vGl3890CjR

Bug 1480854 - Use classic icons again on platforms prior to Oreo. r=jchen We want to use the classic, non-adaptive icon again as our launcher icon on Android versions prior to Oreo, as well as to continue using it in various places within our app. Unfortunately this means that we still have to provide duplicate resources for those two purposes: Because we don't want to use the adaptive icon internally, we can't use the same resource directly for both internal usage and our launcher icon, because other- wise on Oreo and above we'd receive the adaptive icon that way. One possible workaround would have been to use the PNG files of our classic icon directly as a drawable for internal useage and then create a differently named XML bitmap for our launcher icon, which in turn would be overridden by the adaptive icon on Oreo and above. Unfortunately, modern usage demands that the launcher icon should be provided as a mipmap resource, where XML bitmaps - aren't officially supported - unofficially work with some devices/launchers, but not all. Therefore, our only choice is to provide separate drawables for our internal icon and our launcher icon, even if prior to Android O both will have the same contents. We'll also get rid of the separate round icon again, since - on Android O and above, both round and non-round icons were using the same adaptive icon anyway - prior to Android O our normal icon is already round enough, but not round enough to pass the lint check

Bug 1491130. Update webrender to commit da76f6aad61c1ba769566861ec41b42d511fa456

Bug 1473921 - Load checkbox.css and radio.css as document stylesheets. r=paolo

Bug 1491019 - Remove the XPCOM component registration for nsXULControllers; r=baku Differential Revision: https://phabricator.services.mozilla.com/D5774

Bug 1491378 - Update pdf.js to version 2.0.854. r=bdahl

Backed out changeset 56f980324015 (bug 1480854) for lint bustage. CLOSED TREE

Backed out changeset 433f1ab89061 (bug 1491257) for xpcshell failures on test_sync.js. CLOSED TREE

Bug 1384557 - move _DEPEND_CFLAGS+CL_INCLUDES_PREFIX to toolchain.configure, ignore {CC,CXX}_WRAPPER when using sccache; r=glandium Currently mozconfig.cache overrides a few build options for sccache. This patch moves them into toolchain.configure so that the build system will set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER are set in config.mk, so just avoid setting them when sccache is in use.

Bug 1480854 - Use classic icons again on platforms prior to Oreo. r=jchen We want to use the classic, non-adaptive icon again as our launcher icon on Android versions prior to Oreo, as well as to continue using it in various places within our app. Unfortunately this means that we still have to provide duplicate resources for those two purposes: Because we don't want to use the adaptive icon internally, we can't use the same resource directly for both internal usage and our launcher icon, because other- wise on Oreo and above we'd receive the adaptive icon that way. One possible workaround would have been to use the PNG files of our classic icon directly as a drawable for internal useage and then create a differently named XML bitmap for our launcher icon, which in turn would be overridden by the adaptive icon on Oreo and above. Unfortunately, modern usage demands that the launcher icon should be provided as a mipmap resource, where XML bitmaps - aren't officially supported - unofficially work with some devices/launchers, but not all. Therefore, our only choice is to provide separate drawables for our internal icon and our launcher icon, even if prior to Android O both will have the same contents. We'll also get rid of the separate round icon again, since - on Android O and above, both round and non-round icon were using the same adaptive icon anyway - prior to Android O our normal icon is already round enough (ignoring the Fennec icon for local developer builds)

Merge mozilla-central to inbound. a=merge CLOSED TREE

bug 1491257: marionette: make PollPromise more precise; r=whimboo A PollPromise with timeout of 100 ms and interval of 100 ms is normally expected to fire twice: once immediately and once before the timeout at 100 ms. On slow systems, such as Windows PGO TV, the timeout timer may be slow enough for a third evaluation of the PollPromise to occur. By making the timer strategy more precise we can ensure that the repeating timer has a constant period between firings. This guarantees that it will not queue up new events to fire the callback until the previous callback event finishes. This means, that if the callback takes a long time to evaluate, the next evaluation is only scheduled after it returns. This will prevent firings to happen after the timeout duration has elapsed.

Bug 1485420 - Part 2. Make ClipManager trim clip chains which can be merged with the display item. r=mstange

Bug 1485420 - Part 1. Expose WebRender bindings to merge a clip rect with a display item. r=mstange This part allows the caller to push a clip rect onto a stack that will be used with any display items added to DisplayListBuilder. Said rect will be intersected with the given clip rect for the display item (if applicable).

Bug 1490886 - [wpt-sync] Update web-platform-tests to 9a16eee96e7fb06c7ca05899436e35c957e676d8, a=testonly wpt-head: 9a16eee96e7fb06c7ca05899436e35c957e676d8 wpt-type: landing