Preview Update Issue

[Turtle91]

A small change I've found that may count as a bug...?

On my windows 11 machine
- open an html file so you get a preview in the PW
- open/switch to the appropriate css file and make a change to a relevant css entry
- the PW reverts to 'no CSS applied at all' until you click on the html tab to refresh the PW

Previously the PW would automatically refresh when changes were made to the css sheet...this made it very usable to edit and see how your css changes affect the layout. With the current change, having to constantly re-activate the html file really slows things down.

[KevinH]

Are you sure you have properly linked the css and the xhtml file as this still works on my machine?

Try this:

1. open a blank new epub. Use BookBrowser Pop-Up menu to add a blank stylesheet.

2. Add this to the stylesheet:
body { color: bue; }

3. Use BookBrowser pop up on Section0001.xhtml to link the new stylesheet.

4. In Section0001.xhtml type some text inside the p tags, inside the body;
It should appear blue in Preview.

5. Go to stylesheet and change blue to red and Preview should almost immediately show the text colour change without having to reload the xhtml to see it.

Works for me on Linux (with my local build of Sigil), Linux using the AppImage, Mac OS x86_64 and MacOS arm64.

I have no active Windows box anymore to test anything with.


Also there were no changes in that area of code since the last release.

[KevinH]

Also you may see this effect if the code you entered in the css or the code you entered in the xhtml are not well-formed or not syntactically correct. Reloading xhtml in Preview will fix the code internally inside Qt, so something is displayed.

Please try my test and report back.

Also you can try validating the css file, and then run Mend on the xhtml file.

[BeckyEbook]

@KevinH: You are partially right. However, something has definitely changed.
This is particularly noticeable for people who use custom_preview_style.css (and custom_preview_style_alt.css) files.

In point 4 of your post, when you change the CSS, the custom_preview_style.css file suddenly stops being taken into account!
What's more, the "Cycle Custom CSS Files" button stops responding. In fact, it does respond to clicks, but this is not visible until we change the file in BookBrowser, for example.

I have a better way to demonstrate the problem.

1. Create a minimal custom_preview_style.css, e.g., with one line:

:root {background-color: pink;}

2. Follow your post, but run "Inspect Page" and go to the "Sources”' tab.
3. When you get to step 4 and change the color to red, you will see what happens:
3a. custom_preview_style.css is ignored (there is no "file://" in Inspect Page) and no pink background
3b. the "Cycle Custom CSS Files" button will not respond.

Tested on the latest Sigil on Windows 10 Pro.

[KevinH]

That is different from what is reported. Loading changed custom css should only work when editing an xhtml file not a css file. Injecting a different custom css file can only happen when editing an xhtml file as the old injected link will not change. Injection only happens when a Preview of an html file is loaded the first time. This is how Sigil and custom css has always worked because it is injected. But it may possibly be a new bug?

But first please try the test I gave exactly. Does it work or not?

If it works, then the reported issue can not be replicated on any platform.

Your report would then be a different bug report.

Again, nothing in loading css has changed in the Sigil sources since Sigil 2.6.2. If you see a bug, it probably then means a change in Qt might be the issue.

I will try your test to see what is going on Mac. Please try your test with Sigil 2.6.2 as well.

[BeckyEbook]

Yes. In such a simple example, your steps can be repeated and it works.

But in real files, I encounter the situation described by @Turtle91.
I have a regular EPUB file and regular CSS. I change something, but it is not visible until I change the file to another one (forcing the Preview window to refresh) and return to the previously edited one.

If I manage to "catch" such a situation, I will record a video.

[BeckyEbook]

One more scenario:

1. Empty EPUB, empty CSS
2. In xhtml: <p class="red">Test</p>
3. In css (linked of course) .red {color: red;}
4. Your text should be red. Is it? OK.
5. Now select ".red" in CSS file and use "Rename Selected Class"
6. Tada! Text is black and other problems described earlier also occur.

[KevinH]

Originally Posted by BeckyEbook

Yes. In such a simple example, your steps can be repeated and it works.

