7f4cc96fae1212cb2220770ac7311b9cc51af744: Bug 1471025: Part 7b - Don't load preference files in the content process. r=njn
Kris Maglione <maglione.k@gmail.com> - Sat, 07 Jul 2018 12:45:57 -0700 - rev 481719
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 7b - Don't load preference files in the content process. r=njn With the parent sending a snapshot of its preference state at content process startup, we're guaranteed to have the full set of built-in preferences in the shared map at initialization time, so there's no need to load them again. This also applies to static preference default values, so we skip setting those, as well. However, we do need to make sure that we update static preference cache entries whose default values don't match the value in the shared map, since they may have been changed by user preference files. In order to deal with that, we iterate over all preferences in the map, and dispatch callbacks for any that have user values. MozReview-Commit-ID: DlRUbg7Qor3
b4f9178f132de2b5f7064df9a9e1b489ea6576c3: Bug 1471025: Part 7a - Look up preferences from both dynamic and shared preference tables. r=njn
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 22:52:53 -0700 - rev 481718
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 7a - Look up preferences from both dynamic and shared preference tables. r=njn This patch changes our preference look-up behavior to first check the dynamic hashtable, and then fall back to the shared map. In order for this to work, we need to make several other changes as well: - Attempts to modify a preference that only exists in the shared table requires that we copy it to the dynamic table, and change the value of the new entry. - Attempts to clear a user preference with no default value, but which also exists in the shared map, requires that we keep an entry in the dynamic table to mask the shared entry. To make this work, we change the type of these entries to None, and ignore them during look-ups and iteration. - Iteration needs to take both hashtables into consideration. The serialization iterator for changed preferences only needs to care about dynamic values, so it remains unchanged. Most of the others need to use PrefsIter() instead. MozReview-Commit-ID: 9PWmSZxoC9Z
8eff817d2f7e07409269899c048a9091220dec07: Bug 1471025: Part 6 - Optimize preference lookups while dispatching callbacks. r=njn
Kris Maglione <maglione.k@gmail.com> - Sat, 07 Jul 2018 12:47:34 -0700 - rev 481717
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 6 - Optimize preference lookups while dispatching callbacks. r=njn Since lookups in the snapshotted hashtable are currently O(log n) rather than O(1), they're expected to be slightly more expensive than the previous purely-dynamic lookups. In general, I expect this not to be a major issue. The main concern is pref cache lookups while initializing the database. Initialization in the parent process will still always use only a dynamic hashtable, so the performance characteristics there won't change. In the child process, though, we'll still need to notify observers of preferences in the snapshot when they have user values, which could require any number of lookups at startup (though in practice probably will not). This patch solves that problem by caching the wrapper for the current known preference value when dispatching callbacks, and optimizing lookups for that value when it is present. MozReview-Commit-ID: 2CAn0rM0bE9
f9362cf1add47c2f62529e42764ed6088d274170: Bug 1471025: Part 5 - Add a range iterator helper for iterating both static and dynamic preferences. r=njn
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 18:17:48 -0700 - rev 481716
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 5 - Add a range iterator helper for iterating both static and dynamic preferences. r=njn For memory efficiency in content processes, we need to be able to store changed preferences in a separate dynamic hashtable when their values don't match the snapshot values. That makes iteration over the full set of preferences somewhat more complicated, since not only do we need to iterate over two tables, but we also need to ignore preferences in the snapshot table if they also exist in the dynamic hashtable. This patch solves that problem by adding an iterator helper which iterates over values in both tables, and skips values in the static table if they also exist in the dynamic table. In order to support completely deleting preferences that exist in the base table, it also ignores all dynamic entries with the None type, so that they can completely mask deleted base table values. MozReview-Commit-ID: LCIwyPJMByj
ce379eaab17905f39f1665c3e40f683ebd3f8824: Bug 1471025: Part 4 - Add a wrapper class that can access either static or dynamic prefs. r=njn
Kris Maglione <maglione.k@gmail.com> - Sun, 01 Jul 2018 23:23:48 -0700 - rev 481715
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 4 - Add a wrapper class that can access either static or dynamic prefs. r=njn The in-memory format of shared-memory preferences is significantly different from the format used by dynamic preferences, which means that we need different classes to access their properties. Virtual classes would be a potential solution to this problem, but I don't think the performance characteristics would be acceptable for preferences code. And since the wrapper classes used for static prefs are temporary, they would add the additional snag of figuring out how to keep a valid pointer alive. So, instead, this patch adds a wrapper class that can access either type of preference, based on known type flags in a Variant. It also moves some of the logic for deciding which preference value to return to the wrapper, so that it doesn't need to be duplicated for each representation. MozReview-Commit-ID: LameIIbYcD3
7c03b7dd00e9675f9ac045ed1ea733eb0486904f: Bug 1471025: Part 3c - Also pass the shared preference map handle to Android content processes. r=jld
Kris Maglione <maglione.k@gmail.com> - Fri, 13 Jul 2018 11:06:58 -0700 - rev 481714
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 3c - Also pass the shared preference map handle to Android content processes. r=jld MozReview-Commit-ID: CTjDzVC9gcD
ff41551f5ff1b98b72ed771a6f2a3f66a8b79a57: Bug 1471025: Part 3b - Refactor Android shared FD API to require fewer modifications per change. r=jld
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 15:01:25 -0700 - rev 481713
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 3b - Refactor Android shared FD API to require fewer modifications per change. r=jld Adding or removing an FD from this API currently requires changes in about a half dozen places. Ignoring the Java side of things. This patch changes the API to pass a struct, rather than additional arguments for each FD, so that adding and removing FDs only requires changing one declaration, and the two call sites that add and consume the FDs. MozReview-Commit-ID: CToSEVp1oqP
46a6f9d0773ba2d756d8801cee79bfa994165d44: Bug 1471025: Part 3a - Pass shared preference map to (non-Android) content processes at startup. r=jld,njn
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 15:40:38 -0700 - rev 481712
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 3a - Pass shared preference map to (non-Android) content processes at startup. r=jld,njn This adds an additional file descriptor to the set sent at content process startup, for the read-only preference map that we share between all content processes. This forms the base set of preferences. The other preferences FD contains changes that the content process will need to apply on top of the snapshot. MozReview-Commit-ID: 6hc0HIxFmHg
434106f1b75e3ba900912f261bd22a1b7f5c931d: Bug 1471025: Part 2 - Add a helper class creating and accessing shared preference map snapshots. r=njn,erahm
Kris Maglione <maglione.k@gmail.com> - Sun, 01 Jul 2018 18:28:31 -0700 - rev 481711
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 2 - Add a helper class creating and accessing shared preference map snapshots. r=njn,erahm This is based on the SharedStringMap that's currently used for shared memory string bundles. When the parent process is ready to launch its first content process, it creates a snapshot of the current state of the preference database, maps that as read-only, and shares it with each content process. Look-ups in the snapshotted map are done entirely using data in the shared memory region. It doesn't require any additional per-process state data. MozReview-Commit-ID: BdTUhak7dmS
c490838c8329f6b0c21fa57ef078c44bf7a9ba8d: Bug 1471025: Part 1 - Store preference access counts in a separate hashtable. r=njn
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 23:33:28 -0700 - rev 481710
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1471025: Part 1 - Store preference access counts in a separate hashtable. r=njn Once the majority of preferences are stored in a read-only shared map, it won't be possible to modify the access counts in their entries. Which means we need a separate map for the access counts. Fortunately, this code is only active in debug builds, so it shouldn't affect release users. And the net impact on memory usage of this patchset will still be decidedly downward. MozReview-Commit-ID: EuLXlMQJP1M
315103f6db6b1f44647d82c0f494c2d45fc42e07: Backed out 3 changesets (bug 1459937) for failing crashtest with Assertion failure: (IndexInFlow(aOldParent) < IndexInFlow(aNewParent)) on a CLOSED TREE
Andreea Pavel <apavel@mozilla.com> - Sun, 15 Jul 2018 10:06:23 +0300 - rev 481709
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Backed out 3 changesets (bug 1459937) for failing crashtest with Assertion failure: (IndexInFlow(aOldParent) < IndexInFlow(aNewParent)) on a CLOSED TREE Backed out changeset 2cff5c67d000 (bug 1459937) Backed out changeset fb3fba19e615 (bug 1459937) Backed out changeset bd4bd8ac335c (bug 1459937)
2cff5c67d000031ae1cc30f0a89ceb8503c3ff27: Bug 1459937 - In DEBUG mode, verify that reparenting direction is correct - r=dbaron
Gerald Squelart <gsquelart@mozilla.com> - Tue, 10 Jul 2018 15:35:48 +1000 - rev 481708
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1459937 - In DEBUG mode, verify that reparenting direction is correct - r=dbaron MozReview-Commit-ID: JPfg9YtBm6M
fb3fba19e6158564e769f81e1bb66cfe4724e089: Bug 1459937 - Mark pulled floats (from pulled lines) dirty - r=dbaron
Gerald Squelart <gsquelart@mozilla.com> - Tue, 10 Jul 2018 11:36:33 +1000 - rev 481707
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1459937 - Mark pulled floats (from pulled lines) dirty - r=dbaron Similar to lines (see previous patch), floats from next-in-flow or overflow frames have probably not been marked dirty (as ReflowInput hasn't dealt with them when it was constructed), so we need to mark them dirty for proper reflow. If we don't do that, and they don't fit in the current column, the next column will only mark its current children dirty, so when pulling back its first floats from the previous column they will not be reflowed as needed. MozReview-Commit-ID: KKrwtzeQMrI
bd4bd8ac335c77a89b255cf6be616081a4bfd1e3: Bug 1459937 - Mark pulled lines (from n-i-f or overflow) dirty - r=dbaron
Gerald Squelart <gsquelart@mozilla.com> - Mon, 09 Jul 2018 11:42:47 +1000 - rev 481706
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1459937 - Mark pulled lines (from n-i-f or overflow) dirty - r=dbaron Lines pulled from next-in-flow or overflow frames have probably not been marked dirty (as ReflowInput hasn't dealt with them when it was constructed), so we need to mark them dirty for proper reflow. If we don't do that, and they don't fit in the current column, the next column will only mark its current children dirty, so when pulling back its first lines from the previous column they will not be reflowed as needed, which causes this bug. MozReview-Commit-ID: 8GFO1ZWuZ1b
9b4b53a145386e6be47b9acce399a02f427285f4: Bug 1472580 - Ensure we always get a allow/cancel response to an autoplay media permission request. r=smaug
Chris Pearce <cpearce@mozilla.com> - Fri, 06 Jul 2018 21:15:20 +1200 - rev 481705
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1472580 - Ensure we always get a allow/cancel response to an autoplay media permission request. r=smaug The front end code can't always guarantee to give us an allow/cancel response to a permission request. In particular in these cases: * if we close a tab while showing a doorhanger, or * if we navigate a tab while showing a doorhanger, or * if the permission prompt requested in a background tab and never shown. Handling all of these cases is problematic; we don't get events for all of these where it's easy and cheap to determine that we should cancel the permission request. Canceling the permission request is important in the autoplay-media permission request case as there's objects waiting on the resolution of the permission request, and they leak in ASan builds while running chrome tests if the Gecko size of the permission request doesn't get a notification telling it to stop waiting. But we can however rely on the doorhanger code to drop its reference to the nsIContentPermissionRequest object that we pass to it when the doorhanger goes away. So we can cancel the permission request in our nsIContentPermissionRequest's implementation's destructor in order to easily catch all the above cases. In order to do that, we need to split AutoplayRequest into two; one part being the implementation of nsIContentPermissionRequest (AutoplayPermissionRequest), and the other part being the code to own the PromiseHolder and manage the permission request (AutoplayPermissionManager). AutoplayPermissionRequest keeps a weak reference to AutoplayPermissionManager, so that it can tell the AutoplayPermissionManager to reject the request promise when it's destroyed. This fixes the ASan leak for which I got backed out from earlier in this bug, and also fixes the cases above. MozReview-Commit-ID: KoVkgIqDleW
a1a2ee0ee145f0a61c450d979dc23c4fd3b849a2: Bug 1472580 - Test that starting play from tab audio indicator overrides block autoplay. r=mconley
Chris Pearce <cpearce@mozilla.com> - Mon, 25 Jun 2018 13:25:34 +1200 - rev 481704
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1472580 - Test that starting play from tab audio indicator overrides block autoplay. r=mconley MozReview-Commit-ID: 6RB09cd1PHP
a2c0973c0454856e7d594d513a8b03ae794ede05: Bug 1472580 - Gesture activate documents which are played via the tab audio indicator. r=mconley
Chris Pearce <cpearce@mozilla.com> - Wed, 04 Jul 2018 09:32:22 +1200 - rev 481703
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1472580 - Gesture activate documents which are played via the tab audio indicator. r=mconley (This patch was first presented for review in bug 1463919, I've split it off into its own bug here). If the user opens a tab in the background, and that tab tries to play media, we'll delay playing that media until the tab is brought to the foreground. But the user can explicitly start playback of such delayed media by clicking the "play" icon we show in the tab indicator. Then if autoplay is disabled, we'll block the play (unless the origin is whitelisted). This is bad, as the user has clearly indicated intent to play media in this tab. So this patch "gesture activates" the root content document when the tab audio indicator play button is pressed. This means the block autoplay logic will behave as if there's been a user gesture in the tab (mouse click or keypress), and not block the play. Gesture activation state is per document, so it does not persist across document loads. MozReview-Commit-ID: 3pgrADRrJqt *** fix
3acee2d5cd9d94252bbffba40799b09aee9daa64: Bug 1463554 - Position the HTML select dropdown exactly on the rich option element.r=MattN
prathiksha <prathikshaprasadsuman@gmail.com> - Fri, 06 Jul 2018 12:30:09 -0700 - rev 481702
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1463554 - Position the HTML select dropdown exactly on the rich option element.r=MattN MozReview-Commit-ID: 5Rl3lMczGyh
74971b656b9232052ebdeaf52e60ef9253547e90: Bug 1463554 - Fix the tests that are broken due to change in the internal structure of rich-select.r=MattN
prathiksha <prathikshaprasadsuman@gmail.com> - Wed, 27 Jun 2018 17:32:54 -0700 - rev 481701
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1463554 - Fix the tests that are broken due to change in the internal structure of rich-select.r=MattN MozReview-Commit-ID: BTHw9JHZoud
e47e23fcb698e7b00844015f8e934b2b8b245301: Bug 1463554 - Fix auto-selection errors in pickers on the payment summary page.r=MattN
prathiksha <prathikshaprasadsuman@gmail.com> - Thu, 21 Jun 2018 15:03:36 -0700 - rev 481700
Push 9719 by ffxbld-merge at Fri, 24 Aug 2018 17:49:46 +0000
Bug 1463554 - Fix auto-selection errors in pickers on the payment summary page.r=MattN MozReview-Commit-ID: Hlj7RHXnpWi
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip