Created attachment 562140 [details]
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.
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
Created attachment 562142 [details]
This was initially reported in mozilla.dev.apps.seamonkey:
The OP has indicated he is trying the following bookmark:
The "Firefox 6 for developers" article on DevMo mentions <https://developer.mozilla.org/en/Firefox_6_for_developers>:
> the security context of the current page when the user enters them in
> the location bar; instead, a new, empty, security context is created.
> 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,
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:
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:
(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. 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.
Above tested on Windows XP
- Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110923 Firefox/7.0 SeaMonkey/2.4
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.
xref bug 565541
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'!
As I state there, "bug" 565541 is a false assertion for two reasons:
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.
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:
* 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.
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."
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.
Created attachment 577938 [details]
Simple html file with embedded JS that attempts to move and resize window.
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.
Please j.j. do not repeatedly state that this bug is invalid. It is a valid bug.
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.
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!
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.
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:
*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.
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.
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.
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.
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.