GetemAll! - Fork of DownthemAll!

[R3n_001]

Using my customized version of DownItAll, which is a fork of a fork of a fork (this addon), I can download it fine.

Maybe try reinstalling the addon.

[Gordon Dry]

"Bad timing" as it now works for me as well.

[GoodGuy]

There seems to be a bug where the desktop notifications are not displayed when using the OneClick function. When this happens, it is required to restart the browser to work again.

The browser console says this, but I am not sure if it is related:

Code: Select all

Error: TypeError: notification.browser.docShell is undefined
Source File: resource:///modules/PopupNotifications.jsm
Line: 473

[Wrolf]

Hi! Is PM GtA supposed to work with that scottish play? Oops, wrong department. I mean that big player north of the border, yt. cheers/W

[RealityRipple]

Noticed an issue with metalink support, caused by preallocation. Here's my patch for it: https://github.com/RealityRipple/DownItAll/commit/e0a5c2529c740ea21385d253a6eb5bba0d65359a, however, it's kind of a weird kludge and I'm not sure it's the best way to handle the issue... but it does work. See the patch notes for the full explanation of the issue.

[moonbat]

Thanks, RealityRipple. I've included it and published a new version.

[Wrolf]

Version 1.1.1
Released: July 31, 2022
Works with Pale Moon 29.0 to 29.*

Any problems with using it on 31?
cheers/Wrolf

[moonbat]

Any problems with using it on 31?

None at all, it does not use the strictCompatibility flag which would enforce the version limits. It was created and tested on 29.x, and will usually work as long as there isn't any compatibility break in future versions (which is very rare, given the stability/maturity of the codebase).

[__NM64__]

As you know, you recently made me aware of this extension and it's been working without a hitch.

That being said, I discovered a niggle that presumably existed back on DownThemAll as well, and I'm wondering if it's something that Get'emAll could alleviate... assuming it's not something inherent to the way context submenu's work.

Anyway, the niggle is simple - when "Use compact menu" is unchecked, you normally can just press the context menu keyboard key and then the 'o' key as a sort of keyboard shortcut-like quick method to activate Get'emAll OneClick.

But when "User compact menu" is checked, then this method no longer works and you instead have to manually first open the Get'emAll context submenu whether by pointing your mouse cursor on it or by pressing the up or down arrow keys enough times to highlight it and then pressing the right arrow key.

So yeah, I don't suppose this simply an inherent thing with the way context submenus behave?

[opus_27]

With "Use compact menu" checked, try tapping the context menu keyboard key and then tap the "G" key; you may need to tap it more than once depending on other items in your context menu.

[__NM64__]

Actually I'm starting to wonder if this is a bug since the behavior is different depending on whether you press the 'g' key (for normal "Get'emAll") or the 'o' key (for "OneClick").


As I previously stated, if you press the 'o' key for "OneClick", it behaves as if it doesn't even exist no matter how many times you press the 'o' key unless you already manually expanded the submenu. But if you press the 'g' key for normal "Get'emAll" without manually expanding the submenu, it will still be able to highlight normal "Get'emAll" but without actually selecting/activating it (pressing the 'g' key a second time does however select/activate it).

Conversely, if you have "Use a compact menu" unchecked, then both the 'o' and 'g' key will instead instantly select/activate "OneClick" or normal "Get'emAll" respectively whenever the context menu is open.


I'm also wondering if the OS makes a difference here (I'm on Linux Mint 20.3 Xfce), e.g. if it's just following normal OS-defined context menu behavior. Also to be clear, there are no other entries in my context menu that the 'g' and 'o' keys would select instead.



UPDATE: Alright I think I've figured it out - the submenu itself can be expanded via the 'g' key, but this was not apparent to me because the text label for the 'Get'emAll' submenu does not have the G underlined like is the case for the normal "Get'emAll" entry within the submenu itself.

Nevertheless, due to my small hands and my use of the Colemak keyboard layout, reaching the 'g', 'o', and context menu keyboard keys with one hand is very difficult compared to pressing the context keyboard key and then pressing the 'o' key (which are even closer together on Colemak than on QWERTY). That is... unfortunate; I guess I'll need to remove some additional context menu entries in order to get it down to 18 in total due to the context menu not repositioning itself issue.

