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)

enhancement

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-want)

Attachments

(1 file, 1 obsolete file)

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.
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)
Blocks: eviltraps
Attached file resize_move.html
(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
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.
Jesse, should we mark this as resolved? Or do you actually want to remove the pref?
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.
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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3
Attachment #9385001 - Attachment is obsolete: true
Keywords: sec-want
See Also: → 565541
Summary: Allow scripted resizing when window.close and window.open are allowed → Allow scripted resizing when window.close and window.open are allowed (consume user activation to prevent repeated abuse)
Duplicate of this bug: 1880566
Duplicate of this bug: 186708
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: