1514534 - Backspace response slow on reddit

Status: RESOLVED DUPLICATE of bug 613498

(Core :: XPConnect, defect)

Description

[scottbillings]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Went to Reddit using the "new" or redesigned site, opened thread, started typing, tried to use backspace to correct a typo.


Actual results:

Firefox was extremely slow responding to the backspace command. Estimated between a half-second and full second per press of the backspace key.


Expected results:

Backspace should have been instantaneous, and is on all other sites, including creating a new thread on Reddit. Issue seems confined specifically to the text editor for commenting on an existing thread. It also does not affect Chromium browser Vivaldi. Have verified that the issue is present with Firefox 64 and 65b4.

Comment 1

[Kanchan Kumari QA]

I couldn't reproduce this issue on 

User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Backspace command works as expected on https://www.reddit.com/, I didn't observe any slowness.

I would request to test it with Safe Mode(http://support.mozilla.com/en-US/kb/Safe+Mode)and new and empty profile (http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile and http://support.mozilla.org/kb/Managing%20profiles). Please let us know your finding.

Comment 2

[scottbillings]

The issue is specific to replying to existing comments on Reddit, as mentioned in initial report.

1: Go to Reddit
2: Go to any Subreddit, such as https://www.reddit.com/r/ShieldAndroidTV/new/
3: Choose a random comment within chosen subreddit
4: Type something into the comments box
5: Use backspace key
6: Witness slow response

All other text entry boxes on Reddit appear to work correctly, so I am unsure if it is an issue with Reddit's code or Firefox, but issue has been reported to both in hopes of a resolution. Tested with Firefox and Chromium based browser Vivaldi, and only Firefox exhibits the slow response.

Comment 3

[Kanchan Kumari QA]

I still couldn't reproduce this issue on

Version 66.0a1
Build ID 20190111093148
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

However I am placing this under Core: Event Handling, so someone can look into this.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Reporter, any chance you could install https://perf-html.io/ addon (hopefully to Nightly) and try to capture a performance profile when you see the issue?

Comment 5

[scottbillings]

After inspecting the performance profiler info, the issue appears to be with the AdGuard addon. Disabling the extension causes the issue to disappear immediately, and re-enabling it causes the issue to reappear immediately. I will take my issue to the extension developers. Report may be closed unless someone would like the performance profiler data anyway.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Thanks for profiling and analyzing!
I wouldn't mind looking at the profile. The UI should have a "Share" button close to top right and it will generate an URL. Feel free to paste that here.

But for now, closing this bug.

Comment 7

[scottbillings]

https://perfht.ml/2TMoUUg

Thanks for pointing me to the profiler extension. Even if I only have a very basic understanding of the info being presented, it was enough to point me to the problem. I will be sure to run that in the future if I come across a similar issue before opening a bug report.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Thanks.

Parts of this is bug 613498. Reopening and adding dependency.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

And not DOM but more like XPConnect.

Comment 10

[Neha Kochar [:neha]]

Confirmed with Olli that this can be marked as a dup of bug 613498.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Bug 613498 is a tracking bug. Specific manifestations of it may need specific, separate, fixes.

Looking at the profile, a good chunk of the time seems to be spent getting .nodeName over Xrays, right? Bug 1355109 added an IC for that. Why is that not helping in this case?

Comment 12

[Jan de Mooij [:jandem]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #11)

Looking at the profile, a good chunk of the time seems to be spent getting .nodeName over Xrays, right? Bug 1355109 added an IC for that. Why is that not helping in this case?

I installed the AdGuard add-on and followed the steps in comment 2. I do see us attaching a .nodeName Xray getter stub and I don't see any fallback hits for .nodeName in Ion (I do see this in the profile in this bug).

scottbillings, can you still repro this? Does it also happen with Firefox Nightly?

Looking at the profile in comment 7 my guess is that we're attaching too many Xray IC stubs (a lot of different target object shapes/realms for example) and that's why we gave up. That's not what I see locally though.