Closed Bug 27048 Opened 25 years ago Closed 24 years ago

need http clients to implement nsIHTTPEventSink

Categories

(Core :: Networking, defect, P3)

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: gagan, Assigned: mscott)

References

Details

(Whiteboard: [nsbeta2-][nsbeta3+])

Attachments

(1 file)

so that we can move auth-prompting, redirects updates to the client.
Who are the clients besides webshell? Should this be assigned to Travis?
Target Milestone: M15
I think its just the webshell for now... off to travis. Once this is done it will also help us crack other bugs relating to URI updates on redirects (see bug 20072, bug 10647)
Assignee: gagan → travis
Blocks: 20072
taking over... (and marking PDT+ thru property of transitive associativeness) :)
Assignee: travis → gagan
Whiteboard: PDT+
Target Milestone: M15 → M14
Status: NEW → ASSIGNED
Whiteboard: PDT+ → PDT+ ETA 02/29/00
the webshell has changed significantly last night and is going to continue to evolve (per travis) and since the changes rely on the structure of the webshell, this has an indeterminate ETA.
Whiteboard: PDT+ ETA 02/29/00 → PDT+ ETA indeterminate
Blocks: 9472
*** Bug 9472 has been marked as a duplicate of this bug. ***
*** Bug 20072 has been marked as a duplicate of this bug. ***
updating eta
Whiteboard: PDT+ ETA indeterminate → PDT+ 03/01/00
There are two pieces of this problem-- one that necko needed to call events on the eventsink (the part that I have done and is ready for review/checkin) and a second part that makes the webshell (or as per travis the uriloader) implement the interface to do the actual thing-- ranging from throwing the auth dialog box to updating the location bar based on the events from HTTP. Jar recommends that we check in both the pieces at reasonably close enough intervals otherwise we would have a period of severe regression. And so I am going to hold off my changes till I can get an implementor for nsIHTTPEventSink and nsIPrompt (travis/mscott)
Whiteboard: PDT+ 03/01/00 → PDT+ holding off
Gagan: Can you put a dependency in for the bug that Travis/Mscott would be working on? We can make the two mutually dependendent... but we need to be sure that both are on the beta1 PDT+ radar. Thanks
Whiteboard: PDT+ holding off → PDT+ holding off for parallel landing with Travis/Mscott
this bug itself was really intended for that purpose... however I landed up changing part of HTTP event sink in doing so. So if you want I can create a separate bug or just leave this as the main one.
Blocks: 19221
Blocks: 28594
Adding myself to cc and adding beta1 per beta bug #9472. -kevin
Keywords: beta1
Gagan, I can help out and take a look at implementing this in the doc loader for now. I've got another PDT bug I'm working on right now and when I'm done i'll start looking at this one.
Hey gagan, if i add http event sink support to the doc loader, what exactly do you expect the doc loader to do when it's told things like: OnhttpHeadersAvailable, etc.
Adding [Activation] to summary field, since Activation depends on this (0rig Activation bug was 28730, which was a dup of 9472, which was a dup of 27048, which is a dup of this bug.) thx, kevin
Summary: need http clients to implement nsIHTTPEventSink → [Activation] need http clients to implement nsIHTTPEventSink
I know everyone is cranking away very hard, but may I ask what the anticipated date of the parallel landing is? Turning Activation on and getting Activation to work bugfree is dependent on this. thx, kevin
Blocks: 30287
*** Bug 30287 has been marked as a duplicate of this bug. ***
Kevin: I don't know. I haven't even started to look at this bug to see what work Gagan needs help with for the doc loader. On a side note, can you explain what activation has to do with implmenting a http event sink in the doc loader? I'm missing the big picture and am just curious. (also, what is activation?)
Blocks: 28069
1. What is Activation? Briefly, Activation is : - NC registration integrated with the install process. - Necessary to activate server-based features, such as AIM, Webmail, Calendar, Radio, etc. - Dialog-like pages served from Netcenter into a chromeless browser window 2. How does Activation relate to this bug? Basically, - 0rig Activation bug was 28730, which was a dup of 9472, which was a dup of 27048 - 28730 says that a js function(GetQueryParameter) result is not being received. Bhuvan and I checkout out the js and it looks fine. Also, marking Confidential per all Activation bugs, and it's ok because all folks in cc are netscape.com thx, kevin
No longer blocks: 28069
Group: netscapeconfidential?
I still don't quite get it. What feature does nsIHTTPEventSink being implemented give us?
Kevin, I'm trying to go back through the activation bugs that eventually led to involve this bug (I don't understand how this applies to activation yet). You listed 28730 as the original activation bug but that's a mailnews bug. Maybe you have the wrong number?
Here's a summary of the Activation bug trail: 28730 --> 9472 --> this bug. 28730: - http://ins-group1.netscape.com:9999/activation/en/activation.cgi - To replicate original bug: 1. sign into netcenter (sets nc cookie on your computer) 2. load the above url 3. The first radio buttons says "My Netscape user name is." The bug is that your user name is missing at the end of the sentence. It works fine in M13. - This js found at the above URL works in M13 but not in recent builds: userid = GetQueryParameter(query, "userid") - The problem is that we seem to lose the search parameters when we do a 302 redirection (hence window.location.search returns nothing). A DUP of bug 9472. 9472: - window.location.search is not set when a HTTP 302 redirect occurs to a page with a search string which is how Messenger Express server passes arguments to the client application - The original URL specified is not valid. I did find a place on Netcenter where a HTTP 302 redirect takes you to a page with a search component (a ? in the URL). It seems like netlib is stripping out or somehow losing the search component. As a result, querying it through JavaScript returns the wrong answer. - yes this is a definite dup of bug 27048 and norris we need to merge in our changes... 27048 is this bug. I hope this helps instead of confuses. thx, kevin
Blocks: 30271
mscott, I believe 28730 is the right bug to begin with. I don't get a mail/news when I load: http://bugzilla.mozilla.org/show_bug.cgi?id=28730 thx, kevin
mscott: Essentially nsIHTTPEventSink will provide two functions- one for OnHeadersAvailable (which for now would be a no-op but would essentially allow anyone to do a GetContentType and maybe retargetting if required) the other function is OnRedirect which would give the correct URL to which we are redirecting. This should be used to update the location bar. (which is why bugs like 9472 become dups)
Blocks: 8310
Travis/Mscott: When will the other half of this be ready? Please put this landing date into the status whiteboard, or include a reference to the bug for the other "half" in the "depends on" list above. Thanks, Jim
Jar, travis and I don't have another bug to track our part for this. I was going to use this one. Let me know if you'd rather have us file a separate one. As far as a timeline goes. We just started looking at the work gagan needs us to do on Friday. We need to talk to gagan to get a better understanding of what (and where) our stuff needs to do. We'll post an estimate after we talk to Gagan on monday.
andreas.otte@primus-online.de would like to look at this bug, is there a good reason this is netscape confidential?
Removing confidential marking. -kevin
Group: netscapeconfidential?
Current Status: Gagan, Travis and I spent some time looking at this this afternoon and we think we don't need to fix this bug for beta. Norris checked in a bug fix Thursday or Friday which fixed the redirection problem. We checked the bugs that were depending (or marked as dups of this bug) involving redirecting urls and they were all working now. We still need to implement nsIHTTPEventSink. Just not for beta. Activation group: you guys should be unblocked from your dependency on this bug. Clearing the pdt+ resolution so the pdt team can re-evaluate.
Whiteboard: PDT+ holding off for parallel landing with Travis/Mscott → holding off for parallel landing with Travis/Mscott
I would also add that the only problem we saw with redirection was the fact that the url bar isn't being updated with the new redirected url. But relative links inside of the new redirected document were all resolved correctly.
Putting on PDT+ for beta1. Please fix by 03/08
Whiteboard: holding off for parallel landing with Travis/Mscott → [PDT+]w/b minus on 03/08 - holding off for parallel landing with Travis/Mscott
Putting on PDT- for beta1. Please open new bug on location bar issue.
Whiteboard: [PDT+]w/b minus on 03/08 - holding off for parallel landing with Travis/Mscott → [PDT-]w/b minus on 03/08 - holding off for parallel landing with Travis/Mscott
Here's the bug I filed for updating the location bar on redirects: 30783
Blocks: 28728
FWIW I have checked in the HTTP side of the story. I have also checked in changes on the webshell/docshell to return a valid nsIPrompt from the GetInterface calls. So things should work fine now.
IF this is completely fixed (as per comment from gagan), this really needs to be marked fixed, and the dependent PDT+ 27797 bug needs to be closed (marked fixed). Thanks, Jim
I don't think it's fixed completely. Grace -- Assuming the NC activation service is up, we'll see this bug remains: - On the Confirmation screen (Activation Complete), the user name is still missing. The first half of the problem seems to have been fixes -- on cookie-exists Invitation screen, the lookup does occur. Will provide more details as soon as I can, but want to type this quick note now. thx, kevin
Hmm... if this is not fixed... then it is holding up a PDT+ bug 27797 (to some extent). What is the plan/story? Do we have to release note the other bug?? Thanks, Jim
Blocks: 22658
It is realized that the actual problems were in javascript sources on activation servers, as things started working fine once activation team fixed them. Once they reached the place where they called window.location.search, the client is doing the right thing (in the activation case). I have already removed bug 27797's dependency on this one.
Keywords: beta2
Blocks: 25684
Blocks: 28459
Moving to M15
Target Milestone: M14 → M15
this should now be owned by someone in webshell... to travis
Assignee: gagan → travis
Status: ASSIGNED → NEW
Target Milestone: M15 → M16
Keywords: nsbeta2
Travis is gone. Who's looking at this?
Scott, are you the de-facto owner now?
Assignee: travis → mscott
Whiteboard: [PDT-]w/b minus on 03/08 - holding off for parallel landing with Travis/Mscott
Need to know if this is still a problem to get activation up and running?
Whiteboard: [NEED INFO]
I don't think activation is depending on this anymore. We had activation up and running in PR1 (and unitl couple of builds which now suffers with some docshell problem) and I think the parts required for activation are fixed. Gagan or Scott should at look why this bug is origianlly opened and if there are any other issues that need to be addressed/fixed with this bug.
Putting on [nsbeta2-] radar.
Whiteboard: [NEED INFO] → [nsbeta2-]
Blocks: 39439
How can this bug be [nsbeta2-] when it's blocking several [nsbeta2+] bugs? Here's the current status of some of the dependent bugs: bug 39439 [nsbeta2+] bug 30271 [nsbeta2+] bug 28594 [nsbeta2+] 6/1 bug 28459 [nsbeta2+] 6/1 bug 25684 [nsbeta2+] (crasher) Removing [nsbeta2-] from Status Whiteboard for reconsideration, cc self.
Whiteboard: [nsbeta2-]
Putting on [nsbeta2+] radar for beta2 fix base on blocking issues. If there are workarounds, please remove [nsbeta2+] or re-eval.
Whiteboard: [nsbeta2+]
Good catch Andreas: this bug is (has been) considered a major chokepoint for a lot of nsbeta2+ bugs, and it was silly to mark it -. However, I should mention that we're currently re-evaluating our assumptions that those bugs (modal window parenting issues) are actually dependent on this bug. So don't panic yet. A lot of dependencies on this bug may be cleared out. More news soon.
No longer blocks: 25684
No longer blocks: 19221
No longer blocks: 22658
No longer blocks: 28459
No longer blocks: 28594
No longer blocks: 39439
I believe the modal dialog parenting bugs marked as dependent on this one aren't actually. I'd been told they were, but it's looking unrelated to me now that I actually look into it. Without being completely certain, I'm clearing those dependencies. That leaves this bug as blocking one nsbeta2+ bug: 30271, so I can't clear the +.
removing activation from status summary since there no longer is a dependency
Summary: [Activation] need http clients to implement nsIHTTPEventSink → need http clients to implement nsIHTTPEventSink
M16 has been out for a while now, these bugs target milestones need to be updated.
I would not pull beta2 off the wire for this. Per the leads meeting today that's the new litmus test. Adding the nsbeta2-. You'll see email from the some one up above real soon now describing these decisions. I don't believe the bug that depends on this is one I'd pull off the wire for either.
Keywords: nsbeta3
Whiteboard: [nsbeta2+] → [nsbeta2-]
Target Milestone: M16 → M18
Attached patch proposed fix (deleted) — Splinter Review
I attached the changes necessary for proper implementation of nsIHTTPEventSink. However, the various bugs that depend on this implementation of course require docshell to do certain things when it is told there is a redirect.....
Status: NEW → ASSIGNED
Blocks: 49552
note that 30783 got reopened recently and fixing this bug would help fix that more conveniently.
nsbeta3+ per triage meeeting.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
the doc loader now implments this interface and calls into the docshell with a on location change notification in the case of redirects. Any future bugs which require docshell to handle this new information will be dealt with in other bugs.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
development issues - verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: