In the era of B2G, we wanted to hide the carets during scrolling, and
PostScrollState was designed to avoid carets flicking during momentum
scrolling.
These days, we no longer hide carets during scrolling, so PostScrollState
can be removed to make the code simpler and easier to maintain.
MozReview-Commit-ID: Bf6ZgYVlt1q
--HG--
extra : rebase_source : 272bf91b8acaae6d81a3291b6ad85703ff2696dc
As for now, the scrollable direction with a mouse wheel for a single-line text
control is hard-coded; that is, only horizontal wheel scrolls are able to take
effect while vertical ones aren't. However, this isn't the desired case for
vertical writing mode, where the opposite case definitely suits better.
This commit refines the hard-coded scrollable direction for a single-line text
control to be writing-mode-adaptive.
MozReview-Commit-ID: 4Zkoe2ExPCZ
--HG--
extra : rebase_source : 113b2ea80b6bbbcd2d8379b438de97eedd616551
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
Everyone calls them with the shell of the current composed document, and this
allows the multi-presShell stuff to just be in UpdateCurrentStyleSources /
DoGetStyleContextNoFlush.
The only reason we need to use OwnerDoc()->GetShell() instead of the composed
doc in GetStyleContext / GetStyleContextNoFlush is Element::GetBindingURL, which
does expect to get the binding URL for stuff outside of the composed doc (and
changing that gave me a useless browser).
That's technically a behavior change on the cases that used to pass nullptr, but
I think all callers are fine with that. I could also just add a special function
for that particular case, it may be worth it.
MozReview-Commit-ID: 2XlnkgdgDCK
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
We just need to use the existing StyleChildrenIterator which iterates over them.
We need to be a bit careful though, since ::before and ::after are owned by
their own frame, and thus could be unbound from the tree or even dead after
removing the frame.
Hopefully the only access to the node being removed is unnecessary (anon roots
don't have siblings anyway).
There's also the weird thing of the thing we're iterating changing under the
hood. It works fine for this case, but maybe it would be better to handle them
explicitly like:
if (Element* before = nsLayoutUtils::GetBeforePseudo(aChild)) {
bool didReconstruct = ContentRemoved(aChild, ...);
if (didReconstruct) {
return true;
}
MOZ_ASSERT(!nsLayoutUtils::GetBeforePseudo(aChild));
}
// Same for ::after.
StyleChildrenIterator iter(aChild);
for (..) {
// Do the rest of the kids, which can't get unbound.
}
That'd repeat a bunch of code, so not a fan neither... I pointed this out more
explicitly in a comment instead.
MozReview-Commit-ID: HBsjLH01Db3
This is only hooked up for the codepath where the event regions are built
from nsDisplayCompositorHitTestInfo display items, not for when they're
build from nsDisplayLayerEventRegions display items.
--HG--
extra : rebase_source : 4f6fedcd9522362e2e62678428987180399bb796
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 5e502d5d077dd764ca1a43e7c3f06855858fe735
Poking at the frame tree has problems: If we poke in negative (using
eSkipNativeAnonymousContent), as we were doing, we mess up the case where we're
actually _not_ doc-level, and _not_ ::before or ::after. This can't happen for
content documents, but can happen for chrome (since nsDocElementBoxFrame
implements nsIAnonymousContentCreator).
If we poke in positive, as we used to, you get that right, but mess up the
root scrollbar case.
Instead, use a node property to mark doc level anon content. This is a case rare
enough that it seems worth to not steal a node bit.
To recap the failure:
* The initial value of -moz-control-character-visiblity is different on beta
and nightly.
* XUL has a global rule setting -moz-control-character-visibility on the root,
to a value so that it's the initial one on nightly, but the non-initial one
on beta.
* Changes to this property cause a reframe.
* Reframes of a nsIAnonymousContentCreator anon content reframe the container.
* We were failing to inherit correctly for the nsIAnonymousContentCreator
content for the root XUL element on the initial styling, inheriting from the
default computed values instead, since we failed to reach the root element's
primary frame from GetFlattenedTreeParentForDocumentElementNAC ->
AppendDocumentLevelNativeAnonymousContentTo, since the primary frame is set
_after_ processing children.
This seems somewhat risky to change, and inconsistent with any other stuff
the frame constructor does, see bug 973390.
* Given that, the next restyle of the root element, in this case caused due to
the customizable UI, we _found_ the actual correct parent, recomputed the
style, saw that -moz-control-character-visiblity had changed, and reframed.
But we were reframing the whole window, not just the NAC, because of the
fourth bullet point. Reframing the whole window caused us to lose the popup
state (that's bug 1440506).
Worse than that is the fact that given we reframe and reconstruct the
anonymous countent again, we go back to the initial bogus state, just
awaiting for the next restyle to reframe the whole window.
I wish there was a bullet-proof way to test it that isn't just counting reframes
and relying on which properties reframe or not, but due to the nature of
nsIAnonymousContentCreator's NAC, it's not possible in any easy way I can think
of.
MozReview-Commit-ID: IPYB5trsN8R
Calling RequestRestyle() for update cascade results is weird since in general
RequestRestyle() is a result of updating cascade results (e.g. when an
!important style is changed). In the case where we already know that we need
to update cascade results we can do it right after all the other processes that
may need to update cascade results has done so that we don't need to worry about
the cases additional cascade results update happens.
MozReview-Commit-ID: 6lh0NgTPF9j
--HG--
extra : rebase_source : 4dbec85f55a14776907b677f2876421abc141384
If reftest-no-flush is not specified, reftest harness flushes layout in a
callback of setTimeout() that happens after paint process happened in the next
refresh driver's tick. Thus, the paint process triggered by the layout flush
causes no invalidation changes, so reftest harness ends up waiting for the
animation end until the animation finishes.
MozReview-Commit-ID: GXvmyXh0kfV
--HG--
extra : rebase_source : 091a91122b7337ff05032bd64fa2597e59bed3a4
Set pref datareporting.healthreport.uploadEnabled=false during mochitests
and set pref toolkit.telemetry.server to a dummy server during reftests
(uploadEnabled was already false for reftest and the telemetry server was
already set for mochitests - now these prefs are consistent).
Some mochitests failed with this change; they are updated to
set datareporting.healthreport.uploadEnabled where required.
We assert the same in nsCSSFrameConstructor::RecreateFramesForContent, which
asserts aContent.
MozReview-Commit-ID: 5r0ZjfTJ4zZ
--HG--
extra : rebase_source : dcf3ecaa2f7bd6fc8887f84d1f85018ebcae5cd3
Much like we do in nsIFrame::UpdateStyleOfOwnedChildFrame.
There's also the fact that ::-moz-math-anonymous shouldn't probably be
content-exposed... Oh well.
MozReview-Commit-ID: 8mthwW7Nivy
--HG--
extra : rebase_source : b772ca036ac3817d8e5f54b029892e9ece957d40
Unlike CSS animations/transitions, script animations keep alive on display:none
elements, so once the display property was changed to others in normal
styling, we need to do styling for the script animations in the second
animation traversal. Otherwise, the styling for the script animations will
be deferred to the next frame.
MozReview-Commit-ID: 9ikg9N8X73a
--HG--
extra : rebase_source : 8b6a7a75a084eec2b3f276fd498f098bc9ed05bc
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
After the part 1 fix, we can still (asynchronously) call some generic cleanup
code that tries to let the parent process's RemotePrintJobParent know that
printing failed under the stack:
RemotePrintJobChild::OnStatusChange
nsPrintData::DoOnStatusChange
nsPrintJob::FirePrintingErrorEvent
nsPrintJob::CleanupOnFailure
We crash on trying to use the RemotePrintJobChild to message the parent process
since the delete message from the parent has been processed. This change makes
RemotePrintJobChild::OnStatusChange check that it's initialized before trying
to send any messages.
Pushing to CLOSED TREE since this passed a full Try build and is a topcrash
we want to land for beta ASAP.
MozReview-Commit-ID: FfizRMj2s2m
Pass --appname org.mozilla.geckoview.test to 'mach mochitest' or
'mach reftest'. This runs the tests without e10s currently.
MozReview-Commit-ID: 7TIvA3zRCw2
A table's used width may be different with its computed width. In the past, this
situation wasn't taken into account in process of table reflow, this patch
corrects the positioning of children of a table in this situation.
MozReview-Commit-ID: 4siu2ba0pqG
--HG--
extra : rebase_source : b713baa825151e9a789abcc772d081ff065acaed
See bug 1000879 for the last time the MathML pseudo-elements were touched. After
this I want to see if it's easy to remove completely, since it will also remove
the biggest usage of the AdditionalStyleContext API.
MozReview-Commit-ID: 60Z4oAwujsU
We used to do it this way effectively until I fixed it in bug 1400936.
Per the list of fuzz bugs that bug has in the "Depends on" field, some of those
without a super-clear fix, and others that aren't listed in there, and all the
complexity we had to deal with while receiving restyle requests mid-unbind, etc,
I think this is the right call.
This clears data on RestyleManager::ContentRemoved for non-anonymous nodes, and
on UnbindFromTree for subtrees rooted at anonymous nodes.
This will hopefully yield enforceable invariants.
MozReview-Commit-ID: IMwX5Uh1apv
The crashtest will crash whenever the shell is destroyed, which is annoying,
but...
MozReview-Commit-ID: 1JkLy5K98bS
--HG--
extra : rebase_source : 063ca56df3db72940dbb3537a36da561528a5949
Also, make them not rebuild the CascadeData synchronously, via the
FlushSkinSheets call, since that's broken. That fixes bug 1413119.
This is a little step in getting rid of XBL usage for Shadow DOM.
MozReview-Commit-ID: HJ7FeUZlRTW
--HG--
extra : rebase_source : 0fcd0ed461856c1e87e45ef63c9e1d2e81281469
Refrests without specifing reftest-no-flush flush all pending styles so that
we don't need to wait for a requestAnimationFrame to apply the final style
changes.
MozReview-Commit-ID: lAFsFG8CrE
--HG--
extra : rebase_source : 46ba219da0ccbb1bee0d8243b7e2ee5f8d81a13f
This test is supposed to append *animating* element to the document.
MozReview-Commit-ID: 39kvw6IYRF9
--HG--
extra : rebase_source : 510e99190fb60067b0bf404c37d7250e2d994ff0
getComputedStyle() ensures triggering new transitions, so we don't need to wait
for a requestAnimationFrame callback.
MozReview-Commit-ID: Bes1vQeHohI
--HG--
extra : rebase_source : fdb8face312a471be5f93229a9fbbfd4fc59418f
