Saving images with spaces in the name replaces the spaces with %20

[tlaloc77]

So far I have noticed this on only one site. It began about 1 month ago. At first I thought they changed something on their server but no other browser I have access to does that. And it happens only for images, if I save a whole web page, the saved name does contain spaces.

Did I miss something?
Is this supposed to be a feature?
If so, is there a way to opt out of the change?
If not, you may want to know the site but it's NSFW so I wanted to ask first whether it's needed. (And please give me 24 hours to answer. I'll stay alert for about 30 minutes from now on, then I go to bed and "tomorrow" I have to work before I can check for answers.)

[Kris_88]

Are you sure there is actually a space in the image name? It is possible that the name actually contains "%20" (which can be encoded as %2520 in the URL) and not a space.

[tlaloc77]

Are you sure there is actually a space in the image name? It is possible that the name actually contains "%20" (which can be encoded as %2520 in the URL) and not a space.

Thanks for asking - I am not sure at all.

Indeed, image names look like
"6128142 - Jujutsu_Kaisen Misato_Kuroi Riko_Amanai sahagi_ta.jpg" -- as suggested by Libre Wolf (and Firefox ESR, Chromium and several Chromium-based browsers, e.g. Brave and Opera and even Konqueror) or
"6128142 - Jujutsu_Kaisen%20Misato_Kuroi%20Riko_Amanai%20sahagi_ta.jpg" -- as suggested by Pale Moon.*

You can see that the space right after the initial number and after the "-" are still spaces, this IMHO hints strongly towards the %20 coming from the server.

Which would mean that Pale Moon does a strictly correct thing and the others... well, do something... else, some automatic translation. But it were all blanks about a month ago, for Pale Moon too, and it still is for most others. (Dillo and Falkon suggest a completely different name.)

Now what - this is kinda a show stopper because (unless I change all "%20"s in the names by hand) I can't tell when I downloaded something already under the "same" name since now the same file has a different name. (The site is rule34.paheal.net but I STRONGLY suggest to install uBlockOrigin or some other ad-blocker or switch JS off before visiting it.)


*: Edit: I just discovered that Netsurf and Seamonkey show the "%20"s, too. So it's the server. Still, I'd like to have this automatic conversion. As an option!

[Kris_88]

The site is rule34.paheal.net but I STRONGLY suggest to install uBlockOrigin or some other ad-blocker or switch JS off before visiting it.

I see a message on this site: "Some images are temporarily broken due to server migration."

Indeed, the recommended file name comes from the server in the Content-Disposition header:
Content-Disposition = inline; filename="6128142 - Jujutsu_Kaisen%20Misato_Kuroi%20Riko_Amanai%20sahagi_ta.jpg"

There is an RFC regarding this header:
https://datatracker.ietf.org/doc/html/rfc6266#section-5

In general, it will be possible to figure out whether decoding is needed there and what exactly the browser does (or doesn’t do). Maybe later...

[Moonchild]

The fact that the file name has both escaped and unescaped spaces in it should give you a good hint that this is a server-side issue.
I don't see a reason to change Pale Moon's behaviour here - it is doing exactly what it is being told to do. In fact, the RFC clearly states (last bullet point of 4.3) that a quoted-string filename should not try to decode percent-encoded sequences (it calls it "erroneous" but notes some browsers do this!)

[Kris_88]

(it calls it "erroneous" but notes some browsers do this!)

It's here:
https://repo.palemoon.org/MoonchildProd ... s.js#L1044

Code: Select all

 if (fileName)
      return fileName;

If we do this it will work:

Code: Select all

    if (fileName) {
      // return fileName;
      
      var textToSubURI = Components.classes["@mozilla.org/intl/texttosuburi;1"]
                                   .getService(Components.interfaces.nsITextToSubURI);
      return validateFileName(textToSubURI.unEscapeURIForUI("UTF-8", fileName));
      // or maybe (charset || "UTF-8", fileName) ?
    }

I see, FF80 does something similar, but it uses the unEscapeURIForUI() function, which has different parameters than in UXP:

Code: Select all

    if (fileName) {
      return validateFileName(Services.textToSubURI.unEscapeURIForUI(fileName));
    }

Regardless of whether you want to call unEscapeURIForUI(), I think it is advisable to use at least validateFileName().

Example URL: https://r34i.paheal-cdn.net/1f/2d/1f2d6 ... 0afe0d97ff

[Moonchild]

If we do this it will work:

It's not supposed to "work"! For reasons why see appendix C.2 of that same RFC. We should stick to not percent-decoding file names because it's wrong.

[Kris_88]

It's not supposed to "work"!

Don't even know... although, I don't argue...
I remember on some site I came across these “%20” and they pretty much tired me...

[tlaloc77]

OK, I understand that keeping the "%20"s is the correct thing and most browsers fail here.

Period to that.

It also enables a server to mix %20 with real spaces within one filename. I'd consider this as an advantage.

Interestingly, only PM and some old browsers are doing the correct and recommended thing.

So I changed my mind about it, please don't change that behavior. (Except, maybe, as an option, for increased compatibility with other browsers. But this may come as an advantage for some special case that then could be handled by PM out-of-the-box and by the other browsers... not at all.)

I'll think about asking the Rule34 guys about the %20 in filenames but my hopes are low when only PM and some old browsers do the right thing and probably nobody but me even noticed this change. Putting this on the table for other browsers... they'd call me a madman: "You want us to change a convenient, if somewhat incorrect, behavior to something that would yield known bad results at at least one site??" But that's my problem.

Thank you guys. I learned something! Now I wish I could use that knowledge to promote PM but in this case, I better don't try. (Tbh, since convenience trumps correctness, I'll use Libre Wolf for that one site. Don't worry, Libre Wolf can't use legacy add-ons, so I'll stay with PM for most other sites.)

So I think we can close the case.

[Kris_88]

It is possible to make an add-on that solves this problem.
Although, it would probably be better to build decoding into the browser.

In any case, the browser does not allow "%" in the file name:
https://repo.palemoon.org/MoonchildProd ... r.cpp#L346

[Kris_88]

Actually, here is an add-on that solves this problem. I don't think it's necessary to post this little thing on the Pale Moon add-ons site. I hope that someday such functionality will be built into Pale Moon (probably with the ability to disable it).

[tlaloc77]

Well, problem solved. Thank you very much, Kris_88.

And solved in the best way possible I can easily disable it whenever I want.

...

Huh... I just tried a few... works like charm on all kinds of images but not on videos where LW still decodes the "%20" to " " (thereby not giving me an easy to show case to ask them about the %20). I unpacked the .xpi and looked at JS code. Seems very simple, so the method of determining the filename-to-be-used for videos must be a different one.

Anyway, this solves my problem well enough. Videos are rare on that site and the %-encoding is not used when saving videos from Invidious sites (Konqueror shows names with %-encoding in these cases but that that's something different.) The few cases that are now left, I can change by hand without being held up more than a little. That's much better than using LW unless I disable some of the built-in privacy-features.

So, Thank You VERY much! I really didn't expect to get a solution for PM.
Last question, out of curiosity: How did you find it? Initially I had no idea what to look for but even now, a quick DuckDuckGo'ing for "percent decode add-on" didn't result in anything useful.

[Kris_88]

the method of determining the filename-to-be-used for videos must be a different one.

If you can find a link to a video as an example, I'll try to figure it out.

How did you find it?

This is not a search result. I just made it this morning.

[tlaloc77]

If you can find a link to a video as an example, I'll try to figure it out.

Here's one, shows some blue-skinned ass sliding on a glass pane, least NSFW I could find within a few minutes: https://rule34.paheal.net/post/view/6134666
Right-clicking on the "click here" link right above the preview image and selecting "Save Link As..." offers the filename with "%20"s for downloading without starting the video first.

How did you find it?

This is not a search result. I just made it this morning.

WHEW! Feels like a Christmas present I didn't deserve My, I owe you!

[Kris_88]

Yes, there the determination of the file name takes a completely different path.
Okay, I'll look for it in my spare time, then I'll write the answer here.

[Kris_88]

The "Save link as" operation works completely differently. Adding filename decoding is quite simple if you modify the browser sources (or packaged resources). But I don't see a short and reliable way to decode a name using add-on. There are no suitable interception points and no direct access to the functions that need to be fixed. Therefore, I think it is better to leave it as is.

[Moonchild]

Thank you for trying! Sadly, not everyone can always get what they want.

[tlaloc77]

OK.

Thank you very much for trying and investigating.

It's not a big deal when the "problem" (of doing the correct thing) only persists for videos. It was a show stopper for images.