Oxide

Certificate errors in the browser are confusing

Bug #1504853 reported by Chris Coulson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
Medium
Chris Coulson
Oxide branch-1.12
webbrowser-app (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

When the browser displays a certificate error, it indicates the request URL that the error originated from. This is fine. However, if the navigation is content initiated then the addressbar will indicate the URL of the currently committed page (which will be different to the URL of the page causing the error, which is displayed in the error UI provided by the browser).

I have an idea to fix this by navigating the webview to a placeholder interstitial page whilst waiting for a response from the browser. This will update the addressbar, keep the navigation history consistent and also make the back button behave the same as Chrome.

See original description

Related branches

lp:~chrisccoulson/oxide/lp1504853
Chris Coulson: Pending requested
Diff: 2354 lines (+1100/-732)
22 files modified
qt/core/api/oxideqcertificateerror.cc (+3/-3)
qt/core/browser/oxide_qt_web_view.cc (+16/-9)
qt/core/browser/oxide_qt_web_view.h (+5/-1)
qt/tests/qmltests/ssl/tst_CertificateError.qml (+329/-217)
qt/tests/qmltests/ssl/tst_CertificateError_initial.html (+5/-0)
shared/browser/oxide_content_browser_client.cc (+21/-21)
shared/browser/oxide_web_frame_tree.cc (+6/-0)
shared/browser/oxide_web_view.cc (+28/-80)
shared/browser/oxide_web_view.h (+0/-26)
shared/browser/oxide_web_view_client.cc (+0/-2)
shared/browser/oxide_web_view_client.h (+0/-2)
shared/browser/oxide_web_view_contents_helper.cc (+7/-1)
shared/browser/ssl/oxide_certificate_error.cc (+50/-268)
shared/browser/ssl/oxide_certificate_error.h (+20/-100)
shared/browser/ssl/oxide_certificate_error_dispatcher.cc (+196/-0)
shared/browser/ssl/oxide_certificate_error_dispatcher.h (+77/-0)
shared/browser/ssl/oxide_certificate_error_dispatcher_client.h (+36/-0)
shared/browser/ssl/oxide_certificate_error_placeholder_page.cc (+58/-0)
shared/browser/ssl/oxide_certificate_error_placeholder_page.h (+64/-0)
shared/browser/ssl/oxide_certificate_error_proxy.cc (+105/-0)
shared/browser/ssl/oxide_certificate_error_proxy.h (+65/-0)
shared/shared.gyp (+9/-2)
lp:~oxide-developers/oxide/oxide.trunk
lp:~oxide-developers/oxide/packaging.trusty
lp:~oxide-developers/oxide/packaging.vivid
lp:~oxide-developers/oxide/packaging.wily
lp:~oxide-developers/oxide/packaging.xenial
lp:~oxide-developers/oxide/packaging.vivid.overlay
Chris Coulson (chrisccoulson)
Changed in oxide:
importance: Undecided → Medium
status: New → In Progress
assignee: nobody → Chris Coulson (chrisccoulson)
milestone: none → branch-1.11
description: updated
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

For non-overridable errors, this change will require webbrowser-app to explicitly destroy CertificateError once the error sheet is dismissed, in order to work correctly.

Olivier, that shouldn't be a problem, should it?

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

No, that shouldn’t be a problem.

Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Olivier Tilloy (osomon)
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Actually, a browser change might not be needed. For non-overridable errors, the browser doesn't present any buttons in the error UI which means that the only way to dismiss the error is hit the back button. This still works correctly with my proposed changes, because CertificateError.cancelled fires.

If the browser presented a dismiss button in the error UI (which I thought it did when I suggested we might need a browser change), then the browser would need to ensure the CertificateError is deleted so that Oxide removes the placeholder transient page that gets inserted. That doesn't appear to be the case though.

So far the browser is working fine with my changes

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

Having the back button behave the same whether the error is overridable or non-overridable makes the experience much better as well :)

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

That’s great, looking forward to this change!

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

I might shelve this for 1.11. There's a few issues with the way WebView and our RenderWidgetHostView implementation interact when InterstitialPage is used which requires some extra work to make this shippable. I've pushed the changes I have so far in my branch

Changed in oxide:
milestone: branch-1.11 → branch-1.12
Chris Coulson (chrisccoulson)
Changed in oxide:
status: In Progress → Fix Released
Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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