[X] My Assistant

In case that you are on a mobile device (or the site thinks you are on a phone), you can fiddle with the Viewport Override value to get everything re-appear. I use 1020 px myself, but I donno if that's the optimal value for everyone.

Would it be possible to add a toggle in the settings to put the thumbnail selectors back where they used to be?

I understand this might be a bit niche but I used them a lot, going back and forth constantly between small thumbnails when I wanted ovesight (easier to count presence on large galleries, especially those without panels) and large ones if I wanted detail (easier for counting % presence on shorter doujinshi/manga/comics) or trying to do stuff on mobile, depending on what kind of gallery I was tagging.

2023-10-27
When browsing on mobile, the system will now default to using 780x resamples instead of 1280x ones if the browsing resolution is set to "Auto".

I primarily browse e-hentai on mobile, and although the rest of the update is pretty good, I severely dislike this change to make resamples smaller by default on mobile. It makes the image samples needlessly small and blurry. By any chance, would you please consider reverting it back to 1280x by default instead of 780x by default?

The good news is that since I set my settings to be 1280x instead of auto, samples are back to their old size, and so far it seems like settings to my account are saved and automatically applied when I logged in. But this negatively affects mobile lurkers without an account, and I don't see the upside to making the samples so blurry.

Despite my dislike for the mobile samples change, I want to end on a positive note and give a massive thanks to this change, because this one is a massive timesaver:

"Download Original" button will no longer pop up a download dialog, instead it will open the full image directly.

This post has been edited by Flyra: Oct 29 2023, 04:16

Would it be possible to add a toggle in the settings to put the thumbnail selectors back where they used to be?

I'll consider it if there are other regulars who found it genuinely useful.

I primarily browse e-hentai on mobile, and although the rest of the update is pretty good, I severely dislike this change to make resamples smaller by default on mobile. It makes the image samples needlessly small and blurry. By any chance, would you please consider reverting it back to 1280x by default instead of 780x by default?

The change was made due to UI scaling, and I'm not planning on reverting it. People can choose 1280x manually if they want it.

I'll consider it if there are other regulars who found it genuinely useful.

I would also like it back as Glovelove. suggested.

yea i used it from time to time

- The "Download Original" button will no longer pop up a download dialog, instead it will open the full image directly. Mostly because H@H doesn't support doing the former, but also because it's been a somewhat frequent usability request. If you want the download dialog, do a right-click then "Save link as".

I noticed that if you open the full image and then drag & drop it onto a Windows folder, it loses its filename and defaults to "fullimg.jpg". Is it possible to fix that?

I noticed that if you open the full image and then drag & drop it onto a Windows folder, it loses its filename and defaults to "fullimg.jpg". Is it possible to fix that?

That sounds like a quirk with whatever browser you are using, it keeps the filename for me both in Firefox and Chrome.

That sounds like a quirk with whatever browser you are using, it keeps the filename for me both in Firefox and Chrome.

Okay, that's very strange. I am using FireFox and... I can't begin to imagine what causes it. It even happens on Private Browsing with all extensions disabled.

PS: In every other site it works as normal, if you are curious. That's how I've been downloading pictures from Hentai Foundry, Pixiv and the various Rule34/booru sites for 15+ years now. It only started happening in this newest version of the EH galleries.

This post has been edited by eleeinos: Oct 29 2023, 23:22

I noticed that if you open the full image and then drag & drop it onto a Windows folder, it loses its filename and defaults to "fullimg.jpg". Is it possible to fix that?

Same here. Using Firefox (119.0 and 64-Bit). I also tried it with the Troubleshoot Mode (add-ons and extensions disabled) and I always get a fullimg.jpg file. Tried it .... on both, the light and dark themed (of course, only the skin is different!!1) site.

But if I use Chrome (118.0.5993.118), I get the image with the actual file name like it's uploaded on e-hentai.

This post has been edited by Waitugreat: Oct 29 2023, 23:22

