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
This drops the code that compares the WR and Gecko hit-test results when
WR is enabled, because the "baseline" Gecko hit-test result is not
correct enough to provide a useful comparison. Instead flipping the pref
now just enables the WR hit-test code; we will rely on automated testing
to check for correctness.
MozReview-Commit-ID: 8IFtk0p2NvE
--HG--
extra : rebase_source : 6402a87f3345ca3b82220e42185c9f8776475cdd
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
call SetStylistStyleSheetsDirty(). 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 : 39f56227201d435ad416fe21f4b0e0cad7d2d16c
This is a pre-patch for the real fix of Bug 1418433.
In the real fix, we'll add a IncrementUndisplayedRestyleGeneration() call into
SetStylistStyleSheetsDirty(). However, the IncrementUndisplayedRestyleGeneration()
call needs get through some deep structures in nsPresContext, RestyleManager,...
etc., and doing so means we need to move bunches of related include files, forward
declarations, from .cpp file to .h file, which doesn't make sense.
Instead, we move the implementation parts of SetStylistStyleSheetsDirty() to .cpp
file (since it is now a bit more complicated than it was), so we can use the existing
include files in the .cpp file to add IncrementUndisplayedRestyleGeneration() call
(this is in a following patch).
MozReview-Commit-ID: 3Vp9qyCf8NA
--HG--
extra : rebase_source : 16386256e16a2ca98bf988d66d861cbea58490a3
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 some
tests to ensure that, if the inline style sheet is added/changed/removed, the
style data of a non-displayed element is always up-to-date. Some more tests
are added to verify the correctness of the style data when a style rule is
added/changed/removed via CSSOM.
MozReview-Commit-ID: Ggjd4FMqZlo
--HG--
extra : rebase_source : bac0e5a6e2c032922b57b08392f3381b68eeafa8
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
Brindusan Cristian
Emilio Cobos Álvarez
Olli Pettay
Bogdan Tara
Dorel Luca
Andrea Marchesini
Bob Owen
Mats Palmgren
Jeremy Chen
Xidorn Quan
Edgar Chen
Morris Tseng
JW Wang
Brad Werth
Matt Woodrow
Cameron McCormack
Kartikaya Gupta
Margareta Eliza Balazs
Botond Ballo
Hiroyuki Ikezoe
Dave Townsend
Sebastian Hengst
Ciure Andrei
Mantaroh Yoshinaga
Phil Ringnalda
Robert Longson