Javascript 'move and resize existing windows' should be OFF by default

Bug #249656 reported by Ace Suares
4
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
High
firefox-3.0 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

While surfing, I hit a website that suddenly maximized my FF window.

This felt very odd.

I discussed this with someone, and I was told to go to Edit-> Preferences-> Content-> Javascript/Advanced and disable the 'Move and resize existing windows'.

After I did that, the site did not maximize my FF window anymore.

I suggest that this option be turned OFF by default (just like all the other options in that dialog are turned off by default).

Revision history for this message
In , John-p-baker (john-p-baker) wrote :

Created an attachment (id=83324)
test case

In a clean profile (or one that allows javascript to resize windows),
open this attachment in a new tab.
Go to a different tab and try to resize window.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Confirming for investigation.

Revision history for this message
In , nodata (ubuntu-nodata) wrote :

Same problem for me - also, the window position is saved :/

Revision history for this message
In , Asapuntz (asapuntz) wrote :

Don't know much about JavaScript, but I'm guessing that's what's happening at
the following link:

http://www.samsung.com/Features/TechnologyLeadership/Exhibition/cebit2003/

Revision history for this message
In , Security-bugs (security-bugs) wrote :

Reassigning to me. I'm not sure if we need this restriction or not; I will try
to get more opinions.

Revision history for this message
In , Jaroslav-zaruba (jaroslav-zaruba) wrote :

I think there could be done some modification in Edit -> Preferences -> Advanced
-> Scripts & Plug-ins -> Allow scripts to. The checkboxes (some of them) should
have three states: unchecked for disabling the feature completely,
"semi-checked" (checked box with gray bg or whatever) for allowing the feature
only for windows opened with JavaScript (window.open()), and checked for
allowing the feature completely.
We hate when sites resize the browser window on their start page. On the other
hand this feature is great when viewing some gallery - clicking a thumbnail
usually opens a window using window.open() method, and such windows should be
resizable by JavaScript (as they usualy resize to fit the image they show).

This would also solve the JS-resizing of the tabbed windows, because JS-windows
don't open in a tab.

Revision history for this message
In , nodata (ubuntu-nodata) wrote :

It's not fair that a single tabbed website can take control over the entire
application.

We're up to Firefox 0.9 now, and this is still broken :/

I've voted :)

Revision history for this message
In , Ddw (ddw) wrote :

Suggestion: when more than one tab is opened, window resizing should be disabled
in all cases, regardless of the user's setting in Script settings.

Revision history for this message
In , Ddw (ddw) wrote :

(In reply to comment #8)
> Suggestion: when more than one tab is opened, window resizing should be disabled
> in all cases, regardless of the user's setting in Script settings.
more exactly: when the page to be opened is opened in a new tab, ant there is at
least one other tab already open.

Revision history for this message
In , nodata (ubuntu-nodata) wrote :

This is not broken in Epiphany.
But still broken in Mozilla and Firefox..

Revision history for this message
In , Jruderman (jruderman) wrote :

*** Bug 246914 has been marked as a duplicate of this bug. ***

Revision history for this message
In , pmow (pmow) wrote :

I have no experience in these matters but could the solution to this bug not be
very similar to the solution in bug 103452. At the moment resize events are
followed in nsGlobalWindow::HandleDOMEvent:

1194 if (aEvent->message == NS_RESIZE_EVENT) {
1195 mIsHandlingResizeEvent = PR_TRUE;
1196 }

right? If one tries to DispatchCustomEvent("DOMWindowResize") there and then
counts the number of tabs the way it was done in tabbrowser.xml in attachment
86328 before returning. Could that work or don't I have to waste my time trying
that?

Revision history for this message
In , Jruderman (jruderman) wrote :

I think any toolbar, not just the tab bar, should be sufficient reason to consider a window user-controlled and not let a web site resize it. See bug 186708.

Revision history for this message
In , Bmo-2 (bmo-2) wrote :

*** Bug 332630 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

*** Bug 339648 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Philringnalda (philringnalda) wrote :

*** Bug 347579 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ajvincent (ajvincent) wrote :

What will you do for the case of the user typing in javascript:window.resizeTo(800,600)?

This is a case where the user clearly knows what they are doing. Disable that, and you break a DOM Level 0 feature completely.

I understand the concern about pages resizing tabbed windows without the user's permission. But don't stop the user from doing the same himself.

(I note that Firefox 1.5.0.6 has re-enabled window.resizeTo() for bug 309251, and SeaMonkey 1.0.4 has it disabled thanks to bug 317819.)

Revision history for this message
In , Brendan-webafrica (brendan-webafrica) wrote :

(In reply to comment #17)
> What will you do for the case of the user typing in
> javascript:window.resizeTo(800,600)?
>
Expanding the advanced options in a similar way to the image download exceptions (Tools > Options > Content > "Images"..... [Exceptions]) would go very far to squash this bug.
Myself, I'm getting particularly annoyed by this bug since it resizes my window even if it full-screen. I have about 30 tabs open at all times and my Firefox window is always, yet http://www.saeverything.co.za/, resizes my window.

Revision history for this message
In , Kilowatt (kilowatt) wrote :

Previous post led me to another question - what's the point of changing window size for the page? resizeTo() changes size of whole window, not the client area available to the page. Moreover, if there are toolbars, main menu, tab bar, etc. in that window, page would not get the requested client area.

Revision history for this message
In , Kevin Brosnan (kbrosnan) wrote :

*** Bug 393386 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 439177 has been marked as a duplicate of this bug. ***

Revision history for this message
Ace Suares (acesuares) wrote :

While surfing, I hit a website that suddenly maximized my FF window.

This felt very odd.

I discussed this with someone, and I was told to go to Edit-> Preferences-> Content-> Javascript/Advanced and disable the 'Move and resize existing windows'.

After I did that, the site did not maximize my FF window anymore.

I suggest that this option be turned OFF by default (just like all the other options in that dialog are turned off by default).

Revision history for this message
Kevin Brosnan (kbrosnan) wrote :

Mozilla tried a whitelist for sites to be allowed to move or resize windows however this was found to break a significant portions of websites see https://bugzilla.mozilla.org/show_bug.cgi?id=412862. the closest open request I can find is https://bugzilla.mozilla.org/show_bug.cgi?id=144069 to disable move/resize for windows with tabs.

Changed in firefox:
status: Unknown → Confirmed
Changed in firefox-3.0 (Ubuntu):
status: New → Confirmed
Revision history for this message
In , longsonr (longsonr) wrote :

*** Bug 569304 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ilhan (ilhan) wrote :

Still not solved since 2002. Sites like (don't visit) http://www.nobrain.dk/ are annoying. You cannot catch the window.

Changed in firefox:
importance: Unknown → High
Revision history for this message
In , Jruderman (jruderman) wrote :

This was fixed for Firefox as part of the patches in bug 565541.

Did that fix it for SeaMonkey too?

Revision history for this message
In , Philip-chee (philip-chee) wrote :

> This was fixed for Firefox as part of the patches in bug 565541.
> Did that fix it for SeaMonkey too?
Appears to have done so.
WFM:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110604 Firefox/7.0a1 SeaMonkey/2.2a1pre

*** This bug has been marked as a duplicate of bug 565541 ***

Changed in firefox:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.