On some IRC networks, users have vanity host masks with colors or other text styling.
Rizon is one such network.
For example, a user connecting from 127.0.0.1 could instead have the host
angerson@this.is.my.host.mask. this.is.my.host.mask may have IRC color code
characters in it, which without this change would be displayed as a bunch of jumbled
garbage in the /whois response or join/part messages.
Resolves#4232.
Because the "Username" components still had the same ":key" vue tried to in-place update them. This doesn't quite work for objects (in this case "user" or "user.original"). Thus we change the key for the search so that it actually inits a new component and thus evaluates its content correctly.
Tested on latest Chromium / Firefox. In case of .m4a files they want audio/x-m4a and not audio/m4a, in case of .flac files they want audio/flac and not audio/x-flac. The module we useed to detect the types however detects them only as audio/x-m4a and audio/x-flac as they are not offical IANA supported mime types (not in IANA spec == "x-" prefix): https://www.iana.org/assignments/media-types/media-types.xhtml Though flac is not in the IANA spec many programs such as the file command (https://man7.org/linux/man-pages/man1/file.1.html) and Chromium (flac) / Firefox (x-flac and flac) support audio/flac only or both.
We need to remove the metadata without breaking the animation.
For that we use sharp which incooperates libvips (binaries for most common distros included).
This also decreases client side upload complexity as we remove the metadata on the serverside.
Sharp: https://sharp.pixelplumbing.com/
libvips: https://libvips.github.io/libvips/
- Highlight both channel and search query
- By moving search query to topic we can ensure nice behaviour for long search queries (eg. when searching for an url)
A search term is dynamic and not a pointer to a resource such as a channel as such it should be a query.
For now the network as well as the channels are still in the path even though we should take them out of there as well (in the case we want a global / network search later on). As for now we can keep in as there is no such filter / facet yet.
If we have no message provider:
- Search input field not renderd
- Search endpoint retuns empty resultset
Also removed redundancy by setting a main message provider.
Browsers often autocomplete into wrong fields. Eg. wanting to put the password in a fields in the settings screen and then use a sudo random other fields for username etc.
This is rather annoying and can break someones configuration, thus we should only enable it on fields where it somewhat makes sense (name, server & password fields).
By default we take the slug given in the request, if this is not set we try to give a filename from known types.
If we still have no filename we fallback to the previous method of setting no filename.
If the filename is non ascii we will only create the encoded "filename*" and not the ascii only "filename". This is to prevent other applications to save a file like "?????.png" if the filename contains non ascii chars.
For the browsers nothing will really change comapred to the behaviour before this change as good fallbacks if no content-disposition filename is set. But that is not the case for all application, thus it makes sense to include the proper way to set the filename.
