This bug was filed from MDN. Firefox is hanging, and manually crashing using crashfirefox64.exe produces this crash report: https://crash-stats.mozilla.com/report/index/622b6e18-cc02-4686-b722-9d53d1170427 Steps to reproduce 1. Open https://store.docker.com/search?operating_system=windows&q=&source=verified&type=image 2. Click on 'nanoserver' item.

More details: - When hanging, Firefox consumes 100% of CPU core. - The stack-trace of the hanging thread contains 'mozilla::a11y::NotificationController::CoalesceMutationEvents()' function call.

Based on the stack mentioned in comment #1, this looks like an a11y bug to me.

Alex, have you seen this before?

Nope. CoalesceMutationEvents is a known bottle neck though. I'm curious if Firefox 48, which has bug 1261425, is any better. In general I think we should try to go towards to pruning events in subtree (like bug 1301829).

(In reply to alexander :surkov from comment #4) > Nope. CoalesceMutationEvents is a known bottle neck though. I'm curious if > Firefox 48, which has bug 1261425, is any better. > > In general I think we should try to go towards to pruning events in subtree > (like bug 1301829). The crash/hang is from 53.

I attempt finding regression window with Windows10 64bit Nightly 32bit with e10s disabled + a11y activated w/Japanese IME ATOK2016. #1 Regression window(Hang at step 1): https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=850159471c686be76390a2ee8dae12afbac7cc32&tochange=f38aaa49ed11b2e20bced1334e44e203b29e1040 Regressed by: Bug 1296420 #2 Regression window(Hang at Step 2) https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ef23bf8110953349a23ba2e344c20643b392eda0&tochange=387d3acae9e99bdc140a65fd367ecbaa6238f3a3 Regressed (partially progressed?) by: Bug 1270916 @Michael Li and @:tbsaunde, These patches cause the hang. Please look this?

(In reply to :Gijs from comment #5) > (In reply to alexander :surkov from comment #4) > > Nope. CoalesceMutationEvents is a known bottle neck though. I'm curious if > > Firefox 48, which has bug 1261425, is any better. > > > > In general I think we should try to go towards to pruning events in subtree > > (like bug 1301829). > > The crash/hang is from 53. I can reproduce the hang on 52esr w/ e10s disabled + a11y activated. The combination is default for ATOK2016 IME user.

Michael Li was an intern and is currently no longer with us, and Tbsaunde is on PTO. Alex, see comment #6 for the regression windows.

(In reply to Alice0775 White from comment #6) > I attempt finding regression window with Windows10 64bit Nightly 32bit with > e10s disabled + a11y activated w/Japanese IME ATOK2016. > > #1 Regression window(Hang at step 1): > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=850159471c686be76390a2ee8dae12afbac7cc32&tochange=f38a > aa49ed11b2e20bced1334e44e203b29e1040 > > Regressed by: Bug 1296420 this bug is surprising with me, cannot think how it may make the event coalescence worse. > #2 Regression window(Hang at Step 2) > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=ef23bf8110953349a23ba2e344c20643b392eda0&tochange=387d > 3acae9e99bdc140a65fd367ecbaa6238f3a3 > > Regressed (partially progressed?) by: Bug 1270916 ok, that's what I concerned about in 1270916 comment #c73, when switched from EventTree coalescence (introduced in bug 1261425). I'm also curious if single process Firefox is same bad as e10s one.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information