sindhu.chelamcherla@, can you please attach screenshots? Also provide bisect if possible.

Attaching screenshots for reference. Please check the blue dot indicator near chrome://flags page on which print preview is opened and other tab focused.

On Disabling Mac views blue indicator is seen. On enabling blue indicator is not seen.

As this issue is seen from M-67, introduction of Mac-views removing Needs-Bisect label.

Thanks!

Deleted: With views enabled.png 157 KB

	With views enabled.png 157 KB View Download

Deleted: With Macviews disabled_M67.png 216 KB

	With Macviews disabled_M67.png 216 KB View Download

Not sure who's working on this. Rob, do you know? Is this a recent change?

avi might know the story here..

Before "the dot" mac would "pulse" the gradient drawn for their tab background in and out constantly, which burned through a ton of CPU and battery. But it looks like all platforms got "the dot" at some point -- see  Issue 775603  or  Issue 630771  or  Issue 473898  .

Those seem to suggest toolkit-views should have this blue dot, but I haven't figured out how to get it on Linux. Maybe it regressed on views platforms ages ago... Or maybe they only show it for pinned tabs.

The blue dot is used in two circumstances:

1. A background tab is waiting to show an alert dialog when it next comes to the front.
2. A background tab has a dialog showing that will be re-shown when it next comes to the front.

This was working, the last time I tested it, for Views on Windows and for Cocoa on the Mac. If it doesn't behave in this manner it indeed is a bug.

This doesn't seem to repro on the latest canary (69.0.3488.0). Does it repro for you?

On my MacViews Canary, 69.0.3488.0, I don't see any blue dot. You see a blue dot on MacViews brower?

Ah interesting! I had swapped the two expectations in my mind as Windows does not exhibit this behavior.

Are there standard rules on when the blue dot appears? My loose understanding of it is that it's really meant to indicate attention from the site.

The print preview dialog is pretty fast to come up, so if a user moves away, there's no need to show the blue dot. It also seems like a page shouldn't bring up the print preview dialog just to pop the blue dot.

I don't understand your comment.

> The print preview dialog is pretty fast to come up, so if a user moves away, there's no need to show the blue dot.

Huh? If the user moves away, the page is still waiting for user input.

> It also seems like a page shouldn't bring up the print preview dialog just to pop the blue dot.

Huh? The blue dot is a UI artifact. Pages are bringing up dialogs to accomplish things, not to show dots.

Here are the two rules:

1. Dialogs: If a tab shows any tab-modal dialog (e.g. a print dialog), then while that tab is the frontmost tab of its window no blue dot is shown. If the user switches the tab to be a background tab of its window while the dialog is showing, a blue dot appears on the favicon to tell the user that the tab is waiting for their attention to handle its dialog. If the user switches back to the tab, the dialog is shown and the dot disappears. (If the user switches away, the dot will reappear.)
2. Alerts: If a tab in a background window (even the frontmost tab of the background window) calls window.alert(), that tab will show a blue dot until the tab is made into the frontmost tab of the frontmost window. When it is made into the frontmost tab of the frontmost window, then the dot will disappear, and the alert() dialog will be shown. At that point, that is a dialog that follows the rules of case 1.

This worked on every platform the last time I touched it. If the blue dot is not appearing in those cases, it is a regression.

> Huh? If the user moves away, the page is still waiting for user input.
Right. As a user, I've never interpreted the blue dot as a page is waiting for input. 

> Huh? The blue dot is a UI artifact. Pages are bringing up dialogs to accomplish things, not to show dots.
I should have been more explicit here in saying that pages shouldn't be attempting to attract attention by using dialogs to do so.

>> Huh? If the user moves away, the page is still waiting for user input.
> Right. As a user, I've never interpreted the blue dot as a page is waiting for input. 

That's what it's always meant though.

>> Huh? The blue dot is a UI artifact. Pages are bringing up dialogs to accomplish things, not to show dots.
> I should have been more explicit here in saying that pages shouldn't be attempting to attract attention by using dialogs to do so.

Do we have evidence that they're being abusive in that way?

In any case, blue dots are pretty rare nowadays since we stopped using them for pinned tab title changes, and in most cases it's due to user action of switching away from a tab showing a dialog.

Is this regressed on Windows, or just the Mac?

#2 is functional on every platform.

#1 has regressed on every platform.

The blue dot does not show for Windows for the print preview dialog. It is a general Views regression on likely all platforms. It's already on stable.

Not sure what the #2 and #1 means.

#1 and #2 as per the rules of the blue dot in comment 11.

A preliminary investigation suggests Windows never had the behavior for adding the blue indicator for the Print Preview dialog.

The Print Preview dialog was flipped on by default on r272972. In changes after that, I've yet to find one where the blue dot appears in response to the print preview dialog on an inactive state.

It's not about the Print Preview dialog, it's about _any_ tab-modal dialog. (Technically, anything that causes the WebContents to be "blocked".) PTAL at chrome/browser/ui/views/tabs/tab_icon.h, TabIcon::AttentionType, which calls out the two cases in which the attention dot appears.

I find your claim that this never worked on Windows to be startling. I know that it _did_ work on Windows, as I was the one who implemented it. https://chromium-review.googlesource.com/c/chromium/src/+/728719

Ah, thanks for the CL that enabled this! That was the last piece of the puzzle needed.

r511310 <-- Works  (First Available Build 64.0.3249.0)
r520759 <-- Broken (First Available Build 64.0.3282.0)

So it never made it out of M64 :-(.

😦

I think we've clearly shown that there's inadequate testing...

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

commit d628738348dd00a8bd8ea5384ed58003d3fe5f6c
Author: Avi Drissman <avi@chromium.org>
Date: Wed Jul 25 17:49:07 2018

Fix the attention indicator.

It wasn't showing up for dialogs on background tabs (broken in
r520759). This fixes that and adds a test.

BUG= 860185 

Signed-off-by: Avi Drissman <avi@chromium.org>
Change-Id: I70ddec77e987dff727a5189e810aad5c3fc589de
Reviewed-on: https://chromium-review.googlesource.com/1147705
Reviewed-by: Robert Liao <robliao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577966}
[modify] https://crrev.com/d628738348dd00a8bd8ea5384ed58003d3fe5f6c/chrome/browser/ui/views/tabs/tab.cc
[modify] https://crrev.com/d628738348dd00a8bd8ea5384ed58003d3fe5f6c/chrome/browser/ui/views/tabs/tab.h
[modify] https://crrev.com/d628738348dd00a8bd8ea5384ed58003d3fe5f6c/chrome/browser/ui/views/tabs/tab_icon.cc
[modify] https://crrev.com/d628738348dd00a8bd8ea5384ed58003d3fe5f6c/chrome/browser/ui/views/tabs/tab_strip_unittest.cc