I just saw that @Mattches put up a Github for devs (Save as PDF issue - native finder dialogue getting stuck behind browser dialogue - #6 by Mattches) about this issue.
My below notes may or may not be of some help as it adds a bit more context as to how to get this to replicate, because I can do it fairly easily. I can see what it’s doing (I’m a technologist by trade), and I know it’s Mac OS since it’s the native dialog box. What I don’t know is what wizardry Safari is doing where it doesn’t ever happen there. Only Brave.
Description of the issue:
When you trigger a Save - doesn’t matter what you’re saving - and you have the option to Ask for Download Location (which everyone should, frankly, because Mac OS is stupid about default location), a Save As DIALOG BOX (aka NOT a “window”…a dialog box) pops up.
Suppose a user is clicking around after they initiate that save. If you click somewhere else, say navigating tabs, while the Save As dialog box is rendering, there’s a chance that it loses focus and gets “stuck” behind the active window somewhere and cannot be recovered. There’s also no way to cancel the request, because that can only be done when the dialog box is in focus. Moving every window out of the way does not find it.
You can see, on the tray where the Brave icon is, a small blue circle with a number. That’s appearing to represent queued downloads. You cannot interact with this in any way other than to long press to see windows (aka NOT the dialog box you need).
The only way to get past this is to kill Brave (aka lose your work/progress), which then tells you that there are downloads pending. It doesn’t let you complete them. You just have to lose them.
Just for folks: this is a bug with Mac OS that Apple has acknowledged with people who have contacted their support. So I’m not suggesting that Brave can “fix” anything, rather I’m requesting a way to enhance the UI such that we can terminate the rogue request ourselves and restart just that, without losing all work.
How can this issue be reproduced?
- Go to a site
- Download something
- Immediately after triggering the download and before the dialog box shows up, do something else - open a new tab, browse to a different site
Expected result:
The download request should immediately block everything until the dialog has presented; then the dialog should block everything until it’s received whatever response. That’s what Windows does, and why I can never replicate it over there.
Brave Version( check About Brave):
Version 1.73.97 Chromium: 131.0.6778.108 (Official Build) (arm64)
Additional Information:
Seems to be more easily replicated with larger downloads such as video files or executables or ZIPs, which implies that whatever preload is done when rendering the dialog has not yet completed before opening the window (which means the user can still interact with the browser), but the dialog box is not coded to re-establish and force focus when done.
DESIRED Resolution
Just make this a tracked download in the Downloads area (similar to what download managers do) so that it creates a “Pending” record there. Then you can go there from Settings and terminate (meaning you would have to add code that initiates the “Cancel” command we normally would do) and re-download as needed when this happens.