The browser doesn't need to store urls with 404 status in the history

Bug #1244335 reported by Adnane Belmadiaf
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
Medium
Riccardo Padovani
webbrowser-app (Ubuntu)
Fix Released
Medium
Riccardo Padovani

Bug Description

How to reproduce :
- Open "http://www.google.com/test" in the browser (this a 404 url)
- Click on the addressbar, type "test" this show you the url "http://www.google.com/test" from the history

Related branches

Adnane Belmadiaf (daker)
summary: - The browser needs to not store urls with 404 status in the history
+ The browser doesn't need to store urls with 404 status in the history
Olivier Tilloy (osomon)
Changed in webbrowser-app:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Olivier Tilloy (osomon) wrote :

In theory we should be able to filter out 404 URLs using the loadRequest.errorCode attribute in the onLoadingChanged handler (see http://qt-project.org/doc/qt-5.1/qtwebkit/qml-qtwebkit3-webview.html#onLoadingChanged-signal), however in practice the errorCode seems to always be 0.

Revision history for this message
Adnane Belmadiaf (daker) wrote :

I just tested that, yes it's always 0 so i think it's a bug

Revision history for this message
Olivier Tilloy (osomon) wrote :

Tested again with oxide, and for a 404 we’re getting an errorCode of 0. Not really sure what the error code is for, what we’d really need is a 'statusCode' property that contains the HTTP status code returned by the server.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Adding an oxide task: Chris, do you think the OxideQLoadEvent class could gain a statusCode property?

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Yeah, that would be fine

Changed in oxide:
importance: Undecided → Medium
milestone: none → branch-1.8
status: New → Triaged
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Note, "errorCode" is for errors that prevent us from getting a response and which cause the load to fail. A 404 is a valid response from the server, hence no error code :)

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

And LoadEvent.errorCode is a bit of a bogus API, as this is basically the error code from Chromium's network stack, which is fairly meaningless outside of Chromium. LoadEvent.errorDomain is better (although it will still indicate ErrorDomainNone for a 404)

Olivier Tilloy (osomon)
Changed in oxide:
assignee: nobody → Riccardo Padovani (rpadovani)
status: Triaged → In Progress
Changed in oxide:
status: In Progress → Fix Released
Changed in webbrowser-app:
status: Confirmed → In Progress
assignee: nobody → Riccardo Padovani (rpadovani)
Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
status: New → In Progress
assignee: nobody → Riccardo Padovani (rpadovani)
importance: Undecided → Medium
Changed in webbrowser-app:
assignee: Riccardo Padovani (rpadovani) → nobody
status: In Progress → Invalid
Olivier Tilloy (osomon)
no longer affects: webbrowser-app
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package webbrowser-app - 0.23+15.10.20150903.1-0ubuntu1

---------------
webbrowser-app (0.23+15.10.20150903.1-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.
  * Resync trunk.

  [ Michael Terry ]
  * Use the Ubuntu/Canonical search tag when searching with DuckDuckGo.
    (LP: #1490283)

  [ Olivier Tilloy ]
  * Display a friendly message when the renderer process crashes or is
    killed. This adds a runtime dependency for webbrowser-app-autopilot
    on python3-psutil. (LP: #1375272)
  * Do not display the bottom edge hint on tablets in wide mode. (LP:
    #1488995)
  * Update translation template.

  [ Riccardo Padovani ]
  * Don't store urls with status different from 2xx in the history. (LP:
    #1244335)
  * Don't store urls with status different from 2xx in the history. (LP:
    #1244335)

  [ Ugo Riboni ]
  * Allow choosing the bookmark folder when bookmarking a link from the
    context menu. Disable the bookmark option when the link is already
    bookmarked. Ensure the bookmark star state in the chrome is always
    consistent with the bookmarked state of the current webview URL.
    (LP: #1477314)
  * Properly reset focus when the current tab changes (including as a
    result of closing tabs). (LP: #1488470)

 -- CI Train Bot <email address hidden> Thu, 03 Sep 2015 09:46:35 +0000

Changed in webbrowser-app (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.