Wait for the messages to be displayed, and requestLongerTimeout,
as test failures logs seem to indicate that slower machine take
more than 30s to run the test.
Differential Revision: https://phabricator.services.mozilla.com/D51562
--HG--
extra : moz-landing-system : lando
I don't have a test case for this crash, but the stack suggests the frame is null.
This can certainly happen for display: contents.
Differential Revision: https://phabricator.services.mozilla.com/D51560
--HG--
extra : moz-landing-system : lando
This makes it possible for the menus to not be constrained
to the panel boundaries if they are taller than the panel
itself (which could be the case for the simulate menu as
it has lots of items).
We need to style the button with a link role in the toolbox
CSS so they don't look like real buttons.
Differential Revision: https://phabricator.services.mozilla.com/D50461
--HG--
extra : moz-landing-system : lando
(1) Reduce size of content tiles from 2048 x 512 to 1024 x 512.
This reduces the large extra overhead of tiles on screens that
are not 4k resolution.
(2) Remove small 128 x 128 tiles.
These typically create a lot of OS compositor surfaces, which
adds significant overhead on some platforms. Having them be
normal content tiles also means no resizing of the picture
cache for the UI when the awesome bar and/or status bar is on.
(3) Add support for very narrow cache surfaces.
This is a special use case for scrollbar caches. It's worth
supporting this special case for the significant memory and
performance savings for these surfaces.
Differential Revision: https://phabricator.services.mozilla.com/D51541
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
Add an observer to restart the PVideoBridge connection when GPU process
restarts.
Differential Revision: https://phabricator.services.mozilla.com/D50403
--HG--
extra : moz-landing-system : lando
Combine sVideoBridgeToParentProcess and sVideoBridgeToGPUProcess into one
sVideoBridge. Each producing process, GPU or RDD, is only ever started with one
VideoBridgeChild endpoint. This is enough to get RemoteVideoDecoders in RDD
process to start using GPU memory to send video to compositor over PVideoBridge.
Differential Revision: https://phabricator.services.mozilla.com/D50402
--HG--
extra : moz-landing-system : lando
LaunchRDDProcess() and CreateContentBridge() create a sync creation. Merge the
functions into one function. Keep the IPDL messaging async to avoid adding a
exception for the message being sync.
Differential Revision: https://phabricator.services.mozilla.com/D50400
--HG--
extra : moz-landing-system : lando
1. Send OnStatus and OnProgress IPC events over main thread.
2. Merge HttpChannelChild::OnProgress and HttpChannelChild::DoOnProgress into one function, since these two basically do the same thing.
Differential Revision: https://phabricator.services.mozilla.com/D51407
--HG--
extra : moz-landing-system : lando
This implements an all-or-nothing insecure sweeping override that
bypasses security exceptions when loading documents with invalid
or otherwise bad TLS certificates.
Differential Revision: https://phabricator.services.mozilla.com/D50838
--HG--
extra : moz-landing-system : lando
So that fonts chosen by the author inherit into the menuitems
properly, instead of being overriden.
Differential Revision: https://phabricator.services.mozilla.com/D51086
--HG--
extra : moz-landing-system : lando
For allowing `TextEditor` to dispatch DOM events synchronously, we should
remove `AutoScriptBlocker` in `TextControlState::SetValue()` right now.
According to the comment around the `AutoScriptBlocker`, `PrepareEditor()`
may be called while setting value. Therefore, this patch makes
`AutoTextControlHandlingState` call it if `PrepareEditor()` is called
while handling `SetValue()` and when the top most `SetValue()` ends its job.
Depends on D51396
Differential Revision: https://phabricator.services.mozilla.com/D51397
--HG--
extra : moz-landing-system : lando
Currently, "input" event is fired when the `AutoScriptBlocker` in `SetValue()`
is deleted. So, for keeping same behavior, the post processing after calling
`TextEditor` methods should be done before editor dispatches "input" event.
Fortunately, `TextInputListener::OnEditActionHandled()` is a good chance to
do that. Therefore, this patch makes it notify `TextControlState` and
`AutoTextControlHandlingState`.
Note that ideally, each method of `TextEditor` should return
`NS_ERROR_OUT_OF_MEMORY` coming from
`AutoTextControlHandlingState::OnEditActionHandled()`. However, it requires
a lot of changes in editor classes, and the case is really rare since editor
does not use fallible allocation. Therefore, it must be okay to crash in
editor if `OnEditActionHandled()` returns `NS_ERROR_OUT_OF_MEMORY`.
Depends on D51395
Differential Revision: https://phabricator.services.mozilla.com/D51396
--HG--
extra : moz-landing-system : lando
`TextControlState::SetValue()` does 4 things.
1. Committing composition if there is and if possible.
2. Setting value with `TextEditor` if text editor and frame are available.
3. Setting value without `TextEditor` otherwise.
4. Notifying value changed.
We can split #2 and #3 from it now because `AutoTextControlHandlingState`
manages nested actions. Therefore, this patch creates
`SetValueWithTextEditor()` and `SetValueWithoutTextEditor()` which take
`AutoTextControlHandlingState`.
Depends on D51394
Differential Revision: https://phabricator.services.mozilla.com/D51395
--HG--
extra : moz-landing-system : lando
Currently, only `HTMLInputElement` reuses `TextControlState` instance since
`HTMLTextAreaElement` had the instance as a member rather than allocate it.
Now, all instances are allocated in the heap independently for guaranteeing
their lifetime. So, the reuse mechanism should be managed by
`TextControlState` itself.
Depends on D51393
Differential Revision: https://phabricator.services.mozilla.com/D51394
--HG--
extra : moz-landing-system : lando
Currently, nobody guarantees that `TextControlState` won't be deleted while
it handles something with `MOZ_CAN_RUN_SCRIPT` methods.
This patch hides its destructor (and constructor) for making only
`TextControlState` itself can delete its instances. Then, if instance owner
wants to delete it while handling action(s), the oldest `AutoHandlingState`
will delete the `TextControlState`.
Depends on D51392
Differential Revision: https://phabricator.services.mozilla.com/D51393
--HG--
extra : moz-landing-system : lando
Some members of `TextControlState` are initialized and restored in same block
scopes. Therefore, with creating new stack only class and storing latest one
with a new member variable, we can store all of them in the stack.
Depends on D51391
Differential Revision: https://phabricator.services.mozilla.com/D51392
--HG--
extra : moz-landing-system : lando
It should be in `mozilla` namespace and it manages not only `TextEditor`,
manages selection, selection controller and callback from editor. so that
I think it stores state of "text control widget". Therefore, I name it to
`TextControlState`.
And cleaning up the cpp file.
Differential Revision: https://phabricator.services.mozilla.com/D51391
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextControlState.cpp
rename : dom/html/nsTextEditorState.h => dom/html/TextControlState.h
extra : moz-landing-system : lando
Previously, WR needed to update and track dependencies for all
allocated picture cache tiles in the virtual display port. This
means doing extra CPU work (dependency updates) and in some cases,
extra GPU work (larger off-screen child surfaces) than are strictly
required.
With this patch, each tile determines if it is currently visible in
pre_update. If the tile isn't visible, we skip doing dependency
updates until it is on screen again. More importantly, this is
used to reduce the world culling rect for primitive preparation,
which also means large child surfaces only require allocations
large enough to enclose the visible tiles, rather than the
display port.
Differential Revision: https://phabricator.services.mozilla.com/D51006
--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
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
Itiel
Nicolas Chevobbe
Oana Pop Rus
James Teh
Glenn Watson
jaril
Andreea Pavel
Dan Glastonbury
Jeff Muizelaar
Kershaw Chang
sotaro
Matt Woodrow
Razvan Maries
Brian Hackett
Andreas Tolfsen
Emilio Cobos Alvarez
Masayuki Nakano
shindli
Johann Hofmann
Noemi Erli
Coroiu Cristina
Gijs Kruitbosch
Jeff Walden
Sam Mauldin
Nihanth Subramanya
Ting-Yu Lin