23 ms·

Are there any plans to build a completely new browser from Servo? Is there even any worth in that? (A firefox-esque "normal" one, not like that experimental htm

by jumpwah 11y ago

Are there any plans to build a completely new browser from Servo? Is there even any worth in that? (A firefox-esque "normal" one, not like that experimental html browser thing.)

Manishearth 11y ago
(Servo contributor here) No concrete plans. We hope to get a new mobile browser out. For Desktop we're hopeful about browser.html. As a research project we aren't really worrying about any of this yet. browser.html is intended to be a "normal" browser, though in it's current state it isn't quite there yet :P (It's not pure web HTML, there is a small set of "mozbrowser" APIs which it uses to get sandboxing and the other necessary things) Firefox's UI is anyway written in XUL (an html-esque xml thingy), so browser.html isn't too far from what Firefox does.
- jumpwah 11y ago
  Thanks for the response. With browser.html, I think I meant functionally, like isn't it supposed to be marketed as a simple, out-of-box, no configuration browser for those who just want no hassle simple web browsing? (Because otherwise I might be confusing it with something else, although I was sure I saw that Mozilla research was doing something like this.) Because if it is, I obviously don't want that... I "just" want a free software html/css/js spec compliant browser (obviously without the drm, or an option without that part, because that's not free software), but the catch is that I sort of need it to be quite customisable... By which I mean something akin to the current firefox, which allows addons, a great powerful addon api, unlike chrome, allows modifying the ui (via userChrome.css), modifying display of web pages themselves (via userContent.css), developer console, setting configuration options via a config file, view page source etc. This seems off-topic and almost like a personal feature request for Servo or whatever, but my point is that I know my "setup" isn't exactly 'mainstream', hence why I basically require powerful customisation options. For example, I'm on firefox (37), but it looks like this: http://i.imgur.com/L9P8XhC.png http://i.imgur.com/L9P8XhC.png. And it's not exactly a whole heap of fragile customisations which are destined to break, it's "just" one userchrome file and one addon, so it's actually fairly reliable too. I care about the ui in that I want the power to change it to what I like. If I can do that, I don't care what the default ui is. But I don't think browser.html's purpose is to be powerful like current firefox is it? I guess normal isn't the right word. If anything, you're right, browser.html is normal, but not in the way I've grown accustomed to with the feature-filled firefox. If you're familiar with zsh and the fish shell, I mentally labelled browser.html as the special "fish shell" of browsers the first time I saw it, hence why I was quick to dismiss it as a future option. I should probably go and embed servo in emacs or something.. :)
  - Manishearth 11y ago
    I don't think there's a fixed end goal for browser.html; it's also a research project. Spec compliance is Servo's problem. Customizability -- well, browser.html should be just as customizable as Firefox once it gets polished. Like I said, browser.html uses HTML, and Firefox uses XUL, both in mostly the same way. Firefox largely uses XUL because HTML wasn't so powerful in the past, but now it is, and technically we could replace a lot of the XUL with HTML5. Which is sort of what browser.html does. Many firefox UI components are slowly being replaced by html variants these days too. Now with Firefox's addon API, you write addons using XUL/XPCOM. With browser.html it would be HTML/JS, and you'd be able to hook into any part of the chrome[1] you want. Addons would basically be like userscripts, except they would be for the whole browser chrome. So for example you could write a simple CSS addon that colors the location bar yellow, or write a more complex one that moves the tab strip to the side, or whatever. Of course, since browser.html is still researchy, I don't think there are plans for an addon api yet. I'm just saying that an addon api for browser.html sounds like something that could be done. I haven't worked with browser.html, so I could be very wrong here. Actually, fwiw you probably can write your own browser UI (right now!) from scratch using the same APIs that browser.html uses. Instead of fixing an existing UI by totally rearranging everything, write your own! Check out https://github.com/glennw/servo-shell https://github.com/glennw/servo-shell to see what APIs work in Servo and how to use them. Servo has a usable-ish embedding API, you might actually be able to do the emacs thing (it might help if you chat with zmike in the #servo Mozilla IRC room) [1]: browser chrome = the stuff outside the layout engine; the UI (location bar, bookmarks, history, devtools, etc)
    - jumpwah 11y ago
      Wow thanks for the taking the time for the comprehensive reply! :) Really, my comment turned into a half-rant, and I wasn't expecting such a response! Well honestly, if it does become "hackable" (i.e. ui, addons), then that invalidates all of what I said. But yes it is still experimental as you say of course, so I understand. This is a bit off topic, but one thing that's really deterring me from firefox lately is the signed extensions thing. [1] To cut to the point, I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake [2]. (Sort of, I'm twisting the words I think, english actually not my native language, so I still have trouble expressing myself sometimes.) My comment is just that I hope that servo/browser.html doesn't make the same "mistake". I.e. implement proper addon security, sandboxing etc. Because, if you guys do plan for an addons api, and if you give it the power ("except they would be for the whole browser chrome"), then you should also plan ahead on the security implications of that too, if any. I guess I should watch the servo project for any addon plans and bring it up there! But other than that, I'm not a security guy, so I cannot say what exactly to do. If you're wondering why... yes extension signing is great of course, just not when only Mozilla has the power to do so imo: [3] (Not my blog, but iirc I think I agree with most of the post.) And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p Also, thanks for the irc hint! [1]: https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/ https://blog.mozilla.org/addons/2015/02/10/extension-signing... [2]: https://twitter.com/dveditz/status/591996675100545024 https://twitter.com/dveditz/status/591996675100545024 [3]: http://blog.rubbingalcoholic.com/post/110743007958/mozillas-mandatory-add-on-review-considered http://blog.rubbingalcoholic.com/post/110743007958/mozillas-...

by jumpwah 11y ago

Are there any plans to build a completely new browser from Servo? Is there even any worth in that? (A firefox-esque "normal" one, not like that experimental html browser thing.)

Manishearth 11y ago

(Servo contributor here) No concrete plans. We hope to get a new mobile browser out. For Desktop we're hopeful about browser.html. As a research project we aren't really worrying about any of this yet. browser.html is intended to be a "normal" browser, though in it's current state it isn't quite there yet :P (It's not pure web HTML, there is a small set of "mozbrowser" APIs which it uses to get sandboxing and the other necessary things) Firefox's UI is anyway written in XUL (an html-esque xml thingy), so browser.html isn't too far from what Firefox does.

jumpwah 11y ago
Thanks for the response. With browser.html, I think I meant functionally, like isn't it supposed to be marketed as a simple, out-of-box, no configuration browser for those who just want no hassle simple web browsing? (Because otherwise I might be confusing it with something else, although I was sure I saw that Mozilla research was doing something like this.) Because if it is, I obviously don't want that... I "just" want a free software html/css/js spec compliant browser (obviously without the drm, or an option without that part, because that's not free software), but the catch is that I sort of need it to be quite customisable... By which I mean something akin to the current firefox, which allows addons, a great powerful addon api, unlike chrome, allows modifying the ui (via userChrome.css), modifying display of web pages themselves (via userContent.css), developer console, setting configuration options via a config file, view page source etc. This seems off-topic and almost like a personal feature request for Servo or whatever, but my point is that I know my "setup" isn't exactly 'mainstream', hence why I basically require powerful customisation options. For example, I'm on firefox (37), but it looks like this: http://i.imgur.com/L9P8XhC.png http://i.imgur.com/L9P8XhC.png. And it's not exactly a whole heap of fragile customisations which are destined to break, it's "just" one userchrome file and one addon, so it's actually fairly reliable too. I care about the ui in that I want the power to change it to what I like. If I can do that, I don't care what the default ui is. But I don't think browser.html's purpose is to be powerful like current firefox is it? I guess normal isn't the right word. If anything, you're right, browser.html is normal, but not in the way I've grown accustomed to with the feature-filled firefox. If you're familiar with zsh and the fish shell, I mentally labelled browser.html as the special "fish shell" of browsers the first time I saw it, hence why I was quick to dismiss it as a future option. I should probably go and embed servo in emacs or something.. :)
- Manishearth 11y ago
  I don't think there's a fixed end goal for browser.html; it's also a research project. Spec compliance is Servo's problem. Customizability -- well, browser.html should be just as customizable as Firefox once it gets polished. Like I said, browser.html uses HTML, and Firefox uses XUL, both in mostly the same way. Firefox largely uses XUL because HTML wasn't so powerful in the past, but now it is, and technically we could replace a lot of the XUL with HTML5. Which is sort of what browser.html does. Many firefox UI components are slowly being replaced by html variants these days too. Now with Firefox's addon API, you write addons using XUL/XPCOM. With browser.html it would be HTML/JS, and you'd be able to hook into any part of the chrome[1] you want. Addons would basically be like userscripts, except they would be for the whole browser chrome. So for example you could write a simple CSS addon that colors the location bar yellow, or write a more complex one that moves the tab strip to the side, or whatever. Of course, since browser.html is still researchy, I don't think there are plans for an addon api yet. I'm just saying that an addon api for browser.html sounds like something that could be done. I haven't worked with browser.html, so I could be very wrong here. Actually, fwiw you probably can write your own browser UI (right now!) from scratch using the same APIs that browser.html uses. Instead of fixing an existing UI by totally rearranging everything, write your own! Check out https://github.com/glennw/servo-shell https://github.com/glennw/servo-shell to see what APIs work in Servo and how to use them. Servo has a usable-ish embedding API, you might actually be able to do the emacs thing (it might help if you chat with zmike in the #servo Mozilla IRC room) [1]: browser chrome = the stuff outside the layout engine; the UI (location bar, bookmarks, history, devtools, etc)
  - jumpwah 11y ago
    Wow thanks for the taking the time for the comprehensive reply! :) Really, my comment turned into a half-rant, and I wasn't expecting such a response! Well honestly, if it does become "hackable" (i.e. ui, addons), then that invalidates all of what I said. But yes it is still experimental as you say of course, so I understand. This is a bit off topic, but one thing that's really deterring me from firefox lately is the signed extensions thing. [1] To cut to the point, I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake [2]. (Sort of, I'm twisting the words I think, english actually not my native language, so I still have trouble expressing myself sometimes.) My comment is just that I hope that servo/browser.html doesn't make the same "mistake". I.e. implement proper addon security, sandboxing etc. Because, if you guys do plan for an addons api, and if you give it the power ("except they would be for the whole browser chrome"), then you should also plan ahead on the security implications of that too, if any. I guess I should watch the servo project for any addon plans and bring it up there! But other than that, I'm not a security guy, so I cannot say what exactly to do. If you're wondering why... yes extension signing is great of course, just not when only Mozilla has the power to do so imo: [3] (Not my blog, but iirc I think I agree with most of the post.) And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p Also, thanks for the irc hint! [1]: https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/ https://blog.mozilla.org/addons/2015/02/10/extension-signing... [2]: https://twitter.com/dveditz/status/591996675100545024 https://twitter.com/dveditz/status/591996675100545024 [3]: http://blog.rubbingalcoholic.com/post/110743007958/mozillas-mandatory-add-on-review-considered http://blog.rubbingalcoholic.com/post/110743007958/mozillas-...