New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Fixed
Closed: Aug 2017
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 718246: WebVR: Do not fire window.requestAnimationFrame while presenting on Android

Reported by, May 4 2017 Project Member

Issue description

[This is the opposite of  issue 704341  and reflects a change in desired behavior on Android.]

The consensus seems to be that window.requestAnimationFrame should be tied to page visibility. [1]

Thus, we should not fire window.requestAnimationFrame on Android when WebVR is presenting. This may cause issues for some sites or libraries. Those will need to be fixed.

[1] as well as internal discussions.

Comment 1 by, Jun 7 2017

Labels: -M-60

Comment 2 by, Jun 7 2017

Labels: -Pri-3 M-61 Pri-2

Comment 3 by, Jun 7 2017

This may affect some apps. As such, we should do it early in the milestone. We should also reach out to those that were affected last time rAF was not fired on Android. This includes threejs, which is mentioned in  issue 704341 .

Comment 4 by, Jun 9 2017

+ricardocabello for the ThreeJS question.

This will cause a whole bunch of subtle bugs, I think. For many people their loop looks something like:

function main() {
  if (display.isPresenting) {
  } else {

This gives you one frame after entering presentation mode where you are driving the VR loop from a window rAF, which I assume will no longer be fired. I imagine this just kills the loop altogether.

Developers should, of course, cancel the rAF when they begin/end presenting and call the correct one, but due to being *very slightly* more complicated, I wonder if many people currently do it correctly.

Comment 5 by, Jun 9 2017

We actually handle this case explicitly, by manually firing a single extra window rAF after presentation starts.

Should this be part of the spec? Other implementers may have different behavior here in the future. Or does the 2.0 spec address this somehow?

Comment 6 by, Jul 10 2017

Megan, what's the next step here?

Comment 7 by, Jul 27 2017

Labels: -Pri-2 -M-61 M-62 Pri-1

Comment 8 by, Aug 11 2017

Owner: ----
Status: Available (was: Assigned)
I believe this is just a matter of reverting the CL in  issue 704341  (and verifying behavior). It doesn't revert cleanly, but it is small.

Comment 9 by, Aug 23 2017

Status: Started (was: Available)

Comment 10 by, Aug 24 2017

Project Member
The following revision refers to this bug:

commit 1b6a5e96191538ad8a4e0918a14b8724016b4d27
Author: Christopher Grant <>
Date: Thu Aug 24 14:19:08 2017

VR: Do not fire window.rAF while presenting

As per the associated bug, we're reverting an extra call to
window.requestAnimaionFrame. Separate code already triggers a rAF when
presentation starts.

BUG= 718246 

Change-Id: I5bf961749d80476572f1610a3992e62a4e6a5301
Reviewed-by: Michael Thiessen <>
Reviewed-by: Brandon Jones <>
Commit-Queue: Christopher Grant <>
Cr-Commit-Position: refs/heads/master@{#497034}

Comment 11 by, Aug 24 2017

Status: Fixed (was: Started)

Comment 12 by, Jul 4 2018

Components: Blink>WebXR

Sign in to add a comment