mblsha@ : Thank you for the issue.Could you please help us with a sample url/jsfiddle to triage further from TE end.

We can probably prevent dragging off tabs that have persistent child windows on them, similar to what we do for modal dialogs. Sample steps

1) On Mac, Go to https://permission.site
2) Click "Notifications", bubble should appear
3) Drag the 'permission.site' tab off the browser window

Expected: permission request bubble should reappear at the right location when dragging stops

Actual: Cocoa - bubble disappears and permission request gets wedged. Create a new tab and switch back to unwedge it.

I think the proper solution would be for parent NSWindow to manually update childrens' frames after it was moved. This problem is much more severe in Yandex.Browser so I'll probably experiment with this in the nearest couple of weeks. 

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I don't think there's a way around the general problem except to add appropriate observers and reanchor child windows.

But it might be nice to fix the problem I described in #c4 in m62.

This is "different" (improved, perhaps..) with toolkit-views permission prompts, but it's still pretty weird.

In m62, with --enable-features=CocoaPermissionBubbles, dragging a tab off that has a permission request causes the request to be lost completely until switching tabs away and back.

With toolkit-views bubbles (currently default), the permission request appears on the window created by the dragged-off tab, but it appears at the wrong position. It doesn't re-anchor to the correct position until switching to a new tab and back, or resizing the browser frame.

BTW I've got a report from Apple that this should be fixed in High Sierra but didn't yet verify this.

for permission bubbles, I've found a neat fix -> https://chromium-review.googlesource.com/631079

For child windows more generally, code in bubble_anchor_helper_views.mm may help views dialogs shown on Cocoa browser. For mac_views_browser, last I toyed with it for tab-modal dialogs, there didn't seem to be a positioning problem, since some updates were made to ReparentNativeView.

For Cocoa bubbles on a Cocoa browser wrt #c8 "dragging a tab off that has a [Cocoa] permission request causes the request to be lost completely until switching tabs away and back.", by fix doesn't work :/.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2090e0df2feba38f8e72f549dba44104c400af2f

commit 2090e0df2feba38f8e72f549dba44104c400af2f
Author: Trent Apted <tapted@chromium.org>
Date: Thu Aug 24 04:33:09 2017

Mac: Update permission bubble anchor while tab dragging.

When dragging tabs, the window is repositioned with direct setFrame: calls
which don't automatically reposition child windows. Most dialogs block tab
dragging or dismiss on focus loss. Permission bubbles do not, so ensure
they are anchored correctly during tab drag.

TEST=Have two tabs, navigate to https://permission.site/,
     Padlock: Ensure everything is set to "Ask",
     Click, e.g., Notifications to get a prompt,
     Drag the tab off the browser window.
     Prompt should reappear with a correct position.

Bug:  628702 
Change-Id: I5a0f9fd6b194437f9aec258077a0e16ba6a832e5
Reviewed-on: https://chromium-review.googlesource.com/631079
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496950}
[modify] https://crrev.com/2090e0df2feba38f8e72f549dba44104c400af2f/chrome/browser/ui/cocoa/browser_window_controller.mm