Created attachment 137958 [details] A simple demonstration of this bug. I first noticed this in gmail's gchat contact list. The scrollbar is only visible when your mouse hovers over the contact list. When your mouse exits the contact list, the contact list resets its scroll view. I've attached a reduction of this bug. r110046 is the last nightly build that works for me, and r110096 is the first that is broken. I dug through the commits in the 110046-110096 range, and it looks like 110072 is the most likely source of this bug.
Works fine for me on r114665. Can you still reproduce this problem on ToT?
What's ToT? Top of trunk? I spent a while trying to compile WebKit in both Linux and Windows to no avail. The latest version I've tested is r112531 from http://nightly.webkit.org/builds/trunk/win/1, which is admittedly pretty old. I know that this bug was present in r112531. (In reply to comment #1) > Works fine for me on r114665. Can you still reproduce this problem on ToT?
ToT is an acryonym for Top of Trunk, correct. Try the builds on http://nightly.webkit.org/ or a recent version of Chromium from http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html or http://tools.google.com/dlpage/chromesxs. I can't reproduce the problem myself so I am wondering if it's some difference in our machines or the way we are testing or if it's a problem that has already been fixed.
Just downloaded google canary, and it's working for me now, thanks. Sorry for the noise. Why are the windows builds of webkit on nightly.webkit.org so out of date (the most recent build (r112531) is from March 29)? If they were up to date, I wouldn't have created this bug =). (In reply to comment #3) > ToT is an acryonym for Top of Trunk, correct. Try the builds on http://nightly.webkit.org/ or a recent version of Chromium from http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html or http://tools.google.com/dlpage/chromesxs. I can't reproduce the problem myself so I am wondering if it's some difference in our machines or the way we are testing or if it's a problem that has already been fixed.
That I don't know - it's up to Apple and as I understand it the one guy who maintained the Apple Windows port left the company a few months back. But that's just idle speculation on my part :)
(In reply to comment #5) > That I don't know - it's up to Apple and as I understand it the one guy who maintained the Apple Windows port left the company a few months back. But that's just idle speculation on my part :) It's probably best not to speculate about things you don't have any insight in to. The Windows nightlies haven't been updated for a few weeks because a software update on the machine that builds them resulted in an error occurring during the packaging process for the Windows builds. Since the Mac nightlies were being posted correctly I didn't notice that anything was amiss. Now that I know I'll fix the issue.