New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 688934 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
nyerramilli@chromium.org
tapted@chromium.org
pkasting@chromium.org
█ msrchandra@chromium.org
bettes@chromium.org
█ ranjitkan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug


Participants' hotlists:
MacViews-Task-Queue


Sign in to add a comment

Weird behaviour of ’Ask Google for Suggestion’ dialog box is seen while clicking on Learn more link.

Reported by dmascare...@etouch.net, Feb 6 2017 
Chrome Version:58.0.3004.0 (Official Build)604a36b20d9ffe65380031f3f708d859d81f71be-refs/heads/master@{#448183}
OS: Mac (10.11.6,10.12.1)

Pre-condition: Enable ‘#secondary-ui-md’ flag

What steps will reproduce the problem?
1. Launch chrome and navigate to http://textarea.org/
2. Enter any word (fdgdgfdf) ,right click on the word such that context menu gets pen and select Ask Google for Suggestion option.
3. Click on ‘Learn more’ link and observe.

Actual: Animation of ‘Ask Google for Suggestion’ dialog box is seen another tab.
Expected: Animation of ‘Ask Google for Suggestion’ dialog box should not be seen on another tab.

This is non-regression issue, seen from ‘M 58’(58.0.3000.4)newly added feature.

Note:Issue is not seen on Windows and Linux OS.
Actual.mov
4.5 MB Download
Exp.mov
1.4 MB Download

Comment 1 by tapted@chromium.org, Feb 6 2017

Cc: pkasting@chromium.org bettes@chromium.org
Components: -Blink>HTML>Dialog UI>Browser>Spellcheck
Labels: -Pri-2 Proj-HarmonyDialogs Proj-MacViews Pri-3
Status: Available (was: Unconfirmed)
This is because ’Ask Google for Suggestion’ dialog box is Window modal, similar to Save (cmd+s). I think we should make it tab-modal (on all platforms). See also Issue 602872 and  Issue 682638  for Mac. E.g. you can press Cmd+s and drag a link onto the new tab button on Mac for similar oddness.

`Learn More` opens a tab, and dismisses the dialog "simultaneously". But the macOS window server animates the dialog dismissal using a blocking animation.

If we make the dialog tab-modal, then it will get hidden without an animation when the tab switch occurs.

Or we could plumb `Learn More` to first hide the dialog, before navigating.

It's not a problem on Windows and Linux because Window-modal dialogs do not animate at all when they are dismissed (maybe they should).

We could also trigger the navigation to wait for the dialog to be fully dismissed.

Or do nothing, this is "correct" behaviour for a window modal dialog - it's not linked to a tab, so completing the dismiss animation while the `Learn More` page is loading beneath it is the right thing to do. Doesn't even feel clunky IMO.

cc some folks who may have other thoughts.

Comment 2 by pkasting@chromium.org, Feb 6 2017 

We're trying to kill window-modal entirely in favor of app-modal and tab-modal interaction flows.

That said, I don't think this feels bad and I wouldn't spend any special time or effort to fix it out of band.

Comment 3 by ellyjo...@chromium.org, Apr 12 2017

Labels: MacViews-Dialogs

Comment 4 by lafo...@chromium.org, Apr 27 2017

Components: -UI>Browser>Spellcheck UI>Browser>Language>Spellcheck

Comment 5 by pkasting@chromium.org, Aug 9 2017

Labels: -M-58

Comment 6 by karandeepb@chromium.org, Aug 9 2017

Cc: -karandeepb@chromium.org

Comment 7 by ellyjo...@chromium.org, Oct 9 2017

Status: WontFix (was: Available)
I think the current flow is right for window-modal dialogs, and once we use tab-modal or app-modal dialogs this bug will vanish, so I'm going to WontFix this.
►

Sign in to add a comment