I made a website that offers a minimalistic UI approach to automatically view e621 artwork like a slideshow!

Why?

I wanted to have a simple "slideshow" that fetches new images so that I could run it on a second monitor while doing other activities. I didn't want any UI elements obscuring the artwork, so I created the project "e621AutoViewer" with the aim of having as little UI as possible. (I also wanted a neat little project to learn javascript with)

Features

- Global Search Tags and Blacklist/Whitelist
- Presets that can be saved for different search queries
- Quick download button for images
- Quick source button for images
- Go back in History for the current session
- Pause/Unpause
- Mobile and Desktop support

Links

Project in Action: https://e621autoviewer.leithey.com/
Source Code: https://github.com/Leithey/e621AutoViewer/

Notes

Videos (.mp4) not yet supported.
Default Global Blacklist and Default Presets include tags of my own choice. Make sure to clear the Global Settings if you want a pure experience or one more to your own preference.
More features to come in the future.
Feel free to forward me tag combinations to include in the default presets of my website.

Awesome! Thanks! Doesn't seem to work in Firefox (no images display), but it works fine in Chrome.

crocogator said:
Awesome! Thanks! Doesn't seem to work in Firefox (no images display), but it works fine in Chrome.

I see the same in Firefox (desktop, Linux 64-bit) - no images.

Looking at Firefox's web developer console, when hitting right-arrow (desktop) to load a new image, I get two errors.

First error:

Method: Options
Initiator: Fetch
Type: Plain
Transferred: CORS Missing Allow Header
URL: https://e621.net/posts.json/?tags=%20order:random%20score:%3E500&limit=10

Second error:

Method: Get
Initiator: script.js:152
Transferred: NS_ERROR_DOM_BAD_URI
URL: https://e621.net/posts.json/?tags=%20order:random%20score:%3E500&limit=10

For the first error, I have the impression that Firefox is a little more strict about accepting random requests to "foreign" sites than Chrome is. I can't explain it better than that, but maybe Mozilla can.

For the second error, I would suggest that if the tags parameter is blank, maybe don't submit it.

Also, I'm not *sure* about this, but you *might* need something like an & in the URL to append the parameters, rather than a space. Like, say, ?tags=wolf&order:random&score:>500&limit=10.

edit: spelling

kora_viridian said:
Also, I'm not *sure* about this, but you *might* need something like an & in the URL to append the parameters, rather than a space. Like, say, ?tags=wolf&order:random&score:>500&limit=10.

is correct, if you open the URL in your browser it works. An & would break the query parsing.

crocogator said:
Awesome! Thanks! Doesn't seem to work in Firefox (no images display), but it works fine in Chrome.

Thank you for telling me. I don't use Firefox so I didn't think of testing it there. I fixed it and it should work in Firefox now :)

kora_viridian said:
I see the same in Firefox (desktop, Linux 64-bit) - no images.

Looking at Firefox's web developer console, when hitting right-arrow (desktop) to load a new image, I get two errors.

Error is fixed, and thanks for the info!

definitelynotafurry4 said:
%20 is correct, if you open the URL in your browser it works. An & would break the query parsing.

I swapped the spaces in the URL with %20 now, thank you for the tip!

theleithey said:
I swapped the spaces in the URL with %20 now, thank you for the tip!

Technically speaking, you should probably use encodeURIComponent(tagString) which will properly encode other things that might break it as well, for example the tag m&m's will break your script as the & is inserted in plain text and breaks the parsing on the e6 side.

Or, since I see you're using Object.entries(params) to map the params, I'd use the built-in URLSearchParams which will do all of this for you

So I'd personally change

const queryParams = Object.entries(params)
    .map(([key, value]) => {
        if (key === "tags" && Array.isArray(value)) {
            return `${key}=${value.join('%20')}`; // Join tags with spaces
        } else {
            return `${key}=${encodeURIComponent(value)}`;
        }
    })
    .join('&');

to

const queryParams = new URLSearchParams(params).toString()

This little one-liner does everything you're doing there on the params, but easily. It would return tags=tag1%20tag2%20etc&limit=10, which based on your code is exactly what you need and should be a drop-in replacement, but I'd test it first. Mainly with tags that have + or & in them as those can break search params, but I think it should handle both.

definitelynotafurry4 said:
Technically speaking, you should probably use encodeURIComponent(tagString) which will properly encode other things that might break it as well, for example the tag m&m's will break your script as the & is inserted in plain text and breaks the parsing on the e6 side.

Or, since I see you're using Object.entries(params) to map the params, I'd use the built-in URLSearchParams which will do all of this for you

So I'd personally change

const queryParams = Object.entries(params)
    .map(([key, value]) => {
        if (key === "tags" && Array.isArray(value)) {
            return `${key}=${value.join('%20')}`; // Join tags with spaces
        } else {
            return `${key}=${encodeURIComponent(value)}`;
        }
    })
    .join('&');

to

const queryParams = new URLSearchParams(params).toString()

This little one-liner does everything you're doing there on the params, but easily. It would return tags=tag1%20tag2%20etc&limit=10, which based on your code is exactly what you need and should be a drop-in replacement, but I'd test it first. Mainly with tags that have + or & in them as those can break search params, but I think it should handle both.

That's a really neat function! I had to modify my params a little, but I successfully implemented it with URLSearchParams and I can confirm that m&m's works now. Here's hoping I won't need to use that tag ever again!

theleithey said:
Here's hoping I won't need to use that tag ever again!

I am sorry lmao

theleithey said:
Error is fixed, and thanks for the info!

I tried it again and it works now. :) Same desktop Firefox version as before.