On that subject, it would be nice to have separate enable/disable checkbox options for all 4 of the context menu entries that GeA creates, and maybe even the ability to specify which context menu entries go into the submenu and which ones remain in the main menu.

[Moonchild]

All this is normal menu behaviour. It's exactly as designed.
Meaning: access keys for submenu items do not work in the parent menu item (think about it, that would be really bad because it would recursively make all access keys in all menus available everywhere). You can only use access keys for menu items in the currently active menu.

As for the underlining, access key underlining is case-sensitive. If the menu item is "GetEmAll" then while a lower-case 'g" as access key does work, it will not underline unless the access key is "G" (Upper case).

[__NM64__]

As for the underlining, access key underlining is case-sensitive. If the menu item is "GetEmAll" then while a lower-case 'g" as access key does work, it will not underline unless the access key is "G" (Upper case).

But the actual normal "Get'emAll" menu selection within the submenu has the uppercase 'G' underlined yet still works when pressing the 'g' key on your keyboard without having to hold shift or have caps lock enabled.

[Moonchild]

That's what I just said.
The functionality works case-insensitively, it's just a visual thing.

[__NM64__]

it's just a visual thing.

I think a screenshot would make things easier here:

screenshot.png

As you can see, there's only an underline on the "Get'emAll" entry within the submenu yet the (lowercase) 'g' key works for both opening the submenu as well as selecting/activating the normal "Get'emAll" entry within that submenu.

Is this not an inconsistency? Shouldn't it be that either both have the 'G' underlined or neither have the 'G' underlined, not just one or the other?

[Moonchild]

They are 2 different entries.
The string may be the same but the identifier likely is not. And one will have 'g" as access key, no underline, while the other will have "G", resulting in an underline.

[moonbat]

The difference is between a menu shortcut and an accelerator shortcut. An accelerator shortcut is one that works across the application without requiring any menus to be open - clipboard shortcuts like Ctrl C,V,X are an example (by convention, these tend to be Ctrl + some key). Menu accelerators are used to activate an option on a currently visible menu. All goes back to early days of Windows when it was likely that someone may not have a mouse or a busted mouse and it would necessitate keyboard navigation across an application.

So in this case, you're expecting accelerator behavior from what is a menu shortcut, and it is working as intended. Besides, the feature is called One Click, not One Keystroke

[RealityRipple]

Added a small change to read the "deprecated" but still webserver-supported content-md5 header as another way to detect a hash for a download: https://github.com/RealityRipple/DownItAll/commit/234d75245e033d51b69ea048b6e25576cdaa49c7. Sounds like it was deprecated because of Partial Content responses, but as long as you read it from the initial 200 request and ignore any changes from subsequent 206s (which the code does already), it should be fine. It's too bad the header's definition wasn't kept and improved for partial-content, since that would open the door for checking for corruption at a chunk-level, rather than the entire file, but I guess that's a little resource-intensive server-side.

[pm29_2008r2]

gta and userchromeJS are incompatible

Copy link and Add download link manually cannot be used

userChrome_js.js

Code: Select all

/* ***** BEGIN LICENSE BLOCK *****
 * Version: MPL 1.1/GPL 2.0/LGPL 2.1
 *
 * The contents of this file are subject to the Mozilla Public License Version
 * 1.1 (the "License"); you may not use this file except in compliance with
 * the License. You may obtain a copy of the License at
 * http://www.mozilla.org/MPL/
 *
 * Software distributed under the License is distributed on an "AS IS" basis,
 * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
 * for the specific language governing rights and limitations under the
 * License.
 *
 * The Original Code is the userChrome.js component.
 *
 * The Initial Developer of the Original Code is
 * Simon Bünzli <zeniko@gmail.com>
 *
 * Portions created by the Initial Developer are Copyright (C) 2007
 * the Initial Developer. All Rights Reserved.
 *
 * Contributor(s):
 * alta88 <alta88@gmail.com>
 *
 * Alternatively, the contents of this file may be used under the terms of
 * either the GNU General Public License Version 2 or later (the "GPL"), or
 * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
 * in which case the provisions of the GPL or the LGPL are applicable instead
 * of those above. If you wish to allow use of your version of this file only
 * under the terms of either the GPL or the LGPL, and not to allow others to
 * use your version of this file under the terms of the MPL, indicate your
 * decision by deleting the provisions above and replace them with the notice
 * and other provisions required by the GPL or the LGPL. If you do not delete
 * the provisions above, a recipient may use your version of this file under
 * the terms of any one of the MPL, the GPL or the LGPL.
 *
 * ***** END LICENSE BLOCK ***** */

