-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Certain characters in the filename stop Dangerzone from working #144
Comments
Couldn't reproduce this under Linux (Ubuntu 20.04) on |
I also can't reproduce this right now in macOS. Let me check with people who were reporting this problem recently. |
The quoting on https://github.com/firstlookmedia/dangerzone/blob/8044f2276882e4d17570236138d024cecc80d61d/dangerzone/gui/main_window.py#L615 is suspicious, so maybe it's reproducible on Windows? (Also couldn't reproduce on Fedora 34/Qubes) |
On macOS 12.3, when running Dangerzone by double-clicking on the app, and loading a file called When launching the dangerzone gui from the terminal ( |
I've had to debug a few issues with dangerzone where there's a difference between running the GUI app from terminal vs. double-clicking the app to run it. The difference is the environment. In the terminal, the environment is inherited from the shell, but when you double-click it, there's different environment variables. For example, I fixed a bug like this by making use For some reason I can't reproduce this on my own Mac though--it just works for me when I double-click it. |
I can reproduce both issues (
Worth noting that #164, since it upgrades to Qt 6, removes that "QT_MAC_WANTS_LAYER" environment variable since it will no longer be necessary. Also, does dangerzone/dangerzone/gui/__init__.py Line 53 in d8adb2e
I have a suspicion... @micahflee, can you reproduce the issue if you use the official https://github.com/freedomofpress/dangerzone/releases/download/v0.3.1/Dangerzone-0.3.1.dmg distribution? If so, then the build is non-deterministic. Even though PySide2 was pinned to version 5.15.2, the Qt binaries themselves are determined by whatever your Mac's Xcode SDK version was when you first created the DMG, which may have changed between December and March. |
@gmarmstrong, as @micahflee already found out, there's indeed a difference between double-clicking on a "Mac OS app bundle" versus running the underlying executable from the terminal ( I recently encountered that very same issue my "Rust fork of Dangerzone"
ReferencesThere are probably better approaches than my solution, I'm more familiar with Linux than other operating systems. Approaches to the problem
Other links
|
(please ignore the above referenced commits)
I was unable to reproduce this under windows (neither on v0.3.1 nor from main branch). So I guess this is a mac-specific issue as others report. I was able to confirm all the findings above listed on an intel mac running macOS 12.0.
I don't think this is it. I can reproduce it with an intel mac running on the main branch but it only happens when I build the app bundle and execute de Dangerzone.app. If I run it via |
It is indeed Mac OS specific issue:
|
fixes freedomofpress#144: printing non-ascii characters in a macOS application opened directly from finder would sometimes lead to an error error message in /var/log/system.log similar to this: Failed to execute script 'dangerzone' due to unhandled exception: 'ascii' codec can't encode character '\u201c' in position 1: ordinal not in range(128)
fixes freedomofpress#144: printing non-ascii characters in a macOS application opened directly from finder would sometimes lead to an error message in /var/log/system.log similar to this: Failed to execute script 'dangerzone' due to unhandled exception: 'ascii' codec can't encode character '\u201c' in position 1: ordinal not in range(128)
I have a working fix for this. Turns out that it is this print that was causing us issues. printing non-ascii characters in a macOS application opened directly from finder would sometimes lead to an error message in /var/log/system.log similar to this:
While I could not get exactly to the bottom of what it was happening in the first place (possibly related to the lack of encoding support on the stdout of a gui-only mac application), replacing prints with logging fixes this and should be preferred anyways, so I replaced them all and now the issue is fixed. |
It looks like the characters
“
and”
prevent Dangerzone from working, as in the filename:“Wash Brains, Cleanse Hearts”_ Evidence from Chinese Government Documents about the Nature and Extent of Xinjiang’s Extrajudicial Internment Campaign _.pdf
The text was updated successfully, but these errors were encountered: