User Agent: Firefox Nightly 77.0a1 (2020-04-14) (64-bit)

STR

1. Go to youtube.com
2. Open RDM
3. Ensure touch simulation is enabled
4. Ensure the selected device is set to "Responsive"
5. Click on video to watch.

Expected
RDM navigates to the video's URL

Actual
The tab crashes.

Notes: I can only seem to reproduce this issue when there is no device selected and touch simulation is enabled. Otherwise, navigation works just fine.

This is the error I get when this issue occurs:

###!!! [Parent][MessageChannel] Error: (msgtype=0x200001,name=PBrowser::Msg_AsyncMessage) Channel error: cannot send/recv


###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv


###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv


###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv


###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv


###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv

After using mozregression, I was able to narrow the root cause of this to Bug 1625934. See pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=09329f8a223b0e529b5345c7d1bb1b6008314a44&tochange=347e2906d742a72a8b787a6b54df9347b37572e0

12:35.35 INFO: Narrowed integration regression window from [b76975bb, 347e2906] (3 builds) to [09329f8a, 347e2906] (2 builds) (~1 steps left)
12:35.35 INFO: No more integration revisions, bisection finished.
12:35.35 INFO: Last good revision: 09329f8a223b0e529b5345c7d1bb1b6008314a44
12:35.35 INFO: First bad revision: 347e2906d742a72a8b787a6b54df9347b37572e0
12:35.35 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=09329f8a223b0e529b5345c7d1bb1b6008314a44&tochange=347e2906d742a72a8b787a6b54df9347b37572e0

The crash is from an assert that detects a document has a different presShell than the containing presShell. The call stack is just event handler code for a mousedown, but this one does a FlushPendingNotifications because presShell forces reflow on mousedown.

The triggering assert was added in Bug 1514511. Not sure what the relationship is, if any, between that bug and the change in touch event dispatch made in Bug 1625934.

And I've confirmed that if the assert from comment 3 is removed, this crash doesn't occur and the browser appears to handle the mismatched presShell case just fine. Presuming that the assert is testing something that should generally be true (presshell->document->presshell is a cycle), it seems there are two options:

1. This is an important invariant and RDM is violating it and needs to change.
2. This is just "mostly true" and RDM is an exception and we just need to document this better.

What is the stack of the crash? This is an important invariant, you're not supposed to flush on an old presShell.

