1: Problem desc

FDM seems to be ignoring the setting for the size of the file to be captured.

See the image:

https://photos.app.goo.gl/4qAVLij2WgKa1BUt5

As you can see, it is disabled, but I routinely find myself having to use the "right click link and select 'Download with FDM'" function to grab them.

On a related note, FDM seems to do a very poor job of selecting .ZIP files, having to use the same method above to get FDM to download them. The skip domains and skip files with extensions are fully default, I have added nothing to them.

I've compiled a few GitHub links to allow for testing:

https://github.com/gerardog/gsudo/releases - the MSI will not be caught by FDM, it's size is under 1 MB

https://github.com/HandyOrg/HandyWinGet/releases - no issues with .MSI files, much larger than 1 MB

In addition there are these links as well:

https://github.com/pbatard/rufus/releas ... v3.14_BETA Exe DLs fine with FDM, but .sig does not.

https://github.com/Yutaka-Sawada/MultiP ... g/v1.3.1.7 No files will DL automatically with FDM

Across all 4 links, the src code files (both .ZIP and .tar.gz) refuse to be automatically caught by FDM, and require manual override.

Tested in Firefox Nightly 90, Firefox 88 stable, Edge (Chromium) latest, & Chrome latest

2: Steps to recreate

Install FDM, pick your favorite browser and enable automatic catching links from browser, then click on the various DL links in those repositories.

3: Expected output

I expect FDM to catch the DLs that it is not catching, both the ones less than 1 MB in size of file types it normally catches, as well as .ZIP and .tar.gz files automatically.

4: OS / browsers

Windows 10 x64 20H2 (OS Build 19042.928)
Firefox Nightly 90.0a1 (2021-04-24) (64-bit)
Firefox Stable 88.0 (64-bit)
Google Chrome stable Version 90.0.4430.85 (Official Build) (64-bit)
Microsoft Edge Version 90.0.818.46 (Official build) (64-bit)

5: FDM Version

Latest (currently 6.14.1.3835 (f040724) (but both of these issues have been going on for well over a year, and that was on my previous rig as well as the current new rig I built last year).

6: Additional info

Only A/V right now is native Windows Defender, nothing else. The issue occurs on all clean installs, on all clean profiles, and and multiple browsers that I've tested (including Chrome ßeta, Chrome Developer, Chrome Canary, Edge ßeta, Edge Developer, Edge Canary, and Firefox ßeta. As it has been occurring for a long time, it is also across numerous Windows 10 builds, as well,

Any other information, please let me know and I'll include it.

Finally, let me post this link which has a variety of files that you can try and see what gets caught and what does not:

https://www.kurtzimmermann.com/index_e.html#features6-2

HDCleanerX64.zip - caught by FDM - Size (6.687 MB)
TweakPowerX64.zip - caught by FDM - Size (9.20 MB)
RegCoolX64.zip - Not caught by FDM - Size 654 KB (also, when downloaded using manual method via FDM, does not save server time date stamp)
ImageFinderX64.zip - Not caught by FDM - Size (263 KB)

So it's not *all* .ZIPs, only *some* .ZIPs in this page - and directly correlated to size, unlike GitHub links, which I believe has something to do with the URL associated with those files.

I don't think it's a problem with FDM. I have already tested it in Firefox without FDM. Firefox has problems with files smaller then 1.9 MiB (or so, possibly 2*10^6 bytes). Larger files were downloaded properly with proper file names and extensions, smaller files were downloaded with HTML wrapper and some strange names (possibly with html extension). As you report the same problem for different browsers, I suspect that it's a server-side issue.

BTW. Could you provide link to image which doesn't require Google login?

Replaced the link with one that works in a guest profile with no google login - HTH.

As for files - the Rufus-3.14_BETA.exe is just 1.12 MB in size, and gets caught with Fx and sent directly to FDM with no issues.

That's why I was finally convinced that it was the size limitation feature in FDM. Now, with .ZIP files I find it happening a lot - and sometimes regardless of size, so I think that is a separate issue. But the Rufus executable is 1172064 bytes in size, and uses 1179648 bytes on disk (SSD). So it is about as close as I could get to a 1 MB file by just searching the file repositories I frequent regularly.

There may be also other problems:
1. A well-known problem with file type internally supported by browsers and download links which don't contain file name. It's described in FDM FAQ for Firefox and linked in known issues. If you have a direct download link (as it seems to be in the case of Rufus), any browser should download the file properly or properly pass the link to FDM no matter what is the file size.
2. Deliberately broken code on some file hosting services.

In any case it's NOT 1 MB limit visible in FDM.

Yup. I anticipated some of those problems, which is why I used Git Hub links plus the Kurt Zimmerman website for the comparisons, to minimize the differences.

I've run into several websites where the filename isn't in the DL link, and if I try to force them through FDM by right clicking on the link, I get an index.html. But all of these are not like that.

E.G the first link I posted, https://github.com/gerardog/gsudo/releases - the links for file DLs are as follows:

https://github.com/gerardog/gsudo/relea ... v0.7.3.zip

https://github.com/gerardog/gsudo/relea ... zip.sha256

https://github.com/gerardog/gsudo/relea ... oSetup.msi

https://github.com/gerardog/gsudo/archi ... v0.7.3.zip

https://github.com/gerardog/gsudo/archi ... 7.3.tar.gz

If I right click any of those links in FDM, they download fine. but if I left-click them on the page, Firefox doesn't pass them to FDM.

Meanwhile in other repositories at Giuthub, the same file types will be passed from Fx to FDM via direct left-click, with the exception of the source code files, those never (thus far that I've tried) ever get passed from Fx to FDM.

And it's not all .ZIPs either, as seen in the Kurt Zimmerman website - I can directly click on 2 .ZIP (portable) files (both of which are larger than 1 MB) and Fx passes to FDM.

Now, if this is (related to) an Fx file size handling problem, it seems that it is about the same size as the (default) setting in FDM, right around 1 MB, at which point Fx refuses to pass the link to FDM. But if that is the case, then it makes sense that I thought it was FDM ignoring its file size limitation setting being disabled.

johnlgalt wrote:https://github.com/gerardog/gsudo/archive/refs/tags/v0.7.3.tar.gz
If I right click any of those links in FDM, they download fine. but if I left-click them on the page, Firefox doesn't pass them to FDM.

In most cases modern webpages use Javascript which may be executed in a different way by the browser (with left click) and FDM (with right click). That's why I have often recommended to use right click if left click doesn't give expected results, and vice versa.

johnlgalt wrote:Meanwhile in other repositories at Giuthub, the same file types will be passed from Fx to FDM via direct left-click, with the exception of the source code files, those never (thus far that I've tried) ever get passed from Fx to FDM.p

Source code on Github is always displayed like a code in a programmer's editor. You have to use "Raw" button/link to download any source file as-is.

Those are .ZIPped and .tar.gz'd archives of the source code, not the raw source itself unarchived.

As for the files and left versus right - I know this. Again, it's inconsistent and I want to rule out once and for all that it is FDM causing the issue. Because it happens across the board, yet randomly. But it does seem to be a Fx specific issue, and not directly related to FDM. I quick click on the install extension button for Edge opened the Edge extension page, and asked to remove it - I said no, and all of a sudden Edge downloads anything I throw at it through FDM no questions asked.

johnlgalt wrote:Those are .ZIPped and .tar.gz'd archives of the source code, not the raw source itself unarchived.

Are they archives of current source code or some archived build? In the first case they are created on-the-fly, with some delay - it's a case similar like in another topic: viewtopic.php?f=1&t=18499

johnlgalt wrote:As for the files and left versus right - I know this. Again, it's inconsistent and I want to rule out once and for all that it is FDM causing the issue. Because it happens across the board, yet randomly.

How many webmasters and other coders do you want to kill to keep things consistent?
They don't even follow their own standards. I suspect that the Murphy's Law is the only law which rules in that world of chaos.

Usher wrote:

johnlgalt wrote:Those are .ZIPped and .tar.gz'd archives of the source code, not the raw source itself unarchived.

Are they archives of current source code or some archived build? In the first case they are created on-the-fly, with some delay - it's a case similar like in another topic: viewtopic.php?f=1&t=18499

Current - that is the releases page from each of those GitHub links, showing (in descending order) all the releases for the project, current being at the top. Each of the links I provided as an example from the 'gsudo' project, for example, were from the latest release - 20 Dec 2020. Pretty sure they've populated by now ;p

Usher wrote:

johnlgalt wrote:As for the files and left versus right - I know this. Again, it's inconsistent and I want to rule out once and for all that it is FDM causing the issue. Because it happens across the board, yet randomly.

How many webmasters and other coders do you want to kill to keep things consistent?
They don't even follow their own standards. I suspect that the Murphy's Law is the only law which rules in that world of chaos.

Lmfao - that is what it would require, now isn't it? Sigh.

At least I got it working solidly in other browsers now. I have no idea why the addon was not working when it was clearly installed, but going through the same procedure in both Edge Chromium profiles and Chrome allowed all three profiles to grab anything I threw at it from a normal (left-click) on a link on a web page - even files as small as 488 bytes.

At least now I know.

Hello,

I've just checked - FDM catch these links in Chromium browser.

This is the issue of Firefox browser (lack of implementation) which can't be fixed on our side.

Yeah, for some reason my Chrome browser was not working correctly with addon installed. I only realized it late, after testing a lot.

As for Firefox - it's Firefox. Love / hate relationship.

Thanks for the reply, Alex.

I've no issues with FDM plugin when using v3 with Chrome, FireFox browers as of late. I do know the plugins must be updated or removed and newer version installed if you want it to work with FDM correctly.

Not with the above links. If you did try those in Firefox, you'd see exactly what I'm seeing. Even with uninstall / reinstall / clean install / clean profile.

What version of FF and is that a custom FF setup? I'll give those links a try to see what happens on my FF.

Windows 10 (take your pick, but I conducted the tests on 20H2, and am now on 21H1)

FDM Version: 6.14.1.3935 (f040724)

Firefox Nightly (it updates 3-4 times a day, no real customizations, other than making Duck Duck Go my default search engine, removing all other search engines, and installing Panorama Tab Groups and Tab Center Reborn.)

Firefox stable (no real customizations, other than making Duck Duck Go my default search engine, removing all other search engines, and installing Panorama Tab Groups and Tab Center Reborn.)

However, this exact behavior also occurs on blank profiles with 0 customizations in both Firefox Nightly and Firefox stable - so try completely clean and free and clear.