957396 - Hovering Tooltip Text Area Size

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Dave Jarvis]

Attachment: overbearing-tooltip.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131206152142

Steps to reproduce:

1. Go to any site.
2. Hover over any item with a tooltip.



Actual results:

A massive black box appeared with an insignificant amount of text (the tooltip text). This hides a fairly large portion of the web page, which is somewhat obtrusive.


Expected results:

The box for the tooltip should only be large enough to contain the entirety of the text.

Comment 1

[Dave Jarvis]

Attachment: Shows the tooltip extending well beyond the web page

Comment 4

[Mats Palmgren (inactive)]

I seem to recall having seen this problem in the past (on the tooltips on tbpl, iirc).
I thought we fixed that, but maybe I misremember.

Comment 6

[Mats Palmgren (inactive)]

The duplicate bug 974533 has steps to reproduce:
1. open a new window
2. load http://www.mozilla.org/ in the first tab
3. load https://bugzilla.mozilla.org/attachment.cgi?id=8378440 in a second tab
4. hover the tab header of the second tab
5. hover the tab header of the first tab

Actual result:
https://bugzilla.mozilla.org/attachment.cgi?id=8378445

Comment 7

[nicolas m]

Hi,
I’m getting similar issues with Firefox 30 on Ubuntu 13.04/Unity. The tooltips are really big. Here, it doesn't happen on webpages’ links — but on certain UI buttons.

Where it happens:
* “Open a new tab”
* “Reload current page”
* “Bookmark this page”
* “Open menu”
* All buttons in the menu
* …

Where it *doesn’t* happen:
* <tab name>
* ”Close tab”
* <bookmark info>
* Previous page / Next page
* “Show your bookmarks”

Comment 8

[nicolas m]

Edit: It doesn't happen for “all” menu buttons. “Full screen” and “Tab Groups” display normal-sized tooltips.

Comment 9

[nicolas m]

Attachment: Screencast showing some abnormally sized tooltips

Comment 10

[Timothy Nikkel (:tnikkel)]

The steps from comment 6 didn't reproduce for me. Mats if you want to look into this I suspect the problem lies with SetSizeConstraints/GetSizeConstraints, looks like they don't get updated when we re-use the tooltip widget for the new (smaller) tool tip.

Comment 11

[Mats Palmgren (inactive)]

I investigated this a bit and it turns out that the tooltip that is too large actually
has a width=480 attribute set on the content node.  So this seems more like a bug on the
toolkit level.

Comment 12

[Daniel Holbert [:dholbert]]

Is this a regression?

Comment 13

[Harlan Lieberman-Berg]

I had a coworker test this, and it does not occur on Windows in 27.0.1.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

Reproductible on Liunux and latest trunk...I'll look on it.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

When some size boundary is exceed the nsBoxFrame::GetPrefSize() (from  nsMenuPopupFrame::LayoutPopup()) returns too big sizes for all boxes.

Comment 19

[Martin Stránský [:stransky] (ni? me)]

The width/height seems to be defined as an element attributes - so it seems to be XUL element bug after all.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Well, actually, seems to be caused by gtk and popup window implementation. I looks like when tooltip size is bigger than default_width there's a race condition between moz_container and popup shell widget events. Still investigating...

Comment 21

[Martin Stránský [:stransky] (ni? me)]

Btw. It affects both Gtk2 and Gtk3. gtk_window_move_resize(moz_container) seems to be the problem here. The popup window is then resized by gtk during gtk_window_show() because the moz_container is smaller than the popup window.

Comment 22

[Mats Palmgren (inactive)]

