[Bug]: Cursor (Save Menu) not blinking!

[hayaku2]

Bug Description

When selecting "Save As", or even just Saving for the first time, a Window pops up, with the working file name highlighted in blue, text set in white [SEE IMAGE].

In a large number of cases, the blinking cursor simply does not appear. One can click at various places within the file name, thus changing where text will appear, but the blinking cursor simply isn't there. Makes things very confusing.

This requires closing the "Save As" menu and re-launching, after which, the cursor returns.

IN ORDER TO REPLICATE:

It seems that when you type some new text, there is a short lag, and then the "Preview" window on the right (or wherever it's docked) refreshes. After a "refresh" this bug will activate with 100% probability.

Platform (OS)

Windows (Default)

OS Version / Specifics

Windows 10

What version of Sigil are you using?

2.2.1

Any backtraces or crash reports

No response

[dougmassay]

It has to be a Qt/Windows thing. To my knowledge, we don't diddle the native Windows Save As dialog at all.

That said... I can't reproduce this on Windows 10. I type some text; wait for Preview to refresh; select Save As from the menu and get a blinking cursor. No matter where I try placing the cursor in the filename.

I've tried with a Light Theme, a Dark Theme, new epub, existing epub, and I always get a blinking cursor in the Save As dialog.

[dougmassay]

You could try disabling QtWebEngine's hardware rendering in Sigil's preferences. If that makes a difference, it could be your video card/drivers. That would be a weird manifestation, but I've seen weirder.

[kevinhendricks]

I can not reproduce this on MacOS either, but MacOS uses non-native file dialogs.

[kevinhendricks]

Since this is a native FileDialog issue, perhaps this is related to a System or FileSystem OS extension installed by the user or computer manufacturer (typically these show file preview images) that is colliding with Qt somehow. Does the issue happen when the system is rebooted into Safe Mode?

[hayaku2]

Hey guys,

Just tested it on another Windows 10 PC that I have (Sigil 2.02) and same bug on that machine too.

I booted in safe mode, but the bug persists in safe mode as well.

A little more info:

Selecting the "Save as type" (and thus getting the blue select/white text highlight to shift) and then re-selecting the file name solves the issue, causing the cursor to re-appear, for that menu/pop-up instance.

Also discovered that in Safe Mode, preview window refuses to load, but still characteristically 'flashes' a second after new text is entered (it tries to refresh anyway). I noticed in safe mode that typing some text, then rapidly hitting Ctl+Shift+S before the preview 'refresh' can complete, causes the "File name" field to come up without being highlighted/selected in blue, an in this case (and this case only!) the cursor does appear.

I have thus concluded:

It has something to do with the blue highlight/white text feature of Windows, and that the "Preview" refresh may be involved.

Thanks for the help so far! Hopefully this narrows things down...

[hayaku2]

OK! ANOTHER UPDATE!

Bug does not happen when you click "Save As" from the menu. It has to be Hotkey-triggered, IE Ctl + Shift + S (Save As...) or Ctl + S (Save) for a new file that has not yet been saved/named.

I did a bit more bug testing...

Opening a brand new Sigil file, hitting Ctl + S, bug does not activate.

However, causing the preview pane to refresh even once, does activate the bug, on both Ctl + S (Save) as well as Ctl + Shift + S (Save As...).

Can somebody try to replicate this, using hotkeys and not menu?

[dougmassay]

@kevinhendricks : I suspect this is another case of QtWebEngine stealing focus, and keyboard hotkeys are not sufficient to take the focus back (like clicking the File menu does).

Can confirm the OP's behavior on Windows using keyboard shortcut. No similar behavior on Linux.

[kevinhendricks]

What worries me is that this is a Native Windows FileDialog with only a thin Qt veneer over it. This does not give us much room to play.

As Preview needs and uses Focus we can not assume a destination for last focus to return it to. So this would be an issue. Maybe delaying Save and Save as until the Preview Load is complete before invoking things might work. Just not sure.

[dougmassay]

That's only a guess on my part. The previous bug with QWebEngineView involves a second browser to view the images. So this could still be something different. But the fact that it only happens when using keyboard shortcuts (to the same functions) suggests a focus issue to me.

[kevinhendricks]

Agreed and found this:

https://stackoverflow.com/questions/36609489/how-to-prevent-qwebengineview-to-grab-focus-on-sethtml-and-load-calls

So we may be able to turn off the auto focus grab using the WebProfileMgr which sets the settings. We can try that approach and see what impacts it has.

https://github.com/Sigil-Ebook/Sigil/blob/master/src/Misc/WebProfileMgr.cpp

See the default Initial Settings where we currently enable Focus on Navigation to true. We can test what making this false does.

[kevinhendricks]

So when you get a free moment, please test that change on Windows.

I will be away from a computer for most of today but will test things out when I get back to look for side-effects.

[dougmassay]

Shift+Tab followed by Tab is enough to get things back to normal (highlighted file name with blinking cursor). Is it possible our focus/taborder changes have affected this on Windows only? I'll try building a previous Sigil version (with the same current Qt) and see if the behavior is any different.

[dougmassay]

We cross-posted. I'll test that setting. It could potentially remedy a lot of issues on Windows. There's a lot of double-clutching of Preview at various times. It actually has me wondering about my long-standing issue where dockwidgets that are tabbified with Preview mysteriously change the active tab from time to time.

[kevinhendricks]

It is not the focus on navigation enabled as later in the WebProfileMgr specific to Preview we already set that to false.

So it may be focus highlighting. But if it still happens in Sigil 2.0.2 as reported on the second Windows box, then it can't be that either.

I am stumped.