234193 2021-12-10 21:40:44 -0800 Page doesn't draw content if a <style> tag with a Google Fonts @import rule is removed during the DOMContentLoaded event 2022-02-12 18:58:24 -0800 1 1 1 Unclassified WebKit Text Safari 15 Mac (Apple Silicon) macOS 12 RESOLVED CONFIGURATION CHANGED InRadar P2 Normal --- 1 neil webkit-unassigned bfulgham mitz mmaxfield webkit-bug-importer oldest_to_newest 1823165 0 446861 neil 2021-12-10 21:40:44 -0800 Created attachment 446861 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) 1823597 1 ap 2021-12-13 10:20:21 -0800 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? 1823632 2 neil 2021-12-13 10:57:05 -0800 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. 1825306 3 webkit-bug-importer 2021-12-17 21:41:18 -0800 <rdar://problem/86661749> 1840788 4 bfulgham 2022-02-12 18:58:24 -0800 This should now be fixed in STP 139, iOS 15.4 Beta, and macOS 12.3 Beta. 446861 2021-12-10 21:40:44 -0800 2021-12-10 21:40:44 -0800 Simplified test case test.html text/html 620 neil PGh0bWw+Cgk8aGVhZD4KCQk8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CgkJCS8vIFdp dGggdGhpcyBET01Db250ZW50TG9hZGVkIGxpc3RlbmVyLCB0aGUgcGFnZSB3aWxsIG5vdCBwYWlu dC4KCQkJLy8gTm90ZTogSWYgc3dpdGNoZWQgdG8gdGhlIHdpbmRvdydzICJsb2FkIiBldmVudCwg dGhlIHBhZ2UgcGFpbnRzIGZpbmUuCgkJCWRvY3VtZW50LmFkZEV2ZW50TGlzdGVuZXIoIkRPTUNv bnRlbnRMb2FkZWQiLCAoKSA9PiB7CgkJCQlkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCJzdHlsZSIp LnJlbW92ZSgpOwoJCQl9KTsKCQk8L3NjcmlwdD4KCQk8c3R5bGUgdHlwZT0idGV4dC9jc3MiPgoJ CQlAaW1wb3J0IHVybChodHRwczovL2ZvbnRzLmdvb2dsZWFwaXMuY29tL2Nzcz9mYW1pbHk9T3Bl bitTYW5zOjMwMCw0MDAsNTAwLDYwMCw3MDApOwoJCTwvc3R5bGU+Cgk8L2hlYWQ+CgoJPGJvZHkg c3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtPcGVuIFNhbnMmcXVvdDssIHNhbnMtc2VyaWY7Ij4K CQlUZXN0PGJyPlRlc3Q8YnI+VGVzdDxicj5UZXN0PGJyPlRlc3Q8YnI+VGVzdDxicj5UZXN0PGJy PlRlc3Q8YnI+VGVzdDxicj5UZXN0PGJyPlRlc3Q8YnI+Cgk8L2JvZHk+CjwvaHRtbD4=