306015 - Expose more information about redirects in STATE_REDIRECTING events [was: pass onChannelRedirect notifications to nsIWebProgressListeners that impl nsIChannelEventSink]

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, defect)

Description

[timeless]

we need a way to get redirect notifications for stuff we observe. biesi
suggested allowing nsIWebProgressListener implementations to also implement
nsIChannelEventSink and forwarding notifications there.

Comment 1

[timeless]

Attachment: pass it along

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 193897 [details] [diff] [review]
pass it along

this'd be simpler if you forwarded OnChannelRedirect before calling
OnStateChange...

I'm not sure it's a good idea to foward to the parent... it certainly has the
downside that the listener can't tell whether the parent itself or a child of
it was redirected...

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 193897 [details] [diff] [review]
pass it along

hrm, this patch also doesn't tell you whether the redirect was the document
itself or an image or something...

Comment 4

[Darin Fisher]

Comment on attachment 193897 [details] [diff] [review]
pass it along

I think we decided that this patch is not sufficient, right?

Comment 5

[Darin Fisher]

So, IIRC.. a better solution would be to stash a reference to the new channel on
the old channel that is passed to onStateChange(STATE_REDIRECTING).  We could
also stash the redirect flags as well.  We could either make the channel do this
for us or we could make DocLoader::OnChannelRedirect do it before issuing the
onStateChange call.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 193897 [details] [diff] [review]
pass it along

note that what darin said would have the interesting property that one could
follow the entire redirect chain up to the original channel. (if only I
remembered what I wanted to do with that information last time I wanted it...)

Comment 7

[Darin Fisher]

biesi: actually, because we pass the old channel in the onStateChange
notification, you'd only be able to learn about the new channel.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

oh, hrm. I guess that's true. we could also store the previous channel on the
new channel though :-) (although, we better don't do this, due to ref cycles...)

Comment 9

[Benjamin Smedberg]

Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.