Original display changes don't trigger reflow, even though they affect the hypothetical position of an element.
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | fixed |
People
(Reporter: timdream, Assigned: emilio)
References
Details
Attachments
(4 files)
Steps To Reproduce:
- Load the test case
- Observe that the position of the SVG triangle is diffferent even though the DOM+CSS state is exactly the same.
- Trigger layout by change the window width.
- Observe that the SVGs on case #2 and #4 is misplaced again.
Notes:
There are two bugs here.
First, svg is set to display: block in the UA sheet; setting the property to the same value shouldn’t hav any effect but apparently it does. It was also not being placed correctly — the position of a block element inside another block element shouldn’t be affected by the |text-align| property.
Second: unset the “no-op” value should restore the layout but it did not until re-layout.
|
Reporter | |
Comment 1•5 years ago
|
||
Also filed https://bugs.chromium.org/p/chromium/issues/detail?id=972843 and on WebKit.
|
Assignee | |
Comment 2•5 years ago
|
||
First, svg is set to display: block in the UA sheet; setting the property to the same value shouldn’t hav any effect but apparently it does.
This is not true, what makes you think this?
<svg>s are inlines, they just become blocks when absolutely positioned because absolute position blockifies, see this css 2 section.
Thus the display value on the element style is not really a no-op, since the original (inline) position pre-abspos is used to compute the hypothetical position. That's also per spec, though CSS2 is a mess in terms of defining the actual hypothetical position.
It was also not being placed correctly — the position of a block element inside another block element shouldn’t be affected by the |text-align| property.
It actually is, since it's position is determined by the static inline position. It's not a chance that all browsers do the same here. If you specify a combination of positions using top / right / bottom / left, then the hypothetical box is not needed and the element is not affected by text-align.
So there's an issue with the hypothetical position not being correctly recomputed, which is your test-case #2, but the rest is working per spec. Now how sane is the spec is a different matter :)
|
|
Assignee | |
Comment 3•5 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #1)
Also filed https://bugs.chromium.org/p/chromium/issues/detail?id=972843 and on WebKit.
Is this missing a link to the WebKit bug?
|
|
Assignee | |
Comment 4•5 years ago
|
||
So basically, this comparison of mOriginalDisplay should trigger something more than a NeutralChange, since the hypothetical position depends on it:
But other than that this is working as specified.
|
|
Assignee | |
Comment 5•5 years ago
|
||
Morphing to cover that.
I suspect nsStyleDisplay::CalcDifference needs to do something more interesting (i.e., not nsChangeHint_NeutralChange, likely reflow) with mOriginalDisplay and mOriginalFloat -- probably conditional on mPosition being absolute.
|
|
Assignee | |
Comment 7•5 years ago
|
||
|
|
Assignee | |
Comment 8•5 years ago
|
||
(In reply to David Baron :dbaron: 🏴 ⌚UTC-7 from comment #6)
I suspect
nsStyleDisplay::CalcDifferenceneeds to do something more interesting (i.e., notnsChangeHint_NeutralChange, likely reflow) withmOriginalDisplayandmOriginalFloat-- probably conditional onmPositionbeing absolute.
Right. mOriginalFloat actually doesn't, and it's unused. But yeah, that's exactly what I meant in comment 4 :)
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 9•5 years ago
|
||
The original float is not needed for layout, and thus there's no need to keep it
around.
This was presumably used by the old style system, but now it doesn't seem
useful, and is always none.
|
|
Assignee | |
Comment 10•5 years ago
|
||
Depends on D34442
|
||
Comment 11•5 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d93982f48472 Remove unused nsStyleDisplay::mOriginalFloat. r=dbaron https://hg.mozilla.org/integration/autoland/rev/614615b9c8ab Should update layout when the hypothetical display of an element changes, even though the final computed display doesn't. r=dbaron
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/17264 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
| Comment hidden (offtopic) |
| Comment hidden (offtopic) |
|
|
Reporter | |
Comment 16•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
First, svg is set to display: block in the UA sheet; setting the property to the same value shouldn’t hav any effect but apparently it does.
This is not true, what makes you think this?
<svg>s are inlines, they just become blocks when absolutely positioned because absolute position blockifies, see this css 2 section.Thus the
displayvalue on the element style is not really a no-op, since the original (inline) position pre-abspos is used to compute the hypothetical position. That's also per spec, though CSS2 is a mess in terms of defining the actual hypothetical position.
Hum. Thanks for the quick turnaround! I saw the display: block shown as the computed value in DevTools. It turned out it was caused by position: absolute.
data:text/html,<style>svg { position: absolute }</style><svg></svg><script>window.onload = () => alert(window.getComputedStyle(document.body.firstChild).display)</script>
|
||
Comment 17•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/d93982f48472
https://hg.mozilla.org/mozilla-central/rev/614615b9c8ab
Upstream PR merged
|
|
Reporter | |
Comment 19•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Is this missing a link to the WebKit bug?
Description
•