But in real files, I encounter the situation described by @Turtle91.
I have a regular EPUB file and regular CSS. I change something, but it is not visible until I change the file to another one (forcing the Preview window to refresh) and return to the previously edited one.

If I manage to "catch" such a situation, I will record a video.

Please post a test epub that shows this behaviour along with an exact set of steps to see the result, so we can both see the same thing.

[KevinH]

Originally Posted by BeckyEbook

One more scenario:

1. Empty EPUB, empty CSS
2. In xhtml: <p class="red">Test</p>
3. In css (linked of course) .red {color: red;}
4. Your text should be red. Is it? OK.
5. Now select ".red" in CSS file and use "Rename Selected Class"
6. Tada! Text is black and other problems described earlier also occur.

If the p tag has class green then why would you see red when changing a css selector with .red, you mean .green, right? Oh that was a typo, just fixed.

But what are you renaming the class red to?

Again please post a testcase and exact steps so I can see what you are seeing.

Please test that with Sigil 2.6.2 as well.

[KevinH]

1. Empty EPUB, empty CSS
2. In xhtml: <p class="red">Test</p>
3. In css (linked of course) .red {color: red;}
4. Your text should be red. Is it? OK.
5. Now select ".red" in CSS file and use "Rename Selected Class"
6. Tada! Text is black and other problems described earlier also occur.

Okay, I can recreate this one but it has always been this way. When you are editing a css file the text of the last xhtml file is kept in a cache. When you run Rename the class when editing a css file, the actual xhtml file that uses that class gets changed but the cache that stores the xhtml when editing the CSS does not. It never has. I could invalidate the cache when running that command but Preview must have something to show when editing in the CSS. Updating the cache contents is not possible as it is only set when actually loading xhtml into Preview.

Again Sigil has always worked this way.

If you want that behaviour to change then we can look into that as a future feature request.

None of the code has changed in this area.

[BeckyEbook]

This is a test file ONLY for the problem described in post #21.

I am changing the class name (in the CSS file) from ".red" to ".warning".

It turns out that this problem is even older (Update Preview Window also does not work then), because I see it in versions 2.5.2, 2.6.0, 2.6.2...

---

So it's possible that these are three different issues.
* One described by @Turtle91.
* The second related to ignoring custom_preview_style.css.
* The third related to the Preview window not responding after changing the class name in the CSS file.

[BeckyEbook]

Updating the cache contents is not possible as it is only set when actually loading xhtml into Preview.

Shouldn't the "Update Preview Window" button force a refresh of the Preview?

[KevinH]

It does but when editing a css file, Preview is loading its xhtml from a cache of the last edited xhtml file. This is done so changes in css alone will be immediately reflected in Preview.

Changes to the xhtml when editing a css file (such as rename class or use a different injected custom stylesheet css) are NOT reflected in the cached xhtml page. Changes to the xhtml made when editing css requires that you change tabs to that xhtml to see the new injection, or updated class= to appear.

Again, this has been standard behaviour in Sigil since custom stylesheet injection was first added, and when Rename Class was first added.


So maybe we should focus on the original report, as it does not involve changes to the underlying xhtml that happen when editing a css file.

If you can recreate that initial report with no custom css stylesheet changes and no Rename Class, then please post it and exact instructions to recreate it.

There could be a Qt change that is causing a problem that my simple test case is not tickling.

[Turtle91]

I am sure that the css is properly linked...

I am not using custom_preview_style.css, just a standard styles.css, although the issue may be somehow linked.

I have recorded a short video file, but I'm not sure if MR will allow a 65mb file to be posted?? I'll try and post it here but you may need to use this link to download from icloud


No, it didn't allow the upload.

edit:
one thing that may be causing the error... if I type slowly while editing the css, the refresh may be recognizing invalid code and discarding the entire css file. Once done with typing valid code the PW isn't refreshing from the invalid state???

[KevinH]

Invalid css or invalid xhtml will break things so all bets off then. But simply validate the css to remove it out of the equation.

A video without a duplicatable set of instructions and a test epub will not help much.