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

51–60 of 91 posts

Re: WebKit Quirks

#51

Post by ksec »

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…

>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

Re: WebKit Quirks

#52

Post by ksec »

robin_reala wrote: post #3
sdflhasjd wrote: post #2

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

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…

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.

Re: WebKit Quirks

#53

Post by firloop »

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() == "magnifierLens";
https://github.com/WebKit/WebKit/blob/3def0062f77b82a46fc40c...

Re: WebKit Quirks

#55

Post by RandallBrown »

throwaway744678 wrote: post #54

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

I wonder if the typo was done on purpose given the point of the function is to suppress autocorrection.

Re: WebKit Quirks

#56

Post by AshamedCaptain »

colejohnson66 wrote: post #25
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).

That was a Vista thing, definitely not 95. I have seen it working once, but I don't remember what the program was.

Re: WebKit Quirks

#57

Post by colejohnson66 »

AshamedCaptain wrote: post #56
colejohnson66 wrote: post #25

Earlier quoted context omitted.

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

That was a Vista thing, definitely not 95. I have seen it working once, but I don't remember what the program was.

That was Vista? Wow. I was way off...

Re: WebKit Quirks

#58

Post by GranPC »

matsemann wrote: post #48
GranPC wrote: post #36

Earlier quoted context omitted.

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?

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)

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.

Re: WebKit Quirks

#59

Post by capableweb »

goranmoomin wrote: post #45
marcellus23 wrote: post #32

Earlier quoted context omitted.

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

Re: WebKit Quirks

#60

Post by capableweb »

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…

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

Post reply on HN