Move the assertion to the earliest point where it can happen instead, and do it
automatically on exit if it's generated content instead of relying on manual
calls.
MozReview-Commit-ID: 5oPwXg2o22V
This also adopts the resolution of [1] while at it, and switches XUL to not
support display: contents until a use case appears.
This makes our behavior consistent both with the spec and also in terms of
handling dynamic changes to stuff that would otherwise get suppressed.
Also makes us consistent with both Blink and WebKit in terms of computed style.
We were the only ones respecting "behaves as display: none" without actually
computing to display: none. Will file a spec issue to get that changed.
It also makes us match Blink and WebKit in terms of respecting display: contents
before other suppressions, see the reftest which I didn't write as a WPT
(because there's no spec supporting neither that or the opposite of what we do),
where a <g> element respects display: contents even though if it had any other
kind of display value we'd suppress the frame for it and all the descendants
since it's an SVG element in a non-SVG subtree.
Also, this removes the page-break bit from the display: contents loop, which I
think is harmless.
As long as the tests under style are based in namespace id / node name /
traversal parent, this should not make style sharing go wrong in any way, since
that's the first style sharing check we do at [2].
The general idea under this change is making all nodes with computed style of
display: contents actually honor it. Otherwise there's no way of making the
setup sound except re-introducing something similar to all the state tracking
removed in bug 1303605.
[1]: https://github.com/w3c/csswg-drafts/issues/2167
[2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700
MozReview-Commit-ID: JoCKnGYEleD
And fix a comment mentioning nsCSSSelectorList that I came across.
MozReview-Commit-ID: 1BOcDqV5dUr
--HG--
extra : rebase_source : 5fbdae6da74cf4fac145fbdd721723e81839e4b3
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly.
However, some web apps actually broken with the standardized behavior. For
protecting testers from known broken web apps, this patch introduces a
blacklist to take the traditional behavior under specific domain (and path in
it, optionally). Currently, docs.google.com and mail.google.com are set by
default.
MozReview-Commit-ID: HSrYX8LUB0p
--HG--
extra : rebase_source : a2677d07410af289534db051767543a25c9a957a
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
This brings us into alignment with the spec and makes us pass some web-platform
tests, along with the reftests that I've included for this bug.
MozReview-Commit-ID: KoKPi18svGE
--HG--
extra : rebase_source : f00dd814238afd4b09bdcb75b22ea249162252b8
This patch doesn't change behavior.
It simply makes us share code/data for two different cases that both ended up
producing mainAxisCoord->GetUnit() == eStyleUnit_Auto. Now, they'll *both* use
the same static nsStyleCoord to represent this "auto" value.
Originally, in one of these cases ("flex-basis:auto;[main-size-property]:auto),
we left the mainAxisCoord untouched. Now we'll point it at this dummy 'auto'
value. Either way we end up with mainAxisCoord->GetUnit() == eStyleUnit_Auto,
so the behavior doesn't change.
The next patch in this series will make further changes to one of these spots,
as noted in the "XXXdholbert" code-comment included here.
MozReview-Commit-ID: 5ClfbNHuKhO
--HG--
extra : rebase_source : 17efe1e9f721324d6182db654e601727c791800b
This patch's reftests already pass, regardless of whether we have this bug's
fix, because the max-content size in the block axis is the same as the "auto" size
(which is what we were already using in this scenario). I'm just adding these reftests
for symmetry & completeness.
MozReview-Commit-ID: EOlrpnCxoby
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-003-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-004-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-003a.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-004a.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-003b.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-004b.html
extra : rebase_source : 93942d169018276040ef60450c8f8b17c75e0d12
Note: These tests fail in current mozilla-central (and hence are marked as
failing), but they start passing as of a patch later on in this series.
MozReview-Commit-ID: ElWJCl1ki0H
--HG--
extra : rebase_source : a5bdb9afae0a3bb902834d07c4c22783c8904104
With this commit, all the auto-dir scrolling functionalities are completed in
APZ.
MozReview-Commit-ID: L7qa3xOD8t9
--HG--
extra : rebase_source : bad2770219a0e6219f91899ab6c78e68f37195ac
