805039 - Long tooltips without whitespaces are truncated and not wrapped

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[FragerZ]

Attachment: Example of a cut-off tooltip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Steps to reproduce:

Create a long tooltip and do not enter whitespace. This can be easily done by creating/editing the title attribute of an element, and then moving the mouse over it.

This only happens when the title does not have spaces, and is at least ~80 characters long.

Example shown in picture:
<a title="This_is_a_very_long_description_which_does_not_have_whitespace.This_is_a_very_long_description_which_does_not_have_whitespace.">
This_is_a_very_long_description_which_does_not_have_whitespace.This_is_a_very_long_description_which_does_not_have_whitespace.</a>


Actual results:

The tootip is truncated after ~80 characters and does not wrap.


Expected results:

The text should wrap and there should be a margin on the right hand side of the text that is proportional the the margin that exists on the left hand side of the text.

Comment 2

[mjh563]

The fix for this seems to be as simple as adding

tooltip {word-break:break-all}

to chrome://global/skin/popup.css

To fix it yourself as a user, put the above line in your userChrome.css file.

Comment 3

[mjh563]

Hmm, maybe it's not that simple though, because that can cause line wrapping within words even when not necessary. For example:

data:text/html,<a title="This_is_the_first_very_very_very_very_long_word. This_is_the_second_very_very_very_very_long_word.">link</a>

With 'word-break:break-all' the wrapping happens within the second word, not at the space between the words.

Comment 5

[ferongr]

Attachment: Testcase demonstrating the bug

Testcase demonstrating the bug. Firefox 19 and all future versions are affected.

Comment 6

[ferongr]

Attachment: Good (top) vs bad (bottom) rendering.

Last good nightly: 2007-04-24
First bad nightly: 2007-04-25

This was a real blast from the past. This is from the CVS days so I don't know anything more (the Mercurial web interface doesn't have changesets for those dates).

Image attachment demonstrates "good" (using ellipsis to indicate a truncated string) vs a bad build

Comment 7

[[:Aleksej]]

