Closed Bug 29754 Opened 25 years ago Closed 24 years ago

ftp dependence on nsXULWindow

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
All
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: warrensomebody, Assigned: jud)

Details

(Whiteboard: [PDT-]) 

I noticed that nsFtpConnectionThread.cpp prompts the user by getting a XUL 
window's nsINetPrompt interface via proxy, etc. Yuck. We should be getting the 
nsIPrompt interface from the notificationCallbacks and calling that instead 
(without explicit proxying).

I think Gagan just made a similar fix to http (Gagan - if not, you need to). In 
general we should think of necko as a subsystem with minimal dependencies -- 
especially not dependent on layout, xul, rdf, etc.
Target Milestone: M15
[this is Warren from Rick's machine...] This fix has to go into http for beta, 
so by induction, this fix should also go into ftp for beta. Marking beta1.
Keywords: beta1
Target Milestone: M15 → M14
jud: I have split the nsIHTTPEventSink to only contain http specific events. The
auth now takes place thru the nsIPrompt interface thru the supplied
InterfaceRequestor. After I checkin the fixes for bug 27048 the changes for FTP
would be similar and small. 
cool, please send me a URL to your diffs off of tinderbox once your stuff is in.
Status: NEW → ASSIGNED
per PDT, please explain why this needs to be fixed for beta1
Whiteboard: [NEED INFO]
PDT-
Whiteboard: [NEED INFO] → [PDT-]
Target Milestone: M14 → M15
can the nsIPrompt that HTTP uses be used from a different thread?
Copying davidm on this since he can best answer jud's question.
The nsIPrompt( and nsINetPrompt) interface can only run on the UI thread. If you 
are going to be running on a different thread you have to do that proxying 
stuff. I assume the event sink does this but I haven't looked at gagan's code.

just checked in. nsIPrompt is now used (and proxied)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I think nsIPrompt should be proxied by the webshell before it gives it to us. We 
shouldn't be making the decision to proxy to the ui thread -- too many 
assumptions about its implementation.
agreed. we should enfornce this rule everywhere.
Should we reopen this then?
I think we should make a sweep across all the stuf we're currently proxying and 
enforce the rule all at once.
Can you file a bug to remember to do this? Thanks.
marking verified per valeski's comments
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.