All users were logged out of Bugzilla on October 13th, 2018

Embedding needs flag to distinguish popup windows (unrequested windows) from regular windows

VERIFIED FIXED in mozilla1.0.1

Status

()

--
blocker
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: moconnell, Assigned: ccarlen)

Tracking

({topembed+})

Trunk
mozilla1.0.1
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
Need a chrome flag to determine if a window being created in CreateChromeWindow in 
CWindowCreator is for an unrequested window.

The purpose of distinguishing is two fold. First, does the window need to be built using 
an embedding application native window (this window has controls on it for features 
dealing with history, bookmarking, etc). Second, should the window be excluded from the 
embedding applications URL history.

Other embedding applications (Chimera) accomplished a similar task by exposing a new 
API in nsPIDomWindow.h. But this probably isn't the preferred solution.

Updated

16 years ago
Blocks: 150046
(Assignee)

Comment 1

16 years ago
Chimera uses the code feature added from bug 136985 to determine whether a
window is an unrequested pop-up. I want something so that we dont have to expose
something like nsIPIDomWindow in order for embeddors to know this. While the
chrome flags passed to CreateChromeWindow describe *what* sort of window to
create, that isn't enough. The embeddor needs to know the context of the window
being opened (as part of a load or timeout task) I would rather we have a way of
explicitly telling the impl of nsIWindowCreator that it's making an unrequested
pop-up. What I have in mind in this:

Have window watcher use nsIPIDOMWindow to determine whether the window it's
asking to be created thru nsIWindowCreator is an unrequested pop-up.
If so,
(1) add this as a bit in the chrome flags it passes to
nsIWindowCreator::CreateChromeWindow(). The problem here is that the flags are
defined in nsIWebBrowserChrome which is frozen. Adding new bits, as long as the
meaning of other bits is arguably OK.
(2) If window watcher determines that the window it's asking to be created is an
unrequested popup, it QI's the impl of nsIWindowCreator to a new iface
(nsIWindowCreator2) and calls its method CreateVilePopupWindow(), which most
embedding apps will want to consult a pref and refuse to create it. If the QI
fails, it just calls nsIWindowCreator::CreateChromeWindow and the embedding app
unknowingly creates the vile popup.

Opinions on how to deal with this?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Updated

16 years ago
Keywords: topembed+
(Assignee)

Comment 2

16 years ago
Created attachment 93575 [details] [diff] [review]
patch

Patch which creates nsIWindowCreator2
(Assignee)

Comment 3

16 years ago
Created attachment 93577 [details]
Changes to PPEmbed resources to pop the alert dialog (.rsrc.sit file)
(Assignee)

Comment 5

16 years ago
Changing summary and component because this is true for all platforms.
Component: Embedding: Mac → Embedding: APIs
OS: MacOS X → All
Hardware: Macintosh → All
Summary: Mac embedding needs flag to distinguish popup windows (unrequested windows) from regular windows → Embedding needs flag to distinguish popup windows (unrequested windows) from regular windows
Could we see this change attached as text file(s) here please?
jst, uh, no, because the resource changes are binary.
Oh, duh, I thought that was the patch <mehidesincornerfeelingstupid/>
Comment on attachment 93575 [details] [diff] [review]
patch

sr=jst
Attachment #93575 - Flags: superreview+
(Assignee)

Comment 10

16 years ago
Thanks, guys, for quick reviews :-)
Comment on attachment 93575 [details] [diff] [review]
patch

Approved for trunk AND branch.	Change mozilla1.0.1+ to fixed1.0.1 when fixed
on branch.
Attachment #93575 - Flags: approval+

Updated

16 years ago
Keywords: mozilla1.0.1+
Target Milestone: --- → mozilla1.0.1
(Assignee)

Comment 12

16 years ago
Checked into branch.
Keywords: mozilla1.0.1+ → fixed1.0.1
(Assignee)

Comment 13

16 years ago
Checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 14

16 years ago
mdunn: pls verify this as fixed on the 1.0 branch, then replace the "fixed1.0.1"
keyword, with "verified1.0.1". thanks!

Comment 15

16 years ago
To ashish for bug verification
QA Contact: mdunn → ashishbhatt

Comment 16

16 years ago
marking as verified
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.1 → verified1.0.1

Updated

16 years ago
No longer blocks: 150046
You need to log in before you can comment on or make changes to this bug.