Open
Bug 235450
Opened 21 years ago
Updated 17 years ago
blocked popup window can't be opened from menu
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
NEW
People
(Reporter: danm.moz, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: fixed-aviary1.0)
Attachments
(1 file)
|
1.64 KB,
patch
|
bugzilla
:
review+
asa
:
approval-aviary+
|
Details | Diff | Splinter Review |
jasonb found an example of a website with tricky javascript that creates popup
windows which evade the new "open a popup window after the fact" feature (bug
198846). There are several bugs here, I'm filing them separately. This one is
about script that runs basically like this:
<head><script>
function openWindow(someURL) {
var newWin = window.open("", "cool", "width=720,height=300");
newWin.location = someURL;
}
</script></head>
<body onload="openWindow(<someURL>)">
this page attempts to open windows in the load handler
</body>
Mozilla of course fails to capture the actual URL of the popup window. So the
menu enticing the user to open the window promises something it can't do.
There's a whole class of popups like this that we won't be able to open
properly. We probably won't be able to identify them all. I think we can make
this case better, though.
I suggest detecting blocked popups whose URL is equal to either the requesting
page's URL or to its base URL, and giving them some special treatment. Just
leave them out of the list. Or if that's confusing (since the "blocked popup"
icon will be visible), some sort of indicator that we can't actually open that
blocked popup.
|
||
Updated•21 years ago
|
Add about:blank to my above list of detectable problem URLs.
http://www.chicagosuntimes.com/index/ebert.html has a popup window like that in
the opening comment, except it's opened initially to about:blank, rather than a
0-length string.
|
||
Updated•20 years ago
|
Flags: blocking-aviary1.0?
|
||
Comment 2•20 years ago
|
||
Is the cnn.com popup mentioned in bug 176564, comment #26 one of those? Or is
that another problem?
|
||
Comment 3•20 years ago
|
||
mvl and danm, think we can address this in the next few weeks?
This patch addresses the issue by simply not offering to open windows for which
a useful URL was not supplied in the window.open command, as outlined in
comment 0. I think it's all we can do, practically speaking.
Attachment #160943 -
Flags: review?(firefox)
|
||
Updated•20 years ago
|
Attachment #160943 -
Flags: review?(firefox) → review+
Attachment #160943 -
Flags: approval-aviary?
|
||
Comment 5•20 years ago
|
||
Comment on attachment 160943 [details] [diff] [review]
omit unopenable items from popup menu (Aviary)
a=asa for aviary checkin.
Attachment #160943 -
Flags: approval-aviary? → approval-aviary+
Flags: blocking-aviary1.0?
Keywords: fixed-aviary1.0
Whiteboard: trunk prerequisite: bug 250716 → trunk req: 250716
|
||
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
|
||
Comment 6•20 years ago
|
||
So, what is there left to do here?
1) Hold out for a better algorithm that saves whatever URL wanders in
later from JavaScript, rather than pruning the list. (As we all know,
that'd be nice, though it's highly impractical.)
2) Port the patch to Seamonkey
3) Close the bug
Owner's choice ;)
|
|
||
Comment 8•20 years ago
|
||
i'll leave it to the component owner to decide if they want this.
Assignee: mvl → guifeatures
|
||
Comment 9•20 years ago
|
||
How about not showing the separator in the end of the menu when the show option
is not visible?
|
||
Comment 11•17 years ago
|
||
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
You need to log in
before you can comment on or make changes to this bug.
Description
•