54224 - Assertion when loading a plugin from XUL in chrome

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect, P3)

Description

[David Ascher]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    2000091312

Attached XUL file, if used with our plugin (but, IIRC, also w/ the Sample 
plugin), I get an assertion saying "don't do that".  



Reproducible: Always
Steps to Reproduce:
1. Put attached XUL in chrome
2. load XUL with a chrome:// URL


Actual Results:  Assertion. 


Traceback:nsDebug::Assertion(const char * 0x010f4b24, const char * 0x100c6474, 
const
char * 0x010f4ae8, int 312) line 256 + 13 bytes
nsDebug::NotReached(const char * 0x010f4b24, const char * 0x010f4ae8, int
312) line 414 + 22 bytes
nsCachedChromeChannel::GetContentLength(nsCachedChromeChannel * const
0x02c71380, int * 0x0012fb2c) line 312 + 21 bytes
nsPluginStreamListenerPeer::OnStartRequest(nsPluginStreamListenerPeer *
const 0x02c71430, nsIChannel * 0x02c71380, nsISupports * 0x00000000) line
1176 + 16 bytes
nsCachedChromeChannel::HandleStartLoadEvent(PLEvent * 0x02c71110) line 515
PL_HandleEvent(PLEvent * 0x02c71110) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00559910) line 508 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002a0234, unsigned int 49633, unsigned
int 0, long 5609744) line 1044 + 9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
%0

Comment 1

[David Ascher]

Attachment: Test case XUL

Comment 2

[David Ascher]

It's possible that we're doing something wrong in the plugin, but I doubt it, 
since the plugin is pretty simple -- it does no loading of URLs, doesn't know 
chrome from its foot, and I'm pretty sure I once reproduced it with the Sample 
plugin (where can I get that one again?).  I suspect that the problem is that 
most folks use plugins in non-chrome areas, so we're exercising an "unusual" 
code path.

Email from a conversation with Chris Waterson follows:

>> How are you getting a cached chrome channel when loading something from
>> a plugin? (The only thing that I can think of is that you're trying to
>> load a XUL file as a "chrome:" URL from the plugin?)
>
> Well, the plugin isn't trying to load any chrome, but the plugin is _hosted_
> inside a chrome XUL.  So, if I understand correctly, the plugin manager
> creates a stream for the chrome (that the plugin lives in), and passes it to
> the plugin so that it can stream it or render it or whatever).
>
> Does this make sense and help elucidate things?
							
Yes...could you send me the snippet from the XUL file that instantiates
the plugin? Also, what was the stack trace when the assertion was hit?

thanks,
chris

Comment 3

[sean echevarria]

Hey - the assertions stopped recently...  WFM

Comment 4

[Mark Hammond [:markh] [:mhammond]]

Sean writes that the assertions have stopped, but it is still happening for me 
from the tip.

Comment 5

[sean echevarria]

Sorry about my false comment - looks like I commented out the assert before the 
holidays and forgot about it...

Comment 6

[Mark Hammond [:markh] [:mhammond]]

Attachment: To help tickle this bug, a proposed patch.

Comment 7

[Chris Waterson]

sure, r=waterson

Comment 8

[Mark Hammond [:markh] [:mhammond]]

This has had an r= for a while now.  Who can offer an sr=?  The bug is probably 
in the wrong component (currently "Plugins", as the patch is for rdf/chrome.)

Comment 9

[sean echevarria]

You need to specifically ask a particular person for sr (and copy
[e-mail] in the email).  See
http://www.mozilla.org/hacking/reviewers.html

Comment 10

[Mark Hammond [:markh] [:mhammond]]

The nominated super-reviewer appears to be waterson, but he offered his r=.  
Adding blizzard to CC in the hope of getting an sr from him :)

Chris: This is a trivial patch that removes an assertion, and includes a test 
case.

Comment 11

[Christopher Blizzard (:blizzard)]

I can sr this but I see no description in this bug as to why the assertion is bogus.

Comment 12

[Josh Aas]

It's possible that loading a plugin from chrome still doesn't work but it's highly unlikely that the issue referenced in this bug is the problem.