WebKit Quirks(github.com) |
WebKit Quirks(github.com) |
[1] https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
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
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.
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.
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)
Can force a refresh when the page us navigated back to. Or use that event to fix whatever state your in.
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...
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.
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.
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.
https://github.com/WebKit/WebKit/blob/f43587ec2416b86eecef50... https://github.com/WebKit/WebKit/blob/88278b55563e5ccdc0b341...
From the name of the quirk, I'm not sure this is an issue though.
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:
// 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...
is that a crazy idea?
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.
What in the world...
[1] https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
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.
Access to internet should be simple, not complicated so many can participate and leave control out of big corp.
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.
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.
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.
Given WebKit’s lineage I have to wonder if some portion of this was inherited from KHTML.
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.
This is the last (shipped) Presto one for desktop:
https://web.archive.org/web/20190204112249if_/https://github...
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.)
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.
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.
I'm just curious how these changes actually make it to millions of people's browsers
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.
https://html.spec.whatwg.org/multipage/browsing-the-web.html...
Which appears to be supported in Safari, just like all the other browsers.
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.
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.
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.
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.
> return true;
Even Apple themselves are not immune.
(at least in my org we’re generally better at this now)
It tells the server and the server re-renders the page. It's a bit slower than client-side adjustments, but worth it for the extra power and control. I don't do those actions very often, do you? The existing tools screw those up anyhow.
> But I really don’t think making them less flexible is the solution. If anything they’re not flexible enough
That makes the client even more bloated, meaning more client version variation and bugs. That exacerbates the problem. By shifting the burden to the server, the client can be simpler and thus less buggy, and the server can pick the best layout engine for the domain instead of being stuck with the client's one-size-fits-all mistake.
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.
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.
But it wouldn't surprise me if "web apps" makes this hard for some reason.
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.
I think safari desktop hides the URL as well.
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?
> 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.
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.
Anyway, how would you handle connections to remote servers?