viewhtmlmail.py with Firefox about scripts

[akkana]

You're right -- that "Default" is just the name of one of my firefox profiles, and doesn't belong in the code. I've made the change you suggested, and also removed the -P Default from the ARGS argument. Some firefox users may sometimes need to go through a profile dialog; I haven't figured out the rules for when firefox does or doesn't require that.

I didn't include the WORKING_BROWSER change because the point of WORKING_BROWSER starting at None is so it tries the various browser options until it finds one that works.

WARNING: Another change I made this morning was to rename viewhtmlmail.py to viewmailattachments.py. There's still a file called viewhtmlmail.py but it's a symlink to viewmailattachments.py. These used to be two different scripts, which I integrated together under the viewhtmlmail name, but I've been regretting that because viewmailattachments is more descriptive since it's for more than just html mail. So using the viewhtmlmail.py name should still work, but I recommend changing any mutt configs or other files referencing these scripts to use the new preferred name, viewmailattachments.py.

[protist]

Thanks for the fix @akkana.

I agree with your logic about leaving WORKING_BROWSER as None, but I think you did change it to firefox in your commit [fixed]? I was a bit unclear in my original post, but I wasn't actually wasn't proposing hardcoding WORKING_BROWSER to firefox. It was just an ugly hack on my end to suppress the errors. I was thinking a better solution would be to only print the errors (perhaps just as "warnings"?) when in debug mode. IMO I don't think it's really an "error" if the user doesn't have these browsers installed, and it just pollutes the CLI.

I'm happy to submit a pull request, but I just wanted to check a few other things. What is the logic with the first_browser boolean and ARGS_FIRST vs. ARGS? If I interpret it correctly, the first browser checked has first_browser as True, and hence would be launched with ARGS_FIRST. Subsequent browsers would instead use ARGS. Why are there different arguments provided?

(Also, the name of the script needs to be changed in the comments too. And presumably -private-window should be removed from firefox's ARGS? [edit: I don't really understand the logic of opening it in a private window, as IMO clicking links within html should open in a "normal" window.])

[protist]

Hi @akkana, I just wanted to bump this comment. I was thinking about packaging this script up for Arch Linux's AUR, but just wanted to clarify these last few issues first. Thanks in advance.

[akkana]

Yes, sorry, I've been scrambling on another project.

You're right that I accidentally set the default browser to Firefox, and shouldn't have. I noticed that a few days later and changed it back to None. And you're right that not finding a browser isn't really an error, unless it can't find any of them.

You're correct about the difference between ARGS_FIRST and ARGS. The hope was that the first call would bring up up a new private browser window, then any subsequent attachments from the same email message would be new tabs within that window. Then if you call viewhtmlmail on a new message, you'd get a new window with its own set of tabs, so you have one window per email message. That worked with quickbrowse, but with qutebrowser it seems kind of random which existing window opens a new tab, and with firefox I've just given up since they seem to change how they react to command-line arguments a couple of times a year, and the documentation never matches what the app actually does.

I don't want to remove the -private-window because to me that's an important part of what viewhtmlmail does. People send all kinds of random stuff in email, and it's often stuff that I don't want anywhere near my regular browsing profile. Maybe viewhtmlmail.py should offer a --noprivate option so users have the choice, or it could read a ~/.config/viewhtmlmail where you can configure the details of browser use. I think private should be the default, though, because if you see a link in a private window you can always drag it to your regular browser window, whereas if you want it private but it opens in a non-private window, it's too late and there's no recourse.

I've changed a few comments and pushed a new version, but I think it's only comments that changed. Have I addressed all your questions? It would be cool to have it in AUR. It might be best to remove the quickbrowse section since quickbrowse isn't in AUR and may never be updated to qt6.

[protist]

Thanks @akkana. Sorry, didn't mean to push you on this; it was just on my mind. Totally understand the delay and all your comments make sense.

You're correct about the difference between ARGS_FIRST and ARGS... with firefox I've just given up

This also makes sense. However, shouldn't those two variables be the same for Firefox then?

I don't want to remove the -private-window

Ah okay, all good points! I hadn't thought about that. Is this mainly about sandboxing cookies away from the html mails?

It would be cool to have it in AUR. It might be best to remove the quickbrowse section since quickbrowse isn't in AUR and may never be updated to qt6.

I think it should be fine to just leave the quickbrowse part. Some people might want to install this (someone else might put it into AUR), and if it just skips on after not finding it, then no major harm done. Especially if the script is modified to suppress these warnings. I'm happy to submit a pull request; I can just put these messages in if DEBUG: blocks.

[akkana]

No worries, and I definitely don't mind you giving me a bump when I'm slow to respond.

And I guess "given up" was an exaggeration; those arguments worked for me in a couple of tests of firefox, so as of the version I was using then, I think they're correct. Just no guarantees that they'll work on every firefox version. I'm open to bug reports from firefox users if the arguments need to be updated, I just might not notice myself when firefox changes.

And sure enough, I forgot about your point about those browser messages not being important as long as a browser is found. I just checked in a version that handles that better: if a browser is found, the user won't see the errors from previous browsers tried, but if none of them work, the errors are printed. Also I added a -d to turn on debugging more easily.

[protist]

Thanks @akkana. I had a skim of the code, and that looks like a good solution.

Also, I just tested some of the Firefox arguments, and -new-tab doesn't do anything, whether with -private-window or without. So you can probably just remove the -new-tab argument.

You might have missed this.

Is this mainly about sandboxing cookies away from the html mails?

If so, I think it's a good compromise. However, for the record I just did a test, and private mode doesn't totally protect against this. It seems that private mode will prevent access to most cookies, but any new cookies generated in private mode are accessible in all new private-mode windows until the last private-mode window is closed. Hence, if a user has a few private-mode tabs open in general usage, then these cookies will be accessible by other private-mode tabs, including any from html mail. (FWIW I use the Temporary Containers add-on instead.) Having said all this, I think private mode is still probably the best solution for general users.

[akkana]

It's mostly cookie sandboxing, though are other issues too, like whether I want my regular browser profile to be active when loading "web bugs" or other tracking devices.

--new-tab works for me in firefox (currently 108.0.2), both with and without --private-window, using both single and double dashes. Firefox historically used single dashes (-new-tab) and that's what I had in the code, but firefox -h now lists everything with double dashes so I guess they're now preferred (which is good since it's more standard) so I just updated viewmailattachments.py to use the double-dash form. I don't know why it works in my firefox and not yours. I do notice I have to put the --new-tab before the --private-window; if they're in the other order, it opens the new window or tab but then doesn't load anything in it.

[protist]

Sorry, I should have been clearer. I mean on my Firefox (also 108.0.2) any html file opened from the CLI opens in a new tab, regardless of whether I use --new-tab (or single-dashed version) or not. In any case, having it there doesn't have any negative effects, so all good! I'm also creating a pull request to fix some minor comment issues.