Smutkitty said:
Bug: Tags in blacklist aren't blacklisted (chrome/flashfox for android)
Expected behavior: Posts with tags in blacklist are blacklisted
Actual behavior: Posts with tags in blacklist show.
Steps to duplicate:
Use either chrome or flashfox
Have tags in blacklist
Search for blacklisted tag OR browse normally. Please note I have only used these two browsers so it is entirely possible this bug occurs in other browsers.

I don't have an Android device to test it with, but do you happen to know if you have javascript disabled in the settings? The blacklist requires it to be enabled in order to work and it can produce this behavior.

Super_Hornet said:
Receiving an action controller error when viewing posts in e926...

Something similar was happening a few hours ago on e621 and they just had to restart something. I've sent a message to them so hopefully it'll be fixed just as easily. In the meantime the only workaround is to either browse while not logged in or use e621. I'll let you know if I hear anything.

Chessax said:
While maybe not a bug report, I have been wondering how the site handles simultaneous tagging by different users (e.g. two users adding/removing different tags at the same time). I've heard that there have been some issues with this (e.g. by furrypickle and by NotMeNotYou in news 20150212) and I'm curious about what the status is concerning these issues?

I've currently been keeping my eyes on my tag history but due to aliases (e.g. gay -> male/male, straight -> male/female, oral_sex -> sex, etc.) it looks like I'm removing tags from every other post which makes it a little cumbersome (and boring) to keep track of changes. I generally try to follow my golden rule of less than three minutes between post request and tag update. Currently the only hurt I've stumbled across has been self inflicted. How much I should worry?

The tagging bug was fixed in this last set of updates, so you shouldn't have to worry.

From what I understand, the tags now merge the two edits instead of (old behavior) merely replacing one tag list with the newer tag list.

Dynamic image resize seems broken today. The largest image is showing. It used to resize them. Some work while others don't. I believe it started after the site came back up after all the 500/502 errors.

furballs_dc said:
Dynamic image resize seems broken today. The largest image is showing. It used to resize them. Some work while others don't. I believe it started after the site came back up after all the 500/502 errors.

The image resize feature was revamped in the updates, and it defaults to not resizing the image.

To fix it: Go into your settings, under "Image resize mode" change it from "Don't resize" to either of these:

• Dynamically resize: Loads full image, then the browser scales the image to fit the browser. (maximum quality)
• Show reduced samples: Loads an alternative smaller image until you click a button. (less bandwidth, faster performance)

parasprite said:
The image resize feature was revamped in the updates, and it defaults to not resizing the image.

To fix it: Go into your settings, under "Image resize mode" change it from "Don't resize" to either of these:

• Dynamically resize: Loads full image, then the browser scales the image to fit the browser. (maximum quality)
• Show reduced samples: Loads an alternative smaller image until you click a button. (less bandwidth, faster performance)

It was on Dynamically resize. Changed to others then back and still not working.

furballs_dc said:
It was on Dynamically resize. Changed to others then back and still not working.

Also cleared cache and restarted browser but not resizing all large images still.

furballs_dc said:
It was on Dynamically resize. Changed to others then back and still not working.

Oh, never mind. I see similar behavior on my iPad (except it changes when you scroll slightly). I've let Tony know.

Genjar said:
Something seems to be wrong with the tag histories...?
Toggling the columns hides the wrong ones. For instance, disabling 'Source' actually hides 'Tags'.

There's a fix already, it just hasn't been pushed yet.

TLDR: The new checkbox in the theme box pushed everything over slightly.

parasprite said:
The image resize feature was revamped in the updates, and it defaults to not resizing the image.

To fix it: Go into your settings, under "Image resize mode" change it from "Don't resize" to either of these:

• Dynamically resize: Loads full image, then the browser scales the image to fit the browser. (maximum quality)
• Show reduced samples: Loads an alternative smaller image until you click a button. (less bandwidth, faster performance)

I hope that wasn't the actual rationale for implementing it. Because, while it does make it easy for you to get the full image instantly, the 'dynamically resize' option at best has only a little more quality than the 'reduced samples' option, unless your window is capable of fitting 30%+ of the image's full size. Further, the quality of the 'dynamically resize' option cannot be improved by changes on e621's end, whereas 'reduced samples' is quite simple to improve the quality of.

<image-processing tech>

The reason why is that not all pixels contribute equally to the result, so multiplying the pixel count by N does not improve the quality of the downsampled (aka decimated) image by N, or even by sqrt(N). Because most decimation algorithms are unfair in this way, having more input pixels can even produce a worse-looking result.
If you've ever encountered the Photoshop practice of scaling down in 10% increments instead of straight to the final size, this is the main reason behind that.

This page in ImageWorsener's documentation explains the problem in detail. Being aware that browsers generally use a simple decimation algorithm based on either a triangle filter or box filter will help to give some context to understand it.

The 'reduced samples' option, OTOH, since it is statically generated, has the option of using whatever decimation method is deemed best to generate the small image. Imagemagick has a large selection of these, and ImageWorsener has a few more -- including the one that I consider to produce the most reliably high-quality results, 'pixel mixing'.

Also, the statically generated images can be rescaled with gamma-correction, while there is no browser that I know rescales images with gamma-correction. This page explains briefly the reasons gamma-correction is important, but in short: not having it means that your rescaled image tends to end up greyed out, too dark, colors mix in an 'unnatural' way, and fine details may be unduly sharpened or blurred.

</image-processing tech>

Yeah. I think it's a good change, I just hope that wasn't the rationale.

EDIT: BTW, if using NoScript, you need to permit dragonfru.it in order for the dynamic resize to work. Without permission, the image goes full size->correct size->full size when the page loads.

EDIT2: Not sure if this is a bug, but on my initial load of https://e621.net/post/show/630793 , the image was full size. When I reloaded, it fit itself properly to the window. (Yes, I checked that the option was set to Dynamic resize)

