Material: progress-linear: animation behavior varies in Chrome and IE

[SSPai123]

Solution for variation in animation of md-progress-linear needed

Steps to reproduce the issue:

1. _Couldn't Recreate the issue in CodePen, JSFiddle and Plunkr as the animation issue of the progress indicator depends on the large number of data to be fetched and also not sure why the issue is happening just in the application. Hence attaching the css styles used and explaining in detail about the animation behavior. Hoping that it would suffice_.
2. Facing issue of different animation behavior in md-progress-linear in IE browser and animation behavior varies in Chrome when there is large data to be fetched.

Detailed Reproduction Steps:

1. Currently using material version 1.1.6 for the development of an application.
2. The Html for the linear progress bar used is
   <md-progress-linear md-mode="indeterminate"></md-progress-linear>

The css used for progress indicator and its animation which is used from the material version 1.1.6

md-progress-linear .md-container {
    display: block;
    position: relative;
    overflow: hidden;
    width: 100%;
    height: 5px;
    -webkit-transform: translate(0, 0) scale(1, 1);
            transform: translate(0, 0) scale(1, 1); }
    md-progress-linear .md-container .md-bar {
      position: absolute;
      left: 0;
      top: 0;
      bottom: 0;
      width: 100%;
      height: 5px; 
}
    md-progress-linear .md-container .md-dashed:before {
      content: "";
      display: none;
      position: absolute;
      margin-top: 0;
      height: 5px;
      width: 100%;
      background-color: transparent;
      background-size: 10px 10px !important;
      background-position: 0px -23px; 
}
    md-progress-linear .md-container .md-bar1, md-progress-linear .md-container .md-bar2 {
      -webkit-transition: -webkit-transform 0.2s linear;
      transition: -webkit-transform 0.2s linear;
      transition: transform 0.2s linear;
      transition: transform 0.2s linear, -webkit-transform 0.2s linear;
}

md-progress-linear .md-container.md-mode-indeterminate .md-bar1 {
      -webkit-animation: md-progress-linear-indeterminate-scale-1 4s infinite, md-progress-linear-indeterminate-1 4s infinite;
       animation: md-progress-linear-indeterminate-scale-1 4s infinite, md-progress-linear-indeterminate-1 4s infinite; 
}
    md-progress-linear .md-container.md-mode-indeterminate .md-bar2 {
      -webkit-animation: md-progress-linear-indeterminate-scale-2 4s infinite, md-progress-linear-indeterminate-2 4s infinite;
        animation: md-progress-linear-indeterminate-scale-2 4s infinite, md-progress-linear-indeterminate-2 4s infinite; }

1. The application will be displaying the progress indicator running indeterminately when the data fetch operation is taking place. _Please note the application deals with large amount of data._ In case there is lesser number of data fetched, the behavior of linear loader works as expected.

What is the expected behavior?

The linear loader animation should traverse from left to right and then back to left to right in the loader bar repeatedly till the data is fetched in _both_ Chrome and IE as in the link here.

What is the current behavior?

1. _Chrome_: The linear loader animation traverses from _left to middle and then back to left to middle_ repeatedly in the loader track till the data is fetched in . The bar is not traversing full stretch. just traversing half way when large data is to be loaded.
2. _IE 11_: The loader animation originates from the center of the progress track and traverses in opposite directions (starts from centre, the left end of the bar traverses towards the left and the right end traverses towards the right and this is repeated until the data is fetched)

I want the behavior of the indeterminate linear loader to be same as in this for both the browsers in all the cases.

_Could you please provide us the possible cause and resolution since we are not able to reproduce the same in any Demo (example Code Pen)?_

Which versions of AngularJS, Material, OS, and browsers are affected?

• AngularJS: 1.6
• AngularJS Material: 1.1.6
• OS: Windows 10
• Browsers: Chrome and IE

[Splaktar]

It sounds like your browsers are under heavy load. Is there any way that you can provide a video/animated GIF?

For us to debug and help with this, we'll need a CodePen demo. You may need to simulate CPU load or use a public API to simulate many HTTP requests.

[SSPai123]

Hi @Splaktar,

