This also makes the rule map not process all the stylesheets for the document,
which would be a mess with shadow DOM.
Far from the final, ideal state, but hey, progress.
MozReview-Commit-ID: 7TrifME9VZ
Prior to this change, we would print a selection by:
* reflowing the whole document into one infinitely long page
* position at the top of the selection to print the first page
* move the position down by a page length each time to print subsequent pages
This has several shortcomings, detailed in the bug.
This approach uses the original document selection to create an inverted
selection in the document cloned for printing, adding an ellipsis when ranges
start or end in text nodes, then deletes that selection from the document prior
to printing.
It is expected to use 64-bit for all the restyle generation counters, since the
getter methods all return uint64_t type at present. However, we're using uint32_t
for the actual counter variables, which means the potential overflow issue is not
avoided.
In this patch, we use 64-bit for the restyle generation counters, so the overflow
issue can be avoided as expected.
MozReview-Commit-ID: 2y2afIcuwvc
--HG--
extra : rebase_source : 3fe64d7d3fc00fa1031eef9f0c15b64405435dfd
With the conformant Promise handling (bug 1193394), there happen to receive
unexpected MozAfterPaint while waiting for MozAfterPaint for OMT animation.
The safest way to avoid this confusion is to start test refresh mode and
flush all pending styles (layout and paint) there so that the unexpected
MozAfterPaint is absorbed there.
MozReview-Commit-ID: 2xdKe4InYcP
--HG--
extra : rebase_source : dd6ba1dff7c449e40bb3286b5d9083eefc196de5
This EnsureEventualDidPaintEvent() creates software timer. But this timer will
bring several intermittent tests fail. For example, if we want to check the
compositor animation property. If test receives MozAfterPaint of the timer,
there doesn't have animation property on compositor, as result of this, a test
will fail.
I think we don't need to create this timer each time since current painting is
happening synchronously under the refresh driver.
[1] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#189
MozReview-Commit-ID: Hb7UEITer5t
--HG--
extra : rebase_source : 7aee1eced01813907ab0c3e5dff80e90261c0815
Turns out that there's been a bug in the event regions code since it was
first written, where touch-action:manipulation is not properly expressed
in the event region structs. It's sort of a design bug that we can't fix
without adding another region. However, in bug 1389149 I accidentally
changed the behaviour of some of these cases because I wasn't aware of
this bug. This patch repairs the code so that it behaves the same as it
used to prior to bug 1389149, and documents the buggy scenario.
MozReview-Commit-ID: 9XhkH6ypZHi
--HG--
extra : rebase_source : 970054c0cc71cdcb9b89925474e553d638c8fcc6
waitForPaintsFlushed() flushes styles inside it, so we don't need the explicit
flush.
MozReview-Commit-ID: KcQYRDWyhU0
--HG--
extra : rebase_source : 9adeaa107f358d9beb717a6d1fa96bbfd4c05416
The waitForPaints() which is defined in function runOMTATest() invokes
waitForAllPaintsFlushed(), it is the same what waitForPaintsFlushed() does.
MozReview-Commit-ID: BKt2fZO3DuM
--HG--
extra : rebase_source : b0cd89ca4000cd7bfae2c169d44984e15e78f9e5
Setting the 'layout.display-list.retain.verify' gfxPrefs implies
'layout.display-list.build-twice', and then compares the retained-built tree
to the non-retained one, and outputs differences&trees to the terminal.
MozReview-Commit-ID: 3dnyIUTbtH8
--HG--
extra : rebase_source : 36a6b8f029d0bd1339557e7c630906311ecf1254
In the current implementation, we call SetStylistStyleSheetsDirty() every time
a style sheet is changed. However, the dirty bit setting may or may not always
update the style data. For example, the style data for undisplayed elements are
deliberately not updated in Stylo. However, the getComputedStyle API is supposed
to provide a way to get the up-to-date computed style data, even for undisplayed
elements.
In this patch, we increment RestyleGeneration for undisplayed elements when we
decide to update style data (i.e., calling ServoStyleSet::UpdateStylist()) due
to (XBL)StyleSheet is dirty. This could flush the cached data that getComputedStyle
API holds, and ensures the getComputedStyle API computes a new one.
MozReview-Commit-ID: JDDhACOG3z4
--HG--
extra : rebase_source : 51d37757b5449d315aa7c2e0aedb4a4622e2a859
In certain situations, we might access a non-displayed (i.e., display: none;)
element's style data through getComputedStyle API. In this patch, we add a test
to ensure that, if the inline style sheet is changed/modified, the style data
of a non-displayed element is always up-to-date.
MozReview-Commit-ID: Ggjd4FMqZlo
--HG--
extra : rebase_source : 8e9ba5d6b7b4c26b5247b36d44ff02a391dc7ee6
The change is mostly copied from GeckoRestyleManager::AttributeChanged.
It is not clear to me whether it's worth moving it to the superclass so
that we don't duplicate the code. If we are removing the Gecko code in
short term, it probably doesn't matter.
It is also not clear whether we should port other code from that method
to ServoRestyleManager.
MozReview-Commit-ID: Fd1nbwgLGa1
--HG--
extra : rebase_source : 7bba8907fa7e57695a8294cf9277804fbe23ff8f
