GetIndexFromSelectionType() in nsFrameSelection.cpp or
nsFrameSelection::GetSelection() appears in profile of attachment 8848015. So,
it should not use switch statement due to really hot path.
With the previous patch, we can make it use array to retrieve the index from
SelectionType with static_cast<int8_t>.
MozReview-Commit-ID: 8jvIF5buTyT
--HG--
extra : rebase_source : ccb9c855caa6688e45097f67de3160860339d281
nsISelectionController::SELECTION_* are declared as bit-mask. However, no
methods of nsISelectionController treat them as bit-mask and these
values need a switch statement in nsFrameSelection to convert SelectionType to
array index of nsFrameSelection::mDOMSelections because it's too big to create
an array to do it. Additionally, this conversion appears profile of
attachment 8848015.
So, now, we should declare these values as sequential integer values.
However, only nsTextFrame uses these values as bit-mask. Therefore, this patch
adds new type, SelectionTypeMask and creates new inline method,
ToSelectionTypeMask(SelectionType), to retrieve mask value for a SelectionType.
MozReview-Commit-ID: 5Za8mA6iu4
--HG--
extra : rebase_source : 86617c1f5fa23166458f4353cb834f9e7c5b131b
The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
Before this patch, we may get into that piece of code reentrantly from lazy
frame construction itself leaving stale dirty bits around that we really don't
want.
MozReview-Commit-ID: 2wtKeF3o0Gr
CLOSED TREE
--HG--
extra : amend_source : 7618f27e1cf71347f12384935374d303d5c1ab23
extra : histedit_source : 1143d226673ace563bb5d9ff3c420ded33439791%2C9746a30097304bd2214a0072773dc00c767d31cd
This was a test case for bug 1379203 (Google Inbox issue), but to pass this test
also needs the fix in this series to cancel animations when changing
animation-name to 'none' in the specified CSS rule.
Actually the fix in this series also fixes the Google Inbox issue so that this
test can pass without the fix for the Google Inbox issue. But even so without
the fix for bug 1379203, the style data for the first div element in this test
is cached and the second div element uses the cached data.
MozReview-Commit-ID: GfKSDfTZef4
--HG--
extra : rebase_source : caad72ed69e4ebeec8b8cad25949ea69e3bb652e
In the case where values in CSS rules changed directly by CSSOM, the old
value in the CSS rule block is immediately replaced by the new one. So if
the element, which is applied to the CSS rule, has running animations, the
new value is used during cascading process in animation-only restyle. Thus
in a subsequent normal restyle, we can't tell whether the value in the CSS
rule has changed or not. As a result, transitions may not be triggered
(bug 1393323) and CSS animations may not be cancelled if the updated
animation-name is 'none' (this bug).
For the latter case of CSS animations where animation-name has been updated to
'none', this patch introduces a workaround whereby we trigger an update of
running animations whenever the traversal is triggered by changes to CSS rules
and we have existing CSS animations.
change-animation-name-to-none-in-rule.html fails without servo #18214, succeeds
with this patch. Other two tests succeed regardless of the PR.
MozReview-Commit-ID: BrZgTNk9w41
--HG--
extra : rebase_source : 7a55f54a0f94c8db02639f9d8c89f785b3a17a1b
Since these tests harnesses are already disabling Safe Browsing and tracking
protection, they should also disable the other two features that cause
lists to be downloaded from the Mozilla shavar server.
MozReview-Commit-ID: 2158qRU4XZx
--HG--
extra : rebase_source : 287bfb7580538cca7f58ab035b7141166346c318
The FrameLoaderOwner interface has been implemented in WebIDL for several
years now, so these QIs are simply unnecessary overhead.
MozReview-Commit-ID: LAzvfm5Qhy0
--HG--
extra : rebase_source : 2495c07df21c474f5fabc257ff4db43b0d8047e4
J. Ryan Stinnett
Chung-Sheng Fu
Kartikaya Gupta
Emilio Cobos Álvarez
Masayuki Nakano
Bobby Holley
Wei-Cheng Pan
Nazım Can Altınova
Wes Kocher
Sebastian Hengst
Ryan VanderMeulen
Gregory Szorc
Bas Schouten
Kevin Hsieh
Hiroyuki Ikezoe
Brad Werth
Francois Marier
Bill McCloskey
Manish Goregaokar
Kris Maglione