Open
Bug 1396758
Opened 7 years ago
Updated 2 years ago
tabs.onCreated and onRemoved are evaluated at different times
Categories
(WebExtensions :: General, defect, P3)
WebExtensions
General
Tracking
(firefox57 wontfix)
NEW
Tracking | Status | |
---|---|---|
firefox57 | --- | wontfix |
People
(Reporter: dietrich, Unassigned)
References
Details
(Whiteboard: [tabs])
Attachments
(1 file)
57.0a1 (2017-09-04) (64-bit) Mac OS X Listeners for onCreated event are called after the action occurs. Listeners for the onRemoved event are called before the action occurs. For example, given the following code: function dumpTabCount() { browser.tabs.query({}).then(function(tabs) { console.log('TABS', tabs.length); }); } browser.tabs.onCreated.addListener(dumpTabCount); browser.tabs.onRemoved.addListener(dumpTabCount); To illustrate, here's a log of what happens with the code above and a browser with one tab open: <add a tab (2 tabs)> 2 <add a tab (3 tabs)> 3 <remove a tab (2 tabs)> 3 <remove a tab (1 tab)> 2
Comment 1•7 years ago
|
||
Could you quickly try this in Chrome and tell us what it does there?
Reporter | ||
Comment 2•7 years ago
|
||
Bob is looking at tab event ordering vs Chrome in bug 1366290 so ni?ing him to see if he knows.
Flags: needinfo?(bob.silverberg)
Comment 3•7 years ago
|
||
This is a different issue from bug 1366290, which is just about the order in which tabs.onActivated and tabs.onRemoved are fired. I checked Chrome and it does have a different behaviour from Firefox, and what I believe is the correct behaviour. The above code does not include the removed tab in the output from onRemoved in Chrome. As this is a different issue it should remain its own bug, anb does seem like something we should fix.
Flags: needinfo?(bob.silverberg)
Updated•7 years ago
|
The bug is really annoying for keeping a record of the current tabs states. Now, I have no choice to put a hard coded delay for getting the state when the tab is completely closed. onRemoved should be fired once the tab is completely closed, I find it makes more sense. firefox: 57.0b11 browser.tabs.onRemoved.addListener(() => { browser.tabs.query({ currentWindow: true }).then((tabs) => { // tabs STILL contains the close one }); }); browser.tabs.onRemoved.addListener(() => { setTimeout(()=>{ browser.tabs.query({ currentWindow: true }).then((tabs) => { // tabs DONT contains the close one }); }, 300); // Value chosen arbitrarily }); browser.tabs.onCreated.addListener(() => { browser.tabs.query({ currentWindow: true }).then((tabs) => { // tabs contains the open one }); });
Updated•7 years ago
|
Priority: P5 → P3
Is this the same bug? https://bugzilla.mozilla.org/show_bug.cgi?id=1396758
Reporter | ||
Comment 8•6 years ago
|
||
Yes!
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Updated•5 years ago
|
Assignee: nobody → oriol-bugzilla
Status: NEW → ASSIGNED
Comment 9•5 years ago
|
||
Comment 11•5 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #10)
Oriol, What is the status on this?
Unassigning myself since I haven't been working on this lately.
This is actually very tricky. The desired behavior is
onRemoved
should fire once the tab is completely removed, so that it doesn't appear inbrowser.tabs.query
- for compatibility with Chrome,
onRemoved
is supposed to happen beforeonActivated
when the active tab is removed.
However, internally this is what happens
gBrowser.removeTab
callsgBrowser._beginRemoveTab
synchronouslygBrowser._beginRemoveTab
blurs the tab synchronously, this will causeonActivated
gBrowser.removeTab
callsgBrowser._endRemoveTab
. This can happen either- synchronously when removing without animations
- asynchronously, at transitionend
- asynchronously, after 3 seconds, if there was no transitionend event
gBrowser._endRemoveTab
removes the tab for real
So, should we really delay onActivated
until the tab is really removed, even if we have to wait 3 seconds?
What if meanwhile the extension queries the state of the tab, should we make it seem that the old tab is still selected?
Personally I think it may be better to just report what Firefox actually does. If the tab is blurred before being removed, onActivated
should fire before onRemoved
. And if this order is different than in Chrome, so be it.
Assignee: oriol-bugzilla → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(oriol-bugzilla)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•