WebKit Quirks • Hacker News Board

Re: WebKit Quirks

#11

Post by matsemann » Wed, Feb 17, 2021, 1:26 PM UTC

    shouldBypassBackForwardCache()
    // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS.
    // We started caching such content in r250437 but the Google Docs index page unfortunately is not currently compatible
    // because it puts an overlay (with class "docs-homescreen-freeze-el-full") over the page when navigating away and fails
    // to remove it when coming back from the back/forward cache

Millions of pages have this bug, because of Safari's broken navigation. Nice that the big players get the browser to fix it for them. For instance, a common issue is you click a button that becomes disabled and shows a spinner while working, before forwarding to a new page. If you click back from the new page, Safari will render the previous page exactly as it was when leaving, so in a broken loading state (instead of starting it from scratch).

Re: WebKit Quirks

#12

Post by m_eiman » Wed, Feb 17, 2021, 1:31 PM UTC

matsemann wrote: post #11

shouldBypassBackForwardCache() // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. // We started caching such content in r250437 but the Google Docs index page unfortunately is not currently compatible // because it puts an overlay (with class "docs-homescreen-freeze-el-full") over the page when navigating away and fails // to remove it when coming back from the back/…

Why shouldn't it show it in the same state? Seems like a reasonable thing to do.

Re: WebKit Quirks

#13

Post by matsemann » Wed, Feb 17, 2021, 1:39 PM UTC

m_eiman wrote: post #12

matsemann wrote: post #11

shouldBypassBackForwardCache() // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. // We started caching such content in r250437 but the Google Docs index page unfortunately is not currently compatible // because it puts an overlay (with class "docs-homescreen-freeze-el-full") over the page when navigating away and fails // to remove it when coming back from the back/…

Why shouldn't it show it in the same state? Seems like a reasonable thing to do.

If it was a static page, then sure. But for dynamic pages or SPAs it more often than not leads to going back to a page in a broken state. Other browsers have better heuristics for when this cache is used. So Safari's behavior is unexpected, even so that the big guys are taken by surprise it seems. I don't really mind either way, the main thing is that it's inconsistent.

It's not a huge deal, but it's just one of many small things making Safari annoying when developing. Especially since it cannot be tested without owning an Apple device.

Re: WebKit Quirks

#14

Post by jaywalk » Wed, Feb 17, 2021, 1:52 PM UTC

Interesting to see www.icloud.com in there...

Re: WebKit Quirks

#15

Post by theXspidy » Wed, Feb 17, 2021, 1:56 PM UTC

https://thesnippets.substack.com/p/bitcoin-surges-past-51000...

Re: WebKit Quirks

#16

Post by TazeTSchnitzel » Wed, Feb 17, 2021, 2:05 PM UTC

Anyone who's read a few Old New Thing posts would know that Windows must be full of similar checks.

Re: WebKit Quirks

#17

Post by dastx » Wed, Feb 17, 2021, 2:11 PM UTC

robin_reala wrote: post #3

sdflhasjd wrote: post #2

Domain name specific quirks? What in the world...

Oh, WebKit are absolutely not the only people doing this. Opera used to with their Presto engine, and I’m pretty sure I’ve seen a similar list in Gecko, though I can’t find it now. At the end of the day, this is the only way that non-Chrome browsers can meet Google’s hegemony, unless they give up and adopt Chromium itself. The opportunity cost of switching is too low for browser manufacturers no to have these workaro…

> At the end of the day, this is the only way that non-Chrome browsers can meet Google’s hegemony

Except these quirks include a whole lot more than just Google. Some of the domains in there:

1. nytimes

2. twitter

3. ralphlauren

4. baidu

5. warbyparker

6. nfl

7. gizmodo

8. microsoft

I'm not sure what each different piece of code does but there is many more domains in there.

Re: WebKit Quirks

#18

Post by timw4mail » Wed, Feb 17, 2021, 2:17 PM UTC

matsemann wrote: post #13

m_eiman wrote: post #12

Earlier quoted context omitted.

Why shouldn't it show it in the same state? Seems like a reasonable thing to do.

If it was a static page, then sure. But for dynamic pages or SPAs it more often than not leads to going back to a page in a broken state. Other browsers have better heuristics for when this cache is used. So Safari's behavior is unexpected, even so that the big guys are taken by surprise it seems. I don't really mind either way, the main thing is that it's inconsistent. It's not a huge deal, but it's just one of many…

Sounds more like an issue with the web apps to me.

Re: WebKit Quirks

#19

Post by tholman » Wed, Feb 17, 2021, 2:17 PM UTC

If I'm understanding L958+ [1] There's a hyper specific css class browser quirk because the login button for gizmodo/kotaku/etc's CMS's svg icon click event wasn't firing... and here I am fixing my day-to-day browser bugs like a chump

[1] https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...

Re: WebKit Quirks

#20

Post by duckerude » Wed, Feb 17, 2021, 2:17 PM UTC

> domain.endsWith("hulu.com")

Huh, does that mean it would also apply on "thisisnothulu.com"?

Most other endsWith calls seem to do e.g. `domain.endsWith(".hulu.com")` to only match subdomains.