1331312 - Poor scrolling performance on att.com and naver.com, due to horizontal scrolling implemented in JS

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[lgbrowser5]

Attachment: record_att.com.mp4

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; CNS_UA; GWX:MANAGED; AD_LOGON=4C47452E4E4554; rv:11.0) like Gecko

Steps to reproduce:

1. Platform Version (M): NOS(7.0)
2. Firefox version (M): Firefox 50.1, Firefox Beta 51.0
3. Reproducible on LG Ref. device (M) : Yes / G5 device
4. Reproduce rate (M) : 100%
5. Issue Reported (M) : NA
6. Issue Description (Wrong behavior) (M) : Scrolling is not smooth
7. Expected behavior (M) : Page scroll smoothly
8. Steps to reproduce (M) : 
1-1. start Firefox
1-2. go to att.com
1-3. scroll up-down 
The top image and whole page is moves sligthtly when scrolling

2-1. start Firefox
2-2. go to naver.com
2-3. scoll left-right and up-down
scroll left-right and up-down is leggy

9. Screen Capture (M) : Yes(attached video)
10. MORE INFORMATION (O):

When it fixed, please share Engineering Report or Release info. for patches. 


Actual results:

1. The top image and whole page is moves sligthtly when scrolling
2. scroll left-right and up-down is leggy


Expected results:

Page scroll smoothly

Comment 1

[lgbrowser5]

Attachment: record_naver.com.mp4

Comment 2

[lgbrowser5]

(In reply to lgbrowser5 from comment #0)
> Created attachment 8827046 [details]
> record_att.com.mp4
> 
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR
> 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0;
> .NET4.0C; .NET4.0E; InfoPath.3; CNS_UA; GWX:MANAGED;
> AD_LOGON=4C47452E4E4554; rv:11.0) like Gecko
> 
> Steps to reproduce:
> 
> 1. Platform Version (M): NOS(7.0)
> 2. Firefox version (M): Firefox 50.1, Firefox Beta 51.0
> 3. Reproducible on LG Ref. device (M) : Yes / G5 device
> 4. Reproduce rate (M) : 100%
> 5. Issue Reported (M) : NA
> 6. Issue Description (Wrong behavior) (M) : Scrolling is not smooth
> 7. Expected behavior (M) : Page scroll smoothly
> 8. Steps to reproduce (M) : 
> 1-1. start Firefox
> 1-2. go to att.com
> 1-3. scroll up-down 
> The top image and whole page is moves sligthtly when scrolling
> 
> 2-1. start Firefox
> 2-2. go to naver.com
> 2-3. scoll left-right and up-down
> scroll left-right and up-down is leggy
> 
> 9. Screen Capture (M) : Yes(attached video)
> 10. MORE INFORMATION (O):
> 
> When it fixed, please share Engineering Report or Release info. for patches. 
> 
> 
> Actual results:
> 
> 1. The top image and whole page is moves sligthtly when scrolling
> 2. scroll left-right and up-down is leggy
> 
> 
> Expected results:
> 
> Page scroll smoothly

The screen gets scuffed when scrolling in att.com page

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

Kats, Randall: regarding the first issue, it looks like that's a horizontally scrollable frame that is also being moved when we're vertically scrolling. I seem to recall we made a conscious decision to allow this, but it does seem weird here.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Both att.com and naver.com scroll fine vertically for me. The horizontal scrolling is driven by the web page using touch events, and is not APZ-controlled. That horizontal scrolling is definitely smoother in Chrome than in Firefox - I didn't check but I presume our "run JS - repaint - composite" cycle is slower than in Chrome, hence the jankiness.

