WebKit Quirks.cpp

https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp

by Bodacious1445 • 4 years ago

199 91 4 years ago

sanxiyn3• 4 years ago

It's somewhat interesting although not surprising that iCloud is there in WebKit quirks even if both WebKit and iCloud are developed by Apple.

olliej3• 4 years ago

oh, that's magical :D

Bytewave81• 4 years ago

At some point, "one" company becomes a set of loosely-related "companies" all tied together by a single name and a chain of bureaucracy.

jaseemabid• 4 years ago

Knowing apple, its probably illegal for those 2 teams to talk to each other.

sanxiyn3• 4 years ago

By the way, this is as old as web. It's ironic to re-read https://dev.opera.com/blog/opera-s-site-patching/ published in 2009, which uses 2022(!) as a stand-in year for far future when hopefully none of this will be required.

zinekeller• 4 years ago

The bitter irony is that it was indeed "solved" - not by HTML5 as (the original) Opera dev team implied, but by Chromium being in a ~90% market share.

babelfish• 4 years ago

This bit was interesting.

  bool Quirks::requiresUserGestureToPauseInPictureInPicture() const
  {
  #if ENABLE(VIDEO_PRESENTATION_MODE)
      // Facebook, Twitter, and Reddit will naively pause a <video> element that has scrolled out of the viewport,
      // regardless of whether that element is currently in PiP mode.
      // We should remove the quirk once <rdar://problem/67273166>, <rdar://problem/73369869>, and <rdar://problem/80645747> have been fixed.
      if (!needsQuirks())
          return false;

      if (!m_requiresUserGestureToPauseInPictureInPicture) {
          auto domain = RegistrableDomain(m_document->topDocument().url()).string();
          m_requiresUserGestureToPauseInPictureInPicture = domain == "facebook.com"_s || domain == "twitter.com"_s || domain == "reddit.com"_s;
      }
  
      return *m_requiresUserGestureToPauseInPictureInPicture;
  #else
      return false;
  #endif
  }

peaBerberian• 4 years ago

This makes me very jealous!

I'm a developer on a web media player and remember that we had at some point an issue with picture in picture mode: We had a feature that lowered the video bitrate to the minimum when the page that contained the video element was not showing for some amount of time.

That made total sense... until the Picture in Picture mode was added to browsers, where you would see a very-low quality after watching your content in that mode in another page long enough (~1 minute).

The sad thing is that because I was (still am) developing an open-source player and because the API documentation described clearly the aforementioned implementation, I had to deprecate that option and re-create a new one (with a better API documentation, talking more about the intent than the implementation!) instead, which would have the right exceptions for picture in picture mode.

Seeing that part made me remember this anecdote, we should just have asked for quirks :p

CharlesW• 4 years ago

Is the player you're working on public? Does the Picture-in-Picture API do what you need now?

shadowgovt10• 4 years ago

The first rule of browser development is "forget the standard, forget consistency... If it's popular and works in other browsers but not yours, your browser is broken."

matheusmoreira4• 4 years ago

Might as well create site-specific browsers.

Angostura• 4 years ago

"we believe in rough consensus and running code"

olliej3• 4 years ago

That is a glib, and inaccurate claim of browser engine development based on the reality of the web more than a decade ago.

It is however absolutely the behavior of web developers, that's why the web used to be filled with IE only sites, and why we are now getting chrome only sites. It is much easier to blame other engines that ask whether your site is depending on implementation details.

The TLDR for this is: the modern web is very well specified, and all browser engines work very hard to conform to those specs, and now when divergent behavior is found the erroneous engine is corrected, or if the specification itself was incomplete considerable effort is expended making sure it is complete so that it is possible to ensure conforming implementations. The driving force for this was engine developers, not site developers.

Anyway.

The entire point of the html5 and subsequent "living" spec, and the death of ES4 and subsequent ES3.1 and ES5 specs, and then ES's "living spec" was dealing with the carnage of the early web and the Netscape vs IE insanity it produced. This was a huge amount of effort driven almost entirely by the engine developers, specifically so that the specs could actually be used to implement browser engines. The existing W3C and ECMA specifications were useless as they frequently did not match reality, where they did match reality they had gaps where things were not specified, and frequently they simply did not acknowledge features existed.

It took a huge amount of effort to determine the exact specification for parsing html, such that it could be adopted without breaking things. It took a huge amount of effort to go through the DOM APIs, the node traversal, event propagation, and on and on to specify them.

The same thing happened with ecmascript. A lot of effort for many years was spent replacing the existing spec, ignoring a bunch of time wasted by some parts of the committee creating ES4, making it so that the ecmascript specification actually matched reality.

There were places where we found that there were mutually incompatible behaviors between Gecko and Trident, but in most cases we were able to replace old badly written specs, with real specifications that were compatible with reality, and were sufficiently detailed that they could be used to implement a new engine, and be confident that their engine would actually be usable.

