Did so by adding the following to the ~/.bashrc file:

I think I may have found the cause...

What made me report this problem / bug, even though I know that the GPU in that old crate is not a truely supported one, is that I rendered CPU only, then a GPU should not be involved, right...? 🤔

Using rB4e65b1ef6cda no crash log was written to /tmp, but I did grab this from the Terminal:

With daily build rBae379714e4f1 I had Blender 3.0.0 Alpha crash at the fifth bullet already.

Closing this report, reporting it at GNOME and hoping this report does stay inside the system, for others who may run into the same situation...

I just tried Blender 3.0.0 Alpha rB5f5cf21a833f and the problem is still there, switching Blender to "Window Fullscreen" and the mouse cursor in the viewport disappears. The same happens in a webbrowser (Brave / Chrome) too, when watching a YouTube video and then going fullscreen there, again the mouse cursor disappears, making it hard to change settings like resolution of the video.

I can not reproduce this problem on two Macintosh laptops (macOS 10.15.7 and 11.4), only on the Linux box I have access to.

Just for information, I am running the daily builds of Blender 2.93 beta (and before that alpha) on both Fedora 33 and 34, rendering the default cube on CPU only, not having a decent GPU at this moment. Renders as expected.

@Evan Wilson (EAW) That is not what we are seeing at https://builder.blender.org/download/daily/, there the hash code has been d5c3bff6e774 for three days in a row now, with changing archive file sizes for 2.93 beta.

The downloaded archive filesize is different too, not just on the Linux version, the Mac version too.

In T88431#1163528, @Brecht Van Lommel (brecht) wrote:

From the logs, I think it's already there.
https://builder.blender.org/admin/#/builders/10/builds/257/steps/6/logs/stdio

However it seems to not find OpenMP and Jack, which is an issue.

@irfan (Pearlcrafts) Are you really still on macOS Big Sur 11.0...? Apple has release many a required update for Big Sur already, at the moment of writing they are at 11.3.1 and 11.4 has seen daylight as a Release Candidate, should be out any day now.

Tried that on macOS 10.15.7 and found that you need to press the Tab key an additional four times to get from the RGB values into the Alpha value.

@Julian Eisel (Severin) Why not just remove the active region for this action completely? When the File Browser is active it is already at the top of all other Blender windows and can safely "listen" to a user pressing the Enter or Return keys...

@Julian Eisel (Severin) +1

I have been asking about this many times and versions, it is the same design flaw as T82002. The Enter key indeed only works when the mouse is over the file list, yet we need to click the filename itself, outside the file list, in order change it into the name we want to...

The problem is with Mutter, when following the following test fix, Blender can be toggled back and forth to fullscreen windows with a visible mouse cursor:

The same happens on two machines here, one with Fedora 33 Linux kernel 5.11.11, as well as on a MacBook Pro 13" running macOS 10.15.7, with the 3d7e3d5ad0b4 build from thursday evening as well as with the 0515ff70ec09 build from yesterday evening.

This #e0a1a2f49dab on an Apple MacBook Pro 13" from 2016 (running Big Sur 11.2.3 as well) with an Intel 540, not sure what you mean with Sharp though:

Working fine on an older MacBook Pro 13" with just an Intel HD 4000, running on macOS 10.15.7, as mentioned in https://developer.blender.org/T75832

@Nate (nlate) I just tried Blender 2.93 Alpha 321eef6a0c0f from April 3rd 2021 on an older MacBook Pro 13" with Intel HD 4000 running macOS 10.15.7 and there I can not reproduce the crash, this without a "Load Factory Settings" though...

When there is a default button, that entire dialog / window should respond to pressing the "Enter" or "Return" key, not just when the mouse is in / hovering over a smaller area of that dialog / window.

I can reproduce the bug under Fedora 33 and an Apple (Intel based) Macintosh with macOS Big Sur 11.2.1 too, both rendering on CPU only, with the description given by @Shankar Sivarajan (shankarsivarajan) :

Apple calls their operating system "macOS" these days, not "Mac OS X" anymore... ;)

With the build 3a1d1aaa86d0 from December 17th, 2020, HardOps (00986_MercuryX_33) can be enabled again, as well as BoxCutter (717_11). Delete your Blender Configs directory one more time and then install them.

What happens when you delete (or rename) your Blender Configs directory, a.k.a. start completely fresh, even fresher than a "Load Factory Settings"...? For Windows that would be in:

On an old MacBook Pro running 10.15.6 I can reproduce the problem with 2.91.0 Beta, branch: master, commit date: 2020-11-13 00:36, hash: rB2e08500d047e, Blender will completely crash and disappear, leading to the macOS its "has unexpectedly crashed" message.

Perhaps not a steady white but the color set in the Blender theme preferences...

