Closed
Bug 44809
Opened 25 years ago
Closed 24 years ago
Appshell - nsIPrompt Service needs to die
Categories
(SeaMonkey :: UI Design, defect, P1)
SeaMonkey
UI Design
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
Updated•25 years ago
|
Updated•25 years ago
|
Whiteboard: nsbeta3+ → [nsbeta3+]
Updated•25 years ago
|
Target Milestone: --- → M18
Reporter | ||
Comment 1•25 years ago
|
||
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
Comment 3•25 years ago
|
||
cc hyatt,jrgm. How important is this for N6, really?
Whiteboard: [need info]
Reporter | ||
Comment 4•25 years ago
|
||
Depending on the dialog service and the hidden window will screw up modality.
Comment 5•25 years ago
|
||
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+]
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 6•24 years ago
|
||
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
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
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
Assignee | ||
Comment 10•24 years ago
|
||
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
Updated•24 years ago
|
QA Contact: sairuh → jrgm
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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
Updated•24 years ago
|
OS: Windows NT → All
Priority: P4 → P1
Hardware: PC → All
Comment 14•24 years ago
|
||
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 :-)
Assignee | ||
Comment 15•24 years ago
|
||
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 | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
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.
Assignee | ||
Comment 18•24 years ago
|
||
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.
Assignee | ||
Comment 19•24 years ago
|
||
Figured it out. Not a service manager problem; just pilot error. Ignore the
patch above. Use the patch below.
Assignee | ||
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
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: 24 years ago
Resolution: --- → FIXED
Comment 22•24 years ago
|
||
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.)
Assignee | ||
Comment 23•24 years ago
|
||
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.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•