The immense work required for this also means that the spec authors and committees are acutely aware of the need for exact and precise specification of new features. So it is expected that new specifications completely specify all behavior.

As an example, I recall that after originally implementing support for IMEs in webkit on windows, I spent weeks stepping through how key down, up, and press events were fired in the DOM when a user was typing with an IME. The spec at that point failed to say what events should be fired in that case - text entry is not keydown/press/up once IMEs are involved, do not assume one keyup will result in a single character change - it was a months long effort to get to something that only managed to specify keydown/up/press, none of the actual complexity of IMEs. The specification has since expanded to be more capable of handling IMEs, but they have an example of what the "keys typed by a user" vs "key events you receive" [1], and alas my work is now largely "legacy" :D [2]

The problem as ever, is that it is very easy for web developers to rely on some implementation detail that a specification failed to dictate, and then say any browser engine that does not behave identically is wrong. This is what webdevs did with IE, and now it's what webdevs do with Chrome. It is always easier for a webdev to paste "this site requires ie/chrome" than to work out if what they're doing is actually specified behavior. Sure, it's possible it's a bug in the other engine, but if you are saying "install chrome" you're saying it doesn't work in Gecko or WebKit, so it's much more likely to be a site bug.

[1] https://www.w3.org/TR/uievents/#keys-IME

[2] https://www.w3.org/TR/uievents/#legacy-key-models

sanxiyn3• 4 years ago

You can check out https://github.com/webcompat/web-bugs/labels/sitepatch-appli... to see current actions.

lelandfe• 4 years ago

Unrelated to quirks mode: https://en.wikipedia.org/wiki/Quirks_mode

Which even just remembering now gave me some small terror

eatonphil• 4 years ago

I noticed this today through Andreas Kling's tweet: https://twitter.com/awesomekling/status/1580993812247158784.

pvg• 4 years ago

Previous (87 comment) discussion two years ago:

https://news.ycombinator.com/item?id=26165357

richdougherty• 4 years ago

We found a bug last time!

https://bugs.webkit.org/show_bug.cgi?id=222130

adamrezich• 4 years ago

did not realize that webkit has the equivalent of site-specific hard-coded stuff like this, or even isGoogleMaps(), it's like nvidia drivers for the web, crazy

O_H_E• 4 years ago

    // On Google Maps, we want to limit simulated mouse events to dragging the little man that allows entering into Street View.

loool

l_f• 4 years ago

I love how they name things

shouldSuppressAutocorrectionAndAutocaptializationInHiddenEditableAreasForHost(...)

kitsunesoba2• 4 years ago

Can't leave any room for ambiguity!

Apple-style function/method naming may be verbose but at least the names usually have good explanatory value and aren't just meaningless verbosity.

shadowgovt10• 4 years ago

And in the 21st century, everybody's using tab to autocomplete that string anyway.

rcoveson• 4 years ago

Suggested names for porting this source file to other languages:

Java:

isShouldSuppressAutocorrectionAndAutocaptializationInHiddenEditableAreasForHost

Common Lisp:

suppress-autocorrection-and-autocaptialization-in-hidden-editable-areas-for-host-p

saaainheafh

hunter2_• 4 years ago

The dropped "s" and extra "n" is... about right I suppose!

dvirsky• 4 years ago

In Windows, this is just a getter to a private variable variable called m_pcszwclbShouldSuppressAutocorrectionAndAutocaptializationInHiddenEditableAreasForHost

umanwizard• 4 years ago

Many codebases I’ve worked on:

mungeEditable

eyelidlessness4• 4 years ago

I would’ve figured the lisp one would be something like `hidden-autoc-host?`

quickthrower22• 4 years ago

Haskell:

userbinator3• 4 years ago

There's even a typo: captialization

acid__• 4 years ago

Huh, how big does your website have to be in order for your bugs to be patched this way?

shadowgovt10• 4 years ago

Big enough for Apple to believe a critical mass of users will switch to another browser if they don't bend the rules.

alwillis2• 4 years ago

It’s more likely about making sure Safari users have a good or consistent user experience on popular sites.

When you’re the default browser on 1.5+ billion devices, it’s less about losing a few users here or there.

peyton2• 4 years ago

They want a good experience for people who click around popular sites on demo devices at the Apple Store. You can’t switch browser engines on iOS

perardi• 4 years ago

Judging by how many times they show up: Google.

Just kidding. Mostly. Lots of little fiddly text editing patches for Google Docs, which doesn’t surprise me. It’s, I would assume, the most-used application suite on the web, and there’s going to be weird edge cases that pop up around rich text editing that get magnified by the sheer number of users. Including probably inside Apple.

lapcat2• 4 years ago

Interesting that this is posted to HN now, because I recently ran into some YouTube brokenness caused by an old WebKit quirk.

"Site-specific hacks break native video controls in YouTube embeds" https://bugs.webkit.org/show_bug.cgi?id=245612

