35703 - Mac and Windows MoveTo doesn't work on DOM windows which persist screenX and screenY

Status: RESOLVED DUPLICATE of bug 509828

(Core :: XUL, defect, P3)

Description

[Syd Logan]

pParent->OpenDialog(jsContext, argv, 4, ppNewWindow);
        JS_PopArguments(jsContext, mark);
        if ( *ppNewWindow ) {
                (*ppNewWindow)->MoveTo( staggerx, staggery );
        }

The above code seems to work on Linux only, not Mac or Windows. We use this in
IM to stagger display IM windows. See also

 http://scopus/bugsplat/show_bug.cgi?id=363370

Comment 1

[Johnny Stenback (:jst)]

I think travis was the last person who changed this code, reassigning.

Comment 2

[gerardok]

Build ID, please?  JavaScript window.moveTo() is working on 2000-04-10-09-M15 
build on Win95, and 2000-04-11-09-M15 on Win98. May be it's an NT issue only.

Comment 3

[Syd Logan]

Okay, I discovered something here. The Xul document being loaded has persist 
attributes on the window xul for x and y. When we create new windows based on 
this XUL, after the move, we end up stay at the same position as the previous 
window (this happens maybe after the third new IM window, the first couple 
work fine). I took away the persist stuff in the xul, and we started working 
good again. So, somehow persist is triggering new windows to position themselves 
based on a window with the same document that also has the persist attributes.

This only happens on mac and Windows. Assign to Hyatt. This breaks one of our 
beta 2 features, making P2.

Comment 4

[David Hyatt]

...

Comment 5

[Peter Trudelle]

Could someone explain the severity, or lower it?  There is no "major loss of
function" here that I can see.

Comment 6

[Peter Trudelle]

nominating cuz syd says it prevents a required PR2 feature, but I don't see why 
we couldn't live without the tiling.

Comment 7

[Alex Musil]

Not required for Beta 2.

Comment 8

[Peter Trudelle]

[nsbeta2-]

Comment 9

[Peter Trudelle]

Mass-moving all nsbeta2- bugs to M20

Comment 10

[Peter Trudelle]

nice to have... -> Future

Comment 11

[Syd Logan]

Nominating nsbeta3 because the depends bug is nsbeta3. Moving to nisheeth cause 
I think this is a DOM issue.

Comment 12

[Syd Logan]

	nsCAutoString windowFeatures("chrome,dialog=no");

	argv = JS_PushArguments(jsContext, &mark, "sssW", xul, name ? name : "" 
, 
									(const 
char*)windowFeatures, Args);

	if(!argv)
		return NS_ERROR_FAILURE;

	pParent->OpenDialog(jsContext, argv, 4, ppNewWindow);
	JS_PopArguments(jsContext, mark);
	if ( *ppNewWindow ) {
		(*ppNewWindow)->MoveTo( staggerx, staggery );
		(*ppNewWindow)->SetScreenX( staggerx );
		(*ppNewWindow)->SetScreenY( staggery );
	}

At some point or another, either SetScreen[XY] has worked (it did last Saturday)  
or MoveTo has worked. Now neither works. What is it about these that are so 
unstable? Am I doing the wrong thing here to position to window?

Comment 13

[Nisheeth Ranjan]

Johnny, are you aware of changes that could have broken 
MoveTo()/SetScreenX()/SetScreenY()?

Comment 14

[Johnny Stenback (:jst)]

Nope, no idea, what about danm? Ideas?

Comment 15

[Nisheeth Ranjan]

Marking nsbeta3+

Comment 16

[Nisheeth Ranjan]

Balancing nsbeta3+ bugs within XML/DOM team.  Joki's back from sabbatical and is 
ready to help out.  Here's one for you, dude!

Comment 17

[Nisheeth Ranjan]

At this point in the game, since this only affects cascading of instant 
messaging windows, marking nsbeta3- and futuring.

Based on my conversation with Tom, MoveTo() does work properly from JS within a 
document.

Comment 18

[Thomas]

Does this bug still exists with recent instant messaging windows and more recent
Mozilla versions?

Comment 19

[Florian Quèze [:florian]]

This bug still exists.

If a window uses the persist attribute for screenX and screenY then calls to moveTo/moveBy just after opening the window are ignored.

Comment 20

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 21

[Timea Cernea [:tbabos][inactive]]

Hey Florian,
This is a very old issue, could you check if this issue si still relevant today? Otherwise, we should close it. Thanks!

Comment 22

[Florian Quèze [:florian]]

(In reply to Timea Cernea [:tbabos] from comment #21)

Hey Florian,
This is a very old issue, could you check if this issue si still relevant today? Otherwise, we should close it. Thanks!

I don't have a testcase to reproduce anymore. My bug 509828 comment 22 indicated I thought it could have been fixed there, so I'm going to close as a duplicate of bug 509828.