Closed Bug 404157 Opened 17 years ago Closed 17 years ago

Border around <select multiple> is missing since 2007-11-07

Categories

(Core :: Widget: Gtk, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: peter.saaf, Assigned: twanno)

References

Details

(Keywords: regression)

Attachments

(5 files, 2 obsolete files)

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

Multiple selection boxes seems to be missing at least parts of their border since 2007-11-07. I'm attaching screenshots to show the behaviour.

First two screens are with the Candido[1] gtk-engine which I normally use. The problem is quite obvious with this engine.

Second two screens are with the GNOME default clearlooks engine. The problem is much less apparent with this engine.


[1] http://www.gnome-look.org/content/show.php/Candido-Engine?content=41345




Reproducible: Always
Attached image Missing border
Nightly build from 20071116 showing the problem. Candido gtk-engine
Attached image OK border
Nightly build from 2007-11-06 with ok behavior. For reference
Nightly build from 2007-11-16 showing the problem with the clearlooks engine.
nightly build from 2007-11-06 showing the expected look with the clearlooks engine
Version: unspecified → Trunk
Component: OS Integration → Widget: Gtk
Keywords: regression
Product: Firefox → Core
QA Contact: os.integration → gtk
Summary: Multiple selection boxes border missing since 2007-11-07 → Border around <select multiple> is missing since 2007-11-07
Flags: blocking1.9?
OK, I have a solution for this, I am working on that at the moment. This solution should also fix the rounded corners as mentioned in bug 118312 comment 40.

Re Missing border - Clearlooks engine: The "OK border" is actually a wrong border: it is too thick (it is the border of an entry). The "Missing border" here has actually the correct thickness. Compare it with the border of the selection boxes in the Theme Preferences or Theme Details dialogs
Assignee: nobody → twanno
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Note:

I don't have gnome 2.20 so I can't test if 
a) corners are square with Clearlooks on gnome 2.20
b) the border is drawn with Candido engine (since that requires gnome 2.20)
but I think I can reasonably assume that this patch results in both a) and b)
Attachment #289192 - Flags: superreview?(roc)
Attachment #289192 - Flags: review?(roc)
The current border style makes html list boxes not very noticable, maybe reverting back to the old border style is the correct thing to do here, also because html list boxes never require natively themed list headers or twisties.
Attachment #289220 - Flags: superreview?(roc)
Attachment #289220 - Flags: review?(roc)
Comment on attachment 289192 [details] [diff] [review]
fix treeview borders on gnome 2.20 [checked-in]

Looks OK to me but I want to know what Michael thinks
Attachment #289192 - Flags: superreview?(roc)
Attachment #289192 - Flags: superreview+
Attachment #289192 - Flags: review?(ventnor.bugzilla)
Attachment #289192 - Flags: review?(roc)
The listbox patch looks okay but it should have a comment pointing out that for non-HTML listboxes we fall through to the next case. I want to know what Michael thinks about this one too. Arguably instead of doing this, GTK theme designers should make their listboxes stand out a bit more.
Attachment #289220 - Attachment is obsolete: true
Attachment #289258 - Flags: superreview?(roc)
Attachment #289258 - Flags: review?(ventnor.bugzilla)
Attachment #289220 - Flags: superreview?(roc)
Attachment #289220 - Flags: review?(roc)
Comment on attachment 289192 [details] [diff] [review]
fix treeview borders on gnome 2.20 [checked-in]

This patch is fine by me, but I'm not sure about the second patch. I'd rather not return to our old hackish way of making listboxes especially now that we have implemented focus rings for entries, thus making it obvious how hackish our listboxes were. HTML listboxes look fine here with just the first patch.
Attachment #289192 - Flags: review?(ventnor.bugzilla) → review+
Comment on attachment 289192 [details] [diff] [review]
fix treeview borders on gnome 2.20 [checked-in]

Fix a problem on Gnome 2.20 with treeview borders.
Attachment #289192 - Flags: approval1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Priority: P2 → P3
Attachment #289192 - Flags: approval1.9?
Comment on attachment 289192 [details] [diff] [review]
fix treeview borders on gnome 2.20 [checked-in]

Checking in widget/src/gtk2/gtk2drawing.c;
/cvsroot/mozilla/widget/src/gtk2/gtk2drawing.c,v  <--  gtk2drawing.c
new revision: 1.41; previous revision: 1.40
done
Attachment #289192 - Attachment description: fix treeview borders on gnome 2.20 → fix treeview borders on gnome 2.20 [checked-in]
I just tried the nightly from 2007-11-19 and the border starts out ok.
However, a tiny bit of the border just above the scrollbar disappears on
mouse-over.
Also, when I scroll the list the entire top portion of the border disappears.

The odd thing is that the CC list in this bug seems to work fine but the lists in https://bugzilla.mozilla.org/query.cgi shows the above problems.

Comment on attachment 289258 [details] [diff] [review]
keep the old style border for html list box (with comment)

marking this patch obsolete as per comment 11
Attachment #289258 - Attachment is obsolete: true
Attachment #289258 - Flags: superreview?(roc)
Attachment #289258 - Flags: review?(ventnor.bugzilla)
Blocks: 404555
I (In reply to comment #14)
> I just tried the nightly from 2007-11-19 and the border starts out ok.
> However, a tiny bit of the border just above the scrollbar disappears on
> mouse-over.
> Also, when I scroll the list the entire top portion of the border disappears.
> 
> The odd thing is that the CC list in this bug seems to work fine but the lists
> in https://bugzilla.mozilla.org/query.cgi shows the above problems.
> 

I can confirm this, and I have filed bug 404555 for this issue. Now that the original problem is solved, and assuming that no additional work has to be done in this bug, I resolve this bug Fixed. 
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: