265841 - Menus are offset in position

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Peter Weilbacher]

In my current builds (since Oct 21st or so) menus and various other UI elements
are offset in position from where they should be, here it is about 150px to the
right and 50px down. I will attach a screenshot shortly.
 I rebuilt after removing the obj-dir and it is still like that. Unfortunately,
the last OS/2 nightly was 2004101808 where everything in that respect was still
OK, so I cannot check with an independent build.

After looking through the checkins between 18th and 22st I suspect that the
patches for bug 264245 are responsible. I have not yet tried to back that out to
check. This seems to be OS/2 only.

Comment 1

[Peter Weilbacher]

Attachment: Screenshot showing offset help menu

Actually, it is more 278px to the right and 188px downwards...

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: potential fix?

Try this.

Comment 3

[Peter Weilbacher]

No, that doesn't fix the offset, but instead puts the menus behind the browser
window...

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: try #2

hoe about this?

Comment 5

[Mike Kaply [:mkaply]]

> how about this?

Nope, then they are even farther away.

Comment 6

[Mike Kaply [:mkaply]]

The position of the menu is dependent on where the window is placed. If the
window is 30 pixels from the left of the desktop, the menu will display 30
pixels to the right in the mozilla window.

So for some reason, the new code is using the position of the window in its
computation or doing some bad coordinage mapping.

Comment 7

[Peter Weilbacher]

Attachment: Hack fix

Robert was not too far off. nsWindow::Resize at
<http://lxr.mozilla.org/seamonkey/source/widget/src/os2/nsWindow.cpp#1444>
already gets the correct x-coordinate, but if it is a popup we only need to
count pixels from bottom instead from the top (using Desktop coordinates. So
the WinMapWindowPoints() is not needed in that case. Don't understand why
eWindowType_popup are special but at least with this patch I get menus,
dropdown boxes etc at the correct position again.

Additionally, I don't understand why every instance of "h" is written as
"GetHeight(h)", which is a function that only returns its argument. When
loading more complex pages this is called a few thousand times. I didn't try to
measure this yet but this might have some performance impact.

Comment 8

[Mike Kaply [:mkaply]]

Comment on attachment 163497 [details] [diff] [review]
Hack fix

r=mkaply, sr=blizzard (platform specific)

You are correct about GetHeight being unnecessary. It is left over from when we
had subclasses of nsWindow.

Comment 9

[Mike Kaply [:mkaply]]

Fix checked in.

Comment 10

[Felix Miata]

It's back: https://bugzilla.mozilla.org/attachment.cgi?id=185520