(In reply to Hiroyuki Ikezoe (:hiro) from comment #33) > Okay, so using InactiveRefreshDriverTimer means the situation is similar to background tabs. what I don't quite understand is why rAF callback is invoked, isn't it constantly invoked? I mean if script tries to register rAF every time in the callback, is it repeatedly invoked? Yes. I tried to call rAF callback per 5 seconds. e.g. ``` function rAF() { dump("a rAF callback is invoked\n"); setTimeout(() => { requestAnimationFrame(rAF); }, 5000); } ``` And with fission, in the hidden OOP iframe (with inactiveRefreshDriverTimer), the rAF is not constantly invoked. The period between two rAF callbacks is a little be random. Mostly it's more than 5 seconds. > I am also wondering it might be possible that animation.ready is fullfilled 1 minutes later or so? Because in my understandings, InactiveRefreshDriverTimer isn't just triggering tick often. No. I didn't see any animation.ready happened after 1 minutes. We mark the BrowserChild as hidden or visibility in [BrowserChild::UpdateVisibility](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2835-2846). If this should be hidden, we set its [preshell as inactive](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2898), which throttles the nsRefreshDriver. That's why we are using inactiveRefreshDriver for the OOP iframe. So now I think rAF is also buggy in this case.
Bug 1578309 Comment 34 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #33) > Okay, so using InactiveRefreshDriverTimer means the situation is similar to background tabs. what I don't quite understand is why rAF callback is invoked, isn't it constantly invoked? I mean if script tries to register rAF every time in the callback, is it repeatedly invoked? Yes. I tried to call rAF callback per 5 seconds. e.g. ``` function rAF() { dump("a rAF callback is invoked\n"); setTimeout(() => { requestAnimationFrame(rAF); }, 5000); } ``` And with fission, in the hidden OOP iframe (with inactiveRefreshDriverTimer), the rAF is not constantly invoked. The period between two rAF callbacks is a little be random. Mostly it's more than 5 seconds. > I am also wondering it might be possible that animation.ready is fullfilled 1 minutes later or so? Because in my understandings, InactiveRefreshDriverTimer isn't just triggering tick often. No. I didn't see any animation.ready happened after 1 minute. We mark the BrowserChild as hidden or visibility in [BrowserChild::UpdateVisibility](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2835-2846). If this should be hidden, we set its [preshell as inactive](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2898), which throttles the nsRefreshDriver. That's why we are using inactiveRefreshDriver for the OOP iframe. So now I think rAF is also buggy in this case.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #33) > Okay, so using InactiveRefreshDriverTimer means the situation is similar to background tabs. what I don't quite understand is why rAF callback is invoked, isn't it constantly invoked? I mean if script tries to register rAF every time in the callback, is it repeatedly invoked? No, it doesn't. I tried to call rAF callback per 5 seconds. e.g. ``` function rAF() { dump("a rAF callback is invoked\n"); setTimeout(() => { requestAnimationFrame(rAF); }, 5000); } ``` And with fission, in the hidden OOP iframe (with inactiveRefreshDriverTimer), the rAF is not constantly invoked. The period between two rAF callbacks is a little be random. Mostly it's more than 5 seconds. > I am also wondering it might be possible that animation.ready is fullfilled 1 minutes later or so? Because in my understandings, InactiveRefreshDriverTimer isn't just triggering tick often. No. I didn't see any animation.ready happened after 1 minute. We mark the BrowserChild as hidden or visibility in [BrowserChild::UpdateVisibility](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2835-2846). If this should be hidden, we set its [preshell as inactive](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2898), which throttles the nsRefreshDriver. That's why we are using inactiveRefreshDriver for the OOP iframe. So now I think rAF is also buggy in this case.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #33) > Okay, so using InactiveRefreshDriverTimer means the situation is similar to background tabs. what I don't quite understand is why rAF callback is invoked, isn't it constantly invoked? I mean if script tries to register rAF every time in the callback, is it repeatedly invoked? No, it isn't. I tried to call rAF callback per 5 seconds. e.g. ``` function rAF() { dump("a rAF callback is invoked\n"); setTimeout(() => { requestAnimationFrame(rAF); }, 5000); } ``` And with fission, in the hidden OOP iframe (with inactiveRefreshDriverTimer), the rAF is not constantly invoked. The period between two rAF callbacks is a little be random. Mostly it's more than 5 seconds. > I am also wondering it might be possible that animation.ready is fullfilled 1 minutes later or so? Because in my understandings, InactiveRefreshDriverTimer isn't just triggering tick often. No. I didn't see any animation.ready happened after 1 minute. We mark the BrowserChild as hidden or visibility in [BrowserChild::UpdateVisibility](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2835-2846). If this should be hidden, we set its [preshell as inactive](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2898), which throttles the nsRefreshDriver. That's why we are using inactiveRefreshDriver for the OOP iframe. So now I think rAF is also buggy in this case.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #33) > Okay, so using InactiveRefreshDriverTimer means the situation is similar to background tabs. what I don't quite understand is why rAF callback is invoked, isn't it constantly invoked? I mean if script tries to register rAF every time in the callback, is it repeatedly invoked? No, it isn't. I tried to call rAF callback per 5 seconds. e.g. ``` function rAF() { dump("a rAF callback is invoked\n"); setTimeout(() => { requestAnimationFrame(rAF); }, 5000); } ``` And with fission, in the hidden OOP iframe (with inactiveRefreshDriverTimer), the rAF is not constantly invoked. The period between two rAF callbacks is a little be random. Mostly it's more than 5 seconds. > I am also wondering it might be possible that animation.ready is fullfilled 1 minutes later or so? Because in my understandings, InactiveRefreshDriverTimer isn't just triggering tick often. No. I didn't see any animation.ready happened after 1 minute. We mark the BrowserChild as hidden or visibility in [BrowserChild::UpdateVisibility](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2835-2846). If this should be hidden, we set its [preshell as inactive](https://searchfox.org/mozilla-central/rev/200bfc652c5128011e7725fc7c201eb125d453e7/dom/ipc/BrowserChild.cpp#2898), which throttles the nsRefreshDriver. That's why we are using inactiveRefreshDriver for the OOP iframe. So now I think rAF is also buggy in the "hidden" OOP iframe.