Steps to reproduce:

1. Open about:debugging and connect to a USB device.
2. Open another browser window and do a lot of typing in it, for example by filing a number of bugs.

Expected results:
Typing should be responsive as usual.

Actual results:
Around once a minute, typing briefly becomes unresponsive. A profile shows time spent in cycle collection: https://perfht.ml/2tV5jd3

My STR

• Inspect a twitch feed on the phone
• Open Network panel in the remote toolbox
• Let it run for a bit
• Open a new blank tab and profile with native allocation

Trying to capture this with native allocation points to an event listener fired from a worker that allocates strings: https://perfht.ml/3bFsyJo

0x3ca7f7c4b48f
js::jit::MaybeEnterJit(JSContext*, js::RunState&)
js::RunScript(JSContext*, js::RunState&)
js::RunScript
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
js::SpreadCallOperation(JSContext*, JS::Handle<JSScript*>, unsigned char*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>)
Interpret(JSContext*, js::RunState&)
js::RunScript(JSContext*, js::RunState&)
js::RunScript
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
mozilla::dom::EventListener::HandleEvent(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, mozilla::ErrorResult&)
mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, mozilla::dom::Event*, mozilla::dom::EventTarget*)
EventListener.handleEvent
mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event**, mozilla::dom::EventTarget*, nsEventStatus*, bool)
mozilla::EventTargetChainItem::HandleEvent(mozilla::EventChainPostVisitor&, mozilla::ELMCreationDetector&)
mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&)
mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*)
EventDispatcher::Dispatch message
EventDispatcher::Dispatch
mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsPresContext*, nsEventStatus*)
mozilla::DOMEventTargetHelper::DispatchEvent(mozilla::dom::Event&, mozilla::dom::CallerType, mozilla::ErrorResult&)
mozilla::dom::EventTarget::DispatchEvent(mozilla::dom::Event&)
mozilla::dom::MessageEventRunnable::DispatchDOMEvent(JSContext*, mozilla::dom::WorkerPrivate*, mozilla::DOMEventTargetHelper*, bool)
mozilla::dom::WorkerRunnable::Run()
Worker runnable
nsThread::ProcessNextEvent(bool, bool*)
<name omitted>
mozilla::dom::WorkerPrivate::DoRunLoop(JSContext*)
mozilla::dom::workerinternals::(anonymous namespace)::WorkerThreadPrimaryRunnable::Run()
nsThread::ProcessNextEvent(bool, bool*)
…

I don't have a phone I can use to test this today, but the STRs from the summary and comment 1 seem different.

Markus, can you confirm if you were only "connected" to a USB device in about:debugging, but you had no about:devtools-toolbox opened for this device (ie you had not clicked on any inspect button).

I didn't have any toolbox open, that's right.

I did have a bunch of open tabs with captured performance profiles though. I wonder if those profiles get manifested in the parent process and held onto as long as those tabs are open.
And then there's also the ghost window issue in bug 1617015.

The priority flag is not set for this bug.
:jdescottes, could you have a look please?

For more information, please visit auto_nag documentation.

S1 or S2 bugs needs an assignee - could you find someone for this bug?