387131 - Tooltip extends downward into TaskBar

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007070608 Minefield/3.0a7pre Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007070608 Minefield/3.0a7pre Firefox/3.0

Visiting the site in the URL, and hovering over a link near the bottom of the screen results in some tooltips, if large enough, to display down - covering the taskbar and in some cases cutting off a line or two of text. 

The tooltip should be displayed 'upward' if the tip is near the bottom of the display area. 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Tooltip displays wrong, goes down over the taskbar.

Expected Results:  
Should display upward on tips located at the bottom of the screen. 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007070608 Minefield/3.0a7pre Firefox/3.0 ID:2007070608
Vista HP

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Why did you mark this bug as "depends on" bug 386390?

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #1)
> Why did you mark this bug as "depends on" bug 386390?

I didn't that I know of.  I don't know how it could of snuck in when I filed.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Sorry, not you Jeffrey. "supernova_00" did that, my question was addressed to him/her.

Comment 4

[u88484]

I believe that bug regressed this because on the mozillazine forums it was stated that the tooltips were fine (except for the 386390 bugs) then after that checkin, this bug was reported.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #4)
> I believe that bug regressed this because on the mozillazine forums it was
> stated that the tooltips were fine (except for the 386390 bugs) then after that
> checkin, this bug was reported.

I doubt that bug would have had anything to do with this, so unless you have evidence that this specific bug was tested before bug 386390's landing, but after bug 279703's, I'd rather you not jump to conclusions :). It's much more likely that this is a regression from bug 279703.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: screen shot showing problem

100% reproducible in nightly trunk build from 20070705, as shown 
in this screen shot.  Also notice the size of the popup!
BTW, the screen shot was taken while viewing this very bug.

Comment 7

[u88484]

(In reply to comment #6)
> Created an attachment (id=271293) [details]
> screen shot showing problem
> 
> 100% reproducible in nightly trunk build from 20070705, as shown 
> in this screen shot.  Also notice the size of the popup!
> BTW, the screen shot was taken while viewing this very bug.
> 
That is bug 386390 which is fixed in today's build. Please update minefield

Comment 8

[Neil Deakin]

Attachment: Evil fix

This is caused by the famous bug 228673. The preferred height is being returned as one line, then the child is laid out which sets its size to the real size needed, several lines.

This is a workaround style fix which I don't really like but at least can be removed again once inlines and xul boxes work better together. The patch is bug 388112 is also needed.

Comment 9

[Neil Deakin]

Comment on attachment 272681 [details] [diff] [review]
Evil fix

OK, I think this should be ok for now. I can revisit this one day when bug 228673 is fixed.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 272681 [details] [diff] [review]
Evil fix

OK, but make a note in the boxobject bug that this code should be removed.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 272681 [details] [diff] [review]
Evil fix

a=bzbarsky

Comment 12

[Neil Deakin]

Checked in. Will need to add something for this to the largemenu.xul test