Extensions in Firefox 58

With the release of Firefox Quantum on November 14, 2017, we officially entered a WebExtensions-only world for add-on development. While that event was certainly the newsoftheday, Firefox 58 quietly entered Beta and a host of new APIs and improvements landed. As always, documentation for the APIs discussed here can be found on MDN Web Docs.

Additional Theme API

The API around themes continues to grow, allowing you customize even more of the browser appearance. In Firefox 58, you can now:

Use colors.bookmark_text as an alias for colors.toolbar_text to better support porting themes from Chrome to Firefox.

Use theme.getCurrent() to get the ID of the current theme (on a per window basis, if desired).

Listen for theme.onUpdated() to know when a static theme is installed or uninstalled, or a dynamic theme is updated.

Reader Mode API Added to Tabs

The API available for interacting with tabs continues to grow. Firefox reader view (or reader mode) strips away clutter like buttons, ads and background images, and changes the page’s text size, contrast, and layout for better readability. It can even read the page out loud to you, if you want.

The image below shows a page that can be viewed in reader mode, indicated by the page icon in the URL bar (circled in red).

Clicking on the icon puts the page in reader mode, removing most of the page elements except the text and adding buttons to the left-hand side that modify the reading experience.

This powerful browser feature is now available via the WebExtensions API.

tabs.Tab.isArticle – boolean value shows if a tab is an article and thus supports reader mode

Improved webRequest API

Extensions can now easily get the entire URL ancestor chain, even in an HTTP environment. webRequest.onBeforeRequest() now includes another parameter in its callback object called frameAncestors. This is an array that contains information for each document in the frame hierarchy up to the top-level document.

Additionally, to enable proxy authorization to work smoothly, webRequest.onAuthRequired() now fires for system events. If an extension has the correct permissions, it will be able to use onAuthRequired to supply credentials for proxy authorization.

Flexible XHR and Fetch Headers

When a content script makes requests using the standard window.XMLHttpRequest or window.fetch() API, the Origin and Referer headers are not set like they would be when requests come from the web page itself. This is often desirable in a cross-domain situation so that the content script does not appear to come from a different domain.

However, some sites only allow XHR and fetch to retrieve content if the correct Referer and Origin headers are set. Starting in Firefox 58, the WebExtensions API permits the use of content.XMLHttpRequest() and content.fetch() to perform requests that look as if they were sent by the web page content itself.

Improved Content Security Policy (CSP) Handling

Work also continues in the WebExtensions CSP area. Starting with Firefox 58, the CSP of a web page does not apply to content inserted by an extension. This allows, for example, the extension to load its own resources into a page.

This is a fairly large effort requiring some substantial architectural work. In Firefox 58, the first part of this work has landed, permitting basic injection of content generated by DOM APIs. There will be follow-ups for parser-generated content and inline stylesheets and scripts.

The user will also see if their default search engine has been overridden in the Options (about:preferences) page, which is explained in more detail below.

User Notification of Extensions Overrides

As the scope and power of the WebExtensions API increases, it is important to maintain the user’s security and privacy. In addition to the permission dialog that a user sees upon installation, Firefox tries to make sure that users are aware of which parts of the browser are under the control of an extension, and provide a way for them to revert back to default behavior, if desired.

Firefox 58 landed a couple of features in this area. First, when an extension has taken control of the New Tab Page, a notice is shown in Options (about:preferences) along with a button to disable the extension. This is shown in the screenshot below.

Along similar lines, if an extension has set a user’s default search engine, this will be shown on the Options (about:preferences) page.

Over the next few releases expect to see Firefox show even more areas where an extension is in control of a browser behavior along with options to revert back to a default state.

Additional Privacy Controls

In keeping with Mozilla’s mission to protect an individual’s online security and privacy, two new browser settings related to user privacy are now exposed via the WebExtensions API. Within privacy.websites, we’ve added:

firstPartyIsolate – This preference makes the browser associate all data (including cookies, HSTS data, cached images, and more) for any third party domains with the domain in the address bar.

resistFingerprinting – Browser fingerprinting is the practice by which websites collect data associated with the browser or the device it’s running on to personally identify you. This preference makes the browser report spoofed information for data that’s commonly used for fingerprinting.

Browser Action Fixes

A number of changes landed in Firefox 58 that fix issues with Browser Action buttons:

Support for PKCS #11 Security Devices

Firefox supports manual installation of external security devices via a dialog under the Options (about:preferences) screen. Now, WebExtensions includes API support for PKCS #11 security devices. Similar to native messaging and managed storage, a native manifest must be installed outside of an extension before the API become useful.

We continue to receive a lot of feedback from developers and, based on that feedback, work is progressing on new features for Firefox 59 and beyond. Expect to see the WebExtensions API improve and grow, particularly in regards to the organization and management of tabs, as well as the theming API. As always, thank you for using Firefox and helping ensure that individuals have the ability to shape the Internet and their own experiences on it.

You can always use a password manager like bitwarden (free open source) or Lastpass (freemium).
Mozilla has to satisfy as many users as possible. Someone else will care for that tab in reader mode add-on

Firefox 57 and Quantum are definitely big achievements. But at the same time you destroyed a lot of great addons, like SESSION MANAGER. I am staying with Firefox 56 (or Waterfox) until you will solve the problem (see below). Firefox is going to loose a lot of advanced users.

This is a good example of an API which had to be implemented *before* switching of classic XPCOM extension logic. You even acknowledge that many classic extensions make use of them.

The implementation should not be on the radar, it should have been implemented in Firefox 55 or earlier, and when that turned out to be impossible (e.g. for resource reasons) then a plan B should’ve been implemented. (Where in plan B anything could’ve been possible, from delaying the Quantum upgrade to only disabling the part which is significantly changed internally and has a working WebExtension alternative).

As above suggestion is not executed the only good step Mozilla can take is to ensure that toolbars are implemented for either Fx59 or Fx60 – it *suprises(!)* mee that it seems that the related bug has not seen action from Mozilla for over 3 months(!). And you are still suprised why there are huge complaints from the (user) community about the way the process around WebExtensions/Fx Quantum is handled?

I agree.
APIs for all major addons (let say 50) should be ready at least 5-6 months before switching off support for XUL addons.
Alternatively, FF56 ESR should be introduced with longer support for at least 1 year (until APIs for WE are ready for major addons). That way you could have FF57+ with cutting edge technology allowing to improve support for WE and at the same time support for old XUL addons.

Great that FF is moving on to the new APIs. But the decision to hack up the addons website seems rather stupid. Instead of migrating old and TB/Seamonkey addons to a new site, why not just open a new site for the new addons? Why break the old stuff when the new stuff is new? Just makes little sense. I am surprised.

PLEASE, PLEASE, PLEASE add a preference to always open URLs entered in the address bar in a new tab, rather than just using whatever tab happens to be open at the time (and please allow this to happen by default, without using any special key combinations or mouse clicks!).

Agree with that one. There is a preference for the search bar, so it doesn’t make much sense not to have it for the url bar. Moreover, it kind of removes the purposes of pinned bars if you happen to type an address in them.

I really, really encourage you to implement this feature. For now, it’s the single Tab Mix Plus feature I’m missing. I have used Tab Mix Plus as long as I can remember, and I have always been used to being able to configure, that anything opens in a new tab, including the address bar. And no – please don’t tell me to use Alt+Enter for this. I tried switching to Chrome for a period, but being forced to use some weird extra key combination for something I’ve grown so used to doing just by pressing Enter is just … painful. I skipped Chrome, and now I currently use a combination of Firefox ESR and a Chromium based browser, where this is possible to configure.

After I have given Quantum a real spin, I would really like to go back to Firefox, as the speed improvements is quite massive. But this is a deal breaker to me. Please consider adding this as an about:config parameter or API, so we can get Tab Mix Plus back.

“And no – please don’t tell me to use Alt+Enter for this. I tried switching to Chrome for a period, but being forced to use some weird extra key combination for something I’ve grown so used to doing just by pressing Enter is just … painful. I skipped Chrome, and now I currently use a combination of Firefox ESR and a Chromium based browser, where this is possible to configure.”

The catch is that after the current Firefox ESR runs out, Mozilla probably will (semi)hide or even remove legacy extensions from their addon site, so having a browser that still supports them is just part of the solution. But some authors of “legcy” extensions seem to be willing to continue development even after they are declared dead.

Although there is much to criticize about the process, moving to Chrome will not help I’m afraid. AFAIK Chrome has a more limited add-on API already and has a similar theming option.

On the other hand it would have been better that Mozilla members were using common sense when planning this. The fact that the change over is not scheduled just after and ESR release is just plain stupid. And even after I suggested that Mozilla creates a ‘special’ ESR from Fx 56 they just ignored this.

Creating Firefox 56 ESR and moving the people using the classic XPCOM based add-ons to this features until either all their add-ons have been converted completely (which implies that the API exists and is complete) or to the next year (when an ESR based on WE only Firefox is released) would have given Mozilla 1 year to implement missing features without a bat user experience to those users…

Not creating a Firefox 56 ESR was a big mistake, no matter how much abandoning the legacy extensions was inevitable. It seemed Mozilla wants to make the past forgotten asap, and a legacy ESR release would mean presenting all the legcy addons on the site for a longer tme.

Now Mozilla rushes to create new api hooks to replace lost functionality by neutered webextension ports of legacy addons – but in the meantime many users will jump ship to Chrome or user-friendly Chrome derivatives like Vivaldi.

But hope dies last, eventually Mozilla might branch a Firefox 56 ESR and use the time gained to create apis for more popular legacy addon features.

Although it may be helpful to have an API related to the reader mode, the priority Has To Be the API-s used by the classic add-ons. It would be helpful for everyone if Mozilla starts planning features and make these plans public. Just do a strict planning (like is done with killing the classic XPCOM add-on API), so that people who’ve been using add-ons which no longer works due to missing APIs know when to expect the functionality back as a supported API – of course add-on authors need to update their add-ons as well, but without the API in the first place they cannot do anything.

The planning should allow for all classic functionality* to be implemented within 1 year, starting with the most used functionality in the past. (I.e. the top 25 add-ons should be available again *WITHOUT* compromise within 3 months), the top 50 in 6 months and the top 100+ in one year.

*: Before creating a list of top-xx add-ons obvious legacy add-ons (like Firebug) and theme related add-ons (including those who did have an impact on the UI which Mozilla no longer wants to support/allow) should be removed from the list.

Just to give an example of an add-on which did have a proper user experience, but due to the limited functionality of WE no longer has a correct UX: Tile Tabs did work fine using the classic XPCOM API – now using WE it is barely usable.

Perfect is the opposite of done, and the quest for API perfection has left a multi-month gap where a large variety of extensions are not possible. I wish there could have been a set of good-enough transition APIs, with plenty of warnings to developers and even users, to be phased out as the proper APIs are added.

Filesystem access (hey! without that, each extension will need to create a file manager UI on top of available storage APIs and train users! It won’t automatically have familiarity, internationalization, or interoperability effectively for free!), low-level networking, being able to hide tabs…

Worse, at least two of the bugs for such features have disabled comments, effectively the ultimate statement of “wait for it, and accept whatever we give you” to users and extension developers.

The progress that *is* being made is fantastic, I just wish that this ravine of incompatibility never made it to release, much less beta.

Session Manager stopped working in FF57. Can you incorporate functions of this addon directly into Firefox? Maybe with connection to Firefox Multi-Account Containers?
Alternatively, can you create missing APIs required by Session Manager (APIs needed — bugs @ bugzilla: 1378647 (unassigned), 1378651 (unassigned), 1381922 (unassigned), 1284886 (solved), 1322060 (solved), 1322485 (solved)).
Firefox 57 and Quantum are definitely big achievements. But at the same time you destroyed a lot of great addons, like SESSION MANAGER / TAB MIX PLUS. I am staying with Firefox 56 (or Waterfox) until you will solve the problem. Firefox is going to loose a lot of advanced users.

Developers can’t migrate to new WebExtension untill you give them tools to do it. For example silent printing and set printer on fly were unique features for firefox and disabling that was huge mistake.

I’m very glad to see the continued development of APIs for Quantum and beyond. There are multiple Legacy addons I have that cannot be upgraded to WebExtensions because as of now there is no API for their functionality. I would consider it a significant priority that Mozilla please attempt to develop these APIs ASAP, so that users can have a better experience.

For instance, we need a secure way for extensions to work with the password database. I’m very glad that KeeFox works (a massively important addon for those who use Keepass databases instead), but say “Password Exporter” which allows users to back up their Firefox Password Database by exporting it into .csv / .xml etc…. is not possible thanks to lack of API. Ideally, it would be nice if Firefox not only offered an API for this, but included a native way to export to file in both encrypted and plain text formats.

