577096 - App Tabs should indicate change of state in <title>

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, enhancement)

Description

[Fritz]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100706 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100706 Minefield/4.0b2pre

App Tabs should indicate change of state in <title>.  The easiest example is an incoming gchat in Gmail where <title> changes state from "Gmail - Inbox (#) - [e-mail]" to "Person says...".  In App Tabs with only the FavIcon shown it becomes impossible to visually identify that there is an incoming message or any other possible reason for a change in the displayed <title>.

Google Chrome's has an interesting but imperfect solution.  For a "pinned" tab in Chrome, the FavIcon will get larger (and pixelated) on the non-default state of <title> ("Person says...").  I think a better solution would be a slight change of color for the background of the app tab, something that is noticeable but not too jarring (like the old blue flashing in the taskbar).

Reproducible: Always

Comment 1

[Fritz]

Attachment: Screenshot of Chrome pinned tab in both states (note, there is smooth animation between the two states).

Comment 2

[Josh Tumath]

I think the only real way we can do this is by having a standardised API that makes the tab flash or something like that.

Comment 3

[Fritz]

(In reply to comment #2)
> I think the only real way we can do this is by having a standardised API that
> makes the tab flash or something like that.

I threw that out as a suggestion and critique drawn from how Chrome handled it.  My inspiration for the idea was the subtle "flashing" of the pie chart for when a "zombie page" isn't properly loading.  That being said, I think some indication of the change should be implemented and how that is done should probably be left to better minds than my own.

Comment 4

[Tiago Sá]

I think this has to be made with a standard in mind. Or at least a proposal. Stuff like a number in the favicon for the number of emails, or a star, or whatever, that should be possible for the site to change. It would be mighty awesome for email clients and feed readers, for one, or twitter or stuff like that. Of course, it has to be coded by the page, and that's why I think it should be a proposed standard for HTML5.

But NOT a flashing favicon. What is this? 1987?

Comment 5

[Mil]

Pulsating would be good.

Pulsating != Flashing

Comment 6

[WulfTheSaxon [:Wulf]]

Maybe I'm missing something here... Couldn't the page just change its favicon?

Nevertheless, changing the tab background color on title change would be nice (and not just for app tabs).

Comment 7

[Emilio López]

What about having a pulsating background color on the app tab when the page title changes? So you can leave the favicon alone as is and do something like changing the background color from the inactive tab color to the active tab color and back in a nice animation.

Comment 8

[d]

I'm surprised that it hasn't been mentioned yet, but Opera has something which is similar to this idea. I am not entirely sure what makes it appear, but I think it is when enough of the content of the page is changed. Instead of trying to explain it, I suggest you try it. Just by opening a new tab, which is opened in background, it will appear. I think the purpose of it is to mark that the page is unread.

If we create an API for it, we could provide the option to either just display a dot, marking that it needs attention/something has changed, or, it could display a number, like the amount of new tweets since the latest reload like the title of Twitter currently does.

Comment 11

[movrev]

Pushing for a standard way of doing it through HTML5 is the best way, but it will just simply take too long to get implemented. We need this quicker, which probably means it'll first come through an extension or the like.

A pulsating background/favicon could mean a pulsating title (like gChat notifications) while a single pulse and a persistent superscript number could encode numbers in between parenthesis (like gMail and gReader unread counts). There should be a way of enabling only some of this functionality as with everything in firefox.

This probably won't be optimal for a number of reasons, like the fact that unread counts might be encoded differently across the web, but will probably make app tabs a lot more useful as we reach a consensus or standard.

Comment 12

[Aakash Desai [:aakashd]]

This is common feature request from our beta audience on beta 2:

http://input.mozilla.com/en-US/search/?q=app+tabs+notifications&product=firefox

Comment 13

[Caspy7]

I'd like to chime in and say that I strongly object to any ongoing/continuing animation.  If there was a tab that was pulsing or throbbing or whatever, I would click on it only to make it go away not because I WANT to view the changed content (and then click right back to my current tab).  I'm probably a bit ADD so animations distract me and if I'm trying to concentrate on the content of the page in front of me (maybe I need to for some reason) a constant animation will distract me and make that difficult.

However, an animation in the beginning makes good sense to me.  Perhaps Pulse the tab's background twice and then on the third keep the new color.  (The question of tab color then arises - borrow from the theme's definition?)

My thought would be to move forward with a simple implementation now, for the short term, and get the ball rolling for a standard to implement things like number notifications, sub-icons, etc.

Comment 14

[Fritz]

