Wow! Excellent detective work!

I can now recreate it. It seems there are bugs in QtWebEngineView with Zoom being set needing to be set-again after each page load.

The problem is it must be done before the location to scroll to is set but after the page's resources are loaded.

I will try to figure out some way to get it working properly.

Thanks!

KevinH

Okay, this is really messy. It seems a call to setZoomFactor for a QWebEngineView does not complete instantaneously nor is it immediately reflected in the internal state of the QWebEngineView after the call returns.

So any attempt to immediately scroll and centre the Preview Window on a location fails as the window inner height returned by javascript is incorrect for zoom values different from 100% until the zoom is done completely.

The interface for setZoomFactor is not designed to be asynchronous and so there is no way I know about to check if the zoom is complete yet (ie. to wait until setZoomFactor has completed and be reflected inside the QWebEngineView).

To make the situation worse, anytime a page is loaded, its internal zoom value is seemingly set back to 100%, requiring us to use setZoomFactor each time and then wait some amount of time before trying to scroll.

So a delay is needed between the call to Zoom (setZoomFactor) and when we try to scroll to a location. Among a bunch of other changes needed, I have tried to add that delay in PreviewWindow.cpp.

So right now, a delay of 50ms seems to be sufficient when set in DelayedScrollTo by a singleshot in PreviewWindow.cpp once the zoom is done. I have no way to know if that is enough for all platforms. I tried with a delay of 30ms and it fails.

I have pushed this approach to master. So we need people who can pull and build on Windows and Linux to see if this approach can be made workable for all platforms so that Preview syncing when Preview is not set to 100% works.

Please let me know what you find if you do get a chance to play around with this test case.

I built a version for Windows and it seems ok now.

That's puzzling as I can't replicate Becky's findings.

I always have my preview window set to 80% and the synch between code and preview when editing the code works as expected for me.

https://www.mobileread.com/forums/at...1&d=1627919338

https://www.mobileread.com/forums/at...1&d=1627919338

@Ashjuk: Are you sure you have the 80% preview window?
The zoom is independent for the Code View and the Preview window.

The same zoom control works for both. So click in Preview after it loads and then move the zoom slider and it should only zoom the Preview.

Thanks for testing it. I am going to also try moving the call to setZoomFactor even earlier to see if that helps.

KevinH

We had a bug not all that long ago where the Zoom was resetting itself to 100% under certain conditions, but I can't seem to track it down now, to see just how we fixed it. I don't think it had anything to with what we're seeing now, but I just want to make sure that our fix for that (which was to reapply the zoom) isn't somehow exacerbating the problem and breaking sync.

I won't be able to test any builds on Linux until later this evening.

Yes. I have the preview set to 80% and the code view to 100%. Depending upon which window I have clicked the slider changes to reflect my setting.
If you look at the images I attached to my last post you can see the slider is at 80%.


I discovered that some time ago, as I just said to Becky, I have code set to 100% and preview to 80%.

Just a little puzzling that the 'bug' does not seem to affect me despite my having the preview window zoomed out.

It depends on the length of the file and where you are IN it as well. If the edits you're making are close enough to the top (or bottom) of a relatively small file, it's possible for the recent edit to still remain visible in the Preview Window even after the incorrect sync attempt. Try a good long xhtml file and scroll to the middle of it and see if that makes a difference.

I can see in the original images you posted that you're scrolled nearly to the bottom of the Preview Window. And that although the sync is still being botched after your edit, it's just not moving the needle enough to make a huge difference.

@Ashjuk: So how did you take your screenshots when we see Zoom 80% there? This can only be seen after clicking in the Preview window.
If you click on the Preview window, Code View synchronization will occur, and the problem we are discussing is Code View reverse synchronization -> Preview Window.

If you really have Code View 100% and Preview 80% then click on the red paragraph in the Code View and in the Preview window it will not be in the center, but a little above the center.

Yes, that extra Zoom call fix was needed due to a bug in QtWebEngine when you use load() or setUrl() it remembers the old zoom level but does not apply it meaning that all pages appear to have the correct zoomFactor but it is never actually applied. I think it compares it against its previous value and then does nothing since it appears to have not changed.

This does make this bug much worse.

I am still trying other approaches to see if they fix the issue in a more reliable way.

It seems that nothing I try that sets the zoom factor anytime before the load/setURL completes (ie. the loadFinished signal is generated) is just ignored by QtWebEngine. This is a bug as far as I am concerned.

This is what makes this bug hard as every time we load or reload a page after edits with a zoom factor set to something other than 1.0, we need to re-apply that zoom before scrolling to a particular location. But since zoom seems to be actually done asynchronously, we have to delay since there is no signal to tell us zoom is done.

I might try reversing the older to see if that helps (scroll first and then zoom).

Update: That fails too!

So right now the only "solution" is already in master. Let's hope it works on a wide variety of Windows, macOS, and Linux machines because I do not have a different solution that works.

Anything here useful? https://phabricator.kde.org/D12454

They seem to be moving their call to zoom to after a page starts to load: loadProgress()

I've also seen references to setZoomFactor being badly broken in QtWebEngine 5.15. Some people have resorted to calling it multiple times.

They are seeing the same bug I am but they pointed out that doing zoom in loadProgress will also work as a location to set page zoom. But when it reaches 100% it is effectively the same as loadFinished so I am not sure since theirs fires at 100% as well Worth a shot though.