{"id":352,"date":"2019-08-31T16:07:06","date_gmt":"2019-08-31T16:07:06","guid":{"rendered":"https:\/\/stuff.tamius.net\/sacred-texts\/?p=352"},"modified":"2019-08-31T20:31:18","modified_gmt":"2019-08-31T20:31:18","slug":"ultrawidify-and-the-improper-cropping","status":"publish","type":"post","link":"https:\/\/stuff.tamius.net\/sacred-texts\/2019\/08\/31\/ultrawidify-and-the-improper-cropping\/","title":{"rendered":"Ultrawidify and the Improper Cropping"},"content":{"rendered":"\n

Yet another day, yet another post about stuff going wrong. This time, I’ve got a bug report that “videos are jumping around” on Facebook and some other pages. I tried to verify the problem … and everything worked fine for me. Then I decided to boot up Windows and there it was \u2014 the problem as described. So nice \u2014 we have a problem that happens on some operating systems and doesn’t on others, even though that shouldn’t be the case in theory.<\/p>\n\n\n\n

But eventually, the issue was reproduced and that’s all that matters. The issue appears very familiar \u2014 it has been observed on reddit before.<\/p>\n\n\n\n

A video and a player<\/h2>\n\n\n\n

In a very ELI5 way, every webpage is made out of a bunch of rectangles (layers, elements), one within another. In order to properly crop a video, we must know which of these elements is actually the player (‘player’ element is to our video what picture frame is to a picture), and we need to know which element is the player element. Picking the wrong element can result in extension cropping to little, too much, or moving the video out of the picture altogether.

We can’t just assume that the first element above the video is a player, either: sometimes sites put addiitonal elements between the two. This is why we need ‘guess’ the player element by looking at the size.<\/p>\n\n\n\n

Side note: not all extensions use that approach. Some seem to just assume you use a 21:9 monitor and slap a ‘enlarge this element by 1.3’ on the video element. Great and foolproof strategy for fullscreen. Less great for youtube’s theater mode, twitch with chat opened at the side, or non-fullscreen Netflix. <\/p><\/blockquote>\n\n\n\n

Legacy and technical debt<\/h2>\n\n\n\n

The code for determining which element is the player element has some weird quirks thanks to the history of the addon. Most notably, the extension used to work by determining how tall and how wide the video should be back in the day when it was only focused on Youtube and Netflix. This method has a few drawbacks, with most notable ones being:<\/p>\n\n\n\n

  1. If you ask browser to tell you the size of the video, it’ll tell you the dimensions you specified<\/li>
  2. It worked for youtube and netflix, but not for everything else<\/li><\/ol>\n\n\n\n

    In general, we can assume that initial size of the player will be exactly as wide as the video or exactly as tall as the video. However, since we actually changed the size of the video (as opposed to telling browser to just enlarge the video by some factor), we couldn’t check for that as if the video was cropped, browser would tell us the post-crop size (and post-crop size is useless for that purpose). Some wonky code was written to deal with this issue and it worked well enough for Youtube and Netflix and sometimes even other sites. However, said code is \u2014 in retrospect \u2014 pretty bad. Looking at it invokes a few questions that every programmer sometimes asks themselves: “the hell was I trying to do with this shit” and “how the fuck did this even work at all?”<\/p>\n\n\n\n

    \"\"
    You could farm karma at \/r\/badcode with this.<\/figcaption><\/figure><\/div>\n\n\n\n

    Due to problems with #2, a better solution to resizing the video needed to be implemented, and eventually it was in the form of transform: scale(x,y)<\/code>. Using this to crop video (as opposed to modifying width and height attributes of the video) has some nifty advantages: it’s possible to get the size of the video without taking transform<\/code> into account. This allows us to rewrite the player detect loop in a way that will correctly detect the player element.<\/p>\n\n\n\n

    Dealing with duplicates<\/h3>\n\n\n\n

    Another thing worth addressing is “duplicates” \u2014 that is, what happens when more than one element on our way from video element to the root of the page has the same size. I haven’t figured out what to do in this case, since the correctness of picking innermost over outermost element for player may differ from site to site. In absence of better options, I decided to score every element that could be our player. Rules of the game:<\/p>\n\n\n\n