Added a new checkbox in the theme dropdown (and in the user settings) to ignore seasonal theme changes and always use your selected theme

I still had to change it from winter to none when I logged out and in (no cookies)

Does there need to be line breaks after headers?

Test

Test

Test

Test

Test

Test

Test

Test

Test

Test

Test

Test

parasprite said:
...
The tagging bug was fixed in this last set of updates, so you shouldn't have to worry.

From what I understand, the tags now merge the two edits instead of (old behavior) merely replacing one tag list with the newer tag list.

Ah, that's good to hear, there's nothing better than bug fixes!

savageorange said:
...
EDIT2: Not sure if this is a bug, but on my initial load of https://e621.net/post/show/630793 , the image was full size. When I reloaded, it fit itself properly to the window. (Yes, I checked that the option was set to Dynamic resize)

I've noticed that myself sometimes, not sure why.

Anyone having problems with the image resizing, please include what browser you're using :P

EDIT: I just found out our JS file hasn't been recompiled with the new scaling code yet, so hopefully everything will work properly once that's done.

Lance_Armstrong said:
I still had to change it from winter to none when I logged out and in (no cookies)

Does there need to be line breaks after headers?

Test

Test

Test

Test

Test

Test

Test

Test

Test

Test

Test

Test

█████████████████████████████████████████▓▓▓▓▒▒▒███████████████████████████
█████████████████████████████████████▓▓▓▓▓▓▓▓▓▓▒▒▒▒████████████████████████
██████████████▓▓▒░░░░░░░░░░░▓▓████▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒███████████████████████
███████████▓▒░░░░░░░░░░░░░░▒░▒▒▒█████▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓███████████████████████
█████████▓▒▒▒▒░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒████▓▓▓▓▓▓▓▓▓▓▓▓▓▓██████████████████████
████████▓▒▓▓█▓▒░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓████▓▓▓▓▓▓▓▓▓▓▓▒▒▓███████████████████
████████████▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓████▓▓▓▓▓▓▒▒░░░▒▓██████████████████
██████████▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓███████▓▓▒░─────░▓██████████████████
█████████▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▒░░░░░░░░░▒█▒░──────░▓██████████████████
█████████▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▒▒░░░░░░░▒▒▒░░░─────░░░▒▓██████████████████
███████████▓▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓█████████████████▓░────░▒░░▓███████████████████
███████████▓▒▒▒▒▒▒▒▒▓▓██▓▓▓█████▓▓▓▓▓██████████▒░──░▒░▒▓███████████████████
██████████▓▒▒▒▒▒▒▒▒▓██████████▓▓▓▓▓▓████████████▓▒▒▒░▒▓▓███████████████████
████████▓▓▒▒▒▒▒▓▓▒▓███████████▓▓▓▓▓███████████████▓░░▒▓▓▓▓▓████████████████
███████▓▒▒▒▒▓▓██▓▓▓████████████▓▓▓██████████▓███████▓▓███▓▓▓▓▓█████████████
████████▓▓▓▓▓███▓▓█████▓▓██████▓▓▓█████████▒░░▒▓▓████▓▓▓▓████▓▓▓▓▓█▓███████
███████████████▓▓▒▒▒▒▒▒░▒▓████▓▓▓█████████▓░────░▓███▒▒▒▓▓▓▓█████▓▓▓▓▓█████
███████████████▓▓▒░──────░▓███▓▓█████████▓░─────░▓██▓▓▓▓▓▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓██
█████████████████▓▒░──────░▒▓██████████▓▒░──────▒███▓████▓▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓
████████████████████▓▓▒░────░▒▓▓▓▓▓▓▓▓▒░───────░▒▓▓▒▓██████▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▓
███████████████████████▓▒───────░░░░───────────░▓▒▒▒▓█████████▓▓▓▓▓▓▓▓▓▓▓██
█████████████████████▓▓▒░──────────────────────░▓▒▒▒▓██████████████████████
█████████████████████▓▓▒░─────────────────────░▒▓▒▒▒▓██████████████████████
█████████████████████████▓▓▓▒▒▒▒░░────────────░▓▓▒▒▒▒▓█████████████████████
█████████████████████████████████▓░───────────▒▓▓▒▒▒▒▒█████████████████████
█████████████████████████████▓▓▓▓▓░──────────░▓▓▓▒▒▒▓▓▓████████████████████
█████████████████████████▓▓▒░───░▒▒▒░────────▒▓▓▒▒▒▓███████████████████████
█████████████████▓▓▓▓▓█▒▒░────────░▒▒▒──────░▒▓▓▒▒▒▓███████████████████████
████████████████▓▓░░▒▒░─────────────░▒▒░────▒▓▓▒▒▒▒▓███████████████████████
███████████████▓▒░░▒░───────░▒░░░─────▒▒░───▒▓▓▒▒▒▓████████████████████████
███████████████▓▒▒▒────────░▒▓▓▓▓▓▒▒░──────░▓▓▓▒▒▒▓████████████████████████
███████████████▓▓─────────░▒░──░░░▒▒▓▓▒░───▒▓▓▓▓▒▓█████████████████████████
██████████████▓▒─────────░▓▓────────░▒▒▒▒░░▓█▓▓█▓██████████████████████████

test.

