871224 - negative margin-right on inline leads to wrapping of text, in a shrink-wrap block (if the text is wrappable, via having multiple words or "word-wrap: break-word")

Status: RESOLVED INVALID

(Core :: Layout: Block and Inline, defect)

Description

[Amaury]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130409194949

Steps to reproduce:

This is an issue on all versions, I believe, so I'm putting the version as "unspecified." However, I noticed it when a forum I'm on moved from vBulletin to XenForo on August 15, 2012, so whatever Mozilla Firefox version was out then is when I noticed it. (My update history is only going as far back as 16.0.1 from October 18, 2012, so I can't check what version it was back then.)

Table BB code isn't native to XenForo, so unlike on vBulletin, you can't customize things easily or even customize things at all, such as width. So, because of that, tables have an auto-width feature.

The issue is that Mozilla Firefox chooses a width less than what it needs to be and therefore the text wraps instead of being all on one line. This is *not* an issue on Google Chrome or Internet Explorer, only on Mozilla Firefox, so it has to be an issue with Mozilla Firefox's coding somewhere, I would guess.

This is where I originally brought it up: http://kh-vids.net/threads/table-code-problems.135501/

I basically just summed it all up, but you can go to page two in the link above and read all the posts for more detail.


Actual results:

Mozilla Firefox decides on a width less than what the tables need, making the text wrap, as seen here:
http://i101.photobucket.com/albums/m62/AmauryGarcia/TableMozillaFirefox_zps61bc1d08.png


Expected results:

It should look like this.

Google Chrome:
http://i101.photobucket.com/albums/m62/AmauryGarcia/TableGoogleChrome_zps825d3222.png

Internet Explorer:
http://i101.photobucket.com/albums/m62/AmauryGarcia/TableInternetExplorer_zps2f473e43.png

Comment 1

[Manuela Muntean [Away]]

Could you please try the following, to see if you still reproduce the issue :

1) try this with a clean profile: http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

2) running in Safe mode: http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 2

[Amaury]

Thank you for responding, Manuela. =)

I have tried both options, and the issue is still there.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Amaury, can you link to a page with the actual HTML in question?

Comment 4

[Amaury]

Technically, it's anywhere I post, but here's a post of mine with the table in my signature: http://kh-vids.net/threads/background-issue-with-prefixes.139134/#post-4058438

Hope this can help. =)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Thanks, that does help.  The issue is that the <a> has negative margins which cause the cell to not be wide enough for the text; when we see that, plus the "word-wrap: break-word", we break the text to make it fit.  I'll attach a minimal testcase.  Note that Chrome doesn't wrap the text in that testcase in spite of it clearly not fitting inside the block; presumably they are counting the negative right-margin as part of the text for width calculations....

As far as I can tell, CSS doesn't actually define behavior here, just like it doesn't define line-breaking in general.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 7

[Amaury]

Internet Explorer does the same thing as Google Chrome, I would assume, if it's also not an issue on there.

But yeah. I'm not sure if you clicked my other tabs or not in the link I provided above (Current Forum Projects, etc.), but if you did, you saw how text like "Amaury's Gaming & YouTube Timeline" wrapped, but if you look at it on GC or IE, it's all on one line. I also found it funny how Facebook on MF, despite being one word, had the "K" wrap.

