1376536 - WhatsApp Web unuseable slow for longer conversations due to sync layout flush on input events

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Clemens Eisserer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170626235638

Steps to reproduce:

Use WhatsApp web with Firefox ( https://web.whatsapp.com/ )


Actual results:

For longer conversions Firefox starts to become very sluggish. Not only scrolling through the conversion or selecting text is slow, even typing when writing a new message can slow down to 1 character per second. 

All in all, this makes Firefox almost unuseable with WhatsApp web: https://youtu.be/94yIvWMhtLM


Expected results:

Firefox should perform like Chrome, which has no issues at all with long WhatsApp conversions.

Comment 1

[Clemens Eisserer]

unfortunately the content of the text-box is not clearly visible in the video.
starting at 0:12 I kept the backspace key pressed, and it took ~15s to delete the few characters.

This was on a Core-i5 540M Laptop (2.53ghz base, 3.06 ghz turbo) running Linux.

Comment 2

[Cosmin Muntean [:cmuntean], Ecosystem QA]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Firefox: 56.0a1, Build ID: 20170629030206

I have tested this issue on latest Nightly (56.0a1) build on Ubuntu 14.04 and on Windows 7 x64 and  Mac Os 10.11. I have managed to reproduce it. If you have a large conversation on web whatsapp and start typing fast, Firefox become sluggish and the characters are displayed with a delay. On Windows 7 and Ubuntu 14.04 the CPU usage increase until ~25% (AMD FX - 8320 Eight-Core Processor) and on Mac Os the CPU usage increase until ~85% (a 3.06 GHz Intel Core 2 Duo).

It seems that this behavior is also reproducible on Firefox 53.0, 54.0 and Beta 55. I have tested this in Chrome and the issue is not reproducible. 

I have used the Gecko Profiler add-on to measure the performance. Here are the results:
- Windows: http://bit.ly/2u6z6L1
- Linux: http://bit.ly/2t7ZN25
- Mac Os: http://bit.ly/2twXCIl

Mike, can you please help me out again with the provided profiles?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

I'm seeing synchronous layout flush on input events. I suspect this gets worse proportionally to the size of the conversation.

Hey dholbert, is there anything actionable here?

Comment 4

[Daniel Holbert [:dholbert]]

This seems likely similar to bug 1373023 -- I wonder if this got a little better after we removed some sync reflow flushes over there?

In any case, what remains is likely bug 1377253, i.e. we could stand to cache more data between flex container reflows, to make incremental reflow cheaper.

Comment 5

[Danial Horton]

There is also an unexplained spike in VRAM usage occuring when whatsapp web is first drawn and updated as the user interacts with it.

Comment 6

[TMart]

This not only happens with longer text input, opening images or accessing the paperclip menu can be a crawl too (not always though). If Chrome feels like 60 fps, Firefox feels more like 20 fps with dips to lower numbers on the same hardware. 
Other menus, like the hamburger or right click menu behave much better however. 

This hasn't gotten much better over the recent performance improvements efforts and is a big dent in the awesome experience Nightly has become.

Comment 7

[Clemens Eisserer]

the issue is till present in Nightly 57 with Stylo/Servo enabled

Comment 9

[Clemens Eisserer]

Is this really only P3 "normal"? - in fact one of the most popular web-application is almost unuseable.
Whatsapp-Web not working properly was one of the main reasons for me to switch to Chrome.

Comment 10

[Daniel Holbert [:dholbert]]

Don't read too much into the "3" value of P3 there - right now we just loosely use that field, to distinguish bugs that haven't yet been seen/triaged [the field is unset] vs. bugs that have been seen/triaged [the field is set, usually to P3].

In any case: this bug here is indeed a serious issue, and the fix won't be trivial, but I have a rough plan and it'll likely happen over in bug 1377253 and helper bugs.

Comment 11

[Clemens Eisserer]

for more than 6 months it is now known, that WhatsApp-Web - the web interface for the world'd most popular message service isn't working properly with Firefox.

Comment 12

[TMart]

Also WebRender doesn't seem to improve performance one bit - on the contrary. So there seems to be no improvement in sight. 

According to my experience there are also more problems with performance than what will be handled by bug 1377253.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

(In reply to TMart from comment #12)
> Also WebRender doesn't seem to improve performance one bit - on the
> contrary. So there seems to be no improvement in sight. 
> 

WebRender is not designed to help with layout performance, and we've identified the problem here as a layout issue.(In reply to 

> According to my experience there are also more problems with performance
> than what will be handled by bug 1377253.

I'm curious how you're determining that - have you found performance problems with WhatsApp that are not layout-bound?

Comment 14

[Daniel Holbert [:dholbert]]

I'm actively investigating this now, and I've got a WhatsApp conversation set up that pretty reliably triggers slow (~60ms) reflows on every keypress -- kind of like the ones in comment 2.

For anyone affected by this bug: I have a CSS workaround that seems to "fix" all slowness for me, without affecting the page rendering -- and it'd be really helpful to know if it helps for you as well!

So: anyone interested in testing, I'd much appreciate it if you could do the following and then see if you still hit this bug:
 1) Install the Stylus add-on from https://addons.mozilla.org/firefox/addon/styl-us/
 2) Visit https://web.whatsapp.com/
 3) Click the blue "{S}" icon on your toolbar (for the Stylus addon)
 4) Click "this URL" at the bottom right of the menu (below "Write style for")
 5) Paste the following CSS into the "Code" box:

      .app > ._3q4NP {
          overflow: visible;
      }

 6) Click "save" (near top left)
 7) Play around with WhatsApp, and see if you can reproduce the same slowness that you've reported here.