██████████████▒──────────▒▓▒───────────░▒▒▒███▓████████████████████████████
█████████████▒░─────────░▓▓▒░───────────░▒█████████████████████████████████
████████████▓░────────░▒▓▓▒▒▓▒░──────────░▒████████████████████████████████
████████████▓▒─────░▒▒▓▓▒───░▒▓▒░─────────░▓███████████████████████████████
█████████████▓▒▒▒▓▓▓▓▓░───────░▓▒░────────▒█████▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓████████████
███████████████████▓▒──────────░▓▓▒▒▒░░▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓██████████
███████████████████▒░────────────░░▒▒░░▓▓▒░░░░░░░░░░░▒▒▒▒▒▓▓▓▓▓▓▓▓█████████
██████████████████▓░───────────────────▓▓▒░─░░───────░░░▒▒▒▒▓▓██▓▓▓████████
███████████████▓▒▒▒░───────────────░░░░─▒▒░──░░░░──────░░▒▒▒▓▓▓██▓▓████████
██████████████▓▒░─░───────────────░░░▒░░░─▒░─░▒▓▓▓▒░────░░▒▒▒▓▓▓███████████
████████████▓▒░──────────░░░─────░░▒░░░░░─▒▒░─░▓▓▓▓▓▒────░░▒▒▒▓▓▓██████████
████████████▒░───────────░░░───────░░▒░▒▓▒─▒░░░▒▓▓▓▓▓▒────░▒▒▒▓▓▓██████████
██████████▓▒░──────────░░░░░───────░▓█▒▓█▒─▒▒░░░▒▓▓▓▓▓░───░░▒▒▒▓▓██████████
█████████▓▒░───────────░▒▒▒▓▒──────░▓▓▓██▒░█▒░──░▓▓▓▓▓▒░──░░▒▒▒▓▓▓█████████
████████▓▒░─────────────░▒▓██▒░───░▒▓▓██▓░▒██░───▒▓▓▓▓▓░───░▒▒▒▓▓▓█████████
████████▓░─────────────░▒▓████▒░──▒▓▒░▒▒░▒▒██░───░▓▓▓▓▓▒───░▒▒▒▒▓▓█████████
████████▓░───────────░░░▒▓█████▒░─░░────░▒▒▒█░───░▒▓▓▓▓▒░──░░▒▒▒▓▓▓████████
████████▓▒░───────░▒▒░░░▒▓██████▓░░────░░▒▒▒█▒░───▒▓▓▓▓▓░──░░▒▒▓▓▓▓████████
██████████▓▒░──────▒▒░░▒▓█████████▓▒░──░░░░▒▒▒▒░──▒▓▓▓▓▓░──░░▒▒▒▓▓▓████████
████████████▓▒░──────░▒▓████████████▓▒░──────░▒▒░─░▓▓▓▓▓░──░░▒▒▒▒▓▓████████
████████████▓▒░──────▒████████████████▒───────▒▒▓░░▒▓▓▓▓▒──░░▒▒▒▒▒▓▓███████
███████████▓▒───────░▓████████████████▒────────░▓▓▒▓▓▓▓▓▒░─░░▒▒▒▒▓▓▓███████
██████████▓▒───────▒▓█████████████████▓░───────░▓▓██▓▓▓▓▒░─░░▒▒▒▓██▓▓██████
█████████▓░───────░▓███████████████████▒────────▒███▓▓▓▓▒▒─░░▒▒▒▒▓█████████
███████▓▒░───────░▒▓███████████████████▒────────░▓██▓▒▓▓▒▒░─░▒▒▒▒▓█████████
██████▓▒────────░▒▓████████████████████▓░────────░███▓▒▒▓▓▒░░░▒▒▒▒▒▓███████
█████▓▒─────────▒▓█████████████████████▓░────────░▒███▓▒▓██▒░░▒▒▒▒▒▒▓▓█████
███▓▒░─────────░▓███████████████████████▒─────────░▓██▓▓▓███▓▓▒▒▒▒▒▒▒▒▓▓███
██▓▒░─────────░▓████████████████████████▒──────────▒████▓▓█████▓▒▒▓▓▓▓▓▓▓██
▓▓░──────────░▓█████████████████████████▒──────────░▒██████████████████████
▒░──────────░▒██████████████████████████▒───────────░▓█████████████████████
▓▓▓▒▒▒░░░░░▒▓███████████████████████████▒───────────░▒▓████████████████████
████████████████████████████████████████▓▒░░░░░░░░▒▒▓▓█████████████████████
██████████████████████████████████████████▓▓▓▓▓▓▓██████████████████████████

Yup, still needs a line break.

Is dynamic resizing also supposed to stretch images that are natively smaller than your browser window? Cause that's what's happening to me (Firefox btw) and frankly, I think it sucks. Looks awful.

I just want them to be resized without a loss in quality if too big, and shown at their native res whenever that's clearly possible. Like before, really. Now it just tries to always fit your window exactly, even if that means bloating and distorting the image.

Huh, that's strange, I wanted to printscreen an example and all of a sudden it stopped doing the bloaty thing. Like literally while going from one image to the next to look for a good showcase. Perhaps that behavior was never intentional, then.

EDIT: Shit, now it's back again: http://i.imgur.com/OaFNy5s.png

What is this? It really does look like a bug, because there's no resize option but clicking Full Size below the image restores it to its native resolution. Which is this: http://i.imgur.com/Uvuw2AR.png

See? It's like letting your browser zoom in on something a few clicks too many, distorted rubbish.

I know how you feel Jugofthat, it is happening here too.

But when it resizes to a bigger picture clicking the button that reloads the picture with the resolution seems to make the picture go to it's original resolution.

But bigger pictures are always getting resized to the screen's size not sure how i feel about that.

Just_Another_Dragon said:
But when it resizes to a bigger picture clicking the button that reloads the picture with the resolution seems to make the picture go to it's original resolution.

Right, I just added that to my previous post. Really weird this, and it obviously shouldn't do that.

By the way, I've also tried the Reduced Samples option and encountered a bug where it wouldn't let me resize an image again once I had loaded the full image with Full Size. The resize button in the options menu simply appears to do nothing, except for when you press it while the image is still compressed, because then it responds by turning the compressed file it into a larger version that obviously looks quite bad. Thought I should let you know.

Again though, perhaps this is browser-specific. I'm using Firefox 37.0.

So to summerize, at the moment we seem to be stuck with two less-than-ideal resizing options:

