This information is going to be especially useful in the upcoming Qt
WebEngine version of GoldenDict. In the Qt WebEngine version only the
words equal to the last found result can be highlighted, not all FTS
matches as in the Qt WebKit version.
The assertion failure can be triggered by full-text-searching for a
common word, selecting a result with many large articles and quickly
selecting text in the first article while the page is still loading.
This reverts commit c936d03fa0.
A default-constructed QRegExp is passed to ArticleView::showDefinition()
when a user navigates from an FTS-result page by clicking a link or
double-clicking a word. QRegExp().pattern() returns an empty string,
which is stored in the "regexp" query item of an URL. When this URL is
loaded, ArticleView::loadFinished() calls highlightFTSResults(), which
then calls closeSearch(), performs multiple string and regular
expression operations and early-returns because the regular expression
pattern is empty. Returning earlier skips useless work in this case.
An alternative optimization is not calling highlightFTSResults() at all
when the regular expression is empty, but that would skip the
closeSearch() call and keep the FTS search frame visible on a page with
an empty regexp.
One issue with the current implementation is that a wrong-cased match
remains selected when the user checks the Case Sensitive checkbox.
Another issue is that the noResults property of searchText is not
updated right away, which means that searchText's background color
remains wrong until next search.
Handle toggling case sensitivity in the same way as editing the searched
text: restart search from the beginning of the page. This improves the
Search-in-page UI consistency.
The current article is saved to pages history user data before any
navigation to another page and before reloading the current page.
Therefore saving it each time the user activates an article is
redundant. This redundancy is not consistent, because when a user
activates an article by clicking on it, the current article changes in
the UI, but is not immediately saved in history as setCurrentArticle()
is not called. The inconsistent redundancy is a waste of CPU time and
can hide bugs.
This variable overrides history user data, which makes the current
article and position restoring code in ArticleView::loadFinished()
difficult to understand.
Encode the same logic in the history user data instead. This should make
the code more straightforward and less brittle in the face of changes.
MainWindow calls ArticleView::reload() when the group list is updated.
This updating may add/remove/reorder dictionaries in the active group.
MainWindow also calls ArticleView::reload() when the display or addon
style changes.
In both of the above scenarios uncontrolled jumps and current article
change can occur (see also the parent commit message).
Move setting articleToJump from above the only ArticleView's reload()
call into ArticleView::reload() itself.
When the first article in the list is current, expanding or collapsing
optional parts results in:
1) uncontrolled jumps due to the content height changes if the scroll
position is not (0, 0);
2) current article change if a non-first article is saved in history
user data (e.g. if a mouse click had made the first article active).
Treat the first current article in the same way as non-first ones.
This change also affects the case when the current article is not
present in the article list. If the current article is simply empty,
then there is no behavior change. If the current article is not empty,
it *must* be in the list, unless something else went wrong.
This way it is clearer that the pages history is updated just before
each navigation to a different page.
The call to ArticleView::saveHistoryUserData() now occurs slightly later
in ArticleView::showDefinition(). I don't think the intervening code can
affect the current article or window position. So the reordering most
likely does not affect application behavior.
Without the added saveHistoryUserData() call, returning back from the
enlarged picture page ("gdpicture") restores the current article and the
window position that were last saved. At this commit the "gdpicture"
behavior is consistent with regular links: returning back from the
enlarged picture page sets the article with the picture as current and
restores the window position at the time of the click on the picture.
