Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HTML Documentation doesn't load locally-saved fonts in macOS Safari #98769

Closed
kadiwa4 opened this issue Jul 1, 2022 · 8 comments
Closed

HTML Documentation doesn't load locally-saved fonts in macOS Safari #98769

kadiwa4 opened this issue Jul 1, 2022 · 8 comments
Labels
A-rustdoc-ui Area: rustdoc UI (generated HTML) C-bug Category: This is a bug. O-macos Operating system: macOS T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@kadiwa4
Copy link
Contributor

kadiwa4 commented Jul 1, 2022 •
edited

When viewing locally-saved documentation (file:///), rustdoc's output website isn't able to load in any of the woff2 fonts. Since #96279 removed the woff versions of the fonts, the browser defaults to other fonts, and it turns out Times and Menlo don't look great in combination.
Update: since #115904 (1.75.0), the bold version of Source Serif 4 is now used.

Version: macOS 12.4 / Safari 15.5 (still an issue in 17.2.1)
Rust/Rustdoc version: 1.62.0, works fine on 1.61.0

Workaround script: https://gist.github.com/kadiwa4/8e81b820217fdb8d1fb70e2108d1a58d

Web console:

[Error] Origin null is not allowed by Access-Control-Allow-Origin. Status code: 0
[Error] Failed to load resource: Origin null is not allowed by Access-Control-Allow-Origin. Status code: 0 (SourceSerif4-Regular.ttf.woff2, line 0)

... (repeated for other woff2 fonts)
Screenshot 2023-12-31 at 17 49 45
@kadiwa4 kadiwa4 added the C-bug Category: This is a bug. label Jul 1, 2022
@rustbot rustbot added A-rustdoc-ui Area: rustdoc UI (generated HTML) T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jul 1, 2022
@jsha
Copy link
Contributor

jsha commented Jul 5, 2022

Thanks for the report! That's strange - I could imagine reasons why Safari might refuse to load fonts, but I can't think of why it would affect both woff and woff2.

Since I don't have a Safari handy at the moment, could you do me a favor - check what happens if you remove the <link rel="preload"... tags at the beginning of the document? Preloading interacts in interesting ways with CORS; and the preloads are sometimes rejected when viewing file:// URLs. I'm wondering if the rejected preload prevents Safari from later loading the font the regular way. In this theory, fallback to the woff files might have been masking the problem.

@kadiwa4
Copy link
Contributor Author

kadiwa4 commented Jul 5, 2022 •
edited

To clarify: woff files work just fine (even in combination with woff2 files), but they aren't shipped with rustdoc anymore.

Indeed, removing the <link>s you mentioned gets the fonts to work again! As soon as it encounters one of those elements, it seems to "curse" that specific browser tab (it refuses to load the woff2 files ever again in that tab).

@jsha
Copy link
Contributor

jsha commented Jul 6, 2022

Thanks for testing that! That confirms my suspicion: the problem isn't woff vs woff2, but that the <link rel="preload" ...> causes Safari to load the woff2 font with the crossorigin attribute, which is needed for preloading fonts. But crossorigin doesn't really make sense for local files (file:/// URLs). On Chrome and Firefox, when loading file:/// URLs the preload just gets ignored, and when the CSS later gets loaded, the font is loaded from there without any CORS properties.

But I'm guessing on Safari something different is happening: the first fetch "poisons" the URL as you say, so even once the CSS is loaded, Safari's attempt to load that font URL fails. This worked when there was also a .woff file in the CSS, because the .woff file wasn't preloaded and so wasn't poisoned.

I think this is a bug in Safari and it would be good to file it and get it fixed.

Working around the bug in rustdoc could mean putting a small block of inline JS in the <head> that document.write(..)s the preload links only if the URL is not file:///. I would also be fine with temporarily reverting #96279 as a workaround.

@kadiwa4
Copy link
Contributor Author

kadiwa4 commented Jan 2, 2023

WebKit issue: https://bugs.webkit.org/show_bug.cgi?id=249887

@notriddle notriddle mentioned this issue Dec 22, 2023
Open
@jsha
Copy link
Contributor

jsha commented Jan 8, 2024

Clarifying question: according to #85444 I would expect the Safari experience to be even worse than this, with no CSS loaded it all. Do you perhaps have the Develop menu enabled?

@notriddle
Copy link
Contributor

I have the Develop menu enabled. @kadiwa4 do you?

@kadiwa4
Copy link
Contributor Author

kadiwa4 commented Jan 8, 2024

@jsha @notriddle Yes, I have it enabled

@fmease fmease added the O-macos Operating system: macOS label Jan 16, 2024
@rjeli rjeli mentioned this issue Mar 12, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 13, 2024
@matthiaskrgr
Rollup merge of rust-lang#122410 - rjeli:rustdoc-no-local-font-preloa…
62e9e46 
…d, r=notriddle

rustdoc: do not preload fonts when browsing locally

First PR, please let me know if I'm doing anything wrong.

As noted in rust-lang#98769, currently `cargo doc --open` on macOS/Safari (17.2.1) doesn't load fonts due to a CORS issue. (webkit issue [here](https://bugs.webkit.org/show_bug.cgi?id=249887)). This patch moves the font preloads inside a js if statement as suggested in the GitHub issue.

I tried something more elegant with iterating over a tera array of fonts, but ran into issues, so here's the dumb fix. Only thing to note is that the font path is interpolated into a template string, so HTML escaping works fine, but it will break if there's a backtick or `${` in the font path. Not sure if this is a big deal.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 13, 2024
@rust-timer
Unrolled build for rust-lang#122410
1aafe5e 
Rollup merge of rust-lang#122410 - rjeli:rustdoc-no-local-font-preload, r=notriddle

rustdoc: do not preload fonts when browsing locally

First PR, please let me know if I'm doing anything wrong.

As noted in rust-lang#98769, currently `cargo doc --open` on macOS/Safari (17.2.1) doesn't load fonts due to a CORS issue. (webkit issue [here](https://bugs.webkit.org/show_bug.cgi?id=249887)). This patch moves the font preloads inside a js if statement as suggested in the GitHub issue.

I tried something more elegant with iterating over a tera array of fonts, but ran into issues, so here's the dumb fix. Only thing to note is that the font path is interpolated into a template string, so HTML escaping works fine, but it will break if there's a backtick or `${` in the font path. Not sure if this is a big deal.
@kadiwa4
Copy link
Contributor Author

kadiwa4 commented Mar 14, 2024

#122410 fixes the issue for everyone who has dev tools enabled.

Issue #85444 is used to find a solution for the general case (with or without dev tools enabled).

@kadiwa4 kadiwa4 closed this as completed Mar 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-rustdoc-ui Area: rustdoc UI (generated HTML) C-bug Category: This is a bug. O-macos Operating system: macOS T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jsha @notriddle @fmease @kadiwa4 @rustbot