5 ms·

> the better approach would obviously be to work with FF developers to add the extra extension APIs they need; I can only assume they took that path but got rej

by dao- 7y ago

> the better approach would obviously be to work with FF developers to add the extra extension APIs they need; I can only assume they took that path but got rejected. If you're a Firefox user, ie someone who inherently places their trust in the security and privacy decisions of Mozilla, that's probably a red flag. Hi, I'm an engineer at Mozilla working on the address bar of Firefox. We recently released a rewrite of the address bar with the explicit goal of making it easier to extend and experiment with the address bar: https://bugzilla.mozilla.org/show_bug.cgi?id=quantumbar https://bugzilla.mozilla.org/show_bug.cgi?id=quantumbar You're welcome.

kkm 7y ago
Disclaimer: I work for Cliqz. Good to hear that Mozilla changed their mind, when we proposed an open API for extensions to access the search area it was turned down Ref: -https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28
- dao- 7y ago
  We haven't changed our mind there. We're not going to implement a webextension API that allows replacing the results popup or parts of it with an iframe as we don't believe that to be a good API.
  - bagacrap 7y ago
    what is not good about it. Privacy? Security? :~)
bagacrap 7y ago
Sorry if I was unclear, I meant a red flag wrt cliqz's intentions. Do you think the address bar rewrite will be able to satisfy cliqz's needs and therefore allow them to unfork/go back to being an add-on?
- dao- 7y ago
  > Sorry if I was unclear, I meant a red flag wrt cliqz's intentions. Fair enough, but to be fair to cliqz, we didn't turn down their API proposal due to privacy or security concerns. The old address bar stack was kind of a mess and hard to extend in a sane way. > Do you think the address bar rewrite will be able to satisfy cliqz's needs and therefore allow them to unfork/go back to being an add-on? The rewrite makes it technically possible to provide any APIs they'd need. I think we'd consider patches, as we did before, with a better chance of them getting accepted.
  - bagacrap 7y ago
    In that case it sounds like the real explanation for forking was "the relevant part of the Firefox codebase had too much tech debt to make contributions so we had to fork our bodges." (No offense wrt tech debt; I know what it's like to be saddled with it and congrats on addressing yours.) I hope to soon see a cliqz blog post about their project unforking, only spun as an ingenious way of saving memory, improving security and extending reach.

by dao- 7y ago

kkm 7y ago

Disclaimer: I work for Cliqz. Good to hear that Mozilla changed their mind, when we proposed an open API for extensions to access the search area it was turned down Ref: -https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28 https://bugzilla.mozilla.org/show_bug.cgi?id=1361327#c28

dao- 7y ago
We haven't changed our mind there. We're not going to implement a webextension API that allows replacing the results popup or parts of it with an iframe as we don't believe that to be a good API.
- bagacrap 7y ago
  what is not good about it. Privacy? Security? :~)

bagacrap 7y ago

Sorry if I was unclear, I meant a red flag wrt cliqz's intentions. Do you think the address bar rewrite will be able to satisfy cliqz's needs and therefore allow them to unfork/go back to being an add-on?

dao- 7y ago
> Sorry if I was unclear, I meant a red flag wrt cliqz's intentions. Fair enough, but to be fair to cliqz, we didn't turn down their API proposal due to privacy or security concerns. The old address bar stack was kind of a mess and hard to extend in a sane way. > Do you think the address bar rewrite will be able to satisfy cliqz's needs and therefore allow them to unfork/go back to being an add-on? The rewrite makes it technically possible to provide any APIs they'd need. I think we'd consider patches, as we did before, with a better chance of them getting accepted.
- bagacrap 7y ago
  In that case it sounds like the real explanation for forking was "the relevant part of the Firefox codebase had too much tech debt to make contributions so we had to fork our bodges." (No offense wrt tech debt; I know what it's like to be saddled with it and congrats on addressing yours.) I hope to soon see a cliqz blog post about their project unforking, only spun as an ingenious way of saving memory, improving security and extending reach.