User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110200 Minefield/3.0a9pre Steps to perform: 1. Open up enough tabs to enable tab scrolling. 2. Drag a tab over one of the scroll buttons. Expected Results: The tab strip should scroll when a tab is dragged over it. It should stop scrolling when it reaches the end and the scroll buttons should look disabled. Actual results: The scroll buttons don't look disabled until after you drop the tab If you start to drag from either end, the disabled look of the scroll button is maintained even though you now can go back or forward, if you grab a tab from the middle of the scrollable area it's fine - both scroll buttons look enabled. Reproducible: Always Steps to Reproduce: 1. Open up enough tabs to enable tab scrolling. 2. Drag a tab over one of the scroll buttons. Actual Results: The tab strip does scroll but the scroll buttons don't look disabled until after you drop the tab If you start to drag from either end, the disabled look of the scroll button is maintained even though you now can go back or forward, if you grab a tab from the middle of the scrollable area it's fine - both scroll buttons look enabled. Expected Results: The tab strip should scroll when a tab is dragged over it. It should stop scrolling when it reaches the end and the scroll buttons should look disabled.

Confirming on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007110916 Minefield/3.0b2pre.

This sounds like what was mentioned in bug 398965 comment 21.

This regressed before alpha 1.

Comment on attachment 288192 [details] [diff] [review] patch I'm concerned that this will cause a noticeable performance regression when dragging tabs. _updateScrollButtonsDisabledState makes calls to non-trivial scrollBoxObject methods, and fires a DOM event, and onDragOver is called a lot during a drag. What caused this to regress, anyways? (I just noticed this is still in my queue, this comment isn't meant to imply that I think someone should look into this right away. I don't think it's a high priority bug.)

Comment on attachment 288192 [details] [diff] [review] patch I don't think that code is performance critical. This would be more expensive, but shouldn't be noticeable. _updateScrollButtonsDisabledState dispatches the event only if there's an update (bug 398965). This was broken since it landed on trunk.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre] (nightly) (W2Ksp4) R.Fixed, by bug 389931, per steps.

Comment on attachment 288192 [details] [diff] [review] patch Obsoleting: the underlying bug is now fixed.

https://litmus.mozilla.org/show_test.cgi?id=5264 added to litmus.