228848 - Inconsistent moveTo results for modal XUL dialogs

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Wang Xianzhu]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

nsXULWindow treats specially for modal XUL dialog's positioning, by interpreting
the dialog's screenX and screenY attributes as relatives of the dialog's parent
window position.  This may work in most situations, but I think this
reinterpretion of screenX and screenY is not proper.  It may cause inconsistent
meaning of them, and thus cause inconsistent results of moveTo method calls.

For the following example:
<?xml version="1.0"?>
<!DOCTYPE window SYSTEM "chrome://racer/locale/">
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
 width="100" height="100"
 onload="window.moveTo(100,100)">
 <button id="btn" oncommand="window.moveTo(100,100)"/>
</window>

When this window is 'openDialog'ed by another window with 'modal' flag set, the
first moveTo in onload will position the window relative to the opener, while
the second moveTo in oncommand will position the window relative to the screen.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Brendan Eich [:brendan]]

Should this go to dom_bugs?

/be

Comment 2

[Wang Xianzhu]

I don't think this is a DOM bug, because the (mis)interpretion of screenX and
screenY is in /xpfe/appshell/src/nsXULWindow.cpp, which is only a user of DOM.

Comment 3

[Dan M]

This would be a bug, but I can't make it happen. In my testing (using a recent
build on Windows XP) the position is always interpreted in global coordinates,
whether it's given by a moveTo in a load handler, moveTo from a button click, or
initial position given in the window.open feature string. This is the behaviour
intended.

Wang, what misinterpretation are you referring to in nsXULWindow? As far as I
know, a window is (nearly) always positioned using global coordinates. The
single exception is its persistent position. That is indeed relative to the
parent window for dependent (and modal) windows, and that code is found in
nsXULWindow, but it has nothing to do with moveTo.

I suspect your problem window has persistent positioning active, and you're
seeing some sort of fight between all the different gremlins that want to claim
ownership of the window's position.

However the position given by the load handler should win. First, the window
should be moved to its persistent position, then to the position given in the
window.open() command, if any, and then to the position given in its load
handler, if any. So in your test, which has at least those last two and I
suspect the first as well, the persistent position should be effectively ignored.

Please verify that the bug you're seeing is actually as you've described, rather
than a fight between its persistent position and a given position. Also it would
be nice to know whether the window must be modal, or whether dependent suffices.
If so, the testcase need not involve chrome or privileged script and is much
simpler to work with. You could even attach such a testcase to this bug.

Comment 4

[Wang Xianzhu]

I'm sorry I made a mistake.  This 'bug' only reproduces in our own development
environment, because my colleague overrode window.moveTo method and added "load"
event listener (where window position was changed) in XBL.