This might seem like a strange edge case, but it’s pretty important to something I’m working on.
Here’s a link to a demo. (It’s using some strange sandbox site because it was one of the only sandbox sites that doesn’t use the sandbox attribute on its ‘live-load’ iframes, which was causing conflicts with some jQuery plugin your player uses). Make sure to click the JS tab up top to see the script.
The code snippet is adjusting the transform scale of the embedded Twitch.tv iframe player constantly and initially the Chrome version looks identical to the Firefox or Safari version. However, whenever you set focus on the input element in the demo you’ll see that in the Chrome version the Twitch.tv player seems to readjust and resize its internal elements, which seems like incorrect behavior to me. The Firefox and Safari versions don’t do this at all. It’s almost as if the Twitch.tv player knows the bounding rectangle size (post-transform pixel size) of itself.
It may very well be a chrome bug, but it’d be very useful to know how size is passed to your Flash plugin so I can continue debugging this issue. I’m also curious why this resize is triggered on focus of the input. Any advice / insight would be greatly appreciated- Thanks!
Considering Twitch is moving to a new player, I doubt very much they are concerned about the flash player.
If you don’t need the JS API, you can use the new player. Hopefully Twitch will release an IFrame API when it’s ready (they actually already have one, but it doesn’t work unless origin is Twitch’s main site).
Thanks for the response and the link to the new player, night.
After playing around with it for a while though, it seems to be having similar problems. I wish I could share a demo but I couldn’t seem to get it working on any of these sandbox sites.
Though the controls are in HTML5, the player is still in Flash and that seems to be a problem for Chrome- at least when applying transforms. To me, it looks as if the Flash player is somehow getting resize events when it shouldn’t, (with the wrong value too)…
The more I play around with this the more I think this is just a Chrome bug. I’m going report the issue and if / when they get back to me I’ll make sure to update this thread.
Resizing the controls based on the size of the player seems like expected behavior. I suspect the issue has to do with using css transforms on an iframe. I modified your code to set the height and width attribute instead of using a scale transform and it worked just fine.
I’m curious what the actual use case is here. Perhaps we can offer an alternative solution?
Here’s a little more context. I am building a 3D chat room for Twitch.tv streams and the player is mounted on the wall using with CSS transforms. As you move around in the room the transforms change because the player’s perspective changes.
I know this is probably not a high priority use case for Twitch but eh
I updated the demo to use translateZ instead of scale to better illustrate the issue. TranslateZ is moving the element back and fourth in the scene. The element remains 300px by 300px the entire time.
This quote from an MDN article seems relevant:
In case of transforms, the offsetWidth and offsetHeight returns the element’s layout width and height, while getBoundingClientRect() returns the rendering width and height. As an example, if the element has width: 100px; and transform: scale(0.5); the getBoundingClientRect() will return 50 as the width, while offsetWidth will return 100.
My best guess right now is that Safari and Firefox are using offsetWidth and offsetHeight, while Chrome is using the ‘rendering width and height’ from the bounding client rectangle?
