IPFS badge should open native protocol scheme when local node is used

[lidel]

Problem

When IPFS resolution is set to "Brave local node", opening https://en.wikipedia-on-ipfs.org/wiki/Wikipedia/ show "IPFS" badge in address bar:

but clicking on it does not open ipns://en.wikipedia-on-ipfs.org/wiki/Wikipedia/
it opens http://ipns://en.wikipedia-on-ipfs.org.ipns.localhost:48080/wiki/Wikipedia/

Expected bahavior

Brave should open native ipfs:// or ipns://

In this specific case, it should open ipns://en.wikipedia-on-ipfs.org/wiki/Wikipedia/

Other notes

Sounds like we tested "gateway" scenario, but did not check "local node" one when testing fix for #20567

[BigLep]

Good catch @lidel . Did you manually find this? I realize this is a question for Brave, but is there a way to have an automated test for this or manual test in a Brave release checklist?

[lidel]

QA does manual verification before release (e.g. #21462)

afaik there is no way to automate addressbar checks like this one, right @stephendonner?

[stephendonner]

QA does manual verification before release (e.g. #21462)

afaik there is no way to automate addressbar checks like this one, right @stephendonner?

Not at present; especially since it involves going to chrome:///brave:// schemes, which things like Selenium can't get at.

@spylogsster would this be able to be succinctly covered by browsertests?

[stephendonner]

An additional case, from #21462

Steps:

1. install 1.38.21
2. launch Brave
3. load ipns://ipfs.io
4. click on Use a Brave local IPFS node
5. wait for installation to complete
6. load https://blog.ipfs.io/24-uncensorable-wikipedia
7. click on the IPFS button/badge in the URL bar

Actual:
Land on http://blog.ipfs.io.ipns.localhost:48081/24-uncensorable-wikipedia/

Expected:
According to our test plan, it should be ipns://blog.ipfs.io/24-uncensorable-wikipedia

[srirambv]

@lidel this seems to be fixed (mostly) for the original steps with Kubo 0.17.0. Loading https://en.wikipedia-on-ipfs.org/wiki/Wikipedia/ and clicking on the IPFS button loads ipns://en.wikipedia-on-ipfs.org/wiki/Wikipedia/, however #21306 (comment) also seems to work but fails to resolve both ipfs:// or ipns://. Are we good to close this issue as fixed with Kubo update?

21306.mov

[lidel]

ipfs://{domain-name} is invalid (DNSLink works only with ipns://), so that last error is nothing weird.

Ok to close.