522305 - [AeroPeek] Preview-per-tab previews shuffle their positions

Status: VERIFIED FIXED

(Firefox :: Shell Integration, defect)

Description

[Rimas Kudelis [use needinfo to ping]]

After some activity (opening/closing/focusing tabs, browsing), the previews tend to shuffle their positions for me. I think Firefox should ensure that the previews are shown in the same order the tabs are arranged within windows, e.g. [W1T1][W1T2]...[W1Tk][W2T1][W2T2]...[WmTn]

Comment 1

[Rob Arnold [:robarnold]]

This does seem surprising to me but IE8 has a similar bug. Start with a window A with a tab 1. Open window B with tab 2. In Window A, open tab 3. Now, you might expect that the ordering of the previews would be 1,3,2 since that would have them grouped by window. Alas, they are ordered 1,2,3 despite the fact the taskbar should know better. This is possibly related to bug 522610 though that would indicate a bug in IE8.

If all else fails, we can completely restore the ordering by tearing it down and building it back up again every tab open/close/move. Note that we'd also want to have some window ordering otherwise you'd see your download window/error console/other non-tab windows move to the front of the list. This would require some cleverness on our part to pick an ordering for you. I suspect there may not be any ordering that is ideal for all users (unless perhaps the UX folks have an idea here?).

Comment 2

[u88484]

Attachment: Screenshot

I still have this right now so let me know if there is anything I can do to figure out what is going on here.  I'll use a different instance of Firefox for a few hours in case no one responds here quickly.

Comment 3

[u88484]

And this is with only one window the whole session and I haven't dragged any of the tabs.

Comment 4

[Rob Arnold [:robarnold]]

Can you get some simple steps to reproduce? Preferably without dragging and without complex pages (takes forever in a debug build).

Comment 5

[u88484]

I haven't been able to figure out STR.  I was hoping I could just attach some files here.  I'm wondering if this is related to the way new tabs are opened though.  Maybe Dao might have a clue onto what is going on here.

Well I couldn't attach anything here now if I wanted to.  I tried opening Minefield with a different profile and was told the profile was already in use (even though it wasn't) and now I only have the preview for the active tab even though five tabs are opened.

Comment 6

[u88484]

STR:

1)start with about:blank loaded and no other tabs
2) Go to facebook.com
3) Ctrl+T-> mail.google.com
4) Ctrl+T->mozillazine.org
5) Switch back to the gmail tab, open a message and click a link so that the tab opens between the gmail and mozillazine tabs

Look at the previews and the tab order is not the same as what is on the tab bar.  The mozillazine site is loading very very slow right now so I donno if this has to do with it because the link i'm opening from gmail is finish loading before mozillazine.

If you can't reproduce it, try setting accessibility.blockautorefresh to true.  I get the notification bar for the blocked refresh when I open the link from gmail on the new tab.

Comment 7

[u88484]

CC'ing Dao to see if he may be able to help here.  To me this seems like this is related or at least somewhat related to the tab opening behavior.  It appears that if another tab is opened before one finishes, the tab ordering is messed up in the previews.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

i guess if this is the same as bug 522610, or at least due to the same cause.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

following steps in comment 6 with my patch for bug 522610 i cannot reproduce this. adding dependancy for now.

Comment 10

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

i feel that this should now have been fixed by bug 522610, everyone seeing this issue, please retest with next nightly (20100209) and let me know.

Comment 11

[[not reading bugmail]]

Attachment: Out of Order Previews

(In reply to comment #10)
> i feel that this should now have been fixed by bug 522610, everyone seeing this
> issue, please retest with next nightly (20100209) and let me know.

I tested this for quite a while.  The code is better testing with latest hourly build, but I can still get them out of order as shown is the attachment.

Comment 12

[[not reading bugmail]]

Attachment: 2 previews same tab, one dropped.

Its better, but now I have two previews linked to the same tab testing the latest hourly with this change in it.  I also have the modification for bug 522262 in the JSM.  It must have been open/closing tabs that did it.  But I was also dragging tabs around.

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

if you could bring some ordered step to reproduce the out-of-sync problem with 20100209 nightly (once available), that would greatly help.

Comment 14

[Jim Jeffery not reading bug-mail 1/2/11]

I have been testing and so far have not been able to get the tabs to fall out of sequence, or shuffle their positions. 

tested with OpenRelative both on, and off.. and the preview and tabs stay in sync.
Have dragged, opened, reopened and close tabs from from ends, and the middle, and still all stay in sync.  

Using Win7 HP x64 here, running latest hourly:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100210 Minefield/3.7a2pre Firefox/3.6 ID:20100210040525

Comment 15

[u88484]

(In reply to comment #14)
> I have been testing and so far have not been able to get the tabs to fall out
> of sequence, or shuffle their positions. 
> 
> tested with OpenRelative both on, and off.. and the preview and tabs stay in
> sync.
> Have dragged, opened, reopened and close tabs from from ends, and the middle,
> and still all stay in sync.  
> 
> Using Win7 HP x64 here, running latest hourly:
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100210
> Minefield/3.7a2pre Firefox/3.6 ID:20100210040525

I can confirm doing the same things as Jim.  Mark this a dupe of bug 522610?

Comment 16

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

imo this is fixed now.

Remaining cases could be real Win7 backend bugs (see comment 1), by the way it's pretty clear this bug originally was caused by the same code fixed in bug 522610.

If somebody can provide consistent STRs to reproduce a similar issue, it should probably be reported with steps in a new bug.

Comment 17

[u88484]

Verified with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100220 Minefield/3.7a2pre

Comment 18

[[not reading bugmail]]

(In reply to comment #13)
> if you could bring some ordered step to reproduce the out-of-sync problem with
> 20100209 nightly (once available), that would greatly help.

I haven't been able to reproduce the issue in comment 12, but then again, I was hammering on the build while trying to test fixes mentioned in comment 12, so I guess its fixed and will file a new bug if I ever do see it again.