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() 00eb8
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)
Per Chak, reassigning to rpotts and cc'ing alecf.
QA Contact: depstein → rpotts
Assignee: chak → rpotts
QA Contact: rpotts → depstein
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 flag. This patch simply masks off all flags that are *not* nsIRequest flags (especially LOAD_DOCUMENT_URI)... -- rick
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?
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
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..
the documentation for nsIRequest.idl states that the first 16bits are reserved for nsIRequest... see: http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIRequest.idl#114 of course, that's very easy to overlook... we probably want to make it more prominent.
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 on attachment 82897 [details] [diff] [review] Mask off all non-nsIRequest load flags... r=darin (thx rick!)
Attachment #82897 - Flags: review+
patch checked into the trunk.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
this new assert ("attribute encountered") is bug 143512
*** 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
Fix checked into 1.0 branch along with bug 93015
Ashish --Can you mark this as verified1.0.2 in David's absence?
QA Contact: depstein → ashishbhatt
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.