783148 - The active tab when the user undo a recently closed tab is wrong

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Alfredos-Panagiotis Damkalis [:fredy]]

Steps to reproduce:
1. Open the given URL
2. Install the example addon
3. Open the Error Console (Ctrl+Shift+J)
3. Open at least 3 tabs and a website to each of them.
4. Close one (not the last for making the bug more clear)
5. Make the current first tab active
6. Undo the last closed tab (Ctrl+Shift+T)

What happens:
The index of the active tab (on the both methods I use to extract it) is the last tab index (length - 1). Also there is no title, no favicon (the blank one) and the url is about:blank.

What should happen:
The index of the active tab should be the right one and the same should happen for the rest of the tab properties.

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I took your example ( thanks for including it! ) and played around with this. Here's my version:

https://builder.addons.mozilla.org/package/148650/latest/

I am not sure if I am getting what the exact issue is, but what I saw was this:

 - there seems to be a timing issue when I restore the tab where, upon activate, the tab has the *last* possible index and has a url of about:blank

 - if you check on the tab index order once the tab is restored, it looks correct. I would also theorize that if you were to run your 'onActivateTab' function when the tab is *ready*, the url and tab index would be as expected.

I recorded a really quick screencast of the behaviour I saw:

http://www.youtube.com/watch?v=9NZN2SEeJSg

( I'm using Firefox Aurora on OS X 10.7, fwiw )

Does the behaviour you're seeing differ from mine? Does listening for the tab ready event instead help?

https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/addon-kit/tabs.html#ready

Comment 2

[Alfredos-Panagiotis Damkalis [:fredy]]

sorry for the tl;dr comment

(In reply to Jeff Griffiths (:canuckistani) from comment #1)
> I took your example ( thanks for including it! ) and played around with
> this. Here's my version:
> 
> Does the behaviour you're seeing differ from mine?

No, this is exactly the behavior I wanted to point out.  


> Does listening for the
> tab ready event instead help?

The ready event it would help if my main concern was the url. To be honest, now, the about:blank url seems to me to be normal, as on activate event, the tab isn't fully loaded.

Unfortunately I am more interested at the tab index when a tab is activated and not when is ready. I am trying to build an addon that toggles between the current active tab and the last one. (https://builder.addons.mozilla.org/package/148251/latest/)

I have done some more tests and I found that at the time that the sdk "active" event (or better TabSelect event on firefox) is fired the tab index is wrong. It is wrong not only at the addons sdk tab.index value, but also at the gBrowser.tabContainer.selectedIndex which is probably (sorry I didn't have the time to check it) the value that sdk uses.

So the issue seems to be deeper than an sdk problem.

I have to mention that I have checked 2 more cases where a new tab becomes the active one.

The first one is when a new tab opens, in this case the index is the right one and the url is about:blank (even if this tab loads later the homepage or the newtab page).

The second one is when the user has chosen the option to switch tab when he opens a link in a new tab. The index at this case is also right, even if the new tab with the link opens next to the current active tab and not at the end of the rest tabs. The url is also about:blank which I find it normal as I said.

Finally on the both cases above when I checked the label attribute of the tab element was "Connecting…" but at our case (the undo one) the label was "New Tab".

Comment 3

[BMO Automation]

Add-on SDK is no longer supported so resolving bugs as INCOMPLETE