[HN Gopher] WebKit Quirks
___________________________________________________________________
WebKit Quirks
Author : momonga
Score : 166 points
Date : 2021-02-17 11:47 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| matsemann wrote:
| 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).
| m_eiman wrote:
| Why shouldn't it show it in the same state? Seems like a
| reasonable thing to do.
| matsemann wrote:
| 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.
| ksec wrote:
| >Especially since it cannot be tested without owning an
| Apple device.
|
| Yes very annoying. They dont have to bring Safari on
| Windows, but at least WebKit on Windows would be nice for
| testing. In the mean time, Otter for Cross Platform Browser
| [1], or you could do Gnome Web with Windows WSL2.
|
| [1] https://github.com/OtterBrowser/otter-browser
| m_eiman wrote:
| 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.
| tannhaeuser wrote:
| No, it's just one of too many things, big and small, making
| browser web apps annoying. The entire point of a browser
| was a relatively simple viewer app that renders docs ok on
| most devices; not an opionated renderLikeChrome mode. If
| the basic concept of leaving a page for linked content,
| then coming back can't be handled without heuristics, then
| clearly the web app model is broken af.
| capableweb wrote:
| > But for dynamic pages or SPAs it more often than not
| leads to going back to a page in a broken state.
|
| Definitely a page concern, not the browsers. This problem
| is also easy to fix and a solution has been known for many
| years by now: handle navigation via the URL always! (or,
| modern take: via the history API). A modal opens? The URL
| should change and because the URL changed to that specific
| path, show the modal. Now users can bookmark or go
| back/forward without any issues of pages being broken.
| timw4mail wrote:
| Sounds more like an issue with the web apps to me.
| unilynx wrote:
| 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?
| JimDabell wrote:
| 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.
| chrismorgan wrote:
| RFC 2616 is long obsolete; the section you cited is now
| https://tools.ietf.org/html/rfc7234#section-6 and is
| substantially reworked. The chunk you refer to has been
| removed, because it no longer reflected reality in any
| way. Even as originally specified, as a SHOULD, it wasn't
| ever practical to implement completely because of memory
| requirements. Since 1999, a lot has changed, and the fact
| of the matter was that the original recommendation just
| didn't make sense any more, worded as strongly as it was.
| So instead they've switched it round to essentially say
| that you _may_ redisplay an earlier-retrieved
| representation (rather than that you SHOULD NOT do the
| opposite).
| my123 wrote:
| 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.
| my123 wrote:
| You can test GNOME Web (Epiphany) just fine, which does use
| the same engine.
| arghwhat wrote:
| 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.
| machello13 wrote:
| What makes it broken, out of curiosity? Is there a spec
| anywhere that suggests that behavior is incorrect? Or is it
| just because it's not what Chrome does?
| pcr910303 wrote:
| Yeah, I'm interested too. I might be wrong, but AFAIK there
| aren't any specs on how a browser should implement
| forward/back buttons, right?
|
| I'm personally getting a ton of mileage on the Safari's much
| more stable forward/back cache, the fact that you can go back
| reliably gives me more comfort than other browsers where
| going back usually refreshes the page (although I can't
| really explain how this is much better). I personally feel
| that this bug is more of a web app bug rather than the
| browser.
| gsnedders wrote:
| There's a metabug on HTML at
| https://github.com/whatwg/html/issues/5880 about defining
| how various platform-exposed features behave in the face of
| a bfcache (backwards/forwards cache).
| capableweb wrote:
| The closest you get for how browsers should act regarding
| history is part of the HTML spec here:
| https://html.spec.whatwg.org/multipage/history.html
|
| Of course, the exact implementation is not specified,
| browsers are free to either implement cached behavior,
| which I think Firefox does as well, or just a naive
| refresh.
| zachrip wrote:
| I've actually been dealing with this issue. Does anyone have an
| easy way to resolve it? It causes some pretty nasty rendering
| issues in our app.
| matsemann wrote:
| https://stackoverflow.com/a/13123626/923847
|
| Can force a refresh when the page us navigated back to. Or
| use that event to fix whatever state your in.
| zachrip wrote:
| Full refresh defeats the purpose of a spa unfortunately. I
| just tested that event and it actually doesn't appear to
| fire when navigating backwards, only when the page is
| initially shown...which contradicts the comments in that
| code.
| matsemann wrote:
| Maybe you misunderstand the original issue. This is when
| navigating back to a "new" page, not internally in a SPA.
| But this issue mainly happens when navigating back to a
| page with dynamic behavior (typically a SPA or other
| interactive application).
| GranPC wrote:
| I'm actually having a similar issue with my web app currently
| and I'm not sure what the best way to solve it would be. I was
| thinking of setting a checkbox in an invisible form when the
| page loads initially, and force a real reload if the checkbox
| was previously set, but that seems like a terrible hack. Any
| ideas?
| matsemann wrote:
| We use this to force a refresh:
| https://stackoverflow.com/a/13123626/923847
|
| Or you can use that event to fix what's wrong on the page
| without a refresh if possible (remove a modal, enable the
| button again etc)
| GranPC wrote:
| Great! Looks like a proper way to do what I was trying to
| do. Thank you!
|
| My web app is a game, so fixing everything without a
| refresh is unfortunately pointless for the most part, and
| forcing a refresh also ensures players are running the
| latest version if they've been away for a while.
| theXspidy wrote:
| https://thesnippets.substack.com/p/bitcoin-surges-past-51000...
| sdflhasjd wrote:
| Domain name specific quirks?
|
| What in the world...
| robin_reala wrote:
| 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 workarounds; if
| a site is broken for a user, then they'll change browser.
| ksec wrote:
| Oh Yes, As it was in Firefox when they have IE Quirks. And I
| am now leaning towards may be it is the standard's fault, not
| the implementation.
| sdflhasjd wrote:
| Yes, it is a real shame, but then again, a lot of these sites
| are made by reasonably big companies.
|
| I'm sure trello and such could fix whatever these input
| quirks are.
|
| Then there's autoplay specific behaviour on facebook, twitter
| and netflix. Is this really a google hegemony thing, or is
| this leniency that other sites don't get?
|
| I'm just trying to see if there's similar examples in Blink &
| Gecko right now.
| robin_reala wrote:
| I work for a big company. There have been plenty of
| outstanding bugs in my company's sites and apps, because
| the people that care aren't in teams that own the systems
| with bugs in, or aren't in a position to have their voices
| heard, and that's before the hydra of "legacy software"
| rears its many-consultanted head.
|
| (at least in my org we're generally better at this now)
| erichurkman wrote:
| > if (host == "trailers.apple.com")
|
| > return true;
|
| Even Apple themselves are not immune.
| abrowne wrote:
| And icloud.com: https://github.com/WebKit/WebKit/blob/21c
| 441ed8ddc83f3e24ad5...
| dastx wrote:
| > 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.
| robin_reala wrote:
| By Google's hegemony, I was talking about developers only
| testing in Google-developed rendering engines, not their
| web properties.
| dastx wrote:
| Aah! Pardon me. That makes more sense.
| shay_ker wrote:
| How do these domain-specific quirks get into WebKit? Is it
| advocated by the companies? By the users? By the devs?
|
| I'm just curious how these changes actually make it to millions
| of people's browsers
| jonnypotty wrote:
| My thoughts exactly. So fragile. Im so grateful I don't have to
| do web dev any more, what a mess.
| livre wrote:
| This isn't new, I remember Opera (versions 12 and older) used
| to come with a privileged .js file that would apply patches to
| websites. It was used mostly to fix those that blocked Opera
| when they detected its user agent or popular websites that ran
| code using proprietary functions or css properties (things that
| only Chrome or Internet Explorer implemented but weren't part
| of the standard).
| TazeTSchnitzel wrote:
| Anyone who's read a few Old New Thing posts would know that
| Windows must be full of similar checks.
| colejohnson66 wrote:
| 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).
| AshamedCaptain wrote:
| That was a Vista thing, definitely not 95. I have seen it
| working once, but I don't remember what the program was.
| colejohnson66 wrote:
| That was _Vista_? Wow. I was way off...
| chris_wot wrote:
| They really need to get rid of this.
| gruez wrote:
| You can disable it using group policy https://admx.help/?Ca
| tegory=Windows_10_2016&Policy=Microsoft...
| kgin wrote:
| It's like that saying about debt.
|
| When a browser renders your 500 mau site badly it's your problem.
|
| When a browser renders your 50,000,000 mau site badly it's the
| browser's problem.
| lxe wrote:
| Wow, this is terrible. Either fix the bugs, introduce non-
| standard behavior for all sites, or expect these big players to
| fix their own problems.
| firloop wrote:
| Wow, there's not only _domain_ specificity, but also HTML
| _element_ specificity in this quirks list. //
| When panning on an Amazon product image, we're either touching on
| the #magnifierLens element // or its previous sibling.
| auto& element = downcast<Element>(*target); if
| (element.getIdAttribute() == "magnifierLens") return
| true; if (auto* sibling = element.nextElementSibling())
| return sibling->getIdAttribute() == "magnifierLens";
|
| https://github.com/WebKit/WebKit/blob/3def0062f77b82a46fc40c...
| 0x0 wrote:
| 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!
| londons_explore wrote:
| 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
| jakub_g wrote:
| There was a viral tongue-in-cheek tweet this month "how to
| prevent scrolling in Safari when..."?
|
| 1. Buy Zillow. Destroy the company.
|
| 2. Redirect your website to zillow.com
|
| (it was more fun that what I wrote)
|
| https://github.com/WebKit/WebKit/blob/f43587ec2416b86eecef50...
| IMTDb wrote:
| That's new "you have made it when"...they need to change the
| browser engine for your website.
| mappu wrote:
| I was surprised to see they're almost exclusively anglosphere
| websites, i would have guessed a broader variation
| capableweb wrote:
| The web is surprisingly segregated. Seems there is at least
| three versions of everything (from my perspective), from
| websites like the typical social network to utilities people
| use day to day, english/spanish/chinese.
| [deleted]
| throwaway744678 wrote:
| Wow, there's a nice 77 characters function name [1]! Yes, with a
| typo. Hard to keep the lines under 80 characters...
|
| [1]
| https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
| RandallBrown wrote:
| I wonder if the typo was done on purpose given the point of the
| function is to suppress autocorrection.
| jaywalk wrote:
| Interesting to see www.icloud.com in there...
| tholman wrote:
| 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...
| tabtab wrote:
| Web UI's are a friggen mess. We really need to rethink it all.
| For one, if we had a standard state-ful GUI markup language, we
| wouldn't need to reinvent so many common GUI widgets and idioms
| using bloated libraries based on JS + DOM.
|
| Second, if web standards allowed true absolute positioning of
| vectors (as an option), then the layout engines could reside on
| servers, allowing us to choose a layout engine that best fits
| domain and need.
|
| Note that while existing web standards do have some coordinate
| based features, they are too inconsistent to reply upon. If they
| were any good, we wouldn't need PDF viewers.
| duckerude wrote:
| > 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.
| Sephr wrote:
| This is to enable Safari's legacy EME implementation. I wonder
| if there are any vulnerabilities waiting in those unmaintained
| legacy codepaths
|
| https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
|
| I first noticed this bug a year ago last February and it's been
| unchanged ever since.
| Sayrus wrote:
| 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.
| [deleted]
| TonyTrapp wrote:
| I really dislike this sort of quirk workarounds, not just in web
| browsers. It just makes everything complicated. Someone else
| using the exact same code will get different behaviour, just
| because they serve it from a different domain. I did similar
| workarounds before (not related to websites but to specific
| files), and I felt very bad about it even though it was clear
| that no more files in that specific format would ever be
| generated again.
___________________________________________________________________
(page generated 2021-02-17 21:01 UTC)