233081 - modal dialog jumps when dragging its <titlebar> widget

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Cedric. S.]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

The XUL window is opened with opendDialog, titlebar="no".
The XUL window contains a <titlebar> tag, used to replace
the standard MSWindows titlebar.

The problem occurs when trying to move the window by
dragging the titlebar : the window first jumps, then moves.

This does not happend when the window is not opened as modal
(modal=no) which is the expected behaviour.

(I would be glad for a workaround if any)

See test set attached.

Reproducible: Always
Steps to Reproduce:
Using the attached test set, open the "test.xul" page.
1. click on the first button of the page
2. click on the titlebar (custom <titlebar>) of the modal dialog that opens
3. drag




Actual Results:  
The dialog jumps before moving.

Expected Results:  
move directly, the it is done when opening the exactly same dialog, but
non-modal.

Comment 1

[Cedric. S.]

Attachment: zip file containing testcase

execute test case from a chrome package by opening test.xul
e.G.
chrome://dev/content/test.xul

Comment 2

[Dan M]

Interesting. This seems to happen only when a titlebar widget is used in a
top-level, dependent window missing its native titlebar. And probably only on
Windows. As you begin dragging the test window it jumps a distance equal to the
offset between its local and global coordinates. By the way this effect can be
used to move the window completely offscreen, though it takes some cooperation
from the user.

This would seem to be a widget level problem. Parity is broken between the
widget's bounds accessor and mutator, and this confuses appshell-level windows.
In fact, it looks as if the Windows implementation of nsWindow::GetScreenBounds
is simply missing. That's really surprising at this point in the maturity of
this code.

GetScreenBounds isn't a widely used method, so consequences of changing it won't
ripple very far. But still I'm worried something subtle and critical will break
should we change its implementation.

Cedric: I'm sorry, but I can't think of a workaround. It really looks like a
widget-level bug.

Comment 3

[Dan M]

Attachment: implement nsWindow::GetScreenBounds on Windows

Fixes this bug and causes what horrible, subtle problem?

Comment 4

[Dan M]

Comment on attachment 140679 [details] [diff] [review]
implement nsWindow::GetScreenBounds on Windows

I've been running with this patch on my system since early February and noticed
no problems. Maybe it's actually a good thing.

Comment 5

[Ere Maijala (slow)]

Comment on attachment 140679 [details] [diff] [review]
implement nsWindow::GetScreenBounds on Windows

r=ere

Comment 6

[Dan M]

Patch checked in to the trunk for 1.7b. This bug should be fixed in 1.7 barring
discovery of some horrible regression that I never noticed.

Comment 7

[Dan M]

I see no bugs filed after 3 Mar that would seem to be related to this checkin.
Closing.