nsStyleContext::CalcDifference had an optimization where, when we knew
that the old and new style context have the same rule node, we knew that
the only change hints that would need to be handled are those in the
"not handled for descendants" category, generated due to explicit
'inherit' values on reset properties. This was because any changes due
to differences in inherited properties should only have generated
"handled for descendants" change hints (and thus would already have been
handled on an ancestor).
Before bug 931668, this let us avoid calling CalcDifference on structs
that only would have generated hints that we knew we already would have
handled. However, after bug 931668, we compare all structs anyway so
that we can set the aEqualStructs outparam, so we don't gain anything
from this optimization. We can still return these change hints we know
will not need to be handled, and rely on ElementRestyler::CaptureChange
to filter them out.
MozReview-Commit-ID: Ld1s2Js0i6r
This changes ElementRestyler::CaptureChange so that it avoids generating the
current frame's entire set of change hints, if only some of the hints were
handled by ancestors, and instead to remove the hints that we know are
subsumed.
MozReview-Commit-ID: JvhxeQC6MmQ
The relevant frame classes are:
SubDocumentFrame
ListControlFrame (only when used for (non-e10s?) comboboxes)
PluginFrame
ViewportFrame
MenuPopupFrame
The view is now created in the frame's Init() method, except for
ViewportFrame which has its view assigned by the frame constructor
via a SetView() call.
MozReview-Commit-ID: 4O7Hm1yqwIp
Views are used for PluginFrame which inherits nsFrame, not nsContainerFrame,
so it's more appropriate that these methods should live in nsIFrame/nsFrame.
MozReview-Commit-ID: 87EgCnkF5YT
When constructing a Loader without passing a document, we added a DocGroup
parameter so that we could still use it to dispatch events to the DocGroup.
Delete NS_ENSURE_TRUE because new() is infallable.
Use another runnable pointer for calling dispatching because forget() will
nuke the pointer and we need to use evt afterwards.
MozReview-Commit-ID: Ce2K6j4pUhA
--HG--
extra : rebase_source : 2bacf1f856e0700f36b2fefe4d2424719cad77a7
This change is to use gecko_enum_prefix in helpers.mako.rs, so that we do not
need to manually write code for nsStyleDisplay::mTransformBox.
MozReview-Commit-ID: 7UAL0iUcSIO
--HG--
extra : rebase_source : e99b7c163991df7ef3e7c0404fcef1832718a150
The feature is controlled by pref layout.accessiblecaret.timeout_ms, and has been disabled in bug 1268410.
It's time to remove relevant code from the tree.
MozReview-Commit-ID: LLu8RiQcTpm
--HG--
extra : rebase_source : 906299afe9fbcb4bad2c74c83f19eb98b8815882
If we disable APZ on an individual scrollable element by setting the "disable APZ"
flag on the ScrollMetadata, we should also disable paint-skipping for that element.
If we don't do this, we end up in a situation where the APZ code is not applying
the async transform but is sending repaint requests expecting the main thread to
do repaints. Meanwhile the main-thread thinks that it can send empty transactions
and have APZ update the async transform (a.k.a. paint-skipping). So visually
neither APZ nor main-thread have an effect and the element doesn't appear to
scroll except with the tile-aligned displayport shifts. Disabling paint-skipping
on the element fixes the issue.
MozReview-Commit-ID: H4wpVLw8r8X
Various pieces of browser chrome, such as the accessible carets or new
find-in-page highlighter, overlay the content with anonymous content elements.
These overlays are positioned with respect to the root document. This means that
if the overlay really pertains to a scrollable subframe (e.g. carets for a text
selection inside an iframe), then scrolling the subframe would result in the
anonymous contents being "mispositioned" from the user's point of view. The
browser chrome code that creates the overlay is responsible for moving it in
response to user scrolling, so that it appears correct. However, the only
mechanism the browser chrome code has to detect user scrolling are the main-thread
events, which are asynchronous with respect to APZ.
Therefore, in order to improve the user experience, we need to disable APZ in
cases where this happens. We specifically isolate the case where the root content
document has visible anonymous content elements, and disable APZ on scrollable
subframe elements inside that document. Note that APZ remains enabled on the
root scroller itself, because we expect the browser chrome code to use absolute-
positioning on their anonymous contents, so that even with APZ scrolling they
will stay where they are supposed to.
MozReview-Commit-ID: 770edaGWMLi
Override OnScrollPositionChanged() in ScrollState because we want to update
carets during scrolling in subframes without APZ.
Due to the observation in bug 1273045 comment 8, we do not distinguish
PositionChangedResult::NotChanged and PositionChangedResult::Changed.
Instead, we always update caret even if its position is not changed.
To avoid excessive CaretStateChangedEvents are dispatched in
OnScrollPositionChanged(), we add IsScrollStarted to distinguish whether
OnScrollStart() is called or not.
MozReview-Commit-ID: KNi9Mct4dSk
--HG--
extra : rebase_source : 61d29fb0e1b6b91971217d3f45a791c456fa4f07
Part 2 is going to add a new hint which will use with RespectOldAppearance.
Hence this patch.
Remove #include "mozilla/WeakPtr.h" and "nsWeakReference.h" because they're
not used in the header.
MozReview-Commit-ID: KiNv0M0v8iO
--HG--
extra : rebase_source : 0969fc5accf11ac69bc97e3a51569b063172ffe3
The Gecko restyle manager does this synchronously, along with a content flush.
In my testing there's no need to do so, and Boris couldn't think off-hand of
why, except the fact that we have this mRebuildAllStyleData thing that takes
care of rebuilding the rule tree, which is quite sensitive.
Also, Boris made a good point about non-inheriting anon boxes, that could
technically change style. I've left a note about it too.
MozReview-Commit-ID: 2lvzhxugKB0
--HG--
extra : rebase_source : 38cf56811f73f5a9f0f6659e08d03e78d4c6dcb5
This allows us to test our media query stuff at least, and works around the fact
that we don't set mUsesViewportUnits.
This will get us better test coverage, at the expense of more expensive window
resizes and similar, temporarily.
MozReview-Commit-ID: 7lgELz86lmW
--HG--
extra : rebase_source : c6d62438b1d76d5adb9eec3a26ef47af1a84924c
I did manual testing for ::-moz-dropdown-list. Unfortunately, the only way I
know to test it is to have a combobox in a non-e10s window and dynamically
change its background color, then drop down the dropdown and see whether it
picked up the changed background color.
MozReview-Commit-ID: B2RkW4otv4s
Boris Zbarsky
Cameron McCormack
Timothy Nikkel
Wes Kocher
Mats Palmgren
Ting-Yu Lin
Emilio Cobos Álvarez
cku
Carsten "Tomcat" Book
Astley Chen
Kartikaya Gupta
Brad Werth
Manish Goregaokar
Olli Pettay
Samael Wang
Kan-Ru Chen