351909 - Dialogs containing XUL menulists don't size correctly

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Boris Zbarsky [:bzbarsky]]

STEPS TO REPRODUCE:

1) Start Seamonkey
2) Right-click a bookmark on the personal toolbar
3) Select "Properties"

ACTUAL RESULTS:  Right side of dialog is cut off.

EXPECTED RESULTS:  All the content is visible.

There may be other steps too, say with Firefox, but I don't have a Firefox build on hand.  Any dialog that sizes to content and has menulists in it would be affected.

The regression range is http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-03+01&maxdate=2006-09-04+01&cvsroot=%2Fcvsroot and my bets are on bug 348304.

At a guess, we're firing onload while some sort of menu events are pending; this causes the sizeToContent() to size to a too-small size, then we reflow the menus to a larger size and no longer fit.

We should probably block onload while whatever event is involved is live.

Comment 1

[Daniel Veditz [:dveditz]]

Nominating for the releases that are taking bug 348304. There might be stock Firefox dialogs that exhibit this bug, and it could certainly show up in extensions.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Clearing nom request; I don't think we've taken (or gotten a request to take) bug 348304 on the branch -- at least, I don't see a 1.8.1 approval anywhere on there. Also, the new patch on that bug says that it fixes this regression.

Feel free to renom if I've erred!

Comment 3

[Daniel Veditz [:dveditz]]

bug 348304 is marked blocking1.8.1+ by schrep, dunno why the patches don't have approval requests, perhaps waiting for this regression fix. In anycase, they should either be both blocking or both non-blocking, and given the other one is a security bug with a fix my preference is "blocking".

(perhaps FF2 uses a different tracking scheme, but sometimes bugs track separate symptoms that are important not to lose whether or not the supposed dupe or fix in another bug actually works.)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

This should be fixed now.
The patch is in bug 348304.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, looks good.

Comment 6

[Peter Kasting]

It looks like the branch version of bug 348304 got bumped to 1.8.1.1.  Should this do likewise?  Or should the blocking requests just be cleared in favor of that bug?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #6)
> It looks like the branch version of bug 348304 got bumped to 1.8.1.1.  Should
> this do likewise?  Or should the blocking requests just be cleared in favor of
> that bug?
> 

Yes, I think bug 348304 could be used to track also regression related to it. And this bug is a regression from that.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Because bug 348304 is not blocking1.8.1+ , this shouldn't be either.

Comment 9

[Mike Schroepfer]

Moving to 1.8.1.1 to follow bug 348304

Comment 10

[Daniel Veditz [:dveditz]]

Restoring lost blocking flag

Comment 11

[Daniel Veditz [:dveditz]]

Supposedly this won't be a problem, but plussing so we get verification when bug 348304 lands on the branches.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Just tested 1.8 and 1.8.0 seamonkey, and this shouldn't have regressed there. Marking fixed1.8.1.1, fixed1.8.0.9.

Comment 13

[juan becerra [:juanb]]

Verified with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9pre) Gecko/20061128
Firefox/1.5.0.9pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1pre) Gecko/20061128
BonEcho/2.0.0.1pre