Build Id: Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/20091026 Fennec/1.0b5pre and Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a1pre) Gecko/20091026 Fennec/1.0b5pre Steps to Reproduce: 1. Go to www.gmail.com Actual Results: The Form UI doesn't pop-up on page load when the username field is highlighted automatically by Google. This leads to a weird user experience as the next step is to click on the password field which then does bring up the Form UI and zooms into the correct area. Expected Results: The Form UI should acknowledge highlighted form fields on page load.
Interesting. Mobile Safari does not automatically set focus to the web page when loaded. So the user must "touch" the field, which starts the assistant. Fennec does auto focus the document when loaded.
Mobile Safari avoids this problem by not auto-focusing fields in a page. This is probably a side-effect -- the more likely design reason for this is that a focused field would require the softkeyboard to be brought up, and that would cover a lot of the page when the user may not have intended to do anything with the field.
Form assistant bar or no, we must not auto-zoom to an auto-focused field when you load a webpage -- this would run contrary to our goal of showing the page overview when you encounter a page. It would also be very annoying on pages where the user did not intend to use the auto-focused field (unlike google). So, we _could_ follow mobile Safari's example and just not auto-focus any fields, making the user tap on them first. There's is some value, though, to being able to go to a page and just start typing and hit enter to do a search. A compromise position might be just to do what we do now -- auto-focus, so the user can start typing, but not display the form assistant until the user taps on a form element. An enhancement to this would be to - auto-focus as the site demands, but not bring up the form assistant and not zoom - if the user starts typing, show the bar but not zoom -- this puts the relevant controls on the screen without being too visually jarring - when the user presses "previous" or "next", the zooming takes over as usual Down the road, when we're looking at more devices with softkeyboards, we'll probably want to block autofocusing fields instead.
In fact, after having been so clever in the last comment, all of this is dominated by the soft-keyboard issue. Not only should the form assistant not auto-pop-up on page load, as is the summary of this bug, but we shouldn't even be auto-focusing fields on page load. I'm glad I could have this little discussion with myself.
Opening new bug for not auto-focusing fields on page load: Bug 532738
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
I think this bug needs to be opened until the resolution of bug 532738. The result of that bug will determine if this is fixed or invalid...not before that happens.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I disagree -- the founding issue of this bug is that "Form UI doesn't auto pop-up on page load." As I mentioned at the beginning of comment 3, I don't think that it _should_ auto pop up.
Ah, I see what you mean. I'm moving this to verified wontfix now.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.