WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 2 weeks ago

#49066 closed defect (bug) (reported-upstream)

Twenty Twenty: Font characters rendered as symbols

Reported by: pikta Owned by:
Milestone: Priority: normal
Severity: critical Version: 5.3
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

Twenty Twenty theme fonts showed as symbols. It only happens to the Mac computer(s) with the Chrome browser.

Chrome Version 79.0.3945.88 (Official Build) (64-bit)
Mac OS Catalina 10.15.2

Here is the page that has the original fonts: https://brunosautoinc.com/privacy

I manually changed fonts on other pages so the content is readable.

Change History (6)

#1 @SergeyBiryukov
9 months ago

  • Summary changed from Twenty Twenty to Twenty Twenty: Font characters rendered as symbols

Hi there, welcome to WordPress Trac! Thanks for the report.

Just noting it's an issue with Chrome 79.0.3945.88 that's being tracked here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1036250

#2 @ianbelanger
9 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed
  • Version changed from 5.3.2 to 5.3

Since this a chrome issue and not a Twenty Twenty issue I am closing as invalid.

#3 @SergeyBiryukov
9 months ago

#49191 was marked as a duplicate.

This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.


8 months ago

#5 @jemcbade
8 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

@ianbelanger All due respect here and I and not intending any ill will with my comment ok? Take note that this occurs in one of my test environments using Twentynineteen as well. I own more than one MAC OS based device.

I'm trying to understand your reasoning for marking this ticket invalid. As a person trained in QA, in our department your reason for closing the ticket and marking it invalid would not be accepted.

As developers we must test in all environments and although it might not be our responsibility to fix components responsible, we are required to perform due diligence to the best of our ability to discern the reason for an incompatibility. Very curious here, what tests other than observing that this is a Chrome issue on SOME MACS using Catalina and Chrome (but not all BTW) have you performed?

I'm sorry if this sounds harsh, but MANY of us as developers must test on all browsers and OSs if we are doing our job so the issue here is not one I feel deserves just turning a blind eye to and finger pointing. The fact that this issue is occurring effects those of us trying to develop using WordPress in a very critical way.

I request you re-open the ticket and do some testing. Let's all work as a community combining our skills to solve problems.

I will do my part and if I can discern the reason for this issue I will share it with the rest of the WP community.

#6 @desrosj
2 weeks ago

  • Resolution set to reported-upstream
  • Status changed from reopened to closed

Just wanted to note that invalid is the "catch all" default resolution in this Trac instance that is unfortunately named. It sometimes can be quite harsh and inapporpiate, especially when an issue is totally valid but there are just no actions that can be taken within the WordPress Core software. Moving forward, there is an active proposal to change invalid to use more appropriate and less offensive terminology.

Reading through the discussion on the previously linked Chromium ticket, it seems that there was both a change in the macOS API as well as a change in Chrome's routine to match typefaces that was causing this issue in Chrome 79. There was a lot of difficulty reproducing the issue reliably, which makes it difficult to pinpoint the exact change that needs to be made.

According to the last comment on that ticket, it also seems completely unreproducible on Chrome 80 (which was publicly released on February 4, 2020). Chrome is now on version 85 and the Chromium ticket remains closed as fixed without any additional reports about of this problem.

With all this in mind, closing this ticket in favor of the Chromium one was the correct action (though the reported-upstream resolution may have been a bit better), especially when 2-3 experienced WordPress contributors were taking the time to test and follow the discussion on that ticket. I hope this you helps understand the process that was followed @jemcbade.

If anyone is still experiencing this issue, please add additional details to the Chromium ticket so that their team can investigate further.

Note: See TracTickets for help on using tickets.