The craziness of iframe’s “Scrolling” attribute on Webkit browsers

iframe it sucks, let’s put it behind us.

Sometimes, just sometimes, we (not you, of course) have to use it. Why? Maybe to show an older part (ASP.Net) in your app inside a newer (React 16.* / node.js) part. Maybe because of bad architecture. You name it, it exists and it’s a fact.

If you familiar with iframe you probably familiar with its attribute scrolling . In short, Indicates when the browser should provide a scrollbar for the frame.

Wait, are we still using scrolling ? Isn’t html5 “Obsolete”?! Well, it does, but sadly there are, still, some browsers, yes even Chrome, that count on “scrolling” attribute and doesn’t count on overflow: scroll / hidden.

Obviously, if you can set it hard coded, you can change it using script, right?

Well, not in all cases. It depends on that initial definition. If it was “truthy” (attribute not exists or its value is true) the code will work. If it start with no, the code will not work. Don’t believe me?

You could this that you can bypass this issue by hiding the scrollbar with css. Sorry, bad news for you, it will not work (I tested on Chrome 71 on mac as you can see).

But what if you want to hide the scrollbar at the begging and then change it? Well, the answer is simple, hide it with script:

Yes, you see correctly. There is setTimeout in the code. Why is that? well, apparently, if you change the attribute while the iframe is not fully loaded, it will not work. Because of my site is super fast (github-pages) it takes only 30ms to load. I tried another website and the timeout should be 1 second to work. CRAZINESS, right?

Conclusions

• Avoid iframe if you can. It will save you some years in your life and some neurones in your brain.

• If you really have to, try to avoid the need to change scrolling dynamically.

• If you really have to (just like me), start with scrolling="yes"and hide with script.

If it will ever been fixed, please let me know so I could unpublish this embarrassing post.