Bug 87023 – REGRESSION (r109837-109926): Issue displaying position:fixed elements in a scrolling page

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: CSS

[Jonathan Zuckerman]

After scrolling the page it takes a few moments and sometimes a hover event for the browser to paint a fixed element in its correct location.  When I scroll back up the page all the "old" positions of the fixed element relative to the document are still there..

I am not able to provide a link because the page I noticed the issue on is an internal CMS gated by a password, but here is a video showing the issue:

http://youtu.be/8GtxF_4znzs

If getting access to the page would help you debug the issue please let me know, I can see about getting a testing site set up.

[Alexey Proskuryakov]

Thank you for the report. Yes, a test page would be very helpful.

It is very surprising if position:fixed behaves this way. Are you seeing this with shipping Safari 5.1.x, or only in nightlies?

[Jonathan Zuckerman]

Only in the WebKit nightly, I just tested it in Safari 5.1.7 (7534.57.2) and do not observe the issue.  I will see about getting a page for you to test.

[Anders Carlsson]

I wonder if this is the same bug as https://bugs.webkit.org/show_bug.cgi?id=86934

Jonathan, can you try a nightly from today and see if the bug is still there?

[Jonathan Zuckerman]

Just tested with r117796 and the issue still exists

[Jonathan Zuckerman]

I actually just found another example of what I believe may be the same issue, which does not have to do with position:fixed.
I created a css style for a radio input that is checked, so when you select one option, all the other options get deselected, and therefore need that style removed.  But, in WebKit nightly it doesn't update the other radio buttons by removing the :checked style until you hover over them, is it possible that there's some repaint/reflow optimization that is over-zealously not repainting things?

The same issue does not occur in the current stable release of Safari.


Steps to reproduce:

1. load this URI in WebKit nightly (I am using r117796):
   http://dev.brokendisk.com/jon-and-jenny/rsvp/webkit-issue?secret=repaint
2. click the unchecked radio input
3. observe that the now-checked radio button does not display the proper styles until you hover away from it.
4. observe also that the now-UNchecked radio button does not have the style removed until it is hovered over.


This is the CSS rule, incidentally:

.guest input[type="radio"]:checked + span.option {
    font-weight: 700;
}

[Alexey Proskuryakov]

Thank you! Simon and myself looked at this test, and it's not obvious to us that this is the same issue as the one on the video. I filed bug 87146 about the new issue, we can always dupe it back later if we decide that it's the same thing.

Could you bisect with WebKit nightlies to find out when exactly the issue on the internal site started?

[Alexey Proskuryakov]

<rdar://problem/11506601>

[Jonathan Zuckerman]

Here is a testing URL: http://sandbox4.thismoment.com/cms/pagemaker?page_id=9

You can log in with the password "webkittest"

[Jonathan Zuckerman]

I saw your request about bisecting with nightlies but I'm not sure how to do that.. I saw this page but it only goes back so far: 

http://nightly.webkit.org/builds/trunk/mac/1

Do you want me to just try each successively older build until I can find one where the issue no longer manifests?

[Alexey Proskuryakov]

Sorry, I overlooked your comment where you provided a test page. Bisected it myself, unfortunately it's a long range: <http://trac.webkit.org/log/trunk/?rev=109926&stop_rev=109837>. Simon, does anything stand out to you?

> I saw this page but it only goes back so far: 

There are links to older ranges at the bottom of the page, so it goes back pretty far (most of historic builds are so old that they don't work with Safari 5.1.x at all).

> Do you want me to just try each successively older build until I can find one where the issue no longer manifests?

The idea is to try older builds, and there is a more efficient way to do this. If you can find a revision that shows the bug and one that doesn't, you can then try one in the middle, and immediately cut the range in half.

[Simon Fraser (smfr)]

I would guess either
http://trac.webkit.org/changeset/109867/
or more likely
http://trac.webkit.org/changeset/109851/

See also bug 88129 and bug 64201.

[Jonathan Zuckerman]

Bump, issue is still present in 537+

I just checked the testing environment and it's still available with the password previously mentioned.

[Jonathan Zuckerman]

The current version of Safari now demonstrates this issue - Version 6.0 (7536.25)

[Simon Fraser (smfr)]

(In reply to comment #12)
> Bump, issue is still present in 537+
> 
> I just checked the testing environment and it's still available with the password previously mentioned.

And what email address?

[Simon Fraser (smfr)]

Please could you also test a WebKit nightly build. We've changed how position:fixed works quite a bit.

[Jonathan Zuckerman]

Ah - our authentication methods have changed since we created this bug - I'll see about getting you a login for this environment now.

For what it's worth the issue is not present in nightly Version 6.0.2 (8536.26.17, 537+)

(stoked!)

[Simon Fraser (smfr)]

Good to know.