Remove nsIAuthPrompt impls from embedding

VERIFIED FIXED in mozilla0.9.2

Status

()

--
critical
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: galfandary, Assigned: adamlock)

Tracking

Trunk
mozilla0.9.2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
Same as:
http://bugzilla.mozilla.org/show_bug.cgi?id=75745
for independent channels.
(Reporter)

Updated

18 years ago
Target Milestone: --- → mozilla0.9.1
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 1

18 years ago
gagan: I am moving this to mozilla0.9.2.

Updated

18 years ago
QA Contact: benc → bbaetz

Comment 2

18 years ago
gagan: ->adam
Assignee: neeti → adamlock
(Assignee)

Comment 3

18 years ago
I am unfamiliar with what needs to be done here. I did a search through LXR 
and none of the embedding clients uses nsIAuthPrompt. Does that mean this bug is 
done already or do you mean remove it from the embedding infrastructure too?

If so what do I replace it with?
nsIAuthPrompt should never be used (or even seen) from embedding clients. The
purpose of it is to hide nsISingleSignon from both necko and from nsIPrompt. The
only code which should use nsIAuthPrompt is necko, single-signon, and the
windowwatcher. Since I think that's the case, I'm not sure what needs to be done.
(Assignee)

Comment 5

18 years ago
Thanks Conrad. nsIAuthPrompt seems to be hidden from the embedders so I'll mark
this bug fixed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
VERIFYing
Status: RESOLVED → VERIFIED
(Reporter)

Comment 7

18 years ago
I made the following change:
diff TestGtkEmbed.cpp*

560a561,580
> #include "nsNetUtil.h"
> struct stream_t : nsIStreamListener {
>   NS_DECL_ISUPPORTS
>   NS_IMETHOD OnStartRequest(nsIRequest*, nsISupports*)
>     { return NS_OK; }
>   NS_IMETHOD OnStopRequest(nsIRequest*, nsISupports*, nsresult)
>     { delete this; return NS_OK; }
>   NS_IMETHOD OnDataAvailable(nsIRequest*, nsISupports*,
>                            nsIInputStream* s, PRUint32, PRUint32 n)
>     {
>       char *buf = new char[n + 1];
>       PRUint32 r;
>       s->Read(buf, n, &r);
>       buf[r] = 0;
>       printf("%s", buf);
>       delete[] buf;
>     }
>   virtual ~stream_t() {}
> };
> NS_IMPL_ISUPPORTS1(stream_t, nsIStreamListener)
566c586,594
<   gtk_moz_embed_load_url(GTK_MOZ_EMBED(browser->mozEmbed), text);
---
>   static nsCOMPtr<nsIIOService> io = do_GetIOService();
>   nsCOMPtr<nsIURI> uri;
>   io->NewURI(text, nsnull, getter_AddRefs(uri));
>   nsCOMPtr<nsIChannel> ch;
>   NS_OpenURI(getter_AddRefs(ch), uri, io);
>   if (!ch) printf("1\n");
>   stream_t *st = new stream_t();
>   printf("read:\n");
>   ch->AsyncOpen(st, nsnull);

Now what you type in the input panel gets
loaded in an independent channel.

This fails with sites protected by user/password
unless I implement nsIAuthPrompt on the channel.

"Remove nsIAuthPrompt impls from embedding" means,
of course that this should work without my having
to implement this interface, the same way it does with IE.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 8

18 years ago
CC'ing Chris Blizzard

Chris, can you read the previous comment and say whether the behaviour is likely
a problem in the GTK widget or related to this bug?
Umm...I'm not sure what that comment says exactly.  I don't know of any
prompting problems with the gtk widget at this time so I'm not sure what he's
getting at.
To me, "Remove nsIAuthPrompt impls from embedding" means, well, what it says ;-)

The reason you're not getting any prompting in your code is that you have not
set the notification callbacks on the channel. Look at the definition of
NS_OpenURI(). One of its arguments is an nsIInterfaceRequestor. It's through
this object that the prompting iface is gotten. Without it, you won't get any
prompts no matter where the nsIAuthPrompt iface is implemented.

I say we close this one.
(Assignee)

Comment 11

18 years ago
Marking fixed again.

Guy if you're opening URIs for yourself you'll have to follow Conrad's advice 
on how to set the prompt callback.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

18 years ago
Please excuse my thickheadedness, but I don't see how this is fixed.
I'll give yet another example: netwerk/test/TestHttp. This one also
fails to load a URL protected by user/password, although I'm only
interested in the embedding context of this problem.

What I'm asking for here is an enhancement. I know where to stick
my nsIAuthPrompt implementation so that it would work,
thank you very much, but I want to be relieved from
that duty - that is I want Mozilla to open its own
user/password UI the same way it does when the request comes
from an embedded browser and the way URL monikers
do it in IE.

Please don't close this one again unless you have an example where this is
working without the need to implement  nsIAuthPrompt.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 13

18 years ago
Guy, the network layer lives below the UI layer. If you start calling APIs on
the network layer you *must* provide the UI object that will display the user
password dialog. Network won't do it and it won't default to use XUL or some
other prompting scheme because it has no knowledge of such things.

You must either provide this UI object via nsIInterfaceRequestor or you must
obtain the nsIInterfaceRequestor from one of the docshells in the embedding app.
If your embedding app has no docshells, you have no choice but to implement your
own interface requestor object supplying the interfaces network requires.

Marking fixed again.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
re-VERIFYING
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.