Closed ldijkman closed 5 months ago
~Prolly the same as #4296. (I'll keep this issue open until it is confirmed...)~
Nope its not related...
Edit: Cant repro it on master - can you retry with the newer @xterm
packages (beta only atm)?
hmm thought it was the second link on line is not clickable so changed it but if the ip is the first link it is also NOT clickable
Thursday, February 22 2024 04:08:13
mDNS at http://garage.local
Browsing for service _http._tcp.local. ... 1 service(s) found
1: http://kitchen.local - http://10.10.100.100:80
1: http://10.10.100.100:80
looks like :port in link is the problem
last ip without port is clickable
Thursday, February 22 2024 04:19:04
mDNS at http://garage.local
Browsing for service _http._tcp.local. ... 1 service(s) found
1: http://kitchen.local - http://10.10.100.100:80
1: http://10.10.100.100:80
1: http://10.10.100.100
second link on monitor line ip without port is clickable
links with port are not clickable links
hmm
looks like it also does not make links of text with caps
is not linked
maybe because of L
This roughly summarizes, whats going here:
> new URL('hTTpS://Living.local:443/inPathUpperNotLowered')
URL {
href: 'https://living.local/inPathUpperNotLowered',
origin: 'https://living.local',
protocol: 'https:',
username: '',
password: '',
host: 'living.local',
hostname: 'living.local',
port: '',
pathname: '/inPathUpperNotLowered',
search: '',
searchParams: URLSearchParams {},
hash: ''
}
URL
(always case insensitive by spec, uppercase is strongly discouraged)URL
truncates a port notion, if it is the default port of provided protocolWe currently do a sanity check against the URL
parsing result with s.startswith
, here we lose the uppercase matching. We should instead do a s.toLowerCase().startswith
check. For uppercase in the protocol we can change the regexp to
const strictUrlRegex = /(https?|HTTPS?):[/]{2}[^\s"'!*(){}|\\\^<>`]*[^\s"':,.!?{}|\\\^~\[\]`()<>]/;
instead (assuming those funny mixed case things like 'hTTp' is not what we want to match).
I still cannot repro the port issue, startswith
should still match even with the port notion being removed. Have you tested with the newer @xterm
packages?
Sorry i do not have the knowledge how to change the webadonlinks xterm
I use the chromium terminal example https://ldijkman.github.io/async-esp-fs-webserver/WebSerialMonitor.html
https://github.com/GoogleChromeLabs/serial-terminal
They at chromium said xterm webaddonlinks maybe the problem for not linking
And the ESP mdns monitor links are http not https as your test showed
Greet luberth
@ldijkman PR #4965 should fix the issues. Thx for alot for finding them.
hello
Not sure second link in monitor not linked ad on weblinks?
playing with your demo https://ldijkman.github.io/async-esp-fs-webserver/WebSerialMonitor.html
serial monitor demo does not make a second link clickable i think
http://garage.local/ and http://kitchen.local/ is a clickable link
http://10.10.100.100:80 is not a clickable link