Anyway, thanks for taking the time to reply; I hope to see this resolved soon. I've also got another bug to report, but I'm going to wait until the end of the week to report it. I don't want to overload you guys, and since I'm new here, I don't know if there's some limit on how many bugs can be reported in a certain time frame.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Amaury, have you looked at the testcase I attached?  as far as I can tell, the behavior of Chrome (and perhaps IE; I haven't tested it on my testcase) here is arguably wrong: it's not wrapping text that is in fact overflowing.

The reason the one "k" wrapped is that the site explicitly styles everything with "word-wrap: break-word", which means wrapping is allowed at any point in a word.

There's no limit on bug reports; just report bugs if you have them.  ;)

Comment 9

[Amaury]

Yes, I did. It's on two different lines. I'm assuming you're saying that's correct behavior?

So it's how they have the forum styled that's the issue? Is this even a bug, then, or not?

I'm slightly confused, though, because I even looked at it on Opera, and it wasn't wrapping there, either. That's why I assumed it was an issue with MF if out of the four browsers total I looked at (MF, GC, IE, and Opera), it was only an issue on MF.

Regarding overflowing, wouldn't it be obvious? Like text going outside of the tables? Or is it invisible overflow? But XenForo tables' width can't be changed like they can on vBulletin because they're not native to the software, so they have an auto-width feature. I can up the width on vBulletin to fit things on one line -- see my signature here (http://www.kh-mediaflare.net/showthread.php?96-Spam-Sector-Guidelines), for example, where I have the width set to 250px for the Social Networks table and 450px for the Current Forum Projects table. XenForo's auto-width table feature essentially does just that -- automatically sets it to width where the text will be all on one line -- but without the user having to mess with the pixels until they get their desired width. So how exactly is that an issue with overflow on GC, IE, Opera, and whatever other browser doesn't have this "issue"? That's where my confusion comes in.

Are you saying that if KH-Vids were to remove "word-wrap: break-word," then the issue would disappear and everything would be on one line due to the auto-width feature, but without invisibly overflowing?

Ah, thanks. I'll report it either in a little while (currently 9:32 PM) or tomorrow.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> I'm assuming you're saying that's correct behavior?

I'm saying it seems like perfectly fine behavior per spec and given the markup.  Unfortunately, the spec does not define the exact behavior of this markup as far as I can tell, so it could be argued that Chrome's behavior is fine too.  But what I meant was whether you'd looked at the testcase in Chrome.

> Regarding overflowing, wouldn't it be obvious?

Do try my testcase in Chrome.

On the actual site the overflow is only by about 2px (they use a -3px right margin) so it's not that obvious.

> Are you saying that if KH-Vids were to remove "word-wrap: break-word," then the issue
> would disappear

Yes, because then we'd just end up with the text overflowing by those 2px and all being on one line.

Comment 11

[Amaury]

MF testcase: http://i101.photobucket.com/albums/m62/AmauryGarcia/TextMF_zps564cc429.png
GC testcase: http://i101.photobucket.com/albums/m62/AmauryGarcia/TextGC_zpsa00f9a26.png

I'd suggest making the behavior like Google Chrome's so it works like on there and text doesn't wrap, but you probably don't want to do that, haha.

Anyway, I'll bring it up on there and see what they say.

Thanks for the input again.

Comment 12

[Amaury]

An admin fixed it: http://kh-vids.net/threads/table-code-problems.135501/page-3#post-4059052

Other things are still being put on separate lines from Mozilla Firefox's coding now, as far as I know, but Facebook is now on one line as will any future single words I use. =)

Comment 13

[Amaury]

I forgot to mention that while previewing things like my signature, everything appears on one line, just now on posts.

Comment 14

[Amaury]

not*

And now that I think about it, it may have to do with the postbit width.

PS: Sorry for the consecutive comments.

Comment 15

[Amaury]

Hello again.

As I previously stated, while the issue with single words, such as Facebook, disappeared, it's still putting things on separate lines. You said removing that code, which she essentially did, would fix that -- unless I misunderstood you.

Start reading from here: http://kh-vids.net/threads/table-code-problems.135501/page-3

If you look at my "Premium Primetimes" tab on Mozilla Firefox, for example, you'll see how starting with "Premium Primetime III," it starts line-breaking (or wrapping, as it's commonly called); even if I shorten it to "PPT III," it still wraps for some odd reason. If I do like "Premium Primetime 1," "Premium Primetime 2," etc., then the numbers just go down on the next line.

Now that she modified "word-wrap: break-word" to default behavior, essentially the same as removing it, I wonder if part of the issue is indeed with Mozilla Firefox, or is it still correct behavior? Like I said, I may have misunderstood you.

Thanks in advance for a reply.

Comment 16

[Boris Zbarsky [:bzbarsky]]

You misunderstood.

The break-word is what allowed wrapping at random spots between words.

The fact that the site makes the table-cells too narrow for the text is what causes the text to break if there is a valid break opportunity.

Comment 17

[Amaury]

Thank you, Boris! I understand now.

Read this latest post here, also: http://kh-vids.net/threads/table-code-problems.135501/page-3#post-4059246

The reason it's still not the result "I want" is because Mozilla Firefox interprets it differently, but it's not "wrong," which you previously stated.

Comment 18

[Amaury]

Oops. Didn't mean to submit. (And I wish we could edit comments.)

The issue lies in the hands of XenForo now hopefully updating table functionality soon.

You can close this issue now. =)

Comment 19

[cujyaz]

Attachment: testcase

I think this *is* a bug in Mozilla. Why should a negative right margin behave different to a negative left margin? It also overflows a following like a preceding inline box, why shouldn't it overflow the parent's right content edge as it does overflow its left content edge?

Also, it can be useful. Suppose this CSS as in my testcase:

span:hover { padding: .25em .5em; margin: 0 -.5em; background: #ff8 }

If the behavior were correct to wrap the line, then there's still a bug in the shrink-to-fit implementation, as the parent box actually doesn't shrink. A box with width: max-content also wraps.

The testcase includes -webkit- prefixes to compare with Chrome (and also unprefixed versions). I think Chrome is correct here.

Comment 20

[Karl Dubost💡 :karlcow]

Attachment: firefox, safari, chrome

Using the test-case above
https://bug871224.bmoattachments.org/attachment.cgi?id=749633

Firefox, Safari, Chrome latest versions from top to bottom.
Firefox: the text stays in the box.
Chrome/WebKit: text goes out.

Comment 21

[Daniel Holbert [:dholbert]]

Note: word-wrap:break-word probably isn't particularly relevant here; it simply creates linebreak opportunities. You can trigger the same bug with a sentence that includes spaces (which also create linebreak opportunities), too, as in testcases for some upcoming bugs that I'll be duping here.

--> adjusting bug summary to soften the importance of word-wrap:break-word

Comment 26

[Daniel Holbert [:dholbert]]

--> copying Webcompat Priority: revisit field from dupe bug 1476925 and bug 1406116.

Comment 27

[Daniel Holbert [:dholbert]]

Argh, sorry -- it actually looks like this is indeed different from the dupes. Namely:
(1) in the testcases here, Chrome actually matches our rendering now! (e.g. in the first testcase, Sometexthere ends up wrapping midword in Chrome, just like it does in Firefox. And in the second more-complex testcase (from comment 19), Chrome looks just like Firefox as well as far as I can tell (linewrapping/shrinkwrapping in exactly the same places)

(2) The dupe bugs have padding-right which is now what's responsible for the Chrome/Firefox difference in their testcases.

I'll undupe the dupes, and close this bug as INVALID (since per comment 10, our behavior is fine per spec, and webcompat now seems to depend on it).

The Chrome version that I'm testing is Chrome 82.0.4068.4 (Official Build) dev (64-bit), FWIW.

Comment 28

[Daniel Holbert [:dholbert]]

(Cleaned up the dupes. Bug 1406116 is still legitimately a dupe of this one.)