This unfortunately doesn't fix my test-case (because we're replacing the text
content all the time and all that), but it's still worth it, since it fixes the
case we care about (the parser appending).
We could also optimize pure insertions (since in that case we can still figure
out what the old text was), but it's probably annoying and not worth the churn.
In any case, we cannot optimize anything that resembles any kind of removal,
because from there we don't know the old text in any way (and the text nodes
like to reuse string buffers and such).
We could do two other optimizations to replace / extend this one, in that order:
* Pass the buffer and length to CharacterDataWillChange, and use that to get
the exact old text and the new one in RestyleManager. That would make the
optimization exact.
* Pass some sort of Maybe<bool> mWasWhitespace down the CharacterDataChangeInfo
which is computed like:
HasFlag(NS_CACHED_TEXT_IS_ONLY_WHITESPACE)
? Some(NS_TEXT_IS_ONLY_WHITESPACE)
: Nothing()
It's not clear to me it's going to be completely worth the churn, so I haven't
done those yet, if we see code in the wild which resembles my testcase, we can
think of doing it.
MozReview-Commit-ID: 2rTWaZti8rv
Also, make them not rebuild the CascadeData synchronously, via the
FlushSkinSheets call, since that's broken. That fixes bug 1413119.
This is a little step in getting rid of XBL usage for Shadow DOM.
MozReview-Commit-ID: HJ7FeUZlRTW
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. Skip autofocus if the element moved to a
different window in the meantime.
MozReview-Commit-ID: 90jiJYJWmRg
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
