1920710 - ics calendar from webcal://www.webcal.guru can't be added - console says blocked by OpaqueResponseBlocking. Reason: “after sniff: nosniff is true”

Status: RESOLVED FIXED

(Calendar :: Provider: ICS/WebDAV, defect, P3)

Description

[Richard Leger]

Follow up on Bug 1906077 Comment 14

"...
The patch does not seems to work in TB 131.0b5 with webcal://www.webcal.guru/fr-FR/t%C3%A9l%C3%A9charger_le_calendrier?calendar_instance_id=269 (Comment 5).

Still get Could not find calendar's at this location. Check your settings.

While I can subscribe to this calendar in TB 115.13.0 (32-bit) without issue.
..."

...and Bug 1906077 Comment 15

"...
In the console I get `The resource at “https://www.webcal.guru/fr-FR/t%C3%A9l%C3%A9charger_le_calendrier?calendar_instance_id=269” was blocked by OpaqueResponseBlocking. Reason: “after sniff: nosniff is true”.´ This request does work using fetch() though so I'm not sure what's wrong.
...

Comment 1

[Corey Bryant]

I think the intended version was 128 since this worked on 115.

Comment 2

[Richard Leger]

Attachment: unabletobisect.png

The regression windows seems to be between...

app_name: thunderbird
build_date: 2022-10-27
build_file: C:\Users\richard.mozilla\mozregression\persist\2022-10-27--comm-central--thunderbird-108.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/thunderbird/nightly/2022/10/2022-10-27-10-24-48-comm-central/thunderbird-108.0a1.en-US.win64.zip
changeset: 8b330f7342ec20451342580900ba1dd79a59eb57
pushlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=8b330f7342ec20451342580900ba1dd79a59eb57&tochange=5fa7c75aca7eec26d1e9e751ba913c2938fd91ce
repo_name: comm-central
repo_url: https://hg.mozilla.org/comm-central

...which works ok...

...and...

app_name: thunderbird
build_date: 2022-10-28
build_file: C:\Users\richard.mozilla\mozregression\persist\2022-10-28--comm-central--thunderbird-108.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/thunderbird/nightly/2022/10/2022-10-28-10-26-33-comm-central/thunderbird-108.0a1.en-US.win64.zip
changeset: 5fa7c75aca7eec26d1e9e751ba913c2938fd91ce
pushlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=5937332784b764bbaeeba3b067bc6bc453a5d06e&tochange=5fa7c75aca7eec26d1e9e751ba913c2938fd91ce
repo_name: comm-central
repo_url: https://hg.mozilla.org/comm-central

...where it does not work anymore...

When running the bisection attached I got "Unable to find enough data to bisect", so the above is all I can provide.

Comment 3

[Magnus Melin [:mkmelin] (away until Aug 10)]

I don't see anything in there.
Perhaps an m-c change ~ https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2022-10-27+10%3A00&enddate=2022-10-28+13%3A00

Comment 4

[Martin Schröder [:mschroeder]]

(In reply to Magnus Melin [:mkmelin] from comment #3)

I don't see anything in there.
Perhaps an m-c change ~ https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2022-10-27+10%3A00&enddate=2022-10-28+13%3A00

Bug 1785331 and https://hg.mozilla.org/mozilla-central/rev/9596658a1a0f9c8911a18b0322e6f094eedd69b4 seem related.

Comment 5

[Magnus Melin [:mkmelin] (away until Aug 10)]

Thanks Martin, that's definitely it! If I set browser.opaqueResponseBlocking false then it works.

I notice the issue has a twist though. It only happens for http

• fails: http://www.webcal.guru/fr-FR/t%C3%A9l%C3%A9charger_le_calendrier?calendar_instance_id=269
• works: https://www.webcal.guru/fr-FR/t%C3%A9l%C3%A9charger_le_calendrier?calendar_instance_id=269

For the failing case, I see Sec-Fetch-Mode: no-cors in the request headers. (Which should probably not be sent, I'm not sure if it's the cause or not.)

Comment 6

[Toby Pilling [:tobyp]]

Can this be closed and https be used as the solution?

Comment 7

[Magnus Melin [:mkmelin] (away until Aug 10)]

(In reply to Toby Pilling [:tobyp] from comment #6)

Can this be closed and https be used as the solution?

In this case yes, if you now about it. But not generally.

Comment 8

[Magnus Melin [:mkmelin] (away until Aug 10)]

Found out the cause. ORB is in used because we're not using system principal due to bug 1468912.
I tested a patched version with Nextcloud and it seems fine.

Comment 9

[Magnus Melin [:mkmelin] (away until Aug 10)]

Attachment: Bug 1920710 - Use system principal for calendar requests to prevent ORB blocking. r=#thunderbird-reviewers

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ea4766fb5c04
Use system principal for calendar requests to prevent ORB blocking. r=tobyp

Comment 11

[Magnus Melin [:mkmelin] (away until Aug 10)]

Comment on attachment 9472717 [details]
Bug 1920710 - Use system principal for calendar requests to prevent ORB blocking. r=#thunderbird-reviewers

Uplift Approval Request

• Please state case for uplift consideration and ensure bug severity is set: May not be able to add calendar
• User impact if declined:
• Is this code covered by automated tests?: No
• Has the fix been verified in Daily?: Yes
• Has the fix been verified in Beta?: Yes
• Needs manual test from QA?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Unknown unknowns. It's affecting caldav general code.
• String changes made/needed: none

Comment 12

[Corey Bryant]

Comment on attachment 9472717 [details]
Bug 1920710 - Use system principal for calendar requests to prevent ORB blocking. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr128

Comment 13

[Magnus Melin [:mkmelin] (away until Aug 10)]

Let's not take this for 128. Due to bug 1962189

Comment 14

[Geoff Lankow (:darktrojan)]

I think we should back this out. The URL listed in the bug title and comment 0 is a bad URL and should not find any calendars, since the server only responds to secure requests (and serves Strict-Transport-Security headers to enforce this). The correct URL is https: or webcals:. Perhaps we can suggest upgrading the scheme or do it automatically, but I don't think this patch is the answer.

The patch makes all of the code above the changes meaningless, which has led to the regressions.

Comment 15

[Magnus Melin [:mkmelin] (away until Aug 10)]

The calendar with the correct URL ends up being set, so I'm while the URL may be out of date in this case, I do think it should work.
But yes, I agree we'll have to back out (most of) this patch. Going to do that in bug 1964295.

Comment 16

[Francesco]

Should this be re-opened?

Comment 17

[Magnus Melin [:mkmelin] (away until Aug 10)]

Let's continue in bug 1965151. Would be too messy to re-open at this point.