979602 - position: sticky Some reftests render differently on chromium

Status: NEW

(Core :: Layout, defect, P4)

Description

[Viatcheslav Ostapenko]

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

Comment 1

[Daniel Holbert [:dholbert]]

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.

Comment 2

[Viatcheslav Ostapenko]

> 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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 4

[Viatcheslav Ostapenko]

> 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.

Comment 5

[:kip (Kearwood Gilbert)]

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

[:kip (Kearwood Gilbert)]

> 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.

Comment 7

[Viatcheslav Ostapenko]

(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

[:kip (Kearwood Gilbert)]

(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

[:kip (Kearwood Gilbert)]

(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

[Corey Ford [:coyotebush]]

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

[:kip (Kearwood Gilbert)]

> 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

[:kip (Kearwood Gilbert)]

> 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

[:kip (Kearwood Gilbert)]

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?

Comment 14

[Corey Ford [:coyotebush]]

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

[:kip (Kearwood Gilbert)]

No longer Blocking Bug 916315.  This bug has been kept open to track these inconsistencies.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yep, unblocking sounds fine.  It sounds like most of these are WebKit bugs, except for bug 975644 on our end.

Comment 17

[Viatcheslav Ostapenko]

(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

[Corey Ford [:coyotebush]]

(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.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.