MacViews: ASYNC flag may be ignored for COMBOBOX and CONTEXT_MENU types. |
||||||||||||||||||||||||
Issue descriptionOn MacViews, the COMBOBOX and CONTEXT_MENU menu run types are generally shown using a native NSMenu which runs the run loop in NSEventTrackingRunLoopMode and blocks. Hence the ASYNC run type is ignored for these menu run types on MacViews.
,
Apr 12 2017
,
Oct 4 2017
All views menus are supposed to be async now (since 5ab7c2d09320aa6f4fc6ba0118908ac7e378e77b), but this doesn't seem to have any negative effects in practice. tapted@, do you think we can punt this until MacViews-Browser time? I'm speculatively tagging this MacViews-Browser.
,
Oct 4 2017
Yeah there's no such thing as an asynchronous NSMenu (maybe if we spawn a thread....?). So this isn't really "fixable" without phasing out NSMenu. It's just something to be wary of. But like you say, nothing seems to be unhappy about menus being blocking on Mac, but async elsewhere. (background: r466469 came about because menus on Android can never be blocking, but toolkit-views on Android is still ??).
,
Oct 16 2017
,
Mar 23 2018
MacViews triage: assigning to sdy@ as part of MacViews menu work. Let's target M67 for getting menus to do something sensible.
,
Mar 27 2018
As this is targeted for M67, pls have fix landed ASAP to trunk. Thank you
,
Mar 28 2018
ellyjones@: Over to you for assignment, unless I finish the compositing stuff and end up taking it back?
,
Mar 28 2018
lgrey@: This is relevant to you, too.
,
Mar 29 2018
** Bulk Edit ** There are only two M67 dev releases left on 04/03 & 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you.
,
Apr 3 2018
** Bulk Edit ** There is only one dev release left 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you. FYI: Change/Fix has to be landed in trunk latest by 4:00 PM PT, Friday (04/06) so we can pick it up for next week dev release.
,
Apr 6 2018
This change will be fixed by <https://chromium-review.googlesource.com/c/chromium/src/+/998016>, which switches these menus to use Views menus.
,
Apr 6 2018
,
Apr 13 2018
Tested the issue on latest chrome version 67.0.3396.0 using Mac 10.12.6 with steps mentioned below(checked as per comment# 12): 1) Launched chrome version and by enabling and disabling views-browser-windows flag from chrome://flags observed Three-dot menu, Combo box and Bookmarks bar 2) On enabling the views-browser-windows flag observed change in UI for the Three-dot menu, Combo box and Bookmarks bar @karandeepb: Please find the attached screenshots on enabling and Disabling of views-browser-windows flag for your reference and help us in verifying the fix. Thanks!
,
Apr 13 2018
The design change was deliberate and that looks as expected.
,
Apr 20 2018
The issue is fixed on the latest Canary 68.0.3401.0 on Mac OS 10.12.6 as per comment #14. By enabling #views-browser-windows flag, can observe Three-dot menu, Combo box and Bookmarks bar as attached in comment #14. Hence adding TE verified labels as the fix is working as intended. Thanks.. |
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 by bugdroid1@chromium.org
, Jan 20 2017