Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit Quirks

github.com

Post reply on HN
Print view View original

21–30 of 91 posts

Re: WebKit Quirks

#21

Post by my123 »

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…

You can test GNOME Web (Epiphany) just fine, which does use the same engine.

Re: WebKit Quirks

#22

Post by arghwhat »

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…

GNOME Web is a webkit browser to name an example of non-Apple Web browsers.

From my perspective this is an application bug, and relying on heuristics is a bad idea. If a change should be made, it should be to make it explicitly the web apps task to handle on its own.

Re: WebKit Quirks

#23

Post by londons_explore »

0x0 wrote: post #6

I bet it's fun being responsible for developing and deploying on those sites. Works in CI and dev, but deploying to production makes the browser behave differently! Nice surprise!

A lot of the domain filters use things like:

topPrivatelyControlledDomain(url.host().toString()).startsWith("google.")

The definition of `topPrivatelyControlledDomain` means that `google.github.io` would qualify, or `google.works.aero`... Pretty much anybody can abuse that to get any of the quirks modes available in this file.

See the full list here:

https://publicsuffix.org/list/public_suffix_list.dat

Re: WebKit Quirks

#24

Post by unilynx »

timw4mail wrote: post #18
matsemann wrote: post #13

Earlier quoted context omitted.

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.

There is no spec to conform to to work around these cache issues. (IE was even worse in the past, shutting down the back forward cache if devtools were opened. Have fun debugging that)

But imagine Windows opening an app, drawing the last known interface state and then skipping half of the app startup code. Should apps deal with that too, or would it be considered a Windows bug?

Re: WebKit Quirks

#25

Post by colejohnson66 »

TazeTSchnitzel wrote: post #16

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

IIRC, the “checking for a solution to the problem” dialogs were added because they (Microsoft) would submit an actual bug report to the developers, and if they offered a solution, Microsoft’s servers would respond with it. I’ve never seen it work, but IIRC, they added it back in the Windows 95 days (when there was a lot less software to deal with).

Re: WebKit Quirks

#26

Post by m_eiman »

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…

Conceptually I'd say that clicking a link and then clicking Back should be the same as right-clicking the link and opening it in a new window, and then closing that window.

But it wouldn't surprise me if "web apps" makes this hard for some reason.

Re: WebKit Quirks

#27

Post by robin_reala »

dastx wrote: post #17
robin_reala wrote: post #3

Earlier quoted context omitted.

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.

By Google’s hegemony, I was talking about developers only testing in Google-developed rendering engines, not their web properties.

Re: WebKit Quirks

#28

Post by Sayrus »

duckerude wrote: post #20

> 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.

Damn, it seems you're right and it applies to any domain ending with this instead of hulu.com subdomains.

From the name of the quirk, I'm not sure this is an issue though.

Re: WebKit Quirks

#29

Post by my123 »

unilynx wrote: post #24
timw4mail wrote: post #18

Earlier quoted context omitted.

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

There is no spec to conform to to work around these cache issues. (IE was even worse in the past, shutting down the back forward cache if devtools were opened. Have fun debugging that) But imagine Windows opening an app, drawing the last known interface state and then skipping half of the app startup code. Should apps deal with that too, or would it be considered a Windows bug?

Modern applications for Windows (UWP) and iOS do use tombstones. The app's memory itself is completely suspended/saved to disk, and then the state is restored. The app startup code is _not_ called again.

Re: WebKit Quirks

#30

Post by JimDabell »

unilynx wrote: post #24
timw4mail wrote: post #18

Earlier quoted context omitted.

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

There is no spec to conform to to work around these cache issues. (IE was even worse in the past, shutting down the back forward cache if devtools were opened. Have fun debugging that) But imagine Windows opening an app, drawing the last known interface state and then skipping half of the app startup code. Should apps deal with that too, or would it be considered a Windows bug?

The spec. doesn’t cover this case explicitly, but the general gist of RFC 2616 is very much on the side of “don’t reload things”:

> History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

— https://tools.ietf.org/html/rfc2616#section-13.13

If a web application depends on the browser reloading the page when the user presses the back button, then I think it’s fair to call that a bug in the web application. It is “trying to show a semantically transparent view of the current state of the resource”, which is explicitly called out as incorrect behaviour by the spec.

Post reply on HN