ceeb77f79442a9710da29162281e3403955a9a22: Bug 1591386 - Mark one other test262 test of DateTimeFormat functionality as nightly-only, til we enable the relatedYear field in beta/release. r=jorendorff
Jeff Walden <jwalden@mit.edu> - Sat, 02 Nov 2019 22:50:51 +0000 - rev 500284
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1591386 - Mark one other test262 test of DateTimeFormat functionality as nightly-only, til we enable the relatedYear field in beta/release. r=jorendorff Differential Revision: https://phabricator.services.mozilla.com/D51493
ff9cd9a275796006bc19d706b77b7319fd335d0c: Bug 1592389 - Rename Mozfield / Mozfieldtext to Field and Fieldtext r=emilio
Sam Mauldin <sam@mauldin.me> - Sat, 02 Nov 2019 21:28:49 +0000 - rev 500283
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1592389 - Rename Mozfield / Mozfieldtext to Field and Fieldtext r=emilio Split off of Bug 1590894 Rename these to support unprefixed version Also add alias to keep compatibility Differential Revision: https://phabricator.services.mozilla.com/D50989
d3d3f36ec041a16ad1037362edbaae5213dd5f37: Bug 1593424 - Check content blocking log entry count in browser_socialtracking.js test. r=Ehsan
Nihanth Subramanya <nhnt11@gmail.com> - Sat, 02 Nov 2019 20:40:53 +0000 - rev 500282
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1593424 - Check content blocking log entry count in browser_socialtracking.js test. r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D51497
10548d5bb1ccaf86261063de07c61dbea975f900: Backed out 5 changesets (bug 1552176) for causing multiple build bustages CLOSED TREE
Noemi Erli <nerli@mozilla.com> - Sat, 02 Nov 2019 23:20:28 +0200 - rev 500281
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Backed out 5 changesets (bug 1552176) for causing multiple build bustages CLOSED TREE Backed out changeset 203060e4af95 (bug 1552176) Backed out changeset b52f0ff800c8 (bug 1552176) Backed out changeset 9f8d159fe252 (bug 1552176) Backed out changeset 751b518e08fa (bug 1552176) Backed out changeset a11ffd474c0c (bug 1552176)
47865c3e9794bdb4840dd31f2e5374c1f2c5fd57: Bug 1526268 Part 3 - Disable APZ if AccessibleCaret is in position:fixed subtree or its position is changed. r=botond,mats
Ting-Yu Lin <tlin@mozilla.com> - Sat, 02 Nov 2019 03:05:28 +0000 - rev 500280
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1526268 Part 3 - Disable APZ if AccessibleCaret is in position:fixed subtree or its position is changed. r=botond,mats In common cases where the caret is in a position:static frame subtree, the caret's position (relative to canvas frame's custom content container) should not be changed during scrolling. However, when the caret is in a position:fixed or "stuck" position:sticky frame subtree, the caret's position will change during scrolling. We need to disable APZ to avoid jumpy carets. Differential Revision: https://phabricator.services.mozilla.com/D51351
bad5d7c12e6b7a6a2cb451d88545e4eefe9ad6d5: Bug 1526268 Part 2 - Fix the logic to detect whether AccessibleCaret's position is changed. r=mats
Ting-Yu Lin <tlin@mozilla.com> - Fri, 01 Nov 2019 22:19:18 +0000 - rev 500279
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1526268 Part 2 - Fix the logic to detect whether AccessibleCaret's position is changed. r=mats This is the main patch to fix bug 1526268. It is wrong to use the cached rects relative to the root frame (ViewportFrame) to detect whether AccessibleCaret's position is changed or not, because it doesn't account the root scroll frame's scroll offset. The effect is that we always produce "PositionChangedResult::Changed" when scrolling on position:static elements, but "PositionChangedResult::NotChanged" on position:fixed elements. This patch fixes this by using the rect relative to custom content container, which is the actually rect to set caret's position, to check whether the position is changed or not. Note that even with this patch, the caret on "position:fixed" element is still jumpy during scrolling due to APZ. Part 3 will fixed this. Differential Revision: https://phabricator.services.mozilla.com/D51350
4440195bda021a88e204a18040e37fd04cedc5ee: Bug 1526268 Part 1 - Make AccessibleCaret's #text-overlay and #image children be normal in-flow elements. r=mats
Ting-Yu Lin <tlin@mozilla.com> - Fri, 01 Nov 2019 22:16:08 +0000 - rev 500278
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1526268 Part 1 - Make AccessibleCaret's #text-overlay and #image children be normal in-flow elements. r=mats The #text-overlay and #image child divs were "position: absolute" under the main AccessibleCaret div. However, they don't necessary need to be position:absolute to achieve the desired layout. We can make them normal in-flow elements to simplify the frame structure. There should not be any perceivable change to the user. Also, AccessibleCaret's position can made more accurate by using float CSS pixels when converting it from app unit. Differential Revision: https://phabricator.services.mozilla.com/D51349
203060e4af956a2b60c191e84387979dbd94e6a8: Bug 1552176 - pass TRRMode into nsHTMLDNSPrefetch methods r=dragana
Valentin Gosu <valentin.gosu@gmail.com> - Sat, 02 Nov 2019 20:43:30 +0000 - rev 500277
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1552176 - pass TRRMode into nsHTMLDNSPrefetch methods r=dragana Differential Revision: https://phabricator.services.mozilla.com/D49159
b52f0ff800c8550850fd175c654b5e1818a96d23: Bug 1552176 - Pass TRRMode to nsDNSPrefetch r=dragana
Valentin Gosu <valentin.gosu@gmail.com> - Sat, 02 Nov 2019 20:43:12 +0000 - rev 500276
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1552176 - Pass TRRMode to nsDNSPrefetch r=dragana Differential Revision: https://phabricator.services.mozilla.com/D49158
9f8d159fe252b135d79181c9f0cee3ccfa0e35ca: Bug 1552176 - Captive portal domain should not be automatically excluded from TRR r=mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Sat, 02 Nov 2019 20:43:00 +0000 - rev 500275
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1552176 - Captive portal domain should not be automatically excluded from TRR r=mayhemer Previously we had no way from excluding just one channel from TRR mode3. The solution was to add the captive portal domain to the exclusion list. Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so the exclusion is not necessary anymore. Differential Revision: https://phabricator.services.mozilla.com/D48820
751b518e08faf652b48b4dd9622039896f5942af: Bug 1552176 - Add nsIRequest.set/getTRRMode r=dragana
Valentin Gosu <valentin.gosu@gmail.com> - Sat, 02 Nov 2019 20:42:42 +0000 - rev 500274
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1552176 - Add nsIRequest.set/getTRRMode r=dragana * Makes it possible to selectively enable TRR for pbmode/container/window/etc Differential Revision: https://phabricator.services.mozilla.com/D48363
a11ffd474c0cf99da9ab80fb6fa34def53d14b2c: Bug 1552176 - Unit test for TRRMode for individual channels r=dragana
Valentin Gosu <valentin.gosu@gmail.com> - Sat, 02 Nov 2019 20:42:25 +0000 - rev 500273
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1552176 - Unit test for TRRMode for individual channels r=dragana Differential Revision: https://phabricator.services.mozilla.com/D48362
fb90d8c061801c397ac01cb9e04cba4e83c3186a: Bug 1592419 - Reject duplicate toolchain aliases. r=tomprince
Justin Wood <Callek@gmail.com> - Wed, 30 Oct 2019 18:11:11 +0000 - rev 500272
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1592419 - Reject duplicate toolchain aliases. r=tomprince With this patch applied but Bug 1592402 not fixed, I got: ``` Traceback (most recent call last): File "/home/callek/mozilla/hg/mozilla-central/taskcluster/mach_commands.py", line 379, in show_taskgraph tg = getattr(tgg, graph_attr) File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/generator.py", line 151, in full_task_graph return self._run_until('full_task_graph') File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/generator.py", line 351, in _run_until k, v = self._run.next() File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/generator.py", line 287, in _run yield verifications('full_task_graph', full_task_graph, graph_config) File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/util/verify.py", line 36, in __call__ graph.for_each_task(verification, scratch_pad=scratch_pad, graph_config=graph_config) File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/taskgraph.py", line 31, in for_each_task f(task, self, *args, **kwargs) File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/util/verify.py", line 240, in verify_task_graph_symbol key, Exception: Duplicate toolchain-alias in tasks `toolchain-linux64-clang-9`and `toolchain-linux64-clang-9-cross`: linux64-clang ``` Differential Revision: https://phabricator.services.mozilla.com/D51101
b4197fcbd41190d40e4eec3ab4c2e270d80c7424: Backed out 5 changesets (bug 1545123) for causing nsPluginTags.cpp build bustages CLOSED TREE
Ciure Andrei <aciure@mozilla.com> - Sat, 02 Nov 2019 14:00:38 +0200 - rev 500271
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Backed out 5 changesets (bug 1545123) for causing nsPluginTags.cpp build bustages CLOSED TREE Backed out changeset 91313cceae8c (bug 1545123) Backed out changeset d91549e68229 (bug 1545123) Backed out changeset 269d89e09fbb (bug 1545123) Backed out changeset a139ee115519 (bug 1545123) Backed out changeset eb454f238f45 (bug 1545123)
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 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +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
d91549e68229531659bf744f34feca3bc02f5ea5: Bug 1545123 - move plugin finding into its own class to clarify dependencies and data flows, r=handyman
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 29 Oct 2019 05:30:30 +0000 - rev 500269
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1545123 - move plugin finding into its own class to clarify dependencies and data flows, r=handyman This moves plugin finding logic into a separate class (PluginFinder). PluginFinder is a runnable. After this commit, there are two ways in which it can be used: 1. to actually find and load plugins. 2. to check if there have been any changes to plugins. Although it is a runnable, at this point we still invoke its Run method on the main thread, so all that's happening is we're separating the "look for plugins on disk" bits out from everything else. The goal is to be able to run the IO-intensive FindPlugins (including reading and writing pluginreg) away from the main thread. Depends on D48330 Differential Revision: https://phabricator.services.mozilla.com/D48331
269d89e09fbb3c12d5e015845f897b67ab0e2419: Bug 1545123 - remove obsolete things from nsPluginHost, r=handyman
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 29 Oct 2019 05:30:30 +0000 - rev 500268
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1545123 - remove obsolete things from nsPluginHost, r=handyman Remove: - a list of allowed mimetypes; we only support flash anyway. - writing to disk when a plugin's enabled state changes; the plugin's enabled state is not kept on disk so there's no point. - tracking which plugins should load in the parent as no plugins should do so if e10s is on. Depends on D48329 Differential Revision: https://phabricator.services.mozilla.com/D48330
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 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +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
eb454f238f45f46da4f762f41bd511fd2d77e499: Bug 1545123 - store flash information in prefs instead of pluginreg, r=handyman
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 29 Oct 2019 05:30:29 +0000 - rev 500266
Push 36759 by cbrindusan@mozilla.com at Sun, 03 Nov 2019 09:46:18 +0000
Bug 1545123 - store flash information in prefs instead of pluginreg, r=handyman By storing the plugin information in prefs when only flash is allowed, we can avoid reading pluginreg and doing a plugin scan on the mainthread on startup. As part of this, we're now keeping track of the 'is flash allowed' pref on the plugin host, and no longer write 'valid' plugin info into pluginreg if so. Also note that in this commit, we're changing `mPluginRegFile` to actually refer to the file, rather than the containing directory. Differential Revision: https://phabricator.services.mozilla.com/D48328
16aac90f6572f363d2b5c8205e13115ac818869d: Bug 1584479 - Part 4: Update TrackingDBService test. r=ewright
Nihanth Subramanya <nhnt11@gmail.com> - Fri, 01 Nov 2019 23:24:27 +0000 - rev 500265
Push 36758 by aiakab@mozilla.com at Sat, 02 Nov 2019 21:51:29 +0000
Bug 1584479 - Part 4: Update TrackingDBService test. r=ewright Differential Revision: https://phabricator.services.mozilla.com/D51409
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip