Bug 111278 – [chromium] Regression(143825): select elements don't open when there is a marquee on the page

• Component: Forms
• Status: RESOLVED FIXED

[Yair Yogev]

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...)

[Yair Yogev]

Created attachment 191147 [details]
offline version of the URL

[Yair Yogev]

Cross-posted at http://crbug.com/179736

[Alexey Proskuryakov]

Doesn't seem to reproduce with Mac port in Safari.

[Ojan Vafai]

Verified that it broke in the most recent Chrome dev channel release for Windows and Linux, but not for Mac.

[Ojan Vafai]

Created attachment 191564 [details]
reduced testcase

[Ojan Vafai]

WAT? Not sure how this is even possible.

[Ojan Vafai]

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

[Yair Yogev]

i posted that range in the first post
marquee... bizarre :)

[Ojan Vafai]

(In reply to comment #8)
> i posted that range in the first post

Ugh. I missed that. :(

[Ojan Vafai]

Manually bisected to http://trac.webkit.org/changeset/143825. 

Not sure how these are related. :(

[Ojan Vafai]

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.

[Ojan Vafai]

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.

[Ojan Vafai]

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).

[Yair Yogev]

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...)

[Kent Tamura]

*** Bug 112238 has been marked as a duplicate of this bug. ***

[Dominic Cooney]

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.

[Adam Barth]

I rolled out the patch that caused the regression in http://trac.webkit.org/changeset/146185.