_dragging=YES in BaseView after showing webmenu
Reported by
eugene...@yandex-team.ru,
Feb 28 2018
|
|||||||
Issue description
Chrome Version : 64.0.3282.168
OS Version: OS X 10.12.6
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari:
Firefox:
IE/Edge:
What steps will reproduce the problem?
1. Open URL: data:text/html,%3Cselect%3E%3Coption%3Ea%3Coption%3Eb
2. Click on combo box
3. Choose option
What is the expected result?
On showing webenu with mouse down, BaseView sets _dragging=yes, but after closing menu it returns to _dragging=NO state
What happens instead of that?
webmenu eats mouse up event, so after showing and closing it BaseView is still in _dragging=YES state.
Please provide any additional information below. Attach a screenshot if
possible.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.168 YaBrowser/18.3.1.435 (beta) Yowser/2.5 Safari/537.36
,
Mar 1 2018
Unable to reproduce the issue on mac 10.12.6 and win-10 using chrome reported version #64.0.3282.168, latest stable #64.0.3282.186 and latest canary #66.0.3357.0. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Opened URL: data:text/html,%3Cselect%3E%3Coption%3Ea%3Coption%3Eb 2. Clicked on combo box 3. Choose option 4. Observed that after closing menu it returns to _dragging=NO state as expected. eugenebng@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue on latest stable #64.0.3282.186 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Mar 1 2018
krajshree@, to detect this problem, it is necessary to add this DCHECK to code: https://chromium-review.googlesource.com/c/chromium/src/+/939477/7/ui/base/cocoa/base_view.mm and make debug (with DCHECKS) build with it. To make it more clear, extra step is needed: setp 4. Click anywhere in webcontent, that will cause DCHECK to fail. Without this DCHECK, although the variable in code has wrong value, I don't know the way to see the difference/exploit that in working browser. Sorry if this bug description caused some misunderstanding.
,
Mar 1 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 2 2018
> I don't know the way to see the difference/exploit that in working browser.
,
Mar 2 2018
[mac triage] Looks like there's a CL up for this, so moving to "Assigned" to get it out of the triage queue.
,
Aug 21
,
Aug 24
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by susan.boorgula@chromium.org
, Feb 28 2018