Last Comment Bug 706323 - Tab overflow is no longer working - overflow arrow appears - tabs won't slide left
: Tab overflow is no longer working - overflow arrow appears - tabs won't slide...
Status: VERIFIED FIXED
workaround: toggle toolkit.scrollbox....
: dogfood, regression
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: P1 major with 2 votes (vote)
: mozilla11
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
: 706333 706468 706470 706529 706562 706713 706771 706802 708230 (view as bug list)
Depends on:
Blocks: 704171
  Show dependency treegraph
 
Reported: 2011-11-29 17:10 PST by Jim Jeffery not reading bug-mail 1/2/11
Modified: 2011-12-17 06:24 PST (History)
25 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fix scrollbar smoothscrolling to get the timestamp the new way. (2.29 KB, patch)
2011-11-30 09:31 PST, Boris Zbarsky [:bz]
dao+bmo: review+
Details | Diff | Splinter Review

Description Jim Jeffery not reading bug-mail 1/2/11 2011-11-29 17:10:43 PST
The tab overflow arrow comes on when enough tabs are open to cause overflow, however you cannot scroll to tabs that opened beyond the last visible tab, and its only 1/2 displayed once overflow starts, thus giving no way to view tab, or close the visible 1/2 tab.

STR
1.  Use m-c win32 build
2.  Open enough tabs to cause the over flow to kick in
3.  Note that you cannot scroll with the overflow arrow to the opened tabs.

20111129014720 e3c8a14cd60b Good
20111129040354 e320f9f5536f Bad

