Closed Bug 1451150 Opened 4 years ago Closed 4 years ago

TRR: the wait for captive portal isn't right


(Core :: Networking: DNS, enhancement, P1)




Tracking Status
firefox61 --- fixed


(Reporter: bagder, Assigned: bagder)


(Whiteboard: [necko-triaged][trr])


(1 file)

1. The default TRR pref says "wait for captive portal" but the code didn't actually verify that the message said "clear" - just that it was a message. It made the code reset TRR confirmation state (again) when the CP event finally arrives, possibly causing one or two resolves (in TRR-first mode) to instead use the native resolver. This could be seen in session restore cases with many tabs.

2. The captive portal event would reset the confirmation state even when it was already confirmed, as in when the pref was set to not wait for captive portal.

The downside with fixing this to actually wait for the CP confirmation is that we delay the first TRR resolve a bit compared to what it is now...
Comment on attachment 8964716 [details]
bug 1451150 - make TRRService wait for the correct CP event

::: netwerk/dns/TRRService.cpp:289
(Diff revision 1)
>      LOG(("TRRservice in captive portal\n"));
>      mCaptiveIsPassed = false;
>    } else if (!strcmp(aTopic, NS_CAPTIVE_PORTAL_CONNECTIVITY)) {
>      nsAutoCString data = NS_ConvertUTF16toUTF8(aData);
>      LOG(("TRRservice captive portal was %s\n", data.get()));
> +    if (data.Equals("clear")) {

I'm not a big fan of the 7 levels of indentation, but it's fine for now :)
Attachment #8964716 - Flags: review?(valentin.gosu) → review+
Pushed by
make TRRService wait for the correct CP event r=valentin
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.