Jump to content
Search Community

Draggable initialization causes scrollbars to appear in IE11

loueradun test
Moderator Tag

Go to solution Solved by Jonathan,

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

When calling Draggable.Create() on any element on the page, there is a momentary blip of horizontal and vertical scrollbars in IE11 (works fine in IE 9, 10, Chrome, Firefox, Safari).

 

In the codepen I set up a case where 1000 divs have the Draggable applied, but the issue still exists when applied to a single element.  I set it up this way so it could be easily demonstratable and the scrollbars would appear for a longer period of time.  On a site with a lot of elements and extensive javascript the scrollbars appear long enough for the user to notice.

 

See the Pen gaBYGe by anon (@anon) on CodePen

Link to comment
Share on other sites

That is normal behavior.. especially for buggy IE. it is best practice when using any time of draggable effect. To add the CSS property overflow:hidden; either to your <body> tag or to the parent of the Draggable elements. This way if your draggable element goes past the bounds, the scroll-bars would be hidden.

 

By default, all browsers have their overflow property set to visible on elements and the body tag. So just add overflow:hidden to your element draggable parent or to the <body> tag.

body {
   overflow:hidden;
}

CSS overflow property: https://developer.mozilla.org/en-US/docs/Web/CSS/overflow

 

:)

Link to comment
Share on other sites

I would only apply the overflow hidden on your body tag and on your div. You could have issues applying it to everything with the universal selector (*).

 

You shouldn't have to add overflow:hidden on anything in your case, unless you do not want scrollbars on your main browser window. If so then only add overflow:hidden on the body tag only.

 

Always first set up your scene giving your draggable elements a width and height.

 

IE is really strict about not adding height and width on items. In your CSS you have no layout CSS declared.. You need to add some CSS for width and height of your Draggable <div> .. otherwise IE will behave badly.

 

As best practice always setup your scene with CSS first and then apply your JS. So try and add width and height on your draggable elements.

 

See the Pen qOJBmo by anon (@anon) on CodePen

 

So you need to set width, height, background-color, etc on your <div> tags. You were adding 1000 <div> tags to the body tag. So IE was adding them. But you did not define the width and height of the <div > tags. So that is why you saw the scrollbars. The browser has no way of knowing what the <div> tags width and height are, especially when you are creating 1000 instances of them.

 

And always give your elements a width and height or you will have issues, especially in IE.

 

:)

Link to comment
Share on other sites

By not giving a width and height the div's height are auto ... IE needs a height. IE requires a width and height.

 

But there is scroll bug in IE, this is due to the height of the <html> tag.

 

See the Pen MaPYxz by jonathan (@jonathan) on CodePen

 

In my example i do an old IE hack to get around this IE bug, which has been around since IE8. Look at my CSS.. i set the html and body to 100% and give my draggable parent container position relative; and width and height of 100%

 

You should never apply position relative on your body tag. Or you will have issues cross browser when positioning your elements. You should create a parent div that is your container with position relative, and have your draggable elements positioned absolutely within that parent.

html, body{
  height:100%; /* fix for IE scroll flash bug */
}

body {
  background-color:black;
  color: white;
  padding:0;
  margin:0;
  width:100%;
  height:100%;
}

#wrapper {
  overflow:hidden;
  position: relative; /* all children will be relative to this parent */
  width:100%;
  height:100%; /* fix for IE scroll flash bug */
}

#wrapper div {
  position: absolute;
  top:0;
  left:0;
  height:100px;
  width:100px;
  background-color:#CC0000;
}

And append your <div> tags to the parent container #wrapper

var i = 1000,
    $bodyWrapper = $('body #wrapper'); /* cache body #wrapper in the DOM for use in the loop */
while (i > 0) {
     $bodyWrapper.append( "<div></div>" );
     i--;
}

Draggable.create("#wrapper > div");

This is a IE bug, so its best  to just use a parent <div> and use that as your container. Never use the body tag a point of reference for absolutely positioned elements. Since for this very reason IE will misbehave, like you have seen with the scroll bars flashing in and out.

 

As best practice always setup a width and height on your container and on your draggable elements. If you need to use the entire page width and height. Then set your width and height of your container to 100%, like i do in my a example above.

 

:)

  • Like 5
Link to comment
Share on other sites

The only solution that I had any luck with was setting the body height to 100% which isn't really workable with the other plugins used on the site.

 

After some further searching, I have found the offending code that is causing the scrollbars to appear:

// in some browsers (like certain flavors of Android), the getScreenCTM() matrix is contaminated by the scroll position. We can run some logic here to detect that condition, but we ended up not needing this because we found another workaround using getBoundingClientRect().
div.style.cssText = "width:100px;height:100px;overflow:scroll";

If I change that line to contain overflow:hidden, the problem is resolved, however I don't know if that will cause any side affects with the plugin.

