Created attachment 446861 [details] Simplified test case Page doesn't draw content if a <style> tag with a font @import is removed during the DOMContentLoaded event STEPS TO REPRODUCE: - Open the attached test.html file in Safari RESULTS: - Expect to see lines of text in sans-serif font - Actual: Text isn't painted at all NOTES: - It takes a few seconds, but the page is scrollable - Text can be selected and copied, even though it's not painted CONFIGURATION Safari 15.1 (17612.2.9.1.20) macOS 12.0.1 (21A559) MacBookPro18,1 (16" M1 Pro)
Confirmed that this reproduces in Safari, does not reproduce in Chrome. This is clearly a bug, and seems to have the workaround of "just don't do this". Could you please clarify if it's important in some way?
Sure, happy to give context. In an email client, when replying to certain messages (e.g. with Google fonts imports), the compose window's web view was drawing blank (this bug). When replying to or forwarding a message, the client takes the original message's text/html part, inserts it into a `<blockquote>`, and loads this into a `WKWebView`. During load, there is logic to inline styles resulting from `<style>` and `<link>` elements in the quoted text, and remove them from the DOM, so they don't impact the style of newly-typed text above the quote block. This is done as early as possible (e.g. during `DOMContentLoaded`) to avoid visual flicker. For now, I have deferred the removal of `<style>` elements with @imports until the `load` event fires, which works around this issue. However, it has the trade-off of seeing some possible "flicker" on screen because `<style>` element removal has been deferred. I haven't fully investigated if there are any other good approaches to solving this general style-inlining problem.
<rdar://problem/86661749>
This should now be fixed in STP 139, iOS 15.4 Beta, and macOS 12.3 Beta.