Sleazy Fork

[Bug Report] Chrome Redirection Allows No Back Functionality

Re:

// 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. 
	// https://greasyfork.org/en/scripts/4713-eza-s-image-glutton/discussions/90997
		// 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.

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.

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.

Userscript authors routinely want options that are excluded from normal Javascript for very good reasons. (Identifying visited links, for example.) This sort of bug is a lateral thinking puzzle in search of solutions that have not been abused for profit.

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.

That doesn't seem to change any behavior.

I'm beginning to understand the frustration with Chrome's idiosyncrasies, as at this point I don't know where in the documentation to look for the root of the problem, let alone a workaround possible within the constraints of Javascript. As you point out, many restrictions are intentional. As it seems to be an uncommon problem, it wouldn't be worth the amount of code rewritten or added just to replicate what's currently functional on other platforms.
I recall the 'back' functionality working at one point, so it's probable that some Chrome version broke it. I will let you know if it starts working again, but for my purposes I can just use a work-around.

Thanks for your time.

Cheers.

I would genuinely like to fix this behavior. But I have only, just now, today, reliably reproduced this error. So far I have found several new ways to not solve the problem.

Changing the location and reloading doesn't work. Clicking everything .click-able doesn't work. Appending a text box and changing its contents doesn't work. Creating a new event and doing dispatchEvent doesn't work. Creating a link directly to the image URL and clicking on it does not work.

It always fails on Gelbooru... but it always works on Rule34.xxx. It's not a matter of simple_redirect versus the awful Javascript thing that I do to appease Pixiv. Both sites use subdomains to host images. Both redirect to images not currently on the page. So I just have to figure out what the hell Rule34.xxx does but Gelbooru doesn't.

Same problem on newgrounds.com