#0	0x000000011475ff82 in mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:4095
#1	0x00000001105c5cb4 in mozilla::PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) at /Users/brad/mozilla/obj-central/dist/include/mozilla/PresShell.h:1453
#2	0x000000011475fa8f in mozilla::PresShell::DoFlushPendingNotifications(mozilla::FlushType) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:3999
#3	0x000000011094116e in mozilla::PresShell::FlushPendingNotifications(mozilla::FlushType) at /Users/brad/mozilla/obj-central/dist/include/mozilla/PresShell.h:1444
#4	0x00000001147a0c22 in nsPresShellEventCB::HandleEvent(mozilla::EventChainPostVisitor&) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:487
#5	0x00000001128144cd in mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) at /Users/brad/mozilla/central/dom/events/EventDispatcher.cpp:623
#6	0x0000000112817505 in mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) at /Users/brad/mozilla/central/dom/events/EventDispatcher.cpp:1055
#7	0x0000000114778cb5 in mozilla::PresShell::EventHandler::DispatchEventToDOM(mozilla::WidgetEvent*, nsEventStatus*, nsPresShellEventCB*) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:8410
#8	0x000000011477763d in mozilla::PresShell::EventHandler::DispatchEvent(mozilla::EventStateManager*, mozilla::WidgetEvent*, bool, nsEventStatus*, nsIContent*) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:7956
#9	0x0000000114771d4a in mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo(mozilla::WidgetEvent*, nsEventStatus*, bool, nsIContent*) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:7888
#10	0x00000001147718b6 in mozilla::PresShell::EventHandler::HandleEventUsingCoordinates(nsIFrame*, mozilla::WidgetGUIEvent*, nsEventStatus*, bool) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:6831
#11	0x000000011477018d in mozilla::PresShell::EventHandler::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:6636
#12	0x000000011476f3b2 in mozilla::PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*) at /Users/brad/mozilla/central/layout/base/PresShell.cpp:6561
#13	0x000000011427b952 in nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) at /Users/brad/mozilla/central/view/nsViewManager.cpp:750
#14	0x000000011427b64f in nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool) at /Users/brad/mozilla/central/view/nsView.cpp:1133
#15	0x00000001142ce0e7 in mozilla::widget::PuppetWidget::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&) at /Users/brad/mozilla/central/widget/PuppetWidget.cpp:381
#16	0x000000010ff68d1d in mozilla::layers::APZCCallbackHelper::DispatchWidgetEvent(mozilla::WidgetGUIEvent&) at /Users/brad/mozilla/central/gfx/layers/apz/util/APZCCallbackHelper.cpp:540
#17	0x0000000113ab4f65 in mozilla::dom::BrowserChild::DispatchWidgetEventViaAPZ(mozilla::WidgetGUIEvent&) at /Users/brad/mozilla/central/dom/ipc/BrowserChild.cpp:1737
#18	0x0000000113ab378f in mozilla::dom::BrowserChild::HandleRealMouseButtonEvent(mozilla::WidgetMouseEvent const&, mozilla::layers::ScrollableLayerGuid const&, unsigned long long const&) at /Users/brad/mozilla/central/dom/ipc/BrowserChild.cpp:1676
#19	0x0000000113ab3264 in mozilla::dom::BrowserChild::ProcessPendingCoalescedMouseDataAndDispatchEvents() at /Users/brad/mozilla/central/dom/ipc/BrowserChild.cpp:1528
#20	0x0000000113ab4cb1 in mozilla::dom::BrowserChild::RecvRealMouseButtonEvent(mozilla::WidgetMouseEvent const&, mozilla::layers::ScrollableLayerGuid const&, unsigned long long const&) at /Users/brad/mozilla/central/dom/ipc/BrowserChild.cpp:1646
#21	0x000000010f184b2d in mozilla::dom::PBrowserChild::OnMessageReceived(IPC::Message const&) at /Users/brad/mozilla/obj-central/ipc/ipdl/PBrowserChild.cpp:5150
#22	0x000000010e91fe37 in mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) at /Users/brad/mozilla/obj-central/ipc/ipdl/PContentChild.cpp:8410
#23	0x0000000113a6fb5d in mozilla::dom::ContentChild::OnMessageReceived(IPC::Message const&) at /Users/brad/mozilla/central/dom/ipc/ContentChild.cpp:3612

Looks like Bug 1623941 will resolve this.

I can't reproduce this anymore. I'll run mozregression to see if I can identify the fix.

(In reply to Brad Werth [:bradwerth] from comment #8)

I can't reproduce this anymore. I'll run mozregression to see if I can identify the fix.

Correction: I can still reproduce. However, I was able to confirm that the patches for Bug 1623941 resolve this.

This has been fixed in Nightly 78.0a1 by Bug 1623941

This is marked as P1 but bug 1623941 seems a bit too big to my taste to uplift in beta and fix this bug. Is that crash an edge case we can live a cycle with on the release channel? Does it happen only when fission is activated? Thanks

The bug only happens when the pref "devtools.responsive.browserUI.enabled" is set to true, which is currently only default true on Nightly. That makes uplift less imperative since most users won't encounter this bug this release cycle, and turning the pref off again is a viable workaround.

Reproduced the issue using Firefox 77.0a1 (20200414214610) on Windows 10x64.
The issue is verified fixed with Firefox 78.0b7 (20200612174529) on Windows 10x64, macOS 10.12 and Ubuntu 18.04. No tab crash while using devtools.responsive.browserUI.enabled:true pref and STR from comment 0.