307113 - browser forces keyboard refocus after finish loading the web page even if the user interacted with the page before finish loading

Status: VERIFIED INVALID

(SeaMonkey :: General, defect)

Description

[Mihai Hanor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728

My Internet connection is not so fast... when I'm opening http://mail.yahoo.com/
my browser may not finish loading the web page. While loading the page, I manage
to type my account name and part of the password and very frequently I'm caught
with the keyboard refocus while typing my password in the appropriate text box.
When after the refocus happens, I wake myself up and realize that I've typed the
first  part of the password in the right place, adn the 2nd part in the user
name text box, because the browser refocuses the keyboard input on the user name
text box. This is very frustrating some times. With IE6SP1 this doesn't happend.
Mozilla behaves well when change the browser's address text box from the
navigation toolbar while a web page loads (after finishing loading, the browser
doesn't refresh the address text box with the URL of the page that was loading -
this is a good behaviour). This behavior with the keyboard refocus inside a web
page  after the browser finishes loading it should be corrected.
I'm using Mozilla 1.7.11 under Windows 2000 SP4.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Mihai Hanor]

I have switched to SeaMonkey 1.0 final. The issue is still occuring.

Comment 2

[Andrew Schultz]

Focus gets shifted to the username box because the page itself specifies that it should happen (it's trying to be helpful):

function setFocus() {	document.login_form.login.focus(); }
window.onload = setFocus;

I'd be very surprised if that doesn't work in IE.  It actually probably used to not work with Mozilla (before <1.7)

Comment 3

[Mihai Hanor]

IE doesn't refocus. SeaMonkey 1.0 final does. Just test it.
The only reason I think that something should be done to correct this is because sometimes I'm faster at typing the account name than is the browser at finishing downloading the page, so I find myself typing a piece of the password in the account name text box, even if I selected the password's text box, the browser shifted the focus and I wasn't paying attention.

Comment 4

[Andrew Schultz]

> IE doesn't refocus. SeaMonkey 1.0 final does. Just test it.

I don't run windows.  I can't test IE.

Comment 5

[Eyal Rozenberg]

This is indeed quite an annoying problem. Another example is my university's webmail (webmail.technion.ac.il) which loads some of the page fast and the rest of it slow, so you are tempted to start entering your username and password. But usually when I'm in the middle of entering my password, the keyboard focus moves to the username box since loading is complete, and half my password becomes visible.

This could still be a dupe, but confirming for now.

Comment 6

[Brent]

This problem has bothered me for years.  NOT good for security to have the cursor jump to a clear text box when in the midst of typing a password.  Happens in every version of Mozilla and Firefox I've tried, including Firefox 2.0.0.1.

This problem happens on many pages when they are finished loading.  I've seen it on Yahoo, Google, and Hotbot.  Even https://bugzilla.mozilla.org does it-- the cursor will jump back to the "find a bug" text box even if the user has moved on to the login and password text boxes before the page has finished loading, or moved the cursor to the URL input box or the search engine input box at the top of the browser window.  There are also many web pages, even pages that have a text box, such as Slashdot with its search box, where this is not a problem.

I think the problem is not respecting the order in which the user is sending input.  If the user's last action was to start a web page load, then it's ok for the browser to move the keyboard focus to the first text entry box.  But if the user has started a web page load and then done something more, neither the browser nor the web page should interfere with the user.

Some possible solutions:  1. have a flag for whether the last user action was to load a web page.  If that flag is true, then honor web page focus requests, otherwise ignore such requests.  Or 2. change the sequencing so that a web page focus event happens as early as possible during a page load rather than being the final event on completing the loading of a web page.

Comment 7

[Brent]

Another solution:  3.  Add another preference (to about:config) so that users can control whether web pages' setfocus() commands should be heeded.

Comment 8

[Tony Mechelynck [:tonymec]]

The Javascript snippet shown in comment #2 means "give focus to the login input box once the window has finished loading" so the incriminated behaviour is expected behaviour. => INVALID (the problem might be a Yahoo bug but it is not a Mozilla bug).

About comment #5 and #6 (intentionally deviate from the standard, possibly depending on a flag) you may open a new bug, of "enhancement" severity, but I expect that it will be resolved WONTFIX

I think that the most promising solution (if the problem is still seen) is to discuss the problem with the Yahoo webmaster, and try to convince him/her to remove the "window.onload = setFocus;" line and possibly the previous one too.

Comment 9

[Eyal Rozenberg]

(In reply to comment #8)
I would disagree with how you describe the code in comment #2. Such code can be IMHO considered to assume that the user does not interact with the window _during_load_.

Also, you mention a deviation from the standard - can you say which standard? I'm not very well-versed in web standards but it seems strange that a standard would require this to be the behavior.

I think option 2. in comment #6 is a good idea and would result in consistent behavior; however, it may not be possible to separate the command/s to set focus from the rest of the code in the onload handler, so for practical reasons I think option 1. would be right. If the user didn't touch anything during load then it's the same behavior as today, and hopefully does not break any standard.

In light of the above I would ask that this bug be reopened. Also, I think it is somewhat inappropriate to close this a bug without at least considering the opinion of people, who have reported it / have expressed concern with it, about whether it should be closed.

Comment 10

[Tony Mechelynck [:tonymec]]

(In reply to comment #9)
> (In reply to comment #8)
> I would disagree with how you describe the code in comment #2. Such code can
> be IMHO considered to assume that the user does not interact with the window
> _during_load_.
> 
> Also, you mention a deviation from the standard - can you say which
> standard? I'm not very well-versed in web standards but it seems strange
> that a standard would require this to be the behavior.

The standard which mandates that the onLoad event is fired after the page finishes loading. If a JS method is triggered by this event, it will happen at the end of page-load. The fact that such an onLoad method moves focus may be a bug or a feature depending of POV, but it's a Yahoo bug or feature, not a Mozilla one.

> 
> I think option 2. in comment #6 is a good idea and would result in
> consistent behavior; however, it may not be possible to separate the
> command/s to set focus from the rest of the code in the onload handler, so
> for practical reasons I think option 1. would be right. If the user didn't
> touch anything during load then it's the same behavior as today, and
> hopefully does not break any standard.

option 2 breaks the definition of onLoad; option 1 ignores some JS routine explicitly written into the page by its author. Unless there is a security reason for this disobedience, this is a slippery path to take.

> 
> In light of the above I would ask that this bug be reopened. Also, I think
> it is somewhat inappropriate to close this a bug without at least
> considering the opinion of people, who have reported it / have expressed
> concern with it, about whether it should be closed.

Comment 11

[Philip Chee]

Verified INVALID.