282812 - Combobox (select) dropdown menu in wrong position with closed toolbar

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Gtk, defect)

Description

[Mats Palmgren (inactive)]

Combobox (select) dropdown menu in wrong position with closed toolbar.

STEPS TO REPRODUCE:
1. load attached testcase
2. click on the "grip" in the toolbar containing Back/Forward buttons etc.
   so that it is collapsed (see screenshot).
3. click on the combobox

ACTUAL RESULTS:
see screenshot.
(After resizing the window it is positioned correctly again.)

PLATFORMS and BUILDS TESTED:
Bug occurs in 2005-02-17-12 trunk Linux (GTK1)
Bug occurs in Mozilla 1.8a5 Linux (GTK1)
Bug does NOT occur in Mozilla 1.8a4 Linux (GTK1)
Bug does NOT occur in any GTK2 build that I tested.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 2

[Mats Palmgren (inactive)]

Attachment: Screenshot #1

Comment 3

[Mats Palmgren (inactive)]

Attachment: Screenshot #2

Comment 4

[Mats Palmgren (inactive)]

Regression window: 2004-10-06-05 -- 2004-10-16-06
One of these seems most likely:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fview&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-06&maxdate=2004-10-17&cvsroot=%2Fcvsroot

Comment 5

[Boris Zbarsky [:bzbarsky]]

In fact, this regressed between 2004-10-11-08 and 2004-10-12-07.  Almost
certainly fallout from bug 238493.

Comment 6

[Boris Zbarsky [:bzbarsky]]

If I don't cache screen positions in GTK1's nsWindow, the bug goes away.

I poked at this for a bit, and I can't tell why that's going on.  The only time
I see us hitting the cached values for a popup widget is when we're checking
whether the click was inside the combobox's list.  The code in Move() that's
conditioned on |mParent && mWindowType == eWindowType_popup| is not hit, of
course (since the popup has no mParent).

So I'm really somewhat at a loss as to how the position cache screws us up
here...  Robert, any idea?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Requesting blocking.  This is making bugzilla pretty painful to use, actually...

Comment 8

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

In a nutshell, the problem is that widgets in the content window aren't hooked
up to the widget tree, so we never invalidate the position cache of the content
window widgets when the outer window moves.

Comment 9

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

Attachment: fix

This is pretty grotesque, but it works. We basically remember the non-hooked-up
relationship and use it as an extra path to invalidate the cached position.

Comment 10

[Andrew Schultz]

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

Comment 11

[Andrew Schultz]

Comment on attachment 178437 [details] [diff] [review]
fix

this patch doesn't fix the bug for me

Comment 12

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

Attachment: fix

You're right. That one didn't work and I'm not sure why I thought it did.
Perhaps something changed between when I first tested it and when you tested
it.

This one works on today's trunk and it's probably a better approach anyway.

Comment 13

[Christopher Blizzard (:blizzard)]

Comment on attachment 186274 [details] [diff] [review]
fix

This feels pretty hackish to me, but I'll bet it will work.

Did you test this with child plugin windows?

Comment 14

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

Seems to be OK with the null plugin.

Comment 15

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

Comment on attachment 186274 [details] [diff] [review]
fix

GTK1 fix

Comment 16

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

checked in