App Tabs should indicate change of state in <title>

VERIFIED FIXED in Firefox 4.0b7

Status

()

Firefox
Tabbed Browser
--
enhancement
VERIFIED FIXED
7 years ago
5 years ago

People

(Reporter: Fritz, Assigned: dao)

Tracking

(Depends on: 2 bugs, Blocks: 2 bugs)

Trunk
Firefox 4.0b7
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus ?

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [AppTabsTestday] [Input], URL)

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
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 (#) - me@gmail.com" 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
(Reporter)

Updated

7 years ago
Blocks: 551849
(Reporter)

Comment 1

7 years ago
Created attachment 456159 [details]
Screenshot of Chrome pinned tab in both states (note, there is smooth animation between the two states).

Comment 2

7 years ago
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.
(Reporter)

Comment 3

7 years ago
(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

7 years ago
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

7 years ago
Pulsating would be good.

Pulsating != Flashing

Comment 6

7 years ago
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).

Updated

7 years ago
Component: General → Tabbed Browser
QA Contact: general → tabbed.browser
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [AppTabsTestday]

Comment 7

7 years ago
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

7 years ago
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.
(Assignee)

Updated

7 years ago
Duplicate of this bug: 582364
Keywords: uiwanted
(Assignee)

Updated

7 years ago
Duplicate of this bug: 582962

Comment 11

7 years ago
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.
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
Whiteboard: [AppTabsTestday] → [AppTabsTestday], [Input]

Comment 13

7 years ago
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.
(Reporter)

Comment 14

7 years ago
(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

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

Comment 16

7 years ago
(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

7 years ago
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.
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

7 years ago
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.
Yes, I agree with Tiago and Magne!

Comment 21

7 years ago
(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.
(In reply to comment #21)
Ah! But I use App Tab!
(Assignee)

Updated

7 years ago
Duplicate of this bug: 585263
(Assignee)

Updated

7 years ago
Assignee: nobody → dao
Keywords: uiwanted
Whiteboard: [AppTabsTestday], [Input] → [AppTabsTestday] [Input]

Comment 24

7 years ago
(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

7 years ago
Is there a UI/UX person on this bug?
Don't think it can go much further otherwise.
This work is now tracked in bug 588589.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 588589
(Assignee)

Updated

7 years ago
Blocks: 588589
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Updated

7 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 27

7 years ago
Created attachment 468289 [details] [diff] [review]
patch
Attachment #468289 - Flags: review?(mano)
(Assignee)

Updated

7 years ago
blocking2.0: --- → ?
blocking2.0: ? → betaN+
(Assignee)

Updated

7 years ago
Attachment #468289 - Flags: review?(gavin.sharp)
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?
(Assignee)

Comment 29

7 years ago
(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 on attachment 468289 [details] [diff] [review]
patch

You should probably get ui-review on the styling.
Attachment #468289 - Flags: review?(mano)
Attachment #468289 - Flags: review?(gavin.sharp)
Attachment #468289 - Flags: review+
(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? :)
(Assignee)

Comment 32

7 years ago
Created attachment 471455 [details]
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...
Attachment #471455 - Flags: ui-review?(limi)
Comment on attachment 471455 [details]
screenshot

ui-r=beltzner on everything except for the specific colour being used there ;)
Attachment #471455 - Flags: ui-review?(limi) → ui-review+

Comment 34

7 years ago
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.
(Assignee)

Comment 35

7 years ago
http://hg.mozilla.org/mozilla-central/rev/a9648cc0b2c6
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
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.
(Assignee)

Comment 37

7 years ago
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.

Updated

7 years ago
Blocks: 593339
filed bug 593339.
Is this feature suppose to work in normal tabs too?

Updated

7 years ago
Depends on: 593382

Comment 40

7 years ago
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.
(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

7 years ago
(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.

Updated

7 years ago
Depends on: 593447

Comment 43

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

Comment 44

7 years ago
(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... :(
Depends on: 593455

Updated

7 years ago
Depends on: 593836

Updated

7 years ago
Depends on: 594676
Flags: in-litmus?
Duplicate of this bug: 606319
(Assignee)

Updated

6 years ago
Depends on: 605111

Comment 46

6 years ago
Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.