ActivateItemAfterClosing is currently only called during automated tests.
Before this patch, the DoCommandRunnable could be run from two different places:
Either from the regular event loop (dispatched in `-[MOZMenuOpeningCoordinator _runMenu]`
once the menu event loop is exited), or from MenuClosedAsync, whichever happens first.
MenuClosedAsync always runs when the menu closes, so we can rely on
it being called after ActivateItemAfterClosing.
So we can simplify the code by just always firing the command event
from MenuClosedAsync.
Differential Revision: https://phabricator.services.mozilla.com/D149315
This doesn't seem to serve any purpose anymore. MOZ_RELEASE_ASSERTing
if mBuildingRect is read during ::Paint doesn't show it happening
anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D150066
That, when the target is destroyed for any reason other than the process destruction or
when we stop watching for content process targets.
In these two cases, we will notify about the target destruction.
AFAIK, this is actually the only two reasons when a content process target is destroyed.
But it would be safer to assume that the target might be destroyed for some other reason
and have the client to be notified.
Depends on D148529
Differential Revision: https://phabricator.services.mozilla.com/D148137
Now that we always sync decode during reftests we don't switch from non-sync to
sync decoding and expect proper invalidations. For now, we just make sure that
nsImageGeometryMixin never causes invalidations. We'll rip out the code in a
follow up.
Differential Revision: https://phabricator.services.mozilla.com/D150114
This shouldn't be perf-sensitive, but on 64-bit platforms it's more natural to copy
eight bytes at a time.
Depends on D149964
Differential Revision: https://phabricator.services.mozilla.com/D149965
The exception trampoline now uses a `Label` + `jump` to jump to the bailout tail
code, after setting the stack pointer to the `JitFrameLayout` of the bailing frame.
In the bailout tail code, we can now assert the stack pointer is what we expect
instead of clobbering it ourselves.
Depends on D149963
Differential Revision: https://phabricator.services.mozilla.com/D149964
The `argv` method on `BaselineFrame` does not include `this`, but the one on `JitFrameLayout` does.
We can be a bit more explicit about this.
Depends on D149962
Differential Revision: https://phabricator.services.mozilla.com/D149963
* Some methods can forward to the implementation in `JitFrameLayout`.
* Replace `offsetOfFoo` methods with the ones from `JitFrameLayout` now that `FramePointerOffset` is gone.
The next patch will tidy up `JitFrameLayout::argv`.
Differential Revision: https://phabricator.services.mozilla.com/D149962
`PageProtectingVector` has been unused since bug 1342023.
`MemoryProtectionExceptionHandler` was only used to annotate crashes affecting
`LifoAlloc` memory.
Differential Revision: https://phabricator.services.mozilla.com/D149993
We were previously looking for a doc (IsDoc), but we'll never get any doc in a viewport cache except for the doc whose viewport we are searching.
Instead, if we encounter an iframe, we'll hit an OuterDoc (IsOuterDoc) which is the Accessible for the iframe element.
In that case, we walk *inside* that OuterDoc to get its embedded document, then recurse from there if appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D149247
Sometimes, the document occurs too early in the viewport cache, perhaps even right at the start.
We weren't benefitting from it being in the cache anyway, since we always skipped it.
We already have a fallback in ChildAtPoint for the case where we didn't find a matching Accessible, so we rely on that to handle returning the document when appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D149493
This was moved to a post refresh observer on the misunderstanding that this would allow us to benefit from retained display lists.
In reality, it doesn't; work would need to be done in layout to benefit from those, and since there are different display lists for hit testing and painting, this may not be feasible anyway.
Furthermore, the post refresh implementation was broken because WillRefresh often removes the post refresh observer, which meant that a viewport cache update was never actually pushed!
We could fix this by adding the post refresh observer only if the viewport cache is dirty, removing the post refresh observer in DidRefresh and also removing the post refresh observer in Shutdown only if the viewport cache is dirty.
However, given that we can't benefit from retained display lists anyway, using a post refresh observer doesn't serve any purpose at this stage.
Among other things, this fixes intermittent problems with image maps, which often get inserted into the tree after the initial tree is built.
Differential Revision: https://phabricator.services.mozilla.com/D149492
On multi-GPU systems, even though the GPU we're going to use for
accelerated video decoding is driven by Mesa, sometimes the nvidia
proprietary driver can be loaded and attempt to probe devices. This
patch attempts to make the sandbox policy quietly return errors for
those syscalls, instead of treating them as unexpected (and crashing on
Nightly).
Differential Revision: https://phabricator.services.mozilla.com/D149652
* Set root element font-size to 15px to align with the size we set on body (in common-shared.css), allowing predictability when scaling and zoom-friendly (rem) widths
* Remove the <main> grid column-gap and manage padding/gutter around/between content areas with the --content-area-gutter variable
* Use a consistent 32px between content areas
* Simplify <main> grid to 2 columns with 2/3, 1/3 width respectively.
* Add a max-width to the page content to correspond to 1440px and horizontally center it in larger viewports
* Move the colorways content inside right-most column (grid slot) rather than *be* the column.
Differential Revision: https://phabricator.services.mozilla.com/D149457
This ensures they're clamped on Animated -> sRGB conversion, and in the
future we'll have to implement different color spaces so we'll need to
use it anyways.
Differential Revision: https://phabricator.services.mozilla.com/D149792
Also includes the Fn key, which isn't documented to map to a special virtual key code but maps to 0xff, an undefined code, on tested machines.
Differential Revision: https://phabricator.services.mozilla.com/D149928
This removes HTMLMenuItemElement and all the code and tests preffed off
by dom.menuitem.enabled.
The HTML parser changes are the result of applying the previous patch.
Differential Revision: https://phabricator.services.mozilla.com/D149979
It's not clear why they were removed in the first place, but it breaks
the build for some people and newer protobuf/protoc releases add them
back anyway.
Differential Revision: https://phabricator.services.mozilla.com/D150007
Ideally we'd use GDK_TOUCHPAD_SWIPE/GdkEventTouchpadSwipe (GTK's native events)
for this for the best compatibility with the the platform/other apps.
Unfortunately that seems complicated, so for now we use our SwipeTracker code
and make our own determination of what counts as a swipe.
Note that the pref widget.swipe.whole-page-pixel-size can be used to tweak
the swipe sensitivity.
Differential Revision: https://phabricator.services.mozilla.com/D149512
I didn't aware there is any spec that ensure the order of load event and initial
focus event. It could be possible that the initial focus event comes after load
event and cause test failures. But I didn't figure out a way to detect whether
we should wait for the initial focus event, so just delay logging for focus
event a bit to ignore the initial one.
Differential Revision: https://phabricator.services.mozilla.com/D150002
`sTiming` is a hack and I believe animation-delay,
animation-iteration-count, animation-direction, and animation-fill-mode
should be meaningful for scroll-linked animations. (I will add the
tentative wpt in Bug 1775327.)
So we need to introduce a normalized timing when resolving the specified
timing.
Also, this patch makes the bug of printing scroll animations detectable.
No behavior is changed and I'd like to remove the magic values and do
normalization in Bug 1775327.
Note: Based on https://github.com/w3c/csswg-drafts/issues/4862 and
web-animations-2, we will introudce CSSNumberish for duration, current
time, and delay. That is, we will accept percentage for
animation-duration, animation-delay. However, Gecko doesn't support
CSSNumberish for those values, so we'd like to normalize these time values
in Bug 1775327. This patch is the 1st step: split the normalized
timing from the specified timing, and use it when resolving the
timing, for progress-based timeline.
Differential Revision: https://phabricator.services.mozilla.com/D149683
Markus Stange
Jeff Muizelaar
smolnar
Sarah Clements
Eemeli Aro
Alexandre Poirot
ffxbld
Joel Maher
Tomislav Jovanovic
Bogdan Szekely
Jari Jalkanen
Julien Wajsberg
Emilio Cobos Álvarez
Andi-Bogdan Postelnicu
kernp25
Nicolas Chevobbe
Jan de Mooij
Mozilla Releng Treescript
James Teh
Norisz Fay
Bas Schouten
Kagami Sascha Rosylight
Masayuki Nakano
Jed Davis
Sam Foster
Danny Colin
Andrew Osmond
David Parks
Ryan VanderMeulen
Jonathan Watt
Edgar Chen
Boris Chiou
Michael Ratcliffe