Posted under General
This topic has been locked.
Currently for me, all translation notes are appearing at the upper-left corner of the image, not the image area where the hotspot is. I can manage, it's just annoying to tap, scroll back up to read, accidentally tap and lose focus, etc. Really though I'm at least grateful that the hotspots themselves aren't all pushed up to the upper-left as well..
No, it's probably just this same old device I like and don't want to give up on... :shrug: I tried to copy and delete my CSS but that didn't fix it, and the device's copy buffer wasn't big enough to restore the full paste so I'll have to look for that again. 'Netfront Browser(WebKit)' is what I think it's based on. It's just odd that the hotspots are all there in the right spots but the translation notes are not...guessing that means the coordinates are behind a tag/code/whatever that my old browser doesn't recognize so it defaults them to the image's 0,0 coordinate. However newer things like 'custom fonts' DO work(posts/3790300 for instance), you'd think that would break before coordinates would.
BrokenEagle98 said:
What do you mean? I just tried it out myself and it works just fine. More information would be helpful, including any screenshots demonstrating the issue.
I don't know if it's the same issue that Asahina is having, but when I view an image that should be resized to window length, it's instead shown at full size. Clicking on "Resize to window" twice gets it to the expected size, with the first click seemingly doing nothing. Alternatively, it gets fixed if I go back a page in the browser, then open the image page again.
It's particularly annoying when viewing on mobile, as a LOT of images there are wider than the typical window length on that platform.
NeoChaos said:
I don't know if it's the same issue that Asahina is having, but when I view an image that should be resized to window length, it's instead shown at full size. Clicking on "Resize to window" twice gets it to the expected size, with the first click seemingly doing nothing. Alternatively, it gets fixed if I go back a page in the browser, then open the image page again.
It's particularly annoying when viewing on mobile, as a LOT of images there are wider than the typical window length on that platform.
I just tried it out again on both Chrome and Firefox, using both my desktop (Windows 8 64-bit) and phone (Android 7.0), and all platforms and browsers are having none of the mentioned issues.
Also check your userscripts and custom CSS. If possible, also check the dev console (F12) for errors.
Updated
Custom CSS is empty, don't have any userscripts that I'm aware of. Same issue, even after a reboot of that device, the only difference between desktop and that device is the location of the tooltip popup is always at the image's upper-left corner(and still the old-issue, that the image is beneath all of the tags rather than to the right of them). That browser has off-device dev-tools(which you have to type the local URL into to view) but the only thing it tells me is the title of the page and the URL for it. The only thing I could find in the source of that page is slightly more info on what version it is.
http://trac.webkit.org/browser/branches/safari-536.27-branch/Source/WebKit2/qt/Resources/inspectorPageIndex.html Which I'm sure means nothing of itself, just what version it is. But yeah, I know, on everything else the issue isn't there. Sorry I can't give any more info... I'll try to just deal with it as well as I can.
MAGNUS-8M said:
Custom CSS is empty, don't have any userscripts that I'm aware of. Same issue, even after a reboot of that device, the only difference between desktop and that device is the location of the tooltip popup is always at the image's upper-left corner(and still the old-issue, that the image is beneath all of the tags rather than to the right of them). That browser has off-device dev-tools(which you have to type the local URL into to view) but the only thing it tells me is the title of the page and the URL for it. The only thing I could find in the source of that page is slightly more info on what version it is.
http://trac.webkit.org/browser/branches/safari-536.27-branch/Source/WebKit2/qt/Resources/inspectorPageIndex.html Which I'm sure means nothing of itself, just what version it is. But yeah, I know, on everything else the issue isn't there. Sorry I can't give any more info... I'll try to just deal with it as well as I can.
The only suggestion for you really is to upgrade your ancient iWhatever.
BrokenEagle98 said:
I just tried it out again on both Chrome and Firefox, using both my desktop (Windows 8 64-bit) and phone (Android 7.0), and all platforms and browsers are having none of the mentioned issues.
Edit:
Also check your userscripts and custom CSS. If possible, also check the dev console (F12) for errors.
I'm seeing the same issue Asahina and NeoChaos were reporting on mobile, using the latest version of Chrome on a Pixel 3 running Android 9. Verified in my settings that "Default image width" is set to "850px" and "Fit images to window" is set to "Yes". I have no custom CSS and "Disable responsive mode" is set to "No".
However, if I go to a post like post #3800784, with a resolution of 2344x3581, it doesn't properly shrink down to fit on the screen even though it shows the "resized" notice and looks like this.
It doesn't happen for all posts, though; don't have time to test everything but here's a small list of pictures where I'm seeing it happen and not(checking from a query for "absurdres" to make sure it would normally be shrunk down):
DOES have the issue:
post #3800790
post #3800455
post #3800339
post #3800290
DOES NOT have the issue:
post #3800789
post #3800692
post #3800641
post #3800291
Hopefully that helps find some commonality between the ones where it's happening.
(on a side note, when I view my settings page, at first it loads both the Basic and Advanced settings in one column, but if I tap either of those headers at the top it then only shows one group at a time).
Works fine on the site, but saving the webm is impossible (at least on my end) as it always results in a file of 0 bytes.
Some new posts have a techorus-cdn source instead of pixiv.
For example, post #3809104 has https://tc-pximg01.techorus-cdn.com/img-original/img/2019/12/26/23/58/30/78511466_p0.jpg instead of https://www.pixiv.net/artworks/78511466
And also JSON contains "pixiv_id": null
I do not know if this is a bookmarklet or uploader problem.
anonbl said:
Some new posts have a techorus-cdn source instead of pixiv.
For example, post #3809104 has https://tc-pximg01.techorus-cdn.com/img-original/img/2019/12/26/23/58/30/78511466_p0.jpg instead of https://www.pixiv.net/artworks/78511466
And also JSON contains"pixiv_id": null
I do not know if this is a bookmarklet or uploader problem.
This has already been fixed with commit #49a3538, but it hasn't been deployed yet to Danbooru.
disapproval: metatag to disapproved: and changed it so that it shows posts that have been disapproved by anybody, not just posts disapproved by yourself. Examples:Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.02.25-065212-utc...production-2020.03.05-034728-utc
Would it possible to make it so creating or renaming an artist entry generates a warning or error in the event that:
is_active field to is_deleted and inverted the meaning. This is for consistency with deleted fields on other models.limit and type params. Valid values for type: frequent, similar, like.tags_overlap field. This field shows estimated tag frequency.Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.03.05-034728-utc...production-2020.03.11-025008-utc
kittey said:
Maybe the colored labels/icons could get their own column? The zig-zag look of interleaved topics with and without labels is quite annoying to read and counters the advantage of the highlighting.
Yeah, that's what I was thinking as well. They should all go in a new column on the far left. New should probably be given an icon instead. All of the icons should be given different colors, to help them stand out. Also, to make the items line up nicely with the title column, they should be given a right-side text alignment. Finally, all of the text labels should go to the far right of this new column, since the text will jive better when it's next to the other text of the title column.