Closed Bug 522305 Opened 10 years ago Closed 10 years ago
Peek] Preview-per-tab previews shuffle their positions
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]
Summary: Preview-per-tab previews shuffle their positions → [AeroPeek] Preview-per-tab previews shuffle their positions
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?).
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.
And this is with only one window the whole session and I haven't dragged any of the tabs.
Can you get some simple steps to reproduce? Preferably without dragging and without complex pages (takes forever in a debug build).
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.
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.
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.
i guess if this is the same as bug 522610, or at least due to the same cause.
following steps in comment 6 with my patch for bug 522610 i cannot reproduce this. adding dependancy for now.
Depends on: 522610
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.
(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.
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.
if you could bring some ordered step to reproduce the out-of-sync problem with 20100209 nightly (once available), that would greatly help.
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
(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?
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [solved by bug 522610]
Verified with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100220 Minefield/3.7a2pre
Status: RESOLVED → VERIFIED
(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.
You need to log in before you can comment on or make changes to this bug.