Closed Bug 1673192 Opened 5 years ago Closed 5 years ago

Nightly UI unresponsive when open https://twitter.com/FirefoxNightly and support.mozilla.org

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
Firefox 84
Platform:
x86_64
Windows 10
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
84 Branch
Project Flags:
Fission Milestone M6c
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- unaffected
firefox82 --- unaffected
firefox83 --- unaffected
firefox84 + verified

People

(Reporter: alice0775, Assigned: jya)

References

(Regression)

Details

(Keywords: hang, regression)

Attachments

(3 files, 1 obsolete file)

image.png
241.27 KB, image/png
Details
about:support
29.16 KB, text/plain
Details
Bug 1673192 - Don't attempt to launch the RDD process when it's not needed. r?mattwoodrow
47 bytes, text/x-phabricator-request
Details | Review

Reproducible: not always

Steps to reproduce:
0. Start Nightly with new profile

  1. Open https://twitter.com/FirefoxNightly in new tab
  2. Close the tab
  3. Open https://twitter.com/FirefoxNightly in new tab
  4. try interact with Nightly

Actual results:
Status label indicates "Transferring data from abs.twimg.com..."
UI freezes, and not respond. I must kill firefox.exe.
So, I could not get log of gecko profiler...

Attached image image.png —
Attached file about:support —

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3

(Due to intermittent failures, I am not 100% sure of the above regression range)

Keywords: regression
Regressed by: 1595994
Has Regression Range: --- → yes

If you open about:processes, there will be an entry showing the RDD process (data decoder), when you attempt to reproduce those steps, when you refelresh the page in about:processes does the pid changes regularly?

If so it could indicate the RDD process is crashing and it's attempting to recreate it all the time, which could block the UI for up to 5s.

