Secure Connection Failed / Advanced / Accept the Risk and Continue : broken in 80.1.2

[smithi7]

An old site that I remotely maintain requires that this override works. It was still working with the first of the new Firefox Android here, 79.0.4 and 79.0.5, leading to the login/password page (though no auto-fill), but on 80.1.2 tapping or holding the 'Accept the Risk and Continue' button does nothing, not even highlighting the button. Currently having to use Samsung Internet browser to maintain the site in question.

┆Issue is synchronized with this Jira Task

[smithi7]

PS just in case, I turned off 'HTTPS Everywhere' addon, both for that site and generally, but no difference. I also tried both hostname and IP address for the site, just to rule out DNS. It seems that button has been disabled.

[clientenq]

I can confirm the secure connection failed accept risk and continue is broken.
When accepting it throws the user back to the previous visited url, if any.
Steps to reproduce:
0. Disable https everywhere and other addons

1. Open tab
2. Visit https test site https://badssl.com/
3. Follow any certificate test url, eg expired
4. Secure connection failed warning is displayed
5. Select "advanced" option
6. Select "accept risk and continue" option
7. Review faulty browser result not behaving like risk was accepted by user.

Actual result:
Browser ignores user selected option and displays previous url or about:blank

Expected result:
Browser follows user selected choice and displays requested resource.

Firefox daily 80.1.2
Firefix nightly 200906 06:01 (Build #2015762291)

It may be related to auto scroll functionality when selecting the lowest button. Seems like page is scrolling when selecting the button. This may result in actually triggering the "go back" button just above accept risk button. It is similar behaviour.
Other behaviour when trying workaround: button is selected (rectangle displayed around accept risk button) but no action triggered to accept risk.

Workaround:
Tilt screen to horizontal display just before selecting accept risk.

[smithi7]

Thanks clientenq for the badssl.com link, and your thorough checkout.

Mostly similar, but on my own bad link even the 'go back' button does nothing (though it is what I'll call highlit, with rectangle around) but on badssl.com it does indeed return to homepage.

Even with workaround I get nothing, nor highlight, on 'accept risk'. For me it's impossible to tell if the click is being detected and ignored, or not detected. I just know it worked on 79, leading to login user/password and then successful connection.

[jawz101]

I cannot log into my firewall webpage. The error page scrolls back up every time I try to click the "accept the risk" button

[jawz101]

This is a duplicate issue

[cadeyrn]

This is a duplicate issue

If you think it's a duplicate please mention the other issue. Thanks.

[jawz101]

#10721
#7038
#14551

[kbrosnan]

It can't be said for sure that these are duplicates until the people reporting these issues provide more detail about the cert that is being rejected. If the site is reachable in desktop the about:certificate page will have a lot of useful info. If it is not reachable on desktop then this is likely expected behavior. https://www.ssllabs.com/ssltest/index.html can provide info about certificates without the need to access them in Firefox.

[jawz101]

it has nothing to do with certs- it's the actual error page when viewed for any site w/ a self-signed or cert error. The button to "accept the risk" scrolls out of focus immediately when you try to click it. That, or it appears offscreen (underneath chrome of the bottom address bar).

It's hard for me to give an example because, personaly, it happens on equipment with web consoles on my internal network that has self-signed certificates

[smithi7]

I'm now running 81.1.1 and only following release versions. If relevant, on a Samsung Galaxy J5 Pro. No change related to this issue seen on the site in question.

However using the badssl.com test sites, all but one now do actually work, on the SECOND and subsequent attempts, except the one called 'pinning-test',

I have no idea what that means, but it's the only one that still duplicates the behaviour seen with my problem site, i.e:

"Web sites prove their identity via certificates. Firefox does not trust https://pinning-test.badssl.com/ because its certificate issuer is unknown, the certificate is self-signed, or the server is not sending the correct intermediate certificates."

I'm not at liberty to reveal our url, and because it also uses a non-standard port, I can't test at the recommended:
https://www.ssllabs.com/ssltest/index.html

re #14551: not applicable to this issue here; ordinary insecure sites work fine.

re #10721: looks related, but I have the url bar at top so that's not this issue.

re #7038: I'm not sure, but think the specific issue is better described and focused upon here. Too many dupe issues are confusing unless really different.

Frankly, I think my report/s and the first, detailed response by clientenq covers it pretty well.

jawz101, you could try testing with the url bar at top, to see if that makes any difference?

[kbrosnan]

If you are seeing issues with a website and not the original reporter then please create a new issue. Each site can have individual problems that are unrelated to this issue.

[actionsoneverything]

I'm also getting this, I'm trying to test my website on mobile from my development environment, clicking this 'accept risks and continue' works on the desktop browser, but does nothing on mobile (production, beta, nightly & focus).

I have no addons installed, and even tried disabling these https error prompts via about:config in nightly.

Using remote debugging it gives the following error when I click the broken button:

Unexpected error: InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable resource://android/assets/errorPageScripts.js:79:17
    acceptAndContinue resource://android/assets/errorPageScripts.js:79
    onclick resource://android/assets/low_and_medium_risk_error_pages.html?&title=Secure+Connection+Failed&button=Try+Again&description=%3Cul+role%3D%22presentation%22%3E+%3Cli%3EThe+page+you+are+trying+to+view+cannot+be+shown+because+the+authenticity+of+the+received+data+could+not+be+verified.%3C%2Fli%3E+%3Cli%3EPlease+contact+the+web+site+owners+to+inform+them+of+this+problem.%3C%2Fli%3E+%3C%2Ful%3E&image=mozac_error_lock.svg&showSSL=true&badCertAdvanced=Advanced%E2%80%A6&badCertTechInfo=%3Clabel%3ESomeone+could+be+trying+to+impersonate+the+site+and+you+should+not+continue.%3C%2Flabel%3E+%3Cbr%3E%3Cbr%3E+%3Clabel%3EWeb+sites+prove+their+identity+via+certificates.+Firefox+Nightly+does+not+trust+%3Cb%3Ehttps%3A%2F%2F192.168.1.72%3A8080%2F%3C%2Fb%3E+because+its+certificate+issuer+is+unknown%2C+the+certificate+is+self-signed%2C+or+the+server+is+not+sending+the+correct+intermediate+certificates.%3C%2Flabel%3E&badCertGoBack=Go+Back+%28Recommended%29&badCertAcceptTemporary=Accept+the+Risk+and+Continue:1

[RussellAult]

@smithi7

However using the badssl.com test sites, all but one now do actually work, on the SECOND and subsequent attempts, except the one called 'pinning-test',

Just for clarity, desktop Firefox doesn't let you skip past the warning on https://pinning-test.badssl.com/ , either. The full desktop error message explains why:

pinning-test.badssl.com has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.

[lobontiumira]

I can reproduce the

However using the badssl.com test sites, all but one now do actually work, on the SECOND and subsequent attempts, except the one called 'pinning-test',

with Google Pixel (Android 10) on the latest Firefox Nightly build from 1/13.

[stale]

See: #17373 This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sflorean]

This is still reproducible on Nightly 7/13 with Samsung Note 10 (Android 11).

[stale]

See: #17373 This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[RussellAult]

Not sure when exactly this was fixed, but I'm no longer seeing this problem in 95.1.0

[sflorean]

I confirm that the issue is no longer reproducible.