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

Status: NEW

(Core :: Widget: Cocoa, defect)

Description

[mark saint]

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

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

[Chris Lawson (gone)]

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

[Chris Lawson (gone)]

...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

[Chris Lawson (gone)]

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

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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).

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: testcase

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: screenshot of testcase showing distorted gfx widgets

Comment 10

[Simon Fraser [no longer active]]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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/

Comment 13

[Stuart Morgan]

Moving to Widget:Cocoa