1655777 - Extremely laggy typing on Facebook replies (nsRFPService::ReduceTimePrecisionImpl is slow)

Status: RESOLVED WORKSFORME

(Core :: Security, defect, P2)

Description

[Andrew McCreight [:mccr8]]

In maybe the last few days, I've noticed that typing in Facebook replies has become extremely slow. If I type a bunch of characters, it takes multiple seconds for anything to actually appear. I don't think I've seen this happen on other sites, and it also doesn't happen on Facebook in the "Create Post" dialogue.

I took a profile: https://share.firefox.dev/303YTFI

It looks like most of the time is being spent inside Facebook JS code in an event handler, but I'm not good at reading profiles.

I have Fission enabled, but I can reproduce the same issue in a non-Fission window.

Comment 1

[Andrew McCreight [:mccr8]]

I guess on further inspection, at least half of the time is being spent in Performance.now, and 37% of time inside that in mozilla::nsRFPService::ReduceTimePrecisionImpl.

Comment 2

[Sean Feng [:sefeng]]

Yeah...this is abnormal. The graph is well correlated with the key down event. performance.now took 92% of the keydown event https://share.firefox.dev/3f9nMUI. Firefox didn't look busy at all except this process.

I can't reproduce this on my Linux machine. Could it because the CPU was doing some busy because things like PR_Now and pthread_mutex_trylock also showing in the profile?

Comment 3

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

hmm, I very recently filed https://bugzilla.mozilla.org/show_bug.cgi?id=1655683

Comment 4

[Andrew McCreight [:mccr8]]

I see this on Windows Nightly, also. It doesn't seem to be triggered by hitting a single key, but by mashing a bunch of different keys rapidly, along the lines of "we;rioj ewoeijf oweijf owsd;fjk sdf ij".

I also tried disabling Fission entirely on Windows, and I can still reproduce the problem (as I would have expected, given that FB does not have any cross-origin iframes).

Comment 5

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: this makes making replies on Facebook extremely annoying (hangs of multiple seconds when typing fast). I don't know if it is a regression in Firefox or a change in Facebook itself.

Comment 7

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

needinfo'ing some people who might be familiar with nsRFPService::ReduceTimePrecisionImpl

Comment 8

[Tom Tung [:tt, :ttung]]

I made some changes for ReduceTimePrecisionImpl when it's in the cross-origin-isolated environment (Bug 1586761). I assume Facebook hasn't used COOP and COEP headers yet. So, I guess that it's probably related to that one.

From https://share.firefox.dev/303YTFI,

• PR_Now takes around 1/5 of nsRFPService::ReduceTimePrecisionImpl
• pthread_trylock and pthread_tryunlock also contribute a non small portion of time in nsRFPService::ReduceTimePrecisionImpl. Maybe, it's related to RandomMidpoint which acquires StaticMutexAutoLock?

It looks like if we can improve things inside RandomMidpoint, then, perhaps, we can mitigate this issue. However, I'm not familiar with things inside RandomMidpoint.

Comment 9

[Tom Ritter [:tjr]]

So to narrow down the problem, we should figure out if this reproduces if privacy.resistFingerprinting.reduceTimerPrecision.jitter is disabled but privacy.reduceTimerPrecision is enabled. I suspect that will stop it reproducing, because it's almost certain that this is a problem in the jitter code because that does do some real work.

After that, we can probably narrow this down to a locking issue or just intensive CPU usage by commenting out all usages of the lock in the data structure. This could result in us doing some work (a SHA256 hash) multiple times when we don't need to, but maybe this would be faster than lock contention?

If we want to test if it's the hash itself (either with the locking enabled or disabled) we can replace this code with just a nsAutoCStringN<HASH_DIGEST_SIZE_BYTES> filled with any constant character(s).

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Bug 1586761 landed in Fx77. Does this affect the current releases as well?

Comment 11

[Andrew McCreight [:mccr8]]

I don't know.

For what it is worth, I haven't seen this issue for a day or two. I don't know if we changed something or if Facebook stopped doing whatever measurement was causing issues.

Comment 12

[Kim Moir [:kmoir] ET]

:mccr8 triaging as reo for 79, is this issue still a problem? Does the priority and severity accurately reflect the importance of the issue?

Comment 13

[Andrew McCreight [:mccr8]]

Olli, what do you think we should do with this bug in terms of priority? It isn't affecting me any more on Facebook, but it is possible I was just subjected to an A/B test that changed so it is probably still an issue to some extent.

(I'm not sure what "reo" is.)

Comment 14

[Kim Moir [:kmoir] ET]

Thanks! (REO) is release engineering owner. Someone who triages the bugs associated as tagged as impacting a specific release. Seehttps://wiki.mozilla.org/Platform#Bug_Lists

Comment 15

[Jens Stutte [:jstutte]]

Hi Daniel, should this be re-triaged (lowered severity) ?

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Comment 17

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

I don't know what to do with this, if this doesn't occur anymore, on Facebook at least.
But nsRFPService::ReduceTimePrecisionImpl is very slow.

Comment 18

[Andrew McCreight [:mccr8]]

I'll just set this to WFM, given that the other bug is open now.