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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
rename : dom/plugins/base/nsPluginHost.cpp => dom/plugins/base/PluginFinder.cpp
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This patch uses the low memory resource notification facility to detect
scenarios where physical memory is running low without polling. This is a
significant change compared to the previous behavior which measured both
available virtual memory (only on 32-bit builds) and available commit space.
Since we're not trying to avoid OOMs anymore we don't save memory reports
anymore when hitting a low-memory condition.
Differential Revision: https://phabricator.services.mozilla.com/D50471
--HG--
extra : moz-landing-system : lando
Otherwise, a main-thread update can interrupt a touch drag near its very
start, when we're still in the TOUCHING state while we're overcoming the
touch start tolerance threshold.
Depends on D51447
Differential Revision: https://phabricator.services.mozilla.com/D51448
--HG--
extra : moz-landing-system : lando
When the `Debugger` API sets a breakpoint in a JSScript or wasm::Instance, the
BreakpointSite and Breakpoint objects belong to the code's compartment
(logically, at least - they're C++ objects and don't actually have any
compartment). Since a `Debugger` and its debuggees must be in separate
compartments, the Breakpoint's references to its owning `Debugger` and its
handler object must go through cross-compartment wrappers.
If we have nuked the `Debugger`'s compartment, it's not clear how we're still
trying to set breakpoints in its debuggees, but we should at least throw an
error, to capture a JavaScript stack when it occurs.
Differential Revision: https://phabricator.services.mozilla.com/D51210
--HG--
extra : moz-landing-system : lando
This revision refactors RDM's touch simulator to use modern touch web APIs where possible.
Differential Revision: https://phabricator.services.mozilla.com/D50147
--HG--
extra : moz-landing-system : lando
Gijs Kruitbosch
Jeff Walden
Sam Mauldin
Nihanth Subramanya
Noemi Erli
Ting-Yu Lin
Valentin Gosu
Justin Wood
Ciure Andrei
Gabriele Svelto
Sylvestre Ledru
Andrea Marchesini
Andreea Pavel
Botond Ballo
Jim Blandy
Micah Tigley
Edgar Chen
Tom Prince
Dorel Luca
Brian Hackett
Rohit Awate