Open
Bug 502561
Opened 15 years ago
Updated 7 months ago
Allow scripted resizing when window.close and window.open are allowed (consume user activation to prevent repeated abuse)
Categories
(Core :: DOM: Core & HTML, enhancement, P5)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: jruderman, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: sec-want)
Attachments
(1 file, 1 obsolete file)
617 bytes,
text/html
|
Details |
Split out from bug 454779 comment 6. I propose replacing the annoyance pref "Allow scripts to: Move or resize existing windows" with a heuristic that stops all annoying uses without breaking too many sites.
I think we should:
* Never allow sites to resize windows that are owned by the user (bug 144069,
bug 186708). (This is always malicious and/or annoying.)
* Always allow sites to resize pop-up windows at times when they are allowed to
both close the pop-up window and open a new one. (Disallowing it is pointless
in this case!)
Since resizing pop-ups would be allowed in response to clicks, legitimate uses
would not be broken. For example:
* You click a thumbnail and get a "full-size image" pop-up. You click another
thumbnail and the pop-up is reused for another image, which might be a
different size.
* http://www.myfreecams.com/ (NSFW) resizes "private message" pop-ups when you
click the "show video" link.
The only widespread brokenness would be from sites that open image/video
pop-ups before they know what size they should be, and then resize the windows
onload. I'm fine with breaking that, since:
(1) Forcing those sites to determine window sizes ahead of time would improve
the sites for users of all browsers.
(2) Such behavior is difficult to distinguish from malicious or unwanted
behavior.
(3) The brokenness isn't too bad, since users can resize the windows themselves
thanks to the fix for bug 177838.
(4) Users can work around the brokenness by adding sites to the pop-up blocker
whitelist (if not a more specific whitelist, see bug 412862).
(5) If we keep the pref, users can work around the brokenness by flipping the
pref, without having to worry about letting malicious sites resize non-pop-up
windows.
Comment 3•14 years ago
|
||
Move option should be unchecked by default as it is in Opera and
Chrome. I don't know whether there is an option or not in Opera and Chrome but
they do not move the window. Check this site www.nobrain.dk (NSFW)
(In reply to comment #0)
> Since resizing pop-ups would be allowed in response to clicks, legitimate uses
> would not be broken. For example:
Make sure maximum of only 1 resize and 1 move is allowed
after 1 user click event.
(also if there is dbl-click or triple-click to should be considered on action)
remember now site can open multiple window in on click Bug 550238
otherwise you end up situation in resize_move.html
Reporter | ||
Comment 5•14 years ago
|
||
I suppose I should add "... and there aren't any other tabs open in the window" to the heuristic, since window.close followed by window.open doesn't do quite the same thing when there are multiple tabs open.
Comment 6•13 years ago
|
||
Jesse, should we mark this as resolved? Or do you actually want to remove the pref?
Reporter | ||
Comment 7•13 years ago
|
||
If I understand correctly, the patch in bug 565541 added constraints based on the nature of the window being resized (opened with script and only one tab), but not based on the triggering event.
I think we should still do the latter, in order to stop hide-and-seek traps.
Comment 8•13 years ago
|
||
The behavior described in comment 0 sounds perfect to me: sites granted permission to bypass the popup blocker could resize windows freely, and sites could otherwise move/resize a window *once* in response to clicking a link. This seems like exactly the right behavior to have by default, and the pref controlling resize could then go away.
Updated•6 years ago
|
Priority: -- → P5
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
Updated•9 months ago
|
Attachment #9385001 -
Attachment is obsolete: true
Updated•7 months ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•