clicks a link to target A (an image or a real url)
keys ctl-b (viewer properly goes back to loaded text)
clicks a link to target B (another image or url)
keys ctl-b
viewer goes back to target A. User must key ctl-b a second time to get back to original. This continues: link to C, back to A. Link to D, back to A. It also persists over a Refresh which calls history.clear(). Once that item A has gotten into the QWebHistory list there's no getting it out.
I speculate this is a bug in QWebPage/QWebHistory triggered by the fact that we always start, not with setUrl, but with setHtml. I speculate that if we did setUrl, that would initialize the QWebHistory with the first URL, but that doing setHtml does not put anything in the history.
Rather than filing a bug, I think just take history.currentItemIndex()<= 1 as a sign that there is no history -- instead of testing history.canGoBack().
In both the PVW pane and the Help, if the user:
viewer goes back to target A. User must key ctl-b a second time to get back to original. This continues: link to C, back to A. Link to D, back to A. It also persists over a Refresh which calls
history.clear(). Once that item A has gotten into the QWebHistory list there's no getting it out.I speculate this is a bug in QWebPage/QWebHistory triggered by the fact that we always start, not with setUrl, but with setHtml. I speculate that if we did setUrl, that would initialize the QWebHistory with the first URL, but that doing setHtml does not put anything in the history.
Rather than filing a bug, I think just take history.currentItemIndex()<= 1 as a sign that there is no history -- instead of testing history.canGoBack().