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
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).
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?
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.
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.
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).
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.
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.
> 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.
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.
In my mind the forward back buttons apply to the URL. So you are going back and forward in URL history, as if you were typing the URL in fresh each time. In the old days the back forward buttons were right there next to the URL on the toolbar.
It just occurred to me that on mobile, the back button is not associated with the URL at all, so its not surprising that people don't associate it with that anymore.
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.
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.
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.
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.
>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.
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?
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.
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.
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).
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.
just on a quick glance a few lines above might possibly be a good vector to test for ads to get around autoplay sound restrictions. make a domain ending with somethingnetflix.com, iframe it, and maybe figure out if the second link below has a class that allows override to allow autoplay sound without user interaction to something like kWKWebsiteAutoplayPolicyAllow with sound on.
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!
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.
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";
at what point does it make more sense to just have a wasm "html-lib" provided by a specific site that it can depend on instead of burdening webkit/blink with all these unsafory hacks?
if html-lib was versioned and slimed down to remove old hacks, it could he small enough to download quickly, and with hashing could ensure other pages that use the same version dont have to re-download again...
at some point we could have other web front ends than html that can represent "apps" on the web better too...
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.
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.
> 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.
This is the last (shipped) Presto one for desktop:
Perhaps more surprisingly, this continued into Chromium-based Opera (though archive.org seems not to have that, but that's the OPRdesktop directory in that repo); this was primarily down to sites with a UA string allowlist, and having to lie to get in. (Chromium-based Edge also has a means to override the UA string.)
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.
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)
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).
I’d suspect this is driven more by using those sites as internal test cases. Every browser vendor since Firefox broke IE’s total domination has had a “don't break the web” priority to some extent. Using large scale real world examples to validate that has the added bonus of revealing cases where you did, in fact, break a significant (by usage) portion of the web.
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).
Windows has tens of thousands of them. However, the vast majority of them unlike this quirks file are very very specifically gated to an explicit version range, file name, product name, etc etc, typically with consent of the app manufacturer.
When you're making a new technology to interact with existing technology, and following the specification results in your new technology failing to work with what's already there, nobody will care if you blame the standard or everyone's mis-implementation of the standard.
They'll consider your malfunctioning tool as damage and route around it... Until you become big enough that you can be the existing implementation other people have to adapt to.
Every commonly-used browser either has something like this buried in its implementation or has a date-stamp of first release older than everything else out there.
It's fun (and a little depressing) to look at this list, but it exists is basically every popular project. Unfortunately, the incentives are set up for this to essentially be necessary: if something popular doesn't work in your software, users are going to think your code is the one who is broken, not the thing they are trying to use. So you have a sort of a "tragedy of the commons" where if you keep a principled position a user is going to switch to your competitor that supports quirks to get the thing to work.
We need something new here. This is not scalable. If a group of engineers can't write a new browser in sabbatical, then we need to change what a browser (and the spec) should be.
Access to internet should be simple, not complicated so many can participate and leave control out of big corp.
Web UI "standards" 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.
My goodness a coordinates based layout system would be an enormous step backwards. We’d be back to `m.` subdomains and horizontal scrolling as the norm.
The CSS layout standards are certainly not all ideal for my preferences. But the adaptability they afford in fluid layout is far better for real end users than any kind of absolute layout predetermined on a server.
We’ve reached a point I can use most of the web on my phone without compromise and I’d hate to lose that for some development convenience.
I don't think you understand. The layout engine could be on the server, not "non existent". (Although one could program directly with coordinates if they wanted.) Coordinate based vectors allows the layout engine to be on the server, so that we are not stuck with a one-size-fits all layout engine.
And what's wrong with the "m." standard as an option? For some jobs it's the right tool.
And what's good for public site phone use may not be the right tool for internal CRUD applications. I don't recommend Google make an email client with the additions I suggest, for example. The existing standards are fine for light-input consumer sites, but lousy for productivity-oriented CRUD. I'm not saying get rid of existing standards.
> I don't think you understand. The layout engine could be on the server, not "non existent".
Oh, I do understand which is why the thing in your quotes isn't something I said. Layout on the server means you're laying out without the context of my device or viewport, and certainly without any change of context like if I switch to dark mode or prefers-reduced-motion, or if my data access changes.
> And what's wrong with the "m." standard as an option? For some jobs it's the right tool.
Instead of getting overly principled about it... one of the reasons it went away was because the heuristics that determined what even is mobile were becoming increasingly wrong. And like I said this resulted in a bunch of ridiculous horizontal scrolling for lots of users.
Re: "Layout on the server means you're laying out without the context of my device or viewport"
Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details: watch, phone, tablet, laptop, desktop, workstation. (And user should be able to switch the preference manually.)
Re: "And like I said this resulted in a bunch of ridiculous horizontal scrolling for lots of users."
Without seeing a specific scenario, I cannot comment on possible solutions or standard adjustment proposals. Sometimes people throw the baby out with the bathwater even the baby was fine.
> Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details
And what happens when I rotate my device? Or resize my window? Or switch to dark mode? Another request to the server to redraw? What happens when an unknown class of device is encountered? What happens when your assumptions about a known class of device aren’t future proof?
Look I agree that the CSS layout APIs aren’t as good as they could be. But I really don’t think making them less flexible is the solution. If anything they’re not flexible enough (for example many kinds of layout are still very difficult to achieve with dynamic content, even with grid). But what would improve the APIs in my opinion is to design them with common idioms as primitives. Grid has somewhat embraced that by allowing template areas to be named arbitrarily. But the underlying APIs are sprawling and hard to understand even with close attention to the docs/spec.
They likely can’t. What happens when whatever quirk they used to isolate goes global and breaks workarounds on thousands of other sites they didn’t test? I mean, it’s awful that anything like this exists but it’s pretty likely well past any kind of turning back.
Given WebKit’s lineage I have to wonder if some portion of this was inherited from KHTML.
[1] https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...