Link to comment
Share on other sites

Am I the only one that can't see any scrollbar flash? And I don't think that piece of code is related to your problem. That looks like something that has to do with SVGs. If a body height of 100% is messing with your plugins, sounds like your plugins might be the problem.

  • Like 2
Link to comment
Share on other sites

Hey guys! 

 

I wanted to take a look at this myself to see what all the fuss is about, so here is what I came up with.

 

First, make sure you are using IE 9-11,  this obviously doesn't show up in Chrome or Safari.

 

1) Using the codepen URL that louredun first posted,  

I absolutely see the scrollbars showing on his pen.  So the problem is obviously there on "his" demo.

 

2) Using the codepen URL that Johnathan providen, 

See the Pen MaPYxz by jonathan (@jonathan) on CodePen

Its no longer there.

 

So i said, ok..  well... is it really still there but hidden?  and the answer is, yes, its absolutely still there.

 

take this example.  You have a big roach on your floor, and your friend walks in and says, "HEY! its a roach!!!" and you then walk over and throw a carpet down over the top of it and say.. no its gone?  i don't see it.   

 

So the question is, is the roach still there? or is it gone?   well, its still there, its just hidden from view. and thats exactly what johnathan's code does.  

 

See setting the HTML and body to 100% height, and settings a wrapper to 100% height basically puts the scrollbars that loureadan is seeing down below the viewport.  its absolutely still there you just don't see it because your seeing a div 100% the size of your screen. 

 

so you can debate if thats a actual fix, or just a way to hide the bug.  thats up to you.

 

now.. 

 

next point: 

 

loureadon says this code is causing the scrollbars in IE11, so i forked johnathans demo, modified the heights to 200px so you can indeed see the scrollbars are still there, and then i took louredans code and modified it IN draggable so that it has a background of GREEN and a custom size of 250px, and guess what... the scrollbars you see are absolutely 250px and green.  so its definetally the offending code.  

 

See the Pen OyaWeL by Zuriel (@Zuriel) on CodePen

// in some browsers (like certain flavors of Android), the getScreenCTM() matrix is contaminated by the scroll position. We can run some logic here to detect that condition, but we ended up not needing this because we found another workaround using getBoundingClientRect().
div.style.cssText = "background:green;width:250px;height:250px;overflow:scroll";

so his question is valid, will changing that code have an effect on IE9-11 (if you made it overflow:hidden).  Also is this a actual bug?  if this code is suppose to be for android, why does it show up on internet explorer, can the next version of greensock draggable just check for android and do that code, or like (if !IE) do the code?

Link to comment
Share on other sites

I could not see the scrollbars on Android.. i tested on Android 4.0, 4.1, and 5.1

 

Android 4.1 and above use Chrome as their default browsers. Android 4.0 and below use the Android stock browser.

 

I tested on 4 different PC's with Windows 7 (64-bit) and only one out of the 4, i saw this scrollbar issue. All had IE11 version 11.0.9600.17959 .. latest windows update.

 

Oh and Zuriel its Jonathan not Johnathan, nice roach analogy, but my fix above was not meant to hide the roach, and ignore the issue, since they are disease carriers. Just like IE is with there overflow bugs :)

  • Like 1
Link to comment
Share on other sites

  • Solution

Here is my same example from above with the #wrapper height at 250px and a white border so you cant say I'm shoving roaches under the rug!

 

See the Pen zvMwwg by jonathan (@jonathan) on CodePen

 

I use another IE hack to get around this IE overflow bug.

html {
   -ms-overflow-style: none;
}

I just tested on all 4 of my PC's and even on the offending PC that i previously saw this overflow shenanigans on in IE11. And i don't see it any more.

 

One thing i have spent countless years and hours on is debugging IE since IE 5.5, so i hope this helps others :D

 

Due note that i had to bring the <div> tags created down to 100 since IE11 in codepen was crashing onload with 1000.

 

Reference:

-ms-overflow-style property: http://msdn.microsoft.com/en-us/library/ie/hh771902(v=vs.85).aspx

 

Also see this other post on page 2 for an IE check so it doesn't affect scroll-bars globally, and is removed after window onload:

 

http://greensock.com/forums/topic/13088-draggable-initialization-causes-scrollbars-to-appear-in-ie11/page-2#entry54301

 

:)

  • Like 2
Link to comment
Share on other sites

The part I was curious was in this comment:

// in some browsers (like certain flavors of Android), the getScreenCTM() matrix is contaminated by the scroll position. We can run some logic here to detect that condition, but we ended up not needing this because we found another workaround using getBoundingClientRect().

There are 2 things here, first, this fix was added for android (I would assume ones not using chrome as their default browser).  It also states that they ended up not using this because another workaround was identified using getBoundingClientRect().

 

So basically I have two questions here.

