Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080811211528 Minefield/3.1a2pre ID:20080811211528 With the fix on bug 445573 holding down the Ctrl+Tab keys and cycle through the list of tabs let the preview images jump to the left and right. No idea if that happens because we are too fast. Probably we should add a small delay between each cycle. With only 3 visible previews no-one will be able to select the right tab this way.
On Windows this issue is seen less often as on OS X. But each second you see this jumps.
I don't see this at all on Linux. When I hold Ctrl-Tab, the preview images stay fixed in place, with their contents rapidly changing as the tabs cycle. (Though the place where the preview images are fixed is shifted slightly to the left of the normal "resting" Ctrl-Tab preview positions.) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080809020910 Minefield/3.1a2pre
The scrolling we use to switch to the next preview isn't a scrolling anymore. It looks like that we only jump between the both positions. As I said in comment 1 it's not really visible on Windows but sometimes the movement also hangs for a really short time. No idea if this is caused by slowness of VmWare. Marcia, are you able to test this in the lab? The latest nightly is a bit too old, so you would need a fresh build from hg to run the test.
(In reply to comment #2) > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080809020910 > Minefield/3.1a2pre Daniel, your build is too old. The fix went in on 20080811.
(In reply to comment #5) > (In reply to comment #2) > > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080809020910 > > Minefield/3.1a2pre > > Daniel, your build is too old. The fix went in on 20080811. Ah, you're right -- however, I was actually using the "Ctrl-Tab" extension with that build (without realizing it :)), and I have an up-to-date version of that extension, so it showed the updated behavior, including the 20080811 fix for bug 445573. I also just tested a fresh mozilla-central build that I checked out today, and that shows the same behavior I described in comment 2. So, comment 2 still stands.
(In reply to comment #4) > The scrolling we use to switch to the next proeview isn't a scrolling anymore. Lets say scrolling from preview A to preview B takes 100 ms. When pressing Tab within these 100 ms, the scrolling is aborted and a new animation for scrolling from B to C is invoked. That's what's happening when holding Tab: A new scrolling is invoked every, say, 10 ms, so only a tenth of each animation can be finished. Is that what you're seeing?
Something that way, yes. But holding down the tab key doesn't only move the preview some pixels to the left. Instead it gets moved half its width and after your mentioned 10ms we end in the new position. So it jumps between these both positions. Today I ran a test again. This time I have used the current nightly build and not my debug build. But the issue remains. On Windows it only flickers a bit which we cannot compare to what I see on OS X. Marcia will also have a look at this soon.
OS: All → Mac OS X
I see the same thing Henrik describes in Comment 9 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080812022114 Minefield/3.1a2pre. If I continue to hold the tab key and scroll (with around 49 tabs open), after some period of time the scrolling seems to accelerate and the tabs look very strange in the preview. I compared the mac behavior to the behavior on Windows Vista, and I do not see the same thing happening there. The longer you scroll, the smoother it is on Windows and the preview does not seem to deteriorate like it does on Mac when I hold the tab key down.
You need to log in before you can comment on or make changes to this bug.