After you've done that: please let me know whether that style seems to fix things (if so, great!) or doesn't fix some scenario that's specifically only-slow-in-Firefox (if so, good to know -- though please double-check other browsers, too, because I ran across bug 1492605 today which is a case of WhatsApp being janky for every browser :))

Thanks in advance!

Comment 15

[Dennis Jakobsen]

(In reply to Daniel Holbert [:dholbert] from comment #14)
> I'm actively investigating this now, and I've got a WhatsApp conversation
> set up that pretty reliably triggers slow (~60ms) reflows on every keypress
> -- kind of like the ones in comment 2.
> 
> For anyone affected by this bug: I have a CSS workaround that seems to "fix"
> all slowness for me, without affecting the page rendering -- and it'd be
> really helpful to know if it helps for you as well!
> 
> So: anyone interested in testing, I'd much appreciate it if you could do the
> following and then see if you still hit this bug:
>  1) Install the Stylus add-on from
> https://addons.mozilla.org/firefox/addon/styl-us/
>  2) Visit https://web.whatsapp.com/
>  3) Click the blue "{S}" icon on your toolbar (for the Stylus addon)
>  4) Click "this URL" at the bottom right of the menu (below "Write style
> for")
>  5) Paste the following CSS into the "Code" box:
> 
>       .app > ._3q4NP {
>           overflow: visible;
>       }
> 
>  6) Click "save" (near top left)
>  7) Play around with WhatsApp, and see if you can reproduce the same
> slowness that you've reported here.
> 
> After you've done that: please let me know whether that style seems to fix
> things (if so, great!) or doesn't fix some scenario that's specifically
> only-slow-in-Firefox (if so, good to know -- though please double-check
> other browsers, too, because I ran across bug 1492605 today which is a case
> of WhatsApp being janky for every browser :))
> 
> Thanks in advance!

I tested it, it works a bit better, but it's still a bit slow.
364.59 ms	4.88%	364.59 ms	4.88%	185   PressShell::DoReflow   while typing..

I need something similar for Facebook, so Firefox doesn't stall for 5secs. when trying to click a like button :)

Comment 16

[MajestyZ]

