select (dropdown) and input button rendered oddly and non-Aqua

NEW
Unassigned

Status

()

Core
Widget: Cocoa
12 years ago
8 years ago

People

(Reporter: mark saint, Unassigned)

Tracking

({testcase})

Trunk
PowerPC
Mac OS X
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051229 Camino/1.0b2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051229 Camino/1.0b2

inconsistancy possibly due to camino correctly displaying css which is confilicting with standard aqua behavour.

Reproducible: Always

Steps to Reproduce:
1. scroll down in the first left hand iframe
2. note the form dropdown components, they clearly are not displayed correctly
3.



Expected Results:  
display dropdown boxes with standard aqua interface
Wierd.  Safari gets it right, but even Fx does not render the odd way we do.  (0.8.4 renders the text portion as a gfx select but the arrow is still messed up.)

I'll try to dig into the css later today.
Summary: visual errors on dropdown form component → select (dropdown) rendered oddly and non-Aqua
Chris, Wevah, if either of you get a chance, can you take a look at this?  Nothing's jumping out at me here.

frame with selects: http://www.newstoday.com/certified/certified_content.php
style sheet 1: http://www.newstoday.com/_lib/css/nt_common.css
style sheet 2: http://www.newstoday.com/_lib/css/nt_frame.css

Comment 3

12 years ago
Looks to me like we're allowing styles to be applied to it somehow. Maybe related to our two SELECT styling bugs? (Bug 193232 and bug 315203)

cl

Comment 4

12 years ago
...which I see is pretty much what Mark said in the bug report ;)

Yet another reason why this half-functional CSS on form elements is a nightmare. I really think this should be all or nothing, and I prefer nothing. :-D

cl

Comment 5

12 years ago
More specifically, it looks like a background image is getting painted over the form control somehow. I can't seem to find what image it might be, though.

http://www.newstoday.com/_img/solid_line.gif

is the one used for the background in a lot of declarations there. I can't figure out any CSS that would cause it to render like it is on the link you posted, Smokey.

Wevah, any ideas on this one?

Sam, you know CSS pretty well too. See anything here that might be problematic?

cl
Jesse Ruderman's computed style bookmarklet doesn't show anything unusual in the style cascade for that element, either--the only changes are normal Camino select styling on the select, which means anything else would be inherited all the way from */html/body, and nowhere else do we see the strange image where the arrows go (that could explain Chris's image, if it's used as a border, though).

AFAIK we allow very little styling of the dropdown version of selects (maybe less than on input buttons) as they're real Aqua controls; it's the selects-as-boxes where we get into trouble....  

That said, still no clue what's really going on, and I likely won't be able to dig into it further or try to reduce it for a day or so.
A ha!  The ARIN Whois search button had a similar problem, and I started comparing notes.

This tag (or its xhtml equivalent) does really wonky things to our select and input elements:

<meta http-equiv="MSThemeCompatible" content="no">

The only question is *why* does this tag screw up our styles (oddly enough, changing that value to "yes" restores our styles).

This appears to be Camino-only (at least in Fx the testcase displays normal gfx widgets instead of the distorted ones we see).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Summary: select (dropdown) rendered oddly and non-Aqua → select (dropdown) and input button rendered oddly and non-Aqua
Created attachment 208266 [details]
screenshot of testcase showing distorted gfx widgets

Comment 10

12 years ago
It's used here:
http://lxr.mozilla.org/mozilla/source/content/base/src/nsContentSink.cpp#372
I've no idea why we would care about that on Mac.
That code was part of hyatt's original checkin for bug 169373.  I assume it was done because IE was doing it or something.  No idea whether we should be following this on the mac; chances are, if the page thinks it's styling controls enough not to want to deal with the Windows themes, the same ought to be true for the Mac ones.  But maybe I'm wrong.
A few thoughts:

1.  I don't know that it's appropriate to use a Windows theming declaration to disable native widgets on the Mac.  AIUI, if you disable Windows "native" widgets or whatever XP theme you're using, you still get a widget that looks more or less like a Windows widget (and not horribly out-of-place, though perhaps slightly so).  And themes on Windows have no comprable equivalent on the Mac; on the Mac, the choice is Aqua (mostly blue-and-grey widgets with a couple of red-yellow-green ones) or Graphite (everything's shades of grey), but a widget fundamentally looks exactly the same under either "theme".

2. Selects of the drop-down variety we basically don't want to style at all (other than font size of the closed widget so as not to break layouts), I think.

3. Despite having that declaration in the page head, the button at ARIN has absolutely no styling done to it, aside from anything it may inherit from ancestors: http://www.arin.net/whois/

Updated

11 years ago
Target Milestone: --- → Camino2.0

Updated

11 years ago
Assignee: mikepinkerton → nobody
QA Contact: form.controls

Comment 13

11 years ago
Moving to Widget:Cocoa
Assignee: nobody → joshmoz
Component: HTML Form Controls → Widget: Cocoa
Product: Camino → Core
QA Contact: form.controls → cocoa
Target Milestone: Camino2.0 → ---
Version: unspecified → Trunk

Updated

10 years ago
Assignee: joshmoz → nobody
You need to log in before you can comment on or make changes to this bug.