4 ms·

> I want the addons to have full control over my browser I can assure you that you only want this if you can guarantee that your add-ons only do what they clai

> I want the addons to have full control over my browser I can assure you that you only want this if you can guarantee that your add-ons only do what they claim, don't have security vulnerabilities, and are never acquired and maliciously updated. Otherwise, a permissionless add-on model means a bug in TreeStyleTabs could potentially be used to exfiltrate your entire password database, plant malicious binaries on your system, and destroy local data. If TST had limited permissions along the lines of only being able to manipulate tabs and their UI, that wouldn't be a problem. > Have you seen "treestyletabs" implementation on chrome? It's a whole other window that has to be started an placed on the left of the screen by user because of the addon limitations. Firefox will not have this limitation.

darklajid 10y ago
> Firefox will not have this limitation Is that a statement about future Firefox visions or Firefox 57? I assume you know the gritty details while I'm a rather confused Firefox power user / fan / advocate (using .. addons that are affected, vertical tabs/tree style tabs plus vimperator/pentadactyl mostly). The outrage The Internet™ seems to feel is probably not about XUL being deprecated/killed. I'd say no user cares about the technology, the only people even caring are probably the addon developers. From what I can tell, the outrage is mostly due to the impression (and I dearly hope that you will dismiss this as wrong, just like the 'addon limitation' reference above) that the web extension switch happens before popular, polarizing addons are even remotely possible given the new API. "Will not have this limitation", as in "it won't support that use case in 57 at all" or as in "you can do better than this Chrome extension you describe"?
- pseudalopex 10y ago
  Firefox 54 will support WebExtension sidebars.[1] You're basically correct about the APIs, though. Developers of some popular add-ons don't know when or if the APIs they need will be implemented. Support for migrating gradually (embedded WebExtensions) was just released in 51 and will be gone in 57 -- not even a full ESR cycle. Developer burnout is a problem, too. This comes right after many of them put in significant work making their now-deprecated code multiprocess-compatible, which came after mandatory extension signing, which came after a bunch of UI changes. It's not surprising some of them have quit. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1208596 https://bugzilla.mozilla.org/show_bug.cgi?id=1208596
- callahad 10y ago
  Pseudalopex pretty much nailed it; Google has strongly resisted adding sidebar APIs to Chrome, or allowing add-ons to hide / relocate the tab bar. Those are two of the major reasons why it's difficult to build a quality Tree Style Tabs add-on for Chrome. Firefox will explicitly include APIs that allow that, which should be landing soon. Most of these changes and their timelines are motivated by fundamental architectural work happening deep down in Firefox. We're doing the best we can to get as many add-on APIs in place before 57, but for heavy add-on users, it has the potential to be a rough transition. For deeper meddling in the browser, and for APIs that don't yet exist, WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/index.html https://webextensions-experiments.readthedocs.io/en/latest/i...) should provide a reasonable option. Basically, you can keep using old-style "bootstrapped" add-ons in DevEdition and Nightly. Kind of an explicit way to opt-out of API stability guarantess so we can continue refactoring the browser core. Experiments are intended for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but you could also use them for power-user APIs, so long as you don't mind the maintenance burden.
yellowapple 10y ago
"Firefox will not have this limitation." Can you clarify/elaborate? Last I heard, UI modification by web extensions was still unconfirmed at best.
- ripdog 10y ago
  A sidebar API and tab modification API will be implemented specifically to allow TST to work. The addon will have to be rewritten completely on a very short timescale, though.
  - kuschku 10y ago
    So, can I use that to add Tab Thumbnails to Firefox? Can I use it to port AutoHiDPI, which changes the scale of the UI depending on which screen the window is on? Can I use this to replace the entire browser history system and omnibar autocomplete with a custom one? Can I use this to replace the entire browser chrome? Some of these changes I need (AutoHiDPI) to use a browser at all. Others I wish for. All of them I currently am using. The alternative is me staying on an ancient browser, or forking Firefox and browsing with a horribly outdated and barely patched version. Or reading HN with a magnifying glass.
    - bartvk 10y ago
      You could continue to use Firefox LTS until somewhere in 2018.
    - callahad 10y ago
      Replacing the entire browser chrome is unlikely to happen on the release channel of Firefox, but everything else has potential. Generally, the way forward will be to use WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/index.html https://webextensions-experiments.readthedocs.io/en/latest/i...), which let you run classic-style "bootstrapped" add-ons in Firefox Developer Edition or Nightly. The intended use is for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but nothing limits you to that usage.

