Earlier quoted context omitted.
> So you're suggesting they say "we intend to deprecate this feature", but not give a timeline? Yes; but that only works if they don't actually _have_ a timeline. Do the necessary work to let people explore options, then evaluate and give a timeline (in the same order as what it took to get all that implemented). The timeline currently is "you have 12 to 18 months, but can't actually start". That's pretty much a reci…
I guess it's a matter of opinion, but I greatly prefer it they way they did it. Announcing "this is going away" without a timeline would make me worry "when? now? in a month?" Instead, by saying "12 to 18 months", I know this is a long-term thing and I can plan for it. The timeline is very useful information.
The likely end of DownThemAll
131–140 of 142 posts
Re: The likely end of DownThemAll
#132As to NoScript: - from a linked Mozilla blog post: > [...] A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extens…
Re: The likely end of DownThemAll
#133Earlier quoted context omitted.
> What you're describing isn't a modern power user OS -- you're describing iOS. Hardly. Windows, Linux and OS X do not let you monkeypatch the entire system.
Actually, they pretty much do. Take for example Dropbox. Windows officially 3rd party applications adding overlays to icons which dropbox uses to provide sync status for items in the dropbox folder. OS X has no such feature or API for icon overlays. Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well.
And it's not unlikely that Apple will break them at any time. Apple won't even go through the trouble of making an announcement when they do so.
Re: The likely end of DownThemAll
#134Earlier quoted context omitted.
Actually, they pretty much do. Take for example Dropbox. Windows officially 3rd party applications adding overlays to icons which dropbox uses to provide sync status for items in the dropbox folder. OS X has no such feature or API for icon overlays. Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well.
> Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well. And it's not unlikely that Apple will break them at any time. Apple won't even go through the trouble of making an announcement when they do so.
Some discussion of the politics of this issue: http://atp.fm/episodes/128
[1] haven't read enough to know the exact mechanism, but presumably restricting some forms of IPC like Mach messages?
Re: The likely end of DownThemAll
#135Earlier quoted context omitted.
>Electrolysis apparently breaks XUL extensions. This is wrong. It absolutely does not break XUL extensions per-se. Add-ons will require some (moderate for most add-ons) changes when accessing out-of-process web content. A lot of add-ons may not even require changes at all, because they either do not access web content directly in the first place, or the Cross-Process-Wrappers and shims mozilla already implemented wil…
I'm prepared to be wrong, as I am not an expert on XUL, Electrolysis, or the Firefox runtime. I can however interpret what Mozilla says is the reasoning behind breaking XUL extensions, which is: XUL extensions, among other things, get in the way of getting Electrolysis working. That's linked from this blog post. If things have to break in the short term for Mozilla to modernize Firefox's runtime hardening, well, that…
The main new change being announced recently (electrolysis and extension signing have been known about for a while now) is the deprecation of XUL in the browser in general and for add-ons in particular and the adoption of a new extension API's that are more limited in functionality (WebExtensions and whatever else they decide to do to allow more functionality than is available in Chrome). There are security implications to these changes but multi-process Firefox is not the main driver. Mozilla is giving up on XUL in favor of HTML and using this as a pretext to limit the functionality of add-ons (which many Firefox developers have wanted to do for a long time for security and stability reasons).
Re: The likely end of DownThemAll
#136Earlier quoted context omitted.
Actually, they pretty much do. Take for example Dropbox. Windows officially 3rd party applications adding overlays to icons which dropbox uses to provide sync status for items in the dropbox folder. OS X has no such feature or API for icon overlays. Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well.
> Through lots of trial and error, swizzling, mach_inject, and mach_override they managed to provide this feature in OS X as well. And it's not unlikely that Apple will break them at any time. Apple won't even go through the trouble of making an announcement when they do so.
Re: The likely end of DownThemAll
#137I think I might have to go full Stallman and wget + email html-only web pages to myself.
Re: The likely end of DownThemAll
#138This is what happens when humans achieve success. Rather than maintain the course they are obligated to exploit to the nth in order to squeeze every gram of return from an idea(product) until they can get no more. Then, they will get creative and pull out every hook & crook to squeeze some more. Thanks Mozilla, for everything up until your mass-collection, feature- bloat, entrapment blitz you've set out upon. Perhaps…
I don't understand what is being exploited?
"Surreptitious spying is all the rage. Everybody is doing it."
Re: The likely end of DownThemAll
#139Earlier quoted context omitted.
The main reason people install it I thought is because 1. It allows downloads to start and stop. No more 90% of that iso then having to start again. 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection.
> 1. It allows downloads to start and stop. No more 90% of that iso then having to start again. I'm surprised Firefox doesn't do this itself, as in, this sounds like a clear bug. Is there some reason the upstream project by itself doesn't get this right? > 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection. ... this works in 20…