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

71–80 of 91 posts

Re: WebKit Quirks

#71

Post by andrekandre »

firloop wrote: post #53

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 (*target); if (element.getIdAttribute() == "magnifierLens") return true; if (auto* sibling = element.nextElementSibling()) return sibling->getIdAttribute() == "magnifierL…

am i crazy or does this seem not scalable?

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?

Re: WebKit Quirks

#72

Post by shadowgovt »

The thing about network effects is this:

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.

Re: WebKit Quirks

#73

Post by richdougherty »

Sephr wrote: post #43
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.

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.

Definitely a vulnerability there exploitable in concert with the error in the domain name check.

Re: WebKit Quirks

#74

Post by eyelidlessness »

shay_ker wrote: post #33
sdflhasjd wrote: post #2

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

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

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.

Re: WebKit Quirks

#75

Post by eyelidlessness »

lxe wrote: post #41

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.

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.

Re: WebKit Quirks

#76

Post by eyelidlessness »

tabtab wrote: post #66

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 tha…

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.

Re: WebKit Quirks

#77

Post by dillondoyle »

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.

good catch.

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

Re: WebKit Quirks

#78

Post by tinus_hn »

capableweb wrote: post #59
goranmoomin wrote: post #45

Earlier quoted context omitted.

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 p…

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.

I think the closest is the pagehide event

https://html.spec.whatwg.org/multipage/browsing-the-web.html...

Which appears to be supported in Safari, just like all the other browsers.

Re: WebKit Quirks

#79

Post by tinus_hn »

my123 wrote: post #29
unilynx wrote: post #24

Earlier quoted context omitted.

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.

It has been a while since I wrote iOS app code but I’m pretty sure iOS does not, although the libraries provide a mechanism you have to save and restore state yourself. And iOS doesn’t swap, it just kills apps when it needs memory.

Anyway, how would you handle connections to remote servers?

Re: WebKit Quirks

#80

Post by astrange »

tinus_hn wrote: post #79
my123 wrote: post #29

Earlier quoted context omitted.

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.

It has been a while since I wrote iOS app code but I’m pretty sure iOS does not, although the libraries provide a mechanism you have to save and restore state yourself. And iOS doesn’t swap, it just kills apps when it needs memory. Anyway, how would you handle connections to remote servers?

iOS does sometimes swap, but only suspended processes, so you won't notice from inside the app.
Post reply on HN