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

VERIFIED FIXED in mozilla11

Status

()

Core
DOM
P1
major
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Jim Jeffery not reading bug-mail 1/2/11, Assigned: bz)

Tracking

({dogfood, regression})

Trunk
mozilla11
dogfood, regression
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: workaround: toggle toolkit.scrollbox.smoothScroll)

Attachments

(1 attachment)

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

6 years ago
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
Component: Tabbed Browser → DOM
Product: Firefox → Core
QA Contact: tabbed.browser → general

Updated

6 years ago
Duplicate of this bug: 706333

Updated

6 years ago
OS: Windows 7 → All

Updated

6 years ago
Blocks: 704171
Keywords: regressionwindow-wanted
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.
> 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.
(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.
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.
I'm saying we should pass an empty callback to reqestAnimationFrame. I don't expect that the spec will be changed.
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.
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.
Duplicate of this bug: 706468
Duplicate of this bug: 706470

Updated

6 years ago
Keywords: dogfood
Whiteboard: workaround: toggle toolkit.scrollbox.smoothScroll
Hardware: x86_64 → All
(Assignee)

Comment 13

6 years ago
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?
(Assignee)

Comment 14

6 years ago
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....
(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...
(Assignee)

Comment 16

6 years ago
Oh, I see.  I failed to take out the event.timeStamp bits, and that somehow passed tests...
(Assignee)

Updated

6 years ago
Assignee: nobody → bzbarsky
(Assignee)

Comment 17

6 years ago
Created attachment 577998 [details] [diff] [review]
Fix scrollbar smoothscrolling to get the timestamp the new way.
Attachment #577998 - Flags: review?(dao)
(Assignee)

Updated

6 years ago
Whiteboard: workaround: toggle toolkit.scrollbox.smoothScroll → [need review]workaround: toggle toolkit.scrollbox.smoothScroll

Updated

6 years ago
Duplicate of this bug: 706529

Updated

6 years ago
Attachment #577998 - Flags: review?(dao) → review+
Duplicate of this bug: 706562
I applied this patch, rebuilt and it works.

Comment 21

6 years ago
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.
(Assignee)

Comment 22

6 years ago
> 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.
(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
(Assignee)

Updated

6 years ago
Whiteboard: [need review]workaround: toggle toolkit.scrollbox.smoothScroll → [need landing]workaround: toggle toolkit.scrollbox.smoothScroll
(Assignee)

Comment 24

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/f49c353ed414
Flags: in-testsuite?
Priority: -- → P1
Whiteboard: [need landing]workaround: toggle toolkit.scrollbox.smoothScroll → workaround: toggle toolkit.scrollbox.smoothScroll
Target Milestone: --- → mozilla11
Duplicate of this bug: 706713
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
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Duplicate of this bug: 706771

Comment 28

6 years ago
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!
Status: RESOLVED → VERIFIED
Duplicate of this bug: 706802

Updated

6 years ago
Duplicate of this bug: 708230
You need to log in before you can comment on or make changes to this bug.