Closed Bug 289204 Opened 16 years ago Closed 16 years ago

Showing a blocked popup has chrome privs

Categories

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

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: doronr, Assigned: jst)

References

Details

(Keywords: fixed-aviary1.0.3, fixed1.7.7, Whiteboard: [sg:fix])

Attachments

(3 files)

window.open("javascript:alert(Components.stack)"); is the testcase :)
Attached file 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.
I'm positive we had and fixed this bug at one point :-(
So should we start considering doing a security smoketest for releases?
"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.
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 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).
Attachment #179829 - Flags: superreview+
Attachment #179829 - Flags: review+
(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 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.)
Attachment #179829 - Flags: approval1.7.7+
Attachment #179829 - Flags: approval-aviary1.0.3+
Keywords: fixed1.7.7
Whiteboard: [sg:fix]
Fix released
Group: security
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
Attachment #179829 - Flags: approval1.8b2?
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.
Attachment #179829 - Flags: approval1.8b2? → approval1.8b2+
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
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(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 tim.miao@sun.com.
Thanks.

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".
Depends on: sa15601
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.