It's not exactly a 404, it is just that WebView's LoadFailedStatus is set because the first loading was interrupted by the second. Although I agree that if the second url is the same as the first it should be smarter and do nothing instead of complaining.

We can close this if this is what is expected. Hey Simon, what do you think?

I was thinking that if the user interrupted the first page load caused by attributing something to webView.url, and then setting again webView.url with the same or other address, the first page load should not be considered a failure, because the user did this on purpose. In other words, doing: webView.url = "www.one.com" webView.url = "www.one.com" should be semantically equivalent to: webView.load("www.one.com") webView.reload() and webView.load("www.one.com") webView.stop() webView.load("www.two.com") for when the addresses are different. It should not issue an error in both cases, because the first page was expected to stop loading.

(In reply to comment #2) > We can close this if this is what is expected. Hey Simon, what do you think? Perhaps I misunderstood this, but IMHO conceptually calling view->setUrl(view->url()) should be a noop and not cause any errors. In other words: setting a property to the value that's already set should not do anything. Does that make sense?

(In reply to comment #4) > (In reply to comment #2) > > We can close this if this is what is expected. Hey Simon, what do you think? > > Perhaps I misunderstood this, but IMHO conceptually calling > > view->setUrl(view->url()) > > should be a noop and not cause any errors. In other words: setting a property to the value that's already set should not do anything. > > Does that make sense? That makes perfect sense. I believe when user really wants to trigger a reload, then he should use the reload function, instead of view.url = view.url. I didn't look at the code, but the problem might lie around the fact that the current url value of a web view is not the url that is being loaded, but the last url completely loaded, right Marcelo?

(In reply to comment #5) > [...] I believe when user really wants to trigger a reload, then he should use the reload function, instead of view.url = view.url. Exactly!

(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > We can close this if this is what is expected. Hey Simon, what do you think? > > > > Perhaps I misunderstood this, but IMHO conceptually calling > > > > view->setUrl(view->url()) > > > > should be a noop and not cause any errors. In other words: setting a property to the value that's already set should not do anything. > > > > Does that make sense? > > That makes perfect sense. I believe when user really wants to trigger a reload, then he should use the reload function, instead of view.url = view.url. > > I didn't look at the code, but the problem might lie around the fact that the current url value of a web view is not the url that is being loaded, but the last url completely loaded, right Marcelo? (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > We can close this if this is what is expected. Hey Simon, what do you think? > > > > Perhaps I misunderstood this, but IMHO conceptually calling > > > > view->setUrl(view->url()) > > > > should be a noop and not cause any errors. In other words: setting a property to the value that's already set should not do anything. > > > > Does that make sense? > > That makes perfect sense. I believe when user really wants to trigger a reload, then he should use the reload function, instead of view.url = view.url. > > I didn't look at the code, but the problem might lie around the fact that the current url value of a web view is not the url that is being loaded, but the last url completely loaded, right Marcelo? Yes, QQuickWebView::url() returns the url from webPageProxy->mainFrame(), but the frame may not be ready when WebView.url is called, so in QML it will result in an empty string.

(In reply to comment #6) > (In reply to comment #5) > > [...] I believe when user really wants to trigger a reload, then he should use the reload function, instead of view.url = view.url. > > Exactly! I agree that the nop is the behavior that makes sense. In any case, the problem remains that there will be times when QQuickWebView will not know which url it is loading, because it calls webPageProxy->loadURL(url) and it has to wait for the readying of the frame before being able to ask the url again. (I mean, it may ask I think the solution to this is to store the url also in the QQuickWebView (and update it when there are redirections, etc) so that we may compare it to new requests, and also always answer when QQuickWebView::url() is called.

(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #5) > > > [...] I believe when user really wants to trigger a reload, then he should use the reload function, instead of view.url = view.url. > > > > Exactly! > I agree that the nop is the behavior that makes sense. > In any case, the problem remains that there will be times when QQuickWebView will not know which url it is loading, because it calls webPageProxy->loadURL(url) and it has to wait for the readying of the frame before being able to ask the url again. (I mean, it may ask > I think the solution to this is to store the url also in the QQuickWebView (and update it when there are redirections, etc) so that we may compare it to new requests, and also always answer when QQuickWebView::url() is called. From the point of view of my last comment, this one is related to bug 77554.

(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > [...] I believe when user really wants to trigger a reload, then he should use the reload function, instead of view.url = view.url. > > > > > > Exactly! > > I agree that the nop is the behavior that makes sense. > > In any case, the problem remains that there will be times when QQuickWebView will not know which url it is loading, because it calls webPageProxy->loadURL(url) and it has to wait for the readying of the frame before being able to ask the url again. (I mean, it may ask > > I think the solution to this is to store the url also in the QQuickWebView (and update it when there are redirections, etc) so that we may compare it to new requests, and also always answer when QQuickWebView::url() is called. > > From the point of view of my last comment, this one is related to bug 77554. Indeed, and now that 77554 is fixed, how do we move forward with this issue? Is setUrl just missing the url == m_currentUrl shortcut?

Created attachment 165811 [details] Patch

Comment on attachment 165811 [details] Patch I think we need to keep the current behaviour. Loading the same url again, and reloading, are not the same. For example, reloading will restore the viewport position.

(In reply to comment #12) > (From update of attachment 165811 [details]) > I think we need to keep the current behaviour. Loading the same url again, and reloading, are not the same. For example, reloading will restore the viewport position. Okay, true :). Should we close this bug then?

(In reply to comment #12) > (From update of attachment 165811 [details]) > I think we need to keep the current behaviour. Loading the same url again, and reloading, are not the same. For example, reloading will restore the viewport position. What is the current behavior? Do we still get an error when we pass the same url again?

(In reply to comment #14) > (In reply to comment #12) > > (From update of attachment 165811 [details] [details]) > > I think we need to keep the current behaviour. Loading the same url again, and reloading, are not the same. For example, reloading will restore the viewport position. > > What is the current behavior? Do we still get an error when we pass the same url again? As discussed on irc, passing the same url again does not trigger an error, but basically results in a NOP. Closing this now, please holler if you believe it should be left open.