Closed Bug 1575833 Opened 5 years ago Closed 5 years ago

WebRender + wayland reliably crashes when moving a tab into another window

Categories

(Core :: Graphics: WebRender, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: emilio, Unassigned)

References

(Blocks 2 open bugs)

Details

Launching Nightly with MOZ_ENABLE_WAYLAND=1 in the environment, and launching a WebRender-enabled profile, moving a tab from one window to another reliably crashes in mozilla::layers::GetStateForRoot:

https://crash-stats.mozilla.org/report/index/1b753bf5-2c52-4f12-b8ae-177fe0190822
https://crash-stats.mozilla.org/report/index/1e57a5c2-458a-4a1a-ac93-4d11f0190822

I suspect this is a recent regression since I do this from time to time.

Blocks: wr-linux

The crash seems similar to Bug 1575498.

See Also: → 1575498

:botond, can you comment to the bug?

Flags: needinfo?(botond)

The crash should be fixed in today's nightly by bug 1575498.

I do find it a bit strange that this codepath is being taken when moving a tab from one window to another. It suggests that the target window doesn't use APZ (while the source window does), which is unexpected. I think this deserves further investigation.

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

Whoops, didn't mean to change the status flag.

Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(botond)
Resolution: FIXED → ---

Emilio, what Linux distro / desktop environment do you use? Did you have to do any special setup to use Wayland (on your system in general, not for Firefox)?

I was able to get a Wayland environment by installing GNOME Desktop on Debian 10.

However, when I try to drag a tab from one window to another, what actually happens is the tab gets duplicated in the new window, rather than moved.

Are you moving the tab by some other means than dragging? Or is there a way to configure the behaviour of dragging a tab to a new window?

(In reply to Botond Ballo [:botond] from comment #6)

However, when I try to drag a tab from one window to another, what actually happens is the tab gets duplicated in the new window, rather than moved.

Interestingly, the duplication behaviour only happens with Wayland. If I start Firefox without MOZ_ENABLE_WAYLAND=1, dragging a tab moves it.

(In reply to Botond Ballo [:botond] from comment #7)

Interestingly, the duplication behaviour only happens with Wayland. If I start Firefox without MOZ_ENABLE_WAYLAND=1, dragging a tab moves it.

It looks like the duplication is not an expected behaviour. I filed bug 1576268 for it.

(In reply to Botond Ballo [:botond] from comment #3)

The crash should be fixed in today's nightly by bug 1575498.

Emilio, could you confirm this? I can't confirm it because I can't seem to get Firefox to exercise the RecvAdoptChild codepath in my setup (as per previous comments).

Flags: needinfo?(emilio)

Yeah, I cannot get it to crash now on latest nightly. But I can reproduce the duplication described above, or when it doesn't, the tab gets moved but renders just blank.

I'm on Fedora 30 fwiw, with nothing particularly fancy.

Flags: needinfo?(emilio)

Close this bug, since original crash as addressed.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → WORKSFORME

(In reply to Botond Ballo [:botond] from comment #8)

It looks like the duplication is not an expected behaviour. I filed bug 1576268 for it.

It turns out the duplication is expected behaviour in Wayland, as per bug 1576268 comment 2. The "move" beahaviour can be triggered by holding down Shift while dragging.

With that, I am now able to trigger a tab move under Wayland. Unfortunately, I can't trigger the crash (running a 2019-08-21 nightly, which includes the patch from bug 1565525 that introduced the crashing codepath, but not the patch from bug 1575498 which fixed the crash, with WebRender enabled).

So, while I continue to be mystified by why this codepath was being taken during a tab move into a regular window, not being able to reproduce it I'm not in a position to investigate, so I'll just let it be.

You need to log in before you can comment on or make changes to this bug.