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

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[David Epstein]

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

Comment 1

[David Epstein]

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?

Comment 2

[David Epstein]

Per Chak, reassigning to rpotts and cc'ing alecf.

Comment 3

[David Epstein]

oops

Comment 4

[rpotts (gone)]

Attachment: Mask off all non-nsIRequest load flags...

Comment 5

[rpotts (gone)]

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 6

[Alec Flett]

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

[rpotts (gone)]

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

[Alec Flett]

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

[Darin Fisher]

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 10

[Alec Flett]

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=

Comment 11

[Darin Fisher]

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

r=darin (thx rick!)

Comment 12

[rpotts (gone)]

patch checked into the trunk.

Comment 13

[David Epstein]

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

[David Epstein]

this new assert ("attribute encountered") is bug 143512

Comment 15

[rpotts (gone)]

*** Bug 137557 has been marked as a duplicate of this bug. ***

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

I'm proposing merging this fix onto the 1.0 branch as part of bug 93015

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

Fix checked into 1.0 branch along with bug 93015

Comment 18

[Michael Dunn]

Ashish --Can you mark this as verified1.0.2 in David's absence?

Comment 19

[Ashish Bhatt]

verified on 1.0.2