Created attachment 191146 [details] screenshot Some select elements close immediately in Chromium recently. 1. Visit the following URL http://www.tapuz.co.il/forums2008/forumpage.aspx?forumid=1789&r=1 2. Try to Open the select element in the screenshot (it's in the left part of the page, might need to first scroll a little) 3. It won't open, or more precisely- open for some fraction of a second. Regression Window: OK: Chromium 27.0.1422.0 (Developer Build 184339) OS Windows 7 WebKit 537.32 (@143784) JavaScript V8 3.17.2 FAIL: Chromium 27.0.1422.0 (Developer Build 184341) OS Windows 7 WebKit 537.32 (@143855) Relevant Chromium changelog: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Ftrunk%2Fsrc&range=184340%3A184341&mode=html which means this is probably due to the WebKit roll 143784:143855 relevant WebKit Changelog: http://trac.webkit.org/log/?rev=143855&stop_rev=143785&verbose=on I only tested Chromium and only under Windows 7 (but other platforms might also be affected...)
Created attachment 191147 [details] offline version of the URL
Cross-posted at http://crbug.com/179736
Doesn't seem to reproduce with Mac port in Safari.
Verified that it broke in the most recent Chrome dev channel release for Windows and Linux, but not for Mac.
Created attachment 191564 [details] reduced testcase
WAT? Not sure how this is even possible.
Bisected chromium archives. WebKit regression range: http://trac.webkit.org/log/trunk/?rev=143855&stop_rev=143784&verbose=on Chromium regression range: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=184340%3A184341
i posted that range in the first post marquee... bizarre :)
(In reply to comment #8) > i posted that range in the first post Ugh. I missed that. :(
Manually bisected to http://trac.webkit.org/changeset/143825. Not sure how these are related. :(
Is http://trac.webkit.org/changeset/143825 correct? I'm not too familiar with these APIs, but scrolling in a layer (e.g. in a marquee) doesn't necessarily mean that the frame scrolled.
Half-related: it looks like Chrome on Linux/Windows closes the popup when you scroll instead of disallowing scroll. That specific behavior is definitely a Chrome bug, but it's still not clear to me that http://trac.webkit.org/changeset/143825 is a correct change.
Incidentally, if there's a programmatic scroll while the popup is open, Chrome and Safari on Mac will scroll the page, but leave the popup open in its old location (i.e. no longer below the select element).
about disallowing scroll in chromium- looks like Firefox doesn't disallow either. i find it better myself, I don't like "blocking" behaviors... (IE does block, which means you have to first close the open popup before using the scroll wheel to scroll the page...)
*** Bug 112238 has been marked as a duplicate of this bug. ***
I think revision 143825 is incorrect and should be rolled out. The descriptions of r143825/bug 110673 are of the effect that when scrolling pages like <http://instagram.com/p/UrCCIVBQX3/>, FrameViewClient::didChangeScrollOffset() should be called. I think that there are two problems with r143825: 1. Although the desired state (call didChangeScrollOffset for scrolls of body with overflow: hidden) is relatively specific, the change is not. It generates calls to didChangeScrollOffset for all kinds of scrolls. For example, on the Instagram page there is a sub-widget containing comments ("Hockey is slick", etc.) and after r143825, scrolling that widget also results in calls to didChangeScrollOffset. So the effect of the change seems overly broad compared to the stated effect the change is trying to achieve. 2. It is not clear to me that even in the case of the Instagram page, didChangeScrollOffset should be called. The reason is that page is structured with a body with height: 100% and overflow: hidden, and then a div with height: 100% and overflow: auto. As a result the scrollbar belongs to the div, and it is the div that is being scrolled and not the view. Since the frame's scroll offset is (0, 0) and is not changing, it doesn't seem correct to call didChangeScrollOffset. The scroll offset did not change.
I rolled out the patch that caused the regression in http://trac.webkit.org/changeset/146185.