1427480 - Netflix subtitles are given a larger font-size in Linux

Status: VERIFIED FIXED

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

Description

[Jean-Yves Avenard [:jya]]

Attachment: Screenshot-2017-12-31 Netflix.jpg

Playing https://www.netflix.com/watch/70177954?trackId=14170286&tctx=1%2C0%2C39fd9717-784a-4662-a262-479f99095c29-33072685 with subtitles on

The subtitles are way bigger than they should be taking a third of the viewing area.

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

A webvtt issue?

Comment 2

[Benjamin Chen [:bechen]]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #1)
> A webvtt issue?

No, the website doesn't display the subtitle through webvtt.

Comment 3

[Blake Wu [:bwu][:blakewu]]

I cannot repro this bug on my Dell windows laptop with the latest nightly (today). 
Jya, 
Which machine and what version of Firefox you used to see this problem?

Comment 4

[Jean-Yves Avenard [:jya]]

This is on linux as per platform.

Comment 5

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

If anyone else wants to repro: frame from screenshot is at about 1:04 (44:44 left).

I see different sub sizes depending on OS, though even on Linux where my subs are comparatively large, it's not as stated as in the original shot.

Relevant html and blurb:

This div is used to contain further elements that hold the subtitles. For the same player size it behaves similarly on Windows and Linux:
<div class="player-timedtext" style="position: absolute; left: 666px; top: 0px; right: 666px; bottom: 0px; display: block; direction: ltr;">

For the first subtitle line there is another div, which appears to behave similarly on Windows and Linux for the same player size (I see slight differences, don't think they're relevant):
<div style="display: block; white-space: nowrap; text-align: left; position: absolute; left: 17.5%; top: 77.3532%;" class="player-timedtext-text-container">

Inside that div is a span. Here I see a difference in the font-size used depending on OS.

Windows (with controls hidden):

<span style="font-size:56px;line-height:normal;font-weight:normal;color:#ffffff;text-shadow:#000000 0px 0px 7px;font-family:Consolas,Lucida Console,Menlo,Monaco,Arial,Helvetica;font-weight:bolder">No, no, no wait a minute.</span>

Linux (with controls hidden):

<span style="font-size:75px;line-height:normal;font-weight:normal;color:#ffffff;text-shadow:#000000 0px 0px 7px;font-family:Consolas,Lucida Console,Menlo,Monaco,Arial,Helvetica;font-weight:bolder">No, no, no wait a minute.</span>

The font-sizes differ depending on the size of the player, but are always larger in Linux for the same sized player.

For Chromium, both Windows and Linux end up with the same font-size, which is the same as we have on Windows.

Not my area of expertise. Figure there's some JS here setting the font size? Figure this is either layout (if its on our end), or Netflix's JS.

I'm going to move this to layout based on the above.

Comment 6

[Xidorn Quan [:xidorn] UTC+11]

If it is that the font-size provided by the site is different, then it's probably Tech Evangelism.

Comment 7

[Karl Dubost💡 :karlcow]

If you still have a netflix account.
If not we can probably contact them directly.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

I have emailed Netflix and asked whether they can look into this.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

This seems to only affect machines which are booted with 4K monitors. I can only repro the issue on my Fedora 27 workstation if I've booted with a 4K monitor. If I attach a 1080p monitor, I do not see the issue.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Minimized test case

STR:
* Load test case in Firefox on Linux with Gnome's "Scale for menu and title bars" (Ubuntu < 17.10, or other earlier Gnome based system) or "Devices>Display>Scale" (Ubuntu 17.10 and later) setting set to > 100%.
* Load test case in Chrome, observe that in Firefox the text is larger.

If you set the system font scaling to 100%, Firefox renders the text only slightly larger than Chrome.

So we're scaling something here by the system scale factor and Chrome isn't, or vice versa.

Note: you may need to re-login or restart your X session to see the effect of changing the font scale.

I've also seen this on Fedora 27 as well.

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

Lee: Are you able to look into why the testcase above renders different sized text on Linux in Firefox vs Chrome? It seems we're scaling by Gnome's scale factor, and Chrome is't or somesuch.

Comment 12

[Lee Salzman [:lsalzman]]

