Closed
Bug 1423705
Opened 8 years ago
Closed 8 years ago
webExtensions inconsistently change tab IDs
Categories
(WebExtensions :: Untriaged, defect, P3)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1398272
People
(Reporter: badkins79, Unassigned)
Details
Attachments
(1 file)
|
5.40 KB,
application/x-xpinstall
|
Details |
User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Steps to reproduce:
Testing in 32bit Nightly on Windows. This is the nightly version from today (Dec 6 2017).
We develop a WebExtension. We noticed strange behavior when tabs are pulled off of a Window, and then reattached to the original Window.
Actual results:
When you pull a tab off of a window, we get a TabDetached and a TabAttached webExtension method, as we should. For clarity, lets say we have a single Window, with windowID=1. That window contains 2 tabs (tabID=1 and tabID=2). When you pull tabID=2 off of the window, we get a tabDetached event saying tabID=2 was removed from windowID=1. Then we get a tabAttached event saying tabID=2 was attached to new windowID=2.
So far so good. Now if you try and put that tab back onto the original window: We get a tabDetached event saying tabID=2 was removed from windowID=2. Then we get a tabAttached event saying tabID=2 was attached to windowID=1.
At this point, things are jacked. If you do a browser.tabs.get(2), then the tab structure that is returned shows a tab.id=3. Any events on the tab that contain the tab structure show an ID of 3.
We tried to work around it by detecting the mismatch, and resyncing our internal data structures, but then it bit us again in the opposite direction.
If you detach the tab again, and then reattach it, now events go back to using tab.id=2. Only this time, we do not have enough data available to us to detect the mismatch anymore and fix it.
Expected results:
The tab ids should never change. Detaching and attaching tabs shouldn't alter the tab ID. In Chrome extensions, the tab ID never changes.
Component: General → WebExtensions: Untriaged
Product: Firefox → Toolkit
Updated•8 years ago
|
Priority: -- → P3
Comment 1•8 years ago
|
||
I've been looking into another bugzilla issue (Bug 1443221) that is also related to wrongly assigned tab ids and so I've been also trying to see if I could reproduce this issue using the STR from comment 0 and check if it was related to the same underlying issue and/or to a similar one.
May I ask you some additional details about this issue? e.g.
- are you still able to reproduce this issue in a recent Nightly build? (I've tried but I'm not been able to trigger it yet, but it could be because I'm missing some additional details that are needed to be able to fully trigger it as described, e.g. Bug 1443221 is triggered only if the extension also subscribe a webNavigation event)
- besides the onAttached and onDetached tab API events, which are the other APIs (especially API events) used by your extension? (e.g. any other tabs events subscribed? any webRequest and/or webNavigation API event is also subscribed by the same extension?)
- if you can still reproduce the issue, it would be possible for you to attach a small test extension with the minimum amount of code needed to reproduce the issue?
Thanks in advance for any additional detail you can add about this issue,
Luca
Flags: needinfo?(badkins79)
Comment 2•8 years ago
|
||
I've just tried to reproduce it as described in comment 0 on beta (Firefox 60) and I've been immediately able to trigger it with the small test extension attached here.
Using the same extension I don't seem to be able to trigger the same issue on Nightly.
This answer most of the questions from my previous comment, the only remaining one could be:
can you confirm that the issue is being fixed on Nightly also for your extension?
(as it seems to be with the attached test extension)
Thanks in advance,
Luca
Flags: needinfo?(badkins79)
Comment 3•8 years ago
|
||
Bug 1398272 seems to be the one that fixed this issue on Nightly.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•