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

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Jesse Ruderman]

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.

Comment 1

[Jesse Ruderman]

Attachment: testcase

Demostrates the problem in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050521 Firefox/1.0+

Comment 2

[Jesse Ruderman]

I thought I saw a (fixed?) bug about this before, but I can't find it.

Comment 3

[Daniel Veditz [: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 :-(

Comment 4

[chris hofmann]

looks like we need to tackle this in b3

Comment 5

[Daniel Veditz [:dveditz]]

jst: any idea what in your bug 289204 fix might have done to cause this?

Comment 6

[Johnny Stenback (:jst)]

Attachment: Call CalculateChromeFlags() before we push the callee's JS context onto the context stack.

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...

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 186413 [details] [diff] [review]
Call CalculateChromeFlags() before we push the callee's JS context onto the context stack.

Oops, wrong diff.

Comment 8

[Johnny Stenback (:jst)]

Attachment: Call CalculateChromeFlags() before we push the callee's JS context onto the context stack.

Right diff.

Comment 9

[Daniel Veditz [:dveditz]]

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

Comment 10

[Johnny Stenback (:jst)]

Moving this bug to core since it's an embedding code bug, not Firefox specific.

Comment 11

[Jay Patel [:jay]]

brendan:  All we need is an sr= from you and we can get this checked in.

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Johnny Stenback (:jst)]

Fix checked in on trunk and branches.

Comment 14

[Jay Patel [:jay]]

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

Comment 15

[Daniel Veditz [:dveditz]]

Adding distributors

Comment 16

[Daniel Veditz [:dveditz]]

FF1.0.5 advisories published