24746 - Need a way to open modal dialogs from network threads

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Alec Flett]

Per a discussion with valeski and davidm, we need a way to open a modal dialog
without actually knowing the parent dialog, such as inside of a necko thread or
something.

Right now there are hacks to use the hidden window as the parent. This is bad
because:
- we can't center the dialog over the right window (no big deal)
- if you bring up two of these hacked modal dialogs at the same time (i.e. if
two browser windows each pop up a dialog, or browser and mail, etc) Bad Things
happen, as davidm discovered. crashes, unreadable dialogs, you name it.
- the hidden window won't be there in embedded apps and the current scheme will
probably cause a crash.

Jud had this idea in IRC:
<valeski> let's start from teh bottom.
<valeski> http realizes it needs auth info from the user.
<alecf> yup
<valeski> it can either toss up a dialog on it's own or ask it's loading context
to pop one up.
<valeski> right now it's donig the former.
<valeski> the latter is what should happen.
<valeski> but, it has no concept of it's loading context.
<valeski> well that's not true actually
<valeski> here we go
<valeski> one sec
<valeski> nsIInterfaceRequestor
<valeski> these get set on channels at creation time.
<valeski> the channel could ask it's nsIInterfaceRequestor for the prompt iface.
<valeski> so, that means the loader (the one doing the actual load) would have
to implement, or refer to, some prompt object.
<valeski> ok, this gives channels the ability to throw UI *without* knowing
anything about the UI or where it's coming from.
<valeski> but, the backend logic needs to be there. hmmm..
<valeski> so basically the URI loader would need to supply the channel w/ an
nsIInterfaceRequestor that knew how to throw UI.
<alecf> yeah, that would be really cool
* valeski  looks at code
<valeski> crap, rpotts changed the URI loader beyond recognition from the last
time I looked.
<valeski> I don't know who's doing the loadgroup and nsIInterfaceRequestor
retargeting now.
<valeski> regardless, this logic could sit in the URI loader.
<valeski> or nsIAppShellService could be extended to do some extra magic behind
the scenes.
<valeski> This falls into the URI targeting category. Basically any contextual
info surrounding a URI load falls into a (technically quite complex) decision
matrix, and this adds a row and column to that matrix.
<valeski> at one point we started to draw this matrix but after two full days I
think we just passed out.
<valeski> rpotts is taking a swing at what will probably cover 2/3s of it.
<valeski> and I'm inclined to follow his lead.

So I'm assigning this to rpotts, and CCing all relevant people.

Comment 1

[Stephen P. Morse]

One important person that you forgot to cc is davidm.  I'm adding him to the cc 
list.

Comment 2

[ruslan]

per warren's request

Comment 3

[Warren Harris]

Moving to M17 which is now considered part of beta2.

Comment 4

[leger]

Need to know if this embedding APIs or necko or what?  Who should get this bug?

Comment 5

[davidm]

isn't this fixed? I thought we were now requesting an interface off of the 
docshell?

Comment 6

[leger]

Putting on [nsbeta2+][5/18] radar. 

Comment 7

[Warren Harris]

This is part of the massive single sign-on changes I'm making.

Comment 8

[Warren Harris]

Fix checked in. Please give it a try.

Comment 9

[Tom Everingham]

verif:
NT 2000052208