Open
Bug 226386
Opened 21 years ago
Updated 2 years ago
Should not change focus in onload() when the user changed it before the load is complete
Categories
(Core :: DOM: Core & HTML, enhancement, P5)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: relf, Unassigned)
References
Details
I find myself often facing the following problem. Suppose I'm loading a page with Username and Password fields and a lot of graphics and other "heavy" stuff. Using dial-up, the loading process is quite slow and I start filling out the form elements as soon as they appear. I type user name Username field, then switch to Password field and type a password there. But suddenly I discover that Mozilla finished page loading and set up cursor to Username field. And I'm typing my secret password in plain text there. Sometimes it's even worse: I find out that I typed (a part of) the password in the Username field after I have clicked Enter and screwly filled info has been submitted. It would be very useful if Mozilla doesn't reset cursor position to default if the user changed cursor position during page loading process.
Comment 1•21 years ago
|
||
It's not really Mozilla's fault -- the page is specifically focussing the field when the page has finished loading. Not sure what we can do about this. There are plenty of legitimate cases undistinguishable from this one.
Reporter | ||
Comment 2•21 years ago
|
||
But is it possible not change focus if the user took control over it during page loading? Or at least make this feature optional?
Comment 3•21 years ago
|
||
We could make .focus() one of the optional features, I guess.
Assignee: form → general
Component: Layout: Form Controls → DOM HTML
Comment 4•21 years ago
|
||
I see another variant: I load many pages simultanealy (?) in some tab diferents. If the pages do ....focus(), when I'm writing in the first, I see me with de focus in the second o the thirth. Is it possible (uf, my English, I'm sorry) if one page in a tab in background set the focus, set the focus for this tab, but not for all navigator? I try to see: I'm in my tab, when I writing, but if I switch to the another tab, the focus is in the selected tab. Regards. Eduardo.
Updated•19 years ago
|
Summary: Should not reset cursor position which was altered during page loading → Should change focus in onload() when the user changed it before the load is complete
Updated•19 years ago
|
Summary: Should change focus in onload() when the user changed it before the load is complete → Should not change focus in onload() when the user changed it before the load is complete
Comment 5•19 years ago
|
||
*** Bug 314590 has been marked as a duplicate of this bug. ***
Comment 6•19 years ago
|
||
*** Bug 263129 has been marked as a duplicate of this bug. ***
Comment 7•19 years ago
|
||
*** Bug 314154 has been marked as a duplicate of this bug. ***
Comment 8•18 years ago
|
||
*** Bug 328770 has been marked as a duplicate of this bug. ***
See Also: → https://launchpad.net/bugs/24398
Comment 11•13 years ago
|
||
When loading my webmail page, godaddy has a few large images. Very stupid of godaddy. So the HTML loads, I start tying name and password, and partway through the password the page finishes loading and Firefox moves the focus back to the name field. So some of my password is then typed into the name field. Yikes! Please, never allow a change focus whilst the user is typing. Never, even if the page tries to do this when loading finishes. Or, as the initial poster in this old bug suggests, don’t change focus if the user has done so. Thank you.
Comment 12•13 years ago
|
||
Webpages should use autofocus instead of |.focus()|. That would solve this issue. Though, I don't know if we should block |.focus()|, I fear that could break some websites.
Assignee: general → nobody
Comment 13•13 years ago
|
||
It might be that this problem happens at times other than on-load. Hence my suggestion of “never allow a change focus whilst the user is typing”. If I have typed in the last two seconds (configurable?), focus belongs to me not to Firefox and not to the webpage.
Comment 14•13 years ago
|
||
I agree with Mournir Lamouri that this problem is may be complicated than I first thought when I posted a duplicate bug a few years ago, and welcome his introduction of debate into this discussion I do, however find his suggestion that websites should use autofocus unhelpful. I suspect the majority of web developers are not accessibility gurus who have the time to pay attention to issues like this. I would like to prompt for examples where a broken refocus would cause an issue to the user. I can think of an example where this might break the website, but doesn't affect the user much: auto-advancement to the next field when the character limit is reached in, for example, keys that are broken by spaces for ease of use (can't remember the term for this right now). I feel the next stage of discussion should be about when and where focus can be altered by a webpage or the gui, and if we can isolate these instances if needed One such case is password fields. I believe it is a critical security flaw that a user's password can be revealed to anyone watching the screen, be it in the workplace or over a projector screen. (@Mournir Lamouri I hope you won't suggest "learn touchtyping" :) ) Until further discussion on this issue, I move that refocussing should be disabled for password fields whilst the user is typing. Can we agree on this?
Comment 15•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•