Suggestion: Larger Search Logos from OpenSearch XMLs

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
RealityRipple
Lunatic
Lunatic
Posts: 435
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by RealityRipple » 2021-09-10, 18:30

The OpenSearch spec suggests having both a 16x16 icon and 64x64 logo, and while most do not have the 64x64 image, it seems a shame not to make use of the ones that do for about:home and about:newTab. It would also be unreasonable to expect an extensive list of service icons to be included in the already bulky SEARCH_ENGINES constant. I'd like to suggest something along the lines of these changes (plus a small change to UXP to save icons besides the 16x16 default), allowing the logos used for larger, in-content search boxes to be pulled from the provided XML, if available. For the example, I simply went through some standard sizes (32, 48, 64, 96, and 128), but technically you could just iterate through every number between 24 and 256, or whatever you want, to find a decent-resolution icon to use (although that might cause excessive function-calling and annoying delays; I haven't tested that method), or specifically check for 64 alone. This change could also let you slowly move the icons from the SEARCH_ENGINES constant to the default engines' defining XMLs and phase out the use of the constant, or keep them as-is, at your discretion. Of course, which one takes precedence is also at your discretion.

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 435
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by RealityRipple » 2021-09-12, 16:15

I've been thinking about the "retained sizes" list... Noticing a bunch of websites provide a 40x40 icon... Maybe the best option would be a loop with an iteration step size of -8; from 96 to 24... or maybe 128. I figure 96 is a good idea in case of 3x "retina" style displays, but 128 is probably a more common icon size and easily shrinks down to 96 in a pinch. I'll leave the code as-is for now, but a better selection than the 5 constants listed in the existing array should definitely be used for the final version, assuming it ever comes to pass. Hopefully no icon, even a 128x128 one, is gonna touch the self-described "arbitrary" 10,000 byte maximum.

I also noticed a lot of the existing default search engine icons include 32x32 versions within the icon data... I don't know if there's existing code to read multiple sizes from an ICO file, but it'd be another useful bit to be able to extract and save the different icon sizes as new <Image> entries as part of this code... I split them up by hand here, for now. It's too bad the spec says to use ICO for the 16x16, since PNG would be a lot smaller, as the CreativeCommons icon (which actually was a PNG) demonstrates.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 30914
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by Moonchild » 2021-09-13, 12:31

There are a few issues here:
  1. I see no reason to store a search engine image in x number of different formats. If the spec says 16x16 and 64x64 that that should be all that's needed.
  2. There's also an issue with directly using a URL as regards the icon to use. You cannot use remote content that way in the UI or privileged content in a safe way so it will have to be run through the serializer first, saved to disk, then using the deserialized version that has been sanitized.
  3. I disagree with splitting images out from ico files separately as png like you've done. ico files are a multi-resolution file format and we have internal APIs to extract various resolutions from an ICO already. Use it.
In addition, making an argument over a 16x16 icon's encoding? Really, it doesn't matter at that resolution.
RealityRipple wrote:
2021-09-10, 18:30
It would also be unreasonable to expect an extensive list of service icons to be included in the already bulky SEARCH_ENGINES constant.
I have no intention to do so. Only those included with our release out of the box will go in there.
RealityRipple wrote:
2021-09-12, 16:15
is gonna touch the self-described "arbitrary" 10,000 byte maximum.
I know I upped that to 32768 years ago, but I guess it's one of those changes that slipped through the cracks when moving to UXP actually this happened when importing the modified gecko/44 search into the toolkit. Thanks for pointing that out.
"Just because you know something is going to break in the end, doesn't mean that it can't have an effect that lasts into the future. Joy. Wonder. Laughter. Hope. The world can be better because of what you built in the past." -- Tom Scott
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 435
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by RealityRipple » 2021-09-13, 16:37

I tested using direct URLs, you already seem to have something to convert it to base64 during the import process, which was really neat! Edit: If the default icon (16x16) is loaded first, it skips base64-ing any further icons. Changing to allow additional icons to be base64'd and stored if they're not data: URIs. By default, I'm just gonna use image/png for data:'s MIME type, but technically I could run it through loadImageXPCOM to get the actual MIME type, at a slight resource expense. Since it doesn't really matter what the MIME type is set to, though, I skipped it.

Storing the other sizes is mostly about being able to get whatever size third-party search engines provide. I could make the import process select only one specifically, and try to aim for whatever's closest to 64x64 though?
Last edited by RealityRipple on 2021-09-13, 21:44, edited 2 times in total.

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10538
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by New Tobin Paradigm » 2021-09-13, 17:43

I see no reason to redefine the spec. Though it has fallen largely out of favor it is still long standing, valid, and in use.
Of course, all these failures mount up and could easily end up costing more collectively than paying a proper rage would.
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 435
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by RealityRipple » 2021-09-13, 18:13

Right-o. Saving 16x16 and 64x64 only, then. Searching for other sizes inside the 16x16 ICO after import will have to do for finding other possible sizes.

I'm looking through all the info I can find on nsICODecoder, imgILoader, and all that fun stuff, but I'm still not sure how to effectively split up an ICO file... Most of it seems more related to animated images. Just not sure how to decode an icon an get its ICONDIRS list from JS. The ol' #-moz-resolution feature seems to have been removed some time ago; I was hoping to look at its source code to see what the right way was. Seems imgIDecoder was also removed. Any pointers in the right direction here?

Looks like the way to access most the ico stuff might not be JS-accessible. For now, I'm loading the 16x16 ICO and checking its "actual" size, and if it's 32x32 or greater, I'm passing it along as a Promise (because loadImageXPCOM is often asynchronous). This required a few little changes, like checking for "searchEngineLogo" attribute mutations, but it works nicely. If loadImageXPCOM reliably loads larger sizes from ICO files, keeping things this way might end up being more efficient than stepping through each size.


Just to put the branch links in one place: UXP Changes & Pale Moon Changes.
Last edited by RealityRipple on 2021-09-14, 03:52, edited 10 times in total.

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10538
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by New Tobin Paradigm » 2021-09-13, 18:40

No. Just stop.
Of course, all these failures mount up and could easily end up costing more collectively than paying a proper rage would.
Image


User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10538
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Suggestion: Larger Search Logos from OpenSearch XMLs

Unread post by New Tobin Paradigm » 2021-09-15, 03:28

Did I not say no?
Of course, all these failures mount up and could easily end up costing more collectively than paying a proper rage would.
Image

Post Reply