I’m glad to see the theming engine getting an extension to its API, but please please add a function in 58 or beyond that allows for the generation of new “bars” as part of a theme or addon. For instance, I’m a fan of “Download Status Bar” or “Download Manager (S3) ” legacy addons which showcase downloads as little ‘blocks” on a special bar as well as offering other functionality, but they cannot be updated to work with FF Quantum because of a lack of API! Likewise, “The Addon Bar Restored” was a fantastic legacy extension for those with lots of addons, allowing users a separate bar like pre-Australis themes for their addon icons, in addition to the normal space where they reside currently. Without that API, this can’t be added. Though honestly, I’d be appreciative if it could be added as a native feature of FF Quantum under “Bars” when in Customize mode – the ability to spawn an extra bar to put additional functions of any sort should be built in!

While we’re talking of downloading , we need API extensions for this as well. Addons such as “DownThemAll” and “FlashGot” aren’t working at all at the moment, and “Video Download Helper” has to resort to using a separate, local program as a workaround. Please give us powerful downloading addons again!

Lastly, I’ve also noticed that we’re lacking addons regarding privacy and security functions. “Privacy Settings” , a now-Legacy addon that would explain and give the option to modify certain about:config variables from a addon icon w/drop down menu, is not able to work because of lacking APIs to do so. Likewise, the very useful “Private Tab” would allow users to load a single tab in Private mode instead of needing a whole different window. It too cannot work thanks to limited API dealing with tabs and privacy/private mode functions. This too sounds like something that could be built in to Firefox though – I understand the rationale for requiring a separate Private window, but especially with your new Container Tabs, I don’t see any problem with allowing users to enable Private tabs in the Settings menu after a warning telling them to pay attention etc.

Oh and regarding Container Tabs, if the functionality is built in to FF57 now, it seems like the “Multi-Account Containers” extension should either be installed by default and/or easy to get with a link from the settings menu – especially if one of your other addons requires the container tabs feature be checked. Otherwise, users can see options for Containers but have no way to actually spawn them or even know exactly how they work. I know that right now the walk through is built into the addon and that’s fine, but just give people a direct link to the AMO installer page next to “Learn More” (which by the way is still talking about containers as if its part of Test Pilot; I’;m sure this will be updated).

I have long supported Firefox because of Mozilla’s stance on privacy and open source on the web, making FF the biggest and best supported “noob to guru useful”, extensible, open source, multi-platform (Linux preferring user here!), browser around. Quantum is a great step forward and I know there will be some adaptation and kinks to work out, but these API improvements to replicate some features from the XUL days are important to showcase Firefox’s benefits and keep older users on the platform – where frankly, some have gotten annoyed that these APIs were not present by Quantum launch, cutting off their main reason for sticking to the browser when Legacy APIs were no longer available.

We also need to keep going with new and better features ( per-tab or per window sandboxing ?) etc… because it will be hard for Firefox to pull though on ideology alone if users feel that Chrome or others offer better features; we need to be open and ethical, without giving up functionality; Please keep pushing onward!

P.S. – Thunderbird needs a Quantum upgrade, not just aesthetically but in terms of functions too! I’d love to see functionality added to enable full, encrypted connection to those like ProtonMail and Tutanota that run OpenPGP/GnuPG style encryption in the browser. Right now, using IMAP is less secure and leaks metadata, so working on an open method of giving parity security, be it built in or extension, would be a big feature. Likewise, support for Gmail style Mailboxes/filtering besides just additional folders etc. How about namedropping NextCloud and checking up on WebDAV support? Thunderbird is a great program that deserves a Quantum upgrade and a full, modern revival to become a fantastic PIM/communications platform!

Yeah, nice how they broke VDH and a bunch of other nice add-on’s. Makes my job take 3 times as long now. I rolled back to the older version 52 and changed my update preferences. I won’t auto update now until I review the notes and user responses. This last update basically ruined my productivity in Firefox and that is completely unacceptable. Mozilla broke 85% of the add-on’s I use so good job in the QA department boys. What good is Quantum when you lost all the nice things that make it a useful tool? Exactly.

If the API does not get better so the devs can make great addons or port their legacy addons, it will be very bad. I really mean that. I always talked very good and it was deep out of my heart for firefox. Firefox WAS great because of their addons. I have addons that are legacy and the devs can’t port it because of the limitation in the API. Yes, I already talked with them. They even are putting it on the addons page. It’s firefox fault!

