fast-path to skip proxy resolution missed MOZ_ENABLE_LIBPROXY case
Categories
(Core :: Networking: Proxy, defect, P3)
Tracking
()
| 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".
| Assignee | ||
Comment 1•1 month ago
|
||
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".
Updated•1 month ago
|
| Assignee | ||
Updated•1 month ago
|
Comment 2•1 month ago
|
||
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.
Comment 3•1 month ago
|
||
Set release status flags based on info from the regressing bug 2028356
| Assignee | ||
Updated•1 month ago
|
Updated•1 month ago
|
Comment 5•1 month ago
|
||
| bugherder | ||
Comment 6•1 month ago
|
||
The patch landed in nightly and beta is affected.
:cmt, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox152towontfix.
For more information, please visit BugBot documentation.
Updated•1 month ago
|
| Assignee | ||
Comment 7•1 month ago
|
||
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.
Updated•1 month ago
|
Updated•14 days ago
|
Description
•