[Bug?] Sigil's inconsistent behavior with italics and bold

[KevinH]

I just tried this on my Mac by typing "this is a line of text" in Bookview. highlighting just the word "of" and making it italic (I also tried superscript or subscript icons on later tests) and then immediately switching it back using the same button (still in BookView) and then switching to CodeView.

Is this right? If so, Mac OSX shows no problems at all with any of this.
So I can not be much help in tracking this down.

My guess is that it is in fact Qt code related and that we will need to change Qt versions to a newer version to get this fixed.

Has anyone tried Sigil on Linux with a very very recent of Qt 5.9.1 or Qt 5.8? Does it still crash on Linux with much newer Qt's.

My OS X build uses Qt 5.6.2 and it has no problems at least on the Mac side of things.

Originally Posted by DiapDealer

Thanks. I would have been highly surprised had it truly been a Windows-only issue.

P.S. And it's not "unfortunate" at all, really. You've done me a favor! Debugging it on Linux will be a breeze compared to trying to pry clues from Windows' uncooperative fingers.

The unfortunate part is that there's no guarantee we can even address the issue (provided debugging proves successful) if it's deep inside one of those Qt widget functions. How much do you want to bet that the problem goes away if we reverted back to the "tag mode" option -- which of course generates invalid tags?

[Doitsu]

Originally Posted by KevinH

I just tried this on my Mac by typing "this is a line of text" in Bookview. highlighting just the word "of" and making it italic (I also tried superscript or subscript icons on later tests) and then immediately switching it back using the same button (still in BookView) and then switching to CodeView.

On my Linux machine, the problem didn't occur with all books and also not always with the same book. Try the following:

1. Close Sigil then download and open this MR epub.
2. Click Yes when asked if you want to fix the files.
3. Click the Book View icon.
4. Select 02_pof-03-prol.xhtml.
5. Double-click "history," click the Italic button twice and then the Code View button.

If this doesn't crash Sigl, switch to Book View and repeat the last step. Usually this triggers the crash.

[DiapDealer]

Originally Posted by KevinH

Has anyone tried Sigil on Linux with a very very recent of Qt 5.9.1 or Qt 5.8?

I've not tried it yet, but my Linux Sigil at home is using Qt 5.11.x

[DiapDealer]

Originally Posted by Doitsu

On my Linux machine, the problem didn't occur with all books and also not always with the same book. Try the following:

1. Close Sigil then download and open this MR epub.
2. Click Yes when asked if you want to fix the files.
3. Click the Book View icon.
4. Select 02_pof-03-prol.xhtml.
5. Double-click "history," click the Italic button twice and then the Code View button.

If this doesn't crash Sigl, switch to Book View and repeat the last step. Usually this triggers the crash.

Weird. On Windows, I can't get it to crash when styling/unstyling the word "history" no matter how many times I go back to Book View and repeat the last step. But I can highlight just about any other word in that paragraph and get it to crash right away.

[KevinH]

That did the trick for me!

Here is the backtrace - it does not appear to be a Qt bug at all. When you switch to CodeView, Sigil uses javascript to get the location in the DOM hierarchy of the current cursor in BookView (much like a epubcfi and similar in that is is a node count from the body tag) so that in CodeView, we can put the cursor near where it was in BookView. This happens in all transitions from CodeView to BookView and BookView to CodeView.

Whatever we are doing is causing a very very strange or borken hierachy to be produced from the javascript in BookView that is making CodeView barf when it tries to place the cursor there.

The backtrace:

Process:               Sigil [619]
Path:                  /Applications/Sigil.app/Contents/MacOS/Sigil
Identifier:            com.sigil-ebook.Sigil.app
Version:               0.9.9 (0.9.9)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Sigil [619]
User ID:               501

Date/Time:             2018-06-08 13:24:06.358 -0400
OS Version:            Mac OS X 10.13.5 (17F77)
Report Version:        12
Anonymous UUID:        33AB802F-5FDD-DD5B-7A74-A04E3340B88C


