Andrés Delfino Reporter
	Description • 16 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042205 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042205 Minefield/3.0pre

Location bar auto-complete results divisors touch left border.

Please, see screenshot.

Reproducible: Always

	Aleksei Perepelkin [:chaos]
	Comment 2 • 16 years ago

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042204 Minefield/3.0pre

Can confirm!

	Aleksei Perepelkin [:chaos]
	Comment 3 • 16 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=430259#c5 same thing here

	Shawn Wilsher :sdwilsh
	Comment 4 • 16 years ago

What's the intended behavior here?

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 5 • 16 years ago

The outer border line should not be overlaid with the lines between results

	Justin Dolske [:Dolske]
	Comment 6 • 16 years ago

This works for me on both the stock Ubuntu FF3.0.4 and my FF3.1 debug build. Fixed, or needs more steps to reproduce?

	Justin Dolske [:Dolske]
	Comment 7 • 16 years ago

Bug 430259 noted that this issue depends on the Gnome theme selected. It's ok with the Ubuntu default (Human), but not with Clearlooks. I see what's going on, but I'm not sure there's a great fix...

The line between items in the list comes from themes/gnomestripe/global/autocomplete.css:

149 .autocomplete-richlistitem {
150   padding: 1px 2px;
151   border-bottom: 1px solid ThreeDLightShadow;
152   color: MenuText;
153 }

With the Human theme, the border stops 2 pixels from the edge of the panel. With Clearlooks, it extends to the edge of the panel.

The panel itself is styled with "-moz-appearance: menupopup" (global/popup.css). This is where Gnome theme-specific changes happen. With Human, we end up with border-left == border-right == 2px. With Clearlooks, border-left == border-right == 0px. [These border seem to transparent, though? I don't understand DOMi's computed style on this point...]

This is consistent with native window menus, where in Human items have a couple pixels of padding left/right, and in Clearlooks they don't.

Approaches I can think of:

1) Set the left / right borders on the richlist items to be the same color as the bottom-border. This would avoid the chopping effect, but then the results panel would have the wrong border color.

2) Add 1 pixel of left/right margin on the richlist items. This would usually prevent the item dividers from interrupting the panel border (well, unless the panel border is > 1 pixel). This would mean Human would be have 1 extra pixel of padding, and that selected items in Clearlooks wouldn't touch the edge of the panel like they're supposed to.

3) Stop using bottom-border on richlist items, and instead use a separate element (with padding) for the divisor. This opens up a whole mess of other style and performance issues, though.

	Michael Ventnor
	Comment 8 • 16 years ago

We really shouldn't do #1 as the style of the menupopup could be anything and we'd lose the native feel at best.

#2 would be the least evil considering padding forms a large part of GTK anyway and would be far less noticeable than 1 and 3.

#3 of course would be bad for perf.

	Michael Ventnor
	Comment 9 • 16 years ago

And I forgot to mention, I do 2 on bug 430259 :)

	Aakash Desai [:aakashd]
	Comment 10 • 15 years ago

Changing this to verified FIXED as the primary bug 430259 has been verified. Actually, just for kicks, its verified FIXED on the following builds:


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090511 Minefield/3.6a1pre ID:20090511031443

and

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090511 Shiretoko/3.5b5pre ID:20090511031310

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 11 • 15 years ago

This bug's priority relative to the set of other polish bugs is:
P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.

awesome bar results is a primary UI