Closed Bug 315203 Opened 19 years ago Closed 19 years ago

SELECT elements are transparent (background color shows through)

Categories

(Camino Graveyard :: HTML Form Controls, defect)

Product:
Camino Graveyard
Component:
HTML Form Controls
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Camino1.0

People

(Reporter: lehni, Assigned: alqahira)

References

Details

(Keywords: fixed1.8.0.1, fixed1.8.1, regression)

Attachments

(4 files, 1 obsolete file)

Screenshot illustrating the problem.
1.56 KB, image/gif
Details
testcase with yellow background as shown in screenshot
335 bytes, text/html
Details
Updated select widget styling torture testcase
4.75 KB, text/html
Details
v2, fixes bug 282941 also
1.90 KB, patch
mikepinkerton
: review+
sfraser_bugs
: superreview+
dveditz
: approval1.8.0.1+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051104 Camino/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051104 Camino/1.0+ here's a test case: in the following HTML, a simple SELECT element is rendered on a yellow background. the element's background seems to be transparent, so it's displayed in yellow as well. <html> <head> <body bgcolor="yellow"> <select name="select" size="3"> <option>one</option> <option>two</option> <option>three</option> </select> </body> </html> Reproducible: Always Steps to Reproduce: Actual Results: The element's background seems to be transparent. Expected Results: It should be rendered with a white opaque color, according to OS X UI Guidlines.
On the left: Camino On the right: Safari
Do the latest Firefox nightlies have the same problem? This may be a Core bug. cl
Works for me, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051105 Firefox/1.6a1
URL: %3Chtml%3E%0A%3Chead%3E%0A%3Cbody%20b...
This is on Mac OS X. I just downloaded the latest Firefox nightly and tested: The element is rendered correctly there. So it's indeed a Camino issue.
Here's a fairly reduced testcase, based on the HTML in the bug report, that's fully valid HTML 4 (so as to avoid any possible problems with invalid HTML). Verified identical behaviour to screenshot in Safari and latest Camino. cl
Oh yeah. Confirming. cl
Status: UNCONFIRMED → NEW
Ever confirmed: true
I knew we had a dupe for this :-) *** This bug has been marked as a duplicate of 193232 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
This bug (and this bug ONLY) can be fixed by changing the "transparent" on lines 577 and 590 of http://lxr.mozilla.org/mozilla/source/layout/style/forms.css to "-moz-Field" when this file is imported into Camino's package contents. Fixing this problem appears to prevent fixing bug 193232; the two bugs are mutually exclusive as far as I can tell. cl
Reopening per discussion in bug 193232. These are mutually exclusive; fixing one will break the other. cl
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Tweaking summary. This bug is about our poor default behaviour. cl
URL: %3Chtml%3E%0A%3Chead%3E%0A%3Cbody%20b...
Summary: SELECT Element with SIZE attribute set do not have a background color. → SELECT elements are transparent (background color shows through)
Status: REOPENED → ASSIGNED
Assignee: mikepinkerton → bugzilla
Status: ASSIGNED → NEW
We only want to change line 590; otherwise we get white select-as-menus again (sorry Chris). Also fixes a typo in a comment further on down. New testcase with additional select varieties (and disabled versions) to follow.
Attachment #202002 - Flags: superreview?(sfraser_bugs)
Attachment #202002 - Flags: review?(mikepinkerton)
Could you roll the fix for bug 282941 into the patch, just so we have to fight only once for approval? Thanks.
If I'm remembering the rules of the cascade correctly, we just need to add the one attribute to a Camino-only rule and we inherit the rest of the attributes from the core.
Attachment #202002 - Attachment is obsolete: true
Attachment #202010 - Flags: superreview?(sfraser_bugs)
Attachment #202010 - Flags: review?(mikepinkerton)
Attachment #202002 - Flags: superreview?(sfraser_bugs)
Attachment #202002 - Flags: review?(mikepinkerton)
Comment on attachment 202010 [details] [diff] [review] v2, fixes bug 282941 also >Index: mozilla/layout/style/forms.css >=================================================================== >- background-color: transparent !important; >+ background-color: -moz-Field !important; Can this rule simply be removed? The XP styles already have: select { ... background-color: -moz-Field; so I'm wondering if we need this for the !important.
No, we need the !important; otherwise we get bleed-through again (which is odd, because I would have expected to get the select's own bg-color, if defined, since XP widgets can have their bg-color styled). Is there some code in play here, too? That might explain why we have this bug in the first place (or maybe I'm all mixed up again).
Stop the presses; this bug doesn't exist in 0.8.4. The forms.css is very different, though. Or, rather, platform-forms.css. Among other things, it used to have -moz-appearance: listbox; for the select size/multiple (and -moz-appearance: menulist; for the "plain" select), and now that's -moz-appearance: none; (and absent altogether for the "plain" variety) and we're drawing more stuff by hand. It's hard to say what changed it, since the changes are so drastic (and my head is spinning at this point), but maybe the listbox style had some intrinsic property that prevented this bug (but brought along lots of non-native-looking bits and a couple of bugs like the disappearing frames)?
Keywords: regression
Hey, while we're at it, what are those extra numeric designators (three "#999999"s) after the border-color in line 592? If I comment them out, nothing changes, and they seem to be incompatible with "proper" CSS, at least to my knowledge. The W3C validator doesn't explicitly reject it, but the CSS spec doesn't endorse it, either. Is that something we want to be fixing while we're making other fixes to this file? cl
(In reply to comment #18) > Hey, while we're at it, what are those extra numeric designators (three > "#999999"s) after the border-color in line 592? border color for top, right, bottom, left > If I comment them out, nothing changes maybe the border around the list box?
-> Smokey, since he pretty much took care of it for me. cl
Assignee: bugzilla → alqahira
Status: NEW → ASSIGNED
Yeah, this bug appeared when the fixes for bug 298111 were checked in (or, rather, when a build with those fixes finally became available, since none of the widgets changed until 2005-06-28-08--I think the build machine wasn't pulling new source that time....) See bug 298111 comment 4 for some of the reasons, aesthetic and bug-driven, why the select rendering was changed from the Moz-style-attributes to hand-drawn. I think the best course of action is still to take this patch, and then either in the further tweaking for the issues in bug 298111 or in Josh and Simon's forthcoming cleanup/polish of Cocoa widgets see if we can't come up with another solution for some of the bugs and appearance glitches that caused the switch in the first place, or some alternate solution, that might allow the fixing of bug 193232, too (or, decide we want to wontfix it). But for now I think we should take this patch, and see if we can get it approved for the branch for 1.0.
Blocks: 298111
Setting the appropriate flags since it is a regression....
Flags: camino1.0?
Target Milestone: --- → Camino1.0
Comment on attachment 202010 [details] [diff] [review] v2, fixes bug 282941 also Now that the incendiary mammal has launched, do we want to get reviews on this and then start begging for checkin approval?
Flags: camino1.0? → camino1.0+
Attachment #202010 - Flags: superreview?(sfraser_bugs) → superreview+
This issue screams for a new user preference in annoyance blocking, or appearance. We seem to be going back and forth on what exactly is the Right Thing here to honor standards, but I think we need to take the view just like we have with Fonts and Colors. We have a user preference to override the styles for those elements, but not for form widgets. Looks like if we had this preference, then we could either be 100% standards compliant, or the user preference override "Don't Allow Web Sites to alter Form Style", selector would be honored.
Comment on attachment 202010 [details] [diff] [review] v2, fixes bug 282941 also Now that there's a branch strategy, can someone please tell me which flags need to be pulled on the bug in general and this patch in particular (aside from still needing the r+)?
Comment on attachment 202010 [details] [diff] [review] v2, fixes bug 282941 also r=pink requesting approval
Attachment #202010 - Flags: review?(mikepinkerton)
Attachment #202010 - Flags: review+
Attachment #202010 - Flags: approval1.8.0.1?
Comment on attachment 202010 [details] [diff] [review] v2, fixes bug 282941 also a=dveditz for drivers (Would have helped if you made it clearer this was cocoa-only code in the approval request)
Attachment #202010 - Flags: approval1.8.0.1? → approval1.8.0.1+
Checked in on the trunk, will bake there for a couple of days.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Landed on 1_8 and 1_8_0.
Keywords: fixed1.8.0.1, fixed1.8.1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: