87023 2012-05-21 08:43:04 -0700 REGRESSION (r109837-109926): Issue displaying position:fixed elements in a scrolling page 2013-01-05 11:24:14 -0800 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Mac (Intel) OS X 10.7 RESOLVED WORKSFORME InRadar, Regression P1 Normal --- 1 j.zuckerman webkit-unassigned andersca ap enne jaeccles simon.fraser oldest_to_newest 629128 0 j.zuckerman 2012-05-21 08:43:04 -0700 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. 629279 1 ap 2012-05-21 11:06:25 -0700 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? 629283 2 j.zuckerman 2012-05-21 11:09:37 -0700 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. 629340 3 andersca 2012-05-21 11:55:30 -0700 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? 629374 4 j.zuckerman 2012-05-21 12:19:37 -0700 Just tested with r117796 and the issue still exists 629487 5 j.zuckerman 2012-05-21 14:20:25 -0700 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; } 630542 6 ap 2012-05-22 10:54:33 -0700 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? 630545 7 ap 2012-05-22 10:56:24 -0700 <rdar://problem/11506601> 630737 8 j.zuckerman 2012-05-22 14:10:45 -0700 Here is a testing URL: http://sandbox4.thismoment.com/cms/pagemaker?page_id=9 You can log in with the password "webkittest" 644666 9 j.zuckerman 2012-06-08 07:50:06 -0700 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? 644889 10 ap 2012-06-08 11:36:43 -0700 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. 644976 11 simon.fraser 2012-06-08 13:18:08 -0700 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. 685508 12 j.zuckerman 2012-08-02 09:52:18 -0700 Bump, issue is still present in 537+ I just checked the testing environment and it's still available with the password previously mentioned. 688406 13 j.zuckerman 2012-08-06 13:52:51 -0700 The current version of Safari now demonstrates this issue - Version 6.0 (7536.25) 800720 14 simon.fraser 2013-01-04 16:22:00 -0800 (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? 800723 15 simon.fraser 2013-01-04 16:23:39 -0800 Please could you also test a WebKit nightly build. We've changed how position:fixed works quite a bit. 800920 16 j.zuckerman 2013-01-05 07:47:58 -0800 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!) 800938 17 simon.fraser 2013-01-05 11:24:14 -0800 Good to know.