Suggestions for Sigil Improvements or New Features

[KevinH]

Your debug log shows the location being set properly and used once but then somehow the location (tag name and child number info) is lost. And exactly as you said, there are no javascript console errors.

Very strange. I will have to try and run a Windows build done by CI tomorrow on my old Linux box to see if I can see where the location is being lost.

[DNSB]

Recompiled and still get the preview moving to the top of the file when I open the stylesheet. However, I did notice that if I click on the CodeView tab for the HTML file and then click in the code, preview moves back to that position.

[theducks]

I did not run the RED test.
But I did run my normal Adjust the CSS sequence with the preview about mid point (where I want the adjustment). The adjustments took, I saw the preview refresh the screen AND STAY where I left it.
Previously, it would revert to the top.
W10 x64

BTW it was EPUB2 if that matters

[KevinH]

Arrgghhh! Thanks for checking. We are back to square one. For some reason the location is getting stepped on.

I will try adding some key debug in places and trying a Windows CI build in a vm on my old Linux box.

Something unexpected is going on. Not sure what.

[KevinH]

Originally Posted by theducks

I did not run the RED test.
But I did run my normal Adjust the CSS sequence with the preview about mid point (where I want the adjustment). The adjustments took, I saw the preview refresh the screen AND STAY where I left it.
Previously, it would revert to the top.
W10 x64

BTW it was EPUB2 if that matters

Great thanks for testing and reporting back. You are seeing exactly what I hoped for but DNSB is showing it doesn't work. Epub2 vs Epub3 should not matter here.

So it sounds like a race between 2 events, when one wins, everything works but when the other wins, it fails.

I thought this was going to be an easy fix but it is going to take some digging.

[DiapDealer]

Remember you can manually run just the Windows CI action and it will build an installer you can use. I should also be around this weekend to help do some Windows debugging.

[DNSB]

Before I installed the new compile of Sigil, I ran the previous one and noticed that I got two error messages at the end.

Debug: Caching:  "OEBPS/Chapter-07.xhtml"
Debug: Caching:  "OEBPS/Chapter-07.xhtml"
Critical: Request Autofill.enable failed. {"code":-32601,"message":"'Autofill.enable' wasn't found"}
Critical: Request Autofill.setAddresses failed. {"code":-32601,"message":"'Autofill.setAddresses' wasn't found"}

[DNSB]

Installed a compile of Sigil from a download from when the debug was first enabled. No issues with moving around in preview when shifting to the stylesheet though preview did refresh each time. I added color: blue to the p tag and it applied immediately.

OTOH, I put the same executable on an old laptop. The location in preview bobbed around.

I suspect a race conditions and those tend to be so much fun...

[KevinH]

Originally Posted by DiapDealer

Remember you can manually run just the Windows CI action and it will build an installer you can use. I should also be around this weekend to help do some Windows debugging.

Great! As I do think it is a event race for some unknown reason.

Last night, I pushed to Sigil master some selected extra debug info.

And yes I should have done the CI deploy manually on just Windows and forgot I could do that so I did a full deploy.

If you get a chance using the very last deploy build of Sigil on Windows, I would love to see the debug log from running the Alice epub test described earlier, I have the same output from my Mac (and Linux) to compare against.

Thanks!

[BeckyEbook]

Last deploy.

Sample from @RnbJrg – works [image]

Alice – Unfortunately, after opening the CSS file, the preview jumps to the top of the XHTML file [debug].

[KevinH]

@BeckyEbook
Thank you that really helped. Here is the critical snippet:

Debug: MW: UpdatePreview()
Debug: MW: UpdatePreview requested from CSS or SVG - saving tab content
Debug: MW: UpdatePreview to non-html resource, using Previous
Debug: ViewPreview GetCaretLocation:  ""
Debug: MW: UpdatePreview using current PreviewWindow location
Debug: Caching:  "OEBPS/Chapter-07.xhtml"
Debug: MW: Invoking UpdatePage with:  "OEBPS/Chapter-07.xhtml"
Debug: clearing Preview's httpcache
Debug: ViewPreview Cache Cleared
Debug: Javascript error:  QWebEnginePage::ErrorMessageLevel "Uncaught TypeError: Cannot read properties of null (reading 'scrollWidth') on line:7 Source:sigil:///C:/Users/Becky/AppData/Local/sigil-ebook/sigil/workspace/Sigil-RPNDuX/OEBPS/Chapter-07.xhtml"
Debug: MW: UpdatePreview()
Debug: MW: UpdatePreview to non-html resource, using Previous
Debug: MW: UpdatePreview()
Debug: MW: UpdatePreview to non-html resource, using Previous
Debug: ViewPreview GetCaretLocation:  ""
Debug: MW: UpdatePreview using current PreviewWindow location

