240731 - Consider allowing calling nsIURILoader::Open with null context

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

As things stand, nsURILoader::Open will fail when called with a null window context.
see bug 239604 comment 14 through 17

It would be nice if calling with a null context would also be possible.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This content listener we get in Open() is only needed so that we can try the
original docshell that kicked off the load first.  If there is no docshell that
started the load, we should really allow a null.  If you trace through the code,
none of it assumes m_contentListener to be non-null.  So I would say it's safe
to just set it here and ignore whether we got back a non-null listener.

There's the question of whether we should set the retargeted flag for cases when
the original listener is null.  I think we should.

The remaining consumers of the window context are the nsIContentHandler call
(where it's optional, right?) and the helper app service code (which uses it as
a parent for various modal dialogs, it looks like).

I'm not sure what we can do about this last part, really... or even if anything
needs to be done -- what happens if you pass a null parent to the
promptservice's alert() method?

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #1)
> The remaining consumers of the window context are the nsIContentHandler call
> (where it's optional, right?) and the helper app service code (which uses it as
> a parent for various modal dialogs, it looks like).

Yes, no implementation assumes it's non-null. At least, none crashes when passed
null :)

> I'm not sure what we can do about this last part, really... or even if anything
> needs to be done -- what happens if you pass a null parent to the
> promptservice's alert() method?

That works fine, last I checked.

Comment 3

[Dan M]

nsIPromptService was made to handle a null window because it had to; there are
many places in the code where no parent was available. It results in modal
windows with no parent to be dependent on. It more or less works, but it causes
subtle errors.

Darin may have more to say on this but I'd say that as an independent library,
there's no need for necko to require a window context just to perform a URI
load. As a component of Mozilla, it's an error to not have a window available to
host prompts. We've spent a lot of time trying to find all the places where URIs
and channels are initialized without a window context. Prompting works as well
as it does because we've found most of them. The uses remaining are somewhat
problematic, and Darin has a fairly nasty, long-standing open bug against that
(which I of course am unable to find right now).

Comment 4

[Javier Morris]

Attachment: postsubswheelsprep19862109.txt

Thanks from backtecmepi1975.