[tracking] migrate certificate error string determination to front-end

RESOLVED FIXED in Firefox 61

Status

()

enhancement
P1
normal
RESOLVED FIXED
2 years ago
9 months ago

People

(Reporter: keeler, Assigned: franziskus)

Tracking

(Depends on 2 bugs, Blocks 1 bug, {meta})

unspecified
mozilla61
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox61 fixed)

Details

(Whiteboard: [psm-tracking])

Attachments

(1 attachment)

To improve our certificate error pages, we need to be more flexible in the error strings we come up with. This means many things, including moving the error string generation to the front-end, exposing more information from the handshake (fetched OCSP responses, stapled OCSP responses, CT information, etc.), and so on.
Keywords: meta
Depends on: 1415311
Depends on: 1415312
Assignee: nobody → franziskuskiefer
Priority: P3 → P1
Flags: needinfo?(jhofmann)
Depends on: 1441959
Comment on attachment 8952384 [details]
Move error strings for certError and netError pages to frontend

David Keeler [:keeler] (use needinfo) has approved the revision.

https://phabricator.services.mozilla.com/D607
Attachment #8952384 - Flags: review+
Flags: needinfo?(jhofmann)
Comment on attachment 8952384 [details]
Move error strings for certError and netError pages to frontend

David Keeler [:keeler] (use needinfo) has been removed from the revision.

https://phabricator.services.mozilla.com/D607
Attachment #8952384 - Flags: review+
Honza, can you check the devtools changes? The human-readable error message isn't available anymore so I added the error code string instead.
Sebastian can you check the Android changes?
Flags: needinfo?(s.kaspari)
Flags: needinfo?(odvarko)
Flags: needinfo?(jhofmann)
(In reply to Franziskus Kiefer [:fkiefer or :franziskus] from comment #4)
> Honza, can you check the devtools changes? The human-readable error message
> isn't available anymore so I added the error code string instead.
Yep, looks good, some inline comments created.
Honza
Flags: needinfo?(odvarko)
(In reply to Franziskus Kiefer [:fkiefer or :franziskus] from comment #4)
> Sebastian can you check the Android changes?

@snorp: Can you or someone from your team take this over?
Flags: needinfo?(s.kaspari) → needinfo?(snorp)
Blocks: 1441959
No longer depends on: 1441959
Flags: needinfo?(jhofmann)
Attachment #8952384 - Attachment description: Move error strings for certError and netError pages to frontent → Move error strings for certError and netError pages to frontend
Flags: needinfo?(jhofmann)
Comment on attachment 8952384 [details]
Move error strings for certError and netError pages to frontend

David Keeler [:keeler] (use needinfo) has approved the revision.
Johann Hofmann [:johannh] has approved the revision.

https://phabricator.services.mozilla.com/D607
Attachment #8952384 - Flags: review+
Thank you for working on this!
Flags: needinfo?(jhofmann)

Comment 10

a year ago
Pushed by franziskuskiefer@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/617a25dfb30d
Move error strings for certError and netError pages to frontend, r=johannh,keeler,Honza,snorp

Comment 11

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/617a25dfb30d
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61

Comment 12

a year ago
Is there a followup for the remaining URL params? When testing on current Nightly, I see a URL like:

"about:neterror?e=dnsNotFound&u=http%3A//www.afdgusndcoiairhfuadgvadfgafgadfgvnousfgpaerg.com/&c=UTF-8&f=regular&d=We%20can%E2%80%99t%20connect%20to%20the%20server%20at%20www.afdgusndcoiairhfuadgvadfgafgadfgvnousfgpaerg.com."

which seems to still contain some data in URL params, rather than exposing it through webidl or other means - even if some of the parameters (like 'd') don't seem to be used anymore (which makes me wonder why they're still there...).
Flags: needinfo?(franziskuskiefer)

Comment 13

a year ago
Oh, the 'd' bit seems to still make an appearance, just not as the title, which I guess is why I missed it... Still, seems like that should move to frontend, too, and the URL and encoding bits should be passed through some other means than URL params.
> Is there a followup for the remaining URL params?

There's bug 1442203 for more TLS error page improvements. Moving away from using e and c should probably go there. But that's not a PSM issue anymore. The way these error pages are handled in the front-end and in nsDocShell has to change for that.

> Oh, the 'd' bit seems to still make an appearance

Yes there are other errors (like dns) that use it. But no TLS errors.
Flags: needinfo?(franziskuskiefer)
Duplicate of this bug: 1370548

Updated

10 months ago
Depends on: 1483626
You need to log in before you can comment on or make changes to this bug.