There are two things of note. You are still getting that weird javascript error but at least it is not causing problems this time:

Debug: Javascript error: QWebEnginePage::ErrorMessageLevel "Uncaught TypeError: Cannot read properties of null (reading 'scrollWidth') on line:7 Source:sigil:///C:/Users/Becky/AppData/Local/sigil-ebook/sigil/workspace/Sigil-RPNDuX/OEBPS/Chapter-07.xhtml"

But even earlier that that a javascript call to get the current location of the cursor in Preview failed:

Debug: ViewPreview GetCaretLocation: ""

This javascript routine should never return an empty string. It should at least have the html and body tags in the path if the file is correctly loaded.

So either that file is not loading from the cache properly, or the timing of when we run the javascript to get the current location is broken somehow.


I was finally able to get my Windows 11 VM to fire up and was able to take the latest Windows build and run the same tests and in every case, eventually the GetCaretLocation javascript is failing.

This results in Preview losing its stored last location and from there on out it will default to the top of the file.

I will try to now track down what is happening that causes the javascript routine to fail.

All of that said, in no place am I seeing any javascript log error messages.

[DiapDealer]

Running on Windows 10 (Sigil built on Windows 11). I'm not sure where everyone got their Alice in Wonderland so I hope I'm not comparing apples to oranges....

With the latest master, Sigil is behaving the way I would expect with the test. Chapter 7 in Preview stays synced after opening the css file, and after editing the css file (Preview flashes and then resyncs).

No javascript errors in the debug output.

I've not yet tested the svg issue or the injected custom files from the user preference folder.

[KevinH]

Originally Posted by DiapDealer

Running on Windows 10 (Sigil built on Windows 11). I'm not sure where everyone got their Alice in Wonderland so I hope I'm not comparing apples to oranges....

With the latest master, Sigil is behaving the way I would expect with the test. Chapter 7 in Preview stays synced after opening the css file, and after editing the css file (Preview flashes and then resyncs).

No javascript errors in the debug output.

I've not yet tested the svg issue or the injected custom files from the user preference folder.

Yes, your debug log shows that the dreaded "ViewPreview GetCaretLocation" in your log always returns a proper location value ("html 1,body 57,p -1") inside Preview and not a "".

Is your test machine fast/hefty? My VM Windows 11 is horrendously slow and it always triggers the bug.

I have just pushed a potential fix to master. I will try to manully force the ci build.

If you have a slower Windows box around, would you please test it.

[DiapDealer]

Both of my current test machines are VMs. The Windows 10 is Virtualbox, and the Windows 11 is a qemu kvm. The qemu kvm is actually quite snappy, but I wouldn't expect the Virtualbox machine to be very fast. I'll make sure to grab my tired old Windows 10 laptop to test on as well.

EDIT: both VMs are very likely using software rendering for WebEngine. My laptop is configured that way too. Perhaps that's the missing variable here?

On your Windows VM, set the QSG_RHI_BACKEND environment variable to "opengl"

QSG_RHI_BACKEND=opengl

in your en-vars.txt file should suffice.

Everything works right for me when I have that set. It skips a lot of Vulkan and hardware nonsense and uses opengl (which strangely enough is often faster on Windows), so I set it a lot.

If I unset that variable, syncing stops and I get the javascript errors. When I reset it, all is well.

This is somehow down to webengine's software/hardware rendering engine choices. Ticking our preference box in Sigil to disable GPU hardware acceleration doesn't seem to be enough to get it working in this case.

[KevinH]

Originally Posted by DiapDealer

Both of my current test machines are VMs. The Windows 10 is Virtualbox, and the Windows 11 is a qemu kvm. The qemu kvm is actually quite snappy, but I wouldn't expect the Virtualbox machine to be very fast. I'll make sure to grab my tired old Windows 10 laptop to test on as well.

EDIT: both VMs are very likely using software rendering for WebEngine. My laptop is configured that way too. Perhaps that's the missing variable here?

Yes anything that impacts the order of events or time for any event could be a culprit.

My Linux box is a 12 year old iMac!