Closed Bug 295093 Opened 19 years ago Closed 19 years ago

Showing a blocked popup allows window.open feature titlebar=no

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: jruderman, Assigned: jst)

Details

(5 keywords)

Attachments

(2 files, 1 obsolete file)

Steps to reproduce:
1. Open testcase
2. Click pop-up blocked icon in the status bar.
3. Select "Show..."

Result: Get a large window with no titlebar that overlaps the taskbar

Expected: Get a normal pop-up window, as if I had clicked the button in the
testcase.
Attached file testcase
Demostrates the problem in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050521 Firefox/1.0+
I thought I saw a (fixed?) bug about this before, but I can't find it.
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
Assignee: nobody → dveditz
Also a problem in 1.0.4

The closest seemed to be bug 235457. Probably not relevant are bug 244766 / bug
244965.

We recently (1.0.3) fixed bug 289204, about the popup *content* getting chrome
privs, not restrictions on the opening code. I wouldn't have thought that was
relevant, except that's when this regressed: 1.0.2 is correct, 1.0.3 and later
respect the titlebar=no :-(
Flags: blocking1.8b3+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.5+
Keywords: regression
Whiteboard: [sg:fix]
looks like we need to tackle this in b3
Flags: blocking1.8b2? → blocking1.8b2-
Whiteboard: [sg:fix] → [sg:fix] -need patch
jst: any idea what in your bug 289204 fix might have done to cause this?
Assignee: dveditz → jst
The code that was added to push the JS context of the callee onto the context
stack to prevent javascript: URLs the opened window from getting chrome privs
(intially added in bug 289204, moved to nsWindowWatcher in bug 296850) did the
right thing, but did it a bit too early. This makes us call
CalculateChromeFlags() *before* pushing the callee context onto the context
stack to prevent CalculateChromeFlags() from thinking we're *not* called from
chrome...
Attachment #186413 - Flags: superreview?(brendan)
Attachment #186413 - Flags: review?(dveditz)
Comment on attachment 186413 [details] [diff] [review]
Call CalculateChromeFlags() before we push the callee's JS context onto the context stack.

Oops, wrong diff.
Attachment #186413 - Attachment is obsolete: true
Attachment #186413 - Flags: superreview?(brendan)
Attachment #186413 - Flags: review?(dveditz)
Right diff.
Attachment #186414 - Flags: superreview?(brendan)
Attachment #186414 - Flags: review?(dveditz)
Whiteboard: [sg:fix] -need patch → [sg:fix] -has patch
Comment on attachment 186414 [details] [diff] [review]
Call CalculateChromeFlags() before we push the callee's JS context onto the context stack.

r=dveditz
a=dveditz for trunk and branch
Attachment #186414 - Flags: review?(dveditz)
Attachment #186414 - Flags: review+
Attachment #186414 - Flags: approval-aviary1.1a2+
Attachment #186414 - Flags: approval-aviary1.0.5+
Moving this bug to core since it's an embedding code bug, not Firefox specific.
Component: Security → Embedding: APIs
Flags: review+
Product: Firefox → Core
Target Milestone: --- → mozilla1.8beta3
Version: unspecified → Trunk
Flags: blocking1.7.9+
Attachment #186414 - Flags: review+
Attachment #186414 - Flags: approval1.8b3+
Attachment #186414 - Flags: approval1.7.9+
Whiteboard: [sg:fix] -has patch → [sg:fix] need landing
brendan:  All we need is an sr= from you and we can get this checked in.
Comment on attachment 186414 [details] [diff] [review]
Call CalculateChromeFlags() before we push the callee's JS context onto the context stack.

sr=me, but comment why it needs to be early.  Thanks,

/be
Attachment #186414 - Flags: superreview?(brendan) → superreview+
Fix checked in on trunk and branches.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
v.fixed on aviary with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9)
Gecko/20050622 Firefox/1.0.5
Adding distributors
FF1.0.5 advisories published
Group: security
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
Keywords: csec-spoof, sec-low
Whiteboard: [sg:fix] need landing
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: