Closed
Bug 186708
Opened 22 years ago
Closed 5 months ago
don't allow web sites to resize windows with toolbars (by default)
Categories
(Core :: DOM: Core & HTML, enhancement, P4)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
DUPLICATE
of bug 502561
People
(Reporter: jruderman, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: sec-want, Whiteboard: [sg:want P3])
Unchecking "Allow scripts to move or resize existing windows" breaks some sites,
while leaving it checked makes many sites do nasty things to my browser window.
To solve this problem, Mozilla should disallow scripts from resizing "normal
browser windows" while allowing them to resize most script-opened windows.
One way to distinguish a "normal browser window" from a window owned by a web
page is to check whether the window has toolbars. A window.open()ed window is
likely to be used as a normal browser window only if it has toolbars.
Fixing this bug would turn "Allow scripts to move or resize existing windows"
into two prefs:
[ ] Allow scripts to move or resize normal windows
[x] Allow scripts to move or resize pop-up windows that don't have toolbars
The first pref should be unchecked by default and could be hidden.
Related bugs:
bug 60323 Don't allow JS in Web pages to resize my browser window, by default
bug 144069 javascript window resize shouldn't work when more than one tab
bug 111545 script that tries to "almost maximize" an already-maximized window
unmaximizes it
bug 177838 ignore resizable=no
I have never seen a page be broken because it couldn't resize my window. Can
you give an example? Unless you can show me one, I'd say Won't Fix.
Also, there are preferences for ignoring the window.open()'s settings for
toolbars. How do you anticipate this from reacting with that?
Comment 2•22 years ago
|
||
I have never experienced a broken page because of JavaScript resizing. I agree
it's highly annoying to open a link *in the same window* (possibly in a new
tab), and notice my browser gets resized. Most of the time it doesn't even GAIN
any pixels at all -- and sometimes even quite the contrary. Maybe change the
pref (as in comment #1) from "Allow scripts to resize windows" to "Allow scripts
to resize non-popup windows" would be the best way. I don't really think it is
necessary to keep the "resize normal windows" pref, since that doesn't make much
sense. (You might get a few disgruntled "web developers", though.)
Comment 3•21 years ago
|
||
Options > Advanced > Scripts & Plugins
firebird 0.7 does not have this option.. anyone know why? if not i will log
enhancement request on firebird project.
So we should have "Allow scripts to Move or Resize Existing Windows" unchecked
by default.
user_pref("dom.disable_window_move_resize", true);
That's bug 60323 which was WONTFIX'd already.
There would need to be a new backend pref for
dom.disable_window_move_resize_chromeless
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Reporter | ||
Updated•19 years ago
|
Assignee: samir_bugzilla → general
Component: XP Apps → DOM: Level 0
Product: Mozilla Application Suite → Core
QA Contact: pawyskoczka → ian
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.8.1?
Reporter | ||
Comment 6•19 years ago
|
||
See also bug 331408, "JavaScript window resize should not affect default window size".
Comment 7•19 years ago
|
||
Wouldn't block for this, but might well take a patch.
Flags: blocking1.8.1? → blocking1.8.1-
Updated•17 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Reporter | ||
Comment 8•17 years ago
|
||
Major malicious sites such as drivecleaner.com take advantage of this bug to make their fake-dialog advertisements more believable. In bug 402401, there's even some speculation of malicious sites resizing the browser window and covering it with what looks like a crash dialog, in the hope that victims will follow links in the fake crash dialog for a "solution".
Flags: blocking1.9?
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [sg:want P3]
Comment 9•17 years ago
|
||
Not a blocker, but wanted.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Reporter | ||
Comment 10•17 years ago
|
||
Re-nominating: jX has verified that this is being exploited in the wild, with sites hiding the shrunken window using an alert. See bug 402401 comment 16.
Flags: blocking1.9- → blocking1.9?
Comment 11•17 years ago
|
||
I guess I don't see how fixing this would really help with the situation mentioned in that bug. The evil site could simply open the window w/o toolbars and achieve the same thing couldn't it?
Reporter | ||
Comment 12•17 years ago
|
||
This would prevent sites from hiding "normal" browser windows in order to make it look like Firefox has crashed. Users usually have one of those, even if they're using some site-opened windows as well.
Comment 13•17 years ago
|
||
+'ing and setting to P3.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9+
Priority: -- → P3
Assignee: nobody → jst
Priority: P3 → P4
Blocks: 329385
Comment 14•17 years ago
|
||
Moving to wanted - we've had no motion and this doesn't look like it will get finished in time. Bigger fish to fry
Flags: wanted1.9+
Flags: blocking1.9-
Flags: blocking1.9+
Reporter | ||
Comment 15•17 years ago
|
||
Looks like this idea will be dropped in favor of bug 412862, "Change the 'allow scripts to raise or lower windows' pref to a whitelist". The idea in this bug might break fewer sites, but bug 412862 does a better job of fixing the security issues (especially bug 329385) and annoyances such as moving-target popups.
I don't know whether that will make this bug "wontfix", "fixed", or something else.
Reporter | ||
Comment 16•17 years ago
|
||
Scratch that. Bug 412862 was backed out due to web-compatibility concerns involving legitimate popup windows that, for various reasons, resize themselves.
Comment 17•17 years ago
|
||
quote: One way to distinguish a "normal browser window" from a window owned by a web page is to check whether the window has toolbars.
----
what about checking to see if the browser has tabs???
If you only have one window/site open perhaps you should trust the web designer's choice of what size the window should be? There are legitimate reasons for wanting a window to be a particular size. For instance, a lot of people these days are buying these ultrawide aspect ratio screens. It is tremendously difficult to design a site that will look good at any aspect ratio.
I agree that when you have multiple tabs open it is a big pain that sites should arbitrarily resize your browser. But it is actually pretty rare that they do this. And the vast vast majority of sites are designed for 800x600 or 1024x768 screens.
These new laptops with their oddball screen sizes have really made life difficult for web designers. This is especially true because it is so difficult to resize a picture as a function of the browsers size. I know of no way to do this without resorting to javascript. Basically you end up having to create a totally different page layout for an ultrawide screen because the space is so different, it is not as simple as just making the border a little bit bigger. It is much simpler to resize the browser window to something sane.
What about using the same strategy that you currently use for pop-ups, in that resizing is blocked by default and a warning msg is put up with the ability to grant permanent permission to a *.domain to allow resizing?
What about looking at the values being requested and if they are reasonable values, and no other tabs are open, allow them without interference?
as far as the exploits go.... for anybody who is paying attention the title bar will give them away as not being what they claim to be. Also, NoScript is a wonderous thing.
Comment 18•16 years ago
|
||
(In reply to comment #17)
> what about checking to see if the browser has tabs???
That's an alternate approach in bug 144069
Reporter | ||
Comment 22•15 years ago
|
||
I have a more precise proposal in bug 502561.
Comment 23•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: jstenback+bmo → nobody
Updated•2 years ago
|
Severity: normal → S3
Updated•5 months ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•