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

RESOLVED FIXED

Status

()

P3
normal
RESOLVED FIXED
2 years ago
5 months ago

People

(Reporter: linuxhippy, Assigned: dholbert)

Tracking

(Blocks: 1 bug, {perf})

55 Branch
x86_64
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 wontfix)

Details

(Whiteboard: [qf:p3])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

2 years ago
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.
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mconley)
OS: Unspecified → All
Hardware: Unspecified → x86_64
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?
Flags: needinfo?(mconley) → needinfo?(dholbert)
Summary: WhatsApp Web unuseable slow for longer conversations → WhatsApp Web unuseable slow for longer conversations due to sync layout flush on input events
Whiteboard: [qf]
(Assignee)

Comment 4

2 years ago
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.
Depends on: 1377253
Flags: needinfo?(dholbert)
Whiteboard: [qf] → [qf:p3]
Component: Untriaged → Layout
Product: Firefox → Core

Comment 5

2 years ago
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

2 years ago
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.
(Reporter)

Comment 7

2 years ago
the issue is till present in Nightly 57 with Stylo/Servo enabled
See Also: → bug 1395644

Updated

2 years ago
Depends on: 1364813
Duplicate of this bug: 1395644
Priority: -- → P3
(Reporter)

Comment 9

2 years ago
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.
(Assignee)

Comment 10

2 years ago
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.
See Also: → bug 1398697
status-firefox57: --- → wontfix
(Reporter)

Comment 11

a year ago
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

a year ago
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.
(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?
Flags: needinfo?(Tobias.Marty)
(Assignee)

Updated

6 months ago
See Also: → bug 1492605
(Assignee)

Comment 14

6 months ago
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

6 months ago
(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

6 months ago
(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!
(Assignee)

Comment 18

5 months ago
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.
(Assignee)

Comment 19

5 months ago
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.
(Assignee)

Updated

5 months ago
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
(Assignee)

Updated

5 months ago
Depends on: 1503660
(Assignee)

Comment 20

5 months ago
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).)
Flags: needinfo?(Tobias.Marty)
(Assignee)

Updated

5 months ago
Depends on: 1503987
(Assignee)

Comment 21

5 months ago
I filed bug 1503987 for comment 20 suggestion (B), BTW.
(Assignee)

Updated

5 months ago
Depends on: 1504361
(Assignee)

Comment 23

5 months ago
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)
Attachment #9022322 - Attachment is obsolete: true
(Assignee)

Updated

5 months ago
Attachment #9022322 - Attachment is obsolete: true
(Assignee)

Comment 24

5 months ago
I filed bug 1504877 for comment 20 suggestion (C).
Depends on: 1504877
(Assignee)

Comment 25

5 months ago
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
(Assignee)

Updated

5 months ago
Depends on: 1505254
(Assignee)

Updated

5 months ago
Blocks: 1505584
(Assignee)

Updated

5 months ago
No longer depends on: 1364813
(Assignee)

Comment 26

5 months ago
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.
No longer depends on: 1503660, 1503987, 1504877
(Assignee)

Comment 27

5 months ago
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.
(Assignee)

Updated

5 months ago
Attachment #9020942 - Attachment description: testcase 1 (partly reduced) → testcase 1 (partly reduced, now spun off as bug 1505584)
(Assignee)

Comment 28

5 months ago
I'm going to call this FIXED by bug 1505254, which should be in today's Nightly build.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → FIXED
(Assignee)

Comment 29

5 months ago
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.
You need to log in before you can comment on or make changes to this bug.