723940 - File input position changed on focus()

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Scott]

Attachment: Demonstrates Firefox File Input Positioning Bug

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

I've written a jQuery UI plugin for pretty <input type="file" /> elements that works by absolutely positioning the original <input> element over top of other elements that I can easily control the style of. For backwards compatibility with older IE, I set a large font size on the <input> because IE will not bring up a file browser window unless the actual "browse" button is clicked.

Ultimately, I've discovered that Firefox will change the positioning of the input element once the "focus()" javascript method is called on it, which has a side effect of also moving sibling elements over to the left (despite the input being absolutely positioned).

Steps to reproduce:
1. Create a wrapper <div> with position relative, overflow hidden, and explicit width/height.
2. Place an <input type="file" /> inside of the wrapper div with position absolute (left/top 0), and a large font size (e.g., 50px)
3. Use javascript and call "focus()" on the input element


Actual results:

The input element suddenly shifts to the left on focus, making it seem like the position is now "right: 0" instead of "left: 0".

If there are other elements within the wrapping div, these elements are also pushed to the left, despite the fact that the input is absolutely positioned and should not affect the layout of these other elements.


Expected results:

Nothing. Everything should have looked the same after "focus()" than it did before the "focus()".

In addition, resetting the font size of the input element causes the input position to be reset to normal.

I've attached a very simple demo HTML file that reproduces this issue.

Comment 1

[Alice0775 White]

Confirmed on
http://hg.mozilla.org/mozilla-central/rev/e777c939a3f9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120203 Firefox/13.0a1 ID:20120203031138


Regression window
Works:
http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090610 Minefield/3.6a1pre ID:20090610042525
Fails:
http://hg.mozilla.org/mozilla-central/rev/4430cae50dad
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Minefield/3.6a1pre ID:20090611044033
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90d3e6d2cbb9&tochange=4430cae50dad

Triggered by:
cabb8925dcd3	Neil Deakin — Bug 178324, refactor focus by moving all focus handling into one place and simplifying it, add many tests, fixes many other bugs too numerous to mention in this small checkin comment, r=josh,smichaud,ere,dbaron,marco,neil,gavin,smaug,sr=smaug (CLOSED TREE)

Comment 2

[Neil Deakin]

Calling focus() on the file input should focus the Browse button and bring it into view. That's what I see happening and that is what should be happening.

So this bug is likely invalid, unless I'm misinterpreting what you're describing.

Comment 3

[Scott]

While I understand it's just my personal opinion - if this is the desired behavior, I think it sucks. If focusing the input element focuses the browse button within the input element, then how am I supposed to focus... the input element?

Is it standard behavior to shift the position of any input element on focus? This is behavior that I'm unfamiliar with and haven't been able to easily find a specification for.

It does appear that Webkit also does some position shifting on focus, though the browse button is already on the left side of the input in Webkit, so the effect is small.

If this is the desired behavior, then why doesn't it occur on click? Clicking the input throws a focus event first, but there is no position shift. However, focusing on the input by tabbing to it or by explicitly calling "focus()" does re-position the input.

Another consideration - why does the position shift of my absolutely positioned input element cause sibling elements in the same relatively positioned container to get shifted as well? My understanding is that an absolutely positioned element should be removed from the normal document flow and shouldn't affect the layout of sibling elements.

Imo, something is clearly amiss here...

Comment 4

[Scott]

Attachment: Demonstrates Sibling Element Position Shift

This attachment demonstrates the position shift of sibling elements of the input element when the input element is focused, even though the input is absolutely positioned.

Ultimately, for my purposes, if the position shift of the input is expected behavior, then that's fine. I don't think that is intuitive behavior, but the real issue to me is this position shifting of sibling elements.

Comment 5

[Neil Deakin]

(In reply to Scott from comment #3)
> While I understand it's just my personal opinion - if this is the desired
> behavior, I think it sucks. If focusing the input element focuses the browse
> button within the input element, then how am I supposed to focus... the
> input element?

You can't interact with the keyboard with the <input type="file"> element directly, only the browse button. A keyboard only user would expect to be able to 'tab' to the field and then open the file picker. The mechanism we use is to focus the button allowing the space bar to open the file picker.

> Is it standard behavior to shift the position of any input element on focus?

No, since the appearance and controls that make up the file input element are not specified.

> If this is the desired behavior, then why doesn't it occur on click?
> Clicking the input throws a focus event first, but there is no position
> shift. However, focusing on the input by tabbing to it or by explicitly
> calling "focus()" does re-position the input.

We assume that one can't click an element that isn't visible, so we change whether it is visible or not. However, focus() can be called on an element that isn't visible so we scroll it into view.

> Another consideration - why does the position shift of my absolutely
> positioned input element cause sibling elements in the same relatively
> positioned container to get shifted as well? My understanding is that an
> absolutely positioned element should be removed from the normal document
> flow and shouldn't affect the layout of sibling elements.

I don't know enough about element layout to answer this one. sorry.

Comment 6

[Scott]

(In reply to Neil Deakin from comment #5)
> You can't interact with the keyboard with the <input type="file"> element
> directly, only the browse button. A keyboard only user would expect to be
> able to 'tab' to the field and then open the file picker. The mechanism we
> use is to focus the button allowing the space bar to open the file picker.

Ok, that makes sense to me.

> We assume that one can't click an element that isn't visible, so we change
> whether it is visible or not. However, focus() can be called on an element
> that isn't visible so we scroll it into view.

I think I see what you're saying here - this makes my "bug" make sense to me, too. Originally, I thought Firefox was altering the position of the input element, but if it's "scrolling" the content of the relatively positioned container in order to bring the browse button into view, then that explains why my sibling elements get shifted as well.

Comment 7

[Mounir Lamouri (:mounir)]

I tend to think we should mark this as WONTFIX. Does that seam reasonable?

Comment 8

[Scott]

Yea, in the end it doesn't sound like a bug. Thanks, Neil, for helping me understand what was going on here. Scrolling the container div back left on the input's focus event is a much cleaner work-around than toggling the input's font size.