forked from Bug 332807 because branch still crashes crash: https://bugzilla.mozilla.org/attachment.cgi?id=217441 in print preview the XUL button is clickable: https://bugzilla.mozilla.org/attachment.cgi?id=217411

marking [sg:critical] based on bug Bug 332807

Who should own this bug?

Moving this to 1.8.1.18 since Jonas hasn't had time to look.

Jonas, update on this bug as well? As it's sg:crit, the sooner the better...

qawanted: can this be made to affect Thunderbird?

> qawanted: can this be made to affect Thunderbird? i will check next week. imho it is fixed at least on trunk and 1.9, so if they are affected it will be from nontrivial modification of this.

attachment |xul iframe doing parent.document.open() - open this| in the other bug seems safe on trunk (short of some |alert| strangeness) but causes |illegal instruction on latest 1.8 branch

thunderbird -central and 1.8-latest display the XBL generated xul when served in iframe src="..." yet the javascript is not executed so no crash.

the 1.8 branch crash in comment #7 happen onload, so no user interaction or print preview is required if i have tested correctly.

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fcd34b70780 (LWP 21609)] 0x00007fcd341088e2 in nsQueryInterface::operator() (this=0x7fff3cb9f7c0, aIID=@0x13de820, answer=0x7fff3cb9f7d8) at nsCOMPtr.cpp:47 47 status = mRawPtr->QueryInterface(aIID, answer); (gdb) x/i $pc 0x7fcd341088e2 <_ZNK16nsQueryInterfaceclERK4nsIDPPv+42>: mov (%rax),%rcx (gdb) p/x $rax $1 = 0x2900000001 (gdb) p mRawPtr $2 = (class nsISupports *) 0x2b888e0 (gdb) p *mRawPtr $3 = {_vptr.nsISupports = 0x2900000001}

afaict thunderbird is not affected by this bug, unless there is javascript execution bug in 1.8 branch. what may be affected is seamonkey branch 1.8 with the nonstandard option "enable javascript in mailnews". in this case the xbl javascript is executed, though i didn't crash.

Honestly I have no idea how to fix this safely on the 1.8 branch. We did some pretty big rearchitecturing to fix it for 1.9 (the whole scriptblocker setup). Don't fully remember what that depended on, but I'd be very worried back porting it. Bz: Any thoughts? I know the content sink for example was not as good at calling BeginUpdate/EndUpdate as needed back then?

Can we just change untrusted XBL to never run script in a mailnews docshell, perhaps?

>Can we just change untrusted XBL to never run script in a mailnews docshell, >perhaps? in theory no javascript should not be executed (unless the user dumbly allows it) in mailnews. i am not sure your proposal will solve to problem for all cases of <xul:iframe src="javascript:" - can you tell in this case the js is xbl generated?

> in theory no javascript should not be executed (unless the user dumbly allows > it) in mailnews. Users do that, though. > can you tell in this case the js is xbl generated? Indeed, no. We could block javascript: in anonymous content iframes, but that's a bit whack-a-molish...

is acceptable and realistic disabling loading the binding in userland mailnews?

Disabling non-chrome bindings? That might not be a bad idea...

btw, i would like an option for the above for browser too if possible.

(In reply to comment #18) > btw, i would like an option for the above for browser too if possible. Dan asked about Thunderbird because, in the event that this misses the next branch release, this bug will still need to get fixed on the 1.8 branch for Thunderbird.

> Dan asked about Thunderbird because, i realize this, i just would like the option for paranoid reasons :)

more mail testing suggests that an important part of the browser crashing testcase is NOT executed in mailnews with js, namely <xul:iframe src="javascript:...document.open()". this may have fixed the testcase in mail, can't tell for sure.

It looks from georgi's last comment isn't a mail issue, so I think this is now WONTFIX because we're not going to backport to the 1.8 branch. I'm all for disabling XBL from content, though, so if reopening this bug helps with that, then please feel free. :)

> I'm all for disabling XBL from content there is another bug for this.