706323 - Tab overflow is no longer working - overflow arrow appears - tabs won't slide left

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

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

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]

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]

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 4

[Dão Gottwald [:dao]]

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]]

> 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]]

(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]]

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]]

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]]

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]]

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 13

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

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]]

(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 [:bzbarsky]]

Oh, I see.  I failed to take out the event.timeStamp bits, and that somehow passed tests...

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix scrollbar smoothscrolling to get the timestamp the new way.

Comment 20

[Hubert Figuiere [:hub]]

I applied this patch, rebuilt and it works.

Comment 21

[Roman R.]

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 [:bzbarsky]]

> 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]

(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 24

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f49c353ed414

Comment 26

[Ed Morley [:emorley]]

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 28

[alex_mayorga]

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!