-
Notifications
You must be signed in to change notification settings - Fork 1k
feat(chatlog): Add custom web handler as hyperlink #6645
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine
Codecov Report
@@ Coverage Diff @@
## master #6645 +/- ##
=======================================
Coverage 12.08% 12.09%
=======================================
Files 308 308
Lines 20898 20899 +1
=======================================
+ Hits 2526 2527 +1
Misses 18372 18372
Continue to review full report at Codecov.
|
@dvn0 please add at least one positive and possibly one negative test case to: https://github.com/qTox/qTox/blob/master/test/chatlog/textformatter_test.cpp |
Probably not going to get around to making tests anytime soon, unfortunately. Sorry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 LGTMs obtained
a discussion (no related file):
My understanding of web+ scheme is that a website asks a web browser to ask a user to register the mapping from a web+<> to a web URL. I don't really see where qTox comes in to this - with qTox having no way to register web+ URIs to http(s) URLs, won't a link clicked in qTox just fail to open without ever getting to the web browser to resolve the mapping, even if it exists there?
Have you seen this work with a website that registers a web+ URI? Testing myself by adding a registration in firefox's console makes it so that those links in the browser then prompt to open the link with the registered URL, but from qTox I just get "gio: The specified location is not supported" and similar from command line.
Additionally firefox' general settings under applications shows the new link registration, but gnome's "default applications" is unchanged.
@anthonybilinski - sounds like it doesn't work in your environment, but for me, if I open firefox from the command line with a registered |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: 0 of 1 LGTMs obtained
a discussion (no related file):
Previously, anthonybilinski (Anthony Bilinski) wrote…
My understanding of web+ scheme is that a website asks a web browser to ask a user to register the mapping from a web+<> to a web URL. I don't really see where qTox comes in to this - with qTox having no way to register web+ URIs to http(s) URLs, won't a link clicked in qTox just fail to open without ever getting to the web browser to resolve the mapping, even if it exists there?
Have you seen this work with a website that registers a web+ URI? Testing myself by adding a registration in firefox's console makes it so that those links in the browser then prompt to open the link with the registered URL, but from qTox I just get "gio: The specified location is not supported" and similar from command line.
Additionally firefox' general settings under applications shows the new link registration, but gnome's "default applications" is unchanged.
Ah I see, thanks for the explanation. Firefox opened with web+[...]: works for me as well, but the piece my environment is missing is the web+[...] -> Firefox link. With that, I can see how qTox would dispatch the link properly and have no issue with this conceptually. Creating that link seems outside of qTox's scope, so not really something we need to worry about. Creating the links in chat still seems reasonable for us to do.
src/chatlog/textformatter.cpp
line 96 at r1 (raw file):
QRegularExpression(QStringLiteral(R"((?<=^|\s)\S*(gemini://\S+))")), QRegularExpression(QStringLiteral(R"((?<=^|\s)\S*(ed2k://\|file\|\S+))")), QRegularExpression(QStringLiteral(R"((?<=^|\s)\S*(web+\S+:\S+))")),
I believe not including an argument in the link is valid in the spec, and is accepted by Firefox testing, i.e. both "web+burger:" as well as "web+burger:foo" are valid. If you agree, the regex is overly restrictive, and the last \S+ could be changed to \S*.
Adds support for custom web scheme handlers. See MDN docs for more info.
This change is