I still miss a new tab icon, can you please push that back. If users want it, they can move it to their bar. If not, it will stay in the hidden section.

Addons that are legacy and can’t port because of API:
Open download, who does not want to run applications or pdf files without saving them?!
Download manager: who does not want to be in control of their speed and how far the download is, just in their status bar?
Double click close tab: why do we have to go to the close button and close it?

Well to bad. I hope they really care about me as a loyal user and all the others.

I’m just not seeing the so called speed improvement with FF 57 everyone is talking about. It is certainly no faster than FF 56.0. When I install the proper ublock origin (1.14.8) in FF 57, the browser slows down even more by a second or two at least on startups to homepage and because of this FF 57 is the slowest browser I have tried.

Palemoon, IE 11 and FF 56+ all load faster to homepage for me than FF 57. With PM and FF 56 – this is when using the older ublock origin non webextension version – which has no effect on browser speed (other than perhaps speeding it up) esp launch. The newer UO web extension seems to slow the browser (FF56 and FF57) a little. Is that a web extension technology issue?

Additionally, FF 57 seems to use more memory and cpu, not less. FF wise, I’m sticking with FF 56.0 for now. I use it with two legacy extensions which kills electrolysis and the processes by default and keeps my cpu fan calm. Also using Palemoon which is much faster then FF 57 realworld and Chrome as a distant backup. Chrome in my experience (and also according to recent reviews) is also just generally faster than FF 57.

When I need to use Firefox, I am stuck with 52 ESR, since Classic Theme Restorer does not have APIs to fix the latest UI changes —useless from my point of view—

In particular I would like to see APIs that would allow to:
– Have Tabs on bottom
– In the awesome bar, go back to pre- FF48 double line autocomplete results and getting rid of the annoying ‘visit’ link in the suggestions.

In the mean time, Safari has become my main browser; since version 11,it is getting pretty good

I have updated to the latest version, like the new version but it’s become nightmare, how can i roll back to older version, new version is extremely slow on response, if i need click on a link it doesn’t give me the indication that i am about click on, scrolling the browser up and down terrible, now everything become snail process on the Firefox quantum, by the way i am using windows 10 with boot camp. i had reinstalled but no improvement. can someone fix it greatly appreciated.

Sorry … but none of these new features is attractive enough for me if it means it will break most of my current add-ons. My firefox keeps prompting me to upgrade … but I just click the “Not Now” button.

Why did you make FF57 WebExtensions-only when that API is not even remotely feature complete? You are talking about adding more support in FF58 and even FF59? What kind of way is this to manage a project?

Please develop webextension apis to such an extent that a legacy extension shim can be written in it to provide 100% portability to legacy extensions. I wont be updating to 57 until that is possible and done.

If i wanted to use chrome, I would use chrome. Stop making a crappier version of chrome and make a better version of Firefox.

-left right and middle click seperation for action buttons, so they can do different stuff with one button very easily

-custom button , in the sdk buttons i can just go into the buttons add a few div´s and text or whatever and make my own button more usefull with more information( my button begins to blink with the new ip if it changes) but you could also display downloadspeeds or whatever directly in the addon bar

– css styles for tab background and text which can be triggered individually for each tab and can also be saved together with the session data

Also please add a
DEDICATED ADDONBAR , switch it on in the preferences or something , the small bar beside the url bar IS OBVIOUSLY NOT ABLE TO HANDLE 20 or 30 addons , thsi is such a nobrainer

A tab placement API is being worked on right now. It won’t make it for 58, but should appear shortly afterward. Hooks into the keychain service are under discussion (primarily for security review), and session manager API are on the roadmap.

Are hooks for reviving “Mozilla Archive Format” being worked on, too? Even Chrome supports .mht, and the .maff format was propagated for a long time by Mozilla themselves (hence the name). It would be nice if Mozilla would show some faith and acknowledge that abandoning users’ archived data was a bit premature.

The “Save Page WE” is not replacement or viable alternative as it cannot save the full page in many case, and it produces large files that can only contain a single page.