1) Do we know why we are creating this div with overflow:scroll?

2) Are we actively using this workaround in the code?  Can we remove the overflow:scroll without any negative effects?

 

I could just go through and test every browser but without knowing what the workaround was trying to fix I don't know what I might be breaking.

 

P.S. Jonathan, Zuriel mangled my name as well  :mrgreen:

Link to comment
Share on other sites

loueradun try my

See the Pen zvMwwg by jonathan (@jonathan) on CodePen

in IE11 from my last reply and let us know if you still see the scrollbars.

 

Also i added my fix to your original codepen from above and it fixes it as well:

 

See the Pen bVQWaM by jonathan (@jonathan) on CodePen

html {
   -ms-overflow-style: none;
}

Reference:

-ms-overflow-style property: http://msdn.microsoft.com/en-us/library/ie/hh771902(v=vs.85).aspx

 

:)

  • Like 2
Link to comment
Share on other sites

Hi Jonathan,

 

Thanks for the reply.  I guess I was writing mine as it came through.

 

I can verify that adding the -ms-overflow-style: none to the html element definitely resolves the issue.  I will need to take some time to make sure there aren't any side effects to applying this to the html.  I may be able to just add that style to the appending div in that line of code posted earlier if there are other issues caused by adding it to the root html element (perhaps the plugin should do this as well so the issues doesn't come up again in the future).

 

Thanks for everyone's help on this.

  • Like 1
Link to comment
Share on other sites

yeah i added the -ms-overflow-style: none;}and that did indeed fix those scrollbars!  

 

Sorry everyone for butchering your names!  This is why I have a realtime code validator in my IDE :)   Glad this is resolved ;)  Love my tweenmax

  • Like 1
Link to comment
Share on other sites

Just a quick note.. IE has always had issues or bugs with the CSS overflow property. I have come across at least 5-6 different IE overflow bugs since IE 5.5, depending on various other CSS properties that might be on the same tag, inherited from a parent, or missing width and height.

 

The reason the above works is due to -ms-overflow-scroll  property being inherited, since it is at the root of the DOM, its descendants inherit the property from its ancestor the <html> tag

 

I knew this wasn't a GSAP bug, due to IE always leaving crumbs around for those pesky bugs. But at least this is resolved.. sometimes you have to force IE to play nice and clean up after it self.

 

:)

Link to comment
Share on other sites

I still don't know why Zuriel was seeing a green background. That line of code that keeps getting referenced is a temp div and is removed. I know Jonathan showed a fix, but I think the problem in these demos might have something to do with the code. 1000 Draggables all being created using "div" as a selector.

Link to comment
Share on other sites

I think there were using a custom script for Draggable, and added that green and div append on

 

Line 327

http://zadesigns.com/test.js

 

You can see it in the JS panel of Zuriel and loueradun codepen:

See the Pen OyaWeL by Zuriel (@Zuriel) on CodePen

 

I think they just added it to show that it was green, but not sure.

 

But this was a IE bug and not a GSAP bugarooni :)

Link to comment
Share on other sites

Yeah, I saw that. But the while loop and then creating Draggables outside the loop is locking the UI up twice. And look at the console. The CSSPlugin is not ready, but if you reorder the scripts, the message goes away. That's why I was saying to use TweenMax.

 

I still have doubt's that this is even issue. Maybe a loading issue. Loading the CodePen editor with IE is really slow. Can the problem be replicated using TweenMax, without CodePen (or at least in debug mode), and without using such a large number for for the loop? And check the console first.

Link to comment
Share on other sites

I tried to rule out codepen, but when i was testing locally with the first codpen example i used the latest TweenMax and latest Draggable and Throwprops (latest being 1.18.0) .. i only saw it on one of my 4 home PC's on Windows 7 (64-bit) locally in IE11. And I also saw it on my work PC Windows 7 (64-bit) on IE11. But after i applied the -ms-overflow-style on my same local copy, i no longer saw the issue on the problematic IE11 PC. I only realized it was an issue when i saw it on 2 different PC's running Windows 7 (64-bit). One at home and another at work.

 

Since you were not seeing it in Windows 10 and in IE11 or IE Edge.. means that Microsoft probably fixed this bug in those builds for Windows 10. Or it only affects Windows 7 (64-bit)

 

Not sure what was going on.. but i have seen this weird overflow before in IE10 when it first came out. Like a scrollbar flashing vsiible and then disappears. But i think that the CSS property -ms-overflow-style was created for IE10 and above for this reason, and it probably address Internet Explorers overflow buggy poopy-pants in this situation.

 

IE has a habit of going against the grain as we see with this stupid vendor prefix for overflow-style, which is only supported in their dopey browser. So they create a bug and then create a CSS property to fix that bug, instead of fixing that specific bug. Gotta love Microsoft IE, the bane of every web developers existence. :D

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...