(In reply to Martin Stránský from comment #20)
> Well, actually, seems to be caused by gtk and popup window implementation.

That seems unlikely.  This bug affects other platforms too and when I debugged it
(comment 11) I found the element has width/height attributes with the wrong values.
I believe the bug is in whatever code calculated/set those attribute values.

Comment 23

[Martin Stránský [:stransky] (ni? me)]

(In reply to Mats Palmgren (:mats) from comment #22)
> (In reply to Martin Stránský from comment #20)
> > Well, actually, seems to be caused by gtk and popup window implementation.
> 
> That seems unlikely.  This bug affects other platforms too and when I
> debugged it
> (comment 11) I found the element has width/height attributes with the wrong
> values.
> I believe the bug is in whatever code calculated/set those attribute values.

I see. Yes, that's possible, because the min/max values mismatch. But this bug is filled against Linux so I expect we talk about Linux/Gtk here.

From some reason the minSize/maxSize values (from nsMenuPopupFrame::LayoutPopup()) seems to be wrong:

layoutPopup(): minSize.width = 762, minSize.height = 24
layoutPopup(): maxSize.width = 533, maxSize.height = 17895697

Those min/max values are passed to SetSizeConstraints() and sets gtk geometry hint on Gtk. gtk_widget_show() creates the popup widget container 533 pixel width (the geometry hint) and then resizes it to 762 pixels (resize request from layout engine). The resize event calls nsXULPopupManager::PopupResized() which sets the width attribute.

So it looks like a race condition between intended popup size (the 762 pixels) and maximal popup size passed to Gtk (the 533 pixels).

Comment 24

[Martin Stránský [:stransky] (ni? me)]

And the maxSize value comes from popup.css style for tooltips:

tooltip {
  ...
  max-width: 40em;
  ...
}

I uses the same size for Linux and Windows.

Comment 25

[Martin Stránský [:stransky] (ni? me)]

Actually there are two layout issues here:

1) When popup is resized because prefSize.width is bigger than the maxSize.width, it's handled as user-resize. So nsXULPopupManager::PopupResized() sets "width" attribute for the poppup element which causes popup oversize when is filled with some smaller text.

2) minSize.width/maxSize.width mismatch - minSize.width is bigger than maxSize.width which causes rendering artifacts on Gtk2 - the race condition between mozcontainer and popup window. The final popup size pulses between minSize.width and maxSize.width(prefSize.width).

Comment 26

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

Boris, what about this one? When the tooltip min/pref size exceed maxSize, update toolkit widget constraints accordingly. Otherwise the tooltip is reflown to min/pref size but toolkit widget is sized to maxSize.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8424846 [details] [diff] [review]
patch

I have no idea about this code, sorry.  Maybe Neil does?

Comment 29

[Neil Deakin]

Comment on attachment 8424846 [details] [diff] [review]
patch

No, this isn't quite correct. The issue here, at least with the steps in comment 6, is that the minimum size is larger than the maximum size. This is because there is a 'word' in that testcase that is extremely long. However, minimum sizes have priority over maximum sizes, yet nsContainerFrame::SetSizeConstraints doesn't enforce this so it ends up using whatever the platform ends up doing. So the better fix here is to ensure that function constrains the maximum size to be larger than the minimum size.

Comment 30

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch, v.2

Thanks for the feedback! So do you mean something like this? It enlarges the maximal size when the minimal one is bigger.

Comment 31

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 8434941 [details] [diff] [review]
patch, v.2

Try run https://tbpl.mozilla.org/?tree=Try&rev=3e3c536d85c7

Comment 32

[Neil Deakin]

Comment on attachment 8434941 [details] [diff] [review]
patch, v.2

I meant to do this within nsContainerFrame::SetSizeConstraints

Comment 33

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch, v.3

Updated one, Thanks.

Comment 34

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 8438386 [details] [diff] [review]
patch, v.3

Try build: https://tbpl.mozilla.org/?tree=Try&rev=c89bf21b02f2

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0d1f547d353d

Comment 36

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0d1f547d353d

Comment 39

[Ada [:adalucinet]]

Reproduced with Nightly 29.0a1 from 2014-01-07 on Linux 12.04 64-bit with STR from comment 6; Couldn't reproduce with steps from comment 7 on Nightly 2014-01-07 nor Nightly 2014-02-22. 

Verified as fixed with Firefox 33 beta 2 (Build ID: 20140908190852) on Linux 12.04 64-bit [1] and Mac OS X 10.9.4 [2].

[1] - Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
[2] - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0