(In reply to John Volikas from comment #5)
> Created attachment 717977 [details]

It is truncated on the first and other odd tries, and displayed on the seconds and other even tries (2013-02-24-03-10-53-mozilla-central-firefox-22.0a1.en-US.linux-x86_64, and 20 Beta).

Comment 8

[ferongr]

Maybe bug 218223?

Comment 9

[mjh563]

I think I've found a proper fix for this problem (or at least, a workaround). Try adding this to your userChrome.css:

tooltip > label
{
    word-wrap: break-word;
    min-width: 1px;
}

That should make long words wrap onto a new line, keeping the correct margin and border on the right hand side of the tooltip.

I got the idea from bug 630864. For some reason, word-wrap:break-word doesn't work in XUL unless you add a minimum width.

Comment 11

[mseema2003]

Is there going to be a fix provided in latest version of Firefox for this issue?

Comment 12

[mjh563]

Attachment: Patch

This patch should fix the bug. It allows tooltip text to break in mid-word if required, so that long words containing no whitespace will wrap onto a new line instead of being truncated.

Comment 13

[mjh563]

Attachment: screenshot of testcase after patch applied

This is how the testcase appears on a Linux build with the patch applied. The long word is wrapped onto a new line and is fully visible.

Comment 14

[Scoobidiver (away)]

Will this patch fix bug 816436?

Comment 15

[mjh563]

(In reply to Scoobidiver from comment #14)
> Will this patch fix bug 816436?

No.

Comment 16

[mseema2003]

How do I apply this patch in my source code?

Comment 17

[alex_mayorga]

Is this why hovering on https://bugzilla.mozilla.org/show_bug.cgi?id=1126268 shows a truncated tool tip too?

Could you please try landing the patch in any case, please?

Comment 18

[alex_mayorga]

¡Hola!

Tool tips are no longer truncated for me with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 ID:20150624030204 CSet: be81b8d6fae9

Could you please confirm with a build from https://nightly.mozilla.org/ and change the "Status:" field to VERIFIED FIXED at the bottom of the bug accordingly?

¡Gracias!
Alex

Comment 19

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
20151014143721
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
20151030030236

Reproducible with Firefox 41.0.2 as well as the current Nightly.

Comment 21

[p.viral.p]

@gingerbread Man, also another scenario is (as mention in  1220230) is if I enter "/n".... not sure if the fix for this bug will fix that as well.

Thanks
viral

Comment 23

[Cheng Wu]

Came across the same issue while using firefox 60.0.2, is there any progress for this issue currently?

Comment 25

[Roma]

Is there any resolution to this bug?

Comment 26

[alex_mayorga]

¡Hola Roma!

Unfortunately not yet.

The issue still reproduces on today's Firefox Nightly with the test case attached to this bug.

I've set the bug flags accordingly FWIW.

¡Gracias!
Alex

Comment 27

[Roma]

(In reply to alex_mayorga from comment #26)

¡Hola Roma!

Unfortunately not yet.

The issue still reproduces on today's Firefox Nightly with the test case attached to this bug.

I've set the bug flags accordingly FWIW.

¡Gracias!
Alex

Thanks for the reply ..!

Comment 29

[:Gijs (he/him)]

We should try to resurrect this patch. It's breaking the tooltip of origin titles in in-content modal dialogs in proton.

Comment 30

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (even longer tooltip, which is needed to see the bug on larger monitors)

The original testcase loads fine for me right now, but that's just because my monitor is wide enough for the whole thing to fit just fine on a single line.

Here's a version of the testcase with a much larger tooltip, whose last stretch of characters is "zzzzz". Expected results here would be for the "zzzz" to be visible (e.g. via linewrapping) or for the clipped characters to be gracefully ellipsized somehow. Actual results are that it gets clipped right now (somewhere around "dddddeeeee" for me).

Comment 31

[Daniel Holbert [:dholbert]]

Attachment: Bug 805039: Let tooltips break in mid-word if required, so they don't get truncated. r?Gijs

Comment 32

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 (hovered), with patch

I posted a rebased version of the patch. It seems to work. (And its included automated testcase seems to work, too -- it fails without the functional part of the patch, and it passes with it.)

Here's a screenshot of "testcase 2" with the patch, showing the correct/expected behavior, I think.

I also tried a testcase with a bunch of kinda-long words, to be sure we didn't end up wrapping midword unnecessarily, and that worked fine as well. I verified that we'll wrap entire words (instead of e.g. laying out as many characters as possible and breaking at arbitrary midword points).

Comment 33

[Daniel Holbert [:dholbert]]

Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3226a03630d3d708ad5341735feaa0c94d3db657

Comment 34

[Daniel Holbert [:dholbert]]

Try run looks good, I think (seems like just known-intermittent failures, and I don't see the new test failing anywhere).

Since we're in a soft-freeze as of earlier today, I'll hold off to land this until after the merge on Monday. (Gijs, let me know if there's any reason that we might need to uplift this to 89beta; I don't have a good understanding of what the proton impact is here & what if anything that means for 89.)

Comment 35

[:Gijs (he/him)]

(In reply to Daniel Holbert [:dholbert] from comment #34)

Try run looks good, I think (seems like just known-intermittent failures, and I don't see the new test failing anywhere).

Since we're in a soft-freeze as of earlier today, I'll hold off to land this until after the merge on Monday. (Gijs, let me know if there's any reason that we might need to uplift this to 89beta; I don't have a good understanding of what the proton impact is here & what if anything that means for 89.)

I think given this is a CSS only patch (plus a test), and is therefore pretty low-risk, it would be nice to land it today, or if you prefer to wait, uplift to beta for proton. It's proton-relevant in that we use tooltips for long domains in dialog titles (where subdomains will get elided in order to show the toplevel domain), and if the tooltip then truncates at the end (toplevel domain instead of subdomain) that would be unfortunate. Does that help?

Comment 36

[Daniel Holbert [:dholbert]]

Sure, makes sense. I've triggered lando; should be landing soon.

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/360f79d7cb6d
Let tooltips break in mid-word if required, so they don't get truncated. r=Gijs

Comment 38

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/360f79d7cb6d

Comment 40

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the initial issue with an affected build, Firefox 89.0a1 (20210410214333).
Verified fixed with 89.0b10 on Windows 10x64, macOS 11.3.1 and Ubuntu 18.04. The tooltips are displayed as expected using the attached test cases.