Instead, just post the reframe, and process them normally on the next style
flush.
The assertion happens because the observer is triggered due to a doc ltr -> rtl
change, which triggers style invalidation. There's nothing processing the
restyles resulting from that invalidation before we hackily go into frame
construction from there, and thus we assert that the styles aren't up-to-date.
MozReview-Commit-ID: GnOKFqmtTnq
I left some IgnoredErrorResults for now where people warn on failure. We could
consider adding a WarnOnError() thing or something.
MozReview-Commit-ID: L5ttZ9CGKg0
Everything that needs them up-to-date will call flush appropriately, there
should be no need to do it manually.
This way we coalesce all the stylist updates until the next style flush in the
best case, or until one of the consumers actually needs them.
MozReview-Commit-ID: BVsxXxhtcKL
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
The underlying issue here is that the pres shell was already being torn down
when we flush.
The less risky change here is to just change the assertions instead of
IsSafeToFlush too, but the !isSafeToFlush || mViewManager assertion was also
firing already, because we null out the view manager from Destroy.
So this change is effectively idempotent behavior-wise (we tighten a bit the
view manager assertion, but that should be fine).
Just let me know if you want me to just loosen the assertions, but I think the
IsSafeToFlush change is nicer too.
MozReview-Commit-ID: 240qLlLi7RE
In particular, we set the pres context visible area _before_ processing
restyles.
This causes inconsistencies when resolving viewport units. In particular, the
resulting style tree will have some units resolved in terms of the old size, and
some in terms of the new size, depending on whatever is dirty, because we don't
flush the pending media query changes.
Also, some sizes are resolved against the unconstrained size because of the
shrink-to-fit stuff. Fix this by flushing _before_ in this case, instead of
after, since we're going to set the size to an actual value later when reflowing
the root frame.
MozReview-Commit-ID: ExI5yTJCjGp
This patch makes 'Shift', 'Alt', 'Contorl' and 'AltGraph' been suppressed for content
when fingerprinting resistance is enabled. Chrome can still get these events.
The reason behind this is that websites can still observe key combinations to
tell which keyboard layout is using even we spoof the keyboardEvent.code,
keyboardEvent.keyCode and modifier states. For example, the AZERTY France
keyboard, the digit keys of it requires the user press the Shift key. So, it is
easy to differentiate AZERTY and QWERTY keyboard by observing whether a Shift key
generates its own before the digit keys. There are similar issues for 'Alt' and
'AltGraph' as well.
MozReview-Commit-ID: 3CwCgvey4lK
The autofocus attribute on form elements forces layout in CheckIfFocusable.
To avoid unpleasant FOUCs, defer autofocus processing until frames are
constructed in PresShell::Initialize.
Resolve the race between nsAutoFocusEvent running and page load by checking the
readystate at time of event posting.
MozReview-Commit-ID: 90jiJYJWmRg
The event targets of touch events are not necessarily to be the same as their corresponding pointer events. So we don't have to cache the event target of pointer events when they are generated from touch.
MozReview-Commit-ID: 9Gd6ion7NXf
This makes the pres shell be notified as the last observer unconditionally.
In practice this doesn't matter, and it may already be the case if an iframe
goes display: none and back. In practice, the only dependency that requires this
order is that the pres shell needs to be notified _after_ the content sink, so
we don't try to enter frame construction before beginning the shell update.
That may be worth looking into, but definitely not in the scope of this bug... :)
MozReview-Commit-ID: 9WeJ5kaUtBq
There may be some pending input events in the queue of thread when content starts a dnd operation. Spec says that input events should be suppressed when there is a dnd operation. Add a flag in ESM and turn on/off when start/finish a dnd operation. Checking the flag in PresShell::HandleEvent because we may start a dnd operation with pointermove and we want to suppress the mousemove as well.
MozReview-Commit-ID: 43NZrA7SW4c
