Closed Bug 44809 Opened 24 years ago Closed 23 years ago

Appshell - nsIPrompt Service needs to die

Categories

(SeaMonkey :: UI Design, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9

People

(Reporter: dougt, Assigned: danm.moz)

References

(Depends on 1 open bug)

Details

(Keywords: embed, helpwanted)

Attachments

(2 files)

nsIPrompt implemented in the appshell ignore modality and uses the hidden 
windows.  All user should be finding the parent window and using that for their 
child prompt.


See url for possible/probable users
http://lxr.mozilla.org/seamonkey/search?string=NS_NETSUPPORTDIALOG_CID
Keywords: embed, nsbeta3
Whiteboard: nsbeta3+
Whiteboard: nsbeta3+ → [nsbeta3+]
Target Milestone: --- → M18
DanM has a similar bug to this.  Assigning to him.  

last i spoke to him about this, most of this issues were resolving quickly...
Assignee: dougt → danm
renominating for triage by current owners
Whiteboard: [nsbeta3+]
cc hyatt,jrgm.  How important is this for N6, really?
Whiteboard: [need info]
Depending on the dialog service and the hidden window will screw up modality.
nsbeta3+, P4 (not committing for N6) for M18, if only to determine whether the 
remaining dialogs that are a problem here will actually be a problem when 
embedding.
Priority: P3 → P4
Whiteboard: [need info] → [nsbeta3+]
Status: NEW → ASSIGNED
Mass-moving P4/P5 bugs to Future milestone.  We just don't have any time left
for these, although we could still consider taking a good patch.  Adding
Helpwanted keyword.
Keywords: helpwanted
Target Milestone: M18 → Future
nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]
This isn't really my bug -- my involvement should be limited to tracking down 
folks who are still using the nefarious Hidden Window and getting them to go to 
the pain of finding the correct, real window; sometimes a difficult task. I mean 
finding the correct window. But this will end up being necessary work to make 
Gecko embeddable, so I might as well admit it. Bringing in a little closer its 
current "future" gulag.
Target Milestone: Future → mozilla1.0
Blocks: 28594
Further explanation:

nsIPrompt usage is a complex, multi-tiered thing. It is generally cached in the 
networking channel by that object's initiator. End consumers (like Wallet) hope 
to find it there, but are prepared to fall back on the global service should that 
fail. This task is a case of locating all the places where a network connection 
is initiated, and being certain to associate an nsIPrompt window with each (and 
ensuring that there are no other places where the prompt window need be cached, 
or rather fixing them, too, if there are any). And finally, removing the global 
service fallbacks relied on by distrustful end consumers.

Most of the application already conforms to this requirement, but there was at 
least one more difficult holdout. Maybe a couple. The exact description above 
presumes that we want to stick with this scheme.

A slight modification has been suggested: caching the nsIPrompt in another place. 
At the least, someone needs to track down all the channel initiators and 
determine whether we have a problem requiring this modification. At most, someone 
needs to implement the modification. (There is at least one such place. I 
remember there is a channel initiator somewhere in imagelib that can't store the 
nsIPrompt in the usual place; that is already taken by some other object. It's 
not as simple as increasing the storage capacity of this place; it's a matter of 
teaching the mechanism to be able to use a list of such objects.)
Whiteboard: [nsbeta3-]
Target Milestone: mozilla1.0 → mozilla0.8
Blocks: 64846
  Three weeks later...
  The direction we're taking is one of minimal impact -- we want to be able to 
pull an nsIPrompt from the channel, and therefore we need to enforce the usage 
pattern where all freshly initialized channels have an associated nsIPrompt.  
This work has already mostly been done -- see dependent bugs of bug 25684. But 
I'm concerned there may still be holdouts.
  Reassigning to Mike. Despite the fact he expected this, I still get evil 
bastard bonus points.
Assignee: danm → pinkerton
Status: ASSIGNED → NEW
QA Contact: sairuh → jrgm
according to pav, the case in imagelib danm was concerned about where it was
registering callbacks that didn't implement nsIPrompt is gone (i did find the
code). b-bye. 

however, i do see other cases at random where mCallbacks isn't set at all on the
httpchannel. How does that happen? How on earth do i find those?!

