3d3fb1fce6a998fdb79c7523610cc5a9a3cf6a96: Bug 1505777: [Cranelift] Update to Cranelift 0.23. r=bbouvier
Dan Gohman <sunfish@mozilla.com> - Fri, 09 Nov 2018 05:15:49 -0800 - rev 445552
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1505777: [Cranelift] Update to Cranelift 0.23. r=bbouvier
1395bbfd01b8b5ac84862684026f59ffa45cd46a: Bug 1506224 - Update pdf.js to version 2.1.42. r=bdahl
Ryan VanderMeulen <ryanvm@gmail.com> - Fri, 09 Nov 2018 14:31:08 -0500 - rev 445551
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1506224 - Update pdf.js to version 2.1.42. r=bdahl
4bf1c95a5db3496554813b3c333296e759138510: Bug 1503724 - Fix progress bar on first load in Fennec custom tabs. r=esawin
Dylan Roeh <droeh@mozilla.com> - Fri, 09 Nov 2018 08:58:32 -0600 - rev 445550
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1503724 - Fix progress bar on first load in Fennec custom tabs. r=esawin There's a race condition here where we receive STATE_START before we've enabled GeckoViewProgressChild; this patch starts listening for web progress in onInit() rather than onEnable() so that we can guarantee progress tracking will work whenever a ProgressDelegate is set.
3787e34b3595ab7c5c929bc5928c92f04a43a176: Bug 1506180 - part 2 - delete VS2015 mozconfigs; r=RyanVM
Nathan Froyd <froydnj@mozilla.com> - Fri, 09 Nov 2018 14:04:29 -0500 - rev 445549
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1506180 - part 2 - delete VS2015 mozconfigs; r=RyanVM We no longer support MSVC 2015.
0698821c5ebdc6e124cab849a332650f5ac2f895: Bug 1506180 - part 1 - factor out a win_sdk_version variable; r=RyanVM
Nathan Froyd <froydnj@mozilla.com> - Fri, 09 Nov 2018 14:04:29 -0500 - rev 445548
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1506180 - part 1 - factor out a win_sdk_version variable; r=RyanVM This change makes the lines a little longer, but ideally makes changes easier and nicer to read.
4e5d78c219f5ba5917c33ad033a0ea857f422488: Bug 1495749 - Allow add-ons to be updated via policy by uninstalling and reinstalling them. r=mkaply
Felipe Gomes <felipc@gmail.com> - Fri, 09 Nov 2018 17:01:18 -0200 - rev 445547
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1495749 - Allow add-ons to be updated via policy by uninstalling and reinstalling them. r=mkaply
71df0988d340789d2a6fb26edb36936947b543c8: Bug 1429488 - Part 8: Fix mobile about:addons code for enabling/disabling themes. r=aswan
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 01 Nov 2018 22:08:59 +0100 - rev 445546
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 8: Fix mobile about:addons code for enabling/disabling themes. r=aswan about:addons on Android has some logic to ensure that only one theme can be active at the same time. At some point however, themes must have learned to take care of themselves in that regard, which means that this code a) has become unnecessary, and b) with Webextension themes it can actually cause a harmful race condition: Explicitly disabling the previously active theme implicitly enables the default theme, so what happens is that depending on the size of the Webextension theme to be enabled, the new theme can be enabled before the previous disable() call completes. This leads to the new theme then immediately being disabled again as the previous disable() call finally gets around to enabling the default theme. The smaller the Webextension theme to be enabled and the faster it loads, the more likely this is to happen. We still need to manually fix up the disabled state of themes in the UI, though, so that it shows the correct state without a reload. Therefore, we take the opportunity to fix the problem that up until now, disabling a theme wouldn't mark the default theme as enabled in the UI, unless you manually reloaded the page afterwards. Differential Revision: https://phabricator.services.mozilla.com/D10732
9e24466d3f963ab7829331469c241ab242fe2cf1: Bug 1429488 - Part 7: Move responsibility for persisting themes on Android to LWTConsumer. r=jaws
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 31 Oct 2018 20:38:26 +0100 - rev 445545
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 7: Move responsibility for persisting themes on Android to LWTConsumer. r=jaws We intercept the theme data just before sending it to the front-end in order to fix it up as described in part 4. There is one snag, though: When the theme data processed in Android's LightweightThemeConsumer isn't fresh data received via lightweight-theme- styling-update, but instead a theme retrieved via LWTManager .currentThemeForDisplay, we risk passing already persisted theme data to LWTPersister.persistImages(). When the LWTPersister encounters an image which already has a file:// URI, it just skips it and doesn't call the success callback in that case, which means we never execute the rest of the code to pass the data on to the Android front-end. Even if it did, this would mean we'd be calling LWTPersister.getPersistedData() twice: Once implicitly through asking for currentThemeForDisplay, and a second time explicitly. So instead, we're asking the LWTManager for currentThemeWithFallback, which returns the original theme data, which we can then safely pass to persistImages() and fix up ourselves through getPersistedData(). This introduces a different problem, though: If the same theme has previously already been successfully persisted, we'd be unnecessarily persisting it again, and even worse, we'd do that on each startup. To avoid that, we make the LWTPersister store and then check the persisted theme's ID and version. If they have remained unchanged, we can short-circuit the call to persistImages and immediately declare success. Differential Revision: https://phabricator.services.mozilla.com/D10731
116776356ba267214cc299371d023e7c5f26ec05: Bug 1429488 - Part 6: Include some metadata in LWT data extracted from static themes. r=jaws
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 31 Oct 2018 20:37:26 +0100 - rev 445544
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 6: Include some metadata in LWT data extracted from static themes. r=jaws To optimise the behaviour of the LightweightThemePersister, we want the ID and version of the theme that we want to persist to be available for static themes, too. Differential Revision: https://phabricator.services.mozilla.com/D10730
57806d472b170ebf89e62258a9841d988bd2986e: Bug 1429488 - Part 5: Support persisting moz-extension resources. r=Gijs
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 22 Oct 2018 22:08:01 +0200 - rev 445543
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 5: Support persisting moz-extension resources. r=Gijs Bug 1344926 integrated static themes more closely into the existing infra- structure for lightweight themes and also intended the static theme's image data to be persisted to disk as well. While the headerURL image file is in fact successfully copied out of the extension archive into the profile, the persist progress listener being used isn't equipped to properly handle this case and therefore the success callback is never executed. As a result - the callback passed to _persistImages in the LWTManager isn't executed, either, although because setting the fallbackThemeData passes in an empty callback anyway, no one noticed. - the persist operation never actually completes, so subsequent calls to currentThemeForDisplay() always return the original moz-extension:// image URI and never the persisted file from the profile folder. For Android we definitively require a working callback in order to be able to forward the fixed-up theme data once the image data has been persisted, so the persistProgressListener's logic is modified accordingly. Additionally, because as far as the LWTManager is concerned, WE static themes are only fallback themes and a call to LWTManager.currentTheme will therefore never return a WE static theme, the LWTPersister's logic to check whether the theme, whose files have just been successfully persisted, is still the current theme, needs to be modified. Differential Revision: https://phabricator.services.mozilla.com/D10729
af60b25f4a0ee2f2861938396148fed71c7cdb8e: Bug 1429488 - Part 4: Move code for persisting theme images into its own JSM. r=jaws
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 11 Oct 2018 19:35:33 +0200 - rev 445542
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 4: Move code for persisting theme images into its own JSM. r=jaws The Android front-end must be able to access theme resources before Gecko has loaded. Therefore, historically it took advantage of the fact that for Lightweight Themes we were persisting the files for the current theme on disk anyway and directly accessed those files. With Webextension static themes, all resources are now stored inside the extension package, but to avoid having to teach the front-end how to access the correct files from the correct extension package without any direct support from Gecko, the easiest course of action is to continue persisting any required resources to the profile folder. Because the LightweightThemeManager behaves differently for WE static themes (it no longer calls "lightweight-theme-styling-update" again after persisting has finished in order to update the theme data with the location of the freshly persisted files, because this is no longer required for WE static themes as they are used on Desktop) and I've also gathered that the long-term intention is for the LWTManager to be completely removed, the plan is to move responsibility for persisting theme resources on Android into Android's LightweightThemeConsumer. To that effect, we move the persisting code into its own JSM so that it can be shared between the LWTManager (as long as it still exists) and Android's LWT- Consumer. Differential Revision: https://phabricator.services.mozilla.com/D10728
9e11568e7c82be46b3ebacc58ec8b2b7517b3273: Bug 1429488 - Part 3: Test minimal Android static theme support. r=gbrown
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 27 Oct 2018 14:46:08 +0200 - rev 445541
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 3: Test minimal Android static theme support. r=gbrown This tests that the moz-extension URI for the headerURL will be properly rewritten into a file URI before being passed to the Android front-end. The JS part of the test has been adapted for Robocop from toolkit/mozapps/ extensions/test/browser/browser_webapi_theme.js. Likewise, the test extension is based on browser_theme.xpi from the same directory, but modified to include a real image file that can actually be persisted. Differential Revision: https://phabricator.services.mozilla.com/D10727
2633e660f2c6f9b5d9d72b8c4c4fc2a6c49b84e1: Bug 1429488 - Part 2: Allow using mochitest-chrome's head.js for Robocop, too. r=gbrown
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 28 Oct 2018 21:04:36 +0100 - rev 445540
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 2: Allow using mochitest-chrome's head.js for Robocop, too. r=gbrown The head.js used for Android chrome mochitests has a few useful functions for waiting on events and observer service notifications, which I don't want to duplicate yet another time. While superficially similar, the JS environment of Robocop tests differs in several ways from that of (chrome) Mochitests. Thankfully the only relevant difference here is that setTimeout() isn't directly available from within a Robocop JS test. As we're only using that to set a 0-length timeout, we can easily replace it with an equivalent dispatchToMainThread() call. Differential Revision: https://phabricator.services.mozilla.com/D10726
9d96a6d361dbc196789de7d3d78120c2a065aedb: Bug 1429488 - Part 1: robocop_head.js improvements. r=gbrown
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 28 Oct 2018 21:38:07 +0100 - rev 445539
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1429488 - Part 1: robocop_head.js improvements. r=gbrown Most of robocop_head.js is based on xpcshell's head.js, but the log statements should probably still use the new filename after all to reduce confusion. Additionally, I've noticed that in do_report_unexpected_exception(), Components.stack.caller can return null under some circumstances - to avoid breaking error reporting as well as to make debugging easier, we should therefore anticipate this possibility when getting caller_stack.filename. Differential Revision: https://phabricator.services.mozilla.com/D10725
0d06016b7cc98ce65cc25e98e651029b5a587db1: Merge mozilla-central to mozilla-inbound
Dorel Luca <dluca@mozilla.com> - Fri, 09 Nov 2018 19:41:24 +0200 - rev 445538
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Merge mozilla-central to mozilla-inbound
959d83958227bfc648c63618ab52fb47706f7e92: Bug 1495879: Fix register macros and re-enable wasm on aarch64-windows. r=luke
David Major <dmajor@mozilla.com> - Fri, 09 Nov 2018 12:43:41 -0500 - rev 445537
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1495879: Fix register macros and re-enable wasm on aarch64-windows. r=luke
abe6431b995081ec03f8b30a785f075553ec4095: Bug 1501503 Part 2: Test that CORS rejection messages are output for loads triggered from styles. r=ckerschb
Brad Werth <bwerth@mozilla.com> - Wed, 31 Oct 2018 18:57:14 +0000 - rev 445536
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1501503 Part 2: Test that CORS rejection messages are output for loads triggered from styles. r=ckerschb Depends on D9807 Differential Revision: https://phabricator.services.mozilla.com/D9870
b6676334369f8034686e9c50ceb941a27bfa6674: Bug 1471403 - Part 4 - Convert "notificationbox" to a custom class. r=bgrins
Paolo Amadini <paolo.mozmail@amadzone.org> - Fri, 09 Nov 2018 14:58:18 +0000 - rev 445535
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1471403 - Part 4 - Convert "notificationbox" to a custom class. r=bgrins As part of the conversion, support for notificationsHidden and children that are not notifications is also removed. Differential Revision: https://phabricator.services.mozilla.com/D10894
5fc40fe6b994e684f9db2c67b0c4d7e8be5540df: Bug 1471403 - Part 3 - Add a MozElements namespace for element classes. r=bgrins
Paolo Amadini <paolo.mozmail@amadzone.org> - Mon, 05 Nov 2018 13:56:01 +0000 - rev 445534
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1471403 - Part 3 - Add a MozElements namespace for element classes. r=bgrins This provides a way to access specific element classes before any associated Custom Element is instantiated, without creating a new global for each class. This can be useful to access static methods, create derived classes in a page, or allow lazy custom constructors. Differential Revision: https://phabricator.services.mozilla.com/D10893
a2a92421b50f91f29ed416eafd8f86f62dfdab45: Bug 1471403 - Part 2 - Lazify the creation of "notificationbox" elements. r=dao,bgrins
Paolo Amadini <paolo.mozmail@amadzone.org> - Fri, 09 Nov 2018 14:38:49 +0000 - rev 445533
Push 35020 by shindli@mozilla.com at Sat, 10 Nov 2018 21:37:25 +0000
Bug 1471403 - Part 2 - Lazify the creation of "notificationbox" elements. r=dao,bgrins Differential Revision: https://phabricator.services.mozilla.com/D10892
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip