Closed Bug 706323 Opened 8 years ago Closed 8 years ago
Tab overflow is no longer working - overflow arrow appears - tabs won't slide left
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
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
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
Whiteboard: workaround: toggle toolkit.scrollbox.smoothScroll
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?
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...
Oh, I see. I failed to take out the event.timeStamp bits, and that somehow passed tests...
Whiteboard: workaround: toggle toolkit.scrollbox.smoothScroll → [need review]workaround: toggle toolkit.scrollbox.smoothScroll
Duplicate of this bug: 706562
I applied this patch, rebuilt and it works.
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.
> 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
Whiteboard: [need review]workaround: toggle toolkit.scrollbox.smoothScroll → [need landing]workaround: toggle toolkit.scrollbox.smoothScroll
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
Closed: 8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 706771
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
You need to log in before you can comment on or make changes to this bug.