Time Awake Since Boot: 230 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.sigil-ebook.Sigil.app     	0x000000010cccd0db CodeViewEditor::ConvertHierarchyToCaretMove(QList<ViewEditor::ElementIndex> const&) const + 235
1   com.sigil-ebook.Sigil.app     	0x000000010cccd39f CodeViewEditor::ExecuteCaretUpdate(bool) + 143
2   com.sigil-ebook.Sigil.app     	0x000000010c9e4f22 FlowTab::CodeView() + 242
3   com.sigil-ebook.Sigil.app     	0x000000010c9e51ed FlowTab::SetViewState(MainWindow::ViewState) + 141
4   com.sigil-ebook.Sigil.app     	0x000000010cd14705 MainWindow::UpdateViewState(bool) + 149
5   com.sigil-ebook.Sigil.app     	0x000000010cd12b85 MainWindow::CodeView() + 37
6   org.qt-project.QtCore         	0x00000001109ebb4c QMetaObject::activate(QObject*, int, int, void**) + 3020
7   org.qt-project.QtWidgets      	0x000000010d43f3d7 QAction::activate(QAction::ActionEvent) + 263
8   org.qt-project.QtWidgets      	0x000000010d536d29 0x10d437000 + 1047849
9   org.qt-project.QtWidgets      	0x000000010d537dd0 QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 272
10  org.qt-project.QtWidgets      	0x000000010d61219f QToolButton::mouseReleaseEvent(QMouseEvent*) + 15
11  org.qt-project.QtWidgets      	0x000000010d48a5d3 QWidget::event(QEvent*) + 1571
12  org.qt-project.QtWidgets      	0x000000010d537b20 QAbstractButton::event(QEvent*) + 160
13  org.qt-project.QtWidgets      	0x000000010d6127c5 QToolButton::event(QEvent*) + 325
14  org.qt-project.QtWidgets      	0x000000010d448a76 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 294
15  org.qt-project.QtWidgets      	0x000000010d44be73 QApplication::notify(QObject*, QEvent*) + 8339
16  org.qt-project.QtCore         	0x00000001109b5ce4 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 164
17  org.qt-project.QtWidgets      	0x000000010d44942a QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) + 970
18  org.qt-project.QtWidgets      	0x000000010d4ac852 0x10d437000 + 481362
19  org.qt-project.QtWidgets      	0x000000010d4ab82e 0x10d437000 + 477230
20  org.qt-project.QtWidgets      	0x000000010d448a76 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 294
21  org.qt-project.QtWidgets      	0x000000010d449fd8 QApplication::notify(QObject*, QEvent*) + 504
22  org.qt-project.QtCore         	0x00000001109b5ce4 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 164
23  org.qt-project.QtGui          	0x00000001101ff90d QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) + 2877
24  org.qt-project.QtGui          	0x00000001101e7a1b QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 203
25  libqcocoa.dylib               	0x000000011311bb51 0x1130f8000 + 146257
26  com.apple.CoreFoundation      	0x00007fff3fb21a61 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
27  com.apple.CoreFoundation      	0x00007fff3fbdb47c __CFRunLoopDoSource0 + 108
28  com.apple.CoreFoundation      	0x00007fff3fb044c0 __CFRunLoopDoSources0 + 208
29  com.apple.CoreFoundation      	0x00007fff3fb0393d __CFRunLoopRun + 1293
30  com.apple.CoreFoundation      	0x00007fff3fb031a3 CFRunLoopRunSpecific + 483
31  com.apple.HIToolbox           	0x00007fff3ede9d96 RunCurrentEventLoopInMode + 286
32  com.apple.HIToolbox           	0x00007fff3ede9a0f ReceiveNextEventCommon + 366
33  com.apple.HIToolbox           	0x00007fff3ede9884 _BlockUntilNextEventMatchingListInModeWithFilter + 64
34  com.apple.AppKit              	0x00007fff3d09ba73 _DPSNextEvent + 2085
35  com.apple.AppKit              	0x00007fff3d831e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
36  com.apple.AppKit              	0x00007fff3d090885 -[NSApplication run] + 764
37  libqcocoa.dylib               	0x000000011311aa5f 0x1130f8000 + 141919
38  org.qt-project.QtCore         	0x00000001109b1ea1 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 417
39  org.qt-project.QtCore         	0x00000001109b6355 QCoreApplication::exec() + 341
40  com.sigil-ebook.Sigil.app     	0x000000010c9dd257 main + 5735
41  libdyld.dylib                 	0x00007fff6790d015 start + 1

So I will take a closer look at just what hierarchy is being fetched from inside of Bookview to see wherre it is telling CodeView to go.

Originally Posted by Doitsu

On my Linux machine, the problem didn't occur with all books and also not always with the same book. Try the following:

1. Close Sigil then download and open this MR epub.
2. Click Yes when asked if you want to fix the files.
3. Click the Book View icon.
4. Select 02_pof-03-prol.xhtml.
5. Double-click "history," click the Italic button twice and then the Code View button.

If this doesn't crash Sigl, switch to Book View and repeat the last step. Usually this triggers the crash.

[DiapDealer]

Originally Posted by KevinH

Whatever we are doing is causing a very very strange or borken hierachy to be produced from the javascript in BookView that is making CodeView barf when it tries to place the cursor there.

