"Non-overridable certificate error" but page is stuck at 0%

[lufte]

I have sporadically seen this issue where I open a new tab and it gets stuck at 0%. If I go check the logs I see ERROR: Non-overridable certificate error: Server's certificate has expired., but without seeing the logs I have no clue of what's going on.

I cannot reproduce the issue with --temp-basedir nor even by opening the url in a private tab. I have also tried to reproduce it with https://expired.badssl.com/ or with a self signed certificate and a local server, but with no success. Sadly, the site which last caused this issue has been fixed now.

Any clue on how to reproduce or when is a certificate error "non-overridable"?

[The-Compiler]

An error is non-overridable when the website uses HTTP Strict Transport Security (and a response which such a header has been received at some earlier point).

I can reproduce this (even with --temp-basedir) by going to https://projects.dm.id.lv/Public-Key-Pins_test and opening the "No User Recourse test page" from there.

Looks like WebEngineTab._on_ssl_errors should be changed to always display an error page manually in case of a non-overridable error. Do you want to take a look?

[lufte]

An error is non-overridable when the website uses HTTP Strict Transport Security (and a response which such a header has been received at some earlier point).

Ah, that makes sense. That's why I was able to "fix it" by opening the URL in a private tab or using --temp-basedir.

Do you want to take a look?

Sure!

[lufte]

You wrote the next comment in _on_ssl_errors:

        # WORKAROUND for https://bugreports.qt.io/browse/QTBUG-56207
        # We can't really know when to show an error page, as the error might
        # have happened when loading some resource.
        # However, self.url() is not available yet and the requested URL
        # might not match the URL we get from the error - so we just apply a
        # heuristic here.

Yet I'm running Qt 5.11.3 and I still see a blank page if I ignore the error. For example by going to https://expired.badssl.com and choosing "No" when asked to continue. I removed the not qtutils.version_check('5.9') check for now.

As for getting the right URL, I thought of saving the last requested URL in AbstractTab._on_navigation_request and use that one for comparing against error.url(). I made a test in #5085 and it seems to work for this scenario.

[lufte]

Yet I'm running Qt 5.11.3 and I still see a blank page if I ignore the error. For example by going to https://expired.badssl.com and choosing "No" when asked to continue.

Actually this is not entirely true 🤔. My main qutebrowser install shows the error page, but it stops showing it with --temp-basedir... something else is going on here.

[The-Compiler]

Odd. I get an error page with Qt 5.11.2 (can't test .3 easily at the moment) and --temp-basedir.

[The-Compiler]

Looks like Qt also has a fix for this in Qt 5.13.2 and 5.12.6: https://codereview.qt-project.org/c/qt/qtwebengine/+/270556

Did you ever find out why you don't get the error page for the common (overridable error) case? Are you on Debian by any chance?

[lufte]

Looks like Qt also has a fix for this in Qt 5.13.2 and 5.12.6: https://codereview.qt-project.org/c/qt/qtwebengine/+/270556

I'm confused as to whether this solves my issue or not. I understand that the progress will not be stuck at 0% anymore, but I'm not sure the error page will show.

Did you ever find out why you don't get the error page for the common (overridable error) case? Are you on Debian by any chance?

I am in Debian indeed, is there a known problem related to this? What I was able to find out is that I get the error page only with content.javascript.enabled = false (that's why it was working ok with my main install but not with --temp-basedir).
I have created two logs by running qutebrowser --temp-basedir at 7eee698: the first one I visit expired.badssl.com and reply "No" to the prompt. The second one is the same but I disable javascript before opening the page. I only see the error page on the second test.

1. https://paste.the-compiler.org/view/0af7f3e8
2. https://paste.the-compiler.org/view/057ce474

[The-Compiler]

There are actually various issues at play here.

• Debian's packaging messes up error pages, see Debian Bug #882805. I just looked at it again and I think I found the issue, but I want to confirm it with the Debian qutebrowser maintainer first. This explains why you saw something different from what I saw.
• Chromium's error pages require JavaScript to show. If there's an error page shown with JS disabled, qutebrowser gets the error code from it and replaces it by its own error page (in WebEngineTab._error_page_workaround). This explains why you saw different behavior with --temp-basedir.
• Qt before 5.9 did never show error pages for certificate errors (QTBUG-56207), thus the workaround you quoted above.
• Qt before 5.13.2/5.12.6 doesn't show error pages for non-overridable certificate errors (see the change I linked above). I can confirm these are shown correctly with Qt 5.13.2 without any changes to qutebrowser.

[The-Compiler]

FWIW I just found and pushed a workaround for the Debian bug.

[lufte]

FWIW I just found and pushed a workaround for the Debian bug.

Great! I just tested it and it works. Thanks!

Qt before 5.9 did never show error pages for certificate errors (QTBUG-56207), thus the workaround you quoted above.
Qt before 5.13.2/5.12.6 doesn't show error pages for non-overridable certificate errors (see the change I linked above). I can confirm these are shown correctly with Qt 5.13.2 without any changes to qutebrowser.

Okay, so the version check I removed in #5085 is actually right and my testing was broken because of Debian; so I agree that change is not valid. I will add an extra check for versions prior to 5.13.2/5.12.6 and show the custom error page for non-overridable certificate errors on those cases.

[The-Compiler]

I (accidentally) merged #5085, but at least for the test page, it doesn't work for reasons outlined in #5085 (comment) - @lufte do you know if it works for the cases where you've seen this issue before?