6 ms·

This bit was interesting. bool Quirks::requiresUserGestureToPauseInPictureInPicture() const { #if ENABLE(VIDEO_PRESENTATION_MODE) // Facebook, Twit

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 4y 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 4y ago
  Is the player you're working on public? Does the Picture-in-Picture API do what you need now?
  - happytiger 4y ago
    That's Paul. His product is https://github.com/canalplus/rx-player https://github.com/canalplus/rx-player
shadowgovt 4y 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."
- matheusmoreira 4y ago
  Might as well create site-specific browsers.
  - mey 4y ago
    I believe those are called native apps.
    - matheusmoreira 4y ago
      It's useful to distinguish between them, though. Apps are almost always first party software that only does what's officially supported. Browsers have a long history of customizability, extensibility, programmability, adversarial interoperability. What if instead of browsers and ad blockers we had an extensive collection of web scrapers for every web site out there?
      - truemotive 4y ago
        I do believe we have all of those things currently, but with the scrapers working against the human condition. Our only recourse is smart human scrapers but that job sucks really fast.
  - shadowgovt 4y ago
    It's more in the category of "the new kid on the block tries to implement to spec and discovers what everyone else already knows: spec's hosed." I once received a bug report on a site that consistently went down after a computer woke from sleep... But only if the computer was a macintosh, and only if the browser was Chrome. It turned out that the root cause was that when the machine slept and reawoke, XML HTTP requests that were attached to timers in an open webpage would fire all at once. On Windows and Linux, apparently, the network stack would dutifully pause those requests while the radio took a moment to reestablish connection. Mac OS x, adhering to the spec, did not pause but instead immediately reported on wake that the network was unavailable. So, the other browsers on Mac OS wisely broke speck and ignored the first couple network down that came in after sleep, quietly retrying rpcs. Chrome adhered to spec and dutifully reported the dropped network as an error that failed all those rpcs. As a result, client's page was broken, but only on Mac os, only on wi-fi, and only on Chrome. Would you guess that their first solution was to painstakingly rewrite all of their set timeout logic to move the retries up to the JavaScript layer, or would you guess that their first solution was to report a bug to Google and tell their regular users Chrome was broken? In any case, it's a moot point now because at some point Chrome changed their network stack implementation to match everybody else's. ;)

peaBerberian 4y 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 4y ago
Is the player you're working on public? Does the Picture-in-Picture API do what you need now?
- happytiger 4y ago
  That's Paul. His product is https://github.com/canalplus/rx-player https://github.com/canalplus/rx-player

shadowgovt 4y 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."

matheusmoreira 4y ago
Might as well create site-specific browsers.
- mey 4y ago
  I believe those are called native apps.
  - matheusmoreira 4y ago
    It's useful to distinguish between them, though. Apps are almost always first party software that only does what's officially supported. Browsers have a long history of customizability, extensibility, programmability, adversarial interoperability. What if instead of browsers and ad blockers we had an extensive collection of web scrapers for every web site out there?
    - truemotive 4y ago
      I do believe we have all of those things currently, but with the scrapers working against the human condition. Our only recourse is smart human scrapers but that job sucks really fast.
- shadowgovt 4y ago
  It's more in the category of "the new kid on the block tries to implement to spec and discovers what everyone else already knows: spec's hosed." I once received a bug report on a site that consistently went down after a computer woke from sleep... But only if the computer was a macintosh, and only if the browser was Chrome. It turned out that the root cause was that when the machine slept and reawoke, XML HTTP requests that were attached to timers in an open webpage would fire all at once. On Windows and Linux, apparently, the network stack would dutifully pause those requests while the radio took a moment to reestablish connection. Mac OS x, adhering to the spec, did not pause but instead immediately reported on wake that the network was unavailable. So, the other browsers on Mac OS wisely broke speck and ignored the first couple network down that came in after sleep, quietly retrying rpcs. Chrome adhered to spec and dutifully reported the dropped network as an error that failed all those rpcs. As a result, client's page was broken, but only on Mac os, only on wi-fi, and only on Chrome. Would you guess that their first solution was to painstakingly rewrite all of their set timeout logic to move the retries up to the JavaScript layer, or would you guess that their first solution was to report a bug to Google and tell their regular users Chrome was broken? In any case, it's a moot point now because at some point Chrome changed their network stack implementation to match everybody else's. ;)