Closed Bug 2034752 Opened 3 months ago Closed 3 months ago

on-premise azure devops no longer works with firefox 150

Categories

(Core :: Networking: HTTP, defect, P1)

Product:
Core
Component:
Networking: HTTP
Version:
Firefox 150
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
152 Branch
Tracking Flags:
Tracking Status
relnote-firefox --- 150+
firefox-esr140 --- unaffected
firefox150 + fixed
firefox151 + fixed
firefox152 + fixed

People

(Reporter: misc, Assigned: tschuster)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

Bug 2034752 - Revert to ignoring the result of ProcessSecurityHeaders. r?kershaw
48 bytes, text/x-phabricator-request
Details | Review
Bug 2034752 - Revert to ignoring the result of ProcessSecurityHeaders.
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-beta+
Details | Review
Bug 2034752 - Revert to ignoring the result of ProcessSecurityHeaders.
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-release+
Details | Review
Bug 2034752 - Regression test with bad cert + HSTS. r?kershaw
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0

Steps to reproduce:

I opened a page on our on-premise azure devops instance.

Actual results:

The page does not load, it just stays blank and nothing happens. No error message is shown. In the dev tools I can see that I get back a 401 from the GET.
The issue persists in a fresh profile or in a private window.

Expected results:

With Firefox 149 a Firefox authentication pop-up appears where I can log in.

The 401 should probably trigger the NTLM login procedure but no longer does on Firefox 150.

My colleague on Windows cannot reproduce this.

I am on Ubuntu and installed Firefox from the official PPA.
The azure devops server version we use is Azure DevOps Server 2022.2 (AzureDevopsServer_20251024.2) .

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Component: Widget: Gtk → Networking
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

I have similar issue where 401 response is returned to the application as a network failure (NS_ERROR_FAILURE) and fetch promise is rejected instead of providing correct response object. Sometimes the problem can be fixed by using a reverse proxy.

Hi Reporter,

Could you use mozregression to find us find out the regression range?

Thanks.

Flags: needinfo?(misc)

mozregression spit out this: https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=f59d5984853e3ed388f911268964b33fcce482ad&tochange=1a6c5c6f11fca486436075d92fd82d51f706c775

The range seems large to me, mozregression showed a lot of Skipping build xxxxxxxxxxxx: Unable to find build info using the taskcluster route ... warnings.

Flags: needinfo?(misc)

I've checked with mozregression as well and my result is:
Log:

2026-04-27T13:55:11.076000: DEBUG : Found commit message:
Bug 2017102 - Integrate WAICT with script loading. r=arai

Differential Revision: https://phabricator.services.mozilla.com/D283675


2026-04-27T13:55:11.080000: DEBUG : Did not find a branch, checking all integration branches
2026-04-27T13:55:11.083000: INFO : The bisection is done.
2026-04-27T13:55:11.086000: INFO : Stopped

Build info:

app_name: firefox
build_date: 2026-03-06 08:38:45.169000
build_file: /home/rjaros/.mozilla/mozregression/persist/de1867e90b20-shippable--autoland--target.tar.xz
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/QnasY6S9T4qRx9LYku6ohA/runs/0/artifacts/public%2Fbuild%2Ftarget.tar.xz
changeset: de1867e90b203b1f81fa7947611d3f0825b2ad70
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=60781c5b0278e535db70bb0eee4e96664d9c45f1&tochange=521d9a5e1573894c3f53192a34759c8c6fcfc703
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: QnasY6S9T4qRx9LYku6ohA

Appreciate for the information! This is very helpful.

Tom, could you take a look? Thanks.

Flags: needinfo?(tschuster)
Keywords: regression
Regressed by: 2017102

Maybe this change: https://searchfox.org/firefox-main/diff/b7e28a67a13c313fd48787cac883f4f9904e21b1/netwerk/protocol/http/nsHttpChannel.cpp#3242, which looked like a pre-existing bug, but might have been load bearing?

Flags: needinfo?(tschuster) → needinfo?(kershaw)

[Tracking Requested - why for this release]: Load errors on enterprise sites.

tracking-firefox150: --- → ?
Assignee: nobody → tschuster
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
See Also: → 2034403

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

status-firefox-esr140: --- → unaffected

(In reply to Tom Schuster from comment #8)

Maybe this change: https://searchfox.org/firefox-main/diff/b7e28a67a13c313fd48787cac883f4f9904e21b1/netwerk/protocol/http/nsHttpChannel.cpp#3242, which looked like a pre-existing bug, but might have been load bearing?

Seems likely. We can create a try push and ask the reporter to verify.

Flags: needinfo?(kershaw)

Hi! Can you please test if using one of these try builds fixes the problem for you:

Thank you!

Flags: needinfo?(misc)
Pushed by tschuster@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/cb27d8c9205e https://hg.mozilla.org/integration/autoland/rev/dcc41df6daae Revert to ignoring the result of ProcessSecurityHeaders. r=kershaw,necko-reviewers

I cannot reproduce the issue on that build!

Flags: needinfo?(misc)

(In reply to johannes from comment #15)

I cannot reproduce the issue on that build!

Thank you! That is great to know.

Attachment #9574127 - Flags: approval-mozilla-beta?

firefox-beta Uplift Approval Request

  • User impact if declined/Reason for urgency: Completely broken websites. We had reports from enterprise.
  • Code covered by automated testing?: no
  • Fix verified in Nightly?: yes
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: Make some code more obvious, but reverts code to its previous behavior.
  • String changes made/needed?: no
  • Is Android affected?: yes

firefox-release Uplift Approval Request

  • User impact if declined/Reason for urgency: Completely broken websites. We had reports from enterprise.
  • Code covered by automated testing?: no
  • Fix verified in Nightly?: yes
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: Make some code more obvious, but reverts code to its previous behavior.
  • String changes made/needed?: no
  • Is Android affected?: yes
Attachment #9574128 - Flags: approval-mozilla-release?

Hi Dianna,
I hope it’s not too late to include this patch in tomorrow’s dot release. Thanks.

Flags: needinfo?(dsmith)
tracking-firefox150: ? → +
tracking-firefox151: --- → +
tracking-firefox152: --- → +
Flags: needinfo?(dsmith)
Severity: -- → S1
Priority: -- → P1
Severity: S1 → S2
Priority: P1 → --
Priority: -- → P1

https://hg.mozilla.org/mozilla-central/rev/dcc41df6daae

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
status-firefox152: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch
Attachment #9574127 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Regressions: 2035828
See Also: → 2035609
Attachment #9574128 - Flags: approval-mozilla-release? → approval-mozilla-release+
Component: Networking → Networking: HTTP
Duplicate of this bug: 2035609
See Also: 2035609 →
Duplicate of this bug: 2034403
See Also: 2034403 →
Duplicate of this bug: 2035409
See Also: → 2035856
Duplicate of this bug: 2035856
See Also: 2035856 →
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: