717361 - don't autofocus fields on page load

Status: RESOLVED DUPLICATE of bug 1400878

(Firefox for Android Graveyard :: General, defect, P5)

Description

[Madhava Enros [:madhava]]

Some pages autofocus an input field on page load (i.e. the desktop version of google.com). On mobile, focusing a field brings up the keyboard, which is too big a visual change to impose on users without their having asked for it. Can we just not autofocus input fields? I think we were doing it this way in XUL fennec.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

This was wontfixed in bug 701741.

Comment 2

[Aaron Train [:aaronmt]]

Attachment: Nightly (01/13) Screenshot

This is what http://wwww.google.com looks like without touching the device on a Google phone (Nexus S Android 4.0.3).

Comment 3

[Martijn Wargers (dead)]

Can this be closed as a dupe of bug 701741 then?

Comment 4

[Aaron Train [:aaronmt]]

This is awkward on devices that invoke full-screen landscape keyboards. If I am using my phone in landscape, and decide to hit google.com, I go from keyboard straight to a keyboard. I never actually see the site. This is not the case in any other browser.

On another note, I recently did a page comparison and you can see what a user might see on page load in somes cases the keyboard invoked provides a different experience http://people.mozilla.com/~atrain/mobile/Evangelism/01-2012-topsites-01/topsite-01-ics/topsite-01.html

Comment 5

[Madhava Enros [:madhava]]

A lot of desktop sites will autofocus the field because there's no cost to doing so in a world with a hardware keyboard, and it's cuts out a step for the user who _does_ want to use the field.

With a SKB on mobile, though, the keyboard obscures a lot of the page (not to mention how much of it it obscures in landscape), making the initial view of the page a lot less usable. The user loses a lot of context what what page he or she is on.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

I can say, definitively, that in the case of google.com, autofocusing the search box is the right thing to do. I also believe that it is the website, not us, that should make that decision. If the website says "the absolute #1 thing that people are going to do when they come here is type in this box" then we should make that work. There will of course always be dumb websites that autofocus an input field that isn't their primary use case. We should not optimize for the dumb website case though.

Comment 7

[Martijn Wargers (dead)]

I've mentioned this in a different bug before (I think on the one where vingtetun was working on the ime code for a potential solution).
You could also think of other solutions to the problem.
For instance, the website could still be allow to autofocus the input field, but the vkb simply doesn't come up in cases where the page hasn't finished loading yet.
Or you could disallow the vkb to appear when an input is focused, when the user hasn't tapped on the page yet.

Comment 8

[JP Rosevear [:jpr]]

