User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a3) Gecko/20060705 BonEcho/2.0a3 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a3) Gecko/20060705 BonEcho/2.0a3 This is kind of hard to explain without a screenshot, so I'm going to follow up with a few in a second. What seems to be happening is that the window, chrome and all, tries to expand into an area beyond the right-hand window boundary. Ducks out from under your cursor and hides in the bushes, sort of. It's a fabulous prank, but I feel like that's not what you were going for. This doesn't happen when you drag to the left. It doesn't happen when the sidebar isn't open. Reproducible: Always Steps to Reproduce: 1. Open enough tabs to cause the tab bar to overflow. 2. Open the bookmarks sidebar. (The viewable area of the tab bar will shrink.) 3. Scroll the tab bar to the far left. 4. Grab and drag a tab, and try to hover over the scrollbox arrow on the right-hand side of the window. (Try to scroll the tab bar to the right while dragging a tab.) Actual Results: Entirety of window contents overflow the window boundary by about half an inch (well, half an inch on my iBook screen), which makes the scroll box inaccessible. Expected Results: Tab bar scrolls.

This is what the problem looks like. Note that the scroll box, the search box controls, and part of my extension icon collection are all cut off.

For comparison, this is what it looks like after you stop trying to drag a tab to the right.

this bug sounds like something I ran into while working on bug #318168. see https://bugzilla.mozilla.org/show_bug.cgi?id=318168#c51 I fixed it, but I've never tried with the sidebar open. investigating...

I can reproduce this on win32 as well. it's definitely the same thing that timo reported back at https://bugzilla.mozilla.org/show_bug.cgi?id=318168#c51 I spaced out and forgot to test all of the tab browsing stuff with the sidebar open. I'll go do that now, and investigate this issue. I'm hoping it will not be a scary fix, and I can get to it for 2.0b1

the same problem causes the drop indicator to be drawn in the wrong spot. working on it...

it looks like I need to take into account the position of the tab drop indicator bar. working on a fix...

I've tested LTR with and without the sidebar. I'm asking robert for a review, for which I owe him a pony. I'm going to go test RTL now.

Comment on attachment 228259 [details] [diff] [review] patch, take into account the x position of the tab-drop-indicator-bar box Looks good to me. Besides reviewing I also tested this with the sidebar on the left and the right hand side... all worked as it should.

asaf points out: "well, shouldn't the marginright rely on ib.boxObject.x + ib.boxObject.width and marginLeft on ib.boxObject.x regardless of the direction?" he has a point (but we still need to correct for width of the indicator) I'm going to investigate and report back tomorrow. Note, as for my attached patch, "this.mTabDropIndicatorBar.boxObject.x" should be "ib.boxObject.x".

here's some numbers to help answers asaf's questions. here are the (.x,.width) of the tab drop indicator box and the tab strip under the four cases: no scrolling, no sidebar 0,1009 tab drop indicator 2,1007 tab strip scrolling, no sidebar 0,1009 tab drop indicator 25,961 tab strip no scrolling, with sidebar 301,708 tab drop indicator 303,706 tab strip scrolling, with sidebar 301,708 tab drop indicator 326,660 tab strip the reason we can't just use the tab drop indicator bar dimensions to bound the margin for the tab drop indicator is it would be incorrect, and not account for the gap (2px) and more importantly, the width of the scroll box buttons. note, we do use one edge of the tab drop indicator to prevent weirdness (similar to what's reported in this bug). for more on that, see bug #342363. note, the reason we subtract the x position of the tab drop indicator bar is because the tab drop indicator margin left is relative to the tab drop indicator bar. I'm going attach a new patch, that uses ib.boxObject.x (instead of this.mTabDropIndicatorBar.boxObject.x), which is the same thing, but cleaner.

seeking a= for 1.8, as this is a regression (caused by bug #318168 "Improve tabbed browsing")

I will land on the trunk first, but note, there is no sidebar on the trunk (see bug #330923).

fixed on the trunk.

fixed on branch