RESOLVED WORKSFORME84374
REGRESSION(r110046-r110096): Setting overflow: hidden resets scrollbar at gmail.com 
https://bugs.webkit.org/show_bug.cgi?id=84374
Summary REGRESSION(r110046-r110096): Setting overflow: hidden resets scrollbar at gma...
Jeremy Fleischman
Reported 2012-04-19 13:14:58 PDT
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.
Attachments
A simple demonstration of this bug. (790 bytes, text/html)
2012-04-19 13:14 PDT, Jeremy Fleischman 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
James Robinson
Comment 1 2012-04-19 14:14:32 PDT
Works fine for me on r114665. Can you still reproduce this problem on ToT?
Jeremy Fleischman
Comment 2 2012-04-19 14:20:55 PDT
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?
James Robinson
Comment 3 2012-04-19 16:09:30 PDT
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.
Jeremy Fleischman
Comment 4 2012-04-19 16:52:52 PDT
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.
James Robinson
Comment 5 2012-04-19 17:09:35 PDT
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 :)
Mark Rowe (bdash)
Comment 6 2012-04-19 22:17:17 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.