848301 - XHR request from an XPCOM component doesn't generate a save password doorhanger

Status: UNCONFIRMED

(Core :: XML, defect)

Description

[Ian Nartowicz]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20130117 Firefox/20.0
Build ID: 20130117110358

Steps to reproduce:

Submit an XMLHttpRequest that requires authentication.


Actual results:

Prompt appears for username and password (ONLY if the submitted username and password are null/blank).  Prompt does not ask if the password should be saved with the password manager.


Expected results:

Prompt should ask if the password should be saved with the password manager, which is what happened prior to FF18.  Probably cause is bug 282547.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Andrea, Honza, can you take a look?

Comment 2

[Andrea Marchesini [:baku]]

I'm debugging it. Can it be that the password manager has just to be initialized...

Comment 3

[Andrea Marchesini [:baku]]

Wait... I cannot reproduce it. Using mozilla-central the first time the dialog of the password manager appears. Then, if you store the password, the auth dialog is shown populated.

Can you be more precise? Or show a better STR? Thank you!

Comment 4

[Ian Nartowicz]

Are you using XMLHttpRequest called from javascript?  And the dialog comes up with the checkbox to save the password, or is saved some other way?  Is this following a 401 response?

How can it be populated the second time?  The dialog should only appear if no username or password was supplied to the XMLHttpRequest (see bug 282547 comment 33, but you knew that already), so there can be nothing to populate.

In my tests I submit the XMLHttpRequest from a javascript XPCOM component to a server that authenticates and returns 401 if the username or password is no good.  I am doing this on port 9091 to a uTorrent "client" running on another part of my network (uTorrent status tool addon).  If I supply a username *or* password, the status 401 is returned with no password dialog (frustrating but now in line with the spec).  If I supply blank or null for *both* username and password, the 401 response does not return to me but instead a password dialog appears.  It has an empty username and password but no checkbox.  Is the checkbox missing simply because the username is blank?  Supplying a username and password and pressing OK does not save to the password manager, but does resubmit the request with the new details.

Comment 5

[Andrea Marchesini [:baku]]

> Are you using XMLHttpRequest called from javascript?  And the dialog comes
> up with the checkbox to save the password, or is saved some other way?  Is
> this following a 401 response?

Yep:

<script>
var a = new XMLHttpRequest();

a.onreadystatechange = function() {
    if (a.readyState === 4){
        alert(a.readyState);
    }
};
a.open('GET', '/a/foo', true);
a.send(null); 
</script>

and /a/foo is a simple index.html page with a .htaccess.

> How can it be populated the second time?  The dialog should only appear if
> no username or password was supplied to the XMLHttpRequest (see bug 282547
> comment 33, but you knew that already), so there can be nothing to populate.

Right. The second time the auth dialog appears with username and password already filled in.

> In my tests I submit the XMLHttpRequest from a javascript XPCOM component to
> a server that authenticates and returns 401 if the username or password is
> no good.  I am doing this on port 9091 to a uTorrent "client" running on
> another part of my network (uTorrent status tool addon).  If I supply a
> username *or* password, the status 401 is returned with no password dialog
> (frustrating but now in line with the spec).

Right.

>  If I supply blank or null for
> *both* username and password, the 401 response does not return to me but
> instead a password dialog appears.  It has an empty username and password
> but no checkbox.  Is the checkbox missing simply because the username is
> blank?  Supplying a username and password and pressing OK does not save to
> the password manager, but does resubmit the request with the new details.

I don't know which checkbox you are talking about. The Password Manager shows a second dialog asking for storing the password.

Can you provide a simple test? Thank you.

Comment 6

[Ian Nartowicz]

Here's screenshots from FF17 ESR (with checkbox) and FF19 (no checkbox).  I had to blank the username in FF19 to make the dialog appear, while in FF17 it has pulled the password from the login manager.

Is your "second dialog" the doorhanger that prompts to save the password?  I know that appears in some circumstances but I haven't seen it from an XMLHttpRequest.

Comment 7

[Ian Nartowicz]

Attachment: FF17 with checkbox

Comment 8

[Ian Nartowicz]

Attachment: FF19, no checkbox

Comment 9

[Ian Nartowicz]

Am I just seeing the expected behaviour, but am not getting an intended doorhanger prompt because I'm not in a window?  Effectively bug 631802?

Comment 10

[Honza Bambas (:mayhemer)]

(In reply to Ian Nartowicz from comment #9)
> Am I just seeing the expected behaviour, but am not getting an intended
> doorhanger prompt because I'm not in a window?  Effectively bug 631802?

Ian, you need to provide more detailed description.  It might be bug 631802 as you referred, you just never said you were in a pop-up window.

Comment 11

[Ian Nartowicz]

I'm not in a popup.  The javascript is running in an XPCOM component.  I don't know what is supposed to be happening, but reading between the lines of what Andrea said it seems that the dialog is supposed to be the way I see and that the "save password" prompting should come later.  Except it doesn't for me, perhaps because I'm not running from a standard browser overlay.

Comment 12

[Honza Bambas (:mayhemer)]

Even newer info.  Thanks.  I don't know how the doorhanger for storing a password to password manager is coded, but it's probable that XPCOM invoked xhr requests don't trigger it.  You can, however, when being in the browser overlay and accessing XPCOM, save the password your self.  I would have to take a look on the exact API, but that is definitely doable.

Comment 13

[Ian Nartowicz]

Although nobody has said it explicitly, I get the impression that the dialog is behaving as designed, never with a checkbox, and that there should be a doorhanger to prompt for saving the password.  As such I will change the title of this bug.

Certainly I can save the password myself.  I did, because I had to make this work now, not in two releases time.  That doesn't change the fact that something which used to work no longer works, or perhaps that something which was redesigned just doesn't work at all.

Comment 14

[Honza Bambas (:mayhemer)]

Ian, from the last comment is seems you believe this is a regression.

Would you be willing to find the regression range?

Comment 15

[Ian Nartowicz]

(In reply to Honza Bambas (:mayhemer) from comment #14)
> Ian, from the last comment is seems you believe this is a regression.
> 
> Would you be willing to find the regression range?

October 7th 2012, the prompt stops appearing when the username or password is no-blank.  That is bug 282547 landing.  But with blank username and password the prompt appears and has a checkbox.  This happens right up to 18.0.2.  I'll start looking at FF19 nightlies.

Comment 16

[Ian Nartowicz]

October 12th 2012, the save password prompt disappeared from the auth dialog.  Busy day but I don't see anything obvious that would cause this change in the auth dialog.

Comment 17

[Andrea Marchesini [:baku]]

It seems that this checkbox disappeared many days before the 12th.
Can it be that is just a UX change? I don't see how bug 282547 can be related to this issue.

Comment 18

[Ian Nartowicz]

I don't know(In reply to Andrea Marchesini (:baku) from comment #17)
> It seems that this checkbox disappeared many days before the 12th.
> Can it be that is just a UX change? I don't see how bug 282547 can be
> related to this issue.

I don't know.  Maybe it is intentional.  Maybe there is supposed to be a doorhanger instead.  All I know is that I used to be offered the chance to save the password, and now I'm not.

Bug 282547 may or may not be related.  I see a change from this (dialog doesn't appear at all when non-blank authentication details are supplied to the XHR open) in the Oct 7th nightly but there is still a checkbox.  Then the checkbox disappears a few days later.  Presumably there is another change out there, but I can't find the bug that did it.