css transition : transitionend not received

[GENEVET Lidwine]

I encounter a strange behaviour with a css transition for which transitionend is not received by a callback inside javascript.

 

Version : content_shell stable_1.0.36.0.1985.25 + specific ozone layer for our SetTopBox platform.

 

I could not reproduce it on  chrome same stable version on linux

It was reproduced on chromium lkgr branch from May 24th, but not on a older version from January 8th (revision r243541)

The issue appears with a script called FPSMeter.js.

This script launches webkitRequestAnimationframe to count the frames. At the same time, a transparent 1 pixel css transition moves horizontally on the screen. On webkitRequestAnimationFrame callback, the pixel position is registered. On each end of the css transition (transitionend received), the FPS average is calculated, and the duplicates removed (duplicate = same position of the pixel ).

 

A suite of tests, each one including FPSMeter.js (https://github.com/Orange-OpenSource/orangemark), is launched.

 

On some of the tests inside the suite, sometimes (more frequently on lkgr), transitionend event is not received.

 

 

Some more details :

-          the pixel is first at position <left 0,bottom 0>, then moved to <left 0,bottom bodywidth >, On “transitionend” received, it is moved back <left 0,bottom 0>, then to <left 0,bottom bodywidth > on next transitionend etc…

-          the first transition is done , we can see the pixel on to <left 0,bottom bodywidth >, but the first transitionend is not received.

-          Before beginning the transition, the script waits for the readyState of the document to be “complete”.

-          The window.onloaded callback is called before we launch the transition

 

 

Are there any known issues on css transition that could explain such behavior?

Would the fact that we are using ozone introduce a discrepancy in the behavior? 

How can I tackle the issue and try to fix it?

 

Thanks for your help,

 

Regards,

Lidwine

[Alex Sakhartchouk]

Hi Genevet,

I am not particularly knowledgeable on the css side of things, but in regards to ozone, the only way I could see it being related is with gfx::VSyncProvider. Ozone allows you to create a custom one and the data from it affects scheduling in the Chrome compositor. It's a lead to look into, but if the page keeps rendering, it may not be related. It sounds like you've seen this issue on Linux at some point, so it could be a timing bug that manifests itself on systems with different performance.

-Alex

[Youngsun Suh]

https://codereview.chromium.org/139103009
Try this patch. I also had the same problem on android and it has been fixed by this patch.

[Douglas Stockwell]

On Thu Jul 31 2014 at 1:46:04 AM GENEVET Lidwine <lidwine.ge...@gmail.com> wrote:

I encounter a strange behaviour with a css transition for which transitionend is not received by a callback inside javascript.

Is there a bug tracking this issue? 

Version : content_shell stable_1.0.36.0.1985.25 + specific ozone layer for our SetTopBox platform.

 

I could not reproduce it on  chrome same stable version on linux

It was reproduced on chromium lkgr branch from May 24th, but not on a older version from January 8th (revision r243541)

Does this only reproduce in your specific configuration? If not it sounds like this is a regression which could be bisected.

The issue appears with a script called FPSMeter.js.

This script launches webkitRequestAnimationframe to count the frames. At the same time, a transparent 1 pixel css transition moves horizontally on the screen. On webkitRequestAnimationFrame callback, the pixel position is registered. On each end of the css transition (transitionend received), the FPS average is calculated, and the duplicates removed (duplicate = same position of the pixel ).

 

A suite of tests, each one including FPSMeter.js (https://github.com/Orange-OpenSource/orangemark), is launched.

 

On some of the tests inside the suite, sometimes (more frequently on lkgr), transitionend event is not received.

 

 

Some more details :

-          the pixel is first at position <left 0,bottom 0>, then moved to <left 0,bottom bodywidth >, On “transitionend” received, it is moved back <left 0,bottom 0>, then to <left 0,bottom bodywidth > on next transitionend etc…

-          the first transition is done , we can see the pixel on to <left 0,bottom bodywidth >, but the first transitionend is not received.

-          Before beginning the transition, the script waits for the readyState of the document to be “complete”.

-          The window.onloaded callback is called before we launch the transition

 

 

Are there any known issues on css transition that could explain such behavior?

I'm not aware of any specific issues that would case this.

[GENEVET Lidwine]

Thanks all for your answers.

- The patch https://codereview.chromium.org/139103009 is already committed in the stable version I use. I tried it on the lkgr version, and it does not change the behavior.

- There is an existing bug, on which I added comments  : https://code.google.com/p/chromium/issues/detail?id=388082. On stable branch, I reproduce the bug only with my ozone specific version. On lkgr from May 24th, I reproduced it also with content_shell + ozone + egltest platform. 

- I will have a look at VSync management on our case.

[Lidwine GENEVET]

After further tests, I observed the issue will not occur if, for the first transition, the position of the pixel is changed later (in the tests it is changed after 10 ms, we do not reproduced the issue if it is changed after 50ms).

I also observed, in the case it does not work, that no requestAnimationFrame (so no repaint if I understand correctly) happened between the initial set of position {0,0} and the first time we change the position {0, width}.

When a requestAnimationFrame is received, the issue is not reproduced.

So it looks like that if we change a transition value whereas no "repaint" has occured, the transition does not work, so the transitionend is not received.

It would explain why I do not reproduce this on linux chrome, on which the "repaint" must be most frequent.

The tests work correctly if we wait for the repaint to be finished (two requestAnimationFrame callback) before changing the position.

Is this looks like a correct behaviour of the browser, or shall it be considered as a bug?

Thanks