Instead, handle the display: contents case and the ::after case using
FindNextSibling.
The removal of line frames is moved up to not interfere with the insertion point
computation.
Also parentAfterFrame is renamed to nextSibling, which is more relevant to what
it was doing with display: contents.
MozReview-Commit-ID: 1cqclsGQlaw
The only reason not to do that is when there's after content in there. We know
that there isn't really any ::after content, since it would've been handled by
FindNextSibling, so we know we're performing a real append.
MozReview-Commit-ID: ExoPolZy4gG
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
If in the future nsDeviceContextSpecWin::BeginDocument was to return
NS_ERROR_FAILURE, then the channel between RemotePrintJobParent and
RemotePrintJobChild will be close at [1]. RemotePrintJobChild keep using ipc
calls after the channel is broken and hits assertions.
PS:
We always hits this assertion by forcing nsDeviceContextSpecWin::BeginDocument
returning NS_ERROR_FAILURE. It's not relative to the change we made in
previous patches.
[1]
https://hg.mozilla.org/mozilla-central/file/b186fddce27f/layout/printing/ipc/RemotePrintJobParent.cpp#l44
MozReview-Commit-ID: 79mZBf301nb
--HG--
extra : rebase_source : 58076a18be56d7eea37ea2f5a147db0048e3493f
extra : intermediate-source : 88df2caad42694dd77f2a518ea8d460d6c88b8c6
extra : source : b920088860904c5d28f3dd2f6eda790dc09be003
For the last page, here is the final three messages sent between the content
process, RemotePrintJobChild, and the chrome process, RemotePrintJobParent, for
printing:
1. The content process sends *ProcessPage* to the chrome process via
SendProcessPrint to request the chrome process print the last page.
2. The content process sends *FinalizePrint* to the chrome process via
SendFinalizePrint to notify the chrome that there are no more outstanding
print requests, and that the chrome process can release interal resource
now.
3. The content process receive PageProcessed message from the chrome process.
This calling sequence is fine for sync style PrintTarget (even though the
FinalizePrint message is sent out a bit ealy). Since a sync PrintTarget
completes its print task right after receiving *ProcessPage* message in #1,
sending FinalizePrint before getting PageProcessed response is harmless.
But this message dispatching sequence does cause a problem for async style
PrintTargetEMF. After getting a message sent in #2, PrintTargetEMF release all
resources before getting a EMF conversion response from the PDFium process. So
the last page can not be printed correctly. This patch reorder the #2 and #3
message, that is to send FinalizePrint after the content process received
PageProcessed message of the last page.
MozReview-Commit-ID: 9ZVSrFnuHBU
--HG--
extra : rebase_source : a54b264998abeeeb0814768e1dd3f6749de97def
extra : source : 70ce23becf8840408cd72e7f933a167090519c09
Before we introduce PrintTargetEMF, all PrintTargets finish page printing task
before the end of PrintTarget::EndPage(). Unlike others, a page printing
in PrintTargetEMF is done after receiving an async callback from the pdfium
process. So we have both async and sync page printing behavior now. This patch
is trying to make both of them work correctly while priting a content document.
MozReview-Commit-ID: 2PHJToFlvtu
--HG--
extra : rebase_source : 9d2d7cf7330a157a0e5c6a414c75de94ca3fb5a1
extra : source : f61eb00f83acf45511d8448922212dccb12b05aa
This patch is effectively just resurrecting a function that was previously removed in https://hg.mozilla.org/mozilla-central/rev/173a4f49dfe3#l1.96 .
MozReview-Commit-ID: 4PXSOu4tzzU
--HG--
extra : rebase_source : 88deb29578bb6851b606f5088f6f18f3a65e8e3e
The LastContinuation stuff behavior was what we did before the other patches, so
let's do that all the time to avoid surprises, though unfortunately I don't have
test-cases.
This effectively restores exactly the same behavior we had before all my frame
constructor patches, just with less code.
MozReview-Commit-ID: IkQ3H3rtlQM
--HG--
extra : rebase_source : 037f3564a4bb137fe7b9ed08deb248b61bf5fe8c
This patch is effectively just resurrecting a function that was previously removed in https://hg.mozilla.org/mozilla-central/rev/173a4f49dfe3#l1.96 .
MozReview-Commit-ID: 4PXSOu4tzzU
--HG--
extra : rebase_source : a8ada7319ea86ccb6178870510fdbb1dac6bd027
If in the future nsDeviceContextSpecWin::BeginDocument was to return
NS_ERROR_FAILURE, then the channel between RemotePrintJobParent and
RemotePrintJobChild will be close at [1]. RemotePrintJobChild keep using ipc
calls after the channel is broken and hits assertions.
PS:
We always hits this assertion by forcing nsDeviceContextSpecWin::BeginDocument
returning NS_ERROR_FAILURE. It's not relative to the change we made in
previous patches.
[1]
https://hg.mozilla.org/mozilla-central/file/b186fddce27f/layout/printing/ipc/RemotePrintJobParent.cpp#l44
MozReview-Commit-ID: 79mZBf301nb
--HG--
extra : rebase_source : 6b84da35fdc96ae8161552fe5d0764b0c2c0f3ee
extra : intermediate-source : 88df2caad42694dd77f2a518ea8d460d6c88b8c6
extra : source : b920088860904c5d28f3dd2f6eda790dc09be003
For the last page, here is the final three messages sent between the content
process, RemotePrintJobChild, and the chrome process, RemotePrintJobParent, for
printing:
1. The content process sends *ProcessPage* to the chrome process via
SendProcessPrint to request the chrome process print the last page.
2. The content process sends *FinalizePrint* to the chrome process via
SendFinalizePrint to notify the chrome that there are no more outstanding
print requests, and that the chrome process can release interal resource
now.
3. The content process receive PageProcessed message from the chrome process.
This calling sequence is fine for sync style PrintTarget (even though the
FinalizePrint message is sent out a bit ealy). Since a sync PrintTarget
completes its print task right after receiving *ProcessPage* message in #1,
sending FinalizePrint before getting PageProcessed response is harmless.
But this message dispatching sequence does cause a problem for async style
PrintTargetEMF. After getting a message sent in #2, PrintTargetEMF release all
resources before getting a EMF conversion response from the PDFium process. So
the last page can not be printed correctly. This patch reorder the #2 and #3
message, that is to send FinalizePrint after the content process received
PageProcessed message of the last page.
MozReview-Commit-ID: 9ZVSrFnuHBU
--HG--
extra : rebase_source : d12161e1c8ac6469fc1ecb9514939bd35979d573
extra : source : 70ce23becf8840408cd72e7f933a167090519c09
Before we introduce PrintTargetEMF, all PrintTargets finish page printing task
before the end of PrintTarget::EndPage(). Unlike others, a page printing
in PrintTargetEMF is done after receiving an async callback from the pdfium
process. So we have both async and sync page printing behavior now. This patch
is trying to make both of them work correctly while priting a content document.
MozReview-Commit-ID: 2PHJToFlvtu
--HG--
extra : rebase_source : 3531dd6a100e9518d8cb9904326250a8318cdad2
extra : source : f61eb00f83acf45511d8448922212dccb12b05aa
This allows logging from the command line without using a webextension.
MozReview-Commit-ID: 6pkDbLXzz3X
--HG--
extra : rebase_source : 92a840d47054e5bef4cd7adf0aadb16f093f7639
The textBreakPoints variable and its related logic are copied from
BuildTextRunForFrames, however, they are not used in
SetupLineBreakerContext at all. Remove the variable allocation and the
unnecessary while loop.
MozReview-Commit-ID: 1AsA6V7aGMh
--HG--
extra : rebase_source : 408b1e4a44e7a7f41be9cafdb72392ed5f518f37
* New USER_CHROME_CSS_LOADED histogram
* Just log a boolean to reflect if the userChrome.css was successfully loaded at profile initialization, in the parent process.
MozReview-Commit-ID: 8ffSNUot43I
--HG--
extra : rebase_source : 11f43e832449952c83cdb104c61c9c33c1aaa123
We have ServoCSSParser class, and I think it's better to move those
Servo FFI into this class to avoid including ServoBindings.h everywhere.
MozReview-Commit-ID: 6orXtddp9ZU
--HG--
extra : rebase_source : 6da4158c4fec606aaee49fddee3192f94d6c85a3
We should consider slot as a parent in ChildIterator: if slot's
`assignedNodes` is not empty, use `assignedNodes`, otherwise, use direct
children as fallback content.
Also, GetFlattenedTreeParentNodeInternal should be changed to use
`assignedSlot` instead of `DestInsertionPoints`.
This code is used to detect too-early accesses of prefs in content processes.
The patch makes the following changes.
- New terminology: "early" prefs are those sent via the command line; "late"
prefs are those sent via IPC. Previously the former were "init" prefs and the
latter didn't have a clear name.
- The phase tracking and checking is now almost completely encapsulated within
Preferences.cpp. The only exposure to outside code is via the
AreAllPrefsSetInContentProcess() method, which has a single use.
- The number of states tracked drops from 5 to 3. There's no need to track the
beginning of the pref-setting operations, because we only need to know if
they've finished. (This also avoids the weirdness where we could transition
from END_INIT_PREFS back to BEGIN_INIT_PREFS because of the way -intPrefs,
-boolPrefs and -stringPrefs were parsed separately.)
MozReview-Commit-ID: IVJWiDxdsDV
--HG--
extra : rebase_source : 8cee1dcbd40847bf052ca9e2b759dd550350e5a1
With this patch print IPC no longer requires the child process to create files.
Instead files are opened by the parent and a file descriptor is sent to the
child. This will allow us to sandbox child processes more aggressively.
MozReview-Commit-ID: GQWTYLV01kj
--HG--
extra : rebase_source : 9b91e9b01708d73915a49684c2cec96457650e45
It was exposed during stylo implementation but it should be behind
`layout.css.grid-template-subgrid-value.enabled` pref.
MozReview-Commit-ID: DqrU6zYgdES
--HG--
extra : rebase_source : 14859f5912faff9cf2daf9b10409114e853bab6d
Windows 7 doesn't have mono symbol font for emoji code mapping. And fontconfig
doesn't have better option for this. So I except to these platforms.
MozReview-Commit-ID: 7TB1guyzBVS
--HG--
extra : rebase_source : 4a014a26618471cf8bee635bae961321c98a162e
devtools/shared/css/generated/properties-db.js is generated by running
"./mach devtools-css-db"
MozReview-Commit-ID: 1U4yoQTDwxi
--HG--
extra : rebase_source : 16049b4253ae9a3f6e24cc30896ed53f65ebaf7a
On a CLOSED TREE, since the servo patch got in.
This removes one px of "padding" in:
<progress style="-moz-appearance: none"></progress>
But it'd be worse to not be able as an author to override those somehow.
MozReview-Commit-ID: EFZIBHaUskM
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
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
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
A repaint is sufficient to pick up the new property value.
MozReview-Commit-ID: oKFgGfquyl
--HG--
extra : rebase_source : 4f145fb29eddcc5f83506cc6f512b123c29676ef
Run those fragment URL tests in test_transitions_per_property.html for
clip-path only because shape-outside will resolve URL fragments (i.e. #a),
so the computed value of URL fragment will have document URL as a prefix,
which won't match. Also, added absolute URL tests for both clip-path and
shape-outside.
MozReview-Commit-ID: 8SUpfTaV9cz
--HG--
extra : rebase_source : e5c180a2ef293d70fa33133012023e9360eef98e
Some Gecko style system files are modified to prevent assertions and
crashing, and to keep test failures on stylo disabled builds to minimum.
MozReview-Commit-ID: GuxAeCTz0xx
--HG--
extra : rebase_source : 97c8b3900e4492ac03158a38aa03f7c044b71e0f
Most of this patch is just mechanical changes, but note that this patch
now makes the mFlags in scrollbar-container nsDisplayOwnLayer instances
have one of the direction bits set. As a result, this requires changing
the implementation of nsDisplayOwnLayer::IsScrollThumbLayer().
MozReview-Commit-ID: 2BLdbpz5Sa8
--HG--
extra : rebase_source : 27e7d90ce60c7f702fe77d8a3a0f7e3ae3e4a4ff
