Created attachment 128294 [details]
Appearance with and without scale(1)
I've been experiencing a problem with <input type="file"> HTML elements and using the CSS `transform: scale(1)` effect. When using the `scale` transform the "No file chosen" label on file inputs does not appear in it's normal place. Instead it appears offset down and right, and usually outside of the input element's bounding box, giving it the appearance of being absent.
I have included the relevant html snippet along with the CSS used to generate the error.
I have tested in Mac OS X 10.7.3 and Windows 7 Chrome 17.0.963.56 and in Mac OS X 10.7.3 with WebKit nightly Version 5.1.3 (7534.53.10, r108509).
Firefox does not exhibit this error, and the file path appears next to the form control which opens the file dialog.
I can provide additional screenshots if necessary.
====== HTML ======
<div class="modal_alert big up" id="anonymous_element_1">
<div class="modal_alert_content" id="anonymous_element_2"> <!-- this element has no associated styling -->
<div class="support_form" id="inline_support_container">
<input type="file" name="attachments" id="attachments_01" accept="image/gif,image/jpeg,image/jpg,image/png">
<div class="clearfix" style="clear:both;"></div>
======== CSS ==============
/* zoom: 0; */
border: 3px solid #EEF2F9;
-webkit-box-shadow: 0 1px 30px rgba(0,0,0,0.85), 0 0 24px rgba(156, 164, 178, 0.42) inset;
-moz-box-shadow: 0 1px 30px rgba(0,0,0,0.85), 0 0 24px rgba(156, 164, 178, 0.42) inset;
box-shadow: 0 1px 30px rgba(0,0,0,0.85), 0 0 24px rgba(156, 164, 178, 0.42) inset;
-webkit-transition: all .25s ease-out;
-moz-transition: all .25s ease-out;
-o-transition: all .25s ease-out;
transition: all .25s ease-out;
/* This was commented out during testing, but left here, in case it is relevant */
/* -moz-transform: scale(0);
transform: scale(0); */
/* Commenting or uncommenting this block causes the bug to appear */
/* -moz-transform: scale(1);
transform: scale(1); */
Created attachment 128374 [details]
Minimal repro attached. Note that as this repro demonstrates the text doesn't disappear, it is just shifted from where it should be and then clipped. The original test case's text was shifted completely outside the bounds of the clipping rectangle, whereas this test case demonstrates text that is only partially shifted out of the rectangle.
*** This bug has been marked as a duplicate of bug 69248 ***