Closed Bug 1762566 Opened 2 years ago Closed 2 years ago

Going back from a https-only error will present another ssl error

Categories

(Core :: DOM: Security, defect, P3)

defect

Tracking

()

RESOLVED FIXED
104 Branch
Tracking Status
relnote-firefox --- 104+
firefox-esr91 --- unaffected
firefox-esr102 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- wontfix
firefox104 --- fixed

People

(Reporter: petru, Assigned: owlish)

References

(Regression, )

Details

(Keywords: regression, Whiteboard: [domsecurity-active] [geckoview:m104])

Attachments

(2 files)

Attached video FromErrorToError.mp4

Issue seen on klimaentscheid-leipzig.org

STRs:

  • Load klimaentscheid-leipzig.org in a new tab
    (You should get the https-only error)
  • Tap continue
  • click to go back in history

Expected:

  • No error. If http-only is disabled accessing klimaentscheid-leipzig.org presents no error.

Actual:

  • unsecure connection error.

 
The same happens on Fenix and on desktop.

I can reproduce this bug in Firefox 98 and 100 on Windows 11, but not in ESR 91.7.1. That suggests this bug is a regression between 92-98.

owlish, I bisected this regression to the following pushlog with your fix for HTTPS-Only Mode bug 1697866 in v94:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=56c35cc1a87ff4d45bb93c3329ced58b8925c21f&tochange=2716327aeafe1399250a81ecaafd7897f2cad53d

Even though that fix was a GeckoView change, the regression is reproducible in Firefox desktop.

Flags: needinfo?(bugzeeeeee)
Regressed by: 1697866
Assignee: nobody → bugzeeeeee
Flags: needinfo?(bugzeeeeee)
Has Regression Range: --- → yes
Severity: -- → S3
Status: NEW → ASSIGNED
Priority: -- → P1

Set release status flags based on info from the regressing bug 1697866

Whiteboard: [domsecurity-active]
Whiteboard: [domsecurity-active] → [domsecurity-active][geckoview:m101]

Carrying this bug forward from GV 101 to 102 because fixing this bug is still a high priority, but unassigning Irene for now because she's currently working on some other bugs for 102.

Assignee: bugzeeeeee → nobody
Status: ASSIGNED → NEW
Whiteboard: [domsecurity-active][geckoview:m101] → [domsecurity-active] [geckoview:m101] [geckoview:m102]

(In reply to Chris Peterson [:cpeterson] from comment #4)

Carrying this bug forward from GV 101 to 102 because fixing this crash is still a high priority, but unassigning Irene for now because she's currently working on some other bugs for 102.

I suppose that's not a P1 then, thanks Chris.

Priority: P1 → P3
Whiteboard: [domsecurity-active] [geckoview:m101] [geckoview:m102] → [domsecurity-backlog1] [geckoview:m101] [geckoview:m102]

I'm removing the GeckoView whiteboard tags because this bug affects both Android and desktop. This is not a GeckoView bug.

Whiteboard: [domsecurity-backlog1] [geckoview:m101] [geckoview:m102] → [domsecurity-backlog1]

Christoph, is there a fix planned for 103? Thanks

Flags: needinfo?(ckerschb)

(In reply to Pascal Chevrel:pascalc from comment #7)

Christoph, is there a fix planned for 103? Thanks

No, not for 103 as I know.
Irene, any chance you could take a look?

Flags: needinfo?(ckerschb) → needinfo?(bugzeeeeee)

104 would be more realistic

Flags: needinfo?(bugzeeeeee)
Assignee: nobody → bugzeeeeee
Status: NEW → ASSIGNED
Whiteboard: [domsecurity-backlog1] → [domsecurity-active]
Whiteboard: [domsecurity-active] → [domsecurity-active][geckoview:m103]
Whiteboard: [domsecurity-active][geckoview:m103] → [domsecurity-active][geckoview:m104?]

Irene says this bug affects desktop and mobile. She's working on it now.

Whiteboard: [domsecurity-active][geckoview:m104?] → [domsecurity-active] [geckoview:m104]

Before this patch, we would set REPLACE_HISTORY loading flag by calling SetLoadFlags which did not result in replacing history item and would add a new history item instead. That would lead to SSL error if navigating back after https-only error bypass. This patch corrects that by setting the flag on the load type instead (that is what used to happen under the hood before patch for 1697866 was merged)

Attachment #9284403 - Attachment description: WIP: Bug 1762566 - Set loading flag in correct place to make sure the history item is replaced after bypassing https-only error → Bug 1762566 - Set loading flag in correct place to make sure the history item is replaced after bypassing https-only error
Pushed by istorozhko@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7311dd61d853
Set loading flag in correct place to make sure the history item is replaced after bypassing https-only error r=nika
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: