Correction. Ctrl-click on the Mac displays the sample with a zoom tool in a new tab. Click on that and I get the original size.
Ctrl-click is like right click on the PC I have no middle button on my trackpad.
It's like the link fails to auto-size.
Ctrl-click toggles sample sizes for me. Not sure if that's intended behaviour but it's the default for javascript. To get the original you either have to use the Download button or the filesize button if you're unable to middle click.
Ctrl-click toggles sample sizes for me. Not sure if that's intended behaviour but it's the default for javascript. To get the original you either have to use the Download button or the filesize button if you're unable to middle click.
Clicking on the link (right-click I think) auto expanded the image to the original size. It's always done that and works on yandere. Now it's broke no matter what I do.
Ctrl-click is a context menu thing, and it will open in a new tab,but I should have the old behavior.
Clicking on the link (right-click I think) auto expanded the image to the original size. It's always done that and works on yandere. Now it's broke no matter what I do.
Ctrl-click is a context menu thing, and it will open in a new tab,but I should have the old behavior.
Ok, I can save the original, but I can't understand why it won't zoom to the actual size like it use to.
Clicking on View original fetches the original but won't zoom actual size.
Within the past week, I've noticed a change in how translation note text is displayed for standard (non-embedded) notes. Previously, pop-up text would seem to wrap at a roughly standard width for most text boxes, factoring in font size, etc. Now, some narrow notes have narrow-as-possible pop-ups—seemingly width-sized to the longest individual word in the note or the width of the note box itself, whichever value is larger. In contrast, the pop-ups for some wider notes seem to stretch across a good portion of the image, far wider than the note width itself, before they wrap to the next line.
The effects don't appear to be consistent, either, possibly because I don't know the exact dividing point at which this changes. Compare the first and third notes in panel 1 of post #3841623. The first note appears to wrap normally, with the lines coming out fairly even. The third note acts as though it has a "white-space:nowrap" style format on it, even though it doesn't. There's only an 11px difference in width between the two.
Also compare the second note in panel 1 of post #3840440 with the first two notes in panel 4. The former's pop-up has a more natural wrap: roughly even lines of text, more than one word per line on all the wider lines. The latter two try to wrap the text as narrowly as possible, resulting in tall, narrow pop-ups with one word per line. The former is 29 px wide, while the latter two are 27 px and 34 px, respectively, if that helps at all.
On the surface, none of this is particularly disastrous or site-breaking in and of itself, but it might indicate a bigger problem. It could be a side-effect of other recent changes, or it might be a purpose-made change per se, though I can't imagine right now what that purpose might be. Any thoughts on the matter?
Nice, thank you. It was more distracting than anything else, so I wasn't sure if it was worth kicking up a fuss. Sorry I ended up telling stuff you already knew.
Been a while since it started happening, but was removing tags from page cookies/cache intended? It kind of sucks when my browser crashes and I lose all the tags and links I had in like 6-10 upload tabs.
Been a while since it started happening, but was removing tags from page cookies/cache intended? It kind of sucks when my browser crashes and I lose all the tags and links I had in like 6-10 upload tabs.
Saving form values on the uploads page is something your browser is doing, not us. Some browsers (Firefox in particular) are known to save form values and autofill them when you reload the page. We disabled this behavior for Firefox because there were cases where it broke things in very mysterious ways. One case was when an approver would approve a post then try to edit the tags, the tag edit would fail because Firefox tried to autofill stale form values.
Is the undo link in the commentary history gone or am I remembering incorrectly and there was never one there in the first place?
Also, are obsolete tag changes in the tag history not marked anymore? Previously, the +/- on obsolete changes were black and the green/red colors were darker.
Is the undo link in the commentary history gone or am I remembering incorrectly and there was never one there in the first place?
You have to click the version link which will then drill down to the searching commentary by post.
For most items on this site, the revert links only become visible when searching by the instance types that they are attached to. This is because the revert links have no context when they are just in the general listing. As for undo links, they are only available on post versions at this time.
Also, are obsolete tag changes in the tag history not marked anymore? Previously, the +/- on obsolete changes were black and the green/red colors were darker.
Several improvement in the post versions are already being made in issue #4369. If you have any suggestions beyond those, then those could be considered and added in as well.
I've been using an incredibly old script, Danbooru Note Assist which hasn't been updated in 5-odd years; the recent updates to the site seem to have broken its functionality completely.
I'm no programmer, so I don't know how it could be fixed (or at all); however, it's still on the about:userscripts page, so if nothing else it should be removed from there if it's permanently non-functional.