Change:
* Listens to window scroll and resize events. We cache scroll values so that * application code can access them without triggering reflows. * <ins> * ViewportMetrics is only used by SyntheticMouse/TouchEvent and only when * pageX/pageY isn't supported (legacy browsers). * </ins> * NOTE: Scroll events do not bubble. * * @see http://www.quirksmode.org/dom/events/scroll.html */ <del> ensureScrollValueMonitoring: function() { if (!isMonitoringScrollValue) { </del> <ins> ensureScrollValueMonitoring: function(){ if (hasEventPageXY === undefined) { hasEventPageXY = document.createEvent && 'pageX' in document.createEvent('MouseEvent'); } if (!hasEventPageXY && !isMonitoringScrollValue) { </ins> var refresh = ViewportMetrics.refreshScrollValues; ReactBrowserEventEmitter.ReactEventListener.monitorScrollValue(refresh); isMonitoringScrollValue = true;

Discussion:
React adds a scroll listener that tracks and caches the scroll position (I assume for some undocumented internal purpose). Additionally, the scroll listener forces a synchronous layout (see screenshot). This seems wasteful, especially considering that the values tracked are never exposed in the API. What is the scroll listener used for? Can it be removed? !
ViewportMetrics is used to normalize pageX and pageY on mouse events: . Perhaps ironically, it was created to prevent synchronous layouts during mouse event handlers.
I wish these values (as well as the event) were somehow exposed.
:+1:
BTW you can obviously have this if you use a Webpack-like bundler:
Well, is only used for IE8 and possibly other very old browsers (), so we should be able to just disable it for all other browsers and everyone is happy right? (Could still be optimized slightly for IE8... if anyone cares) Also, That makes no sense at all to me, does not take an argument, yet we get the scroll position and provide it as an argument. Instead, gets the scroll position internally and uses that? So we call twice, but only use the result once (also, this should be broken for events inside iframes, for IE8). Also2, I'm pretty sure any browsers that supports touch, also supports . cc
I agree that we shouldn't be tracking it in other browsers if we don't need it. I don't know if there's a way to predict whether we'll have .pageX and .pageY before mouse events actually come in.
:)
Another idea being just let resize/scroll set a flag, when a mouse event is created, if the flag is set, update viewport metrics. That way we only update it when needed, but could potentially cause a reflow if there are other events before it (very unlikely though I imagine).
This issue causes React based longer lists unusable on mobile.
Is there any progress on this issue? I’m not sure if this is the root-cause for pages rendered with react scrolling extremely slow with firefox mobile on android (e.g. this react website ).
Is that your site? If so, you can try commenting out the logic in refreshScrollValues to see if it makes a difference. If it does, I'm happy to prioritize and try to get it in.

No, that is not my site, it is an example react & fluxible page (see: ), but we have exactly the same issues with scrolling on firefox mobile. I’ve applied the changes in manually and it doesn’t solves the problem, so this issue might be unrelated to my problem. I will investigate further. Thanks for considering to prioritize this. Much appreciated.