422515 - popup boxObject's height and width 0 when it's not open

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[:Gijs (out for now; he/him)]

History in bug 418798.

Testcase: Open ChatZilla's preferences on recent trunk, hover mouse over one of the pref items, and observe the weird tooltip size.

Picture: http://dcorr.nfshost.com/tmp/Picture%2010.png

Regression range is:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-04+03%3A00%3A00&maxdate=2007-07-05+05%3A00%3A00&cvsroot=%2Fcvsroot

I'm blaming bug 279703.

(In reply to bug 418798 comment #8)
> The size of a popup before it is open is 0.
> <snip>

It didn't use to be. I also don't think that makes sense, as a normal box's size is still retrievable even if it's display:none; . Of course that isn't exactly the same as an undisplayed popup, but I don't understand why the fact that it's not displayed means its boxObject property should be utterly useless. Even if you think that from a theoretical point of view it should be 0 as it's "not there", I don't think that's enough to justify this regression.

Carrying over blocking1.9? request (resetted on bug 418798)

Comment 1

[Boris Zbarsky [:bzbarsky]]

> as a normal box's size is still retrievable even if it's display:none;

That statement would be false, as it happens.

I have no idea whether that actually affects this bug, of course.

Comment 2

[Neil Deakin]

I don't really consider this to be a bug.

This is caused because the frames inside a popup are not created until the popup is first opened. This is an optimization to avoid creating frames for content that isn't visible at startup.

You could avoid that if really desired for a <tooltip> element by adding a type attribute and set it to something.