Using mutation event listeners slows down all the dom mutations in the document they are used. We should try to avoid them in chrome.

The event listeners are only added when the ctrl-tab panel opens and removed when it closes. Is that really a problem?

Currently just adding a mutation listener sets a flag to the window object, which triggers checks for the particular mutation event. Removing listener doesn't remove the flag. We could fix that by using a counter and not a flag, but not sure if it is really worth it. Would it be possible to change tabPreviews to not to use mutation events?

It's certainly possible, but it seems like a non-trivial task, and it would duplicate the existing infrastructure that updates the tab attributes.

(In reply to comment #2) > We could fix that by using a counter and not a flag, but not sure if it is > really worth it. And this is certainly not trivial way to fix this bug.

Note that the legacy all tabs popup also uses mutation events, and did so for ages.

Ah, perhaps this shouldn't then block 3.6. But should be fixed anyway.

As per comment 6

Ctrl-Tab and All-Tabs panel work fine. Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091221 Minefield/3.7a1pre ID:20091221034526

need to document the TabAttrModified event

Documented: https://developer.mozilla.org/en/Code_snippets/Tabbed_browser#Notification_when_a_tab%27s_attributes_change And added to the Fx4 for developers page.