Closed Bug 1792635 Opened 2 years ago Closed 2 years ago

DNS not found error asks "did you mean to go to X" when the internet connection is flaky and opening X didn't work

Categories

(Firefox :: Security, defect, P3)

defect

Tracking

()

RESOLVED FIXED
108 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox105 --- wontfix
firefox106 --- wontfix
firefox107 --- fixed
firefox108 --- fixed

People

(Reporter: Gijs, Assigned: jteow)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

I'm seeing this a bunch on plane/conference (all hands) wifi - the "did you mean to go to" text has the same URL that I already tried to open. Maybe the only difference is the hash/ref or something? I don't quite know why this is happening at all - I guess that the initial request fails but then the dns request from the webpage succeeds, or something? If that's the case we should just auto-retry the request at that point, or something.

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

:jteow, since you are the author of the regressor, bug 1737043, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jteow)

:gijs, I think what's happening is precisely what you're saying, namely the initial request fails but the follow-up DNS check succeeds. The "fixed" URI is going to be the same as the URI that was provided, specifically if there was nothing to correct such as if the protocol of the URI matches browser.fixup.alternate.protocol.

My worry with automatically reloading the page is it might not be obvious the user why it's reloading, especially if the DNS check completes after the error text is loaded since we're not blocking the initial error message from showing until the DNS check is complete.

I think the easiest solution might just be to early return here if the entered and fixed up URI's match so that error message can just say "We can’t connect to the server at www.example.com."

Severity: -- → S3
Flags: needinfo?(jteow)
Priority: -- → P3

It doesn't seem to make much sense to suggest the same page you're on, I thought we were only testing dns and suggesting an alternative if the fixed uri was different.

I modified the boolean associated with fixupCreateAlternateURI to only
be true if the host which contains the prefix and suffix differs from
the fixed up version. This will allow the boolean to be false in cases
where the fixup doesn't change the host. Then for the DNS error page,
there is a check as to whether the host or protocol was changed.

Assignee: nobody → jteow
Status: NEW → ASSIGNED
Pushed by jteow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cf564357bd46
Prevent DNS not found page from suggesting the same URI - r=mak

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

Regressions: 1796034
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 108 Branch

Should we uplift this to 107?

Flags: needinfo?(jteow)

Actually, even the planned dot release might not be a bad idea, I guess...

:Gijs, initially, I wasn't planning on requesting it since I expect users rarely encounter this page and the suggested link shows a URL that isn't directing them to the wrong place. However, upon reflection, it does add confusion to the error page because it implies to the user that the URL they initially entered was wrong, making an already negative and frustrating experience potentially more so.

So, I'll wait for verification that the patch isn't causing Bug 1796034 (I feel like it's really unlikely my patch caused it, but if it did, I'll investigate and issue another fix) before requesting the uplift.

Flags: needinfo?(jteow)

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

  • If yes, please nominate the patch for beta approval.Also, don't forget to request an uplift for the patches in the regression caused by this fix.
  • If no, please set status-firefox107 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jteow)

Comment on attachment 9298219 [details]
Bug 1792635 - Prevent DNS not found page from suggesting the same URI - r?mak

Beta/Release Uplift Approval Request

  • User impact if declined: The user impact of this is this bug might be adding confusion: users might think they entered the wrong URL to the page they tried visiting.

When users attempt to go to a website and the DNS lookup fails, we show an error page.

This error page may include a suggested link that is generated by taking the URL they tried visiting and fixing it up (e.g. upgrading http to https, adding www. or .com to the host) which also gets checked by the DNS lookup service.

One case I didn't consider was that it's possible for the initial DNS lookup to fail, for the URL to not get fixed up, and the subsequent DNS lookup for that non-fixed up link to succeed, thus showing the user a suggested link that isn't actually different from the link they used to see this error page in the first place. The fix for this makes it so that if the link is not fixed up, we don't proceed to do another DNS lookup.

  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This patch is scoped to the error page, as well as a helper method that modifies a property that is rarely referenced in the codebase.
  • String changes made/needed:
  • Is Android affected?: No
Flags: needinfo?(jteow)
Attachment #9298219 - Flags: approval-mozilla-beta?

Comment on attachment 9298219 [details]
Bug 1792635 - Prevent DNS not found page from suggesting the same URI - r?mak

Approved for 107.0b4.

Attachment #9298219 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: