Open
Bug 979602
Opened 11 years ago
Updated 2 years ago
position: sticky Some reftests render differently on chromium
Categories
(Core :: Layout, defect, P4)
Tracking
()
NEW
People
(Reporter: ostap73, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131206145537 Steps to reproduce: Get mozilla ref tests from mozilla sources (layout/reftests/position-sticky) , do renaming (*-ref.html to *-expected.html) and run as chromium layout tests. Actual results: Some tests render differently and fail on chromium: block-in-inline-2.html block-in-inline-3.html column-contain-2.html inline-2.html inline-3.html inner-table-1.html overconstrained-1.html overconstrained-2.html overconstrained-3.html padding-3.html
Updated•11 years ago
|
Component: Untriaged → Layout
Product: Firefox → Core
Comment 1•11 years ago
|
||
The most likely explanation may be that these are simply bugs in chromium (in part because their implementation is from before there was much of a spec for this feature, I believe). Probably worth going through these tests to make sure that's the case, though.
Reporter | ||
Comment 2•11 years ago
|
||
> Probably worth going through these tests to make sure that's the case, though. Yes, that's what I'm going to do. At least for chromium. This bug is for tracking this issue. Related chromium bug is here: http://code.google.com/p/chromium/issues/detail?id=349193
Comment 3•11 years ago
|
||
Probably worth going through the tests and figuring out which behavior makes more sense for each. I presume you also changed 'sticky' to '-webkit-sticky'? Or does chromium support it unprefixed?
Reporter | ||
Comment 4•11 years ago
|
||
> I presume you also changed 'sticky' to '-webkit-sticky'? Or does chromium support it unprefixed?
Chromium has it unpreffixed, but require --enable-experimental-web-platform-features switch.
Updated•11 years ago
|
Summary: position: sticky Some ref tests render differently on chromium. → position: sticky Some reftests render differently on chromium
Updated•11 years ago
|
Priority: -- → P4
Updated•11 years ago
|
Assignee: nobody → kgilbert
Comment 5•11 years ago
|
||
Bug 979602 I have added -webkit-sticky as needed to enable sticky in Safari, and performed some comparisons of these retests between Chromium, Safari, and FF: block-in-inline-2.html - FF Matches reference - Chromium and Safari render same output, do not match FF - Chromium and Safari behave as if inline sticky elements are not sticky block-in-inline-3.html - FF Matches reference - Chromium and Safari render same output, do not match FF - Chromium and Safari behave as if inline sticky elements are not sticky column-contain-2.html - FF Matches reference - (Chromium and Safari require -webkit-column-count and -webkit-column-rule rather than -moz-column-count and -moz-column-rule) - Chromium and Safari render same output, do not match FF - Sticky element behaves as sticky; however, is displayed, cropped at the bottom of the second column rather than the first. inline-2.html - FF Matches reference - Safari translates sticky text 1 pixel lower than FF - Chromium translates sticky text 2 pixels lower than FF - Adding borders to the sticky and the scroll container resulted in the same distance between the borders in all browsers. - Failure of retest appears to be related to differences in font rendering inline-3.html - FF, Chrome, and Safari did not match reference on OSX 10.9 (Test is disabled for OSX 10.9 in reftest.list) - FF Render matched Safari render - Chrome had a 1px offset in rendered sticky text compared to FF, possibly due to font rendering differences. inner-table-1.html - FF Matches reference - FF, Chrome, and Safari each rendered a different result - Result from FF is expected to be incorrect until Bug 35168 is corrected overconstrained-1.html - FF Matches reference - Chromium and Safari render same output, do not match FF - Increasing height of #scroll from 100px to 101px results in output that matches Chromium and Safari - When over constrained, the sticky element is acting as though it is not sticky, while in Chromium and Safari, it remains sticky overconstrained-2.html - FF Matches reference - Chromium and Safari render same output, do not match FF - Increasing width of #scroll from 100px to 101px results in output that matches Chromium and Safari - When over constrained, the sticky element is acting as though it is not sticky, while in Chromium and Safari, it remains sticky overconstrained-3.html - FF Matches reference - Chromium and Safari render same output, do not match FF padding-3.html - FF Matches reference - Chromium and Safari render same output, do not match FF
Comment 6•11 years ago
|
||
> overconstrained-1.html
> overconstrained-2.html
> overconstrained-3.html
FF and Webkit match in output in these cases until the sizes are increased to trigger the overconstrained scenario. In these cases, there is a difference in how FF and Webkit interpret overconstrained left+right or top+bottom for sticky positioned elements:
FF is choosing to ignore one of the pair (Top takes precedence for top+bottom overconstraint, Left takes precedence for a left+right overconstraint with LTR layout, and Right takes precedence for a left+right overconstraint with RTL layout.
Webkit is keeping all offsets enabled for the sticky positioning.
I am investigating deeper to further understand the webkit behavior when overconstrained.
Reporter | ||
Comment 7•11 years ago
|
||
(In reply to :kip (Kearwood Gilbert) from comment #6) > > overconstrained-1.html > > overconstrained-2.html > > overconstrained-3.html > > FF and Webkit match in output in these cases until the sizes are increased > to trigger the overconstrained scenario. In these cases, there is a > difference in how FF and Webkit interpret overconstrained left+right or > top+bottom for sticky positioned elements: > > FF is choosing to ignore one of the pair (Top takes precedence for > top+bottom overconstraint, Left takes precedence for a left+right > overconstraint with LTR layout, and Right takes precedence for a left+right > overconstraint with RTL layout. > > Webkit is keeping all offsets enabled for the sticky positioning. > > I am investigating deeper to further understand the webkit behavior when > overconstrained. Thanks a lot for investigating this. Do you think LTR/RTL difference in precedence for overconstrained should be added to the specification?
Comment 8•11 years ago
|
||
(In reply to :kip (Kearwood Gilbert) from comment #6) > > overconstrained-1.html > > overconstrained-2.html > > overconstrained-3.html > > FF and Webkit match in output in these cases until the sizes are increased > to trigger the overconstrained scenario. In these cases, there is a > difference in how FF and Webkit interpret overconstrained left+right or > top+bottom for sticky positioned elements: > > FF is choosing to ignore one of the pair (Top takes precedence for > top+bottom overconstraint, Left takes precedence for a left+right > overconstraint with LTR layout, and Right takes precedence for a left+right > overconstraint with RTL layout. > > Webkit is keeping all offsets enabled for the sticky positioning. > > I am investigating deeper to further understand the webkit behavior when > overconstrained. The webkit behavior appears to lerp between the positions expected if each corresponding left+right or top+bottom values are ignored as the scroll offset changes. This appears to be captured in a webkit bug: https://bugs.webkit.org/show_bug.cgi?id=118161
Comment 9•11 years ago
|
||
(In reply to Viatcheslav Ostapenko from comment #7) > (In reply to :kip (Kearwood Gilbert) from comment #6) > > > overconstrained-1.html > > > overconstrained-2.html > > > overconstrained-3.html > > > > FF and Webkit match in output in these cases until the sizes are increased > > to trigger the overconstrained scenario. In these cases, there is a > > difference in how FF and Webkit interpret overconstrained left+right or > > top+bottom for sticky positioned elements: > > > > FF is choosing to ignore one of the pair (Top takes precedence for > > top+bottom overconstraint, Left takes precedence for a left+right > > overconstraint with LTR layout, and Right takes precedence for a left+right > > overconstraint with RTL layout. > > > > Webkit is keeping all offsets enabled for the sticky positioning. > > > > I am investigating deeper to further understand the webkit behavior when > > overconstrained. > > Thanks a lot for investigating this. > Do you think LTR/RTL difference in precedence for overconstrained should be > added to the specification? IMHO, This seems to be important for the specification. As sticky positioning is related to relative positioning, this behavior has descended from there: http://www.w3.org/TR/CSS21/visuren.html#relative-positioning "If neither 'left' nor 'right' is 'auto', the position is over-constrained, and one of them has to be ignored. If the 'direction' property of the containing block is 'ltr', the value of 'left' wins and 'right' becomes -'left'. If 'direction' of the containing block is 'rtl', 'right' wins and 'left' is ignored." For sticky positioned elements, this behavior is subtly different -- sticky elements are only considered to be over-constrained when the sum of the element's size and its offsets are greater than the content box of the scroll area.
Comment 10•11 years ago
|
||
The over-constrained behavior is something I made up (based on the relpos behavior) and included in my spec ideas: https://etherpad.mozilla.org/yqbijwrHI6 I noted WebKit's behavior on www-style: http://lists.w3.org/Archives/Public/www-style/2013Jun/0675.html
Comment 11•11 years ago
|
||
> padding-3.html
> - FF Matches reference
> - Chromium and Safari render same output, do not match FF
In this case, it appears that WebKit Nightly has corrected an issue with the sticky offset disregarding the scroll container padding.
The vertical position of the sticky element still differs between FF and WebKit; however, it appears that FF's behavior is more consistent in this case.
Comment 12•11 years ago
|
||
> I noted WebKit's behavior on www-style:
> http://lists.w3.org/Archives/Public/www-style/2013Jun/0675.html
Your description and example file match the behavior I am seeing with the overconstrained-1.html, overconstrained-2.html, and overconstrained-3.html reftests.
Comment 13•11 years ago
|
||
In all of these cases it appears that FF is behaving consistently. The differences seen in the reftests with WebKit are either captured by existing bugs or perhaps would be edge cases that would be reasonably spec'ed as "undefined behavior". Can this bug be removed as a dependency of Bug 916315 and/or be closed?
Flags: needinfo?(dbaron)
Comment 14•11 years ago
|
||
Overall, I think these are cases where I guessed that WebKit's behavior wasn't necessarily intentional, and chose to deviate from it in our implementation. It might or might not be useful to keep this bug open for tracking these inconsistencies. But in any case this doesn't need to block bug 916315.
Comment 15•11 years ago
|
||
No longer Blocking Bug 916315. This bug has been kept open to track these inconsistencies.
Comment 16•11 years ago
|
||
Yep, unblocking sounds fine. It sounds like most of these are WebKit bugs, except for bug 975644 on our end.
Flags: needinfo?(dbaron)
Reporter | ||
Comment 17•11 years ago
|
||
(In reply to Corey Ford [:corey] from comment #10) > The over-constrained behavior is something I made up (based on the relpos > behavior) and included in my spec ideas: > https://etherpad.mozilla.org/yqbijwrHI6 > I noted WebKit's behavior on www-style: > http://lists.w3.org/Archives/Public/www-style/2013Jun/0675.html Corey, thank you for your clarification. During my chromium patch review Julien have suggested that it would be logical to take into acount vertical wrting mode similar how it is done for horizontally over-constrained behavior: https://codereview.chromium.org/267063007/#msg2 What do you think?
Comment 18•11 years ago
|
||
(In reply to Viatcheslav Ostapenko from comment #17) > During my chromium patch review Julien have suggested that it would be > logical to take into acount vertical wrting mode similar how it is done for > horizontally over-constrained behavior: That sounds reasonable. I agree with you that such behavior should be consistent with position:relative, so it's worth raising the issue with the CSSWG.
Updated•6 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 19•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: kearwood → nobody
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•