(In reply to Daniel Holbert [:dholbert] from comment #14)
> I'm actively investigating this now, and I've got a WhatsApp conversation
> set up that pretty reliably triggers slow (~60ms) reflows on every keypress
> -- kind of like the ones in comment 2.
> 
> For anyone affected by this bug: I have a CSS workaround that seems to "fix"
> all slowness for me, without affecting the page rendering -- and it'd be
> really helpful to know if it helps for you as well!
> 
> So: anyone interested in testing, I'd much appreciate it if you could do the
> following and then see if you still hit this bug:
>  1) Install the Stylus add-on from
> https://addons.mozilla.org/firefox/addon/styl-us/
>  2) Visit https://web.whatsapp.com/
>  3) Click the blue "{S}" icon on your toolbar (for the Stylus addon)
>  4) Click "this URL" at the bottom right of the menu (below "Write style
> for")
>  5) Paste the following CSS into the "Code" box:
> 
>       .app > ._3q4NP {
>           overflow: visible;
>       }
> 
>  6) Click "save" (near top left)
>  7) Play around with WhatsApp, and see if you can reproduce the same
> slowness that you've reported here.
> 
> After you've done that: please let me know whether that style seems to fix
> things (if so, great!) or doesn't fix some scenario that's specifically
> only-slow-in-Firefox (if so, good to know -- though please double-check
> other browsers, too, because I ran across bug 1492605 today which is a case
> of WhatsApp being janky for every browser :))
> 
> Thanks in advance!

It's great news that you're trying to find a solution for this, it's been a real struggle for me to keep using Web Whatsapp in Firefox, the lag can be very frustrating. 
I'm sure it has nothing to do with my laptop specs (i 6700HQ/32GBram/1TBssd). I'm trying your fix as we speak, it works a little better, but it's not perfect yet. If you need any report or proof, please let me know what you need. :)
Again, hope you find a solution!

Comment 17

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (partly reduced, now spun off as bug 1505584)

Comment 18

[Daniel Holbert [:dholbert]]

Here's a profile of me typing "abcdefgh" into the text entry area in testcase 1: http://bit.ly/2zd6jrF
There's a (roughly) 16-36ms reflow associated with each keypress which we'd like to avoid (and which I think are arbitrarily expensive depending on the amount/complexity of the backscroll.

Comment 19

[Daniel Holbert [:dholbert]]

Looking at one of these slow reflows in rr, I've identified the basic issue here: we're retrying the layout with vs. without the vertical scrollbar on the flex container, which means our cached BSize measurement for the expensive-to-reflow first item ends up being always (or frequently) invalid, because it's from our previous attempt which was without a vertical scrollbar, and the current attempt is with a vertical scrollbar, which impacts our mComputedSize and changes the cache key. (correctly, because a difference in width (from reserving/not-reserving space for the vertical scrollbar) absolutely can affect our measured content-height.

I think the solution here is that we need to cache more than one measured BSize for each flex item.  It'd probably be reasonable to limit it to 2 for now, to handle this "toggling a scrollbar on/off" scenario gracefully without going overboard and caching too much.

Comment 20

[Daniel Holbert [:dholbert]]

I've got a few ideas for optimizations that'll help here, which I'll be filing as helper bugs. I think there are several independent things we can do to help:
 A) don't bother toggling scrollbars off for 0-sized scrollable elements (which I've filed as bug 1503660)
 B) when doing flex "measuring" reflows, don't bother reflowing out-of-flow descendants since it obviously doesn't contribute to the size of the thing that we're measuring. (haven't filed a bug for this yet)
 C) As suggested in comment 19, we could cache multiple measurements per flex item (though this is somewhat expensive and might be less necessary if we do (A) and/or (B).)

Comment 21

[Daniel Holbert [:dholbert]]

I filed bug 1503987 for comment 20 suggestion (B), BTW.

Comment 22

[Daniel Holbert [:dholbert]]

Attachment: Bug 1376536: Add MOZ_LOG logging to note when we reflow a flex item extra times. r?emilio

Comment 23

[Daniel Holbert [:dholbert]]

Sorry, the patch in comment 2 was supposed to end up on helper-bug 1504361. (a copypaste error made it end up here by mistake)

Comment 24

[Daniel Holbert [:dholbert]]

I filed bug 1504877 for comment 20 suggestion (C).

Comment 25

[Daniel Holbert [:dholbert]]

Actually, while investigating that bug, I discovered another thing we need to do here & I filed bug 1505254 on it, and it turns out to be sufficient to fix WhatsApp Web, as far as I can tell.

It's not sufficient to fix my attached "reduced testcase", though, because the "height:0" in my attached reduced testcase is getting us *directly* to the slow thing (toggling scrollbars off and on), whereas bug 1505254 makes us avoid the route by which WhatsApp Web ends up arriving at that slow thing.  So, if we end up landing bug 1505254 and closing this bug as fixed-by-it, I'll spin off a followup for the attached testcase.

