1115683 - Nightly 37 with e10s on generates many more TabAttrModified events than Beta 35/non-e10s with same number of tabs/session

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[User Dderss]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141225030205

Steps to reproduce:

I included in my tiny "Add Page Title To URL Bar" (https://addons.mozilla.org/en-US/firefox/addon/add-page-title-to-url-bar/) a counter to see just how many times TabAttrModified gets fired during start-up time or otherwise during the use.


Actual results:

During load of session, TabAttrModified gets fired in Nightly 37/e10s twice more times than in Beta 35/non-e10s.

After the session is already loaded, and you "click-to-load" a number of tabs, the number TabAttrModified fires dramatically higher, too. Especially with those countless "Connecting..." on/off tab labels.


Expected results:

Since there are quite a number of extensions that listen to TabAttrModified (I do not mean mine extension; it is insignificant), the excessive number of TabAttrModified triggering can in some cases significantly slow down browsing in big sessions.

Why number of TabAttrModified fires has increased? It is really necessary, is it by design or just unintended consequence of other intentional changes? What is with the countless "Connecting..." on/off tab label status changes? Can we get rid of that? Maybe this all should work this way, but so far I see nor reason for that.

Also, if TabAttrModified is Nightly 37/e10s mode is generating countless fires by design, is not too broad and should better be split into separate even listeners (for label and other things)?

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Can you try nightly with e10s vs nightly with non-e10s?

Comment 2

[User Dderss]

Sorry, I was not clear enough about this. It is only issue in e10s mode; Nightly 37 in classic mode does not generate any more TabAttrModified events than Beta 35 or other non-e10s versions of the browser.

Comment 3

[Jim Mathies [:jimm]]

There's a regression in the number of label edits we do, but that's about it.

STR:

1) add the attached code to a local build
2) open the browser, open five tabs and load bing.com into each
3) click once through the set of tabs selecting each

without e10s:
**********************************************************
label,crop:55
image:10
busy:15
visuallyselected:18
selected:18

with e10s:
**********************************************************
label,crop:62
busy:16
image:10
selected:18
visuallyselected:18

I don't think this is serious enough to block.

Comment 4

[Jim Mathies [:jimm]]

Attachment: patch

Comment 5

[User Dderss]

Thanks, James.

By the way, did you -- by any chance -- find out about this weird endless "[actual tab label]" -> "Connecting..." -> "[actual tab label]" -> "Connecting..." -> "[actual tab label]" "Connecting..." -> "[actual tab label]" tab label cycle? In my experience it got really abusive only in e10s mode.

Comment 6

[Jim Mathies [:jimm]]

(In reply to User Dderss from comment #5)
> Thanks, James.
> 
> By the way, did you -- by any chance -- find out about this weird endless
> "[actual tab label]" -> "Connecting..." -> "[actual tab label]" ->
> "Connecting..." -> "[actual tab label]" "Connecting..." -> "[actual tab
> label]" tab label cycle? In my experience it got really abusive only in e10s
> mode.

I didn't, I think we have a bug on this someplace. When this comes up in triage I'll ask around.

Comment 7

[Jim Mathies [:jimm]]

felipe, do you remember a "Connecting..." bug from about six months ago?

Comment 8

[:Felipe Gomes (needinfo for replies!)]

Hmm I don't actually remember it.. It might have been someone else who worked on it