292657 - [gtk2]Drop-down selection box with CSS height attribute "drops down" at top left corner of screen (0,0)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jan Darmochwal]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050502
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050502

Opening a drop-down selection menu (<select>-Tag) inside a table cell with
text-align: right, center or justify causes the options to drop down at the top
left corner of the screen.

Reproducible: Always

Steps to Reproduce:
1. Click the first drop-down box in the testcase

Actual Results:  
Options "drop down" at the top left corner of the screen.

Expected Results:  
Options drop down below drop-down box.

Comment 1

[Jan Darmochwal]

Attachment: testcase

Comment 2

[Thomas K. (:tom)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050419
Firefox/1.0.4

Doesn't happen here.

Comment 3

[Andrew Schultz]

confirmed with current CVS.  I only see this with gtk2 builds.

regression between linux trunk 2005042701 and 2005042901

Comment 4

[Crispin Flowerday (not receiving bug mail)]

This also happens when the <select> tag has a 'width: 100%' tag

Comment 5

[Crispin Flowerday (not receiving bug mail)]

This looks to have been caused by bug 240276

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

Are we sure bug 240276 caused this?  Did someone test a local backout?  Also,
could we possibly narrow the regression range to one day?

Comment 8

[Crispin Flowerday (not receiving bug mail)]

I'm pretty sure, I did a build using:

make -f client.mk MOZ_CO_DATE="2005-04-28 23:00:00"

and that failed, but

make -f client.mk MOZ_CO_DATE="2005-04-28 22:50:00"

worked, I'm in BST (+0100) and bug 240276 seemed to be the only checkin during
that period, I can double check again if that would make you feel happier.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Not, that's exactly the sort of info I was looking for.  Much narrower than the
range in comment 3.  ;)

Comment 10

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

I only see this before I first move the window.

Comment 11

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

Attachment: fix

This patch fixes this bug and bug 292802, and maybe other issues. The problem
is when this happens to a widget that has mListenForResizes...

-- someone calls Resize(x,y,w,h) to resize a widget really small and move it
-- it's hidden and !AreBoundsSane, so we just set mNeedsResize and do nothing
-- someone calls Resize(w,h) to resize the widget to sane bounds
-- it's still hidden but now it has sane bounds and mListenForResizes is true,
so we call NativeResize(w,h)
-- NativeResize(w,h) sets mNeedsResize to PR_FALSE

At this point we've forgotten that we still need to move the widget to its
correct position ... when we later call Show(), it doesn't get moved and it
appears in the wrong position.

This fix adds mNeedsMove to separately indicate that the position must be
updated. NativeResize(w,h) doesn't clear mNeedsMove (and Resize(w,h) doesn't
set it).

Comment 12

[nandhp]

Attachment: Another drop down problem

I'm having another, possibly related problem with a drop down I am
experiencing.

For some reason, a drop down (but not a text input) can be compressed down to
0-width by placing it in a table with a 100% width cell. This only seems to
happens in the trunk (Using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050510 Firefox/1.0+).

Comment 13

[Christopher Blizzard (:blizzard)]

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

Looks good.

Comment 14

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

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

old GTK2 widget bug that started showing up due to some other changes, so looks
like a regression

Comment 15

[Asa Dotzler [:asa]]

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

a=asa

Comment 16

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

checked in