Bugzilla

There are three possibilities I can think of; bug 1753436 and bug 1758352. 

1. Bug 1571758 caused a performance regression (the former bug, bug 1753436) and the regression was fixed in 99 cycle, but I didn't uplift the fix into 98. So if the shutter is not observable in 99, that's the cause.

2. Bug 1571758 caused another regression (the latter, bug 1758352), it was originally reported with regard to keyboard scrolling bug in theory if the site in question calls scrollBy (or some such) in setTimeout/setInverval (maybe requestIdleCallback?) callbacks it's possible something does wrong there.

3. In the profile in comment 21, I can see the site has at least one scroll event handler, which means we consider the document has scroll-linked effect, and I can see both cases where a nsRefreshDriver::Tick call is processed quite fast (around 4ms) and where the function call takes relatively long (over 10ms), so it's possible we use the same scroll offset on different two frames, that's causing the jitter scroll, see bug 1571758 comment 30 for the detail.

3 is highly suspicious for me. Introducing `force responsive mode ignoring scroll linked effect` would be the only one way I can think of to solve this jitter.

Hmm maybe I am wrong.  It looks like all reporter cases are on Linux? There's something I am not aware of.

There are three possibilities I can think of; the two are bug 1753436 and bug 1758352. 

1. Bug 1571758 caused a performance regression (the former bug, bug 1753436) and the regression was fixed in 99 cycle, but I didn't uplift the fix into 98. So if the shutter is not observable in 99, that's the cause.

2. Bug 1571758 caused another regression (the latter, bug 1758352), it was originally reported with regard to keyboard scrolling bug in theory if the site in question calls scrollBy (or some such) in setTimeout/setInverval (maybe requestIdleCallback?) callbacks it's possible something does wrong there.

3. In the profile in comment 21, I can see the site has at least one scroll event handler, which means we consider the document has scroll-linked effect, and I can see both cases where a nsRefreshDriver::Tick call is processed quite fast (around 4ms) and where the function call takes relatively long (over 10ms), so it's possible we use the same scroll offset on different two frames, that's causing the jitter scroll, see bug 1571758 comment 30 for the detail.

3 is highly suspicious for me. Introducing `force responsive mode ignoring scroll linked effect` would be the only one way I can think of to solve this jitter.

Hmm maybe I am wrong.  It looks like all reporter cases are on Linux? There's something I am not aware of.

There are three possibilities I can think of; the two are bug 1753436 and bug 1758352. 

1. Bug 1571758 caused a performance regression (the former bug, bug 1753436) and the regression was fixed in 99 cycle, but I didn't uplift the fix into 98. So if the shutter is not observable in 99, that's the cause.

2. Bug 1571758 caused another regression (the latter, bug 1758352), it was originally reported with regard to keyboard scrolling but in theory if the site in question calls scrollBy (or some such) in setTimeout/setInverval (maybe requestIdleCallback?) callbacks it's possible something does wrong there.

3. In the profile in comment 21, I can see the site has at least one scroll event handler, which means we consider the document has scroll-linked effect, and I can see both cases where a nsRefreshDriver::Tick call is processed quite fast (around 4ms) and where the function call takes relatively long (over 10ms), so it's possible we use the same scroll offset on different two frames, that's causing the jitter scroll, see bug 1571758 comment 30 for the detail.

3 is highly suspicious for me. Introducing `force responsive mode ignoring scroll linked effect` would be the only one way I can think of to solve this jitter.

Hmm maybe I am wrong.  It looks like all reporter cases are on Linux? There's something I am not aware of.