91–100 of 121 posts
As always, the only question for me is whether tree style tabs is going to work with WebExtenstions. If not, then say hello to people staying with firefox 56 for years.
Earlier quoted context omitted.
As a Firefox developer, whenever I make a change (and I mean pretty much any change to an API accessible through platform JS), I have two choices: 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice th…
> 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago (emphasis mine) And responding to that emphasis: so what?! People who use Firefox instead…
Presumably he's talking about web features when he says "Chrome landed that change a few months ago". This isn't copying Chrome, this is web compatability. You need that for websites to work.
Earlier quoted context omitted.
I can see where they're coming from though. Today, developers need to create two versions of their extensions - one that works on Safari, Chrome and Opera (and Edge?) and one specifically for Firefox. As the market share of Firefox is not that high, maybe extension developers eventually won't be bothered with supporting that extra version, which means Firefox extensions will be less up-to-date and there will be less…
That's an argument for providing similar/the same APIs as Chrome et al sure, but not for deprecating the old ones.
Man I will be so sad if they finally manage to kill TreeStyleTabs
Earlier quoted context omitted.
It's quite a burden to maintain two different sets of APIs.
I'm sorry, but I hear this all the time--it's the primary argument used for deprecating or removing any functionality in any software. And my response is: so what? Maintaining software is a burden, period. Software exists to be useful. The APIs in question make it useful. The developers have been maintaining it for nearly 20 years. Their employer receives millions of dollars a year to do so. They don't want to mainta…
1. The remote file has changed since the previous download, so "resuming" the download will end up combining two different files.
2. The user's computer crashed during the first download, and some of the data in the partial download was not written to disk properly. (A particularly common case: the last few blocks of the file are zeroed out.)
What, if anything, does this mean for GreaseMonkey?
Extensions is currently the only thing FF is better than the competition at, and they scrap it to copy Chrome APIs... I just can't understand why they would scrap XUL-based extensions before their new APIs reach feature parity. The day pentadactyl stops working is the day I stop using firefox.
What, if anything, does this mean for GreaseMonkey?
Tampermonkey works fine on Chrome, so probably very little.
Because scripts are stored in a database, TamperMonkey does not play swimmingly with GIT either. Finally, TamperMonkey is a third party tool that from time to time asks for money. GreaseMonkey is open-source.
The TamperMonkey EULA:
Your right to use Tampermonkey continues until terminated by the Company, which may terminate this Agreement and your license to use Tampermonkey at any time, without cause and without notice. You may terminate this agreement at any time by uninstalling Tampermonkey. This Agreement will automatically terminate if you fail to comply with any of the terms of this EULA. Upon termination, you agree to stop using and to uninstall Tampermonkey.
Earlier quoted context omitted.
And, related to this, it makes it easier to move to Servo's layout code in the future, as it avoids Servo having to implement XUL and XBL.
The current Firefox UI is XUL and XBL, tons and heaps of it. Re-implementing it in e.g. HTML is not an easy task, in particular not when you also want the result to look at least somewhat OS-native (took XUL itself ages to get there, btw). You also cannot do the OS-native look in HTML alone, you need support from the engine, which means servo has a some work ahead on that front too. So for the foreseeable future, ser…
It's definitely the case that the Firefox UI very much makes it impossible to move away from the current layout implementation at this point, and moving away would be a massive job. At the same time, the Firefox UI cannot move away from XUL/XBL until extensions no longer have free access to it, so this is definitely a first step that's relevant here.
As for using Servo for web content, it's worthwhile pointing out that not only is it the direction Mozilla is taking (with Project Quantum, and progressively moving components from Servo into Gecko), but it would also be a technical challenge because web extensions have access to extra APIs and have security checks disabled in others.
Anyone knows about the fate of SeaMonkey? It's still based on XUL as far as I know and supports a lot of existing Firefox extensions.
There are constant references on forums to how they want to move away from XUL, for both Firefox and Thunderbird. XUL works, but I feel like very people are able to improve the guts of XUL, and that can be a huge risk for the future of the project. Pale Moon seems to be the main contender willing to maintain XUL, but presumably not improve it (changes to XUL can break extensions). As someone working on another free s…