Closed Bug 1455638 Opened 6 years ago Closed 6 years ago

The text is incorrectly displayed

Categories

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

61 Branch
Unspecified
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox60 --- wontfix
firefox61 --- affected

People

(Reporter: daschilean, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached image different-text.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0a1
Build ID: 20180419224145

[Affected versions]:
Nightly 61.0a1

[Affected Platforms]:
Ubuntu 16.04 x64, Windows 10 x64

[Steps to reproduce]:
1. Open the site: https://www.axis-praxis.org/specimens/pappardelle
 
[Expected result]:
The text should be displayed as in Chrome.

[Actual result]:
The text is different displayed.
Blocks: 1302685
WFM on both Win10 and Ubuntu. Are you running on a fully up-to-date Win10 system (Fall Creators Update)? Do you have an updated FreeType (e.g. 2.8.1) on Ubuntu? The standard distro version on 16.04 is too old.

(What's the state of the layout.css.font-variations.enabled pref?)
Both systems are up to date (FreeType 2.8.1 for Ubuntu and the latest update for Win10).

Using the latest Nightly 61.0a1(2018-04-22) the issue is reproducible only for ~2 seconds when the webpage is loaded for the first time in a tab (please see the attached screencast)

The issue is reproducible also with "layout.css.font-variations.enabled"=False.
Attached video 2018-04-23_10h48_45.mp4
(In reply to roxana.leitan@softvision.ro from comment #3)
> Created attachment 8970142 [details]
> 2018-04-23_10h48_45.mp4

This looks like normal behavior if a font resource is a bit slow to load; a fallback may be displayed until the downloadable font becomes available.
Is there something we need to look into further here, or was this only about the rendering of a fallback font when the webfont hasn't yet loaded? (In which case we should just close it, as that's expected behavior.)
Flags: needinfo?(daniel.aschilean)
I think we should close this one as Resolved WFM since on the latest Nightly 62.0a1 on Windows 10 x64 and Ubuntu 16.04 x64 I reproduced the behavior described in comment 2 and confirmed in comment 4 as expected.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(daniel.aschilean)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: