Not sure second link in monitor not linked

[ldijkman]

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

Tuesday, February 20 2024 17:06:33
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

http://garage.local/ and http://kitchen.local/ is a clickable link

http://10.10.100.100:80 is not a clickable link

[jerch]

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)?

[ldijkman]

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

[ldijkman]

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

[ldijkman]

second link on monitor line
ip without port is clickable

links with port are not clickable links

[ldijkman]

hmm

looks like it also does not make links of text with caps

http://Living.local

is not linked

maybe because of L

[jerch]

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: ''
}

• protocol and host part are always lowered by URL (always case insensitive by spec, uppercase is strongly discouraged)
• URL truncates a port notion, if it is the default port of provided protocol

We 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?

[ldijkman]

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

[jerch]

@ldijkman PR #4965 should fix the issues. Thx for alot for finding them.