So many hours spent debugging this...

dschulz• 4 years ago

Interesting bits are to be found under the rug :-)

squeaky-clean• 4 years ago

I've found another webkit quirk in the past which is outside of the Quirks.cpp file, ObjectPrototype.cpp has some special code for the PokerBros app. Looks like it's still there.

https://github.com/WebKit/WebKit/blob/f134a54c03b71e8e3c4da0...

Also not as disgusting as Quirks.cpp, but I was debugging some video decoding stuff in Chrome this week and found some fun things today, special code to work around various GPU driver bugs.

https://source.chromium.org/chromium/chromium/src/+/main:gpu...

And a separate implementation of MSAA for Intel GPUs

https://source.chromium.org/chromium/chromium/src/+/main:gpu...

bialpio2• 4 years ago

There's also https://source.chromium.org/chromium/chromium/src/+/main:gpu...

Cyberdog• 4 years ago

I was going to post a message trying to shame anyone who works on a site with a URL in this file to fix their damn site…

…but now, thanks to this file, it may be difficult if not impossible to fix their damn site in a way that doesn't conflict with WebKit's own fixes. :/

webmobdev• 4 years ago

bool shouldSuppressAutocorrectionAndAutocaptializationInHiddenEditableAreasForHost
Quirks::shouldSuppressAutocorrectionAndAutocaptializationInHiddenEditableAreas

Even with modern IDE's with autocomplete, I wonder if such long names for variables, methods, classes etc. should be encouraged?

lapcat2• 4 years ago

I suspect it's influenced by Objective-C, which tends to have a rather verbose style.

It's an acquired taste.

eyelidlessness4• 4 years ago

Yes

eyelidlessness4• 4 years ago

I was going to explain my reasoning, but I think such a terse answer conveys much of it.

MBCook• 4 years ago

I like it, though I’m used to Apple library function/constant/class names so I’m not surprised the way some might be.

As an exercise: what would you name it that’s shorter?

I’m having trouble thinking of anything that doesn’t make it seriously compromise the clarity unless you had a lot of autocorrect and autocapitalization problems and could shorted that part to AandA.

The only other option, which I do t really like, is to strip all the info and call it something like isBug315255() and put a comment in the function explaining it. But that’s a big loss in my eyes.

dmitriid• 4 years ago

You read code much more often that you write it. So, the answer is: yes.

quickthrower22• 4 years ago

Linus would hate it!

howinteresting2• 4 years ago

Surprised this is hardcoded in C++ and not something that can be pushed as an over the air update.

unsafecast3• 4 years ago

But it can be. Engine fixes are also OTA, it's the same thing really.

howinteresting2• 4 years ago

Do you mean OTA as in pushed with OS updates? I meant something more like a bunch of dynamic rules that can be updated daily or similar.

tiagod2• 4 years ago

Is there a mechanism for the site operators to tell the engine not to apply certain quirks once the underlying bugs are fixed?

KMnO4• 4 years ago

A pull request, I guess.

tiagod2• 4 years ago

My line of thought was that some of these changes could make the fixed code work badly, but it was probably taken into consideration

captainmuon• 4 years ago

It's incredible, most of these are large companies (Zoom, YouTube!) or government entities. They should just be able to send an email (or a registered mail on company letterhead) saying "Hello, we are Google, your website is broken. Please make the following changes.". Fixing sites for other people is less work and technical debt than adding it permanently to the source code of the browser.

And if it is not bugfixes, but keeping around features that were removed: if youtube.com uses something, why can't everybody else use it?

bialpio2• 4 years ago

Nitpick: WebKit is more of an Apple's thing than Google's thing. : - )

NVI• 4 years ago

Many issues certainly get resolved over email or bug trackers. Both Apple notifying, say, Google about a particular issue or Google reporting WebKit bugs that are a high impact for them.

silvestrov• 4 years ago

I would have expected some hash tables instead of long chains of if-statements.

x3ro• 4 years ago

Why? If it’s not dynamic, why make your life harder and slower? Nothing beats a compare and jump compiled into your binary.

yakubin• 4 years ago

Only as long as your compiler optimises it into a jump table, which is effectively a hash table.

archi42• 4 years ago

The quirks are called at the appropriate places, and can be inlined using LTO. The same places would need to hash the current context and check if it's in the hash map (is it one global hash map, or a specialized one for each quirk, with an optimised hashing function?). And on a match, you need to do the full check anyway, due to likely collisions.

The conditionals in the full check seem to use symbolised strings where possible, so they're quite fast. Probably faster than producing a suitable hash.

pkrumins• 4 years ago

Can anyone explain what this is for?

fprct• 4 years ago

Just imagine a domain from such file being recycled in 10-20 years from now and you building a webpage for the new owner - everything works as expected on dev, stage, test etc - but not on prod when deployed...

WebKit Quirks.cpp

Related Stories