Sigil crashes when loading file from the internet

[DiapDealer]

Originally Posted by KevinH

So we could try using a non-native file dialog box here on Windows as this testing of the file happens inside the qfiledialog and can not be screened for in advance by Sigil code.

Help me out. I've been looking for where the file open/select dialog actually gets launched when using the "Other Files" button in Dialogs/SelectFiles.cpp, but I keep coming up with nothing.

[KevinH]

It is a maze indeed. I think I tracked it down to BookBrowser->AddExisting(true) line from MainWindow.

See here:

https://github.com/Sigil-Ebook/Sigil...769C13-L769C24

[mrprobert]

Deleted

[KevinH]

This is kind of expected behaviour. .DS_Store files are MacOS folder metadata files. They are meant to be hidden from MacOS users. They are created inside every folder a user on MacOS opens in the finder for any length of time.

My guess is a MacOS user used FolderIn and FolderOut to work on an epub with tools outside Sigil or to add it to a github version control system. So it accidentally got scooped up and pulled in by FolderIn.

It is always safe to delete it from an epub (and even safe to always delete it on MacOS) but because it starts with a period, most folder file iterators will ignore it.

The one for plugins sees it but Sigil or the plugin does not properly delete it.

I will look into why when things slow down a bit.

[mrprobert]

Deleted

[BeckyEbook]

For me, the DeleteUnmanifestedFiles plugin deletes both files.

[DiapDealer]

Originally Posted by KevinH

It is a maze indeed. I think I tracked it down to BookBrowser->AddExisting(true) line from MainWindow.

See here:

https://github.com/Sigil-Ebook/Sigil...769C13-L769C24

Got it. Thanks! So it looks like both Windows and Linux are still using native file dialogs there, but only Windows crashes when encountering the url. Unless native file dialogs are being disabled on Linux in some other way.

Regardless, I'll see if using non-native there will change things on Windows.

[Doitsu]

Originally Posted by mrprobert

I then ran DeleteUnmanifestedFiles but only some.txt was deleted.

By default my very simple plugin ignored all files in META-INF because none of the files in there need to be manifested.

Obviously, BeckyEbook created a much better version.

[DNSB]

I do get the error popup and hide details/close buttons on multiple sites when I tried inserting an image directly from an URL. OTOH, I'm fairly certain that directly inserting a random image in a blank line in CodeView is definitely not going to work. Even trying to add the file to the Images virtual directory does not work with the identical error message.

I could copy/paste the URL into with wrapping code such as <p><img alt="random_image" src="https://dcdn.disk.zipjpg.com/free/342236f2a840108e64c42e14be935b56_2_-1_art.jpg"/></p> and it displayed in Preview and elsewhere after I deleted "?x-oss-process=image/format,jpg&big.jpg" from the end of the URL. But I definitely believe using remote URLs in an ebook that may be read on a device with no Internet connectivity is Not A Good Idea.

[KevinH]

Unless I am mistaken, I think it is a bug in the Native File Dialog on Windows. If we had another Qt app that used the native dialog and gave it a url, it would be interesting to see it crashes that app too. Also it would be interesting to see if a non-qt app like Notepad, and try to hand type in a url to the native Windows dialog and see if it crashes that app (ie. is it a Windows bug, or a Qt bug).

[Doitsu]

Originally Posted by KevinH

Unless I am mistaken, I think it is a bug in the Native File Dialog on Windows. If we had another Qt app that used the native dialog and gave it a url, it would be interesting to see it crashes that app too. Also it would be interesting to see if a non-qt app like Notepad, and try to hand type in a url to the native Windows dialog and see if it crashes that app (ie. is it a Windows bug, or a Qt bug).

MSPaint, which is obviously not a QT app, opens link1 and link2 without problems.

So does Notepad++. (It opens the files as text files.)

[BetterRed]

AFAIK calibre uses Windows native file dialogues, unless you tell it otherwise via its CALIBRE_NO_NATIVE_FILEDIALOGS EnvVar directive. Another possibility is qBittorrent.

BR

[mrprobert]

Originally Posted by KevinH

Unless I am mistaken, I think it is a bug in the Native File Dialog on Windows. If we had another Qt app that used the native dialog and gave it a url, it would be interesting to see it crashes that app too. Also it would be interesting to see if a non-qt app like Notepad, and try to hand type in a url to the native Windows dialog and see if it crashes that app (ie. is it a Windows bug, or a Qt bug).

I think Krita uses PyQt5 and Windows native file dialogs. Here's what I get on open:



I guess Krita is telling me to go fish.

[Doitsu]

Originally Posted by mrprobert

I think Krita uses PyQt5 and Windows native file dialogs. Here's what I get on open:

Attachment 216028

I guess Krita is telling me to go fish.

Maybe Krita doesn't support opening remote image files at all.

[KevinH]

Or there is a Qt bug in Qt6 since it is handled correctly in PyQt5 which uses the older Qt5.

Thanks!