(In reply to Brad Lassey [:blassey] from comment #6)
> I can say, definitively, that in the case of google.com, autofocusing the
> search box is the right thing to do. I also believe that it is the website,
> not us, that should make that decision. If the website says "the absolute #1
> thing that people are going to do when they come here is type in this box"
> then we should make that work. There will of course always be dumb websites
> that autofocus an input field that isn't their primary use case. We should
> not optimize for the dumb website case though.

I generally agree here, but it does change the user experience, ie wikipedia and google:
http://people.mozilla.com/~atrain/mobile/Evangelism/01-2012-topsites-01/topsite-01-gingerbread/topsite-01.html

Comment 9

[Madhava Enros [:madhava]]

I disagree that this is the right tradeoff. Look at what happens when you load wikipedia.org.

Comment 10

[Madhava Enros [:madhava]]

For comparison, neither the default browser on Android nor Safari on iOS autofocus fields on page load.

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Madhava Enros [:madhava] from comment #9)
> I disagree that this is the right tradeoff. Look at what happens when you
> load wikipedia.org.

what are you going to do from wikipedia's or google's home page besides do a search? Those are both good examples of the right behavior to me. 

Though, somewhat unrelated I'm not sure why we scroll that input field to the top, we should scroll such that it is just visible above the keyboard. If we did that right, would your opinion change?

(In reply to Madhava Enros [:madhava] from comment #10)
> For comparison, neither the default browser on Android nor Safari on iOS
> autofocus fields on page load.

That's been brought up before, and it doesn't really carry much weight for me.

Comment 12

[Madhava Enros [:madhava]]

(In reply to Brad Lassey [:blassey] from comment #6)
> I can say, definitively, that in the case of google.com, autofocusing the
> search box is the right thing to do. I also believe that it is the website,
> not us, that should make that decision. If the website says "the absolute #1
> thing that people are going to do when they come here is type in this box"
> then we should make that work. There will of course always be dumb websites
> that autofocus an input field that isn't their primary use case. We should
> not optimize for the dumb website case though.

So, if we were getting the right versions of websites most of the time, this would be true -- but, by and large, we get desktop versions where the site author has made a decision to autofocus based on an assumption of a desktop browser and a hardware keyboard. There is no cost to doing this in that context, whereas here, in a mobile browser, there is a lot of cost: the software keyboard obscures a lot of the page, and the top of the page, useful for knowing what you've just loaded, is often scrolled away to get to the field in question.

The "dumb website" thing isn't our fault, but it is our problem. People are not seeing what they're expecting to see when they load a lot of pages in our browser.

Comment 13

[Dão Gottwald [:dao]]

browser.autofocus controls the autofocus attribute. I think google.com doesn't use that, though.

Comment 17

[David Tenser [:djst]]

Could we get an update on the status of this bug and who ultimately decides? I filed a bug thinking that this would be up to UX to decide, but I see now in the bug it was duped against that there is disagreement and seemingly no consensus. Does target milestone=Future mean that there is actually agreement that this would be an improvement, but we just don't think it's a high priority? Or does it mean that there is disagreement and that we're deferring the decision? I'm only asking because the bug has been idling for the last five months.

The rationale I was using when filing bug 769179 was:

1. On a desktop computer, the keyboard and mouse are two separate user interfaces. The keyboard is used to type, and the mouse is used to navigate on the page. This means that putting focus in the text box is a convenience on the desktop, since it simplifies typing without interrupting the navigation on the page. 

On a mobile device (without a physical keyboard), typing and navigating are both done through the same interface: tapping the screen. Because of this, any website's focus on a text box is no longer a convenience and instead gets in the way of navigation. (Website authors likely didn't consider small devices without a physical keyboard when deciding to focus on the text box. I've yet to see this behavior on a mobile-optimized site.)

2. Typing is less convenient on a small device compared to a desktop computer with a dedicated keyboard, which means we should probably always strive to optimize for the navigation interaction over the typing interaction. 

In other words, even if there are some examples of entirely type-centric websites where this extra tap on the screen to pull up the soft keyboard would be seen as an inconvenience compared to the current behavior, those type of websites are likely a minority use case on mobile devices since they're not optimized for small screens in the first place.


To flip things around, what would be the added cost/inconvenience of not showing the soft keyboard as soon as a website puts focus in a text field? It seems it amounts to an extra tap in the text field you want to type in. That seems like a very small cost compared to the convenience of not getting half of your screen covered up by a keyboard that sometimes pops up when you least expect it and didn't intend to type.

As an extra, anecdotal point, I remember seeing a Google Play market review about Firefox being a little "trigger happy" with the soft keyboard -- I suspect that person was referring to this behavior. 

Lastly, I note in comment 11 that what other browsers do carry little weight (which I can somewhat relate to), but it should at least be said here that our current behavior is unique to Firefox -- on Android, no other browser does this that I've tested with (Chrome, stock Android, Opera Mobile, Opera Mini). So if we genuinely believe our behavior is better, we should make that explicit and WONTFIX this bug.

Thanks,
David

Comment 18

[Kevin Brosnan [Ex-Mozilla]]

The Product manager for Firefox for Android would be the person to decide this (Karen).

Comment 19

[Mark Finkle (:mfinkle) (use needinfo?)]

Just to add more detail: Most of the "bad" sites that show this "keyboard on load" behavior are actually desktop sites. It has been argued that mobile sites would/should be better behaved and would not auto-focus textboxes on pageload.

Also mentioned previously: Should we stop showing the keyboard on any script-focused textboxes? Should we only show the keyboard for user-focused events?

And yet more: If we decide to only stop showing the keyboard for "after pageload" script-focus events, when is "after pageload" defined? It's very common for site to delay focus using a setTimeout. Even without a setTimeout, it's likely running scripts will cause the focus event after "DOMContentLoaded" and "load" and "pageshow".

Comment 20

[Matt Brubeck (:mbrubeck)]

(In reply to Mark Finkle (:mfinkle) from comment #19)
> Just to add more detail: Most of the "bad" sites that show this "keyboard on
> load" behavior are actually desktop sites. It has been argued that mobile
> sites would/should be better behaved and would not auto-focus textboxes on
> pageload.

If we want, we could disallow focus-on-load for "desktop" sites but allow it for mobile-optimized sites (based on viewport metadata).

Comment 21

[David Tenser [:djst]]

(In reply to Mark Finkle (:mfinkle) from comment #19)
> Also mentioned previously: Should we stop showing the keyboard on any
> script-focused textboxes? Should we only show the keyboard for user-focused
> events?

That would be my proposal at least, and it seems easy enough to do. Even though I don't know of many mobile-optimized pages that actually focus a textbox, it seems like a small sacrifice for the user to then tap once before typing.

Comment 22

[Matt Brubeck (:mbrubeck)]

(In reply to Mark Finkle (:mfinkle) from comment #19)
> Also mentioned previously: Should we stop showing the keyboard on any
> script-focused textboxes? Should we only show the keyboard for user-focused
> events?

We used to do this (bug 641836) but it was backed out (bug 688783) because it broke sites like etherpad (bug 669995) that relied on focusing input elements via script, often in response to events generated by a different element.  So we need to make that implementation a lot more robust at handling these edge cases if we want to re-enable it.

Comment 23

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Matt Brubeck (:mbrubeck) from comment #22)
> (In reply to Mark Finkle (:mfinkle) from comment #19)
> > Also mentioned previously: Should we stop showing the keyboard on any
> > script-focused textboxes? Should we only show the keyboard for user-focused
> > events?
> 
> We used to do this (bug 641836) but it was backed out (bug 688783) because
> it broke sites like etherpad (bug 669995) that relied on focusing input
> elements via script, often in response to events generated by a different
> element.  So we need to make that implementation a lot more robust at
> handling these edge cases if we want to re-enable it.

At one time, I had hoped we could create a mode where script-focused events would focus the editbox, but not show a keyboard. I hoped that somewhere in our IME code we could skip the "show the keyboard" behavior.

Comment 24

[Mark Finkle (:mfinkle) (use needinfo?)]

... so the editbox would still be focused, but show no keyboard. That should keep scripts from failing.

Comment 27

[(inactive) Jim Chen [:jchen] [:darchons]]

(In reply to Mark Finkle (:mfinkle) from comment #23)
> (In reply to Matt Brubeck (:mbrubeck) from comment #22)
> > (In reply to Mark Finkle (:mfinkle) from comment #19)
> > > Also mentioned previously: Should we stop showing the keyboard on any
> > > script-focused textboxes? Should we only show the keyboard for user-focused
> > > events?
> > 
> > We used to do this (bug 641836) but it was backed out (bug 688783) because
> > it broke sites like etherpad (bug 669995) that relied on focusing input
> > elements via script, often in response to events generated by a different
> > element.  So we need to make that implementation a lot more robust at
> > handling these edge cases if we want to re-enable it.
> 
> At one time, I had hoped we could create a mode where script-focused events
> would focus the editbox, but not show a keyboard. I hoped that somewhere in
> our IME code we could skip the "show the keyboard" behavior.

That should be very doable.

Comment 30

[jim d]

Though I'm using the desktop browser (vs. mobile)  I'm also noticing frustrating autofocus behavior. Specifically, on pages where onload takes a few seconds to fire.  

For example, I maintain a login form where the 'username' field has an autofocus attribute.   Occasionally, it takes a few seconds before onload fires (due to cdn-hosted script, i suspect).   In these situations,  a user may have filled out the username field and moved on to the password field.  As he/she types, the onload event fires and focus abruptly changes from from the password field to the username field.