No doubt the code isn't checking if the window is actually showing and no doubt it effects other platforms. I would say the bubble should only be shown once the window is restored.

I suspect this is a long standing issue. Feel free to assign to whoever added the location bubble.

+kuscher

Kuscher, let us have an offline chat about this. We need UX confirmation about whether we should not show permission bubble on inactive browser window or invisible browser window. I can show you the details.

+maxwalker, emilyschechter

Max, Emily - do you have thoughts on whether permission bubbles should pop up in a window that doesn't have focus? Or should they be delayed from showing until the user re-focuses the window?

This doesn't happen on Linux, and I'd be a bit surprised if it happened on other platforms.

You can also use https://benfredwells.github.io/permission-tests/ and "Read Location Delayed" to test.

Oops, posted too early.

What does happen is the permission bubble is shown once the window is shown.

Note we also delay showing the prompt if another tab is active when the permission is requested.

There is more context in https://codereview.chromium.org/2770423002/

But the proposal is that if the window is "inactive" (which means it doesn't have focus) then the permission prompt will not show up until it gains focus. Currently that's not the case. Does that seem reasonable?

What's the reason to change it? Is it because it seems better, it because it makes fixing this bug easier?

In fixing the bug I asked whether we really want to show bubbles when the window is inactive.

One thing I need to mention is, 

If we want to show bubbles when the window is inactive, on Chrome OS, the permission bubble will make the anchored browser window active, i.e. grabbing the focus (I think this is a little bit aggressive). But on Linux, permission bubble on inactive window will not help make the inactive window becoming active.

So the behavior differs. Maybe "show bubble only when the window is active" could unify the behaviors cross platforms.

But thinking in another way, other platforms now are not bad. Chrome OS permission bubble is more problematic.

I actually don't have a strong opinion on this, but I think it's just important that we have a consistent story across different bubbles/infobars and across platforms. So maybe we can get some high level UI guidance and go from there? 

maxwalker: could you share your thoughts from a UX perspective? The question is: 
If a window doesn't have focus (e.g. is in the background) should a permission bubble show up? Or should it be delayed until the user gives the window focus?

hwi@chromium.org (currently OOO) has been working on a cross-platform dialog interaction spec: https://goo.gl/8T8eJA. In contrast to "modal dialogs" (examples: alert, sing-in error), permission requests are (sticky) "popover dialogs" which should be less obtrusive and not steal focus.

Based on the spec, I would suggest the following behavior (this is what we do on macOS):

1. Show the permission request even when the window doesn't have focus. I think the request is still very visible when refocusing the window since it's anchored to the omnibox so we don't need the additional fade-in/show effect. In addition users get the chance to notice that something has happened in the unfocused window (if the window is visible).

2. Keep the current window active (don't steal focus) to avoid unnecessary interruptions. I think this should only happen for modal dialogs which communicate more information that is more severe.

#13's behavior is the behavior I observed in windows/mac/linux.

How about your opinions on Chrome OS? @kuscher Maybe we should follow?

For (1) I think WebContentsObserver::WasShown and WasHidden could fix the bug on Chrome OS.

On Chrome OS, the dialog will make the current window active, which is not WAI from (2). This is another bug I think. I don't have a strong knowledge of this. But it can be investigated.

Thanks maxwalker!

> How about your opinions on Chrome OS? @kuscher Maybe we should follow?

Yeah I think we should try to be consistent across platforms if we can.

Looks like these bubble windows are created differently on desktop aura (looks like TYPE_CHILD) and chromeos (a separate window). Using the same type should make it consistent, although TYPE_CHILD can be clipped by the browser window.

warx@, can you try to make it a transient window? If it works, then the same mechanism should work on other platforms, i think.

Based on comment 16's suggestion, the root cause is found. It is not a permission bubble bug, instead it is a native widget aura bug. On chrome os, the bubble window is added as transient child, we shall set_parent_controls_visibility [1] for it.

For the issue of the bubble dialog is activatable, I think we should make it non-activatable by default [2].

[1] https://cs.chromium.org/chromium/src/ui/wm/core/transient_window_manager.h?q=set_parent_controls_+package:%5Echromium$&l=56
[2] https://cs.chromium.org/chromium/src/ui/views/widget/widget.cc?q=widget.cc&dr&l=146

In this way, the behavior on chrome os will follow other platforms.

In the last several comments, there are some discussion about bubble window stealing focus. The behavior is a little bit divergent, which I filed as  issue 719016 .

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

commit ca0239ad985f47fde15a73d64e3cdac1d8d3660f
Author: warx <warx@chromium.org>
Date: Tue May 09 05:10:36 2017

cros: Fix bubble dialog shows on desktop when parent window is invisible

changes:
CreateBubbleWidget in bubble_dialog_delegate.cc does not set params.child, so it is added as transient child on chrome os: https://cs.chromium.org/chromium/src/ui/views/widget/native_widget_aura.cc?q=native_widget_aura&dr=C&l=180. We should set_parent_controls_visibility(true) for it, which makes the window's visibility following the transient parent's visibility.

BUG= 704350 
TEST=added test coverage
After this change, the reporter's bug will become: when browser is minimized, the dialog will activate/unminimize the browser.

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

[modify] https://crrev.com/ca0239ad985f47fde15a73d64e3cdac1d8d3660f/chrome/browser/ui/views/toolbar/toolbar_actions_bar_bubble_views_unittest.cc
[modify] https://crrev.com/ca0239ad985f47fde15a73d64e3cdac1d8d3660f/ui/views/widget/native_widget_aura.cc
[modify] https://crrev.com/ca0239ad985f47fde15a73d64e3cdac1d8d3660f/ui/views/widget/native_widget_aura_unittest.cc