Currently, if an event is consumed in the main process, EventStateManager
does not send it to remote process. However, this is unexpected behavior
for some WidgetKeyboardEvent dispatchers. OS sometimes has consumed native
key events before sending applications. For example, Alt key on Windows
should activate menu bar of focused window but Alt key may be consumed before
focused window receives the event. In such case, we mark Alt keyboard event
as "consumed before dispatch", and chrome treat it like as its preventDefault()
is called in web content. (Note that for compatibility with other browsers,
the consumed state is not exposed to web content. So, Event.defaultPrevented
returns false in web content.)
Therefore, we need to treat "consumed" state and "cross process forwarding"
state separately. This patch makes calling WidgetEvent::PreventDefault()
always stops cross process forwarding for backward compatibility. Additionally,
for the special case mentioned above, this patch makes
WidgetEvent::PreventDefaultBeforeDispatch() take additional argument,
|aIfStopCrossProcessForwarding|. If this is CrossProcessForwarding::eStop,
the event won't be sent to remote process as same as calling PreventDefault().
Otherwise, CrossProcessForwarding::eHold, PreventDefaultBeforeDispatch() call
does not change "cross process forwarding" state. I.e., if the event's
StopCrossProcessForwarding() and PreventDefault() are not called until
EventStateManager::PostHandleEvent(), the event will be sent to remote process
as usual.
MozReview-Commit-ID: IQGWJvXetxV
--HG--
extra : rebase_source : 4ccdd500e80b8fe29e469ac3b85578e1c07c8358
The probe is expired and there's no clear owner here so let's remove this
for now.
--HG--
extra : rebase_source : 51c332a790ce5081ce4645633991c3b9213a5d21
extra : source : 98d141e6d651b804cf35040a5c20be74b6fb6c7a
Since the test relies on missing keyframes handling.
MozReview-Commit-ID: IfbMvRhIeOh
--HG--
extra : rebase_source : 447bec6c7bc8d8a79f00bb738182e0647ee68ec5
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
This fixes a MathML-disabled reftest with the previous patch.
The reftest assumes the sheet is not loaded, so let's just do that. This
effectively preserves behavior.
MozReview-Commit-ID: KrR4pHslycz
On top of the two depending bugs.
Funny how there's a comment referencing bug 77999.
Differential Revision: https://phabricator.services.mozilla.com/D1750
MozReview-Commit-ID: LCuJROu92bo
Continuations do not have placeholders. There's a bunch of code that already
deals with that in other places in the tree.
MozReview-Commit-ID: Htizql7692e
This fixes a MathML-disabled reftest with the previous patch.
The reftest assumes the sheet is not loaded, so let's just do that. This
effectively preserves behavior.
MozReview-Commit-ID: KrR4pHslycz
On top of the two depending bugs.
Funny how there's a comment referencing bug 77999.
Differential Revision: https://phabricator.services.mozilla.com/D1750
MozReview-Commit-ID: LCuJROu92bo
When an animation targets a CSS property that could cause a containing block to
be generated for its descendants, this containing block must be generated even
if the particular property values used by the animation would not normally
trigger generation of a containing block (e.g. transform: none). This is due
to the implicit application of will-change defined in CSS Animations[1] and Web
Animations[2].
Since this containing block is generated at the start of the animations, we can
throttle animations that produce the UpdateContainingBlock change hint for
animations that are not visible since they shouldn't have any further side
effects beyond the generation of containing blocks (which have already happened).
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Unfortunately perspective animations starting with 'none' and transform
animations from 'none' to 'none' don't create a containing block (bug 1470349
and bug 1470370). That doesn't block the optimization in this patch, however,
since those bugs occur regardless of element visibility.
MozReview-Commit-ID: 8rTl8dShHrD
--HG--
extra : rebase_source : 886b003d0f3c555a12baf0de81b4130ef2d71e82
In the case where the target element is scrolled out or visibility:hidden and
has no visible descendants, we can treat nsChangeHint_UpdateOverflow just like
transform animations which produce nsChangeHint_UpdatePostTransformOverflow,
i.e. unthrottle the animations periodically if the target element is inside a
scrollable element. Some transform animations produce UpdateOverflow hint,
so it would be really nice to optimize the hint.
MozReview-Commit-ID: E1MgPZRi8mW
--HG--
extra : rebase_source : d29a29e137742f88a64b3b18a5a7d4e64e76f54f
This was a memory-saving optimization introduced as part of dependencies for bug
686875, but a more general system landed in bug 77999 for Gecko and
https://github.com/servo/servo/pull/18509 for Servo.
So now it's probably even a bit of a pessimization (though probably not huge),
and given this causes bugs like bug 1462742, bug 1157592, and bug 1468145, and
fishiness like the one pointed out in this bug, we may as well remove it.
The performance impact of having to lookup through more rules should be minimal
given the bloom filter and the rule hash optimizations.
This makes me wonder whether we could remove the whole concept of on-demand UA
sheets, since they've caused pain, for example, when the frontend people try
loading <svg>s from NAC (since that triggers sheet loading from frame
construction, which is not good). I'm not concerned about loading mathml.css and
svg.css everywhere, though xul.css may not be as doable since it adds a bunch of
attribute-dependent selectors. Though on the other hand I asserted in the
xul.css code and we don't load it in content with <video> / <input
type="date/time/etc"> and such, afaict, so maybe now that legacy addons are gone
we can remove that sheet from content processes altogether.
MozReview-Commit-ID: 9JCWNZj6BkT
Those changesets which are related to animations introduced in bug 1462497
seems to cause new crashes. I think the first two changesets for the bug fixed
the original crash cases but the last two (i.e. these changesets) introduced
other crashes unfortunately.
MozReview-Commit-ID: 9LD2hIIXA2y
--HG--
extra : rebase_source : 102c5532128039dcf8274c214e17d58d9a1aa483
This commit just adds some #include directives and "using namespace" directives.
(The "using namespace mozilla::dom;" are the important namespace directives
here, though I've included "using namespace mozilla;" alongside it as well, for
completeness/consistency.)
Differential Revision: https://phabricator.services.mozilla.com/D1647
Just avoid crashing if the element has no data, treat is as display: none.
TakeChangeHint already returns wasRestyled = false, so we won't end up trying to
reconstruct anything, and we don't set frame construction flags in
nsCSSFrameConstructor so we won't traverse children either.
MozReview-Commit-ID: 2gXmHSlj3Jw
--HG--
extra : rebase_source : 9d95a4f3ee8fabc4d73a39699c677ba184061370
- Fix the implementation to return a numerically correct result
- Change call sites that should have instead been using
CalculateCompositedSizeInCssPixels(), to do so
- Rename and document to emphasize that the returned rect is in the
CSS pixels of the content surrounding the scroll frame
MozReview-Commit-ID: GCPbA1k88rz
--HG--
extra : rebase_source : f5b937936fb84b3ae414d6cf0250add4078a9d53
This pref was used to enable the building of nsDisplayLayerEventRegions
items without APZ, so that we could test it in isolation. However, we no
longer need to do so, and these display items are going to be deleted
anyway, so we can remove this pref.
MozReview-Commit-ID: LJVcFafCKyS
--HG--
extra : rebase_source : 76d8eeca8dca4ea88b8226bbe6b829dbc40e03e4
To avoid creating a bunch of layers when we don't need to, this
tracks when a frame needs to be repainted, and invalidates the
IsStyleAnimated logic around mRestyleCounts if the frame is also
being invalidated.
MozReview-Commit-ID: 5Q96Cx6f3V0
--HG--
extra : rebase_source : 4512ef0c6cb50a730f7d5974ef6364d54b6c49b4
This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
--HG--
rename : dom/file/nsHostObjectProtocolHandler.cpp => dom/file/BlobURLProtocolHandler.cpp
rename : dom/file/nsHostObjectProtocolHandler.h => dom/file/BlobURLProtocolHandler.h
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The next changeset is going to move over more annotations that Gecko developers
would count as "layout" into the LAYOUT category, and which is currently marked
as GRAPHICS.
We can add a subcategory for style resolution once we have subcategories, but
for now I think it makes more sense to put style resolution into the same bucket
as reflow and display list building.
MozReview-Commit-ID: 7r9eICVBA1Z
--HG--
extra : rebase_source : 53ce9912d3219ce8ce5dc411e03bb5ef5e2c7b64
The DoMouseClick helper is also removed because no other caller can now pass a null aEvent. Other MouseClicked implementations are also updated since aEvent cannot be null, which was already the case.
MozReview-Commit-ID: 3bTJ6cZW9ZA
--HG--
extra : rebase_source : ae1bafe7144f6f428e2ef4e7047d5c64e0a19e8c
It's write-only, and I'd love to use it for other purposes :)
MozReview-Commit-ID: KpXNp72TcDb
--HG--
extra : rebase_source : 0bc1b00e69eb58b5ae5fe4ea9ec0b3b0970beb6c
The whitespace optimization code only knows about the light tree.
It's not a great idea to try to put flattened tree children of a slot through
there, since the children may not be assigned to the same slot, or to any slot
(in which case we crash).
We should probably rename XBLInvolved to ShadowDOMOrXBLInvolved too, I guess.
Note that the ShadowRoot case already sets the bit on Init().
MozReview-Commit-ID: 91lmE7OxlnA
--HG--
extra : rebase_source : ee87ae28d6065c7fd072afad61c16a59b6dce039
In this case we have a shadow hoot with display: contents, with no children.
Those children wouldn't be flattened tree children of the shadow host.
Instead of using the last light dom child and seek to it, use
FlattenedChildIterator's reverse iteration.
MozReview-Commit-ID: 18XL5Ong7ww
--HG--
extra : rebase_source : 2d34bd5b1fdd509a069ffa5052a7b7b3302be24c
I don't think this part is necessary, but putting the patch up in case we decide we want to take it.
MozReview-Commit-ID: G0JTNddvZma
--HG--
extra : rebase_source : 442a6a563044c2c510f332f881d9fab55c4455be
Mats Palmgren
Masayuki Nakano
Boris Zbarsky
sotaro
Ryan Hunt
Emilio Cobos Álvarez
Dorel Luca
Hiroyuki Ikezoe
Morgan Rae Reschenberg
Jeff Gilbert
Margareta Eliza Balazs
Chris Peterson
Mike Conley
Noemi Erli
shindli
Botond Ballo
Matt Woodrow
Daniel Holbert
Andreea Pavel
Joel Maher
Kartikaya Gupta
arthur.iakab
Doug Thayer
Narcis Beleuzu
Jason Kratzer
Miko Mynttinen
Andrea Marchesini
Gurzau Raul
Cosmin Sabou
Jonathan Kew
Markus Stange
Brad Werth
Paolo Amadini
Ryan VanderMeulen
Csoregi Natalia
Gerald Squelart
Tyson Smith
Olli Pettay
Xidorn Quan