URL detection: False positive for links where port number contains non-numeric characters #14574

Closed
opened 2026-01-31 04:13:56 +00:00 by claunia · 3 comments
Owner

Originally created by @Sominemo on GitHub (Jul 18, 2021).

Windows Terminal version (or Windows build number)

1.9.1942.0

Other Software

No response

Steps to reproduce

  1. Make a terminal display a described link, for example https://example.com:test
  2. Hover on link

Expected Behavior

Only the https://example.com part is being underlined, since it's correct

Actual Behavior

The whole https://example.com:test is being underlined, despite it being a non-valid URL.
image

Originally created by @Sominemo on GitHub (Jul 18, 2021). ### Windows Terminal version (or Windows build number) 1.9.1942.0 ### Other Software _No response_ ### Steps to reproduce 1. Make a terminal display a described link, for example `https://example.com:test` 2. Hover on link ### Expected Behavior Only the `https://example.com` part is being underlined, since it's correct ### Actual Behavior The whole `https://example.com:test` is being underlined, despite it being a non-valid URL. ![image](https://user-images.githubusercontent.com/19842935/126072922-fd36fe97-0b89-4e4d-b99b-9802c48226ce.png)
claunia added the Resolution-Duplicate label 2026-01-31 04:13:56 +00:00
Author
Owner

@orcmid commented on GitHub (Jul 19, 2021):

Steps to reproduce

  1. Make a terminal display a described link, for example https://example.com:test
  2. Hover on link

Expected Behavior

Only the https://example.com part is being underlined, since it's correct

I doubted that Terminal was the source of this until I reproduced it and I could not get it with cmd.exe outside of Terminal. The on-hover "press ctrl-click" to follow the URL does end up with a response that the underlined text is not of a valid URL.

With regard to the underlining of a URL detection, there are conventions for unambiguosly delimiting URLs in texts and these are covered in the IETF specifications. This is demonstrated with <https://example.com>:test although ( ... ) is doubtless preferable, just as in Markdown. It will also be necessary to %-encode spaces and some other characters that might appear in the intended URL.

I suggest that we not expect Terminal to do much about detecting something that might be intended to be followable or not. You can tell from the hover-underline whether it got all, too little, or too much of an intended one. That additional checking occurs only on attempting to use it makes the most sense to me. (I can't imagine how this works with respect to accessibility though.)

@orcmid commented on GitHub (Jul 19, 2021): > ### Steps to reproduce > 1. Make a terminal display a described link, for example `https://example.com:test` > 2. Hover on link > > ### Expected Behavior > Only the `https://example.com` part is being underlined, since it's correct I doubted that Terminal was the source of this until I reproduced it and I could not get it with cmd.exe outside of Terminal. The on-hover "press ctrl-click" to follow the URL does end up with a response that the underlined text is not of a valid URL. With regard to the underlining of a URL detection, there are conventions for unambiguosly delimiting URLs in texts and these are covered in the IETF specifications. This is demonstrated with `<https://example.com>:test` although `( ... )` is doubtless preferable, just as in Markdown. It will also be necessary to %-encode spaces and some other characters that might appear in the intended URL. I suggest that we not expect Terminal to do much about detecting something that might be intended to be followable or not. You can tell from the hover-underline whether it got all, too little, or too much of an intended one. That additional checking occurs only on attempting to use it makes the most sense to me. (I can't imagine how this works with respect to accessibility though.)
Author
Owner

@zadjii-msft commented on GitHub (Jul 19, 2021):

The regex we're currently using is here:
f68324cd09/src/cascadia/TerminalCore/Terminal.hpp (L23)

We've got more discussion over in #8321, so I'm gonna redirect this thread there

/dup #8321

@zadjii-msft commented on GitHub (Jul 19, 2021): The regex we're currently using is here: https://github.com/microsoft/terminal/blob/f68324cd099f2d76321f1889f8de504e67a7c797/src/cascadia/TerminalCore/Terminal.hpp#L23 We've got more discussion over in #8321, so I'm gonna redirect this thread there /dup #8321
Author
Owner

@ghost commented on GitHub (Jul 19, 2021):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Jul 19, 2021): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#14574