1491308 - Playlist content is misplaced on Youtube gaming

Status: NEW

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Anca Soncutean, Desktop QA]

[Affected versions]: 
- Fx 62.0
- Fx 63.0b6
- Fx 64.0a1 (2018-09-14)

[Affected platforms]:
- macOS 10.13
- Ubuntu 18.06 x64
- Windows 10 x32

[Steps to reproduce]:
1. Navigate to https://gaming.youtube.com/watch?v=JVmXlRnfsCE&list=PLiCvVJzBupKkChJstsIDcACZH2Q8K9zMm

[Expected result]:
- The Playlist content is properly aligned, no misplaced/cut off texts/thumbnails can be observed. 

[Actual result]:
- The Playlist content is not properly aligned and some  parts  of the texts/thumbnails are cut off.

[Regression range]: 
- I will determine one asap.

[Additional Notes]:
- See screenshots Chrome vs Firefox: https://drive.google.com/open?id=19UD8k6MqPj_cCItyejFRhz2a9ym38_es and https://drive.google.com/file/d/1Za0BCAw9_m0jgolTTRxyz1FSa1dJMmr7/view?usp=sharing .
- I could not see this behavior, other then inside the Playlist section.
- The size of the browser doesn’t seem to influence the wrongly displayed content.
- The functionality is not affected, once a link is clicked, the user is redirected to the corresponding video.

Comment 1

[Daniel Holbert [:dholbert]]

Thanks for the report!

Two observations:
 (1) Safari (version 11.1 on Mac OS X High Sierra) shows the same issues as Firefox.

 (1) Other gaming.youtube.com pages with a playlist are working fine, e.g. this one has no issues:
   https://gaming.youtube.com/watch?v=iT1l8Dcjb1Y&list=PLiCvVJzBupKnCI20Hybi7oNwiHB9ugFOU

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of same issues in Safari 11.1 in Mac OS X High Sierra (viewed via BrowserStack)

Comment 3

[Daniel Holbert [:dholbert]]

RE the two issues that I'm seeing:
 (1) I can work around the misalignment (content being pushed off the left side, e.g. for playlist entry #2 and #3) by using devtools to add "min-width: 0" to the div with class="style-scope ytg-playlist-panel-video-renderer".  I need to do a bit more investigation to determine whether this indicates a Firefox issue, or whether they're depending on buggy/nonstandard Chrome behavior.

 (2) The text vertical-clipping actually happens for me in Chrome, too (using "bleeding-edge" Chrome dev, version "70.0.3538.16 (Official Build) dev (64-bit)" if it happens to be a version-specific thing).  So that part is just a site bug, it seems.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot of vertical text clipping happening in Chrome, too

Comment 5

[Sean Voisen (:svoisen)]

Setting to P3 given likelihood that this is a site bug.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

So the main issue here (content being pushed off the left side) seems to be due to the interpretation of "word-break: keep-all" styling that they've got on the text there.

In Chrome, that styling prevents linebreaks between the Japanese characters, but allows breaking between Japanese punctuation -- in particular, between！,【, and 】.

In Firefox, (and Safari, I think?), we don't allow line-breaking between those punctuation characters.

Comment 7

[Daniel Holbert [:dholbert]]

It looks like "word-break: keep-all" is documented here:
https://drafts.csswg.org/css-text-3/#valdef-word-break-keep-all

Relevant quote:
> In this style, sequences of CJK characters do not break.

I believe '【' and '】' are CJK characters, according to this:
 https://www.fileformat.info/info/unicode/char/3010/index.htm
 https://www.fileformat.info/info/unicode/char/3011/index.htm
 "Block 	CJK Symbols and Punctuation"

So by the letter of the spec text that I quoted above, I think they would be considered to be part of a "sequence of CJK characters" and hence should not create breaking opportunities in a "word-break: keep-all" section.

jfkthame / xidorn, thoughts?

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

From the spec text, I think Chrome's behavior is correct. Specifically, the spec mentions[1]:
> Breaking is forbidden within “words”: implicit soft wrap opportunities between typographic letter units (or other typographic character units belonging to the NU, AL, AI, or ID Unicode line breaking classes [UAX14]) are suppressed, ... Otherwise this option is equivalent to normal.

And according to LineBreak.txt[2] in UCD, U+3010 and U+3011 belong to OP and CL line breaking classes correspondingly, so they are not part of characters where the soft wrap opportunities should be suppressed.

And given that otherwise it should be equivalent to normal, we should break between a CL and a OP.

But the spec text doesn't seem to be normative... so maybe we are both conformant, and I think Chrome's behavior is indeed better for this case.


[1] https://drafts.csswg.org/css-text-3/#valdef-word-break-keep-all
[2] https://www.unicode.org/Public/UCD/latest/ucd/LineBreak.txt

Comment 9

[Anca Soncutean, Desktop QA]

This issue is still reproducible in the latest Nightly build. I don't know how relevant it might be at this point, but I've tried to determine a regression range, it pointed out on the following pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b5d8b27a753725c1de41ffae2e338798f3b5cacd&tochange=b043233ec04f06768d59dcdfb9e928142280f3cc. Note, that the elements were still not perfectly aligned on before versions, but it was better.