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

RESOLVED INVALID

Status

()

Firefox
Extension Compatibility
RESOLVED INVALID
9 years ago
7 months ago

People

(Reporter: Stijn Sanders, Unassigned)

Tracking

3.0 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 1

9 years ago
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

7 years ago
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/
Version: unspecified → 3.0 Branch
(Reporter)

Comment 3

7 years ago
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

7 years ago
Any update? Is this bug still valid?
(Reporter)

Comment 5

7 years ago
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

7 years ago
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

7 months ago
Legacy extensions are no longer valid in Firefox 57, closing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.