Closed Bug 688841 Opened 13 years ago Closed 12 years ago

window.resizeTo and window.moveTo don't work

Categories

(SeaMonkey :: General, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: stanio, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

Attached file Sample Test (obsolete) —
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110922 SeaMonkey/2.6a1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110916 SeaMonkey/2.4

1. Set in Edit -> Preferences:

   Advanced / Scripts & Plugins:

   Allow scripts to:
   [x] Move or resize existing windows

2. Open the "Sample Test" attachment and click on any of the "Move" elements.

Actual:

   Nothing happens.

Expected:

   The window should be sized 640x480 and moved to 360:120.

This appears to work fine using:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 SeaMonkey/2.3.3
Attached file Sample Test
Attachment #562140 - Attachment is obsolete: true
This was initially reported in mozilla.dev.apps.seamonkey:

http://groups.google.com/group/mozilla.dev.apps.seamonkey/browse_frm/thread/a6bf460dd94b4385

The OP has indicated he is trying the following bookmark:

javascript:self.resizeTo(1600,1000);self.moveTo(40,10);

The "Firefox 6 for developers" article on DevMo mentions <https://developer.mozilla.org/en/Firefox_6_for_developers>:

>   * For security reasons, data: and javascript: URIs no longer inherit 
> the security context of the current page when the user enters them in 
> the location bar; instead, a new, empty, security context is created. 
> This means that script loaded by entering javascript: URIs in 
> the location bar no longer has access to DOM methods and the like, 
> for example. These URIs continue to work as before when used by script, 
> however.

Given that, it appears it should not have worked from a bookmark in SeaMonkey 2.3, also.

I'll try to narrow the regression range between 2.3 and 2.4, further.
> Given that, it appears it should not have worked from a bookmark in
> SeaMonkey 2.3, also.

Ah, discard that.  I've just tried it works from a bookmark in Firefox 6.  It doesn't work just when pasted directly in the location bar.
Here's another possibly relevant scenario:

1. Create a "move-win" bookmark, placing it conveniently on the personal/bookmark toolbar, with the following location:

   javascript:resizeTo(640,480);moveTo(360,120);

2. Have two tabs opened: one with this URL (for example) and the other one with the <about:config> page;

3. When the current tab is the <about:config> page, the "move-win" bookmark always makes the window move despite the "dom.disable_window_move_resize" value (true or false);

4. When the current tab is other than the <about:config> page, the "move-win" bookmark never makes the window move.
(In reply to Stanimir Stamenkov from comment #2)
> I'll try to narrow the regression range between 2.3 and 2.4, further.

The problem is reproducible with the oldest 2.4 build I've found on the ftp.mozilla.org server:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2011/06/2011-06-07-00-comm-central-trunk/seamonkey-2.4a1.en-US.win32.zip
(In reply to Stanimir Stamenkov from comment #4)

1. Open a website in first tab, e.g. google
2. Open a second tab
3. Enter "about:config" in location bar
4. Enter "dom" in "Filter:" line
5. Maximize window
6. Then toggle the "dom.disable_window_move_resizedom.disable_window_move_resize"
7. It's egal if true or false selected
8. Doesn't change the tab!
9. Now select the bookmark [javascript:self.resizeTo(1600,1000);self.moveTo(40,10);]
9. The window will resized to the desired value.
10. This can be repeated when you go to 5.
11. But when you change the tab, it will no more work.
12. Change the tab back to "about:config" and it will work again.
13 So long as you reside in the "about:config" tab, you can enter "javascript:self.resizeTo(1600,1000);self.moveTo(40,10);" in the location bar, and it will work.

Above tested on Windows XP
- Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110923 Firefox/7.0 SeaMonkey/2.4


Additional infos:

In Firefox 6.0.2 and Windows Vista the bookmark will function, but in the location bar not.
- Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20100101 Firefox/6.0.2

In SeaMonkey 2.3.3 and Windows 7 the bookmark will function, and in the location bar too.
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3

Expected result: The bookmark should function with "[x] Move or resize existing windows"
(In reply to Stanimir Stamenkov from comment #4)

> 4. When the current tab is other than the <about:config> page, the
> "move-win" bookmark never makes the window move.

When the current tab is <about:> or <about:plugins> the bookmark-script will function too.
So given this is now the expected behavior (see xref bug bug 565541), should this one be resolved as invalid?
What are you guys talking about, bookmarks and all? The problem reported here is as clear as the light of day: you have a file attached with the bug, that file is a plain old HTML page that loads in the browser, and it simply shows that resizeTo() and moveTo() NO LONGER WORK IN FIREFOX (which i can confirm, at least for Fx7, cuz that's how i got to this bug in the first place). It's as clear a bug as it gets. Just fix it, or say you's not gonna fix it, or wuteva', but stop trippin'!
gyll@iname.com is right: it is simple. In Firefox 7.0.1 Javascript window move and resize does not work even with full enablement. This may be the result of an unwise change to "fix" a non-defect listed as bug 565541 "Web sites shouldn't be allowed to resize main window" and discussed in support questions on 
https://support.mozilla.com/en-US/questions/880032#answer-253830

As I state there, "bug" 565541 is a false assertion for two reasons: 
1) it is a feature of Javascript that the browser window can be resized and repositioned. 
2) There is no formal definition of "main" window. There can be multiple windows, and a script run in one can open another; that makes "parent" and "child" window relationships but there is no such thing as "main".

My copy, Firefox 7.0.1 which is still the latest according to its "check for updates", has the option to disable resizing or repositioning under Tools | Options | Content | Advanced.
I have set to ENable move and resize, and I have also DISabled at "about:config" the preference called 
dom.disable_window_move_resize --- making that disable _false_ should enable move and resize ... but ti still doesn't work.

The defect is that enabling move or resize in that Advanced Javascript Settings panel fails. If we also have this "about:config" route to settings, and if those are not the same settings as those reached from the panel as above, and the about:config overrides the Advanced Javascript Settings panel, then that is a defect and it must be fixed. It is totally improper for a setting under the control of a normal settings panel in a piece of software to be overridden by a separate hidden setting that does exactly the same thing.

And if move and resize still do not work even with the "about:config" preference set the way that should allow move and resize, that is TWO defects:
* a design defect, that there is an apparently secret "move and resize" disabler in "about:config" for a setting that already has an advanced Javascript settings panel check box
* an implementation defect, that even with BOTH these set to ALLOW move and resize, move and resize still do not happen, as of 7.0.1

Move and rezise worked fine in my last version of Forefox 6 before I was automatically upgraded to 7.0.1 a few days ago.

Now the point I made above about the idea of a "main" window having different properties from a pop-up window. Change "main" to say "parent", referring to the window in which a script ran that opened other windows which we call "child" windows offers some possibilities that might go some way to please the person who raised bug 565541: allow more flags in advanced Javascript settings and (if necessary) names in the "secret" list.

If you want to improve Firefox as regards these powers, rather than just fixing the real biug (which was to fix the non-bug), by all means add to the number of check boxes on the Advanced Javascript Settings panel.

Instead of just "Allow scripts to [] move or resize existing windows [] raise or lower windows etc."
you might wish to have "Allow scripts to [] move or resize the existing window they are running in [] move or resize existing windows that are children of the window they are running in [] move or resize existing all windows other than the window they are running in [] open, move and resize new (popup) windows [] raise or lower windows etc."

However to leave the Advanced Javascript Settings panel with the options it still has but to ignore its settings is totally wrong and it was really unacceptable for Firefox 7.0.1. to have gone out like this, offering clear options and not obeying them when it did before.
I use a relatively simple home.html file with a hardcoded size and position in it to initialize the application's window with Javascript whenever it's started. In previous versions (and still in IE) this has worked fine. However in Firefox 8.0.1 it does not (and without any other obvious error indications).

While working on an unrelated bug, I happened to test the file/script with Aurora 10.0a2 where it worked properly -- which is good news I suppose, but it seems to me like something so fundamental not working should have be caught by in some kind of acceptance or regression test.

I'll attach the home.html file mentioned, perhaps something like it could be used as the basis of some sort of test.

[Note: BTW, I *do* have the option selected in Advanced Javascript settings for scripts to be able to move and resize windows.]
HTML file with embedded javascript to move and resize application windows when it's loaded -- previously successfully used as browser's home or start page.
Blocks: 565541
See also Firefox bug 689974 (closed as invalid)
Cant seem to make resizeTo or moveTo work in Firefox 10 either
(In reply to Vaibhav from comment #15)
> Cant seem to make resizeTo or moveTo work in Firefox 10 either

This bug is about SeaMonkey. The corresponding Firefox bug is bug 689974.

Anyway, this functionality was removed on purpose from Gecko 7 in bug 565541 and is therefore invalid in SeaMonkey as well.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Please j.j. do not repeatedly state that this bug is invalid. It is a valid bug.
I have just checked that my copy is fully up to date (it is, at 10.0.2) and that the "Options" panel still contains the Javascript options involved. The "Options" panel Content tab still has the "Enable Javascript" check box with the "Advanced" button next to it. The "Advanced" button still evokes the "Advanced Javascript Settings" panel, and it still has the "Allows scripts to Move or Resize popup windows" check box.

As long as the Options | Advanced Javascript Settings feature still claims to be able to enable moving or resizing of windows, that nor working is a bug. Resizing of popup windows does not work on the latest version with the ability supposedly enabled.

The removal of the Jvascript language feature of being able to move or reszie the window the page containing the script is running in is to my mind still also wrong: I suggested above one or two new check boxes: to allow move or resize of the window itself (as opposed to its child popup windows) and to allow raise or lower of the same. 
I want to be able to do these things, and I want to eb able to use Firefox as my browser. The aim should be to offer the user as much functionality as possible and then to allow them to switch it off if they prefer not to have it.  Simply to delete these abilities for the window itself because some people don't like it seems totally wrong to me, but that is how Firefox stands today. I am very fed up about this. 

Next, j.j. says this bug (688841) is the same as Firefox bug 689974.
Bug 689974 has been marked by j.j. as closed, invalid, a duplicate of bug 691726. (2011-10-04 07:09:23)
Bug 691726 has been marked by j.j. as closed, invalid, a duplicate of bug 691693. (2011-10-04 07:43:16)
Bug 691693 has been marked by j.j. as closed, invalid, a duplicate of bug 691726. (2011-10-04 07:43:17)

The above forms a trail but the last two form a loop.

Further:
Bug 691693 has also been marked by j.j. as a duplicate of bug 663824. (2011-10-23 19:08:48)
But bug 663824 has been marked by j.j. as closed, invalid, a duplicate of bug 691693. (2011-10-23 19:08:47)

Another loop: somehow bug are being closed off as invalid because they are duplicates --- but each because it is a duplicate of the other. One can be an error; two start to look suspicious!

However 
Bug 691693 has been marked by Robert Longson as a duplicate of bug 691956.
But bug 691956 is marked as a VERIFIED DUPLICATE of bug 691693.

Notice anything?

Is this the normal way to treat duplicates? Mark each as a duplicate of the other and delete/close both on those grounds?
I should, I think, add that I do not intend to direct undue criticism at user j.j. but the way this bugzilla forum system works is still very confusing to me and j.j. is the name on multiple messages about this bug and its supposed duplicates. I just went to the root page bugzilla.mozilla.org looking for links to somewhere where names such "SeaMonkey" are defined. I could not find anywhere to look. Believe it or not, I had no idea what "SeaMonkey" is and, finding no clue on the home page here, I had to go to Wikipedia to find a description. It is still a mystery to me why apparently parallel separate programs are maintained; to me a browser is a browser (up to a point: a fully capable, standard-compliant browser is what I hope to find in an open source project like this). However if SeaMonkey has the same removal of functionality as Firefox, regarding ability of JS to move and resize the window it is running in, my view stands: it's wrong to remove functionality because some people say they don't like it. It should simply be put under another option to DISable it --- though I would not mind if the items are disabled on installation and have to be ENabled by those who want it, rather than the reverse, provided the ability for those of us who want it to have it is there. 

To me, saying "some people don't like this so we are removing it from the product" is like the elf and safety people in Britain who through excessive caution stop people having fun, or the nanny state in Britain and parts of Europe saying we can't have certain other things because they have decided they are not good for us --- or, indeed, certain politically or religiously right wing people in north America doing the same for what they claim is the good of our souls. Software development, especially open source, should surely always aim to make the product of the work as flexible as possible; if a thing is not implemented because it is a lot of extra work and nobody is able to undertake to do it, that is one thing; to remove an ability that a program already had, simply because some people are of the opinion that that feature is not good for the rest of us, is something else; but that is what has evidently happened here.

About my point about the practise of setting circular "this is a duplicate of" links between bug records/numbers, I await comment on whether this helps. In my view, such links should go only one way: all later bugs that turn out to be (either exact or effectively) duplicates of an earlier bug should point to the earliest record describing that bug. Marking the early bug as being a duplicate of later ones does not help though a remark that some other bugs are duplicates f this one might be useful. But the annotation on the earliest bug should never say "this is a duplicate of X"; it should only ever say "bug X is a duplicate of this" if it is to say anything at all. The two are not the same; if they are automatically made to say the same at the moment, I suggest a modification to bugzilla to fix this is in order.

Maybe this should be in a different bug number or some other place about how bugzilla works, and how Mozilla development is conducted, in general; but I don't know where that is and finding where is currently more cumbersome than I can get through. I can't see how to find out where these remarks should be.
Let's try to clarify your (and other people's) confusion:

1.
*This* bug is not about Firefox. This bug is about SeaMonkey as you can see in the "Product" field in the header.
Seamonkey is a different browser, it is not Firefox.
So if you are bothered with a problem in Firefox, this here is not your bug.
Therefore I mentioned the corresponding Firefox bug in comment 15 back in January.

2.
Both browsers, Firefox and SeaMonkey, are based on the same layout engine, called Gecko.
Therefore both browsers have the same problem reported in two different corresponding bugs.

3.
The requested functionality was removed on purpose from the Gecko engine in bug 565541.
Read that bug for the reasons this was done.
You can like this decision or not, it's just a matter of fact.
Because this was removed from Gecko, it's not available for browsers based on Gecko. 

4. 
The "Move or resize popup windows" setting was initially forgotten to remove from Firefox's user interface. This was fixed for Firefox 10 in bug 690648.
If you see it in recent SeaMonkey builds then there is something wrong. Please file Bug against SeaMonkey if that's the case and no bug was filed already.

5.
Something about duplication:
Bugs aren't closed as invalid because they are duplicates. A bug is either INVALID or DUPLICATE or something else. If it's a dup, it can be a dup of a valid or invalid bug. Maybe you misunderstand the "duplicate" resolution, it's probably reverse than you think.
You need to log in before you can comment on or make changes to this bug.