request: save dialog improvements
wolftune opened this issue · comments
I'm testing with FF's reader-mode. When I click to create epub:
- The dialog that asks to confirm the author stays open (but blank) after saving
- The filename lacks
.epubwhich makes the "open with" or saving without changing name fail to open correctly with the ebook reader app from Calibre - The generated filename is a complex string of characters, not anything meaningful
Ideally, .epub should be appended automatically, the save dialogue should have the portion excluding .epub selected for name-change, and that portion should default to either a sanitized version of the URL or to the HTML title of the page being saved. That way, I could just click save and the default would be functional enough most of the time.
Otherwise, thanks for the great tool!
The popup thing is only (hopefully temporarily) necessary, because Firefox no longer lets extensions access the content of the reader mode pages.
First it should say "Loading ...", then prompt to confirm the name, then load some more, and finally change the text to "Done!" and open the save dialog.
The popup can't close itself, because that would also close the save/open dialog. But the popup shpuldn't be blank. It should say "Done!".
The name should be author (if one was found/entered), - , title (which is the title displayed in the reader mode) , plus the extension .epub.
There shouldn't be anything "complex without meaning" (unless that's the websites title).
So I don't see how what you describe could have happened.
I made some minor changes that should make the file naming a bit more ... robust. Please install the new development build (see README) and see if that helps!
Even with development version, given https://www.nytimes.com/2018/12/11/science/chicken-anthropocene-archaeology.html as an example:
I first get this is the dialogue title:
Then after the author entry I get this:
And if I do save, I see _3SzcFyM as the proposed name.
I do have a bunch of privacy-related plugins, but I don't know if that's relevant.
Reader mode looks fine. The plugin somehow still uses the same process as reader mode even though it doesn't access the reader mode directly?
Note: I'm on FF 62.0.3 on KDE Neon which is basically Ubuntu 16.04 (I want to update FF, but the integration with KDE is not updated yet, though I could try removing that and just having generic Ubuntu FF updated)
Yes, Mozilla provides the reader mode code as a library.
The file name in your screenshot is the URL of the file to download. It seems that your Firefox (profile) simply ignores the name (but note that the file type is correct).
I don't think that can be fixed on my end.
You could try a fresh profile and/or a standard version of Firefox. And I think you should be able to tell Firefox to open the files with the correct program regardless of the name.
I found the issue. It was solved by getting rid of the KDE-focused plasmazilla variant of Firefox and forcing the standard Ubuntu version. Unfortunately, that means I lose KDE native save dialogue. Instead, I am stuck overall with the clunkier GTK-style save dialogue. I hope it will be updated in a way that's compatible at some point. But anyway, I doubt there's anything you can do on your end.
For reference, it's https://launchpad.net/~plasmazilla etc.
Update: I installed latest 18.04-based KDE Neon and however it is set up, Firefox is not based on that plasmazilla PPA at least (I'm using the KDE Neon normal Firefox), and I again have the superior KDE dialogs and epub-creator is also working! Yay!