809388 - Regression: tooltip doesn't shrink when content shrinks

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[Ian Nartowicz]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Build ID: 20120208060813

Steps to reproduce:

1. Create a tooltip taller than the screen
2. Open the tooltip
3. Shrink the contents so that the tooltip is smaller than the screen
4. Open the tooltip


Actual results:

In step 2, the tooltip receives a height attribute and is cropped to the size of the screen.
In step 4, the tooltip remains at the specified height and there is a larger grey border filling the gap between the content and the bottom of the screen.


Expected results:

Tooltip should shrink to the size of the content, subject to CSS or attributes specified for the tooltip, but not attributes added by Firefox for transient conditions.

This bug did not occur in versions prior to 17.  It appears to be similar to bug 788829 but still occurs after that bug landed.

Comment 1

[Ian Nartowicz]

Attachment: Tooltip (Walnut 2 theme) showing padding to bottom of screen

This is the appearance after the content has shrunk and the blank padding remains at the bottom.  The "dummy" lines are the remaining content.  The tooltip has been opened from the grey icon, offset to the side to avoid being forced down over the icon and shutting itself off.

Comment 2

[Neil Deakin]

Do you have a testcase for this?

Comment 3

[Ian Nartowicz]

My testcase is my addon:
https://addons.mozilla.org/en-US/firefox/addon/utorrent-status-tool/

Load up enough torrents to fill the height of the screen, open the tooltip (open it from the top of the menu because it will close itself if you open it from the icon and it will be very difficult to see).  Delete, or configure not to show, some torrents and open the tooltip again.  Big border stretching from the content to the bottom of the screen.  Started happening with 17 beta.

Comment 4

[[:Aleksej]]

Please make a minimized testcase (as an HTML page, if possible), and/or find when it regressed using the builds in https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/
Thanks.

However, it may be related to bug 802335 and bug 802336.

Comment 5

[Ian Nartowicz]

Attachment: Hacked addon to demonstrate the tooltip issue

Comment 6

[Ian Nartowicz]

Unfortunately I can't run 17/18/19 nightlies on Linux since they messed up lubxul, so I can't narrow down the regression.

HTML test case for an XUL tooltip?  Don't know how to do that either.

So I've attached a hacked version of my addon.  Not exactly minimal but hopefully you'll see the bug in action.
1. Install attachment
2 [review]. Customise the uTorrent icon onto the navbar or somewhere else up top (not the addon bar)
3. In the options dialog, make sure "alternate tooltip style" is not checked
4. Hover over the icon, big ugly tooltip should be taller than the screen
5. Switch alternate tooltip style option on
6. Hover again, tooltip should be one line ("test") but is padded at the bottom

Comment 7

[Virgil Dicu [:virgil] [QA]]

Can reproduce on Ubuntu 12.04.
Can't reproduce on Windows 7.

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d2a7a8ca1c7&tochange=582d4c67b3a7

I'll try to bisect to reduce the range by tomorrow if nobody has a clue about the culprit.

Comment 8

[Ian Nartowicz]

Bug 357725?
Or perhaps bug 582719?

Comment 9

[Virgil Dicu [:virgil] [QA]]

(In reply to Ian Nartowicz from comment #8)
> Bug 357725?
> Or perhaps bug 582719?

Neil, is bisection still needed here? Both these bugs were fixed by you.

Comment 10

[Neil Deakin]

Very likely bug 357725.

Comment 11

[Neil Deakin]

Essentially though, the height attribute shouldn't be being set here. nsXULPopupManager::PopupResized needs to distinguish between a size change caused by the user and one that happens as part of popup layout and ignore the latter.

Comment 12

[Ian Nartowicz]

It does seem that using the height attribute to crop a frame to the screen size is a bit of a hack.