1567556 - Slack "Add reaction" search popup flashes blue alt text before loading emoji images

Status: NEW

(Core :: DOM: Service Workers, defect, P3)

Description

[Chris Peterson [:cpeterson]]

STR:

1. Log into Slack.
2. Click the "Add reaction" button on some comment.
3. The emoji reaction search popup will open.
4. Start slowing typing an emoji search phrase.

EXPECTED RESULT:
The list of emojis should be filtered by the search phrase.

ACTUAL RESULT:
The list of emojis is filtered, as expected, but I see blue letters (alt text?) while typing a search phrase. After half a second, the blue letters are replaced with the emoji images.

I think this is a regression in 70 Nightly from a day or two ago. I'm using Windows 10.

Comment 1

[Chris Peterson [:cpeterson]]

(In reply to Chris Peterson [:cpeterson] from comment #0)

I think this is a regression in 70 Nightly from a day or two ago. I'm using Windows 10.

I no longer think this is a Firefox regression. I think Slack changed something recently that causes this problem in Firefox. I tried to bisect this bug using mozregression, but I could reproduce the bug at least as far back as 64 Nightly from September 2018. I gave up bisecting then.

The emoji search popup is rendered correctly (without blue text) in Chrome 75 and Edge 18.

Comment 2

[Mike Taylor [:miketaylr]]

Chris, once you've reproduced the issue (for example, slowly type "dog") and delete the filter text, and then slowly re-type it, does it still reproduce for you? It doesn't for me, which makes me wonder if this isn't a perf bug?

Comment 3

[Mike Taylor [:miketaylr]]

Actually, I can reproduce this in Dev Edition, but not Nightly...

Comment 4

[Chris Peterson [:cpeterson]]

(In reply to Mike Taylor [:miketaylr] from comment #2)

Chris, once you've reproduced the issue (for example, slowly type "dog") and delete the filter text, and then slowly re-type it, does it still reproduce for you? It doesn't for me, which makes me wonder if this isn't a perf bug?

I see the same thing as you: the first search is slow (flashes blue alt text) and the second search is fast (no blue alt text). This does sound like a perf bug, though (as noted in comment 1 when I tried to bisect this bug) this is not a recent Firefox regression. So perhaps some new Slack content is triggering an existing slow code path?

I recorded this Gecko profile as I slowly typed "dog" into the Slack emoji UI: https://perfht.ml/2NnXCTX

There looks like a big stampede of network traffic (when the emoji icons are loaded) and increasing memory usage. I'll tentatively move this bug to the Core::Networking component and tag this bug for QF perf triage.

(In reply to Mike Taylor [:miketaylr] from comment #3)

Actually, I can reproduce this in Dev Edition, but not Nightly...

I can still reproduce this in 70 Nightly.

Comment 5

[Honza Bambas (:mayhemer)]

Candidate for backtracking.

Comment 6

[Markus Stange [:mstange]]

I can see two problems in the profile: JS/DOM work, and service workers.

If you look at the network panel of the parent process, you can see that the time from actually starting the network requests to getting the first 8 results is only around 210ms: https://perfht.ml/2TUeNxM

However, it takes 650ms for the network requests to be started in the parent process! The content process knows about those requests a lot earlier, compare the two network tracks: https://perfht.ml/2TUApKo

This phenomenon is usually caused by service workers: The content process main thread wants to start a request, it is handled by a service worker in a DOM worker thread, the service worker says "go ahead to the network", and passes the fetch request back to the main thread to actually start the request. This ping-ponging back to the main thread can reduce arbitrary delays when the main thread is busy, as is the case here.
We really need to give service workers the ability to start network requests without having to go through the main thread.

Comment 7

[Sean Feng [:sefeng]]

Attachment: slack-chrome-profile-screenshot.png

Comment 8

[Sean Feng [:sefeng]]

I took a profile for doing the same action on Chrome, not sure what the best way to share it, so I attached it as screenshot.

I think other than the problem that Markus mentioned, Chrome seems to be able to finish the network request much faster than us. The slowest request only took 284ms, and it was more than 1 second on our side.

Comment 9

[Markus Stange [:mstange]]

No it wasn't more than 1 second on our side. It only looks like that if you look at the network requests in the content process, but the markers in the content process include the delay from the service worker. If you look at the network requests in the parent process, you can see that the first one finishes with 192ms.

Comment 10

[Sean Feng [:sefeng]]

I see, yeah, I think that's what I wanted to say. The overall completion time for the slowest chrome request was 284ms.

Comment 11

[Eden Chuang[:edenchuang]]

We had a discussion on another bug, the details are in https://bugzilla.mozilla.org/show_bug.cgi?id=1613912#c4.

The basic idea is sending fetch requests by new IPC protocol PFetch, and creating a channel in the parent process for fetching resources. Such that we can avoid sending the request through a very busy content process main thread.