ain't no way i can finish this by 0.8. help.
Status: NEW → ASSIGNED
there are also problems with nsFTPChannel and the callbacks never being set 
(they're null) while just loading an ftp site (sweetlou). I haven't yet been able 
to track down where this channel was created.
doug has a big branch that's landing in about a week which takes care of many of 
the cases where we're having problems. I'll file the bugs i find in the meantime 
to him as reminders for his branch.

pushing to 0.9, this can't be fixed by 0.8.
Target Milestone: mozilla0.8 → mozilla0.9
OS: Windows NT → All
Priority: P4 → P1
Hardware: PC → All
I think this bug may be the main one for the remaining dialog parenting problems
reported as catfood.  Syd suggested and DanM tentatively agreed that we should
have a mechanism where a parent can be found or assigned automagically when the
caller doesn't have a parent to pass in.  One significant use of this would be
in the installer that's running in the background and really doesn't have a
parent to latch onto.

Adding dveditz and syd to this bug so they'll know I've put them on the spot :-)
Keywords: nsbeta3nsCatFood
  Practically speaking, I believe we'll never be able to without exception 
enforce a rule that all channels contain callbacks corresponding to a window 
useful for parenting. This bug is mostly wishful thinking. However, see bug 
72111, which claims that we need to look in the load group, failing finding a 
window in the channel. That should provide better parent coverage, since the load 
group has a more direct link to the window. Also see bug 71895, which claims 
that, among other things, we should adopt the topmost window as a surrogate 
parent.
  I think we should leave this one at 0.9 for now, but expect to future it as the 
problem it describes is picked up by those other two bugs. Taking it back from 
pinkerton, who asks me to do this at least once a week.
Assignee: pinkerton → danm
Status: ASSIGNED → NEW
Depends on: 71895, 72111
Given my comments above from 2000-03-30, we want a workaround. The patch just
above should work around all remaining dialog parenting problems. (I say
"should" because parentless dependent dialogs happen in Mozilla only
sporadically; I don't know how to reproduce the problem.)

If you use WindowWatcher to open windows (pass a parent parameter of 0) and you
ask for a dependent/transient/child window, it will attach it to the topmost
active window it can find. (This is already checked in.) The above patch keeps
WindowWatcher's reference to the topmost active window current.
OK. I just managed to find a reproducible test case, and the above patch isn't 
working. It isn't working because I'm getting two different objects when I ask 
for the same service in two different places. This will be a joy to debug.
Figured it out. Not a service manager problem; just pilot error. Ignore the 
patch above. Use the patch below.
I'm closing this sucker. You could argue. Here's mine:

This bug is about nsIPrompts not being properly parented. The summary line is 
more colorful than that, but that's what this bug is about. A complete fix would 
be ensuring that in every situation in which a prompt needs to be posted, there 
is a properly parented nsIPrompt ready to use. I think we'll never catalog all 
the situations where this happens. Bug 67852 details the Case of the FTP Channel 
(currently dependent, currently targeted after this bug's target.) Bug 72111 
details an attempt to make it easier to find a proper nsIPrompt when one wasn't 
given. This bug has become a tracking bug for a situation that will never be 
completely resolved.

However, this bug has been fixed in *spirit*. Windows are no longer opened using 
Hidden Window as their parent. Dependent windows (like nsIPrompt windows) posed 
with no parent given (there are still many of these) are attached to the topmost 
window, whatever it is. Chances are that was the correct one, anyway. (The above 
patch, by the way, was the last part of hooking that up. The patch checked in for 
bug 76011 was a superset of the above patch).

This bug is targeted Mozilla 0.9 because we wanted to stop parentless modal 
dialogs from happening. That's been fixed. Modal dialogs are given foster parents 
when necessary. In the sense that this bug is a 0.9 bug for bad behaviour, it's 
been fixed. In the sense that it's a tracking bug for a bunch of other problems, 
it hasn't. I say it's a dessert topping. A 0.9 dessert topping. Closing it.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Dan, so this bug is really INVALID based on your description isn't it?  All the
fixes were in some other bugs.  Since this was a tracking bug at the time you
closed it, should we open a new tracking bug or just reopen this AS a tracking
bug?  (And possibly reassign it as well.)
The bugs mentioned in my comment just above detail all the continuing work on 
this subject that I know of. You could make a tracking bug as well, I suppose.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.