Loading www.netscape.com results in "wrong document channel" assertion (in nsDocLoader)




Embedding: APIs
16 years ago
16 years ago


(Reporter: David Epstein, Assigned: rpotts (gone))


Windows NT

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
Mozilla 0.9.9 Gecko/20020307 debug build. Doesn't happen when launching mozilla,
only MfcEmbed. Occurs in testEmbed when loading some urls.

Assertion: "Wrong Document Channel: 'request==mDocumentRequest', file
/mozilla/uriloader/base/nsDocLoader.cpp line 1292

debug log:

nsDebug::Assertion(const char * 0x01b84ad0, const char * 0x01b84ab4, const char
* 0x01b84a7c, int 1292) line 291 + 13 bytes
nsDocLoaderImpl::OnRedirect(nsDocLoaderImpl * const 0x01684efc, nsIHttpChannel *
0x02d37850, nsIChannel * 0x03637bb0) line 1292 + 49 bytes
nsHttpChannel::ProcessRedirection(unsigned int 302) line 1292 + 54 bytes
nsHttpChannel::ProcessResponse() line 501 + 12 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x02d37854, nsIRequest *
0x02d38b14, nsISupports * 0x00000000) line 2494 + 11 bytes
nsOnStartRequestEvent::HandleEvent() line 161 + 53 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x03661a04) line 116
PL_HandleEvent(PLEvent * 0x03661a04) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00eb8d90) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001d0276, unsigned int 49307, unsigned int 0,
long 15437200) line 1071 + 9 bytes
USER32! 77e71820()

Comment 1

16 years ago
It's happening when netscape.com is loaded. Change location pref in MfcEmbed,
and it will launch file. Chak, who should this be reassigned to?
Severity: normal → major
QA Contact: mdunn → depstein
Summary: Launching MfcEmbed results in "wrong document channel" assertion (in nsDocLoader) → Loading www.netscape.com results in "wrong document channel" assertion (in nsDocLoader)

Comment 2

16 years ago
Per Chak, reassigning to rpotts and cc'ing alecf.
QA Contact: depstein → rpotts

Comment 3

16 years ago
Assignee: chak → rpotts
QA Contact: rpotts → depstein

Comment 4

16 years ago
Created attachment 82897 [details] [diff] [review]
Mask off all non-nsIRequest load flags...

Comment 5

16 years ago
I've attached a patch that fixes this problem...  

It appears that some code was calling GetLoadFlags() on the loadgroup, and then
passing those flags on to a new channel.  Unfortunately, since the load group
gets its flags from the 'defaultRequest' it was inheriting the LOAD_DOCUMENT_URI

This patch simply masks off all flags that are *not* nsIRequest flags
(especially LOAD_DOCUMENT_URI)...

-- rick

Comment 6

16 years ago
Comment on attachment 82897 [details] [diff] [review]
Mask off all non-nsIRequest load flags...

is there some way that one would know that 0xFFFF are not a part of nsIRequest
flags? Perhaps this mask can be defined somewhere more public, so that future
flags stay in this range?

Comment 7

16 years ago
hey alec,

nsIRequest has already frozen...  So, new flags probably won't be added...

I could just 'or' all of the nsIRequest flags together instead of sing '0xFFFF'.
 It would be clearer (i was just avoiding the typing :-)).

do you think that would be better?
-- rick

Comment 8

16 years ago
well, I am just never a fan of magic numbers :)

Basically, I see you taking advantage of the property that all flags are <
0xFFFF, but I don't see that property actually described anywhere..

Comment 9

16 years ago
the documentation for nsIRequest.idl states that the first 16bits are reserved
for nsIRequest... see:


of course, that's very easy to overlook... we probably want to make it more

Comment 10

16 years ago
Comment on attachment 82897 [details] [diff] [review]
Mask off all non-nsIRequest load flags...

doh! Doh. I missed that line :) 
/me removes foot from mouth

with that, sr=alecf, I'll let darin do the full r=
Attachment #82897 - Flags: superreview+

Comment 11

16 years ago
Comment on attachment 82897 [details] [diff] [review]
Mask off all non-nsIRequest load flags...

r=darin (thx rick!)
Attachment #82897 - Flags: review+

Comment 12

16 years ago
patch checked into the trunk.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 13

16 years ago
Mozilla 1.0.0+ Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0+) Gecko/20020509
verified patch against this build in mozilla and MfcEmbed. No longer getting
"wrong doc channel" assert for netscape.com, but getting another assert in
htmlparser code ("attribute encountered". Will submit another bug against that.

Comment 14

16 years ago
this new assert ("attribute encountered") is bug 143512

Comment 15

16 years ago
*** Bug 137557 has been marked as a duplicate of this bug. ***
I'm proposing merging this fix onto the 1.0 branch as part of bug 93015


16 years ago
Blocks: 93015
Fix checked into 1.0 branch along with bug 93015
Keywords: fixed1.0.2

Comment 18

16 years ago
Ashish --Can you mark this as verified1.0.2 in David's absence?
QA Contact: depstein → ashishbhatt

Comment 19

16 years ago
verified on 1.0.2
Keywords: fixed1.0.2 → verified1.0.2
You need to log in before you can comment on or make changes to this bug.