171598 - -moz-appearance for input[type="image"] should be none

Status: VERIFIED FIXED

(Core Graveyard :: Skinability, defect)

Description

[Tim Hill]

-moz-appearance for input[type="image"] (probably type="hidden" too) should 
be "none" in forms.css.  Otherwise nsITheme draws the textbox appearance under 
the image (see the imdb.com Go button).

Comment 1

[Tim Hill]

Attachment: Patch to forms.css

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 101074 [details] [diff] [review]
Patch to forms.css

sr=bzbarsky

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Perhaps a better fix would be to start a rule with the selector

input:not([type]), input[type="text"], input[type="password"], textarea

and move the existing -moz-appearance for |input| and |textarea| there?  (It
would be nice to migrate other declarations to such a rule as well to avoid the
mess we have with non-text inputs having to override all the stuff for text inputs.

Comment 4

[Tim Hill]

Attachment: Patch to forms.css 2

ok I added a rule for single-line inputs, moved -moz-appearance and a few other
obviously text input related properties there, and got rid of the
-moz-appearance and -moz-binding overrides.

Comment 5

[Tim Hill]

Attachment: Patch to autocomplete.xml

Yay, that breaks the autocomplete control since it uses an <html:input
type="autocomplete" internally, which as far as I can tell serves no purpose. 
Here's a patch to make autocomplete use input type="text" instead.

Comment 6

[Tim Hill]

*** Bug 184810 has been marked as a duplicate of this bug. ***

Comment 7

[Adam Hauner]

On this bug is something strange - it was filled 29-09-02, but it's not visible
 in 1.2 final (testcase of duped bug 184810 is okay) and IMHO wasn't visible in
builds around/before 03-12-02. So why is visible in actual builds? If visibility
of this bug was changed in last days, maybe fix should go to 1.3a branch.

Comment 8

[kitchin]

(Probably related.)

An input image with border=1 causes bad resizing.  <input type=image...
border=1> squeezes the image by 2 pixels in each direction.

Maybe this should be a separate bug, but I'll file it here and see what you
think.  My attachment also gives a test case for the transparacy problem, since
I don't see a working test case here (http://www.imdb.com is ok for me, but my
browser does have the bug).

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021214 Phoenix/0.5

Comment 9

[kitchin]

Attachment: Test case: border=1, and transparency problems.

See my comment above.

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 190608 has been marked as a duplicate of this bug. ***

Comment 11

[Boris Zbarsky [:bzbarsky]]

*** Bug 190952 has been marked as a duplicate of this bug. ***

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** Bug 191057 has been marked as a duplicate of this bug. ***

Comment 13

[Adam Hauner]

More visible example:
http://www.slunecnice.cz/

Comment 14

[Brian 'netdragon' Bober]

Bug 184359 is fixed, but image 3 of google still differs in horizontal size 
from image 4. Therefore, this bug appears not to be fixed yet.

Comment 15

[Tim Hill]

A separate bug should be filed for that, it's a separate issue from this bug.

Comment 16

[Brian 'netdragon' Bober]

True... The initial bug was about the second part of the testcase.

And it is a different issue. soo... VERIFIED.

kitchin2: Can you file a different bug on the resizing if none exists?

Comment 17

[kitchin]

OK, the border=1 resizing bug is now Bug 191967.

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 192536 has been marked as a duplicate of this bug. ***

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 192670 has been marked as a duplicate of this bug. ***

Comment 20

[Sébastien Delahaye]

*** Bug 196778 has been marked as a duplicate of this bug. ***