Open onionhammer opened 9 months ago
Good call on the colorization. I bet that's the cause here. Out of curiosity, does the URL detection work for VITE output in plain windows terminal? We more or less match what they do for detection, though we might be doing it at a different stage of the pipeline that has different ultimate effect...
does the URL detection work for VITE output in plain windows terminal
Yes, it works in VS Code terminal as well
Interesting. We'll have to see if we can re-layer that logic (url detection and ANSI-to-CSS are basically two of several steps in the log processing). Good find! We'll take a look.
I am unable to recreate this issue in the latest main
.
I have tried looking at the logs with urls in them and I have tried the following tests:
[Theory]
[InlineData("No urls", "No urls")]
[InlineData("Named https url: https://some-page.com/", "Named https url: <a target=\"_blank\" href=\"https://some-page.com/\">https://some-page.com/</a>")]
[InlineData("Named http url: http://some-page.com/", "Named http url: <a target=\"_blank\" href=\"http://some-page.com/\">http://some-page.com/</a>")]
[InlineData("IP https url: https://0.0.0.0/", "IP https url: <a target=\"_blank\" href=\"https://0.0.0.0/\">https://0.0.0.0/</a>")]
[InlineData("IP https url: http://0.0.0.0/", "IP https url: <a target=\"_blank\" href=\"http://0.0.0.0/\">http://0.0.0.0/</a>")]
[InlineData("Named https url with port: https://some-page.com:5173/", "Named https url with port: <a target=\"_blank\" href=\"https://some-page.com:5173/\">https://some-page.com:5173/</a>")]
[InlineData("Named http url with port: http://some-page.com:5173/", "Named http url with port: <a target=\"_blank\" href=\"http://some-page.com:5173/\">http://some-page.com:5173/</a>")]
[InlineData("IP https url with port: https://0.0.0.0:5173/", "IP https url with port: <a target=\"_blank\" href=\"https://0.0.0.0:5173/\">https://0.0.0.0:5173/</a>")]
[InlineData("IP http url with port: http://0.0.0.0:5173/", "IP http url with port: <a target=\"_blank\" href=\"http://0.0.0.0:5173/\">http://0.0.0.0:5173/</a>")]
[InlineData("Named https url: https://some-page.com", "Named https url: <a target=\"_blank\" href=\"https://some-page.com\">https://some-page.com</a>")]
[InlineData("Named http url: http://some-page.com", "Named http url: <a target=\"_blank\" href=\"http://some-page.com\">http://some-page.com</a>")]
[InlineData("IP https url: https://0.0.0.0", "IP https url: <a target=\"_blank\" href=\"https://0.0.0.0\">https://0.0.0.0</a>")]
[InlineData("IP https url: http://0.0.0.0", "IP https url: <a target=\"_blank\" href=\"http://0.0.0.0\">http://0.0.0.0</a>")]
[InlineData("Named https url with port: https://some-page.com:5173", "Named https url with port: <a target=\"_blank\" href=\"https://some-page.com:5173\">https://some-page.com:5173</a>")]
[InlineData("Named http url with port: http://some-page.com:5173", "Named http url with port: <a target=\"_blank\" href=\"http://some-page.com:5173\">http://some-page.com:5173</a>")]
[InlineData("IP https url with port: https://0.0.0.0:5173", "IP https url with port: <a target=\"_blank\" href=\"https://0.0.0.0:5173\">https://0.0.0.0:5173</a>")]
[InlineData("IP http url with port: http://0.0.0.0:5173", "IP http url with port: <a target=\"_blank\" href=\"http://0.0.0.0:5173\">http://0.0.0.0:5173</a>")]
public void CreateLogEntry_LinkDetectionParsesFullUrls(string input, string expectedOutput)
{
var logParser = new LogParser(false);
var logEntry = logParser.CreateLogEntry(input, false);
var output = logEntry.Content;
Assert.Equal(expectedOutput, output);
}
In all tests, LogParser
correctly parses the full url and generates a link.
If wanted, I can submit a pr adding this test Aspire.Dashboard.Tests
.
In either case, I am convinced the issue has been resolved.
Edit:
The tests tries to validate LogParser
as a whole. UrlParser
is already well tested.
I don't think we've done anything to address the issue. The tests above wouldn't catch the problem. The issue (based on the info provided by the OP) is that VITE passes ANSI control codes to colorize the port number (and the colon and forward slash chars). So the text coming across in the logs to generate the URL in the OP's image (just the URL, ignoring the arrow and other text on that line) would be something like http://localhost\x1B[94m:\x1B[96m5173x1B[94m/x1B[0m
.
We would need to do something such that the URL parsing can ignore the ANSI codes, or some other way to orchestrate both changes.
What would be the preferred way to parse http://localhost\x1B[94m:\x1B[96m5173x1B[94m/x1B[0m
:
<a target="_blank" href="http://localhost:5173/">http://localhost:5173/</a>
<a target="_blank" href="http://localhost:5173/">http://localhost\x1B[94m:\x1B[96m5173x1B[94m/x1B[0m</a>
href
.Also, would it be ok if I made AnsiParser.IsControlSequence
and AnsiParser.EscaoeChar
public
to reuse them in UrlParser
?
Edit: I realize UrlParser
will receive the ANSI sequences as <span>...</span>
due to the AnsiParser
running first.
@tlmii
I have made a pr changing UrlParser
to remove xml tags when parsing an URL.
I would love some input.
I think a true fix here is relatively large.
The stress playground project I added recently includes some examples of URLs mixed with colors. If the ApiService is started directly then you can see terminals detects the URLs mixed with colors:
I think the log parser needs to be completely redesigned to:
I think there is too much here to recommend the issue for a contributor.
@JamesNK - if this is a bigger change from a risk perspective, we would like to consider it post GA -please let me know if you have any concerns.
Punting this to 8.1
When I hover over the URL, it excludes the port, etc.
This may have to do with colored port numbers vite spits out.