265921 - Scripts may close windows that were not opened by script.

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Omar Khan]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0

Peace.

Okay, I am not sure if I am an idiot or not,
but here goes.
I tried window.close() and got this error 
message
Scripts may not close windows that were not opened by script.

So I tried two additional hacks

<a href="javascript:
	var e = document.createEvent('Events');
	e.initEvent('DOMWindowClose',true,false);
	window.dispatchEvent(e);
">CloseWindow</a> - close this, requires two tabs to be open

<a href="javascript:
window.name='thisThing';
window.open('','thisThing','');
window.close();
">CloseWindowReloaded</a> - close this, close the browser if
one tab opened

and was successful.

So I am wondering is this is a bug or feature - like
certain script may have certain privilege, or
I got the wrong preference setting.
I know I am missing something?
Got wrong build?

Reproducible: Always
Steps to Reproduce:
1. For issue one need two tabs opened
2. For issue two need just one tab to close browser
3.

Actual Results:  
For 1. Close tab when two tabs open
For 2. Close browser when one tab open

Expected Results:  
Should not close browser or tab since
I get error message 
Scripts may not close windows that were not opened by script.
when I tried window.close()

Comment 1

[Omar Khan]

Attachment: Just a testcase so you can click the links

Testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

>	e.initEvent('DOMWindowClose',true,false);

Tabbrowser should be checking whether the event is trusted, I would say.  See
http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/tabbrowser.xml#1409
and
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/tabbrowser.xml#1552

> window.name='thisThing';
> window.open('','thisThing','');

This one is fun... danm?  Ideas?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Attempt to fix the event thing

You'd think this would fix the event thing.  It doesn't seem to, over here.

Comment 4

[Johnny Stenback (:jst)]

Attachment: Complete fix.

This is bz's patch, in addition to an event state manager fix for a problem
where it ended up marking all non-mouse/key events dispatched from chrome (or
when UniversalBrowserWrite is enabled) as trusted events. This also fixes the
event.isTrusted getter to properly return true/false (and not 2 or false, as it
currently does).

Comment 5

[Brendan Eich [:brendan]]

Argh.  How many other places might set *aBoolResult = (field & mask)?  Maybe we
can lxr for that.  Trying ....

/be

Comment 6

[Brendan Eich [:brendan]]

Comment on attachment 163352 [details] [diff] [review]
Complete fix.

sr=[e-mail] and approving, good fixes.

/be

Comment 7

[Johnny Stenback (:jst)]

Attachment: Also stop window.dispatchEvent() from always throwing exceptions

This is kindof a followup fix to the earlier patch, but is not needed to block
the security hole. Looks like fallout from some decomtamination work, not sure
(bonsai isn't cooperating right now), but it should be fixed.

Comment 8

[Dan M]

>Argh.  How many other places might set *aBoolResult = (field & mask)?  Maybe we
>can lxr for that.  Trying ....

OK somebody smack me down. Why is comment 4 the right fix? It implies that
somewhere downstream someone depends on the value of |true| being identical to
1. That seems like the true error to me. (Heh heh.)

Comment 9

[Brendan Eich [:brendan]]

Comment on attachment 163363 [details] [diff] [review]
Also stop window.dispatchEvent() from always throwing exceptions

sr/a=me, go fast!

/be

Comment 10

[Brendan Eich [:brendan]]

Re: comment 8, danm, consider yourself smacked ;-).  Storing an arbitrary
non-zero truth value in a PRBool is a bug waiting to bite.  While XPConnect
copes, any code that packs into a PRPackedBool may suffer from the folly of the
person who failed to test == 0 or != 0, or use !!, or (blecherous) use (field &
mask) ? PR_TRUE : PR_FALSE.

Followups to bug 266048.

/be

Comment 11

[Boris Zbarsky [:bzbarsky]]

So.. what effect does this patch have on window.close() calls on windows that
were forced into a tab?  I seem to recall danm fixing that recently, but with
this patch in that codepath will dispatch an event, but the event will be
untrusted and the tab won't close, no?

Should a separate bug be filed on the second issue mentioned in comment 0, by
the way?

Comment 12

[Johnny Stenback (:jst)]

(In reply to comment #11)
> So.. what effect does this patch have on window.close() calls on windows that
> were forced into a tab?  I seem to recall danm fixing that recently, but with
> this patch in that codepath will dispatch an event, but the event will be
> untrusted and the tab won't close, no?
> 
> Should a separate bug be filed on the second issue mentioned in comment 0, by
> the way?

Yeah, that was bad in this patch, fixed as part of 265790.

Marking bug fixed.

Comment 13

[Boris Zbarsky [:bzbarsky]]

So should a separate bug be filed on the second issue mentioned in comment 0?  I
don't think these patches fix it...

Comment 14

[Johnny Stenback (:jst)]

Ah, yes, please do file a separate bug on that...

Comment 15

[Boris Zbarsky [:bzbarsky]]

Bug 266371 filed.

Comment 16

[sairuh (rarely reading bugmail)]

tracy and I had verifyied this back at the end of october with firefox branch
bits on all the three main platforms.

Comment 17

[Frederic Crozat]

Hmm, this bug still have security sensitive bug even if it has been fixed for
some time now..

Comment 18

[Frederic Crozat]

Ok, because of bug 266371, it might be better to keep this bug security
sensitive until 266371 is fixed.