Consider the scenario

  1. user enters url "http://localhost:8000/"

     A new navigation entry is created and committed in the
     NavigationController.

  2. user enters url "http://localhost:8000/download.bin"

     A new navigation entry is created and a download is triggered, but the
     pending navigation entry in the NavigationController is neither committed
     nor discarded (since our WebContentsDelegate's ShouldPreserveAbortedURLs()
     returns true).

  3. user enters url "http://localhost:8000/download.bin"

     At this point the NavigationController will have "http://localhost:8000/"
     as the committed navigation entry and "http://localhost:8000/download.bin"
     as the pending entry. NavigateToPendingEntry will see that the user is
     trying to navigate again to the same URL as the last pending entry and will
     therefore identify this new navigation as a reload.

     However Blink interprets 'reload' to mean reloading the last committed
     entry, i.e. "http://localhost:8000/", and so we end up trying to download
     "http://localhost:8000/" instead of "http://localhost:8000/download.bin

" as
     the user might have expected.

The patch removes the ShouldPreserveAbortedURLs override and relies on the
default implementation which always returns false. As a result the pending
navigation entry in step 2 above is discarded once the download has been
triggered and the unexpected behavior in step 3 is no longer triggered.

Removing the override resurrects QTBUG-48995 where, for example, calling
QWebEnginePage::setUrl triggers first a urlChanged signal for the *old* URL. The
patch adds url and title properties to WebContentsDelegateQt so that property
change signals are triggered only if the properties have actually changed. A
consequence of this fix is that the first urlChanged signal is delivered
directly from the setUrl/load method and not asynchronously once the loading
starts (this is also how Chrome's URL bar is updated).

Task-number: QTBUG-63388
Change-Id: Icfa300b165e5e56f1fbc8978a00a237c263df183
Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>