(In reply to Jean-Yves Avenard [:jya] from comment #4)

If you open about:processes, there will be an entry showing the RDD process (data decoder), when you attempt to reproduce those steps, when you refelresh the page in about:processes does the pid changes regularly?

pid of Data Decoder remains the same.

FWIW, When the problem occurs, I can resume the UI's response and page loading by performing the following steps without killing the process.(if multiple tabs are open)

  1. Right click on Nighty taskbar button in Windows taskbar and choose "Close window" so that "Exit and close tabs" warning dialog will pop up.
    --- The page will resume loading.
  2. Click [Cancel] button
    --- Nightly starts working properly.

(In reply to Alice0775 White from comment #6)

FWIW, When the problem occurs, I can resume the UI's response and page loading by performing the following steps without killing the process.(if multiple tabs are open)

  1. Right click on Nighty taskbar button in Windows taskbar and choose "Close window" so that "Exit and close tabs" warning dialog will pop up.
    --- The page will resume loading.
  2. Click [Cancel] button
    --- Nightly starts working properly.

In this case, the pid of the Data Fecoder does not change.

successfully got a profiler log: https://share.firefox.dev/35ACpxC

0s-6s: Start loading the web page
6s-33s: Website and UI becomes hang up
33s～: I did steps of comment#6

Component: Untriaged → Audio/Video
Product: Firefox → Core

It seems that a11y + RDD process causes this problem.

I can reproduce
A. Nightly84.0a1 + ATOK2016 Insite.
B. Nightly84.0a1 + Windows Narrator.
In both cases, I got the same regression window as comment #3.

And I confirmed that setting accessibility.force_disabled to 1 mitigates this issue.

Component: Audio/Video → Disability Access APIs

Is there any specific a11y call that stands out in those profiles? Reading those is difficult for Jamie and myself, so if a sighted person could give some pointers, it would be helpful. Since I cannot reproduce this with NVDA, I assume it is something related to UI Automation, which both NVDA and JAWS don't use for Firefox, but Narrator does, through the UIAtoIA2 bridge.

Flags: needinfo?(jteh)

If you set the environment variable: MOZ_DISABLE_RDD_SANDBOX=1 as described here https://wiki.mozilla.org/Security/Sandbox#Setting_a_custom_environment_in_Windows

Do you experience this issue?

The hang is almost definitely related to the startup of the RDD process.

We are stuck on mozilla::RemoteDecoderManagerChild::Supports waiting for the RDD parent to respond.

It could be related to some particular code injection the accessibility tool is doing that would be blocked by the RDD sandbox

Component: Disability Access APIs → Audio/Video: Playback
Flags: needinfo?(alice0775)

Ok, it is mostly an accessibility issue.

We are waiting for the parent process to handle the message to start the RDD process.

But the parent process is currently blocked by accessibility code that itself is blocked on the content process main thread (currently waiting on a JS MSE.isTypeSupported())

We have a sync call from the parent process to the content process that we definitely do not want.
Only sync calls from content to parent are allowed.

The hang reported here can already happen today ; the change in the media code just made it more likely.

The method blocking the parent process is mozilla::a11y::AccessibleWrap::GetRemoteIAccessibleFor

Component: Audio/Video: Playback → Disability Access APIs

(In reply to Jean-Yves Avenard [:jya] from comment #12)

We have a sync call from the parent process to the content process that we definitely do not want.

The problem is that a11y has always been an exception to the "don't make sync calls from parent to content" rule. This isn't our choice: all current a11y APIs are synchronous at the OS level. A11y clients make sync calls and we can't respond asynchronously to a synchronous call. Because of sandboxing, a11y clients can't talk to content, so we have no choice but to do sync IPC.

Only sync calls from content to parent are allowed.

I'm not at all trying to play the "whose fault is it" game here - I agree it sucks that a11y is sync - but my understanding is that sync messages period, regardless of direction, are considered undesirable. Even content -> parent sync messages have to be explicitly allow-listed for this reason, and we have bug 1518344 to investigate making that async. We have some control over things like this, but we have no control over OS a11y APIs being synchronous.

The hang reported here can already happen today

Do you mean related to the RDD process specifically? We've had problems with other sync calls in the past (e.g. LSNG, bug 1535221), but we've found ways to work around those.

Flags: needinfo?(jteh) → needinfo?(jyavenard)

(In reply to James Teh [:Jamie] from comment #13)

Do you mean related to the RDD process specifically? We've had problems with other sync calls in the past (e.g. LSNG, bug 1535221), but we've found ways to work around those.

Yes, I was referring to how the RDD is launched.

In current release, anything attempting to play AV1 or some audio codec would deadlock in the same fashion should we need to launch the RDD process.

It's much more rare than how it now works in Nightly. But it can happen.

I'm thinking for a workaround we could maybe move the launch of a new process to a different thread than the main thread.

There are dependencies required to achieve that task, like the ability to read the prefs off the main thread, there are likely others.

Flags: needinfo?(jyavenard)

(In reply to Jean-Yves Avenard [:jya] from comment #11)

If you set the environment variable: MOZ_DISABLE_RDD_SANDBOX=1 as described here https://wiki.mozilla.org/Security/Sandbox#Setting_a_custom_environment_in_Windows

Do you experience this issue?

I can still reproduce this with shell env set MOZ_DISABLE_RDD_SANDBOX=1

Flags: needinfo?(alice0775)
Severity: -- → S2
Depends on: 1674043

Set release status flags based on info from the regressing bug 1595994

status-firefox82: --- → unaffected
status-firefox83: --- → unaffected
status-firefox-esr78: --- → unaffected

I'm reproducing this on Linux x86_64 with fission enabled when I load a page with an OOP youtube iframe: https://paul.bone.id.au/pub/pbone-2016-plasma It's almost perfectly reproducable, mozregression lead me to these changes (but also lead me to other changesets too due to the not-perfect reproducibility. But since accessibility.force_disabled=1 fixes it, and it involves playing a video, this seems the most likely.

If I set accessibility.force_disabled=1 or disable fission then the problem goes away.

Setting MOZ_DISABLE_NPAPI_SANDBOX=1 made no difference.

NI'ing Jamie as comment 17 indicates it's a problem when enabling Fission with a11y.

Fission Milestone: --- → M6c
Flags: needinfo?(jteh)

Ah sorry, missed that it's from jya's patch.

Flags: needinfo?(jteh)
Attached file Main process stack (obsolete) —
I get this in Mac Nightly wich VoiceOver when loading gmail. Here is the stack from the main process: ``` * thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007fff6cbb0882 libsystem_kernel.dylib`__psynch_cvwait + 10 libsystem_kernel.dylib`__psynch_cvwait: -> 0x7fff6cbb0882 <+10>: jae 0x7fff6cbb088c ; <+20> 0x7fff6cbb0884 <+12>: movq %rax, %rdi 0x7fff6cbb0887 <+15>: jmp 0x7fff6cbae629 ; cerror_nocancel 0x7fff6cbb088c <+20>: retq Target 0: (firefox) stopped. (lldb) bt * thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fff6cbb0882 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x00007fff6cc71457 libsystem_pthread.dylib`_pthread_cond_wait + 748 frame #2: 0x0000000100166a58 libmozglue.dylib`mozilla::detail::ConditionVariableImpl::wait_for(this=0x000000012315bab0, lock=<unavailable>, a_rel_time=0x00007ffeefbfaf30) at ConditionVariable_posix.cpp:146:7 [opt] frame #3: 0x000000010221c24c XUL`mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >, IPC::Message*) [inlined] mozilla::OffTheBooksCondVar::Wait(this=<unavailable>, aDuration=(mValue = 250000000)) at CondVar.h:64:18 [opt] frame #4: 0x000000010221c234 XUL`mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >, IPC::Message*) [inlined] mozilla::Monitor::Wait(this=<unavailable>, aDuration=<unavailable>) at Monitor.h:36 [opt] frame #5: 0x000000010221c234 XUL`mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >, IPC::Message*) [inlined] mozilla::ipc::MessageChannel::WaitForSyncNotify(this=0x000000013100f8e0, (null)=<unavailable>) at MessageChannel.cpp:2339 [opt] frame #6: 0x000000010221c1f9 XUL`mozilla::ipc::MessageChannel::Send(this=0x000000013100f8e0, aMsg=<unavailable>, aReply=0x00007ffeefbfb020) at MessageChannel.cpp:1514 [opt] frame #7: 0x0000000102223e06 XUL`mozilla::ipc::IProtocol::ChannelSend(this=<unavailable>, aMsg=<unavailable>, aReply=<unavailable>) at ProtocolUtils.cpp:518:29 [opt] frame #8: 0x00000001023518db XUL`mozilla::a11y::PDocAccessibleParent::SendFocusedChild(this=0x0000000134bb8d50, aID=<unavailable>, aChild=0x00007ffeefbfb0d8, aOk=0x00007ffeefbfb0d7) at PDocAccessibleParent.cpp:7329:20 [opt] frame #9: 0x00000001057d788b XUL`mozilla::a11y::ProxyAccessible::FocusedChild(this=0x0000000134bb8da0) at ProxyAccessible.cpp:767:19 [opt] frame #10: 0x000000010576a047 XUL`-[mozAccessible moxFocusedUIElement](self=0x000000012471fd80, _cmd=<unavailable>) at mozAccessible.mm:237:49 [opt] frame #11: 0x0000000105763936 XUL`-[MOXAccessibleBase accessibilityFocusedUIElement](self=<unavailable>, _cmd=<unavailable>) at MOXAccessibleBase.mm:382:10 [opt] frame #12: 0x0000000105763936 XUL`-[MOXAccessibleBase accessibilityFocusedUIElement](self=<unavailable>, _cmd=<unavailable>) at MOXAccessibleBase.mm:382:10 [opt] frame #13: 0x00007fff30517631 AppKit`-[NSWindow(NSWindowAccessibility) accessibilityFocusedUIElement] + 121 frame #14: 0x00007fff2fd1c77a AppKit`NSAccessibilityGetObjectForAttributeUsingLegacyAPI + 371 frame #15: 0x00007fff2fd1bd01 AppKit`NSAccessibilityGetObjectValueForAttribute + 1565 frame #16: 0x00007fff2fd1b25a AppKit`-[NSAccessibilityAttributeAccessorInfo getAttributeValue:forObject:] + 58 frame #17: 0x00007fff302d8c29 AppKit`___NSAccessibilityEntryPointValueForAttribute_block_invoke.805 + 1674 frame #18: 0x00007fff302d4a74 AppKit`NSAccessibilityPerformEntryPointObject + 16 frame #19: 0x00007fff2ff98c01 AppKit`_NSAccessibilityEntryPointValueForAttribute + 168 frame #20: 0x00007fff300da0b3 AppKit`-[NSObject(NSAccessibilityInternal) _accessibilityValueForAttribute:clientError:] + 351 frame #21: 0x00007fff30104d0c AppKit`-[NSApplication(NSApplicationAccessibility) _accessibilityValueForAttribute:clientError:] + 49 frame #22: 0x00007fff300df1ce AppKit`CopyAppKitUIElementAttributeValueNoCatch + 98 frame #23: 0x00007fff300dc0b2 AppKit`CopyAttributeValue + 142 frame #24: 0x00007fff30ccf3f6 HIServices`_AXXMIGCopyAttributeValue + 389 frame #25: 0x00007fff30cf04cb HIServices`_XCopyAttributeValue + 443 frame #26: 0x00007fff30caff64 HIServices`mshMIGPerform + 174 frame #27: 0x00007fff329fd304 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41 frame #28: 0x00007fff329fd250 CoreFoundation`__CFRunLoopDoSource1 + 541 frame #29: 0x00007fff329fbd79 CoreFoundation`__CFRunLoopRun + 2270 frame #30: 0x00007fff329fae3e CoreFoundation`CFRunLoopRunSpecific + 462 frame #31: 0x00007fff31627abd HIToolbox`RunCurrentEventLoopInMode + 292 frame #32: 0x00007fff316277d5 HIToolbox`ReceiveNextEventCommon + 584 frame #33: 0x00007fff31627579 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64 frame #34: 0x00007fff2fc6d039 AppKit`_DPSNextEvent + 883 frame #35: 0x00007fff2fc6b880 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352 frame #36: 0x00000001046ca48e XUL`-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:](self=0x00000001006505b0, _cmd=<unavailable>, mask=18446744073709551615, expiration=0x00007fff8a2aa618, mode="kCFRunLoopDefaultMode", flag=YES) at nsAppShell.mm:171:24 [opt] frame #37: 0x00007fff2fc5d58e AppKit`-[NSApplication run] + 658 frame #38: 0x00000001046cb2ad XUL`nsAppShell::Run(this=0x000000011b9d3f70) at nsAppShell.mm:692:5 [opt] frame #39: 0x00000001059e3027 XUL`nsAppStartup::Run(this=0x000000011b79c330) at nsAppStartup.cpp:270:30 [opt] frame #40: 0x0000000105ab4dd8 XUL`XREMain::XRE_mainRun(this=0x00007ffeefbff340) at nsAppRunner.cpp:5091:22 [opt] frame #41: 0x0000000105ab556d XUL`XREMain::XRE_main(this=0x00007ffeefbff340, argc=5, argv=0x00007ffeefbff918, aConfig=<unavailable>) at nsAppRunner.cpp:5283:8 [opt] frame #42: 0x0000000105ab58b8 XUL`XRE_main(argc=<unavailable>, argv=<unavailable>, aConfig=<unavailable>) at nsAppRunner.cpp:5339:21 [opt] frame #43: 0x000000010000313c firefox`main [inlined] do_main(argc=<unavailable>, argv=0x00007ffeefbff918, envp=0x00007ffeefbff948) at nsBrowserApp.cpp:218:22 [opt] frame #44: 0x0000000100002eaa firefox`main(argc=<unavailable>, argv=<unavailable>, envp=0x00007ffeefbff948) at nsBrowserApp.cpp:336 [opt] frame #45: 0x00007fff6ca6ccc9 libdyld.dylib`start + 1 frame #46: 0x00007fff6ca6ccc9 libdyld.dylib`start + 1 ``` Here is the content process stack: ``` * thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fff6cbb0882 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x00007fff6cc71425 libsystem_pthread.dylib`_pthread_cond_wait + 698 frame #2: 0x0000000115a028ec libmozglue.dylib`mozilla::detail::ConditionVariableImpl::wait(this=<unavailable>, lock=<unavailable>) at ConditionVariable_posix.cpp:108:11 [opt] frame #3: 0x00000001005ac991 XUL`mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) [inlined] mozilla::OffTheBooksCondVar::Wait(this=0x0000000134dfe620) at CondVar.h:57:11 [opt] frame #4: 0x00000001005ac975 XUL`mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) [inlined] mozilla::Monitor::Wait(this=0x0000000134dfe5d8) at Monitor.h:35 [opt] frame #5: 0x00000001005ac975 XUL`mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) [inlined] mozilla::MonitorAutoLock::Wait(this=<unavailable>) at Monitor.h:71 [opt] frame #6: 0x00000001005ac975 XUL`mozilla::SyncRunnable::DispatchToThread(this=0x0000000134dfe5b0, aThread=<unavailable>, aForceDispatch=<unavailable>) at SyncRunnable.h:71 [opt] frame #7: 0x0000000102749bb2 XUL`mozilla::RemoteDecoderManagerChild::Supports(mozilla::RemoteDecodeIn, mozilla::SupportDecoderParams const&, mozilla::DecoderDoctorDiagnostics*) [inlined] mozilla::SyncRunnable::DispatchToThread(aThread=0x0000000118291eb0, aRunnable=0x000000013332e440, aForceDispatch=false) at SyncRunnable.h:102:15 [opt] frame #8: 0x0000000102749b39 XUL`mozilla::RemoteDecoderManagerChild::Supports(aLocation=<unavailable>, aParams=<unavailable>, aDiagnostics=0x0000000000000000) at RemoteDecoderManagerChild.cpp:216 [opt] frame #9: 0x000000010274e60a XUL`mozilla::RemoteDecoderModule::Supports(this=0x0000000137d2a780, aParams=<unavailable>, aDiagnostics=<unavailable>) const at RemoteDecoderModule.cpp:58:7 [opt] frame #10: 0x00000001027e45c2 XUL`mozilla::PDMFactory::Supports(mozilla::SupportDecoderParams const&, mozilla::DecoderDoctorDiagnostics*) const at PDMFactory.cpp:517:18 [opt] frame #11: 0x00000001027e458a XUL`mozilla::PDMFactory::Supports(this=0x0000000137d66970, aParams=<unavailable>, aDiagnostics=0x0000000000000000) const at PDMFactory.cpp:369 [opt] frame #12: 0x00000001027e44aa XUL`mozilla::PDMFactory::SupportsMimeType(this=0x0000000137d66970, aMimeType=<unavailable>, aDiagnostics=0x0000000000000000) const at PDMFactory.cpp:350:10 [opt] frame #13: 0x00000001027c83c7 XUL`mozilla::MP3Decoder::IsSupportedType(mozilla::MediaContainerType const&) [inlined] mozilla::MP3Decoder::IsEnabled() at MP3Decoder.cpp:16:20 [opt] frame #14: 0x00000001027c8386 XUL`mozilla::MP3Decoder::IsSupportedType(aContainerType=0x00007ffeefbfc348) at MP3Decoder.cpp:24 [opt] frame #15: 0x0000000102580c8a XUL`mozilla::CanHandleMediaType(aType=0x00007ffeefbfc3e0, aDiagnostics=0x00007ffeefbfc460) at DecoderTraits.cpp:184:7 [opt] frame #16: 0x0000000102503378 XUL`mozilla::dom::HTMLMediaElement::GetCanPlay(aType=<unavailable>, aDiagnostics=0x00007ffeefbfc460) at HTMLMediaElement.cpp:4940:7 [opt] frame #17: 0x000000010250cbbb XUL`mozilla::dom::HTMLMediaElement::CanPlayType(this=0x000000011d1cf000, aType=0x00007ffeefbfc688, aResult=0x00007ffeefbfc5d8) at HTMLMediaElement.cpp:4957:27 [opt] frame #18: 0x00000001020d48fa XUL`mozilla::dom::HTMLMediaElement_Binding::canPlayType(cx=0x000000011832f000, obj=<unavailable>, void_self=0x000000011d1cf000, args=0x00007ffeefbfc7b0) at HTMLMediaElementBinding.cpp:519:24 [opt] frame #19: 0x0000000102155a15 XUL`bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(cx=0x000000011832f000, argc=1, vp=<unavailable>) at BindingUtils.cpp:3229:13 [opt] frame #20: 0x00000001044accce XUL`js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [inlined] CallJSNative(cx=0x000000011832f000, native=(XUL`bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) at BindingUtils.cpp:3203), reason=<unavailable>, args=0x00007ffeefbfc978)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) at Interpreter.cpp:506:13 [opt] frame #21: 0x00000001044acc81 XUL`js::InternalCallOrConstruct(cx=0x000000011832f000, args=0x00007ffeefbfc978, construct=<unavailable>, reason=<unavailable>) at Interpreter.cpp:598 [opt] frame #22: 0x00000001044ad62f XUL`InternalCall(cx=<unavailable>, args=<unavailable>, reason=<unavailable>) at Interpreter.cpp:663:10 [opt] [artificial] frame #23: 0x00000001044a63b9 XUL`Interpret(JSContext*, js::RunState&) [inlined] js::CallFromStack(cx=0x000000011832f000, args=0x00007ffeefbfc978) at Interpreter.cpp:667:10 [opt] frame #24: 0x00000001044a63af XUL`Interpret(cx=0x000000011832f000, state=<unavailable>) at Interpreter.cpp:3336 [opt] frame #25: 0x000000010449daa3 XUL`js::RunScript(cx=0x000000011832f000, state=0x00007ffeefbfcdb0) at Interpreter.cpp:476:13 [opt] frame #26: 0x00000001044ad101 XUL`js::InternalCallOrConstruct(cx=0x000000011832f000, args=0x00007ffeefbfced8, construct=NO_CONSTRUCT, reason=<unavailable>) at Interpreter.cpp:635:13 [opt] frame #27: 0x00000001044ad62f XUL`InternalCall(cx=<unavailable>, args=<unavailable>, reason=<unavailable>) at Interpreter.cpp:663:10 [opt] [artificial] frame #28: 0x00000001044ad68c XUL`js::Call(cx=0x000000011832f000, fval=JS::HandleValue @ scalar, thisv=JS::HandleValue @ scalar, args=0x00007ffeefbfced8, rval=JS::MutableHandleValue @ r14, reason=<unavailable>) at Interpreter.cpp:680:8 [opt] frame #29: 0x0000000104a85afc XUL`js::jit::InvokeFunction(cx=0x000000011832f000, obj=<unavailable>, constructing=<unavailable>, ignoresReturnValue=false, argc=1, argv=0x00007ffeefbfd040, rval=JS::MutableHandleValue @ 0x00007ffeefbfcfa0) at VMFunctions.cpp:753:10 [opt] frame #30: 0x0000000104a85e30 XUL`js::jit::InvokeFromInterpreterStub(cx=<unavailable>, frame=<unavailable>) at VMFunctions.cpp:773:8 [opt] frame #31: 0x00000e010f88ffa4 ```
Attachment #9185200 - Attachment is obsolete: true

https://support.mozilla.org/en-US/products/firefox?as=u&utm_source=inproduct also trigger the UI hang.

Profiler: https://share.firefox.dev/2TRAkYU

Summary: Nightly UI unresponsive when open https://twitter.com/FirefoxNightly → Nightly UI unresponsive when open https://twitter.com/FirefoxNightly and support.mozilla.org

Fixed with bug 1674043

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

I am still seeing an a11y/media lockup in Mac. on a local build with the patchset from bug 1674043 in central.
Don't know if this is a separate issue, or the same.
STR:

  1. Start VoiceOver
  2. Load gmail.com

Here is the main stack:

* thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff6cbb0882 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff6cc71457 libsystem_pthread.dylib`_pthread_cond_wait + 748
    frame #2: 0x00000001001662e8 libmozglue.dylib`mozilla::detail::ConditionVariableImpl::wait_for(this=0x0000000124ceb0c8, lock=<unavailable>, a_rel_time=0x00007ffeefbfb080) at ConditionVariable_posix.cpp:146:7 [opt]
    frame #3: 0x0000000102b2e29c XUL`mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >, IPC::Message*) [inlined] mozilla::OffTheBooksCondVar::Wait(this=<unavailable>, aDuration=(mValue = 250000000)) at CondVar.h:64:18 [opt]
    frame #4: 0x0000000102b2e284 XUL`mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >, IPC::Message*) [inlined] mozilla::Monitor::Wait(this=<unavailable>, aDuration=<unavailable>) at Monitor.h:36 [opt]
    frame #5: 0x0000000102b2e284 XUL`mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >, IPC::Message*) [inlined] mozilla::ipc::MessageChannel::WaitForSyncNotify(this=0x000000012e07b0d8, (null)=<unavailable>) at MessageChannel.cpp:2339 [opt]
    frame #6: 0x0000000102b2e249 XUL`mozilla::ipc::MessageChannel::Send(this=0x000000012e07b0d8, aMsg=<unavailable>, aReply=0x00007ffeefbfb170) at MessageChannel.cpp:1514 [opt]
    frame #7: 0x0000000102b35e46 XUL`mozilla::ipc::IProtocol::ChannelSend(this=<unavailable>, aMsg=<unavailable>, aReply=<unavailable>) at ProtocolUtils.cpp:518:29 [opt]
    frame #8: 0x0000000102c5aaab XUL`mozilla::a11y::PDocAccessibleParent::SendName(this=0x000000013371e2c0, aID=<unavailable>, name=0x00007ffeefbfb250, flag=0x00007ffeefbfb224) at PDocAccessibleParent.cpp:311:20 [opt]
    frame #9: 0x00000001060ea15d XUL`mozilla::a11y::ProxyAccessible::Name(this=<unavailable>, aName=<unavailable>) const at ProxyAccessible.cpp:35:19 [opt]
    frame #10: 0x00000001060803a8 XUL`-[mozAccessible moxLabel](self=0x000000012a2d3400, _cmd=<unavailable>) at mozAccessible.mm:593:28 [opt]
    frame #11: 0x0000000106076be0 XUL`-[MOXAccessibleBase accessibilityAttributeValue:](self=0x000000012a2d3400, _cmd=<unavailable>, attribute="AXDescription") at MOXAccessibleBase.mm:139:15 [opt]
    frame #12: 0x00007fff2fd1c77a AppKit`NSAccessibilityGetObjectForAttributeUsingLegacyAPI + 371
    frame #13: 0x00007fff302d8f93 AppKit`___NSAccessibilityEntryPointValueForAttribute_block_invoke.805 + 2548
    frame #14: 0x00007fff302d4a74 AppKit`NSAccessibilityPerformEntryPointObject + 16
    frame #15: 0x00007fff2ff98c01 AppKit`_NSAccessibilityEntryPointValueForAttribute + 168
    frame #16: 0x00007fff300da0b3 AppKit`-[NSObject(NSAccessibilityInternal) _accessibilityValueForAttribute:clientError:] + 351
    frame #17: 0x00007fff300df1ce AppKit`CopyAppKitUIElementAttributeValueNoCatch + 98
    frame #18: 0x00007fff300dc0b2 AppKit`CopyAttributeValue + 142
    frame #19: 0x00007fff30ccf3f6 HIServices`_AXXMIGCopyAttributeValue + 389
    frame #20: 0x00007fff30cf04cb HIServices`_XCopyAttributeValue + 443
    frame #21: 0x00007fff30caff64 HIServices`mshMIGPerform + 174
    frame #22: 0x00007fff329fd304 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
    frame #23: 0x00007fff329fd250 CoreFoundation`__CFRunLoopDoSource1 + 541
    frame #24: 0x00007fff329fbd79 CoreFoundation`__CFRunLoopRun + 2270
    frame #25: 0x00007fff329fae3e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #26: 0x00007fff31627abd HIToolbox`RunCurrentEventLoopInMode + 292
    frame #27: 0x00007fff316277d5 HIToolbox`ReceiveNextEventCommon + 584
    frame #28: 0x00007fff31627579 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
    frame #29: 0x00007fff2fc6d039 AppKit`_DPSNextEvent + 883
    frame #30: 0x00007fff2fc6b880 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
    frame #31: 0x0000000104fdda5e XUL`-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:](self=0x000000010204f9d0, _cmd=<unavailable>, mask=18446744073709551615, expiration=0x00007fff8a2aa618, mode="kCFRunLoopDefaultMode", flag=YES) at nsAppShell.mm:171:24 [opt]
    frame #32: 0x00007fff2fc5d58e AppKit`-[NSApplication run] + 658
    frame #33: 0x0000000104fde87d XUL`nsAppShell::Run(this=0x000000011c2d0040) at nsAppShell.mm:692:5 [opt]
    frame #34: 0x00000001062f6707 XUL`nsAppStartup::Run(this=0x0000000117fd14c0) at nsAppStartup.cpp:270:30 [opt]
    frame #35: 0x00000001063c84a8 XUL`XREMain::XRE_mainRun(this=0x00007ffeefbff340) at nsAppRunner.cpp:5091:22 [opt]
    frame #36: 0x00000001063c8c3d XUL`XREMain::XRE_main(this=0x00007ffeefbff340, argc=5, argv=0x00007ffeefbff918, aConfig=<unavailable>) at nsAppRunner.cpp:5283:8 [opt]
    frame #37: 0x00000001063c8f88 XUL`XRE_main(argc=<unavailable>, argv=<unavailable>, aConfig=<unavailable>) at nsAppRunner.cpp:5339:21 [opt]
    frame #38: 0x000000010000315c firefox`main [inlined] do_main(argc=<unavailable>, argv=0x00007ffeefbff918, envp=0x00007ffeefbff948) at nsBrowserApp.cpp:218:22 [opt]
    frame #39: 0x0000000100002eca firefox`main(argc=<unavailable>, argv=<unavailable>, envp=0x00007ffeefbff948) at nsBrowserApp.cpp:336 [opt]
    frame #40: 0x00007fff6ca6ccc9 libdyld.dylib`start + 1
    frame #41: 0x00007fff6ca6ccc9 libdyld.dylib`start + 1

Here is the content stack:

* thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff6cbb0882 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff6cc71425 libsystem_pthread.dylib`_pthread_cond_wait + 698
    frame #2: 0x0000000115b1a17c libmozglue.dylib`mozilla::detail::ConditionVariableImpl::wait(this=<unavailable>, lock=<unavailable>) at ConditionVariable_posix.cpp:108:11 [opt]
    frame #3: 0x00000001005aafa1 XUL`mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) [inlined] mozilla::OffTheBooksCondVar::Wait(this=0x0000000132838f08) at CondVar.h:57:11 [opt]
    frame #4: 0x00000001005aaf85 XUL`mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) [inlined] mozilla::Monitor::Wait(this=0x0000000132838ec8) at Monitor.h:35 [opt]
    frame #5: 0x00000001005aaf85 XUL`mozilla::SyncRunnable::DispatchToThread(nsIEventTarget*, bool) [inlined] mozilla::MonitorAutoLock::Wait(this=<unavailable>) at Monitor.h:71 [opt]
    frame #6: 0x00000001005aaf85 XUL`mozilla::SyncRunnable::DispatchToThread(this=0x0000000132838ea0, aThread=<unavailable>, aForceDispatch=<unavailable>) at SyncRunnable.h:71 [opt]
    frame #7: 0x0000000102748dea XUL`mozilla::RemoteDecoderManagerChild::LaunchRDDProcessIfNeeded(mozilla::RemoteDecodeIn) [inlined] mozilla::SyncRunnable::DispatchToThread(aThread=0x0000000117a8f820, aRunnable=0x0000000135cbaaf0, aForceDispatch=false) at SyncRunnable.h:102:15 [opt]
    frame #8: 0x0000000102748d72 XUL`mozilla::RemoteDecoderManagerChild::LaunchRDDProcessIfNeeded(aLocation=<unavailable>) at RemoteDecoderManagerChild.cpp:328 [opt]
    frame #9: 0x000000010274cbeb XUL`mozilla::RemoteDecoderModule::Supports(this=0x0000000134f71da0, aParams=0x00007ffeefbfbd88, aDiagnostics=0x0000000000000000) const at RemoteDecoderModule.cpp:54:3 [opt]
    frame #10: 0x00000001027e3042 XUL`mozilla::PDMFactory::Supports(mozilla::SupportDecoderParams const&, mozilla::DecoderDoctorDiagnostics*) const at PDMFactory.cpp:618:18 [opt]
    frame #11: 0x00000001027e300a XUL`mozilla::PDMFactory::Supports(this=0x0000000135cbaac0, aParams=<unavailable>, aDiagnostics=0x0000000000000000) const at PDMFactory.cpp:423 [opt]
    frame #12: 0x00000001027e2f2a XUL`mozilla::PDMFactory::SupportsMimeType(this=0x0000000135cbaac0, aMimeType=<unavailable>, aDiagnostics=0x0000000000000000) const at PDMFactory.cpp:404:10 [opt]
    frame #13: 0x00000001027c6b97 XUL`mozilla::MP3Decoder::IsSupportedType(mozilla::MediaContainerType const&) [inlined] mozilla::MP3Decoder::IsEnabled() at MP3Decoder.cpp:16:20 [opt]
    frame #14: 0x00000001027c6b56 XUL`mozilla::MP3Decoder::IsSupportedType(aContainerType=0x00007ffeefbfbea8) at MP3Decoder.cpp:24 [opt]
    frame #15: 0x00000001025802aa XUL`mozilla::CanHandleMediaType(aType=0x00007ffeefbfbf40, aDiagnostics=0x00007ffeefbfbfc0) at DecoderTraits.cpp:184:7 [opt]
    frame #16: 0x00000001025029e8 XUL`mozilla::dom::HTMLMediaElement::GetCanPlay(aType=<unavailable>, aDiagnostics=0x00007ffeefbfbfc0) at HTMLMediaElement.cpp:4940:7 [opt]
    frame #17: 0x000000010250c22b XUL`mozilla::dom::HTMLMediaElement::CanPlayType(this=0x000000011d6ce800, aType=0x00007ffeefbfc1e8, aResult=0x00007ffeefbfc138) at HTMLMediaElement.cpp:4957:27 [opt]
    frame #18: 0x00000001020d400a XUL`mozilla::dom::HTMLMediaElement_Binding::canPlayType(cx=0x0000000117b2e000, obj=<unavailable>, void_self=0x000000011d6ce800, args=0x00007ffeefbfc310) at HTMLMediaElementBinding.cpp:519:24 [opt]
    frame #19: 0x0000000102155135 XUL`bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(cx=0x0000000117b2e000, argc=1, vp=<unavailable>) at BindingUtils.cpp:3229:13 [opt]
    frame #20: 0x00000001044ac3be XUL`js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [inlined] CallJSNative(cx=0x0000000117b2e000, native=(XUL`bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) at BindingUtils.cpp:3203), reason=<unavailable>, args=0x00007ffeefbfc4d8)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) at Interpreter.cpp:507:13 [opt]
    frame #21: 0x00000001044ac371 XUL`js::InternalCallOrConstruct(cx=0x0000000117b2e000, args=0x00007ffeefbfc4d8, construct=<unavailable>, reason=<unavailable>) at Interpreter.cpp:599 [opt]
    frame #22: 0x00000001044acd1f XUL`InternalCall(cx=<unavailable>, args=<unavailable>, reason=<unavailable>) at Interpreter.cpp:664:10 [opt] [artificial]
    frame #23: 0x00000001044a5aa9 XUL`Interpret(JSContext*, js::RunState&) [inlined] js::CallFromStack(cx=0x0000000117b2e000, args=0x00007ffeefbfc4d8) at Interpreter.cpp:668:10 [opt]
    frame #24: 0x00000001044a5a9f XUL`Interpret(cx=0x0000000117b2e000, state=<unavailable>) at Interpreter.cpp:3337 [opt]
    frame #25: 0x000000010449d193 XUL`js::RunScript(cx=0x0000000117b2e000, state=0x00007ffeefbfc910) at Interpreter.cpp:477:13 [opt]
    frame #26: 0x00000001044ac7f1 XUL`js::InternalCallOrConstruct(cx=0x0000000117b2e000, args=0x00007ffeefbfca38, construct=NO_CONSTRUCT, reason=<unavailable>) at Interpreter.cpp:636:13 [opt]
    frame #27: 0x00000001044acd1f XUL`InternalCall(cx=<unavailable>, args=<unavailable>, reason=<unavailable>) at Interpreter.cpp:664:10 [opt] [artificial]
    frame #28: 0x00000001044acd7c XUL`js::Call(cx=0x0000000117b2e000, fval=JS::HandleValue @ scalar, thisv=JS::HandleValue @ scalar, args=0x00007ffeefbfca38, rval=JS::MutableHandleValue @ r14, reason=<unavailable>) at Interpreter.cpp:681:8 [opt]
    frame #29: 0x0000000104a910cc XUL`js::jit::InvokeFunction(cx=0x0000000117b2e000, obj=<unavailable>, constructing=<unavailable>, ignoresReturnValue=false, argc=1, argv=0x00007ffeefbfcba0, rval=JS::MutableHandleValue @ 0x00007ffeefbfcb00) at VMFunctions.cpp:754:10 [opt]
    frame #30: 0x0000000104a91400 XUL`js::jit::InvokeFromInterpreterStub(cx=<unavailable>, frame=<unavailable>) at VMFunctions.cpp:774:8 [opt]
    frame #31: 0x0000096bb3a00fa4

Yes, I can also reproduce the issue on Nightly84.0a1(20201104095518) Windows10.
Profiler : https://share.firefox.dev/2HWrUx7

Status: RESOLVED → REOPENED
status-firefox84: fixed → affected
Resolution: FIXED → ---

I forgot a stray call to stop the RDD to be launched in the caller :(

Assignee: nobody → jyavenard
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/175273a49304 Don't attempt to launch the RDD process when it's not needed. r=mattwoodrow

https://hg.mozilla.org/mozilla-central/rev/175273a49304

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
status-firefox84: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

Can you confirm that today's nightly is fixed for you?

Flags: needinfo?(eitan)

(In reply to Jean-Yves Avenard [:jya] from comment #30)

Can you confirm that today's nightly is fixed for you?

This problem is no longer reproduced since Nightly84.0a1 (2001106093443).

Status: RESOLVED → VERIFIED
Flags: needinfo?(eitan)
See Also: → 1737193
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: