Metamask .test domain (or any other non TLD) triggers search from Portal Network

[zmaglica]

Bug Reports:

I am using .test domain for local development and when I type URL in the browser, Metamask redirects me to Portal Network search. I am not sure why you guys using that search engine in first place...

• Expected Behavior
  When I type URL in browser it actually redirects you to URL you typed
• Actual Behavior
  If you type any non-TLD domain in browser, Metamask will redirects you to the portal search engine (tested with .test domain)
• Browser Used
  Chrome 68
• Operating System Used
  Windows 10

[jmigdelacruz]

Same issue, same specs except:

Operating system used

• MacOS Sierra

[bdresser]

@zmaglica thanks for the question. We're not routing your request through portal.network - we're loading the ENS info from the blockchain via Infura, and the IPFS content via infura as well.

You can read a full summary of the feature here: https://consensys.zendesk.com/hc/en-us/articles/360012782931

I'll leave this open for a couple days in case other folks have the same question.

[bitpshr]

@zmaglica @jmigdelacruz some additional context: URLs in the form of both <some_domain>.eth and <some_domain>.test are considered valid ENS URLs on certain networks (with .test TLDs being specific to testnets like Rinkeby and Ropsten.) You can read more about the difference between these two TLDs here.

This means that MetaMask (and any other dapp browser that resolves ENS domains) will attempt to resolve .test URLs on using ENS.

[jmigdelacruz]

@bitpshr Thanks for clarifying. Just curious, why do we need Metamask to resolve ENS domains? Can't we leave that functionality to the browser or let users decide to enable/disable this feature?

As a user, i'm coming from the fact that i'm using Metamask primarily, apologies for the simple term, as a "wallet." I am not interested in ENS domains.

[eduadiez]

@bdresser I've reported an issue #5009 related to this and a PR #5010 to fix it, I hope you can review it.

[bdresser]

thanks @eduadiez! We'll get this in the release going out this morning 👍

[bdresser]

@zmaglica this issue is fixed on 4.9.2 by #5010. We'll try DNS first, and if it doesn't resolve, then try ENS.

[pesho]

Seems that #5010 does not fix the issue completely (using Metamask 4.9.3 on Chrome/Linux).

I have a .test domain configured in /etc/hosts which is intercepted by Metamask.

Requesting that the issue be reopened @bdresser

[pesho]

Update: Looks like this is actually a Chrome issue. Chrome seems to have stopped resolving domains via /etc/hosts after updating to v68.x. So Metamask attempts to handle it after the browser fails to resolve the domain.

You can disregard my previous comment.

[ilyakatz]

I'm getting this on Firefox, so it's not just a Chrome issue. Would be nice to reopen it

[bdresser]

This issue was for MetaMask matching on all .test domains. @ilyakatz could you open a new issue with reproduction steps for the problem you're seeing? Thank you!

[ilyakatz]

Yes, i'm seeing the same problem with .test domains. just answering to @pesho who seemed to imply that it's only a chrome issue

[bdresser]

We can't reproduce the original issue, and pesho is writing about interference with domains added to his /etc/hosts. Would appreciate a clean issue with your specific repro steps! Thanks.

[pesho]

I was actually mistaken in my previous message, sorry for any confusion caused. This was the wrong part:

Chrome seems to have stopped resolving domains via /etc/hosts after updating to v68.x. So Metamask attempts to handle it after the browser fails to resolve the domain.

Back then it turned out that there was simply nothing listening on that port locally (Haproxy had failed to start due to incorrect config). It was not a Chrome bug in fact. Metamask actually intercepts such requests not only when DNS doesn't resolve, but also when the target can't be reached (@ilyakatz check if you have a similar issue).

In my case fixing the Haproxy config resolved the issue. I didn't post an update here back then because I had already added enough noise to the thread.