125166 - Password Manager doesn't work with non HTML DOMs (e.g. text/xml documents)

Status: RESOLVED DUPLICATE of bug 354706

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Mike Gratton]

The password manager does not save password from XHTML forms when the file is
served as text/xml.

See the link in the URL field <http://web.vee.net/mozilla/password-manager.xml>
for a basic test case. An identical copy of the file, served as text/html is
available from <http://web.vee.net/mozilla/password-manager.html>. The password
manager will save the password in the second document, but not the first.

This is important as Moz won't treat XHTML as XML content unless the file is
served as text/xml. If the file is not recognised as XML, other embedded XML
markup (not in the XHTML namespace) in the document cannot be styled with CSS.

Comment 1

[Mike Gratton]

I did a little more digging, and found that when the document is served as
text/xml, the Javascript document.forms property does not seem to get built, ie,
document.forms == null.

Not knowing anything about the Password Manager's internals, I don't know if
that is a symptom or the cause..

Comment 2

[Mike Gratton]

One last thing, the lack of document.forms (and others) is covered in bug 111514.

Comment 3

[Kamil Toman]

Attachment: testing xml document and xslt

Steps to reproduce the crash:
- extract the archive, move xml document to a standalone directory
- view the xml document (nothing is displayed)
- copy *.xsl do that directory (so mozilla can find it now)
- reload the xml document
- crash

Comment 4

[Stephen P. Morse]

Comment 3 states "Steps to reproduce the crash:"

What crash?  Nothing above talks about a crash.  Is this crash a new bug?  If 
so, open it in a separate report.  Let's not morph this report.

Comment 5

[Peter Bartecki]

If I can add my 2 cents: 
There are more and more web services that are moving to XHTML what makes
Password Manager useless. 
 Few weeks ago Lycos has announced that most of their Europe sites will be
XHTML/CSS compliant - Password Manager can be tested on sample system here:
http://jscript.dk/lycos/2/

Could we possibly mark this bug New?

Comment 6

[Frank Klein]

I think I may be seeing this bug when I try to log into my bank's online banking
service:

https://comfedbank.bankhost.com/CC/23553/index2.html

I can login just fine, but Mozilla never offers to store my password.

I am not sure if this is the same bug or not, but it acts like the XML version
of the test posted by [e-mail].  It is an html document in the URL, but I do
not know if that rules this out or not. 

Using 1.1b / 2002082608/ WinXP, 

Frank

Comment 7

[Stephen P. Morse]

Comment 6 has nothing to do with this bug.  That comment is a dup of bug 93776.

Comment 8

[Michael Lefevre]

downgrading - this isn't a major loss of function.

however, it does seem to be a problem, so confirming.

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Taking.

Comment 10

[Nowhere man]

In fact, Mozilla even doesn't use an already saved password when the page now
text/xml is...

Comment 11

[Hixie (not reading bugmail)]

Since this now works for application/xhtml+xml, I'm guessing that the problem is
that password manager looks for an HTML DOM, and if it fails to find one, it
silently fails to work at all.

Comment 12

[Nowhere man]

*** Bug 202640 has been marked as a duplicate of this bug. ***

Comment 13

[Asa Dotzler [:asa]]

*** Bug 176477 has been marked as a duplicate of this bug. ***

Comment 14

[Tom Dickson]

Additional: https://login.personal.wamu.com/logon/logon.asp?dd=1 does not ask to
save password either, but I don't know how to tell if this is the same issue.
Kinda annoying, to be truthful. Tested with build 2004032215 on Gentoo Linux.

Note that I think the page is html, but I'm not sure how to check.

Comment 15

[Yan Morin]

There is another way to see this xhtml bug.

If you checks somes checkbox on both pages and hits "reload" button, 
the state of the checkbox remains in the text/html version:
http://yansanmo.no-ip.org:8080/test/html/input_refresh.html

but not in the application/xhtml+xml version:
http://yansanmo.no-ip.org:8080/test/xhtml/input_refresh.xhtml

Comment 16

[thorne]

This is not so much a bug in Firefox as it is a function of the wamu page.
Washington Mutual blocked autocomplete and autofill functions when they did
their upgrade last March and went into the new server. You can try an extension
such as always remember password to use as a work around. It's not a guarantee
that it will work, but it works on most sites.

Comment 17

[Gernot Tenchio]

What is the status of this bug? As far as I can tell, this bug still exists in Firefox 2.0.0.11.

Comment 18

[Daniel Veditz [:dveditz]]

Yes, the original bug--not replaying passwords in text/xml documents--is still present in Firefox 2 and in the rewritten Firefox 3 password manager. Both versions _capture_ the password, they just don't recognize the form to replay it. Comment 11 is still relevant but several of the other comments confuse the issue by bringing up unrelated "password manager doesn't replay" problems.

If you are designing such a site serve it as the preferred content type application/xhtml+xml instead of text/xml, and then the password manager will work. That said, the web.vee.net test page validates as XHTML 1.0 strict and according to the W3C's validator the incorrect content type rates only a warning not an error.

Comment 19

[Justin Dolske [:Dolske]]

This is a Suite bug, so it's an issue with the nearly-defunct Wallet code.

The Firefox/Toolkit equivalent is bug 354706.