5a743f540b83abbbe4fb145d8ba1e713a4125153: Bug 1483671 - Add multiple pin/unpins, release defaults and bug fixes to Activity Stream r=k88hudson
Ed Lee <edilee@mozilla.com> - Wed, 15 Aug 2018 22:31:54 +0000 - rev 431651
Push 34450 by ebalazs@mozilla.com at Thu, 16 Aug 2018 09:22:59 +0000
Bug 1483671 - Add multiple pin/unpins, release defaults and bug fixes to Activity Stream r=k88hudson Differential Revision: https://phabricator.services.mozilla.com/D3441
85f7b7200eea172cc5cc1d4eb853cb5062a35baa: Bug 1482046 - mfbt: FunctionTypeTraits - r=froydnj
Gerald Squelart <gsquelart@mozilla.com> - Wed, 15 Aug 2018 10:27:45 +0000 - rev 431650
Push 34450 by ebalazs@mozilla.com at Thu, 16 Aug 2018 09:22:59 +0000
Bug 1482046 - mfbt: FunctionTypeTraits - r=froydnj FunctionTypeTraits< function type > makes it easier to inspect a function's return type, arity, and parameter types. It works with free functions, struct/class methods, function objects like non-generic lambdas and std::function. Differential Revision: https://phabricator.services.mozilla.com/D2998
92832d7ecc29acb44a81ceb7836baaf528c20282: Bug 1483274 - Remove nsIRemoteBrowser and always use nsIBrowser;r=smaug
Brian Grinstead <bgrinstead@mozilla.com> - Wed, 15 Aug 2018 19:21:22 +0000 - rev 431649
Push 34450 by ebalazs@mozilla.com at Thu, 16 Aug 2018 09:22:59 +0000
Bug 1483274 - Remove nsIRemoteBrowser and always use nsIBrowser;r=smaug Browsers can switch at runtime from remote to non-remote and vice versa, which on the C++ side is detected from a XBL binding change which causes nsIRemoteBrowser to either be implemented or not. Custom Elements can't change at runtime in the same way, so unifying on a single [implements] will allow browser (both remote and non-remote) to be migrated to a single Custom Element. To keep current functionality, this updates Qi calls into nsIRemoteBrowser to instead Qi into nsIBrowser and check isRemoteBrowser. Differential Revision: https://phabricator.services.mozilla.com/D3346
8fbba4053aa0032f7ea5ced9b94c1c3972deee29: Bug 1482259 - Add Telemetry to know the proportion of silent part in the whole audio track. r=cpearce,francois
alwu <alwu@mozilla.com> - Wed, 15 Aug 2018 16:35:51 +0000 - rev 431648
Push 34450 by ebalazs@mozilla.com at Thu, 16 Aug 2018 09:22:59 +0000
Bug 1482259 - Add Telemetry to know the proportion of silent part in the whole audio track. r=cpearce,francois Use new telemetry histogram ID 'AUDIO_TRACK_SILENCE_PROPORTION' to know the proportion of silent part in the whole audio track. Differential Revision: https://phabricator.services.mozilla.com/D3066
907a277d51d8196af0f14ba3ef3f37963303814e: Bug 1482551 - avoid selecting url bar text on searches r=Mardak
ahillier <ahillier@mozilla.com> - Wed, 15 Aug 2018 20:57:36 +0000 - rev 431647
Push 34450 by ebalazs@mozilla.com at Thu, 16 Aug 2018 09:22:59 +0000
Bug 1482551 - avoid selecting url bar text on searches r=Mardak Differential Revision: https://phabricator.services.mozilla.com/D3431
fb0c0ffeec57fee01a9a75e95ecbd4f2942f7ab3: Bug 1474238 - Add a "report breakage" dialog for Tracking Protection. r=Paolo
Johann Hofmann <jhofmann@mozilla.com> - Wed, 11 Jul 2018 17:14:35 +0200 - rev 431646
Push 34450 by ebalazs@mozilla.com at Thu, 16 Aug 2018 09:22:59 +0000
Bug 1474238 - Add a "report breakage" dialog for Tracking Protection. r=Paolo MozReview-Commit-ID: 26q5PYLUZGS
d3f55ddb602b2c123bfb7eef184e4ff8607bdd19: Bug 1280234 - Expose Telemetry APIs to trusted WebExtensions; r=aswan,gfritzsche
Jared Hirsch <ohai@6a68.net> - Fri, 13 Jul 2018 12:35:34 -0700 - rev 431645
Push 34450 by ebalazs@mozilla.com at Thu, 16 Aug 2018 09:22:59 +0000
Bug 1280234 - Expose Telemetry APIs to trusted WebExtensions; r=aswan,gfritzsche MozReview-Commit-ID: 4uQBq3Qvj0M
73efbce701a9880e35a5139dc67757fa68ad892a: Bug 1476106 - Part 5 - Subscribe PromptService to OrientationChangeListener, too. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 02 Aug 2018 21:17:07 +0200 - rev 431644
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1476106 - Part 5 - Subscribe PromptService to OrientationChangeListener, too. r=snorp Now that GeckoScreenOrientation generally offers notifications of screen orientation changes, the PromptService no longer needs to do its own orientation tracking and require to be fed orientation changes from each activity using it. MozReview-Commit-ID: K7KbDsQip7b
67b327d75ce6ff41b854ce731739e0a6851674ca: Bug 1476106 - Part 4 - Refresh ScreenManager data when detecting orientation changes. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 02 Aug 2018 22:03:59 +0200 - rev 431643
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1476106 - Part 4 - Refresh ScreenManager data when detecting orientation changes. r=snorp As of bug 1475875, cached screen data is now held by Gecko, so - we no longer need to cache the screen size (retrieval of which can be expensive when called en masse, as required e.g. by font inflation) within GeckoAppShell, and - we need to trigger a refresh of that data instead when the activity orientation changes. MozReview-Commit-ID: JsY6sBCcOih
e936ef6b4b50fc09d0ffb988cb563f4a79d7b34c: Bug 1476106 - Part 3 - Move GeckoScreenOrientation updates into GeckoView. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 12 Aug 2018 13:31:59 +0200 - rev 431642
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1476106 - Part 3 - Move GeckoScreenOrientation updates into GeckoView. r=snorp By moving the calls to GeckoScreenOrientation.update() into GeckoView, any app using a GeckoView will automatically update the screen orientation in Gecko, too, without any further action being required by the embedding app. The synchronisation around GeckoScreenOrientation.update()/(un)lock() is required for the following scenario: If (un)locking of the screen orientation as requested by Gecko caused the actual screen orientation of the app to change, there are two ways in which this will cause our internal screen orientation to be updated: 1. Either the call to delegate.setRequestedOrientationForCurrentActivity (happening on the Gecko thread if the original request to (un)lock came from Gecko) returns first and update() is subsequently first called from the Gecko thread, too, meaning the onOrientationChange notification to Gecko can occur synchronously as well. In that case, as soon as (un)lock returns to Gecko, querying our internal screen orientation will return the correct value. 2. Or else the GeckoView.onConfigurationChanged() call resulting from the screen rotation manages to call GeckoScreenOrientation.update() first and does so from the Android UI thread. This means that the onOrientationChange notification will be redispatched asynchronously to the Gecko thread, while the Gecko thread's call to GeckoScreenOrientation.update() will return early without doing any work, as the screen orientation had already been previously updated by the UI thread. As a result,there will be a period of time between the Gecko thread returning from GeckoScreenOrientation.(un)lock() and the onOrientationChange notification finally executing where querying the internal screen orientation will not yet return the new orientation. This can cause problems for Gecko (test) code that expects to (un)lock the orientation and then be able to immediately query the new, changed orientation after the call to (un)lock returns. Without additional measures in place, there are no guarantees at what point the GeckoView will receive the onConfigurationChanged() call in relation to the request to change the activity's orientation making its way back to (un)lock(). Therefore, we add synchronisation such that no other thread will be able to up- date the screen orientation in GeckoScreenOrientation while another thread is still busy (un)locking the screen orientation. MozReview-Commit-ID: 5s5NEJcuS0p
70bfe613b3253974eb3a2d2562739a6fd6d4ed22: Bug 1476106 - Part 2 - Fix setting of mRuntime when restoring GeckoView from savedInstanceState. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 04 Aug 2018 15:21:40 +0200 - rev 431641
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1476106 - Part 2 - Fix setting of mRuntime when restoring GeckoView from savedInstanceState. r=snorp The call to mSession.transferFrom(ss.session) in the line above also transfers the window from ss.session into mSession, which means we subsequently won't be able to retrieve a runtime from ss.session any more, thereby defeating the goal of calling mRuntime = ss.session.getRuntime(). This case is encountered e.g. when the containing activity is destroyed and sub- sequently recreated after a configuration change that isn't handled by the app, e.g. screen rotation in the GeckoView example app. MozReview-Commit-ID: 5YGskdLZWqw
1484cdde97b801100ce3b06eb19d510b4f7408ff: Bug 1476106 - Part 1 - Make it possible to notify Java listeners from GeckoScreenOrientation, too. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 02 Aug 2018 21:10:33 +0200 - rev 431640
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1476106 - Part 1 - Make it possible to notify Java listeners from GeckoScreenOrientation, too. r=snorp Once responsibility for notifying GeckoScreenOrientation of potentially changed screen orientations moves from GeckoApp into GeckoView, the former will no longer be able to benefit from the return value of calling GeckoScreen- Orientation.update(), indicating whether the orientation actually changed or in fact remained the same. GeckoApp however requires that information in order to reset/refresh parts of the UI when the orientation changes, and since GeckoScreenOrientation is already doing all the work of tracking screen orientation changes, we don't want to have to partially duplicate those efforts again in GeckoApp. Instead, we introduce a mechanism for GeckoScreenOrientation to notify interested parties on the Android app side as well. The GeckoScreenOrientation.update() call in GeckoApp.onResume() is removed completely (as opposed to merely removing the refreshChrome() bit) at this stage already because it is unnecessary. If any screen rotation happened while the activity was in background, it will receive an onConfigurationChanged() call anyway before being resumed again. MozReview-Commit-ID: Ila1evcj8Ud
20b991052ad7bf4dcd30b34b7f49397bb789e2da: Bug 1476106 - Part 0 - Cleanup imports. r=JanH
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 02 Aug 2018 20:51:17 +0200 - rev 431639
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1476106 - Part 0 - Cleanup imports. r=JanH MozReview-Commit-ID: UHUdrWSIks
aaabe6d53de26960892d20922454b64708ad2319: Bug 1428713 - [mozprocess] Add support for Python 3 r=davehunt
Pavel Slepushkin <slepushkin@yandex.ru> - Sat, 04 Aug 2018 17:32:57 +0200 - rev 431638
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1428713 - [mozprocess] Add support for Python 3 r=davehunt MozReview-Commit-ID: 9wHoIEboA0K
6560b92dbe64151387d6dd2e73167912a17d3af2: Bug 1482306 - Ensure that tables are enabled when shared between features. r=dimi!
Francois Marier <francois@mozilla.com> - Wed, 15 Aug 2018 12:13:16 +0000 - rev 431637
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1482306 - Ensure that tables are enabled when shared between features. r=dimi! The enable/disable logic of the list manager was wrong. If multiple features shared a given table (e.g. tracking protection and tracking annotations) and only one of them was enabled, then updates could either be disabled or enabled depending on which feature was checked first. By disabling everything at the beginning and selectively re-enabling tables, we can ensure that no table gets both enabled and disabled by different feature toggles. Differential Revision: https://phabricator.services.mozilla.com/D3259
68faa8b52f60394faf626d19dc3c439c48e23cfb: Bug 1483394: Remove unneeded #includes of nsContentUtils.h in /layout. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 15 Aug 2018 07:04:43 +0000 - rev 431636
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1483394: Remove unneeded #includes of nsContentUtils.h in /layout. r=TYLin For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity. Differential Revision: https://phabricator.services.mozilla.com/D3370
1cee6e0d07e7aaf3a152d2eb15e2114937ce4151: Bug 1476555 - Show notification when autoplay blocked globally. r=cpearce,johannh
Dale Harvey <dale@arandomurl.com> - Mon, 23 Jul 2018 16:43:08 +0100 - rev 431635
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1476555 - Show notification when autoplay blocked globally. r=cpearce,johannh MozReview-Commit-ID: EI0GiaoBNqX
41443a067773651862461210bd73a521fb396aaf: Bug 1481815 - generate damp subtest alerts. r=rwood
Joel Maher <jmaher@mozilla.com> - Wed, 15 Aug 2018 14:47:27 +0000 - rev 431634
Push 34449 by dvarga@mozilla.com at Wed, 15 Aug 2018 22:19:00 +0000
Bug 1481815 - generate damp subtest alerts. r=rwood allow damp to generate alerts for the subtests Differential Revision: https://phabricator.services.mozilla.com/D3203
2cc6ec2f7f0e1f945858b493133c6a26c0b4c09f: Bug 1472992 - [jsshell] Run javascript shell benchmarks against Google V8, r=jmaher
Andrew Halberstadt <ahalberstadt@mozilla.com> - Wed, 15 Aug 2018 13:52:47 +0000 - rev 431633
Push 34448 by btara@mozilla.com at Wed, 15 Aug 2018 17:54:38 +0000
Bug 1472992 - [jsshell] Run javascript shell benchmarks against Google V8, r=jmaher This runs the jsshell benchmarks against Google's V8 engine in addition to spidermonkey. Both shells will run in the same task to keep things simple and decluttered. Though we could split them out to separate tasks at a later date if needed. Differential Revision: https://phabricator.services.mozilla.com/D3356
c340d01c2552260a7d96ec5699594e6167f7bb43: Backed out changeset d08617053829 (bug 1428713) for awsy-base failures. CLOSED TREE
Brindusan Cristian <cbrindusan@mozilla.com> - Wed, 15 Aug 2018 16:46:18 +0300 - rev 431632
Push 34448 by btara@mozilla.com at Wed, 15 Aug 2018 17:54:38 +0000
Backed out changeset d08617053829 (bug 1428713) for awsy-base failures. CLOSED TREE
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip