Crash report: https://crash-stats.mozilla.org/report/index/d56fa15e-559b-44d3-b97d-a51bf0210301

MOZ_CRASH Reason: Attempting to create a 1260x32722 window/document

Top 10 frames of crashing thread:

0 libxul.so RustMozCrash /build/firefox-developer-edition/src/firefox-87.0/mozglue/static/rust/wrappers.cpp:17
1 libxul.so mozglue_static::panic_hook /build/firefox-developer-edition/src/firefox-87.0/mozglue/static/rust/lib.rs:89
2 libxul.so core::ops::function::Fn::call /build/rust/src/rustc-1.50.0-src/library/core/src/ops/function.rs:70
3 libxul.so std::panicking::rust_panic_with_hook /build/rust/src/rustc-1.50.0-src/library/std/src/panicking.rs:595
4 libxul.so std::panicking::begin_panic_handler::{{closure}} /build/rust/src/rustc-1.50.0-src/library/std/src/panicking.rs:497
5 libxul.so std::sys_common::backtrace::__rust_end_short_backtrace /build/rust/src/rustc-1.50.0-src/library/std/src/sys_common/backtrace.rs:141
6 libxul.so rust_begin_unwind /build/rust/src/rustc-1.50.0-src/library/std/src/panicking.rs:493
7 libxul.so std::panicking::begin_panic_fmt /build/rust/src/rustc-1.50.0-src/library/std/src/panicking.rs:435
8 libxul.so webrender::render_api::Transaction::set_document_view /build/firefox-developer-edition/src/firefox-87.0/gfx/wr/webrender/src/render_api.rs:318
9 libxul.so mozilla::layers::WebRenderBridgeParent::ProcessDisplayListData /build/firefox-developer-edition/src/firefox-87.0/gfx/layers/wr/WebRenderBridgeParent.cpp:1166

There's a handful of these crashes on Linux and macOS, in all cases with gigantic window sizes like:

Attempting to create a 1260x32722 window/document
Attempting to create a 952x65502 window/document
Attempting to create a 954x65500 window/document

The widths are suspiciously close to powers-of-two so I wonder if this might be an actual bug.

Brad, any chance this is related to those issues with large textures you were working on?

