DESCRIPTION: input[type="file"] does not style properly for normal, :hover or :focus. STEPS TO REPRODUCE: view a test case I have for bug # 41819. (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12896) ACTUAL RESULTS: no expected styling as with the other form results shown in testcase. except that when you :hover the over the element that you can see in back of the button... red background color appears (the same result for :focus). EXPECTED RESULTS: Should style the same as other form elements in testcase. DOES NOT WORK CORRECTLY ON: Win98 build 200091505 (9-14-00 nightly build I think)

Reporter: Should the button change colour too, in your opinion?

Taking QA since Chris is on sabbatical.

Hey Ian, I know this used to work. I just checked my NAV6 PR2 and the styling worked except for the :hover & :focus but that was bug #41819. To answer your question... I think that the file path text input should style like the input[type="text"] while the button should style like the submit buttons. What do you think is causing the input[type="file"]:hover styling behind the button? I noticed that this did not occur in PR2 timeframe either. BTW: I received the okay to create some regression pages on our site servers. Do you just want html form testers?

Ian, I also think the when you get to this bug's root, you might solve bug # 52815.

Well, we are treating INPUT type=file to be equivalent to: <input type="file"> <input type="text"> <input type="button"> </input> This may be fixed by using XBL for widgets. Why do you think the button should not have the :hover style? It is part of the file input just as much as the text field, after all.

Ian, I think that the input[type="file"] SHOULD render all psuedo classes. Currectly as of build 2000092205 win98 build, input[type="file"] does not style at all. Look at the test case for bug # 41819 (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12896) All form controls render the correct styling EXCEPT the input[type="file"]! Again I think that the input[type="file"] should render the "path" part like a type="text" while rendering the "browse" button like the other buttons in the test case.

I agree that it SHOULD style the text and button the way the others are styled, but I think the input file is really considered to be a single element. And i don't think HTML4.x or CSS really provides for a way to style these "sub-elements." And Ian is correct, that currently the sub-element text and button pick style via inheritence, we will be trying to "disconnect" that in the next release.

I am a bit confused here... you said "pick style via inheritence" from what. In my testcase, I declared the input "button" and "text". It does not get it from there. Are you saying that it gets styling from the general html.css inputs? I do also want to point out that the since you fixed the bug # 53744, you can again see that whatever "object" is "behind" the browse path button, mozilla is trying to style that instead of the file input. I will add a screenshots showing this for :focus and :hover. I think this "phantom" object is behind my bug # 52815.

see what I mean on how it seems that Mozilla is now styling whatever "object" is behind the browse button?

Yes, the text and button elements get there style from html.css or if ijn your style sheet you are styling all butons: input[type="button"] { .... } The button inside the input file element will get that style. When you style the input file for hover or for focus it is only going to effect the input file "container" which is that obecjt behind the button and th text. You could style the button inside the input file separately: input[type="file"] > input[type="button"] { ... } but I won't guarentee that that will always work, because in the future we are going to try to file this, so the button won't pick up any "generic" button rules from the css. hover and focus rules are not intended to affect the text or the button. The are suppose to affect the input file itself (the element behind the controls). Think of the input file as an atomic object and that you cannot get access to or style anything inside of it. I think it is really a limitation of HTML 4 that you cannot style the controls "inside" the input file element.

Hey Rod, are you hinting that I need to start reading up on XBL widgets...

No, I wasn't hinting at that, but at some point we may convert all the html form controls over to use XUL/XBL widgets.

rod, Because of your good explaination, I'm marking WONTFIX. :-)

sorry about the SPAM.

woops, I mean dup of bug 52500 (CSS Styles applied to INPUT TYPE FILE). again sorry about the SPAM *** This bug has been marked as a duplicate of 52500 ***

rubber stamp verify -- they look the same... ;-)