MobileRead Forums - View Single Post

KevinH · 01-23-2016, 11:40 AM

Okay, I can now recreate this in a new way that really tells me this is a bug in Qt.

1. open firefox or any browser to any page
2. xsel -bc
3. sigil
4. Play with text highlighting in default file 1 - it is fast
5. Click on your browser window and select some text (any text) and copy it to the clipboard, then return to sigil
6. Now try highlighting text again in Sigil it will be slow
7. highlight a small piece of text in Sigil and copy it to the clipbord
8. Now try highlighting text again in Sigil and it will be fast again

So the mere presence of any data not from Sigil in the clipboard will freak things out.

I searched and found this bug:

https://bugreports.qt.io/browse/QTBUG-38585

Which reports a problem with sleeping too much in clipboardWaitForEvent in qclipboard_x11.cpp causing slowdowns and delays.

There was a patch supplied but of course Qt ignored it and then someone at Qt claimed the file qclipboard_x11.cpp no longer exists so they abandoned the patch completely.

Of course, during the interval of qclipboard_x11.cpp was removed and replaced by qxcbclipboard.cpp and it has the exact same issue. Any time it wants to communicate with an outside app (another app that owns the current clipboard contents) it sits in a wait loop for 50000 us or 50 ms. Since highlighting text in X11 is a clipboard activity, as long as anything foreign is in the clipboard, it will sit and sleep many many times here while we are trying to highlight something waiting to talk to the owner of the current clipboard contents.

This problem does not exist in Windows or Mac because the system clipboard is global and there is no such thing as owners of clipboard contents, and because simple selection (highlighting text) is not a clipboard activity on Mac and Windows.

My guess is Qt will never fix it given how they ignored the problem and the patch offered and then abandoned it when they moved to qxcbclipboard.cpp which almost always uses the event loop approach. Sigil has about 3 or 4 other bug reports at Qt for years now that have never seen any action. One includes a use after free that could be used to attack the application. I have no hopes of anyone at Qt even looking at this issue at all, let alone fixing it.

So the question is how can we work around it on Linux? Given simply copying anything to the clipboard inside Sigil will prevent the issue (replacing the foreign ownership) there should be something Sigil can do. I am thinking of having Sigil check for ownership of the item on the clipboard and if necessary copying it and then pasting it back as its new owner. This should be doable.

Anyone have any pull with Qt about bug fixes for Linux that could get them to at least fix this, would be nice.

KevinH

01-23-2016, 11:40 AM	#54
KevinH Sigil Developer Posts: 8,918 Karma: 6240958 Join Date: Nov 2009 Device: many	Okay, I can now recreate this in a new way that really tells me this is a bug in Qt. 1. open firefox or any browser to any page 2. xsel -bc 3. sigil 4. Play with text highlighting in default file 1 - it is fast 5. Click on your browser window and select some text (any text) and copy it to the clipboard, then return to sigil 6. Now try highlighting text again in Sigil it will be slow 7. highlight a small piece of text in Sigil and copy it to the clipbord 8. Now try highlighting text again in Sigil and it will be fast again So the mere presence of any data not from Sigil in the clipboard will freak things out. I searched and found this bug: https://bugreports.qt.io/browse/QTBUG-38585 Which reports a problem with sleeping too much in clipboardWaitForEvent in qclipboard_x11.cpp causing slowdowns and delays. There was a patch supplied but of course Qt ignored it and then someone at Qt claimed the file qclipboard_x11.cpp no longer exists so they abandoned the patch completely. Of course, during the interval of qclipboard_x11.cpp was removed and replaced by qxcbclipboard.cpp and it has the exact same issue. Any time it wants to communicate with an outside app (another app that owns the current clipboard contents) it sits in a wait loop for 50000 us or 50 ms. Since highlighting text in X11 is a clipboard activity, as long as anything foreign is in the clipboard, it will sit and sleep many many times here while we are trying to highlight something waiting to talk to the owner of the current clipboard contents. This problem does not exist in Windows or Mac because the system clipboard is global and there is no such thing as owners of clipboard contents, and because simple selection (highlighting text) is not a clipboard activity on Mac and Windows. My guess is Qt will never fix it given how they ignored the problem and the patch offered and then abandoned it when they moved to qxcbclipboard.cpp which almost always uses the event loop approach. Sigil has about 3 or 4 other bug reports at Qt for years now that have never seen any action. One includes a use after free that could be used to attack the application. I have no hopes of anyone at Qt even looking at this issue at all, let alone fixing it. So the question is how can we work around it on Linux? Given simply copying anything to the clipboard inside Sigil will prevent the issue (replacing the foreign ownership) there should be something Sigil can do. I am thinking of having Sigil check for ownership of the item on the clipboard and if necessary copying it and then pasting it back as its new owner. This should be doable. Anyone have any pull with Qt about bug fixes for Linux that could get them to at least fix this, would be nice. KevinH Last edited by KevinH; 01-23-2016 at 01:09 PM.