501952 - Implementing nsIHttpChannel requires nsIHttpChannelInternal as well to get images on pages to work

Status: RESOLVED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[Stijn Sanders]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.33 Safari/530.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

That is, I still can't get it to work, for some reason. The secundary channel get's SetRequestHeader called, but is then dropped. I found this in the code: http://tinyurl.com/le7m77 requiring image channels to implement nsIHttpChannelInternal, but this QueryInterface call doesn't even get through to my module, perhaps because it's an unstable interface?

I've posted this issue here also: http://stackoverflow.com/questions/1046523/nsiprotocolhandler-trouble-loading-image-for-html-page

Reproducible: Always

Steps to Reproduce:
1. create a custom nsIHttpChannel implementation (like this one, see below for a ready-made debug-dll: http://xxm.svn.sourceforge.net/viewvc/xxm/trunk/Delphi/gecko/)
2. request page a.html with <img src="a.png" />
3. a.html loads fine, NewChannel gets called for a.png
4. SetNotificationCallbacks and SetRequestHeader("Accept",... is called on the channel
5. *break* ?
6. the image channel is freed (no SetLoadGroup, no AsyncOpen, nothing)
Actual Results:  
page shows broken image icon instead

Expected Results:  
page should show PNG

see also http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/6facf8e74bcac10f
for a ready-made debug-dll and reproduce-script:
http://drop.io/xxmGeckoBugRepro1

Comment 1

[Stijn Sanders]

Wait a minute! Why isn't this page showing the interface's UUID has changed!
http://www.oxymoronical.com/experiments/apidocs/compare/interface/nsIHttpChannelInternal/1.9.0.0/1.9.1b2

Comment 2

[Tim (fmdeveloper)]

Reporter -> Are you still experiencing this issue with the latest version of Firefox 3.6.15? Does the issue occur with the latest nightly? http://nightly.mozilla.org/

Comment 3

[Stijn Sanders]

There's something changed in 3.6 that breaks my add-on. I've been debugging the firefox source to see what's going wrong where, but haven't been able to find it yet. I'm also stuck figuring out how nsInputStreamPump actually works, to see if I was mimicing the right part, and what I should be doing...

Comment 4

[Tim (fmdeveloper)]

Any update? Is this bug still valid?

Comment 5

[Stijn Sanders]

I've checked with my add-on version that's ready for FF7, and without exposing the nsIHttpChannelInternal interface, the images on the page I serve don't load. So I guess this bug is still valid. (Is it really a bug, if you guys have a really good reason for this so be it. I should take some time to dig into the code or run it with a debugger.)

Comment 6

[caribou]

In fact, i faced the same problem implementing a custom http channel and the problem comes from imgLoader.cpp (you can see it at http://dxr.mozilla.org/mozilla/mozilla-central/modules/libpr0n/src/imgLoader.cpp.html).

I think this is caused by the "evil hack" as it is said in the comment to associate the original document uri to the image http channel. It is only done for http channel (not the other : data channel, file channel...)

The guilty code is the following : 

------
 // Initialize HTTP-specific attributes
  newHttpChannel = do_QueryInterface(*aResult);
 if (newHttpChannel) {
    newHttpChannel->SetRequestHeader(NS_LITERAL_CSTRING("Accept"),
                                     aAcceptHeader,
                                     PR_FALSE);

    nsCOMPtr<nsIHttpChannelInternal> httpChannelInternal = do_QueryInterface(newHttpChannel);
    NS_ENSURE_TRUE(httpChannelInternal, NS_ERROR_UNEXPECTED);
    httpChannelInternal->SetDocumentURI(aInitialDocumentURI);
    newHttpChannel->SetReferrer(aReferringURI);
  }
-----
I just found the cause but can't really understand what is involved here and if it can be changed. If it is really necessary, there should at least be a message in the error console when nsIHttpChannelInternal is missing from a channel implementation as it is done for nsIUploadChannel2. But the problemn I think is that that interface is far from beeing frozen !!!

Comment 7

[Andy McKay]

Legacy extensions are no longer valid in Firefox 57, closing.