Components.utils.import("resource://gre/modules/Services.jsm");
Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");

function UserChrome_js() {};

UserChrome_js.prototype = {
  // Properties required for XPCOM registration:
  classDescription: "userChromeJS Loading Component",
  classID         : Components.ID("{8DEB3B5E-7585-4029-B6D0-4733CE8DED50}"),
  contractID      : "@userChromeJS;1",

  _xpcom_categories: [{
    category: "app-startup",
    service: true
  }],

/* ........ QueryInterface .................................................. */

  QueryInterface: XPCOMUtils.generateQI([Components.interfaces.nsISupports,
                                         Components.interfaces.nsIObserver,
                                         Components.interfaces.nsIModule,
                                         Components.interfaces.nsIFactory,
                                         Components.interfaces.nsIDOMEventListener]),

/* ........ nsIObserver ..................................................... */

  observe: function(aSubject, aTopic, aData) {
    switch (aTopic) {
      case "app-startup":
      case "profile-after-change":
        Services.obs.addObserver(this, "final-ui-startup", false);
        break;
      case "final-ui-startup":
        var file = Services.dirsvc.get("UChrm", Components.interfaces.nsIFile);
        file.append("userChrome.js");

        if (!file.exists()) {
          var componentFile = __LOCATION__;
          var componentsDir = componentFile.parent;
          var extensionDir = componentsDir.parent;
          extensionDir.append("README.txt");
          if (extensionDir.exists())
            extensionDir.copyTo(file.parent, "userChrome.js");
        }

        if (file.exists() && file.isFile() && !Services.appinfo.inSafeMode) {
          this.mFileURL = Services.io.getProtocolHandler("file")
                                     .QueryInterface(Components.interfaces.nsIFileProtocolHandler)
                                     .getURLSpecFromFile(file);

          Services.obs.addObserver(this, "domwindowopened", false);
        }
        break;
      case "domwindowopened":
        aSubject.addEventListener("load", this, true);
        break;
    }
  },

/* ........ nsIDOMEventListener ............................................. */

  handleEvent: function(aEvent) {
    var document = aEvent.originalTarget;
    if (document.location && document.location.protocol == "chrome:") {
      try {
        Services.scriptloader.loadSubScript("chrome://userChromeJS/content/userChromeJS.js",
                                            document.defaultView,
                                            "UTF-8");

        Services.scriptloader.loadSubScript(this.mFileURL,
                                            document.defaultView,
                                            "UTF-8");
      }
      catch (ex) {
        // script execution can be stopped with |throw "stop";|
        if (ex !== "stop") {
          Components.utils.reportError(ex);
        }
      }
    }
  }

};

/**
 * The following line is what XPCOM uses to create components. Each component
 * prototype must have a .classID which is used to create it.
 * 
 * XPCOMUtils.generateNSGetFactory was introduced in Mozilla 2 (Firefox 4).
 */
var NSGetFactory = XPCOMUtils.generateNSGetFactory([UserChrome_js]);

userchromejs-2.0-sm+tb+fx.xpi

userChromeJS_Mix.xpi

QQ图片20220903195251.png

QQ图片20220903195257.png

QQ图片20220903195308.png

[moonbat]

gta and userchromeJS are incompatible

And? Contact the author of user chrome JS and ask them to make it work with Pale Moon.