(In reply to comment #13)
> However, an animation in the beginning makes good sense to me.  Perhaps Pulse
> the tab's background twice and then on the third keep the new color.  (The
> question of tab color then arises - borrow from the theme's definition?)

The issue with that is with tab overflow or if you're away from the computer you won't notice it if it goes away.  The idea is to have an unobtrusive solution that doesn't take away the previous functionality.  Flashing/glowing don't have to be as annoying as taskbar changes were in Windows XP.  They can and should be subtle yet noticeable for those looking.

Comment 15

[imradyurrad]

What issue with tab overflow? App Tabs are sectioned off in their own space.
http://img97.imageshack.us/img97/3286/clipboard01tq.png

Comment 16

[Ron]

(In reply to comment #13)
> However, an animation in the beginning makes good sense to me.  Perhaps Pulse
> the tab's background twice and then on the third keep the new color.  (The
> question of tab color then arises - borrow from the theme's definition?)

I have to say I strongly agree with Mark's comment. Constant animation would be both distracting and annoying. I find gmail's and facebook's chat notifications to be very disturbing, for example.
The problem is that even if there was some animation, that would not really be enough, as there's vital information missing.
For example, seeing how many unread mail items, new rss items and so on.
Of course, there are plugins and scripts that help overcome those issues, but I think that to the average user, those are too complicated.
If the idea is to give a permanent tab, and actually use the name App Tab for it, there should be more behind it than just sticking it in the left side and making them permanent.

Comment 17

[d]

I'd prefer a little dot appearing on the right side of the favicon, just like Opera. The tab could also animate when the change in title occurs, but not after that.

Comment 18

[Gabriela [:gaby2300]]

I'm afraid I strongly disagree with Mark.
I must be aware of any new GMail email as soon as I receive it for work opportunities and it would be useless if the app tab blinked or changed it's colour only for a few seconds because if I were just away from my PC at that moment, I wouldn't be alerted about the new message.
I'm sorry but I don't understand at all the users who say they would find it disturbing because as soon as you would click on the tab the blinking would stop.

Comment 19

[Tiago Sá]

I have to agree with Magne. A little dot at the top right corner of the favicon is probably the best thing to do. Something that pulsates for a little bit or something, but then just stays there until the tab is open. That'd be perfect.

Comment 20

[Gabriela [:gaby2300]]

Yes, I agree with Tiago and Magne!

Comment 21

[Ron]

(In reply to comment #18)
> I'm afraid I strongly disagree with Mark.
> I must be aware of any new GMail email as soon as I receive it for work
> opportunities and it would be useless if the app tab blinked or changed it's
> colour only for a few seconds because if I were just away from my PC at that
> moment, I wouldn't be alerted about the new message.
> I'm sorry but I don't understand at all the users who say they would find it
> disturbing because as soon as you would click on the tab the blinking would
> stop.

I'm not sure your point is valid. When you don't use the App Tab, the only notification you get a change in the title. No animation, no blinking, no extravaganza of any kind. A blinking tab that would require clicking is time wasteful. If I'm busy doing something else, I don't want to have to click the tab and return to my original tab just to remove the blinking effect.
I agree that there needs to be an better indication than just a tab change, but as I mentioned before, it's probably not that easy without implementing some kind of 'protocol' that allow web pages to decide what information to overlay the App Tabs.

Comment 22

[Gabriela [:gaby2300]]

(In reply to comment #21)
Ah! But I use App Tab!

Comment 24

[David Naylor]

(In reply to comment #13)
> I'd like to chime in and say that I strongly object to any ongoing/continuing
> animation.

Agree. And I know the Firefox devs are intelligent enough not to put anything flashing or constantly pulsating in there. So we needn't worry about that.
 
> However, an animation in the beginning makes good sense to me.  Perhaps Pulse
> the tab's background twice and then on the third keep the new color.

Best suggestion so far. Some kind of glow effect is all you need to know that something has changed. IMHO, numbers or other indicators would be excessive. If you want to keep a constant check on your e-mail, that's all you need.

Comment 25

[Caspy7]

Is there a UI/UX person on this bug?
Don't think it can go much further otherwise.

Comment 26

[Alex Limi (:limi) — Firefox UX Team]

This work is now tracked in bug 588589.

Comment 27

[Dão Gottwald [:dao]]

Attachment: patch

Comment 28

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 468289 [details] [diff] [review]
patch

>diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml

>+          else if (!tab.hasAttribute("busy"))
>+            tab.setAttribute("titlechanged", "true");

Not sure I understand the rationale here - is this trying to exclude title changes caused by new page loads?

>diff --git a/browser/themes/gnomestripe/browser/browser.css b/browser/themes/gnomestripe/browser/browser.css

>+.tabbrowser-tab[pinned][titlechanged]:not([selected="true"]) {
>+  -moz-box-shadow: 0 0 0 1em rgba(255,0,0,.5) inset;
>+}

Isn't it impossible for the selected tab to have titlechanged=true, given that remove it in updateCurrentBrowser? Or is this just for _previewMode's benefit?

Comment 29

[Dão Gottwald [:dao]]

(In reply to comment #28)
> >+          else if (!tab.hasAttribute("busy"))
> >+            tab.setAttribute("titlechanged", "true");
> 
> Not sure I understand the rationale here - is this trying to exclude title
> changes caused by new page loads?

Yes, just having a page load in a background app tab triggers DOMTitleChanged. This would affect session restore as well as pages such as iGoogle that reload periodically without actually changing the title or necessarily showing new content.

> >+.tabbrowser-tab[pinned][titlechanged]:not([selected="true"]) {
> >+  -moz-box-shadow: 0 0 0 1em rgba(255,0,0,.5) inset;
> >+}
> 
> Isn't it impossible for the selected tab to have titlechanged=true, given that
> remove it in updateCurrentBrowser? Or is this just for _previewMode's benefit?

Yes, _previewMode.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 468289 [details] [diff] [review]
patch

You should probably get ui-review on the styling.

Comment 31

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #30)
> Comment on attachment 468289 [details] [diff] [review]
> patch
> 
> You should probably get ui-review on the styling.

Can you attach a screenshot, and I'll get it reviewed quickly? :)

Comment 32

[Dão Gottwald [:dao]]

Attachment: screenshot

I never expected this to be the final styling and would rather land this right now for people to test the behavior, but here's the screenshot...

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 471455 [details]
screenshot

ui-r=beltzner on everything except for the specific colour being used there ;)

Comment 34

[Caspy7]

Does this new code also notify based on dialogs prompting for user action as well?
Previously, you were much more likely to be aware of a (modal) dialog prompting for action as it would steal complete tab focus.  It's good that that's gone, but is there a notification system in its place?

On a related note, Panorama now completely hides tabs making such that a user will be completely unaware of tab state changes or prompts for user action.  I've filed bug 593120 to address this.

Comment 35

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/a9648cc0b2c6

Comment 36

[Marco Bonardo [:mak]]

Hm, could I say I don't understand the choosen color? red is scary, for many users. Windows 7 has already predefined colors for notifications, we should use the same "orange" color that is used to show when a download is complete in the taskbar, for example.

Comment 37

[Dão Gottwald [:dao]]

The color was arbitrarily chosen. Please file a bug if you have a concrete proposal for a better color. Bonus points for attaching a patch.

Comment 38

[Marco Bonardo [:mak]]

filed bug 593339.

Comment 39

[Gabriela [:gaby2300]]

Is this feature suppose to work in normal tabs too?

Comment 40

[Brian Polidoro]

Dão

Does this just automatically get triggered anytime the title gets set?  I'm seeing this get triggered for Yahoo Mail even though the title has not changed.  I'd guess they are setting the title after the application checks the server for messages.  And even if the title gets set to the same thing it triggers the indicator.

Comment 41

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #39)
> Is this feature suppose to work in normal tabs too?

Not as implemented.

(In reply to comment #40)
> seeing this get triggered for Yahoo Mail even though the title has not changed.

Please file a new bug?

Comment 42

[Paul [pwd]]

(In reply to comment #40)
> Dão
> 
> Does this just automatically get triggered anytime the title gets set?  I'm
> seeing this get triggered for Yahoo Mail even though the title has not changed.
>  I'd guess they are setting the title after the application checks the server
> for messages.  And even if the title gets set to the same thing it triggers the
> indicator.

Yup the current implementation seems to be checking for any activity with the title tab instead of the text actually changing.

Also, wasn't the plan for this to flash the fav icon rather than change the colour to red that actually makes it look transparent on aero.

Comment 43

[Brian Polidoro]

(In reply to comment #41)
Ok - Bug 593447
I even threw in a testcase.

Comment 44

[Michael Lefevre]

(In reply to comment #41)
> (In reply to comment #40)
> > seeing this get triggered for Yahoo Mail even though the title has not changed.
> 
> Please file a new bug?

Hopefully the new bug 593447 will be marked as a blocker, given that it is actually necessary to fix the issue as originally described here (which was marked as a blocker), on popular sites like Google Reader and Yahoo Mail.

As implemented, some sites are just going to have permanently orange tabs... :(

Comment 46

[Vlad [QA]]

Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre