Resolution is at:
* https://github.com/w3c/csswg-drafts/issues/3779#issuecomment-481762912
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974,
I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element
is styled _before_ calling UpdateViewportScrollStylesOverride(). This saves
duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a `display: none` subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none
subtree case (since we ensure the unstyled case isn't hit by styling the
document earlier). But that case is one of the cases we're interested in
changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
--HG--
extra : moz-landing-system : lando
Return a raw pointer instead of a strong reference to a ComputedStyle, and
handle the case of the style not being present by returning null rather than
requiring an extra function to check it and crashing if the precondition is not
met.
Also, name them so that it's clear they just return outdated styles and don't
make any extra effort.
This is just cleanup that makes the next patch easier / more obvious.
Differential Revision: https://phabricator.services.mozilla.com/D40080
--HG--
extra : moz-landing-system : lando
This is mostly straight-forward cleanup, but there's a behavior change which
was an oversight from bug 1386840, the regular mObservers stuff didn't pass the
right thing (was passing only mWasAlternate rather than whether it was
deferred).
I think that as a result, only in XML documents (since nsXMLContentSink is the
only thing that adds itself as a global CSS loader observer that ever looks at
this boolean), we may end up breaking this assert:
https://searchfox.org/mozilla-central/rev/9ae20497229225cb3fa729a787791f424ff8087b/dom/base/nsContentSink.cpp#183
(If there are any sheets with non-matching media queries and such).
But I couldn't find a test-case that broke it (tried SVG / XHTML), and in other
documents like pure XML you cannot specify a media query...
Differential Revision: https://phabricator.services.mozilla.com/D41091
--HG--
extra : moz-landing-system : lando
Saving a refcount bump is not worth the churn. Use a proper RefPtr<>
everywhere instead of manual refcounting, and don't make DoSheetComplete call
NS_RELEASE unconditionally.
Also, make clear by using references where null is expected or not.
Also, properly use a RefPtr in mPendingDatas, since they are strong pointers,
in fact.
Finally, remove some unused macros from nsCSSValue of which this code was the
last consumer.
Differential Revision: https://phabricator.services.mozilla.com/D41090
--HG--
extra : moz-landing-system : lando
They're bad, specially if they do vastly different thing in overloaded
functions, like aUseSystemPrincipal and aIsPreload. :)
Differential Revision: https://phabricator.services.mozilla.com/D40851
--HG--
extra : moz-landing-system : lando
Just moving code around but hopefully the new code is nicer :)
Also fix a regression I introduced in D40691 where the parsing mode wouldn't be
checked for XUL sheets.
Differential Revision: https://phabricator.services.mozilla.com/D40692
--HG--
extra : moz-landing-system : lando
The current code needs to handle incomplete draws already due to async decoding,
and this prevents the race condition where we paint between the size-available
and load notifications, as the CSS image loader only invalidates for the first.
Once we try to decode the image at least once, then we'd repaint properly from
ImageLoader::OnFrameComplete.
Differential Revision: https://phabricator.services.mozilla.com/D41006
--HG--
extra : moz-landing-system : lando
So the issue here is that this test-case has a zero-sized border, but still with
a border-image (which we should paint).
So the first time we get here, the image is not loaded, and thus we don't get
here:
https://searchfox.org/mozilla-central/rev/e0b0c38ee83f99d3cf868bad525ace4a395039f1/layout/painting/nsDisplayList.h#4254
Which means that we end up with zero bounds and thus we don't even get to the
border painting code.
However, when the image loads, we get to MarkNeedsDisplayItemRebuild(), but that
doesn't schedule any paint, only marks the frames as modified in order for
display items to be rebuilt _eventually_.
Thus eventually, where we force a repaint by other means, we paint correctly.
This only works in more general cases because we get to the nsImageRenderer code
which does vastly different stuff.
InvalidateFrame() seems to do the right thing and schedule a paint, so use it.
It's not clear to me which one of nsIFrame::InvalidateFrame() or
nsIFrame::SchedulePaint() we should use...
If I understand correctly, InvalidateFrame() will only do something iff there
are display items for the frame, so that should make the IsVisible() check
redundant.
Note however that I think there's still a race condition, if we get to paint in
between the SIZE_AVAILABLE notification (the one where we actually invalidate
the display items), and the LOAD notification (the one the border-image code
checks).
I'll send a separate patch for that, I think SIZE_AVAILABLE should be a
strong-enough hint and that allows us to remove nsStyleImage::IsLoaded()...
The RequestReflow stuff also looks highly suspicious... shape-outside
sync-decodes, and it seems we could end up invalidating reflow from the reflow
code...
Differential Revision: https://phabricator.services.mozilla.com/D41005
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/22
* mathml/relations/css-styling/attribute-mapping-001.html (length, dir)
* mathml/relations/html5-tree/display-1.html (display)
* mathml/relations/css-styling/displaystyle-1.html (displaystyle)
* mathml/relations/css-styling/displaystyle-2.html (displaystyle)
* mathml/relations/css-styling/mathvariant-case-sensitivity.html (mathvariant)
layout/reftests/bugs/355548-3.xml has been updated now that units are case
insensitive.
Note:
* mathml/relations/css-styling/attribute-mapping-002.html also checks
case insensitiveness of mathvariant and displaystyle but for now we map
these attributes to internal -moz-* CSS properties.
* mathcolor and mathbackground values are already case insensitive, this
is verified by mathml/relations/css-styling/attribute-mapping-001.html
Differential Revision: https://phabricator.services.mozilla.com/D42081
--HG--
extra : moz-landing-system : lando
This patch is auto-generated by the following command:
./mach clang-format -p layout/
Differential Revision: https://phabricator.services.mozilla.com/D42218
--HG--
extra : moz-landing-system : lando
The fuzzy-if added in bug 1508177 should have added to the test in
css-ui-invalid/ not the test in css-ui-valid/.
Differential Revision: https://phabricator.services.mozilla.com/D42072
--HG--
extra : moz-landing-system : lando
Run broken-column-rule-1.html with column-span enabled because it was
regressed by Bug 1548100 Part 2, but fixed by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D41907
--HG--
extra : moz-landing-system : lando
We always pass consumed block-size into BlockReflowInput's constructor
in nsBlockFrame::Reflow(). By making mConsumedBSize a constant, its
assessor method becomes redundant.
Update the documentation to reflect the reality that ConsumedBSize()
accumulates content block-size from all previous *continuations*, which
was done in Bug 1506293 Part 2.
Differential Revision: https://phabricator.services.mozilla.com/D41906
--HG--
extra : moz-landing-system : lando
We do have test coverage for this
(layout/style/test/test_visited_reftests.html), but it seems that that uses
snapshotWindow() / drawWindow() and that may not use the WR code paths? It seems
we may be missing a bit of test coverage there. Is this expected?
Differential Revision: https://phabricator.services.mozilla.com/D41935
--HG--
extra : moz-landing-system : lando
ComputedStyle* aComputedStyle doesn't provide any extra value over just aStyle.
Lots of these should be const and what not, oh well.
Differential Revision: https://phabricator.services.mozilla.com/D41933
--HG--
extra : moz-landing-system : lando
(This basically addresses the review comments that I missed in
bug 1105868 part 4. My bad.)
Differential Revision: https://phabricator.services.mozilla.com/D42134
--HG--
extra : moz-landing-system : lando
Intent email: https://groups.google.com/d/msg/mozilla.dev.platform/1NP6oJzK6zg/ftAz_TajAAAJ
For now do the obvious check rather than bigger refactorings, since we keep them
matching :link or not depending on whether they have an href.
I'll file an HTML spec issue about not making them traversable, and a MathML
issue about the craziness that it is that almost all MathML elements can be
links.
Differential Revision: https://phabricator.services.mozilla.com/D41269
--HG--
extra : moz-landing-system : lando
The counting code was incrementing the start counter twice for <li value>, as it
generates both an increment and a reset.
We should instead only increment it once per list-item, that is, once per
increment.
Differential Revision: https://phabricator.services.mozilla.com/D42001
--HG--
extra : moz-landing-system : lando
This fixes it and seems to be an acceptable fix... Should I make it conditional
on box-sizing: border-box for completeness? The display frame has border-box
box-sizing, and not having it would be a bug, I'd think...
Differential Revision: https://phabricator.services.mozilla.com/D41939
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Mats Palmgren
Frédéric Wang
Nicholas Nethercote
Daniel Holbert
Noemi Erli
Hiroyuki Ikezoe
Ting-Yu Lin
Mihai Alexandru Michis
Brindusan Cristian
Bogdan Tara