[BUG]: App crashes after setting user details on macOS

[Isaac-Leonard]

What happened?

When attempting to configure an image the imager crashes after the user details step.
I can select the device (raspberry 4), the OS (octopi), the disk to flash the image to, and the host name, then the country, timezone and keyboard locale, but when I click next after setting a username and password the app crashes with no error message or anything.
It also crashes if I leave the password and confirm password fields blank.

I’m using an m1 MacBook Pro running macOS Tahoe 26.4.1.

I don’t believe it’s relevant but I am using the voiceover screenreader which can sometimes interfer in weird ways.

Version

2.0.7

What host operating system were you using?

macOS

Host OS Version

Tahoe 26.4.1

Selected OS

Octopi

Which Raspberry Pi Device are you using?

Raspberry Pi 4B, 400, and Compute Modules 4, 4S

What kind of storage device are you using?

microSD Card in an internal reader

OS Customisation

• Yes, I was using OS Customisation when the bug occurred.

Relevant log output

[tdewey-rpi]

Thanks for the report, @Isaac-Leonard

This is an extremely surprising report - not least because macOS is my primary development platform, and I run through this flow several times per day.

I wouldn't expect VoiceOver to cause issues - as I do routinely test with that as well.

I'll see if this reproduces on the upcoming 2.0.9 - but if you have the macOS crash report, that would be exceptionally useful.

[m0ebp]

What happened?

When attempting to configure an image the imager crashes after the user details step. I can select the device (raspberry 4), the OS (octopi), the disk to flash the image to, and the host name, then the country, timezone and keyboard locale, but when I click next after setting a username and password the app crashes with no error message or anything. It also crashes if I leave the password and confirm password fields blank.

I’m using an m1 MacBook Pro running macOS Tahoe 26.4.1.

I don’t believe it’s relevant but I am using the voiceover screenreader which can sometimes interfer in weird ways.

Version

2.0.7

What host operating system were you using?

macOS

Host OS Version

Tahoe 26.4.1

Selected OS

Octopi

Which Raspberry Pi Device are you using?

Raspberry Pi 4B, 400, and Compute Modules 4, 4S

What kind of storage device are you using?

microSD Card in an internal reader

OS Customisation

• Yes, I was using OS Customisation when the bug occurred.

Relevant log output

[m0ebp]

Hello,
I too have exactly the same result. I too am a voice over user. I differ in that I was selecting a Ubuntu server image. A mac Mini M2, Tahoe 26.2. I was really grateful to see the accessibility of the imager and tried twice to write my SD for my Pi 400.
Gena

[m0ebp]

Hello,
Found a work around. Simply, CMD F5 to turn Voice Over off when on the Save/Next button and press enter. I did that for the following customisation screens for WiFi etc. So I suspect it is related to Voice Over It hasn't finished writing yet but certainly got me further. Fingers crossed..
Enjoy :-)

[tdewey-rpi]

Coming around to this now.

Thanks for your updates, @m0ebp. It appears that this is directly related to the VoiceOver navigation hooks I include, given you can avoid the crash by disabling the tool (thankfully, we do track the state via a binding, allowing the actions to be remapped as you turn on/off the tools).

[Isaac-Leonard]

It only seems to trigger when using the voiceover key plus space, simply hiting enter doesn’t seem to trigger it so avoiding it is easier then I originally thought and I was able to complete the imaging process.

[tdewey-rpi]

A very curious failure.

Examining the code in this area revealed a few things:

1. A double-register of password fields with accessibility tools. I believe this was the cause of your crash.
2. Some controls were constructed with knowledge of the screen reader state, but this was never updated - meaning turning on VoiceOver might've only registered some controls, and not others.
3. Text field contents were exposed via an incorrect field (as well as the correct one), creating confusion.

All 3 will be fixed for 2.0.9.