See? I just knew the word "cursor" would be involved somewhere!

[KevinH]

Okay the underlying cause of the problem is gumbo does not build DOM trees the way that Qt builds DOM trees when it comes to where text nodes are inserted. It seems Qt's tree assumes there is a text node made up of a null string between the p tag and its first child the span tag. But in this case gumbo does not create the same null string text node and thinks that the span tag is the first child of the p tag and that the next node is the text tag we are playing with.

So sometimes by playing around with text nodes the offset is the same between Qt's Dom and Gumbo's node tree and sometimes it is not.

The fix is not easy as it is hard to say how when this issue will arrive. It arrives here because of the span tag having no text separation from its parent p tag.

I will have to think about this some more.

[KevinH]

And to make matters worse, turning on italic and then off in BookView (or any other styling) will randomly cause the inclusion or removal of these implicit null string nodes in the webpath.

Here is an example webpath from Qt for the word "history":

Debug: webpath: "html 1,body 1,p 1,#text -1"

Adding one to the counts following each piece will tell you which child to use when only counting preceding siblings that are element nodes (not text nodes).

If you then play around with italics on that word and switch back (even though the cursor is still on the word "history", you get this path instead:

webpath: "html 1,body 1,p 2,#text -1"

And there are only two children in total of that particular p tag so that makes no sense.

This is all caused by live editing in BookView inserting and removing strange nodes in the tree that makes converting the BookView Dom location back to a CodeView DOM location quite hard.

Argh! I really am beginning to really hate BookView!

[KevinH]

BTW, in case anyone is interested the BookView webpath is generated by this file written in Javascript in Sigil tree:

book_view_current_location.js

And the problem is that JQuery's function to check where the text node is in its parents contents:

...
return first_part + jQuery.inArray( this, $( this ).parent().contents() );

varies depending on whether you have styled and unstyled that node or not in BookView.

So when live DOM editing is done in BookView the tree is getting nodes added and removed that are not really there once you dump out the xhtml from the webkit widget so it returns the wrong index of the text node in its parent.

This causes our cursor position to be wrong and sometimes even return something from out in the weeds which causes the segfault/crash.

There is no real way for me to detect what is going on inside BookView's DOM tree in webkit when live editing is done and how that edited DOM tree is then serialized back to text.

All I can do is guess.

So I would really stay away from doing any editing in BookView at all, at least until I can figure out some sane way to get consistent results from the DOM tree to locate the cursor.

[DNSB]

Originally Posted by KevinH

Argh! I really am beginning to really hate BookView!

Only beginning? I thought you and BookView had a long standing hate/hate affair.

[kovidgoyal]

@KevinH: You need to normalize() before calculating the path. https://developer.mozilla.org/en-US/...Node/normalize

[un_pogaz]

Originally Posted by theducks

It really is not recommended to make edits in Bookview.

FWIW I use Preview (on a second monitor) to visually review the look and sync up the code to the block with the focus in the preview.
All edits are done in code view

The only time I use BV, is when there is a pink, error box showing that I can't spot the issue. Attempting to switch, gives you the option to MANUALLY fix the code, AND that usually takes you to the problem

And when you don't have a second monitor? What do we do? [Troll=OFF]
(and the magic alt+TAB doesn't work)

In ohter words: "Book display" is only a slightly interactive preview, certainly not complete, nor optimized.
Okay
Too bad, it would have been cool and practical, but from what I've read, it doesn't seem possible.

Thank for the answer

[Turtle91]

Originally Posted by un_pogaz

And when you don't have a second monitor?

You can dock the Pre View pane to the main window. That way you always have a view showing how it looks and a view for editing. If you are lucky enough to have a 2nd monitor you can undock the PV pane and move it to free up landscape for Code View.

The only benefit of Book View, that I've heard, is that you can 1) click on links, and 2) you can paste raw text from other sources and BV will give it some basic <tags>. IIRC, enabling those two functions within CV or the PV pane would be the final step before removing BV from Sigil entirely.

Most of us rarely, if ever, use BV because of all the issues and risks to your code. CV/PV cover 99.9% of all your needs. There has been much wailing and gnashing of teeth over the last few years about all the problems caused when someone (mis)uses BV.

[BetterRed]

Originally Posted by Turtle91

You can dock the Pre View pane to the main window. That way you always have a view showing how it looks and a view for editing.

QED:



As well as clickable links in PV, I'd like a simple Find a'la Notepad.

BR

[DiapDealer]

Clickable Preview links have already been added. https://github.com/Sigil-Ebook/Sigil...6f3a402c364fa6