"Port Firefox bug 687754 |unread attribute set at different times during page load| part 1"

Neil, here's your patch: I don't like it, but you said you wanted it. Notes: - I'm not sure about that _tabAttrModified method call - I couldn't find the right place to put the _other_ cange, as in bug 687754 attachment 565397 [details] [diff] [review].

oops: s/cange/change/

oops, I think I made a typo

(In reply to Tony Mechelynck from comment #1) > - I'm not sure about that _tabAttrModified method call It doesn't matter, we're not using it consistently yet anyway. > - I couldn't find the right place to put the _other_ change, as in bug 687754 > attachment 565397 [details] [diff] [review]. We don't have any preview mode code, so that doesn't matter either.

removing the "regression" keyword as I don't remember whether or when this particular behaviour was "right" in some (and which) previous release.

Comment on attachment 567260 [details] [diff] [review] patch v0.1 [Checkin: comment 6] http://hg.mozilla.org/comm-central/rev/6472355bbf4d

Comment on attachment 567260 [details] [diff] [review] patch v0.1 [Checkin: comment 6] Callek: I'm requesting approval in order to have a clear yes/no decision, but you should be aware that Asa declined approval-mozilla-aurora on the corresponding Firefox patch.

> - I'm not sure about that _tabAttrModified method call We don't actually listen for that. Extensions might depend on this though. Firefox : 1. Originally invented this for their Alltabs popup to replace the performance sucking DOMAttributeModified listener. We use broadcast listeners instead so don't need the fake event. 2. Also uses it in their tab-preview code which we don't have and anyway they could have used broadcast listeners as well.

Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111017003001 Unlike in the previous nightly, here (and with appropriate user CSS, cf. bug 564100 comment #9) all tabs (which I haven't seen except the first!) start up :not([unread]). The [unread] background-color only arrives as the tabs finish loading. I still don't like it but I can live with it. I'd set VERIFIED except that I fixed it myself, and that I only checked that it works on Linux64 which isn't even (yet) an "official" Tier 1 platform for SeaMonkey.

(In reply to Tony Mechelynck [:tonymec] from comment #9) > Unlike in the previous nightly, here (and with appropriate user CSS, cf. bug > 564100 comment #9) all tabs (which I haven't seen except the first!) start > up :not([unread]). The [unread] background-color only arrives as the tabs > finish loading. I still don't like it but I can live with it. Wouldn't the following give you the background-color from start of loading that you prefer? >.tabbrowser-tabs tab[busy]:not([selected=true]), >.tabbrowser-tabs tab[unread] or even >.tabbrowser-tabs tab[busy]:not([selected]), >.tabbrowser-tabs tab[unread]

In reply to comment #10: AFAICT, the tab's favicon is replaced by a throbber icon iff [busy=true]. So yes I could test for that (and in fact I added it to my userChrome.css, http://users.skynet.be/antoine.mechelynck/other/userChrome-seamonkey.css ) — or I could also depend on the tab throbber icon and disregard the tab background when it is "throbbing".

Comment on attachment 567260 [details] [diff] [review] patch v0.1 [Checkin: comment 6] declining approval for beta/release branches. Will leave the aurora requested for now (for someone else to triage), if this misses aurora cutoff (and would morph to a beta request) i'll call it declined.

Comment on attachment 567260 [details] [diff] [review] patch v0.1 [Checkin: comment 6] sorry about the miss here, aurora in this patch applied for 2.6, which shipped. This is in 2.7