(In reply to Jim Mathies [:jimm] from comment #1)

Brad, any chance this is related to those issues with large textures you were working on?

Not related; it's a different limit defined at https://searchfox.org/mozilla-central/source/gfx/wr/webrender/src/render_task.rs#31. Nical is the author of some of the code that checks this limit; he'll know more.

Widget size constraints are communicated to the platform's API but we don't actually check that resize events honor these constraints. Let's see if enforcing the size constraints there fix the nonsensical window sizes we sometimes get on linux on android.

https://crash-stats.mozilla.org/report/index/05021332-9d14-4a49-a7ac-fa3ff0210424 is a report having source code links.

https://hg.mozilla.org/mozilla-central/file/33143ef17c70c76f39ac75fe51d3ae9342365845/gfx/wr/webrender/src/render_api.rs#l323

Presumably TransactionBuilder::SetDocumentView() is called from
https://hg.mozilla.org/mozilla-central/file/33143ef17c70c76f39ac75fe51d3ae9342365845/gfx/layers/wr/WebRenderBridgeParent.cpp#l1124

The assertion panics on sizes over 16384.

32722 would be a valid window dimension on X11. The protocol uses CARD16 for xEvent::configureNotify::height so I guess 65513, as in the crash report, can be received in events. That seems unlikely from an X server but perhaps plausible from a window manager. Perhaps this was on Wayland and I don't know what limits are involved there.

For all intents and purposes it is safe to assume that a window width or height of 32722 today is a bug somewhere even if the protocol can express it.

Funny enough (and luckily), I just ran into this assert and found a way to reliably reproduce it on a Fedora 34 gnome desktop on top of x11: https://crash-stats.mozilla.org/report/index/34ae8e22-c45b-4afd-92b2-bd8720210429 I was looking at a data:url image from a reftest run.

If I hover over the tab, I get the crash, most likely from a tooltip which tries to contain the whole dataurl as a single line string.

(In reply to Nicolas Silva [:nical] from comment #5)

For all intents and purposes it is safe to assume that a window width or height of 32722 today is a bug somewhere even if the protocol can express it.

With virtual screens, numbers up to 32767 can be expected.

(In reply to Nicolas Silva [:nical] from comment #6)

Funny enough (and luckily), I just ran into this assert and found a way to reliably reproduce it

Nice :)

Here are two crash reports with this bug's signature and interesting mac_crash_info:

bp-cf178404-030d-4316-be4a-59f420210615
bp-67f10cc0-57af-421f-afd6-321fc0210615

    {
      "num_records": 1,
      "records": [
        {
          "message": "Performing @selector(_setNeedsZoom:) from sender _NSThemeZoomWidget 0x10a02c000",
          "module": "/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit"
        }
      ]
    }

    {
      "num_records": 1,
      "records": [
        {
          "message": "Performing @selector(_setNeedsZoom:) from sender _NSThemeZoomWidget 0x1192b3800",
          "module": "/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit"
        }
      ]
    }

[@ wr_transaction_set_document_view ] should be added to crash signature

There is a user experiencing this issue on reddit: https://www.reddit.com/r/firefox/comments/ttzgv0/firefox_crashing/

I am currently using endeavour os with kde plasma firefox browser keeps crashing a lot

i was trying to resize my firefox browser. from small window to full screen.

Crash reports:

https://crash-stats.mozilla.org/report/index/aba962bc-03ff-4775-832b-5a5da0220401
https://crash-stats.mozilla.org/report/index/fbead01c-276c-4598-86f6-8af7a0220401
https://crash-stats.mozilla.org/report/index/925d3b3d-4ffa-4e2c-a8b1-cf4ba0220401

I've been having this issue since March 18, and I'm willing to follow steps to troubleshoot the issue.

Crash reports:
https://crash-stats.mozilla.org/report/index/13507f62-131c-4f82-bfb9-276e80220603
https://crash-stats.mozilla.org/report/index/7ae859f9-d416-4b7b-bb20-c2c470220603
https://crash-stats.mozilla.org/report/index/0c3c427d-27aa-4e6d-9c60-909c00220512
https://crash-stats.mozilla.org/report/index/51bfba25-f0f4-45d3-92a1-6d00a0220318

(These were unsubmitted crashes between 3/18 and now that I only just submitted)
https://crash-stats.mozilla.org/report/index/5c1af3de-2a4f-4ad5-9d82-3edad0220603
https://crash-stats.mozilla.org/report/index/450a3aa3-21e8-4a5b-9597-b974f0220603
https://crash-stats.mozilla.org/report/index/44e76050-5515-44c8-99fe-9bf390220603
https://crash-stats.mozilla.org/report/index/5bc63046-85b9-4953-a761-05d2e0220603
https://crash-stats.mozilla.org/report/index/3f523cce-ce22-42fa-89d7-380610220603
https://crash-stats.mozilla.org/report/index/09e6bc0e-cfcf-4659-940d-092430220603
https://crash-stats.mozilla.org/report/index/9892d99e-5aca-4eda-9d09-5ed1a0220603

In comment 12 are the crash reports of https://www.reddit.com/r/firefox/comments/v48aji/firefox_crashes_when_dragging_window/

(Manjaro Linux, KDE Plasma)
Seemingly at random, when I grab the top of a Firefox window and try to move it, the entire program crashes.
I've only noticed this happening if the window is 'snapped' (taking up the whole screen or half the screen), but I almost always have my windows like that, so I don't know if that's the cause.

Hi.
I'm experiencing Firefox crashes since version 101. I'm using (old) CentOS 7.3 with GNOME desktop environment. Interesting thing is that these crashes do not happen in KDE or XFCE desktop environments. Further, I have found that if I start Firefox with 'env -i' the crashes also do not happen. I am talking about this category of crashes: https://crash-stats.mozilla.org/signature/?product=Firefox&signature=webrender%3A%3Arender_api%3A%3ATransaction%3A%3Aset_document_view&date=%3E%3D2022-05-31T12%3A36%3A00.000Z&date=%3C2022-06-07T12%3A36%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&_sort=-version&page=1
They have all in common that some nonsensical window size was trying to be allocated (for example: Attempting to create a 28117x32840 window/document).
This, however, fixes it for me (starting firefox from the terminal, shell is bash):
env -i DISPLAY=:0 ./firefox/firefox
I have tried it with Firefox 101 and with beta 102b4 - it's the same.

Also, I have found another way that v 101 and newer do not crash with the above mentioned error: Go to Customize Toolbar and enable Title Bar (bottom left - there's a checkbox). When Title Bar is activated, I can't get Firefox to crash, but when the Title Bar is deactivated, I can crash Firefox by simply un-maximizing the window, for example.

(In reply to goran_obal from comment #14)

Also, I have found another way that v 101 and newer do not crash with the above mentioned error: Go to Customize Toolbar and enable Title Bar (bottom left - there's a checkbox). When Title Bar is activated, I can't get Firefox to crash, but when the Title Bar is deactivated, I can crash Firefox by simply un-maximizing the window, for example.

Unfortunately, this doesn't seem to be a universal fix. I've always had the title bar on, and I still experience these crashes.

Widget size constraints are communicated to the platform's API but we don't actually check that resize events honor these constraints. We do know that on some platforms we sometime get garbage sizes which crash the browsers. In some cases it is because Gecko requests unresonably large windows (For example a tooltip that contains an entire data-url), in some cases we know that the bug is on the window manager side (with a number of reports coming from gnome users) and unrelated to actual screen resolution and content.

This fix is the same as what landed a while ago on android.

https://hg.mozilla.org/mozilla-central/rev/95fe0652625c

I am testing nightly version 103.0a1 (2022-06-20) (64-bit).
The crashes do NOT happen anymore. If Firefox is stared maximized and I unmaximize the window, Firefox attempts to create a huge window ([GFX1-]: Failed to allocate a surface due to invalid size (DTD) Size(13479,16384)), which results in a very unusable GUI. Everything responds to clicks in a few seconds, instead of instantly. While it's nice that there are no crashes, this is not really usable. Just a thought experiment: what if we could find out why version 100.0.2 (64-bit) doesn't have this problem and find out what the key difference is and then maybe look for a fix that way?
Other finding I have is that if Firefox is closed unmaximized and then started again, the window size is normal and everything is working OK. There are no crashes, I can resize, maximize, unmaximize the windows as much as I want and everything is fine.
If I have the Title Bar enabled, there are no issues either way.
The only way that I have the described problems is if I close Firefox while maximized, open it again and then unmaximize the window, all that while not having Title Bar enabled.

goran_obal, you may want to open a new bug in regards to this issue (slowness after restore). Providing a Firefox profile may help locate what is slow as well: https://profiler.firefox.com.

The excessive sizes could be related to window decorations. The previously suggested workaround "Go to Customize Toolbar and enable Title Bar" changes the window decorations. Using gtk_window_get_size in nsWindow::OnSizeAllocate could help in this case.

From gtk_window_get_size documentation (https://docs.gtk.org/gtk3/method.Window.get_size.html):

Note that, if you connect to the GtkWidget::size-allocate signal, you should not use the dimensions of the GtkAllocation passed to the signal handler, as the allocation may contain client side decorations added by GTK+, depending on the windowing system in use.

Might be worth noting from the same documentation:

To avoid potential race conditions, you should only call this function in response to a size change notification, for instance inside a handler for the GtkWidget::size-allocate signal, or inside a handler for the GtkWidget::configure-event signal