There are a couple of UX interactions that need spec'd for tab-modal prompts. * What to do when a background tab triggers a prompt. I assume we want to avoid switching to that tab, since that tends to disrupt the user current task. Worth considering switching if the user has been idle for X minutes? * How to indicate when a tab has a pending prompt. Looks like we started discussing having a "glow state" for other reasons: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/eb581c44da4b627e# Seems like this would work well. One technical concern here is that we really want the user to deal with prompts in a timely manner, or else there is the potential for some things to mysteriously stop working (because of stacked event loops) until they dismiss newer prompts. So I'd recommending erring on the side of annoying, at least initially.

>I assume we want to avoid switching to that tab, since that tends to disrupt >the user current task. Worth considering switching if the user has been idle >for X minutes? yeah, we should avoid switching the tab if the use is actively using the computer. The idle check is a good idea. Bug 588589 covers implementing the glow state (a dependent bug added this already for app tabs). We should also have these dialogs glow the app icon in the taskbar or bounce the dock icon if the application does not have the focus (and on application focus go to the tab that produced the dialog).

Seems like bug 593339 may actually be implementing the glow?

(In reply to comment #2) > Seems like bug 593339 may actually be implementing the glow? Yes, but please use different color. I suggest red, as it is the only one color that is associated with errors/prompts/alerts for me.

copied from bug 59314: > Masayuki Nakano (Mozilla Japan) 2010-10-28 20:26:37 PDT > > Would you call window.notifyDefaultButtonLoaded(defaultButton) when the dialog > becomes visible? It supports "snap to default button" on Windows. See bug 76053. > Justin Dolske [:dolske] 2010-11-11 20:44:11 PST > > I don't think we want to do that, since the plan is to make these prompts > less like OS dialogs, and not even immediately pop up when triggered in a > background tab (unlike the current dialogs). Bug 598824 would be the place > to discuss this if you disagree. > Masayuki Nakano (Mozilla Japan) 2010-11-11 23:05:58 PST > > Hmm, okay. But note that if the window (the API called window) isn't active > in OS level, it does nothing. On Windows, users can choose "Snap cursor to default button". Bug 76053 emulates the behavior on XUL. The important thing is, users don't need to move cursor to the default button when dialog is opened. This helps some users who have some trouble for accessibility or think it's bother. The method will do nothing when the window isn't active. This is native behavior of Windows. However, maybe, we need to change it for being called from hidden tab's window. It's might be broken by widget removal. http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#9975

(In reply to comment #1) > >I assume we want to avoid switching to that tab, since that tends to disrupt > >the user current task. Worth considering switching if the user has been idle > >for X minutes? > > yeah, we should avoid switching the tab if the use is actively using the > computer. The idle check is a good idea. Is watching a video considered as idle ?

(In reply to comment #4) > On Windows, users can choose "Snap cursor to default button". Bug 76053 > emulates the behavior on XUL. The important thing is, users don't need to move > cursor to the default button when dialog is opened. This helps some users who > have some trouble for accessibility or think it's bother. An interesting use case, but I'm still not sure we'd want to do that. Perhaps for the case of when it's the active tab opening a dialog... But then it's a little odd/inconsistent to have switching to a background tab move the mouse (which I think we definitely wouldn't want). There's also, as I noted, the general issue of making these dialogs appear to be part of the actual web page, which can't trigger mouse-moving behavior itself. [Indeed, some pages already use these kinds of dialogs for esthetic reasons, and the mouse won't respond specially.] We'll make sure keyboard shortcuts work correctly (and the default button should be focused, so just pressing enter should work).

(In reply to comment #1) > >I assume we want to avoid switching to that tab, since that tends to disrupt > >the user current task. Worth considering switching if the user has been idle > >for X minutes? > > yeah, we should avoid switching the tab if the use is actively using the > computer. The idle check is a good idea. Let's say one morning I am surfing around aimlessly until I see an interesting but long blog post so I go get a coffee for reading it and when I come back I see, to my nuisance, that Firefox switched to another tab that tells me that some random AJAX request has failed. I don't want Firefox to switch to another tab automatically, even when I'm idle. I am sure I'm not the only one with this opinion.

^^ Exactly. If you want to make it obvious, that some activity has taken place on a particular tab, just make it flash (take the windows taskbar as an example), or change its color, or perhaps change its icon to something like yellow triangle with and exclamation mark, but don't switch to it automatically. Never. It's annoying and there is no way to detect if idle is really idle.

It would probably also make sense to autoscroll to the tab if there's a glow effect that would be off-screen.

(In reply to comment #9) > It would probably also make sense to autoscroll to the tab if there's a glow > effect that would be off-screen. This would be (when you have several tabs open) annoying if the right-most tab kept scrolling back to it, and you wanted to look at the left-most tab (if that required scrolling.) My suggestion would be to flash the icon used for scrolling the tabs in the relevant direction. This can be just as noticeable and won't interfere with the user. The other alternative is like, don't auto-scroll if the mouse is over the tab-bar so they can finish what they're doing and not have the rug pulled out from under them. Which seems overcomplicated. -[Unknown]

Current thinking, from a discussion with Limi and Faaborg on Friday: * Never switch to a prompting tab * ...unless the browser was not the foreground app, in which case switch to it (browser stays in the background, of course). There was also some discussion on how Panorama's tab groups might play a role, since the prompting tab might not only be in the background but in a different tab group. Tradeoffs both ways, decided not to worry about it for now.

(In reply to comment #11) > * ...unless the browser was not the foreground app, in which case switch to it > (browser stays in the background, of course). Just make sure the user realizes the tab has switched. Otherwise, this behavior may facilitate tabnapping attacks. An attacker can show an alert in one tab so it gains focus and then set its location from another tab, clearing the alert.

I would much rather just have the tab/taskbar icon get highlighted (similar to apptab titlechanges, although probably a different color) over having focus-changing going on without my consent.

Yes there would be issues with autoscrolling - another would be not doing it when there were already examples (to avoid floods and so on). I like the scroll idea, the question is how to handle the transition upon scrolling. Perhaps the existing glow system already supports that, no idea.

Sorry I meant I like the glow idea.

So you'd glow the panorama button & the 'offending' tab in the panorama screen (& the offending tab in the tab bar, in case you switch to another tab in the group) when the alert is in another panorama-group?

> * ...unless the browser was not the foreground app, in which case switch to it > (browser stays in the background, of course). Bad idea. Imagine I'm currently copying information from a tab to an application, always switching between the tab and the application. If now an alert is issued while I'm currently in the application the tab would changed. That's distracting.

One of the UX team's goals for Fx4 includes to reduce paper-cuts, if you transfer focus away from a tab for any reason, its counterproductive. We certainly don't ever automatically change focus away from from what the user is working on at the time, if its important enough we can rely on users to get to it in their natural workflow. I say just start by flagging both the tabbar tab and the panorama thumbnail red like app tabs. From there we could do something even cooler like follow the SMS messaging model. Either use a new widget entirely, or list the number of red tabs requiring attention on the list all tabs and panorama buttons or something.

(In reply to comment #18) > We certainly don't ever automatically change focus away from from what the user > is working on at the time I meant we don't ever *want to* automatically change focus away from the user [since its distracting and most users gripe about it].

(In reply to comment #19) > I meant we don't ever *want to* automatically change focus away from the user > [since its distracting and most users gripe about it]. Big +1 I pledge for *nothing* to *ever* steal focus nor change tabs on Firefox.

(In reply to comment #20) > > I meant we don't ever *want to* automatically change focus away from the user > > Big +1 I pledge for *nothing* to *ever* steal focus nor change tabs on Firefox. +2. Really don't need another pile of duplicate bugs from irritated users which get ignored 'cause not enough users voted for the same duplicate.

That is indeed the plan, with the caveat of if the window doesn't have focus and you are off in another application (at which point we also glow the Firefox taskbar entry or bounce the dock icon): comment #11 >* Never switch to a prompting tab >* ...unless the browser was not the foreground app, in which case switch to it >(browser stays in the background, of course).

Changing tabs when I'm looking is annoying; changing tabs when I'm not looking just adds confusion to that annoyance. If you do that I won't be the only one filing a bug (or switching browsers).

>changing tabs when I'm not looking just adds confusion to that annoyance we already do this. The main reason is that if we are indicating in the taskbar/dock that Firefox would like to tell you something, once you bring it back we need to actually deliver the message, instead of saying "nevermind!"

(In reply to comment #24) > >changing tabs when I'm not looking just adds confusion to that annoyance > > we already do this. The main reason is that if we are indicating in the > taskbar/dock that Firefox would like to tell you something, once you bring it > back we need to actually deliver the message, instead of saying "nevermind!" IMO this would be better: 1. Alert is called in unfocused tab in unfocused window. 2. Taskbar icon flashes. Tab's background color changes 3. User focuses Firefox. 4. Notification box (easily dismissible with a click) appears from tab with a message to notify user of the pending alert. 5a. If user clicks outside of the tab/notification, the notification goes away, but the tab remains colored. 5b. If user clicks the tab/notification, tab goes back to normal color, notification goes away, and tab is focused.

(In reply to comment #24) > if we are indicating in the > taskbar/dock that Firefox would like to tell you something, once you bring it > back we need to actually deliver the message, instead of saying "nevermind!" So flash the tab or scroll controls, as suggested in comment 8 and discussed in several following comments. When tabs get switched out of my control I lose minutes trying to find the tab I'd intentionally left up for when I get back to that window, and sometimes I lose even more by not realizing that was the window it was in. It's extremely frustrating, and for no good reason. You're right to have some alert, but automatically switching tabs does more harm than good. (It would be even better to be able to dismiss the alert without switching tabs, but that's relatively minor.)

If a notification box ("Such-and-such tab wants your attention", akin to "All downloads have completed"?) is used, which I would recommend, then I'd suggest a "switch to that tab" button or link in the notification box.

(In reply to comment #26) > You're > right to have some alert, but automatically switching tabs does more harm than > good. I share this opinion. The only thing that would make automatically switching somewhat less annoying for me would be if there was an easily reachable function for returning to where I was before.

Talked with Limi again yesterday, current thinking is to just keep things simple -- no focus changes, just put a glow or whatever on the tab.

Filed bug 616070 for the ability to make tab-modal prompts switch to the prompting tab (pref controlled). Until we have a tab-glow indicator, I think we need to have this be the default (and with the looming Beta 8 freeze, we might ship this way). Most of the win from the current tab-modal prompts is being able to switch away (or close the annoying tab), so this isn't the end of the world. :)

also now I might start noticing my calendar appointments again :) It would be good for us to provide an app tab exception when we do go back to removing the focus change.

There was no rationale provided with the blocking request on this bug. Blocking-. If you think these interactions are so extraordinarily bad that we should ship Firefox 4 later (than later), please renominate.

Do I understand correctly that bug 616070 is closed because automatically switching tabs is the default behavior again? Does the preference to not automatically switch exist now? Is there another bug I should be following for alerts that could replace automatic switching? When a tab raising a prompt does steal the window, what happens when more than one tab in the same window raise prompts at nearly the same time?

(In reply to comment #33) > Is there another bug I should be following for > alerts that could replace automatic switching? I think it's bug 611553, because it was mentioned in attachment 496081 [details] [diff] [review].

In bug 593120 I proposed a solution (which seemed well enough received but missed the feature freeze deadline) to notify users of tab notifications in tabs hidden by Panorama. I think essentially the same approach could be used for tabs (as well as consistency with Panorama notifications). I'll paste the relevant text below for discussion. === Pulse the Panorama icon once and then another half pulse to keep the highlight color. Once the user opens Panorama, use the same effect on all affected tabs (or minimized groups) in order to draw the user's attention. Whether or not the user chooses to view any of the tabs, reset the panorama icon state to be non-highlighted. If the user leaves and returns to panorama, leave 'old' attention-needed tabs their solid highlight color while animating any new notifications. This way the user's attention is drawn by the animation/color of the panorama icon, but may choose to ignore it and the current task at hand is not disrupted. === In a similar manner non-focus tabs in the current window/group can pulse and remain highlighted while, for tabs which are out of view in the tab bar, the scroll arrow (right or left) will pulse and highlight in the direction of the tab in question. The arrow will remain in that state until the tab in question comes into view or becomes focused. The Tab List can also inherit the highlighting so one can easily identify and jump to it. This would hopefully tread the line of notifying appropriately without annoying or confusing.

is this bug contains interaction with operating system taskbar? I mean when a prompt appears on page and if the window is minimized, there should be a warning to user that web page says something. In windows, it is icon flashing on taskbar.

could somebody please give latest information about this bug ? Why it is waiting? I'm asking for just curiousity not to blame anyone.

1. tabs should pulse (once) and then glow for background tabs with modal dialogs in them. Glow disappears when dialog is dismissed. 2. a glow should appear around each "list all tabs" menu-item for each tab with a modal dialog. 3. arrows (that appear when tabs overflow) should pulse (once per each new modal tab) and then glow if the tabs with modal dialogs in them are off-screen in that direction. Glow disappears when all off-screen tabs in that arrows direction do not have any modal dialogs in them. 4. right clicking on a glowing arrow should focus the nearest tab containing a modal dialog in that direction.

Pulsate the tab. If the tab is in backgorund, Pulsate the Panaroma icon. Going to Panaroma should also list out alerts and should pulsate the border of the tabs that are seeking attention. how does that sound?

(In reply to comment #7) > (In reply to comment #1) > > >I assume we want to avoid switching to that tab, since that tends to disrupt > > >the user current task. Worth considering switching if the user has been idle > > >for X minutes? > > > > yeah, we should avoid switching the tab if the use is actively using the > > computer. The idle check is a good idea. > > Let's say one morning I am surfing around aimlessly until I see an > interesting but long blog post so I go get a coffee for reading it and when > I come back I see, to my nuisance, that Firefox switched to another tab that > tells me that some random AJAX request has failed. > > I don't want Firefox to switch to another tab automatically, even when I'm > idle. > I am sure I'm not the only one with this opinion. You are right to be sure :-) I share this opinion. (In reply to comment #8) > ^^ > Exactly. If you want to make it obvious, that some activity has taken place > on a particular tab, just make it flash (take the windows taskbar as an > example), or change its color, or perhaps change its icon to something like > yellow triangle with and exclamation mark, but don't switch to it > automatically. Never. It's annoying and there is no way to detect if idle is > really idle. I agree. If flash, then once or twice, and then keep some special colour / aspect, but don't flash permanently, this would be disturbing. (In reply to comment #9) > It would probably also make sense to autoscroll to the tab if there's a glow > effect that would be off-screen. If the attention-craving tab is off-screen, that means the tabs the user is playing with are on-screen. And these have to keep priority. Sorry for the tab. User first. (In reply to comment #10) > (In reply to comment #9) > > It would probably also make sense to autoscroll to the tab if there's a glow > > effect that would be off-screen. > > This would be (when you have several tabs open) annoying if the right-most > tab kept scrolling back to it, and you wanted to look at the left-most tab > (if that required scrolling.) > > My suggestion would be to flash the icon used for scrolling the tabs in the > relevant direction. This can be just as noticeable and won't interfere with > the user. This is a much better idea. :-) (In reply to comment #13) > I would much rather just have the tab/taskbar icon get highlighted (similar > to apptab titlechanges, although probably a different color) over having > focus-changing going on without my consent. I share this opinion. (In reply to comment #23) > Changing tabs when I'm looking is annoying; changing tabs when I'm not > looking just adds confusion to that annoyance. If you do that I won't be > the only one filing a bug (or switching browsers). I totally agree.

is there a reason the htaccess authentication dialogs are still window-modal?

Had to look it up. This is bugzilla's explanation of an Incomplete resolution: "The problem is vaguely described with no steps to reproduce, or is a support request. The reporter should be directed to the product's support page for help diagnosing the issue. If there are only a few comments in the bug, it may be reopened only if the original reporter provides more info, or confirms someone else's steps to reproduce. If the bug is long, when enough info is provided a new bug should be filed and the original bug marked as a duplicate of it." I'm not seeing how this bug fits any of that definition. Can you please explain?

yeah, Frank obviously confused “resolved: incomplete [description]” with “[not yet] resolved: incomplete [implementation of fix]” please change to reopened, which is the correct status for this.

No, we're done here. Tab-modal prompts have shipped, and the general UX is fine. I'm actually going to call this FIXED, as I filed this bug in the context of specing a UX for the feature when it was being developed. If there are specific issues with the prompts as they exist today, please file new bugs. Vague bugs about shipped features are unactionable.