389341 - Tooltips too tall: only expand, don't shrink height based on event that's under mouse

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Pete Riley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5
Build Identifier: Lightning 0.7pre 2007072204 / Thunderbird 2.0.0.5

Tooltips don't change height based on the event that's currently under the mouse.

Reproducible: Always

Steps to Reproduce:
1) In month view, create a simple event with no description and create another event with a multiple-line description.

2) Restart Lightning/Thunderbird.  (don't know if this affects Sunbird)

3) In calendar mode, hold your mouse over the simple event first and notice the correct height of the tooltip.

4) Hold your mouse over the event with the long description.  The tooltip correctly becomes taller.

5) Hold your mouse over the simple event again.
Actual Results:  
In step (5), the height of the tooltip is too big.  It's the same height as when you held the mouse over the event with the long description.

Expected Results:  
The tooltip should adjust its height based on the event that's currently under the mouse.  This might also be a problem with tasks, etc.

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

Confirmed, thanks for the bug report, I wanted to file this one for a while. Bug 366680 will change most of mouseoverPreviews.js, so it would be smart to wait for that one.

Comment 2

[Ken West]

I can confirm this bug also affects Sunbird, both under Windows and Linux. I suggest the severity ought to be more severe than 'trivial': this problem is visually annoying and makes it difficult to see the details of an event.

Comment 3

[Stefan Sitter [:ssitter]]

Confirmed as regression on Linux:
  WORKS in Sunbird 0.7pre (2007-07-04-04)
  FAILS in Sunbird 0.7pre (2007-07-05-04)

Checkins during regression range: <http://tinyurl.com/32ywea> 

Most likely caused by the checkin for Bug 262811.

Comment 5

[gekacheka]

Attachment: move workaround sizeTo(0,0) code before adding new content.

(patch -l -p 1 -i file.patch)

Here's an adjustment to the workaround that seems to help on w2k.
(Bug 396298 seems to indicate Linux is different.)

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

Sorry I haven't taken a look at this yet, I haven't had access to other OS's over christmas. Can someone test this on xp,mac,linux? I have the feeling that setting the dimensions before might make the tooltip very small...

Comment 7

[Simon Paquet [:sipaq]]

Philipp, the patch works as advertised on WinXP with a patched nightly from today.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080105 Calendar/0.8pre + the patch in this bug

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

Simon,  thanks for checking. Now I'm only concerned about the mac. Maybe if someone has a mac at home or work (mickey? daniel? berend?) they could give this patch a quick test, otherwise I promise I'll review this coming monday or tuesday.

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 291803 [details] [diff] [review]
move workaround sizeTo(0,0) code before adding new content.

Ack, sorry again :/ r+ and I'll try to test on the mac tomorrow at work.

Comment 10

[Philipp Kewisch [:Fallen][📱📆]]

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 11

[Andreas Treumann]

Checked in latest nightly builds 2008021418 (Sunbird and Lightning) -> task is fixed and verified.