Adding RB label as this is a recent regression.

+ellyjones, +ainslie. I investigated. This is technically an issue with the permission bubble, not the fullscreen bubble, but it was introduced by my adding the backspace bubble code.

This has been a latent bug forever but just got tickled by my new code (there are probably other ways to activate it).

Here's the problem:
1. When you click Location, the permission bubble appears and is parented to the omnibox. The parenting logic is in PermissionBubbleViewViews::GetAnchorView.
2. When you click Fullscreen, the permission bubble is reparented to the fullscreen bubble (so that it appears immediately below it).
3. When you press backspace twice, the fullscreen bubble widget is destroyed. This activates an observer PermissionsBubbleDialogDelegateView::OnWidgetDestroying, which closes the PermissionBubbleViewViews' bubble_delegate_. Strangely, this does not actually close the permission bubble itself, but it makes it unresponsive to future changes.

As such, the bubble hangs around forever in the centre of the screen, not caring about future fullscreen changes.

The only reason this hasn't been an issue before is that the fullscreen bubble goes invisible when it disappears, rather than being deleted. The permission bubble code shouldn't be depending on that. So there are a few options:

1. Make permission bubble position itself relative to the fullscreen bubble, but not actually anchor to it. (Complicated fix, probably "ideal".)
2. Make sure fullscreen bubble never gets deleted, just stays around forever to avoid this bug. (Provides the ideal behaviour, but with smelly code.)
3. Decouple the two bubbles entirely, so the permission bubble gets positioned at the top of the screen when in fullscreen and the fullscreen bubble overlaps it. (Super easy fix, simplifies the code, sub-optimal user experience.)

I think #3 is actually the best here: this is a very rare case (you have to go fullscreen while a permission bubble is showing to trigger it), and since fullscreen is now an ephemeral notification, not a dialog itself, it looks kind of fine to have them overlapping for a few seconds. See screenshot. So I will put up this code review to do #3. Alex, are you fine with this?

Deleted: exit-fullscreen-over-permission-bubble.png 12.2 KB

	exit-fullscreen-over-permission-bubble.png 12.2 KB View Download

CL for option #3: https://codereview.chromium.org/2065983003/

rolfe - any thoughts about the screenshot / comments in #2?

#3 doesn't sound crazy to me - I also expect this to be very rare in practice. Happy to defer to rolfe@'s judgement. 

Friendly ping as we are approaching the M-53 branch point. Would be good to have this fixed before next week.

I just pinged Rebecca. Should be OK to land the fix.

Ben could you LG the CL tentatively so we can land this?

Apologies - this got stuck in Draft Purgatory. If ainslie@ is ok with it, that works for me. Seems like a rare case. Thanks for looking into this rkote and mgiuca. Such a weird bug!

I don't know if this is quite the best solution as if you do it in the inverse (go full screen then click on a permission) the permission overlaps the full-screen toast message yeah?

Visually it's important to consistently root the permission bubble to the URL in the omnibox. There's always the thought that one day we might do more dialogy/centered styling but for now we're trying to help users associate permissions management with the lock. For mgiuca's write-up I get stuck on step No. 2. I wouldn't think the permission bubble should be anchoring to anything but the omnibox. But that seems to be the case that's hard to fix.

Fine to launch this proposal now and if there's a way I can help propose something that "just works" : ) for the longer term let me know. But I don't want to burn eng hours on a very small edge case.

> I don't know if this is quite the best solution as if you do it in
> the inverse (go full screen then click on a permission) the permission
> overlaps the full-screen toast message yeah?

No, it will still underlap (if that's a word?).

> For mgiuca's write-up I get stuck on step No. 2. I wouldn't think the
> permission bubble should be anchoring to anything but the omnibox.

Well there is no omnibox in fullscreen, which is why it jumps to the fullscreen bubble instead. My CL *is* fixing that; it will now be anchored just in the top-center of the screen. The only issue is that in doing so (detaching the permission bubble from the fullscreen bubble), I have made them overlap when they appear simultaneously.

OK sounds like we have your blessing so let's just go ahead with this.

In earlier full-screen-entering the permissions bubble WOULD stay in place where it appeared (just the omnibox would slide off screen.) I would have liked to kept that behavior if we could. The jumping doesn't feel so great in general (if I was looking at the latest implementation.) If it ever becomes more easy to fix that would be great! More to the point of this bug: the solution of where to put the full screen toast seems reasonable for now.

#10: Which earlier version? I have not changed this code. AFAIK it's always behaved this way. (Perhaps you are looking on a Mac, which has totally different code for this and is not relevant here?)

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

commit 63388490f5cba741db9b49c1e04124c79ed3d1cd
Author: mgiuca <mgiuca@chromium.org>
Date: Mon Jun 27 07:58:05 2016

Permissions bubble is no longer anchored to the fullscreen bubble.

This fixes a bug where if the fullscreen bubble is deleted while the
permissions bubble is open, the permissions bubble will no longer be
anchored anywhere. Simplest fix was to decouple these two bubbles (so
the fullscreen bubble can now display over the top of the permissions
bubble for a few seconds).

BUG= 619894 

Review-Url: https://codereview.chromium.org/2065983003
Cr-Commit-Position: refs/heads/master@{#402133}

[modify] https://crrev.com/63388490f5cba741db9b49c1e04124c79ed3d1cd/chrome/browser/ui/views/website_settings/permissions_bubble_view_views.cc

Re No. 11: Yeah I might be remembering Mac behavior, apologies.