1849320 - UI response becomes extremely slow when running certain codepen demo.

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Alice0775 White]

+++ This bug was initially created as a clone of Bug #1849313 +++

STR:

1. Create a fresh Nightly profile (no add-on)
2. Go to https://codepen.io/meodai/pen/WNYxBay
3. Within the demo-pane, click on the settings button. A panel with some settings will open.
4. Drag the "baseHue" slider left and right.
5. Click on Firefox UI item(e.g. App menu button(Hamburger button in Nav bar))

AR: It takes long period to response the UI.
ER: Not so

Profiler log: It takes almost 20 seconds for the menu to appear after clicking the button.
https://share.firefox.dev/3E2BSGu

Comment 1

[Alice0775 White]

Attachment: about:support

Comment 2

[Mayank Bansal]

lots of A11y stuff in the profile. Is it better for you if you force disable a11y from about: config ?
(accessibility.force_disabled = 1)

Comment 3

[Mayank Bansal]

your about:config also says "Accessibility Instantiator: UNKNOWN|" . So looks like something is triggering a11y codepath in Firefox, and Firefox cant determine which program is triggering it.

Comment 4

[Alice0775 White]

Yes,
Setting accessibility.force_disabled = 1 fixes the issue.

FWIW,
ATOK 2021 insight(one of the features of the Japanese IME ATOK 2021) activates the a11y.

Comment 5

[James Teh [:Jamie]]

In this demo, there is a node (.bg__inner) with 1200+ children (.bg__dot). Every time you move that slider, every single (.bg__dot) child gets removed and re-created, but not the (.bg__inner) container. That means a11y has to fire hide and show events for each node that is destroyed and added. If the (.bg__inner) container were re-created, a11y would only have to fire a single hide event and a single show event, but that's not what is being done here.

I'd be interested to know whether Chromium browsers have a similar performance issue. If not, I need to investigate the events they fire.

It might be possible to optimise this in the a11y engine by hiding/showing the whole container if there are too many show/hide events on its children. However, this is a very specific use case and I'm not sure how common this really is in the wild. It wouldn't handle show/hide events on descendants deeper than direct children. Doing that would require ancestor walks for every hide/show event, which would be very expensive and degrade performance across the board.

Comment 6

[James Teh [:Jamie]]

This should be fixed by the patch in bug 1774918.

Comment 7

[Nathan LaPré]

It looks like the fix for Bug 1774918 will also almost entirely ameliorate the issues here. I just tested the codepen demo with the pending patch applied, and I can no longer reproduce the steps as stated. That indicates to me that was is happening here is roughly the same as the issue described in this comment.

To be specific: with that patch applied, I can no longer observe the browser lock-up. There is still a slight lag when using the color slider in the codepen demo, but it's much less lag than before, and the lag ends when you pick up your mouse. It is still not quite as smooth as Chromium. I suspect that we might need to increase the number of events that we send via IPC at once if we want to make that slider smoother.

Comment 8

[Nathan LaPré]

I suspect that we might need to increase the number of events that we send via IPC at once if we want to make that slider smoother.

I ended up adding some more code to the patch for Bug 1774918 that does this. It does make it a bit better still. With that patch merged, we'll have the ability to send essentially uncapped batches of mutation events from the content process to the parent process (the cap as of writing my previous comment was 100). This change makes the frame rate a bit more consistent in my local testing. It appears that the net effect of this is that we will no longer overflow the IPC queue despite a flood of events - the issue that was causing the lockup described in the bug description.