New issue
Advanced search Search tips

Issue 667643 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Sep 18
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

HTTP authentication dialog positioned incorrectly if the window is moved before it appears.

Project Member Reported by patricia...@chromium.org, Nov 22 2016

Issue description

Chrome Version       : 56.0.2922.0
OS Version: OS X 10.12.1
URLs (if applicable) : https://www.httpwatch.com/httpgallery/authentication/authenticatedimage/default.aspx?8

What steps will reproduce the problem?
1. Navigate to the above URL. While it's loading, move the Chrome window away from its original location.
2. Wait for the "Authentication Required" HTTP auth dialog to pop up.

What is the expected result?
The dialog is positioned below the omnibox (or bookmarks bar) as usual. Dragging the window afterwards doesn't change the dialog location relative to the window.

What happens instead of that?
The dialog is offset from the window depending on which direction the window was dragged in. Dragging the window around keeps the offset, so the dialog is always in the wrong place.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36



 
dialoglocationbug.mov
1.1 MB Download
Screen Shot 2016-11-22 at 17.13.02.png
220 KB View Download
Status: Untriaged (was: Available)

Comment 2 by tapted@chromium.org, Nov 22 2016

Components: -Internals>Views>Desktop UI>Browser
Labels: Hotlist-Polish
Owner: patricia...@chromium.org
Status: Assigned (was: Untriaged)
[mac triage] this happens with both Cocoa and MacViews dialogs. But I think it only happens while you're actively dragging the window when the dialog appears.

The problem is that [NSWindow frame] doesn't update during a window drag.

There's a private API that updates in real time, but there can still be race conditions. It's called CGSGetWindowBounds() and there's a snippet here that uses it, but never landed: https://codereview.chromium.org/1877043003/diff/60001/ui/views/widget/native_widget_mac.mm#newcode317 

The way to fix this might instead be to detect when the window is currently being moved, and somehow suppress adding child dialogs until the move completes (hard). Or, slightly easier, force a reposition of tab modal dialogs after every window move fully completes.

patti - you're probably a good owner for this, since you've looked at the web_modal stuff before. But it's not high priority.
Status: Archived (was: Assigned)
Archiving old bugs that have only received trivial updates for some time.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Sign in to add a comment