Closed Bug 65024 Opened 24 years ago Closed 23 years ago

"Save As" doesn't do basic auth, doesn't give good error.

Categories

(Core Graveyard :: File Handling, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 116279
mozilla0.9.9

People

(Reporter: anthony, Assigned: adamlock)

References

()

Details

(Keywords: relnote, Whiteboard: username: mozilla, password: mozilla)

For an example: go to
http://www.acm.org/pubs/citations/journals/cacm/1999-42-10/p72-cusumano/

Shift-Click on 'PDF' - I get the 'Save As' file chooser,
then a popup with

Unknown error [1 80004005]

Just clicking normally gives the basic auth popup. As far as
I can see, 'Save As' doesn't have the basic auth stuff hooked up.

This is with built 2000-12-26, on Linux
this is not an http bug.  the implementor of "save as" is failing to specify
an nsIPrompt on the http channel, thereby leaving http with no way to do basic
auth.

->mscott (does this belong to the uriloader?)
Assignee: darin → mscott
Component: Networking: HTTP → Browser-General
WORKSFORME
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001010908


Reporter try one of the latest nightlies and report back if its a problem or
not. My bet is that one of the latest nightles and/or a new profile will fix the
problem.
I see this bug on Win98 with 2001 011204, confirming and setting OS to All.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
I just tried the same version as you (linux, 2001010908) on Redhat 6.2,
and I see the same, broken, behaviour. Shift-Click on the 'PDF' icon
(or select 'Save Link As' on it), get file selector, pick file, get
"unknown error" popup.

I also tried with a new profile, still see it.
*** Bug 67568 has been marked as a duplicate of this bug. ***
"Save As" is not intended to mean as "Save Link As", by the way.
Save As is to save the page source (yes, there is another bug for that), and
Save Link As is to save the pdf file in this case. Save Link As is supposed to
bring up basic authentication which is skipped here.
this is actually Bill's save as code from the file menu i believe.

Assignee: mscott → law
Marking nsbeta1+, p3, mozilla0.9
Keywords: nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla0.9
I'm not getting to this dialog till next round...
Target Milestone: mozilla0.9 → mozilla0.9.1
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
nav triage team:

Pushing out to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
nav triage team:

Nice to have, but not a mozilla0.9.3 stopper. Marking mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
Assignee: law → pchen
Component: Browser-General → XP Apps
Keywords: relnote
QA Contact: tever → sairuh
-> xp apps, out of networking 
workaround might be to auth before you hit the link.
That workaround isn't always going to be useful. The example 
given is a site where you can see the abstracts, but it's only
when you try to download the paper that the auth is required.
Mozilla seems to be about the only browser that I can find that
doesn't get this right ... :(
spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)
Component: XP Apps → File Handling
->law
Assignee: pchen → law
->mozilla0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9
I need an update on this bug.  Currently, that URL doesn't have a link to a PDF 
file.  There's a text link that says "Click here to access the full text" and 
that opens another web page with a login screen.  We handle clicking on that 
link the same as IE.  I don't have an account but I suspect logging in would 
work OK.

I don't think we've done anything to fix the problem Darin alluded to (not 
implementing nsIPrompt) so there still may be a problem here.  But I think 
maybe we get some default nsIPromptService if there isn't one specific to the 
http request, so maybe there is no longer any bug here.

Please check it out and let me know.
The acm site no longer uses basicauth.  Changing url to a working testcase.

This is still broken.
putting username/password to use in status whiteboard.  Sorry about forgetting
that....
Whiteboard: username: mozilla, password: mozilla
This needs to be done in nsWebBrowserPersist.
Assignee: law → adamlock

*** This bug has been marked as a duplicate of 116279 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.