Open Bug 1649035 Opened 3 years ago Updated 1 year ago

Unify uses of <browser> and progress listener in all tabs


(Thunderbird :: Mail Window Front End, task)


(Not tracked)


(Reporter: darktrojan, Unassigned)



From bug 1646483 comment 9:

Yes, and that's the problem. A WE cannot expect all loads, in tabInfo.browser, in a Tb tab to emit progress events in the same way. It also cannot even expect a |browser|. A chat tab that does not autoconnect an account, for example, has no |browser| and only adds one to a <deck> later; completely unnecessary and hard to set up for, and why you have to comment out tests. And why shouldn't a chat and every other tab emit WE api progress events. The glodaFacet tab is similar; the <browser> is not there on tab open and is additionally wrapped in some <iframe> for zoom purposes, again unnecessarily.

You do realize, I hope, that there is the tabmail.progresslistener (which wasn't even being added to firstTab before) which you've now made TabProgressListener and the |tabProgressListener| that applies only to contentTab types in specialTabs.js. So what I'm saying, clearly enough I believe, is that you should step back and audit all tab types for complete compatibility with WE tab apis, consistent non duplicated progresslisteners, and the expectation that a Firefox extension operating on tab <browser> can run cleanly in Tb. This includes #messagepane and #multimessage <browser>s, and chat and glodaFacet and even chromeTab. Because what I'm seeing is a lot of bandaid layering going on.

Note that web progress was recently broken for WE in Tb until Bug 1633011, in case you're not aware.

Anyway. What I've needed to do I've done in BrowseInTab, using custom progress listeners, and what made sense only to do internally I did in Bug 1641345.

See Also: → 1680587
You need to log in before you can comment on or make changes to this bug.