Tampermonkey / tampermonkey

Tampermonkey is the most popular userscript manager, with over 10 million users. It's available for Chrome, Microsoft Edge, Safari, Opera Next, and Firefox.
GNU General Public License v3.0
4.17k stars 416 forks source link

GM_download start takes 10+ seconds now #2147

Open Owyn opened 1 month ago

Owyn commented 1 month ago

(Please fill out the issue template with your details)

now when I do GM_download - it now has at least a few second delay or even like 10 seconds for the save_as window to pop_up - even if I don't use original filename but set up my own - could you perhaps make it fetch original filename only if name is null but not otherwise? should be easy to check before and not fetch the server filename making users wait for no reason

Expected Behavior

instant

Actual Behavior

can be 10 or more seconds for a save as window to pop up

Specifications

Script

Example script: https://github.com/Owyn/HandyImage/raw/master/HandyImage.user.js

example url with a video to save via CTRL+S hotkey (SFW): https://danbooru.donmai.us/posts/7905903?q=animated+rating%3Asafe

derjanb commented 4 weeks ago

@Owyn this fix did not involve any changes that could modify timing. It only made the name parameter optional and used xhr headers in case "xhr based" download is used ("Download Mode" set to "Native" or "Default")

When testing I see a background xhr request happening first in "Native" mode and no background xhr request in "Browser API" mode.

So do you see this in "Browser API" or "Native" mode? If "Browser API", then I can't fix this because download is entirely handled by the browser otherwise please check whether the "xhr based" download at the background page takes that long...

Thanks.

Owyn commented 4 weeks ago

I have "default mode" set in my Firefox TM image

background xhr request

it might be background yes but the downloading still waits for it to end start showing "save as" window so it doesn't really matter that it's background since it's "blocking"

the request still happens even tho the filename is specified, no?

could you test some faraway image host to actually have a high ping to test this? e.g. one in japan or australia

e.g.: https://zip.2chan.net/2/src/1723650427946.jpg (japan) https://austockphoto.com.au/imgcache/uploads/photos/compressed/worker-finishing-up-job-cleaning-sticks-off-the-lawn-after-felling-a-tree-austockphoto-000142634.jpg (australia)

before that fix - download's "save as" was definitely popping up instantly always

derjanb commented 4 weeks ago

In every mode except "Browser API", the file is downloaded via xhr first and only then passed to the browser to show a save dialog. It has always been like this... 🤷

before that fix - download's "save as" was definitely popping up instantly always

Only possible in "Browser API" mode.

Owyn commented 4 weeks ago

Browser API seems instant yea (and even "save as" works fine)... but then using server filename stops working

Can you maybe make Browser API default and if the filename is null (use server filename) - use other download mode which supports it?

or make an option - a 2nd choice of download mode just for the server-named files: image

cuz now it seems like a huge downgrade to use the default one instead of Browser API, - I click to save the image - nothing happens, I click again & again & again... the same, I switch to another tab and do other things and after like half a minute 10 windows of "save as" all together pop up 😡 while before (with browser api) I could do the thing instantly but now I must wait at least some seconds each time while just staring at the screen waiting for it to pop up