I noticed a couple of other things. There is a "stray" bit of HTML after the </html> tag: <template id="presetsettingspanel"> </template>. To see this, view source on your site while it is displaying an image. It doesn't seem to affect anything, but I figured I'd note it.

The other thing I noticed, is that if you set up the tags on your site such that it gets zero results when it queries e621, it just keeps repeating the query to e621 about once a second. This doesn't present an error to the user - the user just doesn't see any images - but e621 might eventually object to the hits to their API.

To reproduce (at least in Firefox), open the web developer console and switch to the "Network" tab. In the main browser window, go to your site. Click on the gear icon on your site, go to the Global Settings tab, put a tag that has zero hits on e621 into the "Search Tags" box (such as fortran), and hit "save". Look at the network activity in the web developer console - you will see the same query to e621 being repeated about once a second.

(For me, Firefox reports "cached" for the repeated queries in the dev console. However, I also ran Wireshark while the repeated queries were happening, and it showed repeated TCP packets from my machine to e621 and back, about once a second. As soon as I closed the browser tab with your site in it, the repeated packets stopped.)

A possible fix might be that if your site's query gets 0 hits from e621, you stop querying, and tell the user something like "No images found. Try adjusting your tags, whitelist, blacklist, or the global parameters", and give them a button/link that will open up the settings screen so they can do that.

Here's hoping I won't need to use that tag ever again!

You will. :D

Free advice: keep a short list of "tags that might be a problem" and test against them when you make changes. A lot of these will be tags with weird characters in the name, like DefinitelyNotAFurry first brought up. It also can be tags that return a zillion hits (like anthro), tags that return a very small, but non-zero, number of hits (like imminent_fish_insertion), and tags that have no hits at all (like fortran).

The zillion-hits one can show you if you're potentially going to allocate an array that will take 926 gigabytes of RAM (although e621 is pretty good at limiting how much stuff you get back from the API). The small-hits one helps quickly show that it basically works - it doesn't take nearly 3 hours to make sure your site loads all 9,900 hits for wolf score:>500. The zero-hits one makes sure you don't crash or do something silly if you're expecting something to never be null/zero-length... as noted above. <_<

Don't forget to run the tests on both browsers you now support - this is way better than it used to be, but there are still a few differences between Chrome (in all its works and all its ways) and Firefox. There may even be a few critters using Safari. (Iron mode: check the User-Agent strings in your web server log, and/or turn on any analytics offered by your web host, to see which browsers are popular at your site.)

kora_viridian said:
I tried it again and it works now. :) Same desktop Firefox version as before.

I noticed a couple of other things. There is a "stray" bit of HTML after the </html> tag: <template id="presetsettingspanel"> </template>. To see this, view source on your site while it is displaying an image. It doesn't seem to affect anything, but I figured I'd note it.

The other thing I noticed, is that if you set up the tags on your site such that it gets zero results when it queries e621, it just keeps repeating the query to e621 about once a second. This doesn't present an error to the user - the user just doesn't see any images - but e621 might eventually object to the hits to their API.

Thank you! I've removed the stray bit of HTML and added Error handling when e621 returns 0 images. And thank you a lot for the advice, very valuable indeed :3

theleithey said:
Thank you! I've removed the stray bit of HTML

I see the Git commit where that happened... but the HTML on your site still seems to have the stray template tag. I tried force-reloading the page and the stray tag is still there.

Did the latest HTML get copied from Git to the site? <_<

(If it's true that the latest HTML didn't get copied... that will happen again, too. :D )

and added Error handling when e621 returns 0 images.

I can confirm that this works for me now. :) If I enter a tag on your site that doesn't get any results, I don't see any repeated queries over the network to e621 - just the initial query that returns 0 results. Also, where the image should be, I see white text on a black background saying No images found! Try other search tags....

kora_viridian said:
I see the Git commit where that happened... but the HTML on your site still seems to have the stray template tag. I tried force-reloading the page and the stray tag is still there.

Did the latest HTML get copied from Git to the site? <_<

(If it's true that the latest HTML didn't get copied... that will happen again, too. :D )

I can confirm that this works for me now. :) If I enter a tag on your site that doesn't get any results, I don't see any repeated queries over the network to e621 - just the initial query that returns 0 results. Also, where the image should be, I see white text on a black background saying No images found! Try other search tags....

I forgot to upload it to the website, you are right. Fixed.

Glad to hear that the no results message works as intended. I know of one case where it will still repeat like previously, which is when the client sided blacklist or whitelist filters out all found images. I have it on my radar to fix at some point though x3

theleithey said:
I forgot to upload it to the website, you are right. Fixed.

Looks good now!

More trivia:

For complex projects, sometimes you have a version number somewhere in the source that ends up being user-visible somehow. The simplest way is just to have a static text string like 1.1 in the source that you display on the settings box, or at the very bottom of the page, or whatever. That way, you can get some assurance that the version you're actually running is the same version you just applied a fix to.

You have to remember to religiously update that string when you change anything, which can sometimes be hard to do. Otherwise, you end up asking yourself things like "is this the old version 1.2 before I fixed the menu, or the new version 1.2 after I fixed the menu?"

(Back when we used to write native applications, the 1.1-style version number got displayed on the "Help > About" screen in a GUI, or got printed out when you said something like foobar.exe /V or foobar --version on the command line.)

For projects that are stored in Git or similar, sometimes the build process asks Git for the ID of the commit is is building, and then puts that ID in a user-visible spot when it creates the production code. Weasyl does this - look at the very bottom of the page, right before the copyright statement - that's the ID of its latest commit.

I have it on my radar to fix at some point though x3

Write yourself an issue on Github! :D