Okay, that's very strange. I am using FireFox and... I can't begin to imagine what causes it. It even happens on Private Browsing with all extensions disabled.

PS: In every other site it works as normal, if you are curious. That's how I've been downloading pictures from Hentai Foundry, Pixiv and the various Rule34/booru sites for 15+ years now. It only started happening in this newest version of the EH galleries.

Same here. Using Firefox (119.0 and 64-Bit). I also tried it with the Troubleshoot Mode (add-ons and extensions disabled) and I always get a fullimg.jpg file. Tried it .... on both, the light and dark themed (of course, only the skin is different!!1) site.

I can't reproduce it, but if this started after HC ranges were added, I'm guessing it could have something to do with H@H not explicitly specifying the filename as a HTTP header, which the image servers do. Normally browsers should be able to derive the filename from the URL regardless of this header, which they do for me.

It would be easy enough to make H@H set the header in question, but that wouldn't actually have any effect until everyone updated to whatever version that would be.

Since 780x is now the default on mobile, I wonder if /lofi is going to be deprecated?

Since 780x is now the default on mobile, I wonder if /lofi is going to be deprecated?

Less than 1% of EH traffic is to lofi, so I wouldn't be too surprised if it disappears at some point if it needs major work to keep up with other site changes, but there are no concrete plans to get rid of it.

I'll consider it if there are other regulars who found it genuinely useful.

It was kind of useful for comparing galleries (expunging) (being able to quickly switch to small thumbs for an easier overview over a lot of pages).

Maybe feasible to let the nerds enable the thumb row + size buttons in the general settings?

- The "Download Original" button will no longer pop up a download dialog, instead it will open the full image directly. Mostly because H@H doesn't support doing the former, but also because it's been a somewhat frequent usability request. If you want the download dialog, do a right-click then "Save link as".

PS: If you still want a one-click Save As dialog, you can get it by alt-clicking the link in most browsers. Note that in Firefox, to enable this behavior you have to turn it on in about:config (browser.altClickSave).

You can never please everyone; I'm one of those people who really liked the automatic "Save As" dialog. Especially since I have things configured to skip the dialog here, so I just click it and poof it's downloaded. If I can use Alt-Click though then that's probably good enough.

...It's not working for me though. I set "altClickSave=true". With that, alt-clicking on the "download original" link in a normal gallery page downloads the image but saves it as "fullimg.php". It's indeed the image - running "file fullimg.php" spits out that it's a PNG. But the filename (and more importantly the extension) is wrong. Probably because the link itself is ".../fullimg.php?..." I guess.

But at least that downloads something. If I use the MPV then alt-clicking just navigates to the image itself, as if I didn't hold alt at all. In fact, if I right-click the download icon, it doesn't even give me the option to download the link - all I get are:

• Open Image in New Tab
• Save Image As...
• Copy Image
• Copy Image Link
• Email Image...

(Plus a couple random accessibility ones but whatever.) I assume this is because the download icon isn't an actual link - it's an "img" with an onclick, not an "a" with an href - so Firefox doesn't detect it as something you should be able to "download link" on. Hence alt-click doesn't do anything, since Firefox doesn't think it's valid. Maybe? Dunno. It's a guess.

...I think now the only way I can download the full image (in any viewer, normal or MPV) is to normal-click the image, navigate to it in the same tab, then right-click and save-as, then hit the back button to go back to the previous listing. Which is... not very fast or ideal for me, I guess. But I also assume that the kinks are being worked out, judging by the other people having "fullimg" issues, MPV acting different, etc.

...It's not working for me though. I set "altClickSave=true". With that, alt-clicking on the "download original" link in a normal gallery page downloads the image but saves it as "fullimg.php". It's indeed the image - running "file fullimg.php" spits out that it's a PNG. But the filename (and more importantly the extension) is wrong. Probably because the link itself is ".../fullimg.php?..." I guess.

It looks like this is an issue specifically with Firefox, H@H probably needs to set the name header to fix it. Which will take a lot of time to roll out a fix for, because a lot of people aren't very quick at updating.

