Might be mac-only.. tested with my iBook and stephend on macbook pro. 1) Type something into location bar to have results appear 2) Scroll down with the 2-finger-scrolling 3) Scroll right with the 2-finger-scrolling expect: no side scrolling actual: scrolls to the side.. see attachment Might also be 2-finger-scrolling specific as well... ?

I need to google 2-finger scrolling, but I can imagine how this would be possible given that I use a scroll box. from autocomplete.xml: 1067 <xul:scrollbox anonid="title-scrollbox" class="ac-title"> 1068 # note, we rely on the newlines here so that we have 1069 # a textNode before and after the span. see _setUpDescription() 1070 # for more details 1071 <xul:description anonid="title" class="ac-normal-text ac-comment" xbl:inherits="selected"> 1072 <xul:label class="ac-emphasize-text"/> 1073 </xul:description> 1074 </xul:scrollbox> I might need overflow:-moz-hidden-unscrollable; on the actual scrollbox.

Doing that causes the title to not crop but the url correctly crops right. (Still scrollable because now the title text goes off the edge.)

Seth: 2-finger scrolling is the same as using any other scroll-wheel that supports side-to-side scrolling. We should probably disable it for the richlisttextbox, as it's pretty unexpected.

ok, thanks beltzner. I can reproduce this now.

I'd try: .autocomplete-richlistbox > scrollbox > .scrollbox-innerbox { overflow-x: hidden; } But I'm unable to trigger the bug, so I can't test this.

overflow-x: hidden on any of those 3 elements doesn't seem to help. (used dom inspector and added the styles)

Maybe there's no way around adding overflow[-x]:hidden to all richlistitems, which I think is what Seth did initially.

hmm, I can't reproduce on current trunk. Seth, did you fix this somehow?

I can still reproduce on the 2007121107 build. I can scroll horizontally only after scrolling vertically, but if I move the cursor out of the popup and back in, I can't scroll horizontally until scrolling vertically again.

There seems to be potential for the bug to appear even if there is fewer items than needed to cause the vertical scrollbar to appear. But I'm unable to scroll horizontally without a vertical scrollbar. So, I'm thinking there's a bug with the scroll code that handles the special "ticks" generated by the 2-finger scrolling. If I type in something to the location bar that has 2 results.. richlistbox: computed width 540.8px scrollbox: computed width 540.8px innerbox: computed width 615.2px richlistitems: current_width 540.8000.., computed width 613.2px titlescrollbox: min/maxwidth 459.8000.., computed width 459px hbox containing title: computed width 613.2px urlscrollbox: min/maxwidth 463.8000.., computed width 463px hbox containing url: 613.2px vbox containing the 2 hboxes: computed width 613.2px Both the title and url require ellipses. It seems like the computed width of the hboxes containing the title or url will expand if the content was long enough before adding ellipses. The other richlistitem has smaller content and the hboxes inside are the correct computed widths, but the richlistitem's computed width is also 613.2px probably because its sibling has that width and forced the innerbox to expand.

martijn's patch for bug #408621 fixes this problem.

Seems like bug 421412 fixed this.

in-litmus+ https://litmus.mozilla.org/show_test.cgi?id=5223 Verified FIXED using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008032404 Minefield/3.0b5pre