The bad build was the latest m-c -> m-c merge on 11/29/2011
Comment 1 Jim Jeffery not reading bug-mail 1/2/11 2011-11-29 17:14:57 PST
We need an edit:  
The bad build is in the latest m-i -> m-c merge on 11/29/2011
based on cset: e320f9f5536f
Comment 2 Alice0775 White 2011-11-29 20:33:20 PST
Regression window (m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/02d0a386a026
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111128 Firefox/11.0a1 ID:20111128023610
Broken:
http://hg.mozilla.org/integration/mozilla-inbound/rev/0d33f892f63a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111128 Firefox/11.0a1 ID:20111128045109
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=02d0a386a026&tochange=0d33f892f63a
Comment 3 Alice0775 White 2011-11-29 21:20:47 PST
*** Bug 706333 has been marked as a duplicate of this bug. ***
Comment 4 Dão Gottwald [:dao] 2011-11-30 00:17:44 PST
I recommend that the front-end changes from bug 704171 be reverted. We should just pass dummy functions to mozRequestAnimationFrame; this code clearly doesn't benefit from having to keep track of its animation frame requests.
Comment 5 Masatoshi Kimura [:emk] 2011-11-30 01:30:48 PST
> We should just pass dummy functions to mozRequestAnimationFrame;
Then BOTH of dummy functions and previously passed function will be called per spec.
cancelRequestAnimationFrame (which is not implemented yet) is the only way to cancel the callback.
Comment 6 Dão Gottwald [:dao] 2011-11-30 01:55:13 PST
(In reply to Masatoshi Kimura [:emk] from comment #5)
> > We should just pass dummy functions to mozRequestAnimationFrame;
> Then BOTH of dummy functions and previously passed function will be called

No, I said we should revert the patch that caused this bug. There would be no previously passed function.
Comment 7 Masatoshi Kimura [:emk] 2011-11-30 02:54:29 PST
Do you say that we should leave no-argument form requestAnimationFrame?
We will have to remove no-argument form sooner or later unless it is spec'ed.
Comment 8 Dão Gottwald [:dao] 2011-11-30 03:09:53 PST
I'm saying we should pass an empty callback to reqestAnimationFrame. I don't expect that the spec will be changed.
Comment 9 Masatoshi Kimura [:emk] 2011-11-30 03:21:37 PST
I'm confused. Reverting attachment 576543 [details] [diff] [review] will not work unless no-argument form is left. Passing empty callback will not work unless we violate (or change) the spec.
Comment 10 Dão Gottwald [:dao] 2011-11-30 05:09:30 PST
Please try to re-read comment 4, a couple of times if needed. I think it's pretty clear and I don't know what else to say.
Comment 11 Jim Jeffery not reading bug-mail 1/2/11 2011-11-30 07:28:41 PST
*** Bug 706468 has been marked as a duplicate of this bug. ***
Comment 12 Jim Jeffery not reading bug-mail 1/2/11 2011-11-30 07:30:25 PST
*** Bug 706470 has been marked as a duplicate of this bug. ***
Comment 13 Boris Zbarsky [:bz] 2011-11-30 08:56:09 PST
I don't understand comment 4, actually.  I'd love it if you could explain it to me.

Firing of MozBeforePaint events was removed entirely.  So backing out the front-end changes only will simply make the front end not get any notifications at all.

Taking this to look into what's actually going on here, but if you happen to already know that, please do feel free to put it in the bug!  I assume the issue is the scrollbox.xml changes?
Comment 14 Boris Zbarsky [:bz] 2011-11-30 09:09:17 PST
OK, so when I click the arrow on the tabbar, I see a single call to arrowSmoothScroll_start then a bunch of calls to arrowSmoothScroll_handleEvent, then a single call to arrowSmoothScroll_stop, then one last call to arrowSmoothScroll_handleEvent, all for the "arrowscrollbox-clicktoscroll" binding.

This is all as expected, as far as I can tell, but no actual scrolling happens....
Comment 15 Dão Gottwald [:dao] 2011-11-30 09:14:22 PST
(In reply to Boris Zbarsky (:bz) from comment #13)
> Firing of MozBeforePaint events was removed entirely.

Sigh. I had no idea this was the case.

> Taking this to look into what's actually going on here, but if you happen to
> already know that, please do feel free to put it in the bug!

I haven't taken a closer look yet.

> I assume the
> issue is the scrollbox.xml changes?

Presumably, yes...
Comment 16 Boris Zbarsky [:bz] 2011-11-30 09:21:49 PST
Oh, I see.  I failed to take out the event.timeStamp bits, and that somehow passed tests...
Comment 17 Boris Zbarsky [:bz] 2011-11-30 09:31:00 PST
Created attachment 577998 [details] [diff] [review]
Fix scrollbar smoothscrolling to get the timestamp the new way.
Comment 18 Cork 2011-11-30 09:39:29 PST
*** Bug 706529 has been marked as a duplicate of this bug. ***
Comment 19 Jim Jeffery not reading bug-mail 1/2/11 2011-11-30 10:57:34 PST
*** Bug 706562 has been marked as a duplicate of this bug. ***
Comment 20 Hubert Figuiere [:hub] 2011-11-30 11:58:04 PST
I applied this patch, rebuilt and it works.
Comment 21 Roman R. 2011-11-30 12:37:53 PST
Is there an experimental build with the patch? I want to use it now because I need to use FF for work, and I don't want to switch to a new profile.
Comment 22 Boris Zbarsky [:bz] 2011-11-30 12:44:00 PST
> Is there an experimental build with the patch?

There isn't, but you can make the edits manually to your chrome if you're desperate and don't want to just downgrade to yesterday's nightly.
Comment 23 Jim Jeffery not reading bug-mail 1/2/11 2011-11-30 12:49:15 PST
(In reply to Roman R. from comment #21)
> Is there an experimental build with the patch? I want to use it now because
> I need to use FF for work, and I don't want to switch to a new profile.

You could toggle the pref listed in the work-around toggle toolkit.scrollbox.smoothScroll
Comment 25 Jim Jeffery not reading bug-mail 1/2/11 2011-11-30 17:40:40 PST
*** Bug 706713 has been marked as a duplicate of this bug. ***
Comment 26 Ed Morley [:emorley] 2011-11-30 20:12:41 PST
At lurking's suggestion, I (double) landed this directly on mozilla-central, since mozilla-inbound may not be merged before the next nightly (needs to green up a bit first and can't take from further back since backouts near the tip are needed) and it will hopefully save having a few more dupes / mercurial will deal with it quite happily during the merge anyway.

https://hg.mozilla.org/mozilla-central/rev/1900e3edd32d
Comment 27 Jim Jeffery not reading bug-mail 1/2/11 2011-12-01 03:38:49 PST
*** Bug 706771 has been marked as a duplicate of this bug. ***
Comment 28 alex_mayorga 2011-12-01 07:36:57 PST
Happy to report that overflow arrows now work on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111201 Firefox/11.0a1 ID:20111201031025

Thanks!
Comment 29 Jim Jeffery not reading bug-mail 1/2/11 2011-12-01 07:56:40 PST
*** Bug 706802 has been marked as a duplicate of this bug. ***
Comment 30 Dão Gottwald [:dao] 2011-12-17 06:24:30 PST
*** Bug 708230 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.