289204 - Showing a blocked popup has chrome privs

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Doron Rosenberg (IBM)]

window.open("javascript:alert(Components.stack)"); is the testcase :)

Comment 1

[Doron Rosenberg (IBM)]

Attachment: testcase

Happens on trunk too, Seamonkey and Firefox.

Steps:
  - popup is blocked
  - Showing it (via infobar or statusbar item) will print Components.Stack, a
nono.

Comment 2

[Daniel Veditz [:dveditz]]

I'm positive we had and fixed this bug at one point :-(

Comment 3

[Doron Rosenberg (IBM)]

So should we start considering doing a security smoketest for releases?

Comment 4

[Hixie (not reading bugmail)]

"start considering"???

You _should_ be doing regression testing of all security fixes. In an automated
fashion, ideally, on every nightly. Preferably as part of the tinderbox tests so
it goes orange when a security thing like this regresses.

Comment 5

[Johnny Stenback (:jst)]

I'm actually not convinced this was fixed. A very similar problem was fixed, but
I think this one simply slipped through the cracks and noone noticed (or at
least told us) until now. Patch coming up.

Comment 6

[Johnny Stenback (:jst)]

Attachment: Push the callee's cx onto the context stack if contentwindow.open() is called from chrome.

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 179829 [details] [diff] [review]
Push the callee's cx onto the context stack if contentwindow.open() is called from chrome.

r+sr=brendan (in person).

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> I'm actually not convinced this was fixed. A very similar problem was fixed,

Yes, I was thinking of bug 235457.

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 179829 [details] [diff] [review]
Push the callee's cx onto the context stack if contentwindow.open() is called from chrome.

>+            stack->Push(cx);

stack->Push(cx) is treated as fallible in many of our other calls.  Seems like
we should
early-out if this fails, since we can be in a world of hurt.  (This world of
hurt,
specifically.)

Comment 10

[Johnny Stenback (:jst)]

Attachment: 1.7 version of the above diff.

Comment 11

[Daniel Veditz [:dveditz]]

Fix released

Comment 12

[Mike Connor [:mconnor]]

Comment on attachment 179829 [details] [diff] [review]
Push the callee's cx onto the context stack if contentwindow.open() is called from chrome.

applies cleanly, requesting a= for trunk checkin

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 179829 [details] [diff] [review]
Push the callee's cx onto the context stack if contentwindow.open() is called from chrome.

a=shaver for the trunk.

Comment 14

[Brendan Eich [:brendan]]

Comment on attachment 179829 [details] [diff] [review]
Push the callee's cx onto the context stack if contentwindow.open() is called from chrome.

a=brendan for 1.8b2.

/be

Comment 15

[Mike Connor [:mconnor]]

Fixed on trunk.

Comment 16

[Tim Miao]

(In reply to comment #1)
> Created an attachment (id=179767) [edit]
> testcase
> 
> Happens on trunk too, Seamonkey and Firefox.
> 
> Steps:
>   - popup is blocked
>   - Showing it (via infobar or statusbar item) will print Components.Stack, a
> nono.
Hi Doron,

Would you please compose a new test case for mozilla? With this case you
provided here I can't reproduce this bug on mozilla/linux while the os of this
bug is set to all. Please send it to [e-mail].
Thanks.

Comment 17

[Doron Rosenberg (IBM)]

In Seamonkey, just go to the testcase, right click on the buttom-right (in the
statusbar) icon for the blocked popup, and choose "Show blabla".