Does not work on Firefox Developer Edition 45.0a2 (2016-01-06)

[Harrald]

No errors during installation. cliget simply does not show up on download modals.

I tried restarting the browser. And reinstalling cliget.

[zaidka]

I did some digging and found that the request object passed from the download dialog no longer implements the interface nsIHttpChannel which is required to inspect request headers. Not yet sure whether this is a bug in Firefox or the change is intentional.

[char101]

It works in FF 47 nightly if e10s is disabled. With e10s, aRequest is an instance of nsIChannel but not nsIHttpChannel.

[BtbN]

After Updating to FF48, cliget stopped working for me. According to about:support, e10s is enabled for me. There are no errors, it just doesn't show up anymore.

[char101]

I have forked a version that works with e10s here https://github.com/char101/cliget/releases

[BtbN]

How do I install that on Firefox 48? It says it's unverified.

Edit: Updated to Aurora and installed it there, but it still doesn't work. The Download-Dialog remains unchanged.

On Aurora 50.0a2:

cliget:TypeError: request is undefined
Stack trace:
getDownloadCommands@resource://gre/modules/commonjs/toolkit/loader.js -> resource://cliget-at-zaidabdulla-dot-com/lib/main.js:27:5
exports.main/windowTracker<.onTrack@resource://gre/modules/commonjs/toolkit/loader.js -> resource://cliget-at-zaidabdulla-dot-com/lib/main.js:213:22
_regWindow@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:104:7
handleEvent@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:130:11
EventListener.handleEvent*EventTargetInterposition.methods.addEventListener@resource://gre/modules/RemoteAddonsParent.jsm:652:5
AddonInterpositionService.prototype.interposeProperty/desc.value@resource://gre/components/multiprocessShims.js:160:52
_regLoadingWindow@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:85:5
_regWindow@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:106:7
_onToplevelWindowReady@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:143:5
Observer<.observe@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/system/events.js:81:7
nsUnknownContentTypeDialog.prototype.reallyShow@resource://gre/components/nsHelperAppDlg.js:170:22
nsUnknownContentTypeDialog.prototype.notify@resource://gre/components/nsHelperAppDlg.js:555:9

[char101]

I have uploaded a new release. If you still get the request undefined error, it probably means that the request cache size is not enough (can be increased via the options page).

[TimoRoth]

Still the exact same "request is undefined" error. Even after increasing the cache size to 1000. Disabling filtering of Accept-Encoding results in a slightly different stack trace:

TypeError: request is undefined
Stack trace:
exports.wget@resource://gre/modules/commonjs/toolkit/loader.js -> resource://cliget-at-zaidabdulla-dot-com/lib/getters.js:16:1
getDownloadCommands@resource://gre/modules/commonjs/toolkit/loader.js -> resource://cliget-at-zaidabdulla-dot-com/lib/main.js:37:21
exports.main/windowTracker<.onTrack@resource://gre/modules/commonjs/toolkit/loader.js -> resource://cliget-at-zaidabdulla-dot-com/lib/main.js:215:22
_regWindow@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:104:7
handleEvent@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:130:11
EventListener.handleEvent*EventTargetInterposition.methods.addEventListener@resource://gre/modules/RemoteAddonsParent.jsm:652:5
AddonInterpositionService.prototype.interposeProperty/desc.value@resource://gre/components/multiprocessShims.js:160:52
_regLoadingWindow@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:85:5
_regWindow@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:106:7
_onToplevelWindowReady@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/deprecated/window-utils.js:143:5
Observer<.observe@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/system/events.js:81:7
nsUnknownContentTypeDialog.prototype.reallyShow@resource://gre/components/nsHelperAppDlg.js:170:22
nsUnknownContentTypeDialog.prototype.notify@resource://gre/components/nsHelperAppDlg.js:555:9

At one point during testing, Firefox even completely crashed on me.

[char101]

Did you restart after installing the xpi? It may be a restartless addon, but I found no restarting causes firefox to crash.

[BtbN]

Yes, I did restart it, even after a full re-install of the AddOn, but it still refuses to work with the same error. Maybe something changed in FF50?

[BtbN]

Ok, I think I found out what's going on. In the list of recent requests, the download-request is stored as "https://github.com/char101/cliget/archive/e10s.tar.gz" But getDownloadCommands is looking for "https://codeload.github.com/char101/cliget/tar.gz/e10s", which is where the first URL redirects to. Tested it with a download-site that doesn't do such a redirect, and it indeed works as expected there.

[char101]

Tried with firefox nightly 51, works here

[BtbN]