Anyway -- for the "before"/"after" comparison -- here's a profile of stock mozilla-central (no fix), capturing me typing 3 characters into WhatsApp Web in a conversation with a lot of backscroll:
 https://perfht.ml/2DtLxZe
The 3 blue bars on the bottom there (also visible in the chart at the top) are the long reflows associated with each keypress - they take 74ms, 74ms, and 63ms, as you can see if you hover them.

If I add bug 1505254's fix and perform the same experiment, here's the profile I get instead:
  https://perfht.ml/2Dr5tfx
The 3 blue marks in the marker chart at the bottom show the much-shorter reflow durations for the 3 keypresses -- each one is about 0.5ms

Comment 26

[Daniel Holbert [:dholbert]]

It's looking like the WhatsApp slowness here will be fixed by bug 1505254 (per comment 25), so I've spun off bug 1505584 for the reduced testcase (which is *not* fixed by bug 1505254, because it's been reduced past the point where bug 1505584 helps).   And I'm moving the speculative helper-bugs (parts A/B/C from comment 20) to be blockers of that new bug instead.

Comment 27

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced, closer to actual WhatsApp)

For the record, here's a testcase that's closer to WhatsApp -- its styling iswhat I'm using in the automated testcase in bug 1505254, and (unlike testcase 1 here, but like whatsapp) it does get an improvement from bug 1505254's changes.

Comment 28

[Daniel Holbert [:dholbert]]

I'm going to call this FIXED by bug 1505254, which should be in today's Nightly build.

Comment 29

[Daniel Holbert [:dholbert]]

As verification, I just profiled today's Nightly, with me typing "abcdef" into my lots-of-backscroll heavy WhatsApp conversation (the same one I used in comment 25), and here's the result: https://perfht.ml/2zCuccu

The reflows (shown in the marker chart, directly after each of the 6 black "Input" DOMEvents shown in the timeline up top) are all < 1 ms in duration.

Comment 30

[Chris Vanden Berghe]

Is this fix in the current production version of FF? I'm using 77.0.1 (64-bit) on Kubuntu, and still have similar issues.

Basically, I need to close FF every few days as typing in Whatsapp Web becomes unbearably slow. Potentially just closing the Whatsapp Web tab could work as well, haven't tried.

Comment 31

[Daniel Holbert [:dholbert]]

I'm sorry to hear you're having similar issues.

Yes, the fix for this issue (as-reported) landed 2 years ago, in a supporting bug (as noted in Comment 28), which means Firefox 65 and newer include that fix.

So: whatever you're seeing, it's probably something different (under-the-hood), even though it may have similar symptoms.

Could you please file a new bug, describing your use case & noting specifically which actions are slow (e.g. scrolling, typing) and any other info that seems relevant (e.g. does this only happen in WhatsApp threads with lots of backscroll)?

Also: ideally, it'd be great if you could capture a profile of the slowness, using https://profiler.firefox.com/ -- that site should give you an option to "enable profiler menu button", and then you can use that Firefox toolbar-button to start profiling, and then you can do the stuff that's unbearably slow, and then use the same toolbar-button to capture a profile. Once you're looking at the profile UI, you can use the "share" button at the top-right of the profiler UI to upload and share the profile, and to get a permalink that you can post in the bug that you file.

(Note that the profile may show what other sites you have open in background tabs, so you may want to close background tabs to reduce noise & unrelated potentially-personal information that you might be sharing about what websites you're using.)

Comment 32

[Chris Vanden Berghe]

@daniel I totally missed your response. Will try what you proposed (profiler) and file a new bug. This is still happening under v82.0.2.

Comment 33

[Chris Vanden Berghe]

(Note that the profile may show what other sites you have open in background tabs, so you may want to close
background tabs to reduce noise & unrelated potentially-personal information that you might be sharing about
what websites you're using.)

I have started a second instance without any add-ons etc and have just opened a single tab/window. Will report back in a few days.

Comment 34

[Elizabeth Lewis]

You can use other versions of whatsapp at https://heymods.net/fr/gb-whatsapp store with best quality today.