The mouseover of links in HTML-Mails shows the destination of that link. This is quite usefull to identify phishing/scam mails. The timeout for that mouseover happens to be so short that it is impossible to read it. Reproducible: Always Actual Results: Mouseover disappears almost immediately. Expected Results: Mouseover stays visible for multiple seconds or until the mouse is moved away from the link.
Something™ triggers an event that makes qtooltip feel required to hide. Next event cycle is by far not sufficient, so hacko mui uglydo would be: diff --git a/src/Gui/Window.cpp b/src/Gui/Window.cpp index 93ecc8d..25f85a7 100644 --- a/src/Gui/Window.cpp +++ b/src/Gui/Window.cpp @@ -740,7 +740,8 @@ void MainWindow::createWidgets() if (url.isEmpty()) { QToolTip::hideText(); } else { - QToolTip::showText(QCursor::pos(), tr("Link target: %1").arg(UiUtils::Formatting::htmlEscaped(url))); + QTimer::singleShot(250, [=]() { + QToolTip::showText(QCursor::pos(), tr("Link target: %1").arg(UiUtils::Formatting::htmlEscaped(url))); }); } }); connect(m_messageWidget->messageView, &MessageView::transferError, this, &MainWindow::slotDownloadTransferError) But this is a "bug" in QToolTip or QWebPage/View or in Qt's event handling (ie. Qt5 is in poor shape anyway and getting worse in every update) No, it's afaics not the hideText() call ;-)
> hacko mui uglydo This is going into the commit message verbatim :) > But this is a "bug" in QToolTip or QWebPage/View or in Qt's > event handling Seems to to be due to qtwebkit's d441d6f3 (Qt 5.2.0-alpha1+): 1717 page->chrome().mouseDidMoveOverElement(hoveredNode, event.modifierFlags()); 1718 page->chrome().setToolTip(hoveredNode); IOW, the link mouseover is called prior to webkit's own tooltip handling. > (ie. Qt5 is in poor shape anyway and getting worse in every update) Ceterum censeo Carthaginem esse delendam.
Git commit 27bae663dae466c088d5c66dabf89894605be068 by Jan Kundrát, on behalf of Thomas Lübking. Committed on 02/06/2016 at 12:53. Pushed by gerrit into branch 'master'. Fix tooltips in QtWebKit Something™ triggers an event that makes qtooltip feel required to hide. Next event cycle is by far not sufficient, so hacko mui uglydo would be this thing. But this is a "bug" in QToolTip or QWebPage/View or in Qt's event handling (ie. Qt5 is in poor shape anyway and getting worse in every update) No, it's afaics not the hideText() call ;-) jkt: It's actually caused by WebKit trying to handle the popups internally and by an unfortunate order in which these events are fired. This only works on Qt 5.4+ because that's when qtbase got its commit e2df05f120ea76f7fb777926f5c00163dba4a92b. In other words, the bug remains unfixed for Qt 5.2 and 5.3. I can live with that. Change-Id: I03373a86695a8813cef70a964a2168e78a311368 M +6 -1 src/Gui/Window.cpp http://commits.kde.org/trojita/27bae663dae466c088d5c66dabf89894605be068