Various atom-related things have improved recently.
- The main atom table is now threadsafe (bug 1275755) and so can be accessed on
any thread. It has also been split into pieces (bug 1440824), which greatly
reduces lock contention.
- A cache has been added to the HTML5 parser (bug 1352874) that removes the
need for most of the full table lookups.
As a result, there is no point having a separate static atom table. This patch
removes it.
MozReview-Commit-ID: 8ou1BrnPAwd
--HG--
extra : rebase_source : 0c6ab073b1a20b703705582d28731a68456741e1
When sizing the container under a min- or max-content constraint,
the item's min/max-content contribution needs to be clamped (when
Automatic Minimum Size / clamping applies) if its size is 'auto'.
That'll give the container the right intrinsic size. In Reflow,
we'll size the track initially to the clamped min-content
contribution again (in the Resolve Intrinsic Track Sizes step),
but since the container now has a definite size we'll grow
the track in the Maximize Tracks step up to its limit
(i.e. the clamp size).
For more details on the underlying issue, see:
https://github.com/w3c/csswg-drafts/issues/2303
This is enough to get the stylo-enabled build green.
There's still some orange in WPT with stylo disabled (due to interfaces not
exposed and that) that I'll update tomorrow.
Will send a different patch on top of this for that, though I'll land together.
MozReview-Commit-ID: CsN5CM93RUz
More improvements to come. In particular, this still iterates through Shadow DOM
in each_xbl_cascade_data, but that should be changed later. That allows to
cleanup a bunch of stuff and finally fix Shadow DOM cascade order.
We still rely on the binding parent to be setup properly in the shadow tree, but
that requirement can go away later (we can walk the containing shadow chain
instead).
This mostly focuses on removing the XBL binding from the Shadow host.
It'd be nice to do EnumerateShadowRoots faster. I think that should also be a
followup, if needed.
MozReview-Commit-ID: Jf2iGvLC5de
If a single element is inserted in the document, from the lazy frame
construction path we mark it as the restyle root.
It has no restyle data, and we weren't calling ClearServoData when its parent
was being removed from ClearServoDataFromSubtree, thus leaving the stale restyle
root.
MozReview-Commit-ID: GY812b8tDk0
--HG--
extra : rebase_source : e6d1035e7d3a72b931aa53ac8dcbf7db58982479
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
--HG--
extra : rebase_source : 6cafc4499c9b80cbc96f1c4d1496e524f59e3c4d
We never removed the event listeners (the code was there, lol, but the function
that was supposed to call into the tooltip listener returned
NS_ERROR_NOT_IMPLEMENTED instead).
Furthermore, we added an event listener each time we reframed an element, which
is insane. Basically, each time an element with tooltip / tooltiptext gets its
frame tree reconstructed, we add the even listener, again, and we never free it.
Xidorn pointed out that this is not such a huge deal because we deduplicate
event listeners per spec, but still...
Move the code from the RestyleManager and the frame constructor to AfterSetAttr
/ BindToTree / UnbindFromTree in nsXULElement to hopefully make this saner.
MozReview-Commit-ID: 6BQbIQJ87qt
This test already has a fuzzy-if annotation with webrender, but when run-by-manifest
is enabled, the fuzz increases. The fix will be tracked in bug 1439980.
MozReview-Commit-ID: 14xidhwXCue
--HG--
extra : rebase_source : cc16f16421478189dc367a739c84e5894c58366c
Run-by-manifest is a mode where we restart Firefox between every manifest of
tests. It sacrifices a little bit of runtime for better test isolation and
improved stability.
This turns run-by-manifest on for all platforms except Android. It also skips
jsreftests and crashtests for now (mostly to limit the scope of what was
landing all at once). Follow-ups will be filed to get it turned on in those
places.
MozReview-Commit-ID: DmvozAIPE5Q
--HG--
extra : rebase_source : 67470894a7aa0b3189380a4874495395401909bb
The point of start-after-crash was to resume running tests after a crash so we
don't miss out on test coverage when a crash happens. Now that we're close to
landing run-by-manifest, this feature is as necessary since only tests that
appear later in the same manifest as the crashing test will be skipped.
Another reason to remove it, is that it's current implementation is buggy. It
assumes tests have a unique ID (they don't), which means we could accidentally
get into an infinite loop if the wrong test happens to crash at the wrong time.
A third reason to remove it is that it adds a lot of complexity to the harness.
Especially now with run-by-manifest, supporting both would require handling a
lot of different edge cases and make things much more complicated than the
already are.
All that being said, it would still provide value. Not only would it allow us
to resume tests in the same manifest, but run-by-manifest isn't yet enabled on
Android, jsreftest or crashtest (though we hope to get it enabled in those
places in the future). So it may be worth re-implementing start-after-crash
again based on the new manifest parsing mechanism that run-by-manifest uses. It
should be possible to implement it a lot more cleanly now. This work will have
to be left to a follow-up.
MozReview-Commit-ID: P2hh5VecKW
--HG--
extra : rebase_source : 809d5103b8d513c709aa950b102d3efee28fb205
This implements a chunk_by_manifest algorithm. It is similar to chunk_by_slice
in that it tries to make an even number of tests run in each chunk. However,
unlike chunk_by_slice it will guarantee that tests in the same manifest will
all run in the same chunk. This makes it suitable to use with run-by-manifest.
This means the chunks won't be perfect (as manifests are differnet sizes). It
is also prone to more randomization, similar to chunk-by-runtime.
In fact, this algorithm is nearly identical to the chunk-by-runtime one, so it
was refactored out to a base class.
MozReview-Commit-ID: HI2ByxW0i8V
--HG--
extra : rebase_source : e066c034b85222d26bafe6873a80366d5bd9df9e
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
Sebastian Hengst
Florian Quèze
Nicholas Nethercote
Mats Palmgren
Emilio Cobos Álvarez
Eitan Isaacson
Brian Grinstead
Valentin Gosu
Andrew Halberstadt
Brindusan Cristian
Cosmin Sabou
Adrian Wielgosik
Ting-Yu Lin
Andreea Pavel
Zhang Junzhi
Xidorn Quan
Mike Conley
arthur.iakab
Botond Ballo
Coroiu Cristina
shindli
Jonathan Kew