@Richard Antalik (ISS) The glitch is a constant flickering while rendering, in the statusbar in the upper left, which shows the time rendered, time remaining, memory usage. Those numbers and their explaining meanings are rapidly flickering between white, red and cyan colors, while I personally think they should remain at a steady white...

Could not reproduce this with Blender hash 21cb6f09ffa8 on macOS 10.15.6 and Intel HD Graphics 4000

Seen a similar problem with mesa 20.04, it got fixed with mesa 20.07 and up

In D7893#190695, @William Reynish (billreynish) wrote:

Adding the ability to use bold and italics is nice, but probably we should add this properly using real font variants rather than generated variations, which are almost always a lot worse that bespoke weights.

And if we do that, I think it might be a good time to actually review the UI font we use to begin with - it's quite an old font that has since ben bested by other, better UI fonts.

I can reproduce on Fedora 32, start Blender, Load Factory Settings and select the default cube, hide it with the "h"-key and then pressing the TAB-key, this on Blender 2.83 Beta e5ace51295b9.

With the overnight update of the Fedora 32 Mesa drivers to version 20.0.7 Blender 50ef801a79b5 no longer crashes and also the current nightly build e5ace51295b9 does not crash upon closing the Preference and File Browser windows! Many thanks Clément (and others!) for your attention, time and patience!

Blender 2.90 Alpha f9d0f59bed4d works now, did the patch make it into Blender 2.83 Beta yet? For the buildbot version 50ef801a79b5 still crashes unfortunately...

It also happens with:

Fedora 32 here... Semi rolling release...

I concur with Eric, still crashing with hash 9605c2616696 here

Worked fine before I went from Fedora 31 to Fedora 32... And the crashes only occur when closing an extra Blender window, like Preferences or the File Browser, nothing exciting there...

System Information
Operating system: Linux-5.6.8-300.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits
Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.6.8-300.fc32.x86_64, LLVM 10.0.0) X.Org 3.3 (Core Profile) Mesa 20.0.5

Continues to crash with version: 2.83 (sub 15), branch: master, commit date: 2020-05-02 11:33, hash: rB1623fdb3bc55

Additional info: Didn't have this issue under Fedora 31... And Blender 2.79 doesn't have this problem while being under Fedora 32

Problem also exists in the official Blender 2.82a release, on the same system, after having deleted the complete ~/.config/blender directory...

This on several of the machines at my disposal, both on macOS and Linux...

With the current beta 2.82 and macOS 10.15.2 Catalina I have not had the problem yet, no...

I do not think it is a bug but activating Blender its factory-setup does not go far / deep enough, it does not delete preference files. Back then Blender crashed and kept crashing, until I manually deleted the Preferences folder for Blender.

I have been running the 2.82 beta on that same machine now, which has been updated to Ubuntu 19.10 in the mean time. So not an issue at this moment, no.

In the mean time I have updated / upgraded to Fedora 31 and with the current build from December 30th 2019, switching to fullscreen and back presents no problems.

This morning I downloaded the most recent Daily Build, version rB0812949bbc3d and found that it had the exact same problem. I tried launching it using the Terminal with a --factory-setup, still crashed right upon launching.

Goedemorgen Jeroen,

Here are some of the requested info-files, all created on the same machine, just switching between Fedora 30, where the Window Fullscreen causes a crash upon returning and Ubuntu 19.04, where it works like a charm... :

Unable to reproduce on macOS 10.14.5, MacBook Pro Mid 2012, Intel HD Graphics 4000, works fine with everything accessible.

Is there anything I can do to test that? It is not a machine with a real GPU, just an Intel HD 4000.

The earlier Ubuntu test was on another machine running 18.04.2LTS, but for completeness, I just formatted the machine running Fedora 30 and installed Ubuntu 19.04 on it, Blender its "Toggle Window Fullscreen" performed flawlessly.

I grab Blender 2.80 beta daily and yes, three or four version back it worked fine.

Are your popup menus and drop down menus from the menu bar transparent by any chance...? Then it could be related to UI graphics glitches on macOS with Intel HD 4000...?

In T65383#696221, @Brecht Van Lommel (brecht) wrote:

It's made a bit more complicated by the fact that de0cae29cf751 added additional fixes on this commit, so 77f5210f2233 by itself is already known to be wrong, it's the combined change that needs to be debugged.

This is the exact same problem as T65383, where a "Load Factory Settings" unfortunately doesn't change things. On a cleanly installed macOS machine with just Buildbot daily Blender 2.80 beta's installed.

Here you go:

On Blender 2.80 (sub 72) things were fine, didn't download sub 73, so can't tell when the UI artifacts got introduced. Nothing else changed on the machine except for a newer daily build of Blender.

Then I get this:

Tried the same buildbot version on another machine under Ubuntu 18.04.2 LTS and there the UI artifacts don't appear, just the macOS version (10.14.5)

That would be?