94296 - XUL Popups appear at wrong coordinates when collapsing/expanding toolbars and sidebar

Status: VERIFIED DUPLICATE of bug 146108

(Core :: XUL, defect)

Description

[Colin Phillips]

Steps to reproduce:
1) Browse to: http://www.mozilla.org/projects/xul/tests/popups.xul
2) collapse the three toolbars at the top of the screen (toolbar with menus,
toolbar with url entry field, personal toolbar) using the collapsable portion of
the toolbar on its leftmost edge
3) press "Above Left" button once to make popup appear
4) click off the popup to make it disappear
5) expand the three toolbars mentioned above
6) press "Above Left" button again to make the popup appear

Expected Results: Popup should appear directly above the button to the left.

Actual Results: Popup appears above the button to the left with a gap equivalent
to the size of the toolbars between the top of the button and the bottom of the
popup.
Reproducable: Always

Comment 1

[John Morrison]

Both this bug and bug 94294 are Linux-only bugs, likely window manager joy :-]

Comment 2

[David Hyatt]

--> bryner

This is a linux-only issue.  Need to figure out what strangeness is occurring 
only on Linux.

Comment 3

[Peter Trudelle]

->099

Comment 4

[Ben Tremblay]

2002011604 Win95 166MHz, using popups.xul

"At Pointer"
* popup collapses far above expand point (near "Left Bottom" button)

"After Point"
* popup collapses far above expand point (near "Right Top" button)

The reason I specific clock speed is the disfunction I see is time sensitive:
even a slight hesitation results in displacement while a very quick selection 
results in proper collapse.

Additionaly - "After Point" popup expands further from pointer than seems 
reasonable

Comment 5

[Brian Ryner (not reading)]

This seems to be a relatively obscure issue.  Pushing off & marking helpwanted.

Comment 6

[Peter Bojanic]

Nominating for mozilla1.0

Comment 7

[Peter Bojanic]

Removing the mozilla1.0 nomination because this is no longer an oeone bug and
wasn't previously nominated.

Comment 8

[Pierre Chanial]

*** Bug 114467 has been marked as a duplicate of this bug. ***

Comment 9

[Pierre Chanial]

*** Bug 101835 has been marked as a duplicate of this bug. ***

Comment 10

[Pierre Chanial]

*** Bug 111819 has been marked as a duplicate of this bug. ***

Comment 11

[Pierre Chanial]

*** Bug 116335 has been marked as a duplicate of this bug. ***

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

re-nominating.  This has been collecting more than a few dups.  I run into it on
a daily basis, and it can affect other cases where items move due to chrome
going display:none.  While we don't use context menus, we do use dynamic
display:none to remove chrome, and we know for sure this is confusing widgets,
and perhaps other things.

Comment 13

[John Morrison]

*** Bug 140924 has been marked as a duplicate of this bug. ***

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

This is not a window-manager problem; we run mozilla without a WM and have it.
Our content causes the XUL menubar to appear and disappear depending on where
we've browsed, and this bug causes popups and combobox dropdowns to appear in
the wrong place.

I would assume it's a problem with the widget caching of the location (or
perhaps more likely the offset from window's 0,0) when the widget is created,
and not updating it when it's repositioned.

Is this a general linux issue, or is it only a GTK issue?

Scrolling also moved dropdowns, but doesn't cause this problem.  Why?  Does
window resize cause this?

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

FYI: scrolling moved the sub-widget popup position, but doesn't undo the
incorrect position (i.e. it applies a delta to the position).

Resize of the window (not surprisingly) repositions the dropdown position
correctly.  A content-area resize (due to XUL appearing/disappearing) should do
the same thing as a window resize.  Both must already be doing reflows.

Comment 16

[Christopher Blizzard (:blizzard)]

I strongly suspect this is a dup of 146108.

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

Yes, or vice-versa, but that bug has a patch.

Chris, can you review the patch there?  I'd LOVE this patch for 1.2b/1.0.2, or
at least for 1.2b/1.0.3

duping to bug 146108

*** This bug has been marked as a duplicate of 146108 ***

Comment 18

[:deanis74]

v