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.

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.

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

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”

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

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.

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.

Is this a regression?

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

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

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

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

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...

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.

(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.

(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).

And the maxSize value comes from popup.css style for tooltips: tooltip { ... max-width: 40em; ... } I uses the same size for Linux and Windows.

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).

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 on attachment 8424846 [details] [diff] [review] patch I have no idea about this code, sorry. Maybe Neil does?

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.

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

Comment on attachment 8434941 [details] [diff] [review] patch, v.2 Try run https://tbpl.mozilla.org/?tree=Try&rev=3e3c536d85c7

Comment on attachment 8434941 [details] [diff] [review] patch, v.2 I meant to do this within nsContainerFrame::SetSizeConstraints

Updated one, Thanks.

Comment on attachment 8438386 [details] [diff] [review] patch, v.3 Try build: https://tbpl.mozilla.org/?tree=Try&rev=c89bf21b02f2

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