Yes, it also works on that site for me. Every "simple" download works. But for example when Downloading Github-Releases, or the JDK from Oracle, it doesn't work, because there seems to be a redirect involved. I used the zip/tgz downloads of the github release for testing.

[char101]

Thanks for the information. So the problem is that the value of channel.URI is the same as channel.originalURI even though it is a redirect. So neither channel.URI or channel.originalURI works when searching the headers in the cache.

[char101]

Should work with redirected downloads now. Apparently instead of http-on-opening-request event, it should observe http-on-modify-request.

[robot3498712]

Thanks! Working now for https://github.com/char101/cliget/releases and dropbox direct download.

[BtbN]

A new release of cliget would be nice, specially now as e10s is starting to land in Firefox stable!

[twirrim]

It is now broken for me, entirely, Running 51.0b6, with cliget version 1.2.3.1-signed.1-signed (interesting version number?)

[oilian]

Is there any progress on this.. trying out a pre build of FF 52 ESR, with e10s enabled, and cliget is not working (also the one from char101 does not enable at all)

[char101]

I'm still using it with the latest stable version without problem. By the way, isn't Firefox moving to web extensions? Maybe it's already implemented in nightly?

On Wed, Mar 1, 2017, 19:53 ohaessler [email protected] wrote:

Is there any progress on this.. trying out a pre build of FF 52 ESR, with e10s enabled, and cliget is not working (also the one from char101 does not enable at all)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zaidka/cliget/issues/27#issuecomment-283332136, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEWVyxwW0Cqg4E5XlQZXqjNcTKG1mDQks5rhWpTgaJpZM4HAOOY .

[BtbN]

I doubt this extension is possible to implement with WebExtensions. If cliget still works for you, your Firefox did not switch to e10s yet, which it will soon do though. All it needs is a new release, all the code for e10s is in place!

[roblabla]

Nightly isn't compatible with cliget since version 56, at least. It needs #45

[twirrim]

There is a native option in Firefox.

Go to the page where you'd start the download. Through the browser menu, select: Tools > Web Developer > Network.

Now do whatever you need to in the site to get the download dialogue box to appear. Hit cancel. In that network section you'll see an entry related to the download. Right click on it and you'll see the option "Copy as cURL". You can then copy and paste that anywhere you like. The one proviso is you must remember to add "-L -O" flags to the end of what it gives you.

[roblabla]

1. It's neither wget nor aria compatible
2. I need to start the download to get the curl link. Some download provider kill the link after it's been "used".
3. It's burried. What I like about cliget is that it's right there for me to click on.

This is really not a good alternative TBH.

[Zialus]

Any updates on this issue?

[roblabla]

Latest nightly killed legacy (XUL) addons entirely. This needs to be rewritten as a webextension, but webextensions don't allow theming the download popup AFAIK (Please correct me if I'm wrong). We need to take this up to moz I guess.

[BtbN]

They don't care. No idea what got into Mozilla, but they just killed the one thing that made Firefox better than Chrome.

[roblabla]

@BtbN they do care. If you want to go trolling, please go elsewhere please. We're trying to have an actual conversation here.

[BtbN]

Why are they removing the one thing that makes Firefox unique then? Everyone I talked to thinks of it as a bad decision.

So far every time I saw someone from Firefox defend the decision it sounded like marketing, and not like technical reasons.

I highly doubt the functionality of this, and a lot of other AddOns, are going to be re-gained.

[roblabla]

BtbN this will be my last reply to you : Sure, extensions might make firefox "unique", but it is also holding it back. Did you even try Nightly 57 ? It's very, very, very fast, and a lot more stable. This is not "marketing". I used to have tab crashes frequently (at least once a day, probably a lot more), yet in the past couple months I haven't gotten any. And a lot of it can be tracked down to the deprecation of legacy extensions.

You have to see that maintaining compat with legacy extensions is an enormous task, and I'm surprised mozilla didn't give up earlier, given how ridiculously out of hand it had gotten. Sure, at first it might look like "a bad decision", but go ask the actual firefox developers. They'll share a much different story with you.

Besides, this is open source ! Pale Moon, a firefox fork, plans on maintaining XUL compatibility. If you want to use XUL addons, you may use Pale Moon.

Finally, what people may not realize is that it's easy to propose new webextension API using the Webextension Experiments. Through this, you may propose new API for inclusion by mozilla, and distribute addons that depend on it. I'm going down this road right now to get CliGet back.

Some extensions are going to be hard to bring back, sure. But the gains are well-worth the pains. This is necessary for firefox's future.

[zaidka]

Sorry for the lack of update folks. I am indeed reimplementing cliget as a Web Extension for Firefox 57+. See https://github.com/zaidka/cliget/issues/46.