Open
Bug 1420620
Opened 7 years ago
Updated 2 years ago
Restoring tab clears extension badge
Categories
(WebExtensions :: Frontend, defect, P3)
WebExtensions
Frontend
Tracking
(Not tracked)
NEW
People
(Reporter: Oriol, Unassigned, NeedInfo)
References
Details
(Keywords: regression, Whiteboard: investigate[browserAction])
Attachments
(1 file)
651 bytes,
application/x-xpinstall
|
Details |
1. Enable automatic session restore and open various tabs 2. Restart Firefox 3. Install the attached webextension. It shows a badge with a random string when a tab becomes active. 4. Switch to a tab from the previous session Result: The badge appears for an instant, but when the page is restored, the badge disappears.
Comment 1•7 years ago
|
||
I'll take a look at this.
Assignee: nobody → bob.silverberg
Whiteboard: investigate[browserAction]
Comment 2•7 years ago
|
||
I was able to reproduce this. I believe it has to do with lazy tabs and what the browser does to restore them. I'm not sure if this is a WebExtensions issue, or a lazy tabs issue, or both. I noticed that this happens with standard web pages (e.g., https://www.mozilla.org/), but not with about: pages (e.g., about:config). When I added a listener for tabs.onUpdated, in addition to the listened for tabs.onActivated, I found that onActivated does fire for each tab, which is why we see the badge briefly updated, and then onUpdated fires a large number of times for the tab. Here is a record of the onUpdated events I see fired, along with what is passed as changeInfo, and the url that is reported for the tab: { discarded: false } - url: about:blank *** - onActivated is called here { status: "loading" } - url: about:blank { status: "complete" } - url: about:blank { status: "complete", url: "https://www.mozilla.org/en-US/" } - url: https://www.mozilla.org/en-US/ { status: "complete", url: "about:blank" } - url: about:blank { status: "loading" } - url: about:blank { isArticle: false } - url: about:blank { status: "loading", url: "https://www.mozilla.org/en-US/" } - url: https://www.mozilla.org/en-US/ { favIconUrl: "https://www.mozilla.org/media/img/favicon/favicon-196x196.c80e6abe0767.png" } - url: https://www.mozilla.org/en-US/ { favIconUrl: "https://www.mozilla.org/media/img/favicon.d4f1f46b91f4.ico" } - url: https://www.mozilla.org/en-US/ { status: "complete" } - url: https://www.mozilla.org/en-US/ The above does look a bit strange to me, but I don't know if it's relevant to this bug. I assume what's happening is that the tab is being activated, which causes the badge to update, and then when it's brought back from its lazy state the chrome is recreated which removes the badge. onActivated is not called again after that, so the badge disappears. I'm not sure what we should do about this issue, or even where the ownership for this should lie. Andrew, do you have any suggestions?
Flags: needinfo?(aswan)
Reporter | ||
Comment 3•7 years ago
|
||
This is a regression from bug 1395074. https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=71ea88d938e5d68c5843a3689b5ddc0fda38a063&tochange=dda6098cc5161046af377ef69bae69099255b098
Blocks: 1395074
Keywords: regression
Comment 4•7 years ago
|
||
Thanks Oriol. Mark, as you worked on bug 1395074, can you take a look at this?
Flags: needinfo?(aswan) → needinfo?(mstriemer)
Updated•7 years ago
|
Assignee: bob.silverberg → nobody
Updated•7 years ago
|
Priority: -- → P3
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•