Please improve support for user security & privacy. In particular, improve extension Design Guidelines by requiring WebExtension developers to design extensions in a modular way aiming for most of now required Permissions converted to Optional, thus revocable by users after install. Also, expose a list of current permissions in Extension Details on Add-ons page, and update GUI allowing to revoke optional permissions on that page. Advice developers to provide detail description in Help or on Details page, what features are enabled by each permission separately, and will be disabled if revoked. Extremely important: provide browser users with a way to promptly disable any extension on certain websites that require more privacy, such as banking websites. The easiest way to do it is adding “Disable in Tab” or “Disable on Domain” browser (not extension) controlled option to RMC Menu of each extension button placed on the browser toolbar. Currently users must open Add-ons page to access global Disable Extension option, which is extremely inconvenient, when several Tabs are open, and some require more privacy than other. That would allow to stop input monitoring by extensions on sensitive pages regardless of developer desire, so browser behavior control would be returned to its user as it should be.

Points well raised, concur with the aspects of extension scrutiny and safety. It would be handy to combine with the container feature, such as an option set to disable extensions on containers used for banking.

Also the extension permissions should not just show once during installation but should be permanent display in the details of the extension listing

“The most important thing I want to emphasize is that we intend to go to great lengths to ensure compatibility with add-ons. We realize that add-ons are extremely important to Firefox users, and we have no intention of abandoning or disrupting add-ons”

… which was shortly before it was announced that all legacy extensions would be abandoned. But what about FEBE, S3 Download Manager, Classic Theme Restorer, Tab Mix Plus, … ? What takes the cake is dropping MHT/MAFF without any replacement, making libraries of saved websites inaccessible.

Firefox 57 on xubuntu broke the previously working integration with the gnome keyring by not providing the required API. That is an enormous usability lapse. I did switch to Chromium, which was easy before the upgrade to Firefox 57, since it automatically imported all login credentials and did store it in the keyring.

It is totally incomprehensible to me how Mozilla did not address such a key topic as credential storage in a user friendly manner (which is exactly what keyrings provide) before making the existing add-ons that accomplish this unusable. Instead, they focused on totally secondary topics like another screenshooter.

One lost user here who used Firefox happily before for ages. Only positive point is that it made me realize Chromium is doing all I need seamlessly.

At work, I have to change my password regularly. Since this domain password is used on about 30 pages, I used “Saved Passwords Editor”, which allowed me to update all of these logins at once.

Unfortunately, this addon has stopped working now. Migrating to another password editor (e.g. lastpass) is also not an option, since there are no tools available, that can access the passwords from the current store.

So I can choose between editing all 30 domain-logins manually each month, or copying all of my logins manually to some other password manager.

By the look of unattended a/o long standing bugs in Bugzilla and bogged down developers it appears that M has not the necessary interest/focus/resources on WE but is rather keen to make good on the mainstream market.

It does not seem that they are bothered by losing few from the advanced user crowd, which likely will be offset easily in the mainstream market. In the end FF is not an idealistic project but a commercial machine that needs to feed some bread winners.

Maybe the Vivaldi crew will make a difference, at least they give a try as it can be expected from a new entry. Paying attention to details such as coherent colour themes and not like FF with a dark lwt shell that opens than to a blinding interior.

With respect, many add-on authors have asked for many APIs to be added to WebExtensions over the last 12+ months and while I appreciate Mozilla can’t implement all of it, much of it hasn’t even been triaged for approval.

Could this please be prioritised so that potential contributors at least know where they stand? Nobody is going to volunteer code that could be later veto’d at the policy level (for what often seems like arbitrary reasons).

In fact, that reminds me. Could you (the “royal you”, meaning Mozilla people with influence) please stop knee-jerk WONTFIXing bugs that are entirely reasonable requests, due to (essentially) technical concerns that could be properly discussed?

Again, I appreciate that Mozilla can’t implement everything, but shutting down requests without debating possible implementation options that might address technical or security concerns is a) childish and b) counter productive if you’re trying to maintain any semblance of an add-on community.

i stopped using firefox after tiletabs add-on failed to work. also, in my previous experience, if one tab freezes with memory issues all tabs are frozen. the latter wasn’t a big deal since i could always do the memory intensive work in chrome, but tiletabs breaking was a deal breaker. would be good to know if functionalities like tiletabs will ever come back to Firefox. thanks.

Will you be fixing the queue limitations on Video Downloadhelper anytime soon? I used to be able to queue downloads and set a destination at that time and they would just auto start when the queue got to them – now with any queued downloads above the number of allowed simultaneous downloads you can’t set a destination – and have to rely on you being there to set a destination and start them when the slot opens up and the destination dialogue box appears – frustrating!