• One that resizes big pictures like before, but also automatically bloats low-res pictures in an unsightly way unless specifically told to knock it off every time (which is basically the reverse of having No Resizing on and needing to manually resize everything that's too large to properly view).

Now admittedly, it doesn't always look that bad, but the smaller the image the further it has to zoom, and more complex lineart quickly suffers by appearing blurry or pixelly. What's worse, it sometimes appears to actually bloat an image so much it becomes larger than my browser window, and I have to press Full Size not just to regain sharpness, but to be able to see the whole image at once. So then it's like resizing a normal large full-res, just... with a really crappy full-res. :|

Also, pressing Full Size in order to shrink something feels very counterintuitive.

• One that only resizes large pictures, but at the visible cost of image quality, and that doesn't want to resize again once you decide to load the full image (which then instantly becomes full-sized and thus potentially huge, instead of first showing up as resized without quality loss).

I don't like it. Not like this, at least. =/

parasprite said:
Yup, still needs a line break.

Damn, that ASCII art...

Jugofthat said:
Again though, perhaps this is browser-specific. I'm using Firefox 37.0.

So to summerize, at the moment we seem to be stuck with two less-than-ideal resizing options:

• One that resizes big pictures like before, but also automatically bloats low-res pictures in an unsightly way unless specifically told to knock it off every time (which is basically the reverse of having No Resizing on and needing to manually resize everything that's too large to properly view).

Now admittedly, it doesn't always look that bad, but the smaller the image the further it has to zoom, and more complex lineart quickly suffers by appearing blurry or pixelly. What's worse, it sometimes appears to actually bloat an image so much it becomes larger than my browser window, and I have to press Full Size not just to regain sharpness, but to be able to see the whole image at once. So then it's like resizing a normal large full-res, just... with a really crappy full-res. :|

Also, pressing Full Size in order to shrink something feels very counterintuitive.

• One that only resizes large pictures, but at the visible cost of image quality, and doesn't want to resize again once you decide to load the full image (which then instantly becomes full-sized and thus potentially huge, instead of first showing up as resized without quality loss).

Interesting. Do you happen to have an option in your userContent.css disabling interpolation? This is a file found in the 'chrome' subdirectory of your firefox user profile directory.

I mention this because I do (it's related to correctly displaying zoomed pixel art), and it would be a sensible cause for the specific artefacting you show -- since that artefacting is exactly what you'd get if you scaled the image up/down with 'nearest neighbour'/'none' interpolation

What I have looks like this.

img[src$=".gif"] { image-rendering: -moz-crisp-edges; -ms-interpolation-mode: nearest-neighbor; }
img[src$=".png"] { image-rendering: -moz-crisp-edges; -ms-interpolation-mode: nearest-neighbor; }

I believe doing this via an addon is also possible, so that is worth checking for. By default interpolation is set to bilinear, which will not exhibit very clear 'pixel edges' like the ones seen in your example.

Anyway, I just had a look at type:png, and successfully reproduced the bug with https://e621.net/post/show/631234 (on which, to me, it looks surprisingly decent actually). Have not reproduced the 'bigger than browser window' bug.

Hopefully we can agree that the correct solution is to limit scale to <= 100% (of the image that's actually specified in src attribute, not just the full size image).

I'm also using FF 37.0, on Arch Linux x86_64.

Jugofthat said:
Is dynamic resizing also supposed to stretch images that are natively smaller than your browser window? Cause that's what's happening to me (Firefox btw) and frankly, I think it sucks. Looks awful.

Nope, it's a bug and I've already pushed a fix that'll hopefully be live soon (possibly not until tomorrow). Weird thing is, I know I wrote the code to handle that case before I committed it originally, but who knows where it went...

Let's uh, just call this our April Fool's Day prank. Haha, ha, ha

Here's a serious bug:

Tag scripting currently clears all the sources from the posts.

After browsing my tag history, looks like it started between March 31st, 6:00 - 10:30 PM. All posts that have been tag scripted (by anyone) since then are missing sources.

That's at least ten thousand posts (though not all had sources to begin with)... I wish I had noticed this sooner.

Genjar said:
Here's a serious bug:

Tag scripting currently clears all the sources from the posts.

After browsing my tag history, looks like it started between March 31st, 6:00 - 10:30 PM. All posts that have been tag scripted (by anyone) since then are missing sources.

That's at least ten thousand posts (though not all had sources to begin with)... I wish I had noticed this sooner.

I've confirmed this and Tony pushed a fix, which should hopefully be live within the next hour or so. In the meantime avoid using any tag scripting as it seems to affect every post that it's used on. There will be a news post after we can confirm that tag scripts are safe to use again.

Going forward, it may be a good idea to try and remember to check the tag history for posts before trying to hunt for sources in case that particular post was accidentally wiped from today.

Tag script source bug has now been fixed.

I suppose there's no easy way of restoring the sources?
...ah well, I guess I'll fix mine manually. That'll literally take about a month, but at least I can tag those posts with other things at the same time. So it's not a complete waste of time.

Genjar said:
I suppose there's no easy way of restoring the sources?

I'm kind of surprised if so, since I figured there would be some kind of log of recent actions, for debugging purposes if nothing else.

Genjar said:
I suppose there's no easy way of restoring the sources?
...ah well, I guess I'll fix mine manually. That'll literally take about a month, but at least I can tag those posts with other things at the same time. So it's not a complete waste of time.

I think you can bulk revert changes by clicking and holding shift or something. I'm away from a computer at the moment so I can't test it (also I've never tried it before). There are ~200 or so +male/female that were tag scripted in my recent history that can safely be reverted if you want to play with it.

I suspect that if yout try to do it on your own tag history it will automatically push them to the front of the list and make it generally more confusing to revert.

parasprite said:
I think you can bulk revert changes by clicking and holding shift or something.

There's probably no way of reverting just the source, while keeping the tags intact. So either way, I'd lose all the edits I made within the past days. Which was a lot.

On the whole, I think I'll rather fix the sources manually. Even though there's thousands, and it'll take a long while. There's always other things to tag while I'm doing it.

Bug: Unordered lists in wiki edit don't show properly when you hit "preview"
Expected behavior: http://i.imgur.com/uKA4KjY.jpg

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 

    eiusmod tempor incididunt ut labore et dolore magna aliqua. 
     ø list_item

     ø list_item

        o nested_list_item

            ◊ nested_nested_list_item

  

     ø list_item

Actual behavior: http://i.imgur.com/Bf7MJQD.jpg (the last item is just me testing something)

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do 

    eiusmod tempor incididunt ut labore et dolore magna 
  ø list_item

  ø list_item

  o nested_list_item

  ◊ nested_nested_list_item
  ø list_item

Steps to duplicate:

Find a wiki with varying levels of unordered lists, go to edit, hit preview.

Bug found with switching between different sizes of an image without refreshing the page.

Bug: The 'resize image' link (found directly under the 'favorite' button) no longer works properly.
Expected behavior: To be able to use the "resize image" link under the favorite button, in combination with the 'full size' (and/or 'size: [deminsions x deminsions] [file size]' link) in order to switch between a reduced size and the full original size of that image while viewing the page, as needed.
Actual behavior: Depending on which sizing option your Settings are currently on, using the 'resize image' button either partially works only once per refreshed page, or doesn't respond to being clicked at all and does nothing.
Steps to duplicate:

• On the "Dynamic Resize" setting: the "resize image" button won't work at all. This means you can click the full size to check something, but then can't make it go back to a smaller display of that image without refreshing the whole page.

• On the "Don't resize" setting: clicking the "resize image" button will work only once to shrink it to screensized, but then acts broken if you try to switch between sizes any more than that without refreshing the whole page.

• On the "Show Reduced Samples": the "resize image" button will make it go from the sample size up to the slightly bigger midsize, but then becomes unresponsive on subsequent attempts to switch between sizes without refreshing the page back to default. And it doesn't respond at all if you've clicked to go to the full size and want it to go to a smaller size again.

So in short: most attempts to switch back and forth between sizes on a page right now (without refreshing) are crippled.

furrypickle said:
Bug found with switching between different sizes of an image without refreshing the page.

Yeah we forgot to rebuild the JS file again :(

Hopefully it'll be fixed sometime today.

Login to Respond doesn't redirect user on forum threads.

The link should be like this:

https://e621.net/user/login?url=%2Fforum%2Fshow%2F28544%3Fpage%3D54

Bug:[Nomethoderror in post#show]
Expected behavior:[viewing post]
Actual behavior:[redirects to error page which states Showing app/views/post/show_partials/_image.html.erb where line #32 raised ]
Steps to duplicate:[clicking any post]

Rulersof34 said:

That's very hard to read and I'm pretty sure it wasn't what you intended. Try previewing it in the future.

(To bold "some words", write:

[b]some words[/b]

)

Bug: Sections cause extra "padding" between blips and user info boxes in profile.
Expected behavior: Initial "padding" is calculated as if all section tags are collapsed.
Actual behavior: Initial "padding" is sometimes calculated as if all section tags are expanded. Refreshing usually fixes it, and changing the width of the window by a single pixel fixes it. See http://i.imgur.com/m7aMg9s.png
Browsers affected: Happens on Chrome with or without addons and with a clean settings profile. I haven't been able to reproduce this in Firefox or Safari, but I haven't done much testing with those.
Steps to duplicate: Variable. It doesn't happen on every page load but if you keep putting them in new private windows it will eventually popup. Has been going on for at least a couple months, but it's probably much less noticeable if you only have a few sections in your profile.

My guess is that it has to do with how Chrome prioritizes the page loading. It seems as if the user info box size is sometimes calculated before javascript has a chance to collapse it; the wrong value causes extra "padding" to show up between that and the blips.

*Note that I'm using the word "padding" here for readability. In the box model, the issues are actually with content, not padding.

Bug: When deleting several posts from a pool you are presented with the a message with a click box asking if you would like the page to stop asking for confirmation of the action which does not fuction properly.

Expected behaviour: You are able to continue deleting posts from the pool without having to continue confirming the action.

Actual behaviour: Clicking on any post in the pool after clicking on the click box will take you to the post/show/ page of the post instead of deleting it.

Steps to duplicate: Attempt to delete posts from a pool after clicking the click box in question.

(I am using Windows 7 with Firefox.)

DragonFox69 said:
Bug: When deleting several posts from a pool you are presented with the a message with a click box asking if you would like the page to stop asking for confirmation of the action which does not fuction properly.

That's a Firefox feature (Chrome has the same thing). The checkbox should actually say "Prevent this page from creating additional dialogs" which doesn't mean "always confirm" it means "the browser should temporarily ignore dialog boxes", which would do nothing if the action requires a button on the dialog box to be pressed. ;)

However, it is a bit faster to remove posts if you use the enter key instead of clicking with the mouse.

Bug: Respond button (for comments) doesn't work except on the submission page itself.
Expected behavior: e621 will open a text box for you to submit a response to the selected comment.
Actual behavior: Nothing happens.
Steps to duplicate: Open the "Comments" tab or the subset "Comments on Your Posts" and click "Respond" under any comment listed.

PheagleAdler said:
Bug: Respond button (for comments) doesn't work except on the submission page itself.
Expected behavior: e621 will open a text box for you to submit a response to the selected comment.
Actual behavior: Nothing happens.
Steps to duplicate: Open the "Comments" tab or the subset "Comments on Your Posts" and click "Respond" under any comment listed.

Can confirm. Clicking on any individual comment-specific 'respond' link on this page https://e621.net/comment/index doesn't do anything.

However, the generalised 'respond' link listed once per image after all the specific comments on that image, that link works perfectly. But trying to respond to any specific comment from that page is what is fails to generate a typing box.

PheagleAdler said:
Bug: Respond button (for comments) doesn't work except on the submission page itself.
Expected behavior: e621 will open a text box for you to submit a response to the selected comment.
Actual behavior: Nothing happens.
Steps to duplicate: Open the "Comments" tab or the subset "Comments on Your Posts" and click "Respond" under any comment listed.

Just curious, do you happen to be running eSix Extend?

parasprite said:
Just curious, do you happen to be running eSix Extend?

Yes?

PheagleAdler said:
Yes?

Turn it off temporarily, reload the page, and then try it again. Let me know what you see.

parasprite said:
Turn it off temporarily, reload the page, and then try it again. Let me know what you see.

Tested it myself: yes, it's eSix Extend. I've also figured out the exact cause. I'll report it now. Reported.

is uploading acting up again? i was about to start adding to that pool i was working on last night and it's giving me a 500 internal error whenever i hit upload after choosing a pic and entering all the info. (the upload page is fine but it won't actually do the upload)

treos said:
is uploading acting up again?

Yes. It's probably just a upgrade or something they're doing.

Bug: Editing a set and changing short name (and/or name?) to something that already exists gives no visible error message
Expected behavior: Set is not updated with a message of the kind "Error: Shortname is already taken"
Actual behavior: Set is not updated with a "success" message "Set updated"
Steps to duplicate: Create a new set, edit it and change the "Short Name" (and/or Name?) to a taken name, e.g. "temp"

Uploads are broken again.
Edit: Not the uploads that were broken, it's just that using the pool: metatag to add a post to a comic in the upload causes the Action controller error.

Another thing, I'm fairly sure that my uploads were around 4810 or so, now they're 4760+, yet no posts were added to my deleted posts.

Don't know if this is a bug or whatnot but have been getting a few strange "redirects" when updating tags via the site (with update not going through with unknown red error (as in don't remember)), e.g.:

https://e621.net/post/show?id=%23%3CProc%3A0x00000000043b8400%40%2Fhome%2Fe621%2Fe621-production%2Frelease-2014-06-08%2Fapp%2Fcontrollers%2Fpost_controller.rb%3A6%3E
https://e621.net/post/show?id=%23%3CProc%3A0x00000000041343f0%40%2Fhome%2Fe621%2Fe621-production%2Frelease-2014-06-08%2Fapp%2Fcontrollers%2Fpost_controller.rb%3A6%3E

Edit: Red error is "This post does not exist". Seems to be a timeout problem at update and when Chrome happily reloads the page for me when visiting the tab it goes "boom".

Bug: HTTP 500 when supplying invalid parameters to Note API update
Expected behavior: Some kind of handled error for API user, e.g. no valid parameters specified
Actual behavior: HTTP 500 with: "NoMethodError in NoteController#update", "undefined method []&#39; for nil:NilClass" and stack trace [b]Steps to duplicate:[/b] E.g.: [code]$ curl "https://e621.net/note/update.xml?login=xxxxxx&password_hash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" --data "ashjdaksd=ashdjkasd"[/code] --- [b]Bug:[/b] Might not be a bug, but a misunderstanding of the notes API: Editing a note through API and supplying both "note[post_id]" and "id" may cause creation of a new note. At first I thought it was because I was mixing POST and GET, but based on the response Ouroboros seemed to get all info needed. [b]Expected behavior:[/b] Old note is updated [b]Actual behavior:[/b] A new note is created [b]Steps to duplicate:[/b] Create a note (e.g. with id 123456789 on post_id 123456789), edit it with e.g.: [code]$ curl "https://e621.net/note/update.xml?login=xxxxxx&password_hash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&id=123456789" --data "note[post_id]=123456789&note[x]=0&note[y]=0&note[width]=100&note[height]=100&note[is_active]=1&note[body]=body"[/code]

Chessax said:
Don't know if this is a bug or whatnot but have been getting a few strange "redirects" when updating tags via the site (with update not going through with unknown red error (as in don't remember)), e.g.:

https://e621.net/post/show?id=%23%3CProc%3A0x00000000043b8400%40%2Fhome%2Fe621%2Fe621-production%2Frelease-2014-06-08%2Fapp%2Fcontrollers%2Fpost_controller.rb%3A6%3E
https://e621.net/post/show?id=%23%3CProc%3A0x00000000041343f0%40%2Fhome%2Fe621%2Fe621-production%2Frelease-2014-06-08%2Fapp%2Fcontrollers%2Fpost_controller.rb%3A6%3E

Edit: Red error is "This post does not exist". Seems to be a timeout problem at update and when Chrome happily reloads the page for me when visiting the tab it goes "boom".

I can't confirm this is the case, but it may just be having issues with accessing the database through an overloaded server. Obviously it shouldn't be returning errors like this if the post does exist (better ways to handle it internally), but it's likely that this issue will disappear with the new upgrades. Let me know if it keeps happening after that.

In the meantime, I'm going to keep an eye on this one and possibly see if I can figure out how to replicate it.

• How often have you see this happen?
• Does this happen when the site is overloaded?
• Do you know if you have any nontypical networking-related things or other software (think proxies) that might be directing traffic, messing with POST, etc.?

parasprite said:
I can't confirm this is the case, but it may just be having issues with accessing the database through an overloaded server. Obviously it shouldn't be returning errors like this if the post does exist (better ways to handle it internally), but it's likely that this issue will disappear with the new upgrades. Let me know if it keeps happening after that.

In the meantime, I'm going to keep an eye on this one and possibly see if I can figure out how to replicate it.

• How often have you see this happen?
• Does this happen when the site is overloaded?
• Do you know if you have any nontypical networking-related things or other software (think proxies) that might be directing traffic, messing with POST, etc.?

Actually got a bit of a revision to my story (again). What I really got was CloudFlare timeouts (502 Bad Gateway) before the error I described and it was not Chrome reloading the page (trying to blame the browser...), but it was I doing it manually. Somewhere along the way the POST got lost or malformed or something...

It has only happened a very select few times, hence my memory was a little foggy. It's not really a big issue, 99.9% of the time everything seems to work just fine, it's only those times when the server(s) appears to be struggling with traffic (or similar) and CloudFlare is complaining about e621. Proxies? Nope, all I got is a "light" application firewall and a pretty basic router setup and nothing that should make any difference.

In the end I suspect it's just one of those times being in the wrong place at the wrong time while doing the wrong thing.

Steps to reproduce (good luck with that):
1. Update tags on post
2. Wait for CloudFlare to tell you that e621 is crap not responding.
3. Reload page (and resend data?)
4. ????
5. Profit

Bug: HTTP 500 when searching for more tags than allowed using API.
Expected behavior: There should be no HTTP error, only the current API error.
Actual behavior: HTTP 500 error
Steps to duplicate: Search for more tags than allowed, e.g.:

$ curl -i "https://e621.net/post/index.xml?tags=a+b+c+d+e+f+g"

Or simple browser link works (with dev tools): /post/index.xml?tags=a+b+c+d+e+f+g

Bug: Textarea "post_source", when editing post, has no tabindex (should be 11, "post_description" should be 12, "reason" should be 13" and so on, i.e. the most logical order).
Expected behavior: Hitting TAB in textarea "post_tags" should jump to textarea "post_sources".
Actual behavior: Jumps to textarea "post_description"
Steps to duplicate: Go to random post, click "Edit", tab away!

Chessax said:
Bug: Textarea "post_source", when editing post, has no tabindex (should be 11, "post_description" should be 12, "reason" should be 13" and so on, i.e. the most logical order).
Expected behavior: Hitting TAB in textarea "post_tags" should jump to textarea "post_sources".
Actual behavior: Jumps to textarea "post_description"
Steps to duplicate: Go to random post, click "Edit", tab away!

Huh, I never noticed this.

Bug: excluding set from the search querry does weird stuff

Expected behavior: posts that are in the selected set Will be hidden from the search page when you add a - behind it (ex. -set:name)
Actual behavior: some images included in the set, will appear twice or even 3 or 4 times
Steps to duplicate: take for example set:fgriffs
Now try -set:fgriffs feral gryphon
You will see that there will appear 2/3/4 of the exact same posts, thats what im trying to hide.

(Sidenote, i want to do this because i want to add more posts to my set, otherwise i keep getting "post already added" which makes it alot harder. So adding -set will make it alot easier)

Pool history of pool #670 looks rather weird.

Not sure if it's been posted already, but I occasionally get a random 404 error with some posts/search results. After a few refreshes, it goes away.

I am not sure if I am the only one getting this bug but I have my view on "Add to Favorites" Mode. If I add to favorites by clicking the thumbnail It doesn't apply to the page on the full post's page. So, the +Favorite button stays green and doesn't show as the red -Favorite button. Also i I try to click it, I get "Error: You've already favorited this post".

But, I will just put it on "Remove from Favorites" Mode whenever I need to un-favorite a post I faved by accident, as a temporary fix.

TheLoneBit said:
I am not sure if I am the only one getting this bug but I have my view on "Add to Favorites" Mode. If I add to favorites by clicking the thumbnail It doesn't apply to the page on the full post's page. So, the +Favorite button stays green and doesn't show as the red -Favorite button. Also i I try to click it, I get "Error: You've already favorited this post".

But, I will just put it on "Remove from Favorites" Mode whenever I need to un-favorite a post I faved by accident, as a temporary fix.

I can't exactly reproduce this, but does the +Favorite button change when you refresh the post page?

Uploading Flash files still appears to be horribly broken. Like this one for example:

post #649006

Other people couldn't get it to upload at all (they'd get booted to the familiar error message), I did manage to by uploading from the source instead of file, but now it's not exactly working.

I've been having image loading problems. It won't auto-resize some.

ShadowBolt14 said:
I've been having image loading problems. It won't auto-resize some.

Go to your "settings page':/user/edit and make sure it is set to dynamically resize images.

If it is already set, what browser are you using? Does it fix itself when refreshing the page?

parasprite said:
I can't exactly reproduce this, but does the +Favorite button change when you refresh the post page?

No. Refreshing doesn't fix it. But, if you can't reproduce it then, it must be an internal problem. So, I will try clearing my cache and restarting my browser. Thanks!

parasprite said:
I can't exactly reproduce this, but does the +Favorite button change when you refresh the post page?

TheLoneBit said:
No. Refreshing doesn't fix it. But, if you can't reproduce it then, it must be an internal problem. So, I will try clearing my cache and restarting my browser. Thanks!

Boom! Fixed. Just had to clear my cache and cookies.

Automatic Resize seems to be broken for me.

Absurdly large pictures do not scale down to my screen size when clicked on.

And no matter how many times I click on the "Resize Image" button they never get smaller.

I'm using a 1080p screen by the way. Yes I've cleared my cache and cookies and it still presists, on 3 different computers too. Even across linux and windows.

EDIT: Using latest version of chrome 32-Bit.

EDIT 2: I've checked and tried every possible option for "Image resize mode" under my user settings page, and nothing seems to change what is happening.

kithylin said:
Automatic Resize seems to be broken for me.

Absurdly large pictures do not scale down to my screen size when clicked on.

And no matter how many times I click on the "Resize Image" button they never get smaller. (...)

Clicking on the image itself will not trigger resizing, so I'll assume that's a typo or something.

I can partially confirm this bug as everything works fine for me, except in one case. If Image resize mode is set to Show reduced samples, gif images (which don't have reduced samples to begin with) are never resized. In every other case, things were working as expected. Non-gif images displayed reduced samples and the resize links worked properly. in Dynamically resize images mode, every image I've tested got resized as I resized the window and the resize links worked as expected. In Don't resize images mode, the "Full size" link disappeared from under the image, but the resize links on the sidebar worked properly.

Note: I haven't tested swf and webm posts as (if I remember correctly) resizing never worked on them.

So questions:
1) Type(s) of posts affected by this bug?
2) Is JavaScript enabled in your browser / not blocked by an addon?

Re: forum #142029
Bug: CloudFlare error/timeout when previewing long/complex posts, or simply being unlucky due to server load, may cause you to lose entered text.

Any fix/update? I hate this!

Chessax said:
Re: forum #142029
Bug: CloudFlare error/timeout when previewing long/complex posts, or simply being unlucky due to server load, may cause you to lose entered text.

Any fix/update? I hate this!

From personal experience: On any website, always, always always move your text walls to a new wordpad/notes/textedit/Word/etc. document while you are working on them. Internet can cut out, browsers can crash, RAM can refresh, batteries can die, server requests can fail. Nothing worse than having an hours worth of writing get wiped out for no reason. The only proven way to prevent this from happening is to save it to disk (either your own or in the cloud), preferably somewhere that autosaves as you go.

That being said, I won't speak of the server load right now but there's 2 separate issues here that I know are being looked into:

Preview button:

Here's a tldr for how the button currently works: User writes text, hits preview button on computer -> Text is sent to server -> Server parses it -> Server sends back some html to display -> Computer displays html. An issue with any part of this stage can cause problems.

For instance, during heavy load Cloudflare will sometimes hijack the request and send you to a Error 5xx page instead (because it can't deliver the new html to you), and this can result in a wiped comment in some cases. It also doesn't really help that the code for the preview button is buggy as hell and hacked together (it's almost surprising that it works at all, really). It's to the point where patching is getting more complicated than scrapping it and starting over, and this is going to have to be done eventually anyways. I don't have a timeframe to give you right now, but I know this is one of the things that are being planned right now.

What you can do: To prevent long comments from getting lost, write them in a text document first and then copy them into the browser window. I said it before, but I'd still recommend doing this for any long comment you write regardless of what website you're on (this is especially true of mobile devices).

Cloudflare blocks:

Both "captcha/blocked page when typing long comments" and "blocked page when comments contain certain strings of text" are related to the security settings. Dari has said that they may need to relax these settings a bit so that Cloudflare doesn't overreact as much, but I know they are also looking for ways to change how the requests are sent in the first place, and make them generally less prone to triggering Cloudflare.

What you can do: If you get a blocked page...

• Find the Ray ID on the bottom of the page (where to find this)
• Send this to either me or Dari along with a brief explanation of what you were doing right before the page came up.
• If you were typing a comment, a screenshot or pastebin of the exact comment is extremely useful to have.

This information allows us to figure out exactly what is triggering Cloudflare, and will help to find ways to prevent it from happening in the first place.

EsalRider said:
Clicking on the image itself will not trigger resizing, so I'll assume that's a typo or something.

I can partially confirm this bug as everything works fine for me, except in one case. If Image resize mode is set to Show reduced samples, gif images (which don't have reduced samples to begin with) are never resized. In every other case, things were working as expected. Non-gif images displayed reduced samples and the resize links worked properly. in Dynamically resize images mode, every image I've tested got resized as I resized the window and the resize links worked as expected. In Don't resize images mode, the "Full size" link disappeared from under the image, but the resize links on the sidebar worked properly.

Note: I haven't tested swf and webm posts as (if I remember correctly) resizing never worked on them.

So questions:
1) Type(s) of posts affected by this bug?
2) Is JavaScript enabled in your browser / not blocked by an addon?

1.) Every large post of every kind for me. Does not resize down to fit my screen. And by "button", I meant the "Resize Image" link on the left side of the page.
2.) I have javascript enabled in chrome, of course.. a large portion of the web uses it today. I do not have any addons or anything to "Block" javascript, other than Adblock plus, and it doesn't do that.

kithylin said:
And by "button", I meant the "Resize Image" link on the left side of the page.

... Ok, then that was me not being able to read properly. Somehow I thought you wrote "And no matter how many times I click on the image they never get smaller."

Edit: Oh yeah, I was actually referring to this line:

Absurdly large pictures do not scale down to my screen size when clicked on.

As for the resize problem, I have no idea what causes it... Anything in the debug console? (Ctrl + Shift + J)

I have an issue with that dynamically resizing feature too.

Basically, only horizontal resizing works, which seems to work fine. Unfortunately, no images seem to resize according to my vertical window boundaries. Maybe the feature is working as intended. I don't know. Regardless, I don't want to scroll down to see entire pictures, and clicking Download to see a properly resized picture doesn't conform to my ideal e621 browsing experience's flow.

This happens on Firefox 37, private browsing, Windows 7. Same behavior on a clean profile as my normal profile. Same behavior in Chrome and IE, so I assume this feature is working as intended.

post #649862 doesn't resize vertically.
post #649856 resized horizontally before running off my window's normal vertical size.
What this looks like.

The only thing that pops up in the console as those pages load is:

Use of getPreventDefault() is deprecated. Use defaultPrevented instead. applicatio... :473:0

Clicking on "applicatio... :473:0" highlights this line in another window:

if(src&&src.type){this.originalEvent=src;this.type=src.type;this.isDefaultPrevented=(src.defaultPrevented||src.returnValue===false||src.getPreventDefault&&src.getPreventDefault())?returnTrue:returnFalse;}else{this.type=src;}

I'll stick with image samples while this behavior remains.

Bug
You can flag a post as an inferior version of itself.

Expected behavior
You shouldn't be able to do that.

Actual behavior
You can.

Steps to duplicate
post #650953

Munkelzahn said:
Bug
You can flag a post as an inferior version of itself.

Expected behavior
You shouldn't be able to do that.

Actual behavior
You can.

Steps to duplicate
post #650953

I...I must see what happens when I delete this.

Edit: Well that was boring.

Edit 2: Yeah that should be making the same check as with parenting, I'll forward this to the devs. As far as I understand it, it should be pretty simple to fix.

I am having issues with [nintendo] [-pokemon], why is this not working? (I suspect it's a bug as it worked before)

nintendo is implicated to video_games, so by blacklisting video_games you essentially block everything that nintendo -pokémon lets through.

Try using video_games -pokémon instead.