After reading this blog post, I was just wondering:
What are the possible ramifications for Meteor apps?
That’s potentially worrying.
One of the respondents (Timothée Groleau) did make this comment, however:
Even in backgrounded tabs, messages from web workers and incoming messages on websockets are processed as they happen, so there is an opportunity to take some action on these events. For websockets, a ping-pong protocol driven by the server should work just fine.
Which is what Meteor does, so it could be fine.
2 Likes
From what I understood of it, messages will happen, but anything that mutates the dom will not actually do so immediately, so there are potential edge cases and race conditions made more prevalent than they were in the past. For example, data loads in the background, dom is “updated” then you go to query the dom, the update hasn’t happened yet. The safest way to ensure that you are always working with the dom that has been updated is a little known function on window: requestAnimationFrame. What that function does is trigger a callback passed into it immediately before the next paint. At this point dom and layout are updated so you can get the true changes to the dom.
2 Likes
Comment on the Intent to Ship thread if you’re worried about this…
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/XRqy8mIOWps/LvBUbWbxAQAJ
Download Chrome 56 Beta to test your app:
https://www.chromium.org/getting-involved/dev-channel
And file a bug here:
https://chromiumbugs.appspot.com/?token=XCKjBqKrmakiNeJzuAwpMzoxNDg1MzYxNzUy&role=&continue=https%3A//bugs.chromium.org/p/chromium/issues/entry.do
1 Like
The issue was already closed. Apparently it will not be affected, but we have to test it.
Hmm. I’ve use requestAnimationFrame in my gauge package and while that does provide a callback at the start of a paint cycle (typically 60 times a second), it doesn’t in and of itself do anything useful. That callback will not be triggered if the tab isn’t active (usually desired behaviour for mobile apps, as it saves battery).
Maybe I’m misunderstanding what you’re saying.
the callback will only fire once (though you can register a new one for the next paint immediately) and will do so after all dom manipulations.
It’s a relatively common pattern to do something with the DOM after blaze is done with it. For example, showing a bootstrap datetimepicker on certain conditions. You want to after data has changed (using an autorun) do something with the changed dom. The thing is there’s no way to know that blazes changes have actually affected the dom with changes like this. There’s some question about exactly how it works, but basically the DOM has never guaranteed to be completely updated by the time the mutation calls return. When the window has focus, (or in the past even when it didn’t) this was a relatively minor issue as DOM updates were “fast enough” that 99% of devs never notice these kind of edge cases. However, with this happening as I understand the behavior, it means that dom manipulation libraries will return but the dom won’t be actually updated, such that dom query libraries won’t get the new updates until the tab gets focus.
RAF solves that by not firing either until the tab regains focus. Effectively, it helps with situations where you need to know that the dom is fully updated.
It in the past was a rare edge case (which I have encountered once in over 10 years of development). With this throttling though, it could get far more common, but fortunately, the tools already exist to manage it.