Unfortunately, I am not allowed to upload any video/animated GIF of the behavior. :( That is the reason why I had to explain the animation behavior in detail.

Demo Link
However, please find this Code pen link where it demonstrates the behavior of linear indicator.

Additional Information:
1. Please note that, in case, the linear loader is not visible for the first time, please perform any minor change (like inserting any space etc) in any file to re-run the program.
2. Also, Please note that, for getting more weird behavior of linear loader, the following condition can be changed
i<randomData.length*x where x is any value>10000 in the below for loop in the dummyFunction() of AppCtrl controller

for(i=0;i<randomData.length*10000;i++){
              $scope.count+=1;
            }

3. Also, Found out that I had given the condition of displaying the linear loader as shown below:

<div ng-show="isLoading">
  <md-progress-linear md-mode="indeterminate"></md-progress-linear>
  </div>

where isLoading is a scope variable in the angularJS controller which is set to true before the server call and set to false once the data is fetched successfully.
When the ng-show="isLoading" is replaced by ng-show="true" in the <div> tag, the behavior of the indeterminate linear loader works as this which is expected in _Chrome_.

Is there any connection to the behavior of animation of loader when variable is assigned to ng-show instead of the value directly?

Any help/response would be truly helpful.

[Splaktar]

Thank you for that CodePen, that's exactly what we needed!

I updated the CodePen to 1.1.10 and removed the CSS to make sure that wasn't causing any issues. I also tried with ng-if and saw the same behavior.

It looks like the animation skips or misses a bunch of frames when the CPU load is very high. I will have to look into how it works. We have some parts of AngularJS Material that use $mdUtil.nextTick() to run queue things up, doing that when the CPU is very busy could cause them to be delayed quite a while. I'll have to investigate some more, but at least I now have a starting point and will be able to verify a fix.

[SSPai123]

Does it mean that the animation issue in IE11 browser is also caused by the CPU load? The behavior of the progress indicator in the IE browser is constant everywhere (as described in the bug statement) no matter the size of data (less or huge).
Couldn't run the codepen demo in IE. Looks like IE no longer support codepen.

Eagerly waiting for any fix/updates.

[Splaktar]

You should be able to run debug view in IE11.

Yes, IE11 has high CPU load just by handling layouts, animations, and styling with a medium number of elements. You can find our IE11 performance guide here.

[SSPai123]

Oh, thanks for the guidelines! We will look into it for implementing the same.
Can you please provide a rough estimate by when this bug would be fixed? And If it's fixed, it would be fixed as part of material version 1.1.6 right?

[Splaktar]

@SSPai123 no problem.

We don't really provide ETAs on bug fixes. If it's important to you, then I would suggest submitting a PR to fix it. I am happy to help review the PR and work on getting it merged in.

The next release is 1.1.11, which is due very soon. This fix would go into 1.1.12 at the earliest (if the community sends a PR).

Please note that our limited resources are currently focused on fixing issues with the labels P1: urgent and P2: required.

[SSPai123]

@Splaktar Thank you! We will work on submitting PR soon and we will definitely need your help in reviewing and merging tasks.

[rk150390]

Has anyone found answer to this question? Even i am also facing the same issue.

If yes please share the solution

[disdyakis]

I looked into this a little bit and this is what I think the issue is: The animation for the loading bar has two properties being animated - position and scale. The scale animation for the two blue bars is being done with a css transform (scaleX) - the animation to move the two bars is being done by animating the left property. In modern browsers, CSS transforms are animated apart from the main thread, while other properties, such as 'left' are animated in the main thread - so when the main thread gets blocked, the translation animation stops, but the scaling animation keeps going.

So it looks like the 'left' animation needs to be changed to a translateX transform, but you can't really do two transforms with different timing functions(as the case is here) without the css getting messy. However, according to this stack overflow it looks like adding a wrapper and animating that with the other transform works fine.

@SSPai123 - have you had any headway on this?

[disdyakis]

also I forked the codepen above to more succinctly show the issue: https://codepen.io/disdyakis/pen/YdevKK

[disdyakis]

Update: I went to fix this using the wrapper solution and it looks like that's only a viable solution if you're translating by absolute lengths as opposed to relative lengths - I guess it makes sense that the part of the rendering process that would need to calculate where things are given percentages also gets blocked! I'm out of ideas at this point - I want to say there's no way to fix this bug and it's a current limitation of browsers ☹️

[SSPai123]

@disdyakis : Unfortunately , I couldn't find any headway to this problem. :( From your research, I understand that the animation properties of the css do not work properly under heavy load which was mentioned earlier by @Splaktar as well.
Isn't there any way to fix this issue? There has to be a solution or atleast a hack for fixing any problem, right.