searching for reviewer(mconley)
c1d83dcf63762028c6601f34d3e83466fe2ceca9: Bug 1595143 - Port LightweightThemeChild to JSWindowActors r=mconley,Gijs
James Jahns <jahnsjam@msu.edu> - Mon, 18 Nov 2019 22:51:18 +0000 - rev 502504
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1595143 - Port LightweightThemeChild to JSWindowActors r=mconley,Gijs Differential Revision: https://phabricator.services.mozilla.com/D52555
d5db2146b9c5519a2d42233c4699818ba347ec2a: Bug 1596800 - Remove document.getBindingParent usage from autocomplete-popup. r=mconley
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 18 Nov 2019 19:06:51 +0000 - rev 502474
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596800 - Remove document.getBindingParent usage from autocomplete-popup. r=mconley This preserves the behavior, though I think we could probably remove that block altogether? Depends on D53340 Differential Revision: https://phabricator.services.mozilla.com/D53341
cceae677e859c9915d895bee2783ca1c0c34a296: Bug 1596800 - Remove document.getBindingParent usage from preferences search. r=mconley
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 18 Nov 2019 19:07:47 +0000 - rev 502472
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596800 - Remove document.getBindingParent usage from preferences search. r=mconley When the focus moves elsewhere inside the <tree> blur events aren't dispatched outside the shadow tree (as expected), so checking the originalTarget is always bogus. Furthermore, the event handler does nothing if the input isn't focused, and when the input is blurred the tree takes care of calling stopEditing itself, so this change should be pretty safe in general: https://searchfox.org/mozilla-central/rev/492214c05cde6e6db5feff9465ece4920400acc3/toolkit/content/widgets/tree.js#1083 It's not clear to me whether the blur event handler is doing anything at all after bug 1547382 (before this patch), as the binding parent is not a <xul:textbox> anymore, so <input>.getBindingParent() will return the <tree>... Depends on D53338 Differential Revision: https://phabricator.services.mozilla.com/D53339
5bc4fbe48df7276c4b6da448e9b85953620ac913: Bug 1596800 - Remove document.getBindingParent usage from PluginChild.jsm. r=mconley
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 18 Nov 2019 19:06:50 +0000 - rev 502471
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596800 - Remove document.getBindingParent usage from PluginChild.jsm. r=mconley It wants to get the containing shadow host of the target to get to the plugin. Do that explicitly. Depends on D53337 Differential Revision: https://phabricator.services.mozilla.com/D53338
85408aaba4a32de2ecf495093f24643e93154292: Bug 1596800 - Remove unneeded forced layout flush in PluginChild.jsm. r=mconley
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 18 Nov 2019 19:06:50 +0000 - rev 502470
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596800 - Remove unneeded forced layout flush in PluginChild.jsm. r=mconley We don't need layout flushes to attach XBL bindings anymore, as there are no XBL bindings. This is drive-by. Depends on D53336 Differential Revision: https://phabricator.services.mozilla.com/D53337
b39ba65e2071c2e8f84b166ad367f7fd8c40f7d4: Bug 1583951 - Remove XUL grid from printPreviewProgress.xul. r=mconley
Tim Nguyen <ntim.bugs@gmail.com> - Mon, 18 Nov 2019 19:33:56 +0000 - rev 502459
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1583951 - Remove XUL grid from printPreviewProgress.xul. r=mconley Differential Revision: https://phabricator.services.mozilla.com/D53307
57308405ef981e915faa3493c44207eb7a25cef7: Bug 1595647 - fix flash permissions so they get set for the toplevel page's principal instead of the subframe, r=mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Mon, 18 Nov 2019 18:56:08 +0000 - rev 502453
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1595647 - fix flash permissions so they get set for the toplevel page's principal instead of the subframe, r=mconley This is the historical behaviour here (cf. bug 1305232, bug 853855). I accidentally broke it when I refactored this code for fission. This restores the "old" behaviour. Differential Revision: https://phabricator.services.mozilla.com/D53351
df333402f12666918a136e961c4f0bb0c6ffc40a: Bug 1596090 - use staticprefs for flash enabled state pref, r=mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Wed, 13 Nov 2019 21:17:12 +0000 - rev 502304
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596090 - use staticprefs for flash enabled state pref, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D52845
4921e64c42017a8fc5d935eb12e3334bb23a7b60: Bug 1596862 - Add fission.autostart to PREFS_WHITELIST in Troubleshoot.jsm r=mconley
Andrew McCreight <continuation@gmail.com> - Fri, 15 Nov 2019 20:39:53 +0000 - rev 502286
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596862 - Add fission.autostart to PREFS_WHITELIST in Troubleshoot.jsm r=mconley Differential Revision: https://phabricator.services.mozilla.com/D53246
ae8d3569d4b4f2a2877c640bb61d62b14113d43f: Bug 1590769 - Scale PiP player window correctly on OS X retina r=mconley
Mark Striemer <mstriemer@mozilla.com> - Fri, 15 Nov 2019 18:53:13 +0000 - rev 502282
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1590769 - Scale PiP player window correctly on OS X retina r=mconley Differential Revision: https://phabricator.services.mozilla.com/D53098
4177c6123ddb391dc50894ddecb6d244b4f0bfd0: Bug 1596834 - Use forceNewProcess in browser_permmgr_sync.js. r=mconley
Andrew McCreight <continuation@gmail.com> - Fri, 15 Nov 2019 17:24:11 +0000 - rev 502246
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596834 - Use forceNewProcess in browser_permmgr_sync.js. r=mconley Also fix a few typos in comments. Differential Revision: https://phabricator.services.mozilla.com/D53229
dea221c2e93e9ebc1c9d117b42a42c9399f7b744: Bug 1594521 - enable remote settings blocklist on nightly, r=mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 15 Nov 2019 16:54:23 +0000 - rev 502237
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1594521 - enable remote settings blocklist on nightly, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D52939
cab5d681291405a636d403d0cb9bf5359f58afbb: Bug 1595927 - Remove XPCOM gunk around RemoteWebNavigation creation. r=mconley
Kris Maglione <maglione.k@gmail.com> - Fri, 15 Nov 2019 01:23:40 +0000 - rev 502097
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1595927 - Remove XPCOM gunk around RemoteWebNavigation creation. r=mconley It just adds a lot of unnecessary overhead and indirection. Differential Revision: https://phabricator.services.mozilla.com/D52753
70304898d836c345e2ad3583ed148bb5ba0797d9: Bug 1595927 - Remove XPCOM gunk around RemoteWebNavigation creation. r=mconley
Kris Maglione <maglione.k@gmail.com> - Thu, 14 Nov 2019 19:09:22 +0000 - rev 502005
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1595927 - Remove XPCOM gunk around RemoteWebNavigation creation. r=mconley It just adds a lot of unnecessary overhead and indirection. Differential Revision: https://phabricator.services.mozilla.com/D52753
f7cc2f6d9640820f5278bbc7787ccae542e06e69: Bug 1591253 - Maintain PiP player position when source video is resized r=mconley
Mark Striemer <mstriemer@mozilla.com> - Thu, 14 Nov 2019 00:32:05 +0000 - rev 502000
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1591253 - Maintain PiP player position when source video is resized r=mconley Differential Revision: https://phabricator.services.mozilla.com/D52064
bc637c20c7d4c06835d3269e9a3558feacb6c28e: Bug 1535437 - Part 2: Resize PiP window when video source resizes r=mconley
Mark Striemer <mstriemer@mozilla.com> - Tue, 12 Nov 2019 20:51:51 +0000 - rev 501999
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1535437 - Part 2: Resize PiP window when video source resizes r=mconley Differential Revision: https://phabricator.services.mozilla.com/D50139
6e3d285d14eeffbf8861d39c664b796bd9640322: Bug 1594521 - enable remote settings blocklist on nightly, r=mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Thu, 14 Nov 2019 14:43:17 +0000 - rev 501968
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1594521 - enable remote settings blocklist on nightly, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D52939
6b2ea992707b0475e9424b6ae02eb1ebb32df6d6: bug 1594351: toolkit: add AppConstants.REMOTE_AGENT; r=remote-protocol-reviewers,maja_zf,mconley
Andreas Tolfsen <ato@sny.no> - Thu, 14 Nov 2019 13:32:01 +0000 - rev 501926
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
bug 1594351: toolkit: add AppConstants.REMOTE_AGENT; r=remote-protocol-reviewers,maja_zf,mconley The remote agent is a forthcoming new low-level debugging interface in Gecko. This constant will tell toolkit code that the feature is enabled. Differential Revision: https://phabricator.services.mozilla.com/D52357
1f6cd5814db95dda18ac4aeaffe2dffcd2b887d9: Bug 1533943, modify WebNavigation to inherit from JSWindowActor, r=mconley
Neil Deakin <neil@mozilla.com> - Thu, 14 Nov 2019 00:53:29 +0000 - rev 501908
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1533943, modify WebNavigation to inherit from JSWindowActor, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D50886
6e3c105cfcde3a6821120a83674f77692f5c7bf2: Bug 1533943, modify WebNavigation to inherit from JSWindowActor, r=mconley
Neil Deakin <neil@mozilla.com> - Thu, 14 Nov 2019 00:53:29 +0000 - rev 501868
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1533943, modify WebNavigation to inherit from JSWindowActor, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D50886
60db8c551c38d0619df981ac11e5616b8d8e3002: Bug 1586920 - Strip non-chrome/resource URLs from BHR r=mconley
Doug Thayer <dothayer@mozilla.com> - Wed, 13 Nov 2019 21:07:07 +0000 - rev 501847
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1586920 - Strip non-chrome/resource URLs from BHR r=mconley This is just a precaution - I can't actually observe any instances of the dynamic strings added in the parent revision including anything other than chrome or resource URLs. However, since we are including URLs and since there's no hard guarantees that we won't accidentally cause, say, a file:// URL to make it in here, it seems like a reasonable precaution to strip them out. Differential Revision: https://phabricator.services.mozilla.com/D52114
7cb704c0ca2b72fa6c7e0fe8e584c203574b30e9: Bug 1588203 - Change process for tab open in cpstartup r=mconley
Doug Thayer <dothayer@mozilla.com> - Mon, 11 Nov 2019 16:25:53 +0000 - rev 501491
Push 114170 by malexandru@mozilla.com at Tue, 12 Nov 2019 21:58:32 +0000
Bug 1588203 - Change process for tab open in cpstartup r=mconley This will cause us to actually launch a new content process, which we were previously not doing. Differential Revision: https://phabricator.services.mozilla.com/D50708
aa04697d9a3f061726fd6acec930bfaa4062d290: Bug 1595048 - move JSWindowActor notes into Fission.rst document, r=mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 08 Nov 2019 19:42:02 +0000 - rev 501354
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1595048 - move JSWindowActor notes into Fission.rst document, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D52352
4c42cbc6d2221687687f668ddbeca090683dfb7f: Bug 1590540 - Remove BrowserTestUtils.contentPainted, r=mconley
Kashav Madan <kmadan@mozilla.com> - Fri, 08 Nov 2019 16:24:40 +0000 - rev 501321
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1590540 - Remove BrowserTestUtils.contentPainted, r=mconley This helper only has 2 callers. Just use BrowserTestUtils.waitForContentEvent directly. Depends on D51441 Differential Revision: https://phabricator.services.mozilla.com/D52058
bfa48920ac65d80927aa7f56324d94a574098e46: Bug 1590445, only adjust zoom level for FullZoomChange and TextZoomChange events for top-level frames, r=mconley
Neil Deakin <neil@mozilla.com> - Tue, 05 Nov 2019 00:08:18 +0000 - rev 501312
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1590445, only adjust zoom level for FullZoomChange and TextZoomChange events for top-level frames, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D51617
dacb2051e47e4664bfa38a5015f37121627725d9: Bug 1593487 - tighten up registerWindowActor's handling of nonsensical actor specifications and remove cruft, r=nika,mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 08 Nov 2019 11:59:37 +0000 - rev 501240
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1593487 - tighten up registerWindowActor's handling of nonsensical actor specifications and remove cruft, r=nika,mconley Differential Revision: https://phabricator.services.mozilla.com/D52002
897eb7fb05808abaf1c3e293743a64629a7f1766: Bug 1594472 - do less work for same-document navigations, r=MattN,mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Thu, 07 Nov 2019 21:02:26 +0000 - rev 501187
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1594472 - do less work for same-document navigations, r=MattN,mconley Updating tab - mute state - audio playing indicator state - find bar state - tab titles - icons is not necessary when the navigation is same-document. Avoid doing the work. Differential Revision: https://phabricator.services.mozilla.com/D52109
8cc74a09b1c61b0bcc8a58281dbcf6581ff77b12: Bug 1588193 - Register the ContentEventListener actor for every browsing context, r=mconley
Kashav Madan <kmadan@mozilla.com> - Thu, 07 Nov 2019 21:16:01 +0000 - rev 501167
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1588193 - Register the ContentEventListener actor for every browsing context, r=mconley Various BrowserTestUtils.waitForContentEvent call sites expect to see an event on a browser element that was open before the call was made. For this reason, each of the browsers need to also have a ContentEventListener actor. Depends on D51439 Differential Revision: https://phabricator.services.mozilla.com/D51440
da87ab43340f87e85b4a0df593df957d7dbf18be: Bug 1591259, insert catch block before accessing PushService to avoid exception during session-windows-restored r=mconley
Emma Malysz <emalysz@mozilla.com> - Wed, 06 Nov 2019 17:36:45 +0000 - rev 500895
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1591259, insert catch block before accessing PushService to avoid exception during session-windows-restored r=mconley Differential Revision: https://phabricator.services.mozilla.com/D52053
8fe301759bc7130ca2df03e954a81a07de3d3a50: Bug 1590385 - Renew startup cache / script preloader telemetry r=mconley
Doug Thayer <dothayer@mozilla.com> - Wed, 06 Nov 2019 16:45:07 +0000 - rev 500882
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1590385 - Renew startup cache / script preloader telemetry r=mconley These will be expiring - they're still relevant though, given recent work on the startup cache and continued interest in startup perf. Differential Revision: https://phabricator.services.mozilla.com/D51499
1ada54e7ba7c2cf72aa2f19c71aeb1f535c9d1ea: Bug 1588193 - Register the ContentEventListener actor for every browsing context, r=mconley
Kashav Madan <kmadan@mozilla.com> - Wed, 06 Nov 2019 15:35:18 +0000 - rev 500864
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1588193 - Register the ContentEventListener actor for every browsing context, r=mconley Various BrowserTestUtils.waitForContentEvent call sites expect to see an event on a browser element that was open before the call was made. For this reason, each of the browsers need to also have a ContentEventListener actor. Differential Revision: https://phabricator.services.mozilla.com/D51440
b10ec4058ec3aee7c9cde560a6afeeaca7bce2c9: Bug 1588193 - Register the ContentEventListener actor for every browsing context, r=mconley
Kashav Madan <kmadan@mozilla.com> - Tue, 05 Nov 2019 21:52:23 +0000 - rev 500757
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1588193 - Register the ContentEventListener actor for every browsing context, r=mconley Various BrowserTestUtils.waitForContentEvent call sites expect to see an event on a browser element that was open before the call was made. For this reason, each of the browsers need to also have a ContentEventListener actor. Differential Revision: https://phabricator.services.mozilla.com/D51440
7271753097f953121de6e4a7881abf1111c3794d: Bug 1594123 - Fix lookup of toolbarbutton-icon in TabsList r=mconley
Brian Grinstead <bgrinstead@mozilla.com> - Tue, 05 Nov 2019 18:22:38 +0000 - rev 500683
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1594123 - Fix lookup of toolbarbutton-icon in TabsList r=mconley document.getAnonymousElementByAttribute is dead code now, and even when it wasn't this would have returned null ever since <toolbarbutton> stopped using XBL. Differential Revision: https://phabricator.services.mozilla.com/D51727
b2bf4da4035056149dd1ad4e2fb0a84839c77f53: Bug 1567493 - Date Input field pushes the year back by one year each time you type a '0' in the month part of the input field, r=mconley
Olli Pettay <Olli.Pettay@helsinki.fi> - Mon, 04 Nov 2019 21:16:34 +0000 - rev 500459
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1567493 - Date Input field pushes the year back by one year each time you type a '0' in the month part of the input field, r=mconley Tweaking the patch for bug 1445207 a tiny bit. Unfortunately we don't seem to have good way to test this. Differential Revision: https://phabricator.services.mozilla.com/D51408
3ac07ce7e004f4e07ac9a48458460e9a1fe7a568: Bug 1575075 - Add an audio toggle button in PiP to mute and unmute a video. r=mconley
Gabriel Luong <gabriel.luong@gmail.com> - Mon, 04 Nov 2019 21:14:50 +0000 - rev 500458
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1575075 - Add an audio toggle button in PiP to mute and unmute a video. r=mconley Differential Revision: https://phabricator.services.mozilla.com/D51413
72d319686ce0e806c83c47cf8f7ae27372ae3f1a: Bug 1593463 - Fix RTL for about:tabcrashed r=Gijs,mconley
Itiel <itiel_yn8@walla.com> - Mon, 04 Nov 2019 18:17:41 +0000 - rev 500430
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1593463 - Fix RTL for about:tabcrashed r=Gijs,mconley Differential Revision: https://phabricator.services.mozilla.com/D51502
e5ca446ceff7f065799431197a6b2a7d68230c4c: Bug 1591140 - Allow chrome privileged documents to preventDefault contextmenu events regardless of dom.event.contextmenu.enabled r=gl,nika,mconley
Julian Descottes <jdescottes@mozilla.com> - Mon, 04 Nov 2019 08:20:02 +0000 - rev 500387
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1591140 - Allow chrome privileged documents to preventDefault contextmenu events regardless of dom.event.contextmenu.enabled r=gl,nika,mconley @gl can you take a look at the DevTools test added here? @nika @mconley I used this.browsingContext.docShell.isContent here to rule out chrome-privileged documents. Do you know if there is better way to check if the current document is chrome-privileged or not? Differential Revision: https://phabricator.services.mozilla.com/D51320
89521f19577223ea653809b25d04e33bb336cc53: Bug 1590644 - Set font family on the content select menupopup, not menuitem. r=mconley
Emilio Cobos Alvarez <emilio@mozilla.com> - Sun, 03 Nov 2019 10:04:34 +0000 - rev 500304
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1590644 - Set font family on the content select menupopup, not menuitem. r=mconley So that fonts chosen by the author inherit into the menuitems properly, instead of being overriden. Differential Revision: https://phabricator.services.mozilla.com/D51086
16d21676bcb9d75a488d25ac67f536331899b959: Bug 1545123 - move reading pluginreg and scanning for plugins to a background thread, r=handyman,mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Sat, 02 Nov 2019 22:35:04 +0000 - rev 500289
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1545123 - move reading pluginreg and scanning for plugins to a background thread, r=handyman,mconley Finally, let's move the actual IO away from the main thread. This means there are now 3 ways of looking for plugins: 1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable on the main thread. 2. loading plugins from LoadPlugins. This will: a) first check prefs and report the flash plugin based on that information, if the prefs indicate it exists (using the callback provided by nsPluginHost). b) then hopefully dispatch to a background thread, where it will read pluginreg.dat, scan the appropriate folders on disk, and see if anything changed. Once done, it sets mFinishedFinding to true and re-dispatches itself to the main thread. c) then on the main thread, it reports any changes to nsPluginHost. 3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main thread. Note: if ReloadPlugins is called, we intiially do (1), but if we find changes, we clear out the set of known plugins and then run LoadPlugins again (meaning we go through 2 (or 3 if 2(b) fails)). This is how reloading plugins worked prior to my changes and I've attempted not to change it. In order for this to work, there are some other changes in this commit: - the sandbox prefs are being read "early" and cached for flash vs "everything else". We can't access prefs on non-main threads without using StaticPrefs, which doesn't seem worth it here. - some of the plugin tag classes are moved to threadsafe refcounting. This is a bit unfortunate, but because they're instantiated on a non- mainthread, and then later used on the main thread, despite the fact that the architecture means nothing tries to touch them from more than one thread at once, without threadsafe refcounting we hit asserts in debug mode if we add references to them back on the main thread. - we add shutdown blocking for pluginfinding. We don't really want to be halfway through finding plugins and then trying to shut them down, or re-instantiating plugins after they've been unloaded. - we keep a reference to the "pending" pluginfinder instance while doing lookups away from the main thread (ie (2)), to avoid re-entrancy or trying to write to pluginreg while we're reading it somewhere else, etc. If there's an attempt to do more plugin finding while this is ongoing, we flip mDoReloadOnceFindingFinished and do a reload once our initial lookups are complete. Depends on D48331 Differential Revision: https://phabricator.services.mozilla.com/D48332
1facb4403c96f742879e63f418955a1ad93772b3: Bug 1545123 - simplify how we get directory information for plugins, r=handyman,mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Sat, 02 Nov 2019 22:33:42 +0000 - rev 500286
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1545123 - simplify how we get directory information for plugins, r=handyman,mconley In this change we: - stop treating the nsPluginDirServiceProvider as a directory provider, as its GetFile implementation was a no-op anyway - registering it didn't make any difference. - stop treating it as a class entirely, because the PLID getters were already static, so instantiating it also didn't do anything. - move IO from the plugin directory list provider and the Windows-only PLID getters into nsPluginHost. This enables us to move it off of the main thread later - the directory getting has to happen on the main thread, but we can postpone further checks on the nsIFile instances. - in the process, stop doing exists() calls on files because we can fail more lazily. This allows us to remove more allowlist entries from browser_startup_mainthreadio, though the `isDirectory` calls will actually still cause IO - they don't seem to create IO markers in the profiler. We will move this IO away from the main thread in subsequent commits. Depends on D48328 Differential Revision: https://phabricator.services.mozilla.com/D48329
91313cceae8c54aedd2b177ae14b10269e8e1678: Bug 1545123 - move reading pluginreg and scanning for plugins to a background thread, r=handyman,mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Wed, 30 Oct 2019 15:53:15 +0000 - rev 500270
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1545123 - move reading pluginreg and scanning for plugins to a background thread, r=handyman,mconley Finally, let's move the actual IO away from the main thread. This means there are now 3 ways of looking for plugins: 1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable on the main thread. 2. loading plugins from LoadPlugins. This will: a) first check prefs and report the flash plugin based on that information, if the prefs indicate it exists (using the callback provided by nsPluginHost). b) then hopefully dispatch to a background thread, where it will read pluginreg.dat, scan the appropriate folders on disk, and see if anything changed. Once done, it sets mFinishedFinding to true and re-dispatches itself to the main thread. c) then on the main thread, it reports any changes to nsPluginHost. 3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main thread. Note: if ReloadPlugins is called, we intiially do (1), but if we find changes, we clear out the set of known plugins and then run LoadPlugins again (meaning we go through 2 (or 3 if 2(b) fails)). This is how reloading plugins worked prior to my changes and I've attempted not to change it. In order for this to work, there are some other changes in this commit: - the sandbox prefs are being read "early" and cached for flash vs "everything else". We can't access prefs on non-main threads without using StaticPrefs, which doesn't seem worth it here. - some of the plugin tag classes are moved to threadsafe refcounting. This is a bit unfortunate, but because they're instantiated on a non- mainthread, and then later used on the main thread, despite the fact that the architecture means nothing tries to touch them from more than one thread at once, without threadsafe refcounting we hit asserts in debug mode if we add references to them back on the main thread. - we add shutdown blocking for pluginfinding. We don't really want to be halfway through finding plugins and then trying to shut them down, or re-instantiating plugins after they've been unloaded. - we keep a reference to the "pending" pluginfinder instance while doing lookups away from the main thread (ie (2)), to avoid re-entrancy or trying to write to pluginreg while we're reading it somewhere else, etc. If there's an attempt to do more plugin finding while this is ongoing, we flip mDoReloadOnceFindingFinished and do a reload once our initial lookups are complete. Depends on D48331 Differential Revision: https://phabricator.services.mozilla.com/D48332
a139ee11551926d3746825e92051b635fe2ae084: Bug 1545123 - simplify how we get directory information for plugins, r=handyman,mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 29 Oct 2019 05:30:29 +0000 - rev 500267
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1545123 - simplify how we get directory information for plugins, r=handyman,mconley In this change we: - stop treating the nsPluginDirServiceProvider as a directory provider, as its GetFile implementation was a no-op anyway - registering it didn't make any difference. - stop treating it as a class entirely, because the PLID getters were already static, so instantiating it also didn't do anything. - move IO from the plugin directory list provider and the Windows-only PLID getters into nsPluginHost. This enables us to move it off of the main thread later - the directory getting has to happen on the main thread, but we can postpone further checks on the nsIFile instances. - in the process, stop doing exists() calls on files because we can fail more lazily. This allows us to remove more allowlist entries from browser_startup_mainthreadio, though the `isDirectory` calls will actually still cause IO - they don't seem to create IO markers in the profiler. We will move this IO away from the main thread in subsequent commits. Depends on D48328 Differential Revision: https://phabricator.services.mozilla.com/D48329
2a832a6aab1bccf0aa725eee15c95aa4ffa8f0df: Bug 1591212 - make webchannel work with fission, r=vladikoff,mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Sat, 02 Nov 2019 00:39:35 +0000 - rev 500247
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1591212 - make webchannel work with fission, r=vladikoff,mconley Differential Revision: https://phabricator.services.mozilla.com/D51214
2012ad5d5af45bc7e7fec2a24b1e2472c7536d8d: Bug 1576915 Port of Picture in Picture to JSWindowActors r=mconley
Teja Bayya <bayyatej.dev@gmail.com> - Fri, 01 Nov 2019 14:15:22 +0000 - rev 500167
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1576915 Port of Picture in Picture to JSWindowActors r=mconley Differential Revision: https://phabricator.services.mozilla.com/D49797
59d974115d8e6c8532354b60aacdc3228b720274: Bug 1538200 - Kill the preallocated process when we're low on memory r=mconley
Gabriele Svelto <gsvelto@mozilla.com> - Thu, 31 Oct 2019 15:55:40 +0000 - rev 500065
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1538200 - Kill the preallocated process when we're low on memory r=mconley Differential Revision: https://phabricator.services.mozilla.com/D50926
af03745fab88e5b2ce83694980c811a4df17450e: Bug 1590752, remove now unneeded content.js framescript, r=mconley
Neil Deakin <neil@mozilla.com> - Thu, 31 Oct 2019 10:11:52 +0000 - rev 499954
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1590752, remove now unneeded content.js framescript, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D50585
fdd10ea7281bf12721ebce7475a6153c3f9e5a5a: Bug 1590752, convert ContentMetaHandler.jsm into JSWindowActors, r=mconley
Neil Deakin <neil@mozilla.com> - Thu, 31 Oct 2019 10:11:40 +0000 - rev 499953
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1590752, convert ContentMetaHandler.jsm into JSWindowActors, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D50584
6554ed35eaabf3027cd081847647dbf714180e92: Bug 1585732 - cache fission.rebuild_frameloaders_on_remoteness_change pref instead of refetching it, r=mconley
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 29 Oct 2019 23:33:54 +0000 - rev 499713
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1585732 - cache fission.rebuild_frameloaders_on_remoteness_change pref instead of refetching it, r=mconley Differential Revision: https://phabricator.services.mozilla.com/D50956
075c5b4d582737f6879f9262f774df62b087a6ae: Bug 1586393, part 2 - Fix BrowserTestUtils.addContentEventListener() with Fission. r=mconley
Andrew McCreight <continuation@gmail.com> - Tue, 29 Oct 2019 21:29:02 +0000 - rev 499695
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1586393, part 2 - Fix BrowserTestUtils.addContentEventListener() with Fission. r=mconley The current implementation of addContentEventListener() is centered around the message manager. When any message manager goes away, it cleans up everything, which does not work when Fission is enabled and we do a cross-process navigation. My new implementation instead uses window actors. Message manager shared state is used to store the set of expected event listeners. New windows, after the function is called for the first time in a test, will get listeners added properly. Of windows that exist at the first time the function is called in a test, only windows associated with the BC of the browser that is passed in will get added, which is a disadvantage relative to the current setup. That could probably be fixed. We auto remove at the end of the test, not when any message manager is torn down, so there's never a need to disable auto removal. Differential Revision: https://phabricator.services.mozilla.com/D48777
9ab73cab0869b31335e024b0a905bde6ed4682a8: Bug 1586393, part 1 - Add test-complete observer notification. r=mconley
Andrew McCreight <continuation@gmail.com> - Tue, 29 Oct 2019 21:25:02 +0000 - rev 499694
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1586393, part 1 - Add test-complete observer notification. r=mconley This allows generic code, like a testing JSM, to do clean up when a test completes, in a way that will work in different test suites. Differential Revision: https://phabricator.services.mozilla.com/D50648