Scrolling tabs (in tabbar) with two fingers on touchpad works differently now. Earlier tabs was scrolling fast all the time I move fingers. Now tabs scroll just a little (about one tab width) in a single scroll animation and stop responding to scroll motion until I remove fingers and start scrolling again. Vertical scroll works the same as before: tabs scroll all the time I do scrolling on touchpad.
Forgive my ignorance, but how is scrolling tabs *supposed to* work? Please describe that in some detail.
Or to be more precise, please describe in some detail how to scroll tabs (in FF distros where it works properly).
Open some tabs so that some of them go out of view and scroll arrows on both sides appear. Place cursor over any of visible tabs and scroll. Vertical scroll works as it's supposed to work. Tabs scroll fast and do so all the time you perform scroll gesture on trackpad (or magic mouse, or I guess any mouse with two scroll wheels). Notice the difference when you do horizontal scroll. That's what reported in this bug.
With the latest fix from bug 668953, firefox now also moves back & forth through the history stack for the active tab when scrolling horizontally in the tab-bar. Steps to reproduce: Scroll horizontally in the tab bar. Actual results: 1. The tab bar scrolls one tab to the left or right 2. The active tab is going back/forward through the history stack. Expected results: 1. The tab bar should scroll as it does when scrolling vertically. 2. The history-stack on the active tab should not be altered when doing horizontal swipe gestures in the tab bar.
Created attachment 556146 [details] [diff] [review] part 1, v1: call preventDefault on scroll events processed by scrollbox I'm not requesting review because I haven't run this through tryserver yet.
Created attachment 556147 [details] [diff] [review] part 2, v1: don't start a swipe if the scroll event has been preventDefaulted
Comment on attachment 556146 [details] [diff] [review] part 1, v1: call preventDefault on scroll events processed by scrollbox This passes tryserver.
(In reply to comment #4) I frankly don't understand these steps-to-reproduce. Please provide more detail. Markus, is this something fixed by your patch?
Comment on attachment 556147 [details] [diff] [review] part 2, v1: don't start a swipe if the scroll event has been preventDefaulted If Neal is fine with part 1, then I'm fine with part 2. I briefly tested this patch on OS X 10.7.1, and it does seem to fix this bug. I have to admit I don't really understand why part 1 works, though.
(In reply to comment #10) RE my reply to comment #4: Comment #4 appears (on the face of it) to describe a different bug than comment #0 and comment #3 (though possibly one that's related). So I was asking for more detail about what's reported in comment #4. I understand well enough what's reported in comment #3. As for the rest of what you say, I await further developments :-)
(In reply to Steven Michaud from comment #11) > (In reply to comment #10) > > RE my reply to comment #4: > > Comment #4 appears (on the face of it) to describe a different bug than > comment #0 and comment #3 (though possibly one that's related). So I was > asking for more detail about what's reported in comment #4. I understand > well enough what's reported in comment #3. > > As for the rest of what you say, I await further developments :-) Steps to reproduce: Scroll horizontally in tab bar with magic mouse. Result: The currently active tab goes back one page (if scrolled right) and goes forward (if scrolled left and there is a page to go forward to). I don't know how I can be any clearer than that but I also recorded a video of the behaviour I'm seeing when scrolling horizontally in the tab bar. :) http://www.youtube.com/watch?v=TVsVVfsEqG8 The mouse is at the top right of the video and here I'm simply scrolling horizontally, back and forth. Please let me know if I can make it even clearer. :)
Comment on attachment 556147 [details] [diff] [review] part 2, v1: don't start a swipe if the scroll event has been preventDefaulted OK, this patch is simply unnecessary. Scroll events always come back to nsChildView with status nsEventStatus_eConsumeNoDefault. That's either set when preventDefault() is called on them during DOM event handling, or at the end of default handling: http://hg.mozilla.org/mozilla-central/file/33031c875984/content/events/src/nsEventStateManager.cpp#l3264 Part 1 fixes this bug on its own. That's because the event's scrollOverflow is set during default handling, and if default handling is skipped, scrollOverflow stays zero. And for a zero scrollOverflow we don't start a swipe.
(In reply to comment #12) Thanks, this is much clearer -- especially with the video. But I can't reproduce this with two-finger scrolling on the trackpad, and I don't yet have a Magic Mouse to test with. Needless to say this isn't what was reported in comment #0, though it may be related.
Markus, is there a reason you haven't yet landed your part1 patch?
(In reply to Steven Michaud from comment #14) For what it's worth - I can reproduce this on the trackpad of my Macbook Air (separate computer from the iMac that recorded the video). I was sent to this bug from bug 668953.
> I was sent to this bug from bug 668953. Yes. I was the one who sent you. At that time I didn't understand your STR, but thought it might be related to this bug. > For what it's worth - I can reproduce this on the trackpad of my > Macbook Air (separate computer from the iMac that recorded the > video). If Markus doesn't land his patch soon, I'll do a tryserver build with the patch, and you can test that. If his patch also fixes your problem then everything's fine. If not, I'll ask you to open a new bug, and we can deal with your problem there.
Johan, here's a tryserver build made with part 1 of Markus' patch. Please try it out and let us know if it fixes your bug: https://firstname.lastname@example.org/try-macosx64/firefox-9.0a1.en-US.mac.dmg
(In reply to Steven Michaud from comment #18) Fantastic, it fixes my bug. I've only been able to test it on my Macbook Air with its integrated trackpad. I will be able to test it with my Magic Mouse, on my iMac, tomorrow.
(In reply to Steven Michaud from comment #15) > Markus, is there a reason you haven't yet landed your part1 patch? Lack of time. Pushed to inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/a8a9ade7fefb
qa+ for verification in Firefox 8.