Crash when window is across monitors of different density.
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: matrix.org, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0
Steps to reproduce:
Drag a Firefox (or Thunderbird) window from a high-DPI monitor to a regular-DPI monitor (or vice versa).
This also sometimes occurs when trying to drag a tab within a window. I suspect this is because when dragging sometimes a "drag window" appears and I think this sometimes ends up partially on a different monitor.
Note that moving a window to a different DPI monitor is fine. For example using a keyboard shortcut or using an "overview" mode to move monitors between displays. The issue only appears when dragging, presumably because the window is straddling two different DPIs at the same time.
Actual results:
Firefox (or Thunderbird) crashes.
Expected results:
The window drags as expected.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Can you attach your about:support information? Also, maybe you have a crash report id in about:crashes
? That would be extremely useful, I can't repro this on GNOME + Wayland.
Comment 3•3 years ago
|
||
(the case you're describing should generally be handled transparently by GTK, by choosing the higher DPI)
Reporter | ||
Comment 4•3 years ago
|
||
Reporter | ||
Comment 5•3 years ago
|
||
about:crashes doesn't work for me.
I'm using GNOME + Wayland as well. It seems to be unlikely to be a pure GTK issues since other GTK apps have no problem. I have only noticed it on Firefox and Thunderbird.
I do have MOZ_ENABLE_WAYLAND=1 set. So it is using native Wayland.
Comment 6•3 years ago
|
||
Ah, it seems you're using a distro build of Firefox (for NixOS, it seems?), which seems to disable crash reporting :(
Does this reproduce:
- With an official release build from https://www.mozilla.org/en-US/firefox/new/?
- With a Nightly build from https://nightly.mozilla.org?
You just need to extract the tar.bz2 and run MOZ_ENABLE_WAYLAND=1 ./firefox
. If it repros on an official build, ideally there will be a crash reporter window when it happens and then we can look at it. Alternatively (or if the crash reporter somehow doesn't show up), maybe NixOS has something like coredumpctl
that can allow you to grab a stack via gdb
?
Thanks.
Reporter | ||
Comment 7•3 years ago
|
||
Reporter | ||
Comment 8•3 years ago
|
||
Yeah, I found that the crash reported is disabled on NixOS by default (https://github.com/NixOS/nixpkgs/issues/107889). I'm trying to rebuild with it enabled but this may take a while. I've attached stack traces above. Might take a while...
I'll see if an official build works.
Reporter | ||
Comment 9•3 years ago
|
||
Doesn't appear to reproduce on the official build.
Comment 10•3 years ago
|
||
It seems the crash comes from mozilla::widget::WlCrashHandler
. On an official build or a build with the crash reporter set the crash reason would say what the underlying wayland protocol error is. Maybe it's in the journal?
Reporter | ||
Comment 11•3 years ago
|
||
Ok, the process doesn't appear to be quite as simple as I thought. But I have managed to get a reproduction pattern.
- Open a second window.
- Go to a Foundary VTT instance.
- Open a popup that is connect to the main window.
- Drag that across monitors.
The crash is definitely more general than this (I have seen it many times without Foundry on different machines) but this one reproduces reliably. maybe something about multiple windows.
Here is the crash: https://crash-stats.mozilla.org/report/index/b15f3c00-f7b0-43f3-85f6-799e10220507
Reporter | ||
Comment 12•3 years ago
|
||
It's not even that simple. I just dragged the window and it didn't crash. However closing, reopening, then dragging the popup triggered it.
journald said:
May 06 22:09:21 kevinryzen .gnome-shell-wr[1585]: WL: error in client communication (pid 8012)
Crash report: https://crash-stats.mozilla.org/report/index/5b969bd4-ba74-48c7-bfff-948170220507
Reporter | ||
Comment 13•3 years ago
|
||
Ah, got a crash on the official release: https://crash-stats.mozilla.org/report/index/43436786-55f1-45ab-8d42-8461b0220507
It took a couple of tries to trigger, maybe slightly less likely? But nothing conclusively different.
May 06 22:16:03 kevinryzen .gnome-shell-wr[1585]: WL: error in client communication (pid 10809)
Reporter | ||
Comment 14•3 years ago
|
||
Ah, the crash reports did appear to catch the error message:
wl_surface@113: error 2: Buffer size (615x480) must be an integer multiple of the buffer_scale (2)
Does sound DPI related to me and likely is triggered by the switch between monitors. Weird that it is so finicky though. Unless the window opened is a slightly random size each time that error is strange. Maybe it depends how much of the window is on each monitor?
Description
•