Closed Bug 2040125 Opened 1 month ago Closed 1 month ago

fast-path to skip proxy resolution missed MOZ_ENABLE_LIBPROXY case

Categories

(Core :: Networking: Proxy, defect, P3)

Firefox 151
defect

Tracking

()

RESOLVED FIXED
153 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- unaffected
firefox150 --- unaffected
firefox151 --- wontfix
firefox152 --- wontfix
firefox153 --- fixed

People

(Reporter: cmt, Assigned: cmt)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [necko-triaged])

Attachments

(1 file)

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

Steps to reproduce:

In bmo #2028356 a "fast-path to skip proxy resolution[...]" was added, but the required method GetSystemProxyDirect() was not added for libproxy-enabled builds (all other cases - general Unix without libproxy, OSX, Windows - got that function).

This makes a "--enable-libproxy" build (MOZ_ENABLE_LIBPROXY) fail at startup, as the symbol for nsUnixSystemProxySettings::GetSystemProxyDirect() does not resolve.

I have a patch to add GetSystemProxyDirect() to the MOZ_ENABLE_LIBPROXY case - it's trivial, as we cannot know what libproxy will return for a specific URL, thus the fast-path does not apply and we can just return "false".

In bmo #2028356 a "fast-path to skip proxy resolution[...]" was added,
but the required method GetSystemProxyDirect() was not added for
libproxy-enabled builds (all other cases - general Unix without
libproxy, OSX, Windows - got that function).

This makes a "--enable-libproxy" build (MOZ_ENABLE_LIBPROXY) fail at
startup, as the symbol for nsUnixSystemProxySettings::GetSystemProxyDirect()
does not resolve.

This adds GetSystemProxyDirect() to the MOZ_ENABLE_LIBPROXY case - it's
trivial, as we cannot know what libproxy will return for a specific URL,
thus the fast-path does not apply and we can just return "false".

Assignee: nobody → cmt
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
Regressed by: 2028356

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, but is not confident enough to move the bug to that component.

Component: Untriaged → General

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

Component: General → Networking: Proxy
Product: Firefox → Core
Severity: -- → S4
Priority: -- → P3
Whiteboard: [necko-triaged]
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 153 Branch

The patch landed in nightly and beta is affected.
:cmt, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(cmt)

This only affects non-default build configurations, and anyone doing that can carry the patch for a while?
So I'd argue no uplift; but I'm not allowed to set the wontfix myself.

Flags: needinfo?(cmt)
Duplicate of this bug: 2041150
QA Whiteboard: [qa-triage-done-c154/b153]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: