Closed Bug 58724 Opened 25 years ago Closed 11 years ago

should autofill password while page is loading, not onload

Categories

(Toolkit :: Password Manager, defect)

Product:
Toolkit
Component:
Password Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 355063

People

(Reporter: tgodouet, Unassigned)

References

Details

(Keywords: perf, testcase, Whiteboard: [Snappy:P2])

Attachments

(1 file, 5 obsolete files)

PHP test-case
814 bytes, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m18) Gecko/20001027 BuildID: 20001027 Mozilla fills the textboxes of login and password only when the page has been completely loaded. Mozilla should fill this textboxes as soon as they appears (there is no need to wait the end of the download of all the images) Reproducible: Always Steps to Reproduce: go to bugzilla go to the login page wait and see ! Actual Results: Expected Results:
Attached file test case (obsolete) —
Steps to reproduce: 1. Load testcase (don't have to wait for image to load) 2. Enter a few chars for a username and password 3. Click "log in" and save the password (you'll end up at a 404 page) 4. Go back to the testcase 5. Shift-reload or click the location bar and hit enter Result: password doesn't show up until the image times out. Win98 branch build from 10/27 and a trunk build from 11/01 (can't test against today's trunk build because of bug 59125). I don't know whether this should be considered a bug or an enhancement request.
Status: UNCONFIRMED → NEW
Component: Autofill → Single Signon
Ever confirmed: true
Hardware: PC → All
Summary: autofill should occur as soon as possible → should autofill password while page is loading, not onload
Status: NEW → ASSIGNED
Target Milestone: --- → M25
Summary: should autofill password while page is loading, not onload → [y]should autofill password while page is loading, not onload
Target Milestone: M25 → ---
I've noticed this behaviour as well. It's *very* annoying, as a user (myself, as an example) may believe that Mozilla is not going to fill in the password field, try typing in it and have it fill in on top of them! For most sites I've managed to re-type name and password myself before Mozilla gets around to it, making the password autofill feature useless. The correct behaviour should be for Mozilla to wait for all of the necessary fields that it needs to autofill and, once they have been loaded, should fill them in immediately. BTW, what is the [y] in the summary? I've noticed [x], [y] and [z] appearing lately. :)
*** Bug 61189 has been marked as a duplicate of this bug. ***
Summary: [y]should autofill password while page is loading, not onload → should autofill password while page is loading, not onload
Whiteboard: [y]
Whiteboard: [y]
Adding new email address to CC list
adding self. This bug needs a milestone of at least 1.0
Target Milestone: --- → mozilla1.2
I have the problem Matthew describes almost every time I go to a page where I have prefills, especially the bugzilla login page. I make a change to a bug, I get the login page because my IP address has changed, I wait a second or so then start typing in my email address, then while I'm in the middle of typing the form fills in and I have to backspace over what I just typed. It makes wallet much less useful.
*** Bug 103541 has been marked as a duplicate of this bug. ***
*** Bug 87870 has been marked as a duplicate of this bug. ***
ccing hyatt. Hyatt, would this benefit from an approach similar to what's being taken for the link toolbar? The form controls could fire off custom DOM events when they appear, assuming they have no value filled in by default by the page.
It would be nice if a small Password Manager icon came up some where (say top right)in Mozilla as soon as a paticular login page starts loading. I could just the click the button to fill in my password without waiting for the page to load. Also I can also ignore the button if I do not want it to fill my password for me.
*** Bug 105415 has been marked as a duplicate of this bug. ***
Above comment was incorrect. Bug 105415 was not a dup of this bug but rather was a dup of bug 96131. This has been corrected in bug 105415.
There's a slow-loading ad image on the Netscape webmail login page, so my password often isn't filled for several seconds after the "Sign In" button appears. Adding perf keyword.
Keywords: perf
*** Bug 111415 has been marked as a duplicate of this bug. ***
*** Bug 115807 has been marked as a duplicate of this bug. ***
*** Bug 116237 has been marked as a duplicate of this bug. ***
*** Bug 120950 has been marked as a duplicate of this bug. ***
*** Bug 136342 has been marked as a duplicate of this bug. ***
*** Bug 143928 has been marked as a duplicate of this bug. ***
See also bug 138892, "form data only remembered for first form on page". Could the same fix work for both bugs?
This bug is a dup of bug 87070 which is assigned to HTML form controls. See Alex Bishop's comment 10 in that bug report. Then that bug got marked as a dup of this bug, so now it's been thrown back to password manager. I agree with bug 87070 comment 10 that this is a layout issue. So I'm assigning this to HTML form controls. It's up to them to call for the password-manager fill-in earlier in the game.
Assignee: morse → rods
Status: ASSIGNED → NEW
Component: Password Manager → HTML Form Controls
I think Morse meant bug 87870, not bug 87070.
*** Bug 155176 has been marked as a duplicate of this bug. ***
*** Bug 156399 has been marked as a duplicate of this bug. ***
*** Bug 157034 has been marked as a duplicate of this bug. ***
*** Bug 158431 has been marked as a duplicate of this bug. ***
*** Bug 159283 has been marked as a duplicate of this bug. ***
*** Bug 159654 has been marked as a duplicate of this bug. ***
*** Bug 159804 has been marked as a duplicate of this bug. ***
It is a pity that this bug still is not fixed in Mozilla 1.1 IMHO this is the only bug left in 1.1 that hinders in the dayly work with Mozilla. But maybe I am the only one left with a 56K Modem. This bug is not a problem with a fast line.
-->
Assignee: rods → jkeiser
Status: NEW → ASSIGNED
Keywords: mozilla1.3
> This bug is not a problem with a fast line Unfortunately, it is. It only takes a glitch on an image or banner server to make this bug highly annoying, no matter how fast the line is.
*** Bug 137831 has been marked as a duplicate of this bug. ***
I was thinking of reporting this incredibly irritating bug, but saw it was already reported. I was astonished to find it's been around for 2 years and not fixed. Some sites have big, slow images running off other (potentially non-working) servers, including Flash-based ad banners, etc, on their login pages. Having to wait an eternity for this **** to load for the autofillin to occur is insane.
*** Bug 187172 has been marked as a duplicate of this bug. ***
*** Bug 189912 has been marked as a duplicate of this bug. ***
*** Bug 193884 has been marked as a duplicate of this bug. ***
*** Bug 195619 has been marked as a duplicate of this bug. ***
Note that some sites have their own automatic filling of data fields from cookies, etc. As this may be unwanted, Mozilla should wait until those activities are triggered before over-writing those values, but it doesn't need to wait for extraneous image downloads.
How do you propose we tell whether "those activities" are going to be triggered sometime in the future? Crystal ball? ;) More to the point, any reasonable site will run such scripts from onload, which is in fact after all the images have loaded.
Actually, I would say that any reasonable site would do this on the server side, i.e. it would send the input fields already prefilled. What advantage would doing it with client-side scripts have? BTW, Boris, are you commenting in Bugzilla on your vacation, or are you now "back from vacation for real"? ;-)
Some sites just do some cookie reading and set the values into form fields within <script></script>. This processing gets done during page loading, which may be a long time before extranous banners get loaded. No crystal ball required to tell whether this has been done yet.
So you're suggesting we do the fill after we see </html>, basically? (note that I've yet to see a site that uses the technique you describe, but....)
Yes, that is what I'm suggesting. That would work fine for those sites with fields pre-filled by the server or other weird javascript methods. (For an example of the script method, see www.ual.com.) I'm not sure what should be done about the ones using onload though. Vaclav, there doesn't need to be an advantage for many sites to use client-side scripts. Just look at the number of sites that use javascript for things that could be better done with CSS or server-side or even plain HTML! In this case, however, there probably is an advantage: Doing so means they can send the same page to everyone, rather than generating separate ones for each user.
on a lot of sites the html code may be received very slowly (perhaps due to an overloaded server, or very slow scripts on the server, or because of a slow client connection) so it may be a long time before </html> is reached, when the login/form can be submitted as soon as </form> is reached.
*** Bug 203674 has been marked as a duplicate of this bug. ***
*** Bug 207138 has been marked as a duplicate of this bug. ***
*** Bug 212685 has been marked as a duplicate of this bug. ***
See also bug 221634, same bug for Firebird.
*** Bug 221674 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Keywords: mozilla1.3 → testcase
*** Bug 232796 has been marked as a duplicate of this bug. ***
*** Bug 235530 has been marked as a duplicate of this bug. ***
*** Bug 237193 has been marked as a duplicate of this bug. ***
Filling in as soon as it sees "</html>" (or actually the end of the document, since <html>, <body>, etc. are not required for a page to function) might be a problem (<sript src="fill_in_this_forum.js">, for example). But if a script is writing values to a form, chances are that they are overwriting the existing values, so it will be a harmless redundancy (unless they use += instead of =, but I don't think anyone would do that). Any status of this bug (it is from 2000 and still exists in 1.7). Marking this bug as fixed (when it gets there) might stop the endless flow of "*** -Bug X- has been marked as a duplicate of this bug. ***". Just a thought. BTW: this is very annoying on netscape mail login where there's a spacer gif that doesn't load unless you right-click: view image (so ~80% of the time, info doesn't auto-fill).
It is very annoying on Yahoo too, where Ads load very long sometimes. But I think it is too complicated to let Mozilla decide this auto- matically, because: * Forms may be build or filled dynamically with Javascript * External Scripts may have to be loaded before the Form can be used * Images/Videos, Frames, etc may have to be loaded before the Form can be used So, why don't add a checkbox "During-Load" (default not checked!) for _every entry_ in the the Password Manager and let the (experienced) user decide how to manage this?
(In reply to comment #56) > But I think it is too complicated to let Mozilla decide this auto- > matically, because: > > * Forms may be build or filled dynamically with Javascript If so, let the script override the values, there is probably a reason for this > * External Scripts may have to be loaded before the Form can be used Scripts from external sites? I hope not, I think that would be a security breach, can a script from site A change things in a form from site B? scary... > * Images/Videos, Frames, etc may have to be loaded before the Form can be used If so, images have a function, are often small (image replacement of buttons) and come from the same site. Otherwise do not wait on the images to be loaded > > So, why don't add a checkbox "During-Load" (default not checked!) for > _every entry_ in the the Password Manager and let the (experienced) > user decide how to manage this? > This could be an option, although with regard to my comments I'd dare to give it a default of on.
Maybe autoform should wait in a manner something like this: 1. Wait for document to finish loading 2. Wait for all frames to load 3. Wait for all external scripts to load 4. Execute all scripts Then: Foreach field If current field was not modified (by scripts) Fill in field (This will require external documents to be loaded non-linearly.) This will not remove the ability to autofill forms written with document.write.
> > * External Scripts may have to be loaded before the Form can be used > > Scripts from external sites? I hope not, I think that would be a security > breach, can a script from site A change things in a form from site B? scary... With external I meant <script SRC="..." > > * Images/Videos, Frames, etc may have to be loaded before the Form can be > > used > > If so, images have a function, are often small (image replacement of buttons) > and come from the same site. Otherwise do not wait on the images to be loaded The problem is that it is too difficult to decide automatically if additional files are needed. The way posted in the previous comment #58 would be the right one, but as also written this requires non-linearly loading of files. I think this will have an impact on too many Mozilla components. The Checkbox on the other side should be easy to integrate: * If Checkbox==false -> usual behaviour * If Checkbox==true -> Auto-Fill after loading of HTML-Document without integrated external Elements
Why not autofill a form when </form> is found? If, later, some scripts want to modify it, let them do it. They will probably fill in the same data that was stored. I suggest resummarizing when a proper solution is found.
It is conceivably possible that a script will fill bad values in a field, so I think that there should be an option to force forms to be refilled. There are other factors I was not taking into account. These require my recommendation to change to: 1. Check autofill options 2. Document loading: If I should autofill Look for <form...</form> Autofill (ignoring value=) 3. Document loaded: If I should autofill Autofill all forms missing </form> 4. Load external documents: If content was written AND I should autofill Look for <form Autofill 5. onLoad 6. Wait for content to be written (essentially onDocumentWrite) =>Step 3. This does not as nice as my initial suggestion, but there are some possible situations (2) where my initial suggestion does not work. Any better solutions or anything I haven't taken into account?
*** Bug 249734 has been marked as a duplicate of this bug. ***
*** Bug 250978 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → ---
If some script wants to fill in values, it should have done so when the complete HTML page is loaded, doesn't it? So instead of filling in the stored values from the password manager when </form> is found, Mozilla could wait until </html> shows up (or the input stream closes), and fill in the values *before* loading the images.
(In reply to comment #64) > If some script wants to fill in values, it should have done so when the complete > HTML page is loaded, doesn't it? So instead of filling in the stored values from > the password manager when </form> is found, Mozilla could wait until </html> > shows up (or the input stream closes), and fill in the values *before* loading > the images. Just casting another vote for filling in when </form> seen. As previously remarked, the </html> may be a _long_ time arriving; in my opinion, if the browser sees fit to _show_ me the form, it should see fit to fill it in as well. If people really care about this, make it a 3 way choice: fill remembered forms in on </form>, on </html> or after the "onLoad" point (i.e. current annoying behaviour). And please, if this setting is per-form, make the default be a settable option so I can go to prefs, say "fill on on </form> by default" and be happy. And, of course, for those forms which can be prefilled, right clicking in said form might usefully offer a context menu option along the lines of "refill with remembered values" (and, I suppose, a "reset form" option).
*** Bug 282208 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
No longer blocks: majorbugs
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Flags: blocking-aviary2.0?
It's almost a year since anybody thought of working on the code for this bug (I refer to comment #65). Can we please have some work on this? Adding self to CC. Also added this bug to the forgotten bugs thread over at MozillaZine: http://forums.mozillazine.org/viewtopic.php?p=1681163
*** Bug 291835 has been marked as a duplicate of this bug. ***
This is really a seamonkey bug, the Firefox equivalent is another bug.
Flags: blocking-aviary2?
fyi: that other (firefox) bug is 221634, which this bug blocks.
Is this view too simple?: Is not the intent of the password autofill feature to do something the user could be doing, only (if the feature is to make sense) faster? If so, is not the most logical place to put the call to the autofill (on a per element basis) exactly just after each form element has rendered (or been added to the DOM), since that is the first opportunity that the user would have to take any action? This would obviate the need for </form>, </html>, etc. checks and processing. As to the comments about script stuffing/configuring form elements: Since the user (for example, on a slow loading page) could be manually filling in fields, script is obliged to anticipate fields already having been filled in by the time the script gets around to running. In practise, I would ask how many sites there are which would break if the elements have already been filled out by the time the script gets to them? I should think that if a script intends to muck about with elements, it will simply overwrite what (possibly by virtue of autofill) is already there. Csaba Gabor from Vienna
Another "me too" with several Gecko-based browsers (Firefox, Epiphany, etc). Several comments noted that there could be problems with auto-filling before client-side scripts run, because they may want to fill in fields. I don't think this should be too big of a problem, since any script that would get broken by auto-filling would almost certainly get broken by the user clicking in the field and typing.
> Several comments noted that there could be problems with auto-filling > before client-side scripts run, because they may want to fill in fields. > I don't think this should be too big of a problem, since any script that > would get broken by auto-filling would almost certainly get broken by the > user clicking in the field and typing. Unfortunately, there are several pages that I've encountered which fill in their <form>s' fields with blanks on onLoad(). Yes, this is frustrating. No, they don't care -- they expect all their "real" customers to be using broadband, not a dial-up connection, so we can "benefit" from a lot of useless images.
(In reply to comment #73) > Unfortunately, there are several pages that I've encountered which fill in > their <form>s' fields with blanks on onLoad(). Yes, this is frustrating. No, > they don't care -- they expect all their "real" customers to be using > broadband, not a dial-up connection, so we can "benefit" from a lot of useless > images. This affects broadband users too. From what I've seen, the images tend to stored on a separate server for static content; if there is a transient problem causing it not to respond, then autofill won't happen until the image loading times out. This also occurs with sites that use external providers for ads - if the ad server has a problem then autofill won't occur until everything times out. I guess it's a choice between having a non-optimal behaviour with either some (arguably broken) sites, or when there are network issues/server issues/slow connections.
Another reason I often use safari still. Please fix this for the next build.
Flags: blocking1.8.1?
*** Bug 329664 has been marked as a duplicate of this bug. ***
Why not prefill everything possible and if a script ever asks to modify values later on then you just clear the textbox to its default value and let the script do whatever it wants. kind a like: onTextboxScriptChange(textbox) if textbox.autoprefilled == true textbox.value = textbox.defaultvalue hope there is a handler like that.
Sounds like more design work needs to be done here, and then a patch authored, but it's pretty desireable for 1.8.1, so blocking+ optimistically.
Flags: blocking1.8.1? → blocking1.8.1+
Assignee: john → nobody
Status: ASSIGNED → NEW
QA Contact: tpreston → layout.form-controls
Assignee: nobody → michael.wu
Whiteboard: [SWAG: 2d]
This works for the testcase, but much testing will be needed to ensure correct behavior on other pages and make sure we're acting similar to other browsers.
Crashing is bad.
Attachment #226533 - Attachment is obsolete: true
Comment on attachment 226536 [details] [diff] [review] Fill in form on DOMContentLoaded event, v2 I'm somewhat convinced that just filling in the form at DOMContentLoaded is the right thing to do, because that is the same time that the user can fill something in. If the page javascript decides to overwrite the username on onload, it could have also overwritten a username entered by the user. However, for most cases, the site will end up filling in the same username if they're just trying to remember the last username used. Sites should check to see if the user managed to fill anything in before filling the cached username in. Better sites should fill it in on serverside.
Attachment #226536 - Attachment description: WIP: Fill in form on DOMContentLoaded event, v2 → Fill in form on DOMContentLoaded event, v2
Attachment #226536 - Flags: review?(bryner)
Status: NEW → ASSIGNED
Attachment #226536 - Flags: review?(bryner) → review?(enndeakin)
Comment on attachment 226536 [details] [diff] [review] Fill in form on DOMContentLoaded event, v2 + sPasswordManager->LoadPasswords(); + Might want to add a comment so it's clear an attempt to load passwords is made again if it failed. + if (NS_SUCCEEDED(sPasswordManager->ReadPasswords(mSignonFile))); + sPasswordsLoaded = PR_TRUE; +} + I don't think the sPasswordManager-> is needed. Should it be the same as 'this'? Otherwise, looks good.
Attachment #226536 - Flags: review?(enndeakin) → review+
(In reply to comment #82) > (From update of attachment 226536 [details] [diff] [review] [edit]) > > + sPasswordManager->LoadPasswords(); > + > > Might want to add a comment so it's clear an attempt to load passwords is made > again if it failed. > Done. > + if (NS_SUCCEEDED(sPasswordManager->ReadPasswords(mSignonFile))); > + sPasswordsLoaded = PR_TRUE; > +} > + > > I don't think the sPasswordManager-> is needed. Should it be the same as > 'this'? > Oh, opps. I guess I didn't look at the code too carefully after copying it over. Thanks for the review!
Comments from Neil Deakin applied.
Attachment #226536 - Attachment is obsolete: true
Make apply on trunk.
Fix checked in on trunk. Note that this fix is for the toolkit password manager. If someone wants seamonkey's password manager fixed, please file a new bug for that.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 221634 has been marked as a duplicate of this bug. ***
What's the difference between the "toolkit" and Seamonkey? This bug was originally opened on the Mozilla application suite, so shouldn't the fix be in Seamonkey, which has replaced Mozilla? Is there a standard way to designate that a particular fix needs to go into Firefox and Seamonkey?
As Gavin stated in the comment 39 of bug 221634, that was a Firefox bug and this a Seamonkey bug. The bug Michael marked as duplicate was the bug he really worked on and this bug is the bug he cited: "If someone wants seamonkey's password manager fixed, please file a new bug for that".
Verified FIXED using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060627 Minefield/3.0a1. The password field appears filled as soon as the page loads, whereas without the patch it never was filled in.
Status: RESOLVED → VERIFIED
Whiteboard: [SWAG: 2d]
OK. Please do NOT hijack bugs from other products. If you're rude enough to do so, have the decency to file a replacement bug yourself. Neil, jwalden, one of you should really have caught that, imo...
Uh, I don't get it, are we reopening this bug or what? Also, Michael, since this was originally a Seamonkey bug, I think it's fair for you to make the (probably additional effort and fix it (hopefully in exactly the same way) in Seamonkey as well. Don't patch & run :-\
(In reply to comment #91) > Neil, jwalden, one of you should really have caught that, imo... Had I been CC'd on the bug during the fixing process, I would have done so. Also, had I read the bug beyond verifying that the patch had been properly reviewed before committing it, I would have done so. However, I didn't, and consequently I didn't catch it. I certainly *wish* I'd caught it, but given that I had no involvement with this bug beyond committing its properly-reviewed patch, I don't think it's reasonable to have expected me to catch it.
Bug 342948 filed. Gavin mentioned that this bug morphed into something less seamonkey specific in the hopes that there would be a general solution for both/all password managers. Or something like that. That turned out not to be the case, so I closed both this somewhat ambiguous bug and the firefox/toolkit specific bug. I should have been the one to open a new seamonkey password manager bug to fully clarify the issue. Sorry about that.
(In reply to comment #94) > Bug 342948 filed. Given the large numbers of votes and people watching this bug, this bug should remain open, not have a duplicate bug opened which we all have to vote for again, subscribe to again, etc, etc.
(In reply to comment #94) > Bug 342948 filed. > > Gavin mentioned that this bug morphed into something less seamonkey specific in > the hopes that there would be a general solution for both/all password > managers. Or something like that. That turned out not to be the case, so I > closed both this somewhat ambiguous bug and the firefox/toolkit specific bug. I > should have been the one to open a new seamonkey password manager bug to fully > clarify the issue. Sorry about that. > What happens with the firefox/toolkit specific bug, since you closed it? Isn't that problem still not resolved?
(In reply to comment #96) > What happens with the firefox/toolkit specific bug, since you closed it? Isn't > that problem still not resolved? > No, that is precisely the bug that I fixed. (In reply to comment #95) > Given the large numbers of votes and people watching this bug, this bug should > remain open, not have a duplicate bug opened which we all have to vote for > again, subscribe to again, etc, etc. > As I said before, I do not think that is a duplicate bug, and now we can be completely sure everyone still interested in the bug wants seamonkey's password manager fixed.
(In reply to comment #95) > Given the large numbers of votes and people watching this bug, this bug should > remain open, not have a duplicate bug opened which we all have to vote for > again, subscribe to again, etc, etc. I agree complete. This bug should be reopened, and bug 342948 should be closed as a dupe of this bug. Just designate this bug as being for Seamonkey. This all boils down to the point I was trying to make: is there a clear method for designating a bug for Firefox and/or Seamonkey? It doesn't look like, and that's why we have this confusion. I'm not familiar with the code bases, so I don't know how much code is common between Seamonkey and Firefox. Is there any common code? If not, then shouldn't Seamonkey and Firefox have their own bugzilla databases or whatever? After all, people use either Firefox or Seamonkey, but rarely both.
*** Bug 342948 has been marked as a duplicate of this bug. ***
This is the suite version of this bug, as stated in the Firefox version bug 221634 comment 39 long before there were any patches here.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee: michael.wu → dveditz
Status: REOPENED → NEW
Component: Layout: Form Controls → Password Manager
Flags: blocking1.8.1+
Flags: blocking-aviary1.5-
Priority: P3 → --
Product: Core → Mozilla Application Suite
QA Contact: layout.form-controls
Attachment #227338 - Attachment is obsolete: true
Attachment #227340 - Attachment is obsolete: true
i'm only interested in the ff fix.
Assignee: dveditz → nobody
Depends on: 343169
No longer depends on: 343169
No longer depends on: 376765
This is still happening (and is annoying) as per FF 2.0.0.3
(In reply to comment #102) > This is still happening (and is annoying) as per FF 2.0.0.3 The Firefox version of this bug (bug 221634) was fixed for Firefox 2, and it's still fixed in my 2.0.0.4pre build using the testcase at http://www.squarefree.com/bug221634/ . If for some reason it's not working for you, file a new bug, and mention bug 221634, not this bug.
Is there even the slightest possibility that reported fix might be backported to the Seamonkey 1.1.* releases? It is great that it will be in the next major version (really!), but it is also so very annoying, that I would categorize it as a major defect, qualifying it for inclusion in release 1.1.5. Adding myself to CC...
(In reply to comment #104) >Is there even the slightest possibility that reported fix might be backported >to the Seamonkey 1.1.* releases? SeaMonkey 1.x uses the old Wallet password manager which is unsupported. SeaMonkey 2.x will use the supported login manager, which I assume is fixed. >Adding myself to CC... We know already, there's no need to spell it out...
(In reply to comment #105) > >Is there even the slightest possibility that reported fix might be backported > >to the Seamonkey 1.1.* releases? > SeaMonkey 1.x uses the old Wallet password manager which is unsupported. > SeaMonkey 2.x will use the supported login manager, which I assume is fixed. Ok, thanks for that info. > >Adding myself to CC... > We know already, there's no need to spell it out... Fair enough, just saw others saying the same, so thought of it as a kind of courtesy. If it is indeed "bad style", thanks for pointing that out.
I notice with Firefox 3 now out that my saved password no longer work or show in prefs. I went back to firefox 2. Everything is fine now.
QA Contact: privacy
Hi: In the new version of Firefox for Mac (3.5.3) note that it has some impact. If you open multiple tabs at once, including two or three are required to master password, you open two or three times, as the case, the master password window when previously only opened once. Thus, we must put two or three times, as the case, the master password when in fact only make once put it, as in previous versions of Firefox. Another incident: When a web user, in this case, I have multiple accounts, for example in WordPress that I have three blogs, before this version (3.5.3) once set the master password, at the time of clicking with the mouse the user name field, showing the three names of the accounts, select the one that wanted to open and revealed the password. Now, this is not that ... We must put the master password, so far, perfect-but then, does not leave a name, must be put and then it does appear the password. I think this version should be revised to return the church to respond effectively than before this release. I forgot to mention hat when entering a website that requires a password, if you only have an account on this site, it automatically displayed the name and password. Is there a solution for these problems that I mentioned? Thank you.
Flags: blocking1.9.2?
I believe that will be handled by async prompt auth - bug 475053, which should be fixed on mozilla-1.9.2 and thus in Firefox 3.6.
Flags: blocking1.9.2? → blocking1.9.2-
Whiteboard: [tsnap]
Component: Passwords & Permissions → Password Manager
Product: SeaMonkey → Toolkit
QA Contact: privacy → password.manager
Whiteboard: [tsnap] → [snappy]
Whiteboard: [snappy] → [Snappy:P2]
I think this bug isn't valid anymore. http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/nsLoginManager.js#344 tells that we use DOMContentLoaded to fill the login data into the form. Can't reproduce with the attached test case and the STR from comment #2.
I, for one, am still experiencing this with Firefox 8.0. I don't know if it's specifically waiting for onLoad(), but on many websites I'm still having to wait a considerable time after the form is loaded before it's auto-filled.
I agree it isn't happening with the test case attached to the bug, but it still happens regularly on real-world pages (though I'm still on FF6).
Attachment #18748 - Attachment is obsolete: true
The form element could be visible before the DOMContentLoaded event is fired.
One of those real-word pages is Amazon. I had something in my cart, and clicked on Proceed to Checkout. In the next screen where it had me log in, the form elements appeared but I still had to wait for the throbber to stop and the page to load completely before the password was filled.
Maybe due to excessive external scripts?
I asked dolske to add this bug to his todo list.
Not only do we not autocomplete right away, but form history uses expensive sync queries to do IO. Fixing sync IO and doing async form fill might be related. This now a P1 bug since at the moment form history actually adds lag to loading a page.
Whiteboard: [Snappy:P2] → [Snappy:P1]
Taras, to my knowledge "form history" and "password manager" (autofill password forms only) are separate features. This bug is only about the latter.
(In reply to Taras Glek (:taras) from comment #117) > Not only do we not autocomplete right away, but form history uses expensive > sync queries to do IO. Fixing sync IO and doing async form fill might be > related. This now a P1 bug since at the moment form history actually adds > lag to loading a page. Bug 566746 is making the form history storage async. But yes, password manager needs to go async too (bug 657007). (In reply to Ben Bucksch (:BenB) from comment #118) > Taras, to my knowledge "form history" and "password manager" (autofill > password forms only) are separate features. This bug is only about the > latter. You're right, they are separate features. Bug 355063 could help in that the idea there is we will watch for password fields being added to the document and then process that as opposed to just looking at the DOM on DOMContentLoaded. I know that's just about script-generated forms, but presumably it would apply to the general case.
(In reply to Ben Bucksch (:BenB) from comment #118) > Taras, to my knowledge "form history" and "password manager" (autofill > password forms only) are separate features. This bug is only about the > latter. Ok, thanks for pointing this out
Whiteboard: [Snappy:P1] → [Snappy:P2]
Paul, Should this bug block on 355063?
Depends on: 657007
(In reply to Taras Glek (:taras) from comment #121) > Paul, > Should this bug block on 355063? Yea, let's do that.
Depends on: 355063
No longer depends on: 657007
Attached file PHP test-case —
Now that bug 355063 is fixed, I think we can resolve this since we no longer wait for the "load" or DOMContentLoaded events. I confirmed that with the attached test case. We don't fill in the password synchronously at parse time but I also don't think we can or want to due as we wouldn't want to block rendering the field on querying the passwords.
Status: NEW → RESOLVED
Closed: 19 years ago → 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: