Bug 111278 - [chromium] Regression(143825): select elements don't open when there is a marquee on the page
Summary: [chromium] Regression(143825): select elements don't open when there is a mar...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 112238 (view as bug list)
Depends on:
Blocks: 110673
  Show dependency treegraph
 
Reported: 2013-03-03 14:24 PST by Yair Yogev
Modified: 2013-03-19 00:59 PDT (History)
11 users (show)

See Also:


Attachments
screenshot (24.10 KB, image/jpeg)
2013-03-03 14:24 PST, Yair Yogev
no flags Details
offline version of the URL (961.84 KB, application/octet-stream)
2013-03-03 14:27 PST, Yair Yogev
no flags Details
reduced testcase (85 bytes, text/html)
2013-03-05 14:19 PST, Ojan Vafai
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yair Yogev 2013-03-03 14:24:42 PST
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...)
Comment 1 Yair Yogev 2013-03-03 14:27:04 PST
Created attachment 191147 [details]
offline version of the URL
Comment 2 Yair Yogev 2013-03-03 14:28:53 PST
Cross-posted at http://crbug.com/179736
Comment 3 Alexey Proskuryakov 2013-03-04 11:15:52 PST
Doesn't seem to reproduce with Mac port in Safari.
Comment 4 Ojan Vafai 2013-03-05 12:30:38 PST
Verified that it broke in the most recent Chrome dev channel release for Windows and Linux, but not for Mac.
Comment 5 Ojan Vafai 2013-03-05 14:19:12 PST
Created attachment 191564 [details]
reduced testcase
Comment 6 Ojan Vafai 2013-03-05 14:20:04 PST
WAT? Not sure how this is even possible.
Comment 8 Yair Yogev 2013-03-05 14:52:22 PST
i posted that range in the first post
marquee... bizarre :)
Comment 9 Ojan Vafai 2013-03-05 14:54:02 PST
(In reply to comment #8)
> i posted that range in the first post

Ugh. I missed that. :(
Comment 10 Ojan Vafai 2013-03-05 15:57:21 PST
Manually bisected to http://trac.webkit.org/changeset/143825. 

Not sure how these are related. :(
Comment 11 Ojan Vafai 2013-03-05 16:00:06 PST
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.
Comment 12 Ojan Vafai 2013-03-05 16:08:37 PST
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.
Comment 13 Ojan Vafai 2013-03-05 16:17:21 PST
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).
Comment 14 Yair Yogev 2013-03-05 16:20:22 PST
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...)
Comment 15 Kent Tamura 2013-03-17 20:16:56 PDT
*** Bug 112238 has been marked as a duplicate of this bug. ***
Comment 16 Dominic Cooney 2013-03-18 23:45:30 PDT
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.
Comment 17 Adam Barth 2013-03-19 00:59:52 PDT
I rolled out the patch that caused the regression in http://trac.webkit.org/changeset/146185.