Last Comment Bug 289204 - Showing a blocked popup has chrome privs
: Showing a blocked popup has chrome privs
Status: RESOLVED FIXED
[sg:fix]
: fixed-aviary1.0.3, fixed1.7.7
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
: Hixie (not reading bugmail)
: Andrew Overholt [:overholt]
Mentors:
Depends on: sa15601
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-05 15:16 PDT by Doron Rosenberg (IBM)
Modified: 2007-04-01 14:38 PDT (History)
1 user (show)
bob: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (150 bytes, text/html)
2005-04-05 15:18 PDT, Doron Rosenberg (IBM)
no flags Details
Push the callee's cx onto the context stack if contentwindow.open() is called from chrome. (2.75 KB, patch)
2005-04-06 01:31 PDT, Johnny Stenback (:jst, jst@mozilla.com)
jst: review+
jst: superreview+
dbaron: approval‑aviary1.0.3+
dbaron: approval1.7.7+
shaver: approval1.8b2+
Details | Diff | Splinter Review
1.7 version of the above diff. (2.92 KB, patch)
2005-04-06 17:36 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Splinter Review

Description Doron Rosenberg (IBM) 2005-04-05 15:16:37 PDT
window.open("javascript:alert(Components.stack)"); is the testcase :)
Comment 1 Doron Rosenberg (IBM) 2005-04-05 15:18:37 PDT
Created attachment 179767 [details]
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] 2005-04-05 15:19:50 PDT
I'm positive we had and fixed this bug at one point :-(
Comment 3 Doron Rosenberg (IBM) 2005-04-05 16:11:43 PDT
So should we start considering doing a security smoketest for releases?
Comment 4 Hixie (not reading bugmail) 2005-04-05 18:05:39 PDT
"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, jst@mozilla.com) 2005-04-06 01:25:38 PDT
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, jst@mozilla.com) 2005-04-06 01:31:06 PDT
Created attachment 179829 [details] [diff] [review]
Push the callee's cx onto the context stack if contentwindow.open() is called from chrome.
Comment 7 Johnny Stenback (:jst, jst@mozilla.com) 2005-04-06 01:31:46 PDT
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] 2005-04-06 02:03:38 PDT
(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) 2005-04-06 08:36:31 PDT
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, jst@mozilla.com) 2005-04-06 17:36:39 PDT
Created attachment 179901 [details] [diff] [review]
1.7 version of the above diff.
Comment 11 Daniel Veditz [:dveditz] 2005-04-15 19:52:37 PDT
Fix released
Comment 12 Mike Connor [:mconnor] 2005-04-21 11:46:39 PDT
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) 2005-04-21 13:02:40 PDT
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] 2005-04-21 13:04:03 PDT
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] 2005-04-21 14:24:58 PDT
Fixed on trunk.
Comment 16 Tim Miao 2005-04-25 20:16:18 PDT
(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.

Comment 17 Doron Rosenberg (IBM) 2005-04-26 08:43:17 PDT
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".

Note You need to log in before you can comment on or make changes to this bug.