Closed Bug 1610836 Opened 5 years ago Closed 5 years ago

Firefox fails to load URL provided from command line when trr mode is 2

Categories

(Core :: Networking: DNS, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla74
Tracking Status
firefox74 --- fixed

People

(Reporter: michal, Assigned: valentin)

References

(Regression)

Details

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

Attachments

(2 files)

Attached file log

I cannot reproduce it with nightly build, but I can reliably reproduce it with debug build of mozilla central. See this part in the log:

2020-01-22 13:36:10.261154 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver Resolving host [geekflare.com] type 0. [this=0x7fdac4a690e0]
2020-01-22 13:36:10.261174 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver No usable record in cache for host [geekflare.com] type 0.
2020-01-22 13:36:10.261184 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver NameLookup: geekflare.com effectiveTRRmode: 2
2020-01-22 13:36:10.261193 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TRRService::Enabled MaybeConfirm()
2020-01-22 13:36:10.261199 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TRRService:MaybeConfirm mode=2, mConfirmer=0x7fda93560000 mConfirmationState=1
2020-01-22 13:36:10.261204 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TRRService::Enabled mConfirmationState=1 mCaptiveIsPassed=1
2020-01-22 13:36:10.261210 UTC - [Parent 22744: Socket Thread]: D/nsHostResolver TrrLookup:: geekflare.com service not enabled
2020-01-22 13:36:10.261220 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport after event [this=0x7fda8e77d800 cond=804b001e]
2020-01-22 13:36:10.261226 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketTransport::OnSocketDetached [this=0x7fda8e77d800 cond=804b001e]
2020-01-22 13:36:10.261234 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketTransport::RecoverFromError [this=0x7fda8e77d800 state=0 cond=804b001e]
2020-01-22 13:36:10.261239 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport not in a recoverable state
2020-01-22 13:36:10.261262 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketInputStream::OnSocketReady [this=0x7fda8e77da98 cond=804b001e]
2020-01-22 13:36:10.261269 UTC - [Parent 22744: Socket Thread]: D/nsSocketTransport nsSocketOutputStream::OnSocketReady [this=0x7fda8e77dad0 cond=804b001e]

Valentin, can you have a look at it?

Flags: needinfo?(valentin.gosu)

Nice catch. It seems we gTRRService->Enabled() returns false when mConfirmationState is CONFIRM_TRYING

Assignee: nobody → valentin.gosu
Flags: needinfo?(valentin.gosu)
Priority: -- → P2
Whiteboard: [necko-triaged][trr]

And nsSocketTransport::mState is STATE_CLOSED instead of STATE_RESOLVING for some reason.

See Also: → 1612027
Regressed by: 1552176
Has Regression Range: --- → yes

When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.

See Also: 1612027
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/e051d75e66f7 Don't fail TRR_FIRST requests if the TRR service is not ready r=mayhemer
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/cd7d8aad0306 Don't fail TRR_FIRST requests if the TRR service is not ready r=mayhemer
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
Flags: needinfo?(valentin.gosu)

Note that for some users in Nightly 74 this could break network connectivity. If you can't access any pages then try going to about:config, and set network.trr.mode to 0. Then update Firefox. That should fix the issue.

Flags: qe-verify+
QA Contact: daniel.cicas

Tried reproducing the issue with both an affected normal nightly build and a debug build, but without any success.
@Michal, could you please help out in verifying the issue?

Flags: needinfo?(michal.novotny)

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #15)

@Michal, could you please help out in verifying the issue?

I can reproduce the bug with revision c6fcec6a58c9 but cannot with revision cd7d8aad0306, so it's fixed.

Flags: needinfo?(michal.novotny)

Closing the issue as verified based on Michals comment.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressions: 1637512
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: