Repository navigation
Temporary file gets deleted too soon? #100
Description
Activity
It seems to be reproducible with practically any HTML file:
$ echo '<html><body>Example</body></html>' > example $ time xdg-open example xdg-open example 0.48s user 0.13s system 102% cpu 0.599 total $ time firefox example firefox example 0.05s user 0.02s system 73% cpu 0.101 totalSo it definitely is an
xdg-openbug as well.Another possible solution:
Add the possibility of detecting HTML MIME types (
text/html) and opening them with theopen_urlcommand instead of theopen_partcommand by default. Then I can just pointopen_urlatfirefox&and circumventxdg-open.- added a commit that references this issue
on Mar 5, 2022 A simple solution is to defer deleting all temporary files until we leave the thread view. I've mocked it up on the
defer-rm-tempbranch.A question is when opening a part with a foreground command, i.e. without a trailing
&, should the temporary file be deleted as soon as the command returns. That assumes the command only returns once the user is done viewing the part, which I guess would not be true if you usexdg-opento launch a web browser. On the other hand, email parts are small and keeping them around for a little longer doesn't really hurt.
I often find myself opening certain HTML emails in the browser, with "xdg-open&". I noticed that there is some delay (around a second) before the browser tab actually gets opened. (Only for these emails, for some reason) When this happens, bower has usually already deleted the temporary file by the time xdg-open has identified the file and forwarded it to the browser.
Obviously, the real bug here is that "xdg-open" takes too long on these files, for unknown reasons. But I think it's still bad UX from the side of bower for me to have to wait for the attachment to finish opening at all, before I can press away the message.
I think it would be better for bower to keep them around, either for a set amount of time, or until program exit. (I don't usually keep my mail client open when I'm not expecting mail, personally)