(Plus a couple random accessibility ones but whatever.) I assume this is because the download icon isn't an actual link - it's an "img" with an onclick, not an "a" with an href - so Firefox doesn't detect it as something you should be able to "download link" on. Hence alt-click doesn't do anything, since Firefox doesn't think it's valid. Maybe? Dunno. It's a guess.

Hmm. Yeah, there's no real reason for why what link is an onclick, I'll change it to a regular link with the next update.

It looks like this is an issue specifically with Firefox, H@H probably needs to set the name header to fix it. Which will take a lot of time to roll out a fix for, because a lot of people aren't very quick at updating.

Probably a Firefox issue, yeah. Not sure if a name header would help though. Picking a random-ish gallery (front page, jump back a week, pick something arbitrarily on that list) gives me this (just in case some galleries show it and some don't): https://e-hentai.org/s/07c4e9b25e/2716469-1

If I alt-click the original link it downloads "fullimg.php". Doesn't show up in the network tab for whatever reason... Normal clicking does, however, show up in the tab, and shows this.

* GET for "https://e-hentai.org/fullimg.php?gid=2716469&page=1&key=xxxxxxxxxxx"
- 302 redirect to the real download location
- Its URL is "fullimg.php"
- Has no Content-Disposition (filename or otherwise) specified

* GET for "https://xxxxxxxx.hath.network/xxxxxxx/014_010_011_copy.png"
- 200, image data
- Its URL has the actual file name
- Has a Content-Disposition with the filename too (and inline instead of attachment)

I'm guessing that Firefox must make the decision for what to name the file prior to following the redirect. Either it decides on the filename before actually doing the first GET (ie before even knowing there would be a redirect), or after making the first fetch but before following the redirect. If it does the latter, then maybe setting a Content-Disposition on the 302 itself would maybe help? But if it's the former then I'm not sure any headers would matter. I suspect it's the former just based on some other quick poking around, but hard to know for sure.

(The old mechanism worked fine, since Firefox didn't know it wanted to save at all until it reached the final fetch. That one presumably had the Content-Disposition saying to save instead of display, as well as the filename. But here, using the Save Link As, we're telling Firefox to save much earlier in the process. Too early for its own good, apparently.)

Probably a Firefox issue, yeah. Not sure if a name header would help though. Picking a random-ish gallery (front page, jump back a week, pick something arbitrarily on that list) gives me this (just in case some galleries show it and some don't): https://e-hentai.org/s/07c4e9b25e/2716469-1

I'm guessing that Firefox must make the decision for what to name the file prior to following the redirect. Either it decides on the filename before actually doing the first GET (ie before even knowing there would be a redirect), or after making the first fetch but before following the redirect. If it does the latter, then maybe setting a Content-Disposition on the 302 itself would maybe help? But if it's the former then I'm not sure any headers would matter. I suspect it's the former just based on some other quick poking around, but hard to know for sure.

(The old mechanism worked fine, since Firefox didn't know it wanted to save at all until it reached the final fetch. That one presumably had the Content-Disposition saying to save instead of display, as well as the filename. But here, using the Save Link As, we're telling Firefox to save much earlier in the process. Too early for its own good, apparently.)

Hm. Well, if anything that makes it much easier. I tried to add a header to the redirect which did nothing, but running it through a server-side URL rewrite seems to do the trick - in other words, instead of linking to fullimg.php?xyz it'll just link to fullimg/xyz/filename.jpg instead.

I'll push a fix for this with the next update.

Would it be possible to add a toggle in the settings to put the thumbnail selectors back where they used to be?

You can find this under settings now. There were some minor changes made to it, and the smallest row option was left out for space reasons, so let me know if there are any issues with it.

I noticed that if you open the full image and then drag & drop it onto a Windows folder, it loses its filename and defaults to "fullimg.jpg". Is it possible to fix that?

Let me know if you're still seeing anything like this after today's update.

Thank you for the last tweeks. (IMG:[invalid] style_emoticons/default/wub.gif)