Chris, does mucking with the layout.css.devPixelsPerPx pref alleviate this for you? Just as a sanity test to verify the problem is at least coming from that area...

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

Lee: Setting layout.css.devPixelsPerPx to 1.0 in Nightly alleviates this for me (but makes the rest of my UI look too small).

Comment 14

[Jonathan Kew [:jfkthame]]

What you're running into here is the fact that the used font size in cairo-ft-font is clamped to a maximum of 1000 (device pixels):

https://searchfox.org/mozilla-central/rev/877c99c523a054419ec964d4dfb3f0cadac9d497/gfx/cairo/cairo/src/cairo-ft-font.c#106

So when the code tries to use an element with font-size:1000px to measure some text, and devicePixelRatio > 1.0, we end up measuring with a smaller size (e.g. 667px if devicePixelRatio is 1.5, etc), and this results in calculating a larger font-size to apply to the actual visible element.

Given that this is in cairo-ft-font, it only affects Linux and Android, not Windows or Mac.

(Note, though, that on any platform, a similar problem would arise if you had a configuration with devicePixelRatio > 2.0, because we clamp the used font size in gfxFontStyle to a maximum of 2000 (device) pixels:

https://searchfox.org/mozilla-central/rev/877c99c523a054419ec964d4dfb3f0cadac9d497/gfx/thebes/gfxFont.h#55)

The cairo-ft-font limit was introduced in bug 322345 to avoid what appears to have been a FreeType bug. However, it looks like the specific limit of 1000 pixels was just an arbitrary figure; and it also looks like the underlying bug has been fixed in FT for a decade or more at this point. As such, I think we could safely relax this limit, at least bumping it to 2000 to match the limit we're imposing in gfxFont.

I suspect it might be safe to completely remove these limits, or at least raise them significantly further -- e.g. by an order of magnitude -- but that would need more testing across all platforms, in case it might expose weaknesses in one or other of the platform rasterizers. So I suggest we start by taking a conservative fix here to mitigate the immediate problem.

Comment 15

[Jonathan Kew [:jfkthame]]

Attachment: Increase the MAX_FONT_SIZE limit applied in cairo_ft_font to match the gfxFont size limit

This is a conservative tweak to mitigate the problem here, but without completely removing the used font-size limit (although that might well be safe these days), as described above.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/74ffac5bc156
Increase the MAX_FONT_SIZE limit applied in cairo_ft_font to match the gfxFont size limit. r=lsalzman

Comment 17

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/74ffac5bc156

Comment 18

[Lee Salzman [:lsalzman]]

Jonathan, should we uplift this to beta to make sure it gets into ESR? Should be pretty harmless, right?

Comment 19

[Jonathan Kew [:jfkthame]]

Probably a good idea, yes. I guess the patch should be in the latest Nightly by now; Jean-Yves, can you confirm it fixes the problem on Netflix for you?

Comment 20

[Jean-Yves Avenard [:jya]]

yes, looks good now, tested on both a normal and 4K laptop ..

Comment 21

[Jonathan Kew [:jfkthame]]

Comment on attachment 8960701 [details] [diff] [review]
Increase the MAX_FONT_SIZE limit applied in cairo_ft_font to match the gfxFont size limit

Thanks, :jya. Given that it can affect a top-usage site (netflix), and is such a trivial fix, I think we should take this in beta to get it out sooner.


Approval Request Comment
[Feature/Bug causing the regression]: Not really a regression, an arbitrary implementation limit that affects netflix code on hidpi Linux systems. (Originates with code landed in bug 322345, fwiw.)

[User impact if declined]: Possibility of oversized subtitling on netflix for Linux/hidpi users.

[Is this code covered by automated tests?]: no

[Has the fix been verified in Nightly?]: yes

[Needs manual test from QE? If yes, steps to reproduce]: no

[List of other uplifts needed for the feature/fix]: none

[Is the change risky?]: no

[Why is the change risky/not risky?]: Trivial fix for overly-conservative clamping of font-size within cairo (now matches limit used elsewhere in gfx).

[String changes made/needed]: none

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8960701 [details] [diff] [review]
Increase the MAX_FONT_SIZE limit applied in cairo_ft_font to match the gfxFont size limit

Low-risk fix for font sizing issues which can affect major sites. Approved for 60.0b11.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4aee8de5790b