darklajid 10y ago

> Firefox will not have this limitation Is that a statement about future Firefox visions or Firefox 57? I assume you know the gritty details while I'm a rather confused Firefox power user / fan / advocate (using .. addons that are affected, vertical tabs/tree style tabs plus vimperator/pentadactyl mostly). The outrage The Internet™ seems to feel is probably not about XUL being deprecated/killed. I'd say no user cares about the technology, the only people even caring are probably the addon developers. From what I can tell, the outrage is mostly due to the impression (and I dearly hope that you will dismiss this as wrong, just like the 'addon limitation' reference above) that the web extension switch happens before popular, polarizing addons are even remotely possible given the new API. "Will not have this limitation", as in "it won't support that use case in 57 at all" or as in "you can do better than this Chrome extension you describe"?

pseudalopex 10y ago
Firefox 54 will support WebExtension sidebars.[1] You're basically correct about the APIs, though. Developers of some popular add-ons don't know when or if the APIs they need will be implemented. Support for migrating gradually (embedded WebExtensions) was just released in 51 and will be gone in 57 -- not even a full ESR cycle. Developer burnout is a problem, too. This comes right after many of them put in significant work making their now-deprecated code multiprocess-compatible, which came after mandatory extension signing, which came after a bunch of UI changes. It's not surprising some of them have quit. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1208596 https://bugzilla.mozilla.org/show_bug.cgi?id=1208596
callahad 10y ago
Pseudalopex pretty much nailed it; Google has strongly resisted adding sidebar APIs to Chrome, or allowing add-ons to hide / relocate the tab bar. Those are two of the major reasons why it's difficult to build a quality Tree Style Tabs add-on for Chrome. Firefox will explicitly include APIs that allow that, which should be landing soon. Most of these changes and their timelines are motivated by fundamental architectural work happening deep down in Firefox. We're doing the best we can to get as many add-on APIs in place before 57, but for heavy add-on users, it has the potential to be a rough transition. For deeper meddling in the browser, and for APIs that don't yet exist, WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/index.html https://webextensions-experiments.readthedocs.io/en/latest/i...) should provide a reasonable option. Basically, you can keep using old-style "bootstrapped" add-ons in DevEdition and Nightly. Kind of an explicit way to opt-out of API stability guarantess so we can continue refactoring the browser core. Experiments are intended for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but you could also use them for power-user APIs, so long as you don't mind the maintenance burden.

yellowapple 10y ago

"Firefox will not have this limitation." Can you clarify/elaborate? Last I heard, UI modification by web extensions was still unconfirmed at best.

ripdog 10y ago
A sidebar API and tab modification API will be implemented specifically to allow TST to work. The addon will have to be rewritten completely on a very short timescale, though.
- kuschku 10y ago
  So, can I use that to add Tab Thumbnails to Firefox? Can I use it to port AutoHiDPI, which changes the scale of the UI depending on which screen the window is on? Can I use this to replace the entire browser history system and omnibar autocomplete with a custom one? Can I use this to replace the entire browser chrome? Some of these changes I need (AutoHiDPI) to use a browser at all. Others I wish for. All of them I currently am using. The alternative is me staying on an ancient browser, or forking Firefox and browsing with a horribly outdated and barely patched version. Or reading HN with a magnifying glass.
  - bartvk 10y ago
    You could continue to use Firefox LTS until somewhere in 2018.
  - callahad 10y ago
    Replacing the entire browser chrome is unlikely to happen on the release channel of Firefox, but everything else has potential. Generally, the way forward will be to use WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/index.html https://webextensions-experiments.readthedocs.io/en/latest/i...), which let you run classic-style "bootstrapped" add-ons in Firefox Developer Edition or Nightly. The intended use is for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but nothing limits you to that usage.