Quota file stream wrappers will bind an actor to the thread where
the stream deserialization is done (the actor is needed for proxying quota
checks to the parent process), so we can't deserialize the stream on the worker
thread anymore because the stream is used off the worker thread (on the IO task
queue).
Differential Revision: https://phabricator.services.mozilla.com/D163944
This is a preparation for lazy deserialization of the stream on the IO task
queue. After that, we won't be able to touch mStream directly on the worker
thread.
Differential Revision: https://phabricator.services.mozilla.com/D163943
Instead of doing IO directly on the worker thread, these methods now instead
dispatch a task on the IO task queue and block the worker by spinning a nested
event loop (worker control runnables can be processed).
Differential Revision: https://phabricator.services.mozilla.com/D163941
This patch adds all remaining infrastructure for handling async close calls
without actually closing the stream on the IO task queue.
Differential Revision: https://phabricator.services.mozilla.com/D163842
Async Close will have to close the stream on the IO task queue which introduces
a new state of the object which can't be controlled by a bool member.
Differential Revision: https://phabricator.services.mozilla.com/D163565
The Close method will return a MozPromise. Calling such method if the object is
already closed would uselessly allocate a MozPromise and dispatch a runnable
for the MozPromise resolving. So it's better to call Close only if the object
is not yet closed.
Differential Revision: https://phabricator.services.mozilla.com/D163564
This is a preparation for an async closing of FileSystemSyncAccessHandles which
requires finising of the operation on a live worker thread (after closing the
stream on the IO task queue, we need to send an IPC message to the parent
process).
Differential Revision: https://phabricator.services.mozilla.com/D163563
This helps out when clipping to rects with canvas2d. It reduces GPU
usage on the React-Stockcharts benchmark from ~70% down to ~45% on
a desktop gen9 Intel GPU.
It would be better to handle this in the D2D backend like we do in other
backends, but there's not an easy way to detect rectangle paths there.
This was the easiest place to slot it in and shouldn't have too high a
cost for the other places we use the recording backend.
Differential Revision: https://phabricator.services.mozilla.com/D164764
This stops selecting buttons on mousedown so that selection and the input remain
in a sensible state after clicking the block button while top sites are showing
(e.g., in the weather suggestion).
This turned out to be surprisingly complicated, so please see the bug and code
comments for details. I think our selection logic is pretty brittle or at least
convoluted and could stand to be simplified, but I didn't want to make large
changes here. Ideally we wouldn't treat buttons any differently on mousedown --
so we'd select them too -- and it may be possible to do that while avoiding the
problems I talk about in the bug, but I don't think it's at all worth the
complexity that seems to be required.
I added a new task to the test Daisuke created in D155812.
Differential Revision: https://phabricator.services.mozilla.com/D164018
We always use the document timeline of the cloned document, and clone the
paused animation with the preserved progress, even if the original
timeline is null.
Differential Revision: https://phabricator.services.mozilla.com/D164712
Bug 1798242 did not cause a regression. Then it seems OK to try to enable video overlay without ZeroCopyNV12Texture with non-intel GPUs to release.
Differential Revision: https://phabricator.services.mozilla.com/D164634
See the code comments for an explanation.
This fixes assertions and crashes when pushing the cache when a page contains a map which is unslotted in a shadow host.
Differential Revision: https://phabricator.services.mozilla.com/D164783
Calling GetAccessibleOrContainer meant that if a particular content node didn't have an Accessible but did have a frame, we'd insert its container in its place.
There might have been other descendants of that container that did have Accessibles, though.
In that case, we would have put the container ahead of some of its descendants!
To fix this, use GetAccessible instead.
We'll still fall back to the container if the user hit tests a point in an inaccessible node, since it will appear later in the viewport cache.
Differential Revision: https://phabricator.services.mozilla.com/D164803
That patch was always somewhat hacky, but we couldn't figure out the cause of the problem.
Now that I've figured it out, a more correct solution is forthcoming.
Differential Revision: https://phabricator.services.mozilla.com/D164802
Because the parent process lacks information about the current shell
size, the child has to send both the current and the new shell size to
the parent. The parent then applies the delta to the window size. This
can produce different results for calls with the same arguments,
whenever a previous call did not have enough time to update the child
with its new size.
The implementation is replaced by applying the delta in the child.
Differential Revision: https://phabricator.services.mozilla.com/D160261
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
The getter used to return CSS pixels, while the setter expected layout
device pixels. The nsIDocShellTreeOwner documentation used to suggest that
CSS pixels are used for getters and setters of the primary content and
the root shell size. Only the getter for the primary content size
happend to match that documentation.
Differential Revision: https://phabricator.services.mozilla.com/D161944
Two minor changes that otherwise might go unnoticed in the following
parts:
- AppWindow can't skip SetSize calls that match the current size. On
Linux a previous call might not have changed the size yet. If the
current call is skipped, the previous call can ultimately dictate the
resulting size.
- BrowserParent should not have to call UpdatePosition when receiving
new dimensions from BrowserChild. But HeadlessWidget needs to call
NotifyWindowMoved when moved.
Differential Revision: https://phabricator.services.mozilla.com/D160259
ReflowChildren() needs more bookkeeping data to correctly place tall flex items
being pushed from prev-in-flows during fragmentation. This is a preparation for
bug 1743890 that is going to add more fields to the struct.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D164399
When I first implemented flexbox fragmentation, all the children in flex
container's next-in-flows are all put in one FlexLine, because we assume the
position of flex items won't shift in fragmentation. However, when we implement
more granular control of flexbox fragmentation such as pushing a tall flex item
to next page/column, we'll need the information of flex lines.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D164398
- Remove the return value since it is never used.
- Store the newly create flex item in a reference since EmplaceBack() returns
NonNull<FlexItem*>.
Differential Revision: https://phabricator.services.mozilla.com/D164396
This adds checks to the main sponsored and nonsponsored tests to ensure we have
test cases where this value is both true and false. I think it's important to
have test cases for both sponsored and nonsponsored suggestions since these are
the two main types of Firefox Suggest suggestions. I don't think it's necessary
for other types of suggestions because they all use the same logic, so if these
checks pass for sponsored and nonsponsored suggestions, we can be reasonably
sure other suggestion types are handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D164617
Unfortunately, this can be called through both reflow and frame construction
much like nsCSSFrameConstructor::ContentAppended, so we can't just use a page-
name tracker.
Differential Revision: https://phabricator.services.mozilla.com/D164760
