Redirects to high-res images on gallery sites, skipping past descriptions and comments
< Feedback on Eza's Image Glutton
[Bug Report] Chrome Redirection Allows No Back FunctionalityRe:
// Apparently Chrome doesn't redirect properly - there's no 'back' functionality. Grand.
// ... there's back functionality if and only if the page finishes first. Fuck Chrome.
// Can I detect when this happens? Maybe add some awful floating fake back button, linked to the #dnr URL?
// I can't even reproduce this anymore. "It works on my machine" is an obstacle.
// User says any delay will work, to stop Chrome from ignoring a redirect. Sweet.
This issue remains in the latest version; no back-functionality unless triggered from the context-menu after the page has already loaded. As the discussion link in the comment 404s, is there a proper way to add an (automatic) delay, as referred to?
The discussion link works if you're logged-in. Otherwise you have to go to https://sleazyfork.org/en/scripts/4713-eza-s-image-glutton/discussions/90997 - because Greasy Fork split off "adult" scripts to Sleazy Fork when advertisers complained.
Also... Image Glutton does not use the context menu. Are you sure this is the right page?
The automatic delay was added, and has been in the last several versions. It's the setTimeout( redirect, 1 ) right before function redirect(). You could try higher numbers and see if that makes a difference. I still can't reproduce this error, so I can't test for what fixes it.
setTimeout( redirect, 1 )
To clarify, Tampermonkey has a run-at setting for each script; that is what I was referring to.I found the timeout, but no duration prevents the #dnr page from being eaten. However, with a usable (~3s) delay, any interaction with the page (right-clicking, typing in a text field, clicking on a button) will preserve the #dnr page.
Further, I checked that the #dnr page is added to the browser's history; it just isn't available as a 'back' option without some interaction.
Ah, that makes sense. Does adding document.body.click() before the setTimeout line have any impact? Randomly clicking on things is not generally a good idea, but none of these sites should do anything when someone clicks on the background. Abundant caution would look like document.querySelector( '*:not([onclick])' )... no, that still clicks links. document.querySelector( 'div:not([onclick])' ).click() should do nothing but register a click event.
document.querySelector( '*:not([onclick])' )
document.querySelector( 'div:not([onclick])' ).click()
I just don't know whether Chrome will consider that real.
Neither .click() works, even if I give it a usable selector ('Fit Image to Window').
Very tentatively, from using Chrome's 'Recorder' tool, it seems those .click()s might not be attributed to the page properly.See the following screencap:Where the first click is on a thumbnail that, opening the individual page. While the timeout runs, those three real clicks are attributed to the individual page, before the script opens the full image, where the final real click occurs. However I noticed with the .click()s, they would all attribute to the first index page, even if they actually clicked links on the individual page.This could just be a quirk of the new Recorder, but it suggests that Chrome doesn't think the fake clicks occur in the new page, and if no real ones have occurred doesn't cache it, as it doesn't cache pages without any events.
Unfortunate but not surprising. This behavior in Chrome seems designed to prevent back-traps and ignore automatic redirect pages. But this script turns image submissions into automatic redirect pages. And the #dnr pages are the only thing stopping the script from also being a back-trap.
You could try modifying history to put the image URL in the "forward" page, and then navigate forward. But I'd be mildly worried if that works.
Maybe try location.assign( image_url ) instead of window.location.href = image_url? Gelbooru uses that simple_redirect code-path.
location.assign( image_url )
window.location.href = image_url
Same problem on newgrounds.com
Sign in to post a reply.