605111 - Pinned tabs show "new content" highlights when there is no new content

Status: NEW

(Firefox :: Tabbed Browser, defect, P3)

Description

[Deb Richardson [:dria] (plz NEEDINFO)]

Both Zimbra and Gmail app tabs have a "new content" highlight on browser restart, regardless of whether there is new content or not.

Comment 1

[Marcia Knous [:marcia]]

Added https://litmus.mozilla.org/show_test.cgi?id=13741 to cover testing this.

Comment 2

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

At least in the Zimbra case, this happens because it changes its title after the page has finished loading (from "Zimbra" to "Zimbra: Inbox").

Not much we can really do about this, I don't think. Using the title for activity changes is a "usually good enough" kind of solution, and aside from developing some kind of web-exposed API for apps to tells us exactly when they've been "active", we don't really have any better options here, I don't think.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As bug 636144 shows this also happens for Twitter. I can reproduce that with a fresh profile for restarting Firefox and enter/leaving Private Browsing mode.

Also resetting the in-limus flag because the test is not about what this bug really covers. You can also see that because no-one has ever marked it as fail.

Comment 6

[Peter Retzer (:pretzer)]

(In reply to comment #2)
> Not much we can really do about this

Could the listening for a title change not be delayed slightly after application start-up to solve this problem?

Comment 7

[David]

Could specific cases not be specified in the code? (ie. Don't highlight a tab if it changes from "Zimba" to "Zimba: Imbox")

Comment 10

[Daniel]

(In reply to pretzer from comment #6)
> (In reply to comment #2)
> > Not much we can really do about this
> 
> Could the listening for a title change not be delayed slightly after
> application start-up to solve this problem?

I think this is an okay solution. I have the same problem with Gmail and I think a delay would fix most "false positives" Gmail included.

Comment 11

[Peter Retzer (:pretzer)]

This is still an issue for sites that change their title during initial load, e.g. Feedly:
"feedly: your news. delivered." ---> "All" (or whatever category name was selected last)

Gavin, wouldn't comment 6 be a simple, viable solution to this problem?

Comment 12

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

Absolutely. Some kind of time-based delay (relative to either application startup or tab load) before showing the "unread" indicator would make sense, I think.

Comment 13

[Dão Gottwald [:dao]]

I don't see how it would be possible to find a delay that sufficiently reliably prevents false positives while not breaking true positives, because, you know, sites could communicate actual updates right after they're loaded. I think Facebook is doing exactly that. I suspect this is even true for Gmail and Zimbra (immediately changing the title from "Zimbra" to "Zimbra: Inbox (1)" rather than "Zimbra: Inbox"). So I don't think this bug is actionable with that plan.

A feasible approach might be to be smarter about what title changes we consider to be update indicators. For instance, we could require that the new title contains a number that the old title didn't contain. This would work for cases like Facebook, Gmail and Zimbra.

Comment 14

[Peter Retzer (:pretzer)]

(In reply to Dão Gottwald [:dao] from comment #13)
> I don't see how it would be possible to find a delay that sufficiently
> reliably prevents false positives while not breaking true positives,
> because, you know, sites could communicate actual updates right after
> they're loaded. I think Facebook is doing exactly that. I suspect this is
> even true for Gmail and Zimbra (immediately changing the title from "Zimbra"
> to "Zimbra: Inbox (1)" rather than "Zimbra: Inbox"). So I don't think this
> bug is actionable with that plan.
> 
> A feasible approach might be to be smarter about what title changes we
> consider to be update indicators. For instance, we could require that the
> new title contains a number that the old title didn't contain. This would
> work for cases like Facebook, Gmail and Zimbra.

Personally I still think that a time delay would be the best solution, as the change indicator isn't really helpful right after startup, where you probably end up checking you Inbox regardless of the indicator being present or not. The indicator is most helpful if a change happens during your 'normal' browsing session later in the game.

The 'title containing a different number' solution you proposed is generally a good I idea, but it won't work for sites that indicate a change without numbers (I believe the mibbit.com ICR client does that by changing the title to "People said stuff" for example).

Comment 15

[Dão Gottwald [:dao]]

(In reply to Peter Retzer (:pretzer) from comment #14)
> Personally I still think that a time delay would be the best solution, as
> the change indicator isn't really helpful right after startup, where you
> probably end up checking you Inbox regardless of the indicator being present
> or not. The indicator is most helpful if a change happens during your
> 'normal' browsing session later in the game.

I don't get your logic here. That there are unread mail, new facebook messages, etc. is useful information regardless of whether Firefox was already running or you just started it. I for one don't generally select all my pinned tabs when starting up Firefox.

Comment 18

[David Lawrence [:dkl]]

Changing qe-verify? to qe-verify+.