(In reply to lgbrowser5 from comment #0) 
> The top image and whole page is moves sligthtly when scrolling

The top image moving left-right when scrolling up-down happens in Chrome as well, for me. I don't know what you mean by "whole page is moves sligthtly". Do you mean the page is jittering? I don't see anything that looks like that in the video.

> 
> 2-1. start Firefox
> 2-2. go to naver.com
> 2-3. scoll left-right and up-down
> scroll left-right and up-down is leggy

Scrolling left-right is laggy, yes. Up-down seems fine to me. There might be a bit of latency when starting the scroll, again I presume because of the touch event listeners on the webpage.

(In reply to lgbrowser5 from comment #2
> The screen gets scuffed when scrolling in att.com page

I don't know what you mean by "gets scuffed".

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #4)
> 
> Scrolling left-right is laggy, yes. Up-down seems fine to me. There might be
> a bit of latency when starting the scroll, again I presume because of the
> touch event listeners on the webpage.
Would the passive touch event listeners that Chrome recently enabled be relevant here? 
https://developers.google.com/web/updates/2017/01/scrolling-intervention

Comment 6

[Kartikaya Gupta (email:[e-mail])]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> Would the passive touch event listeners that Chrome recently enabled be
> relevant here? 
> https://developers.google.com/web/updates/2017/01/scrolling-intervention

Yes, that might very well make a difference on this site.

Comment 7

[lgbrowser5]

Attachment: record_scroll.7z.001

att.com and sport.naver.com

Comment 8

[lgbrowser5]

Attachment: record_scroll.7z.002

Comment 9

[lgbrowser5]

Yes, att.com scorll is jittering.
"gets scuffed" just means that scoll is not smooth vertically.

I'm sorry a short video. I uploaded a new video(att.com and sport.naver.com)
file name : record_srcoll

Please check it.
Thanks.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

I looked at the video but unfortunately I'm still not able to see much of a difference between Firefox and Chrome in the vertical scrolling here. I stepped through the video one frame at a time, but maybe the video framerate isn't high enough to show the issue. Can you please clarify which of these is the problem you're seeing:

(a) The scroll in Firefox takes longer to start after moving your finger
(b) The scroll in Firefox consistently lags behind your finger
(c) The scroll in Firefox visibly jerks ahead/behind where your finger is
(d) Some combination of the above, or something else

Something else that might help is if you turn on the layers dumping (go to about:config and set layers.dump to true), and then get a logcat of the scrolling in Firefox. To do this:
- Connect the device to a computer and make sure it is accessible via a console using adb
- set layers.dump to true in about:config
- load the page (naver.com, for example)
- Run "adb logcat -c" to clear the log
- Run "adb logcat -v time | tee scroll.log" to record the log to a file "scroll.log"
- Do the vertical pan with your finger
- Hit ctrl-c in your console to stop logging.
- Upload the scroll.log file to this bug.

The layers dump will give us the scroll position per composited frame and hopefully we'll be able to see if there's any unexpected jitter in those values.

Comment 11

[lgbrowser5]

Attachment: logcat.zip

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Hm. Neither of the two logcats in the zip file have any layer dumps. Anyway, I believe there are some reference devices in the Toronto office - Botond, are you able to grab one of those devices (I believe mconnor has them) and see if you can reproduce this?

Comment 13

[Botond Ballo [:botond]]

Attachment: Logcat while scrolling att.com vertically

I borrowed an LG reference device from :mconnor and tested the STR in this bug, but I'm not seeing anything different from what you describe in comment 4.

I did get a logcat (with layer dumps) of vertical scrolling on att.com for completeness.

lgbrowser5, could you answer the question from comment 10, "please clarify which of these is the problem you're seeing"? Thanks!

Comment 14

[Botond Ballo [:botond]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #3)
> Kats, Randall: regarding the first issue, it looks like that's a
> horizontally scrollable frame that is also being moved when we're vertically
> scrolling. I seem to recall we made a conscious decision to allow this, but
> it does seem weird here.

We have an "axis lock" feature which I believe should be kicking in in a situation like this. (Thanks Milan for reminding me of this!)

I think we may have regressed it when we enabled touch-action, because the "consider the entire scroll handoff chain" feature (which is probably needed for this page) that was added in bug 1201101, was only implemented for the non-touchaction codepath.

Comment 15

[lgbrowser5]

Attachment: Chrome vs Firefox (att.com)

Comment 16

[lgbrowser5]

Attachment: Chrome vs Firefox (naver)

Comment 17

[lgbrowser5]

Please check vidoe file.

Comment 18

[Botond Ballo [:botond]]

These videos depict horizontal scrolling. That was already diagnosed by Kats in comment 4 as being unrelated to APZ.

I was under the impression, based on comment 9, that there is a remaining issue with vertical scrolling not being smooth. This is what Kats was asking clarification about in comment 10.

Perhaps we misunderstood and there is no issue with vertical scrolling not being smooth?

Comment 19

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #14)
> (In reply to James Willcox (:snorp) ([e-mail]) from comment #3)
> > Kats, Randall: regarding the first issue, it looks like that's a
> > horizontally scrollable frame that is also being moved when we're vertically
> > scrolling. I seem to recall we made a conscious decision to allow this, but
> > it does seem weird here.
> 
> We have an "axis lock" feature which I believe should be kicking in in a
> situation like this. (Thanks Milan for reminding me of this!)
> 
> I think we may have regressed it when we enabled touch-action, because the
> "consider the entire scroll handoff chain" feature (which is probably needed
> for this page) that was added in bug 1201101, was only implemented for the
> non-touchaction codepath.

Filed bug 1337990 for support cross-apzc axis locking with touch-action enabled.

Comment 20

[lgbrowser5]

Attachment: ATT_vertical.z01

Comment 21

[lgbrowser5]

Attachment: ATT_vertical.z02

Comment 22

[lgbrowser5]

Attachment: ATT_vertical.z03

Comment 23

[lgbrowser5]

Attachment: ATT_vertical.zip

Comment 24

[lgbrowser5]

Attachment: Naver_vertical.z01

Comment 25

[lgbrowser5]

Attachment: Naver_vertical.zip

Comment 26

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #19)
> (In reply to Botond Ballo [:botond] from comment #14)
> > (In reply to James Willcox (:snorp) ([e-mail]) from comment #3)
> > > Kats, Randall: regarding the first issue, it looks like that's a
> > > horizontally scrollable frame that is also being moved when we're vertically
> > > scrolling. I seem to recall we made a conscious decision to allow this, but
> > > it does seem weird here.
> > 
> > We have an "axis lock" feature which I believe should be kicking in in a
> > situation like this. (Thanks Milan for reminding me of this!)
> > 
> > I think we may have regressed it when we enabled touch-action, because the
> > "consider the entire scroll handoff chain" feature (which is probably needed
> > for this page) that was added in bug 1201101, was only implemented for the
> > non-touchaction codepath.
> 
> Filed bug 1337990 for support cross-apzc axis locking with touch-action
> enabled.

Unfortunately bug 1337990 does not help in this case, because the horizontal scrolling is implemented entirely in JS. (It's still useful for other sites, though.)

Comment 27

[Botond Ballo [:botond]]

I've had a look at the videos of vertical scrolling. I do see some slight jank. On att.com it's barely noticeable; on naver.com it's more noticeable, and seems to happen on touch-start. That suggests the likely cause is the touch event listeners registered for implementing the horizontal scrolling, which APZ needs to block on (to make sure they don't preventDefault() the touch-start event).

Comment 28

[Botond Ballo [:botond]]

Given that the poor performance of horizontal scrolling, the horizontal jitter of the page during vertical scrolling (due to lack of axis lock), and the jank after touch-start during vertical scrolling, are all caused by the page implementing horizontal scrolling itself using JS, I think the appropriate course of action here is to treat this as an evangelism issue. If the websites made the page be actually horizontally scrollable (by the platform, not by JS), and used CSS scroll snapping [1], they could achieve the same effect with much better performance.

lgbrowser5, do you have contacts with AT&T and Naver that you could reach out to about this issue? If not, we have an evangelism team who could do so.

[1] https://www.w3.org/TR/css-scroll-snap-1/

Comment 29

[lgbrowser5]

I don't have contact with AT&T and Naver.
For technical assistance, contact Customer Support.
https://help.naver.com/support/home.nhn
https://help.naver.com/support/contents/contents.nhn?serviceNo=1074&categoryNo=8298#
https://www.att.com/contactus/index/wireless.html?tab=1

Comment 30

[Botond Ballo [:botond]]

Moving to Tech Evangelism.

Comment 31

[Mike Kaply [:mkaply]]

> Given that the poor performance of horizontal scrolling, the horizontal jitter of the page during vertical scrolling (due to lack of axis lock), and the jank after touch-start during vertical scrolling, are all caused by the page implementing horizontal scrolling itself using JS, I think the appropriate course of action here is to treat this as an evangelism issue. If the websites made the page be actually horizontally scrollable (by the platform, not by JS), and used CSS scroll snapping [1], they could achieve the same effect with much better performance.

I don't understand this statement. We're basically saying "You're doing it wrong" when clearly chrome performs better than us in this exact same scenario.

Do we know exactly what the technical difference is between Chrome and Firefox as to why they can do fine in this scenario and we can't?

I'm fine with telling folks to fix things when it is standards related, but this seems like "We don't do that well, so you should do it differently"

Comment 32

[Milan Sreckovic [:milan] (needinfo for best results)]

Right - evangelism because it's better to use CSS scroll snapping instead of JS, if you can swing it.  The "make JS scrolling go faster" isn't going to happen any time soon, but even once it does, the CSS approach would be better.

Comment 33

[Karl Dubost💡 :karlcow]

Indeed CSS scroll snapping would be better than JS. At the same we can balance the

> The "make JS scrolling go faster" isn't going to happen any time soon

with another truth

> deployed JS libraries on multiple sites across the world will not happen any time soon to never

Right now, a lot of developers are using this JS technique. It's very good we send a message in the console of devtools about it and that we try to convince people about it. But contacting is no guarantee that it will work, and has also its intrinsic cost in terms of time dedicated to it. 

Question:
miketaylr?
Do we have telemetry (is it possible) to detect how many pages have JS scroll effects (as we send the message in the devtools console, I guess we can measure that at least).

Comment 34

[Botond Ballo [:botond]]

(In reply to Karl Dubost :karlcow from comment #33)
> Do we have telemetry (is it possible) to detect how many pages have JS
> scroll effects (as we send the message in the devtools console, I guess we
> can measure that at least).

We had such telemetry, added in bug 1229052, and then subsequently removed in bug 1282587 because the number it had been reporting was pretty stable.

Comment 35

[Mike Taylor [:miketaylr]]

(Looks like Botond answered the question here.)

Comment 36

[Mike Kaply [:mkaply]]

I still didn't see an answer to this question:

> Do we know exactly what the technical difference is between Chrome and Firefox as to why they can do fine in this scenario and we can't?

Do we know why we perform so bad in this scenario? Is there really nothing we can do to make things faster?

Comment 37

[Kartikaya Gupta (email:[e-mail])]

(In reply to Mike Kaply [:mkaply] from comment #36)
> Do we know why we perform so bad in this scenario? Is there really nothing
> we can do to make things faster?

Most of the time we investigate problems like these it boils down to "painting is too slow in Firefox". There's not much we can do to make it faster, and we're already working on doing the things we can do - but they take time.

Comment 38

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #28)
> If the websites made the page be actually horizontally scrollable (by the
> platform, not by JS), and used CSS scroll snapping [1], they could achieve
> the same effect with much better performance.
> 
> [1] https://www.w3.org/TR/css-scroll-snap-1/

For full disclosure: Firefox currently implements an older version of the scroll snapping spec [1] that has since been superseded by a newer version [2].

If writing new code, it's probably better to use the newer version of the spec (though with the understanding that the improved performance in Firefox will be realized once Firefox implements that version).

[1] https://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
[2] https://www.w3.org/TR/css-scroll-snap-1/

Comment 39

[Mike Taylor [:miketaylr]]

vertical scrolling seems pretty good these days, but the side-swiping between content sections is still pretty janky compared to chrome.

Comment 40

[Oana Arbuzov [:oanaarbuzov]]

I currently don't see any difference between Firefox and Chrome, when scrolling horizontally or up/down on att.com or naver.com.

Tested with:
Browser / Version: Firefox Nightly 201116 (🦎 84.0a1-20201114094625)
Operating System: Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density), Huawei P20 Lite (Android 8.0.0) - 1080 x 2280 pixels, 19:9 ratio (~432 ppi density)

lgbrowser5 can you still reproduce it?

Comment 41

[Karl Dubost💡 :karlcow]

Needs Triage.

Comment 42

[Raul Bucata]

I was not able to reproduce the issue. For me, there isn't any difference between the two browsers when performing horizontal scrolling or up/down scrolling on either att.com or naver.com

Tested with:
Browser / Version: Firefox Nightly 92.0a1 (2015822091 -🦎92.0a1-20210714093409🦎)
Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)

Suggestion: Try clearing cache/data/cookies, disable Ad-blocker (if available), or use a clean profile, and check again? If there are any changes made to the default settings of the browser (e.g. in about: config) please revert to the default settings and try again. Also, have the required cookies been accepted for this page?