Relationship among <browser>, tabmail tab, and web-ext tabId is broken for shared messagepane tabs.
Categories
(Thunderbird :: Add-Ons: Extensions API, defect)
Tracking
(thunderbird78 fixed)
Tracking | Status | |
---|---|---|
thunderbird78 | --- | fixed |
People
(Reporter: alta88, Assigned: alta88)
Details
Attachments
(2 files, 3 obsolete files)
9.72 KB,
patch
|
darktrojan
:
review+
wsmwk
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
1.38 KB,
patch
|
darktrojan
:
review+
wsmwk
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
Aside from the root problem of the original tabmail implementation, Bug 1455471 did not account at all for a shared #messagepane among tabs and tabIds. Bug 1627556 and Bug 1628245 fixed some things but did not go all the way.
One place to see this is the uBlock extension. Any folder or message type tab opened will break the updating of the toolbar badge, after having switched among these tab types. The _browsers WeakMap keys are wrong for the tabId, being identical and all.
one way to fix it. not sure why a WeakMap reference to browser elements is used in Fx, but it seems pointless in Tb. the "permanentKey" part in tabmail.js can likely be removed too.
also clean up on tab close and make sure tab moves (event not emitted) do not break anything by using a session unique tabInfo.tabId rather than tabIndex.
Comment 3•4 years ago
|
||
Updated•4 years ago
|
- remove permanentKey, the only usage was for the WeakMap for we purposes.
- add a progresslistener to messagepane in firstTab. one is added on all subsequent shared messagepane tab types, so unless one of those is opened, messagepane never gets one. seems wrong.
The second patch has a slight risk; perhaps a try for both would be good, thanks.
Comment 6•4 years ago
|
||
I can put it back, but are you sure? It was linkedBrowser that was added for the tests. The permanentKey would only be necessary if browser/linkedBrowser were being used as WeakMap keys I believe..
Comment 8•4 years ago
|
||
The try run is looking good. There's one failure I've never seen before but I don't think it's related. Re-running that just to be sure.
Updated•4 years ago
|
Updated•4 years ago
|
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/0a04d2187ccd
Relationship among <browser>, tabmail tab, and web-ext tabId is broken for shared messagepane tabs. r=darktrojan
Comment 10•4 years ago
|
||
Assignee | ||
Comment 11•4 years ago
|
||
add back permanentKey.
Assignee | ||
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
Comment 14•4 years ago
|
||
Comment 15•4 years ago
|
||
Assignee | ||
Comment 16•4 years ago
|
||
Thanks, yes both are very low risk.
Comment 17•4 years ago
|
||
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/c79bee7bdfcf
Fix up firstTab browser; it is no longer stored in a WeakMap (for web ext), ensure it gets a listener. r=darktrojan
Comment 18•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Description
•