7 ms·

As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to

As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app. This is completely up to them of course, and it probably let them move firefox forward faster, due to not having to care about APIs. However, it also means that chrome completely took over the entire market with electron and similar things.

mintplant 6y ago
> As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app. This has been in the works since at least 2016. I believe conversations around improving the embedding story were happening before that, too.
GeneralMaximus 6y ago
I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web. As you said, this is too little, too late. I'm a Firefox user, but Chrome has pretty much won the browser wars. The only thing preventing it from achieving complete market dominance is the existence of Mobile Safari.
- arghwhat 6y ago
  Mostly because it is a lot of work and tends to lead to new and exciting compromises. This is for example why Chrome decided to fork WebKit. (I do believe that people messed around with Electron drop-in replacements, but it's probably hard to sell if it doesn't bring anything new to the table.)
  - alexlarsson 6y ago
    It is expensive, but also it is a competitive advantage (of sorts), as we can see with electron. At the end of the day its just a strategic decision Mozilla made to focus on the application itself.
- jefftk 6y ago
  > If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web. People coding specifically to Chrome when writing Electron apps is way less harmful to the web than people doing the same with web pages. The latter case specifically hurts other browsers, because people who don't use Chrome can't use the site. Additionally, each Electron app represents a (smallish group of) developers. They're a very small number compared to all the developers writing public-facing websites that (should!) work in all commonly used browsers.
  - thawaway1837 6y ago
    It makes a difference though. The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off. It’s likely they would have chosen something else if that wasn’t the case (or maybe continued with their own web tech).
    - roca 6y ago
      > The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off. What evidence do you have for this? AFAIK the main reason why Microsoft picked Chromium is that Web sites are pretty much guaranteed to work well in Chromium without Microsoft having to do any work.
      - leeoniya 6y ago
        > What evidence do you have for this? they stated that their experience with CEF (Chromium Embedded Framework) was instrumental in their decision. VSCode (built on electron) was probably the main PoC for them.
        roca 6y ago
        OK. I doubt the absence of CEF would have changed their decision though.
      - alibert 6y ago
- fouc 6y ago
  It was funny when I realized that mobile-first also means safari-first for the iOS world.
- roca 6y ago
  Supporting embedding well is a lot of work, both to create the APIs and then deal with their constraints as the browser evolves. Mozilla has always been under-resourced compared to the competition (IE, then Chrome) and taking people off improving Firefox/Gecko to work on embedding never made the cut. I don't really regret those decisions. What made it extra unappealing for Mozilla was that we knew the Firefox/Gecko architecture needed lots of work that would destabilize an embedding API. Not much point in supporting an API that assumes single-process while you're moving to multi-process, or that exposes XUL which you know is a dead end, or that isn't compatible with off-main-thread rendering or GPU rendering, etc. Things are much better now that a lot of that debt has been paid off.
  - asiachick 6y ago
    There's nothing stopping a 3rd party from making an Gecko version of Firefox. Electron is not run by Google nor the Chromium team. It's run by github (which only recently became Microsoft) That said, I'm not sure what the point is. I believe (but could be wrong) that Chromium has more features that Gecko doesn't? So if you're choosing one over the other I'm only guessing most people would choose Electron
    - sanxiyn 6y ago
      "Electron for Gecko" was in fact done. See Positron discussion below.
    - roca 6y ago
      I don't have any direct insight into why the Atom people chose Chromium but I can see a few reasons that are more likely than "features": -- Chromium was faster. (For Electron apps you don't really care about Web compat, where Firefox was ahead of Chromium for a while, but you do care about performance.) -- Chromium was already multiprocess and had some other architectural advantages where Gecko was still catching up. So, less upcoming architectural churn. -- Chromium had Google's resources committed to it. (Google's shine has worn off a bit since then but it's still a powerful effect.)
  - pcwalton 6y ago
- deleted 6y ago
  [deleted]
- Scaevus 6y ago
  Considering the potential performance issues of Electron apps, I am still hopeful that someone can come up with an Electron alternative with the right engine, but I don't know if that engine is Gecko or not.
- dhruvkar 6y ago
  >> Chrome has pretty much won the browser wars Probably the same could have been said about IE ~20 years ago. This is less of a war, more of a never-ending race. Currently (temporarily?) Chrome is ahead.
- slightwinder 6y ago
  > I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web. On desktop Mozilla did that: https://en.wikipedia.org/wiki/XULRunner https://en.wikipedia.org/wiki/XULRunner It was quite successful und I never understodd what happend for them to abonded it and let mozilla run down so deep into s* as it is now.
  - duskwuff 6y ago
    "Quite successful" is perhaps an exaggeration. Most of the projects using XULRunner were directly related to the Mozilla project (forks of Mozilla Navigator and Composer, Thunderbird, Chatzilla, etc). There are very few projects which independently chose to use XULRunner. https://en.wikipedia.org/wiki/Category:Software_that_uses_XUL https://en.wikipedia.org/wiki/Category:Software_that_uses_XU...
johnchristopher 6y ago
> As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app. Your comment reminds me of a 15 or 20 year old remark from Feeddemon and Topstyle author (Nick Bradbury) about how he gave up baking firefox preview into his CSS editor. https://nick.typepad.com/blog/2008/03/can-mozilla-be.html https://nick.typepad.com/blog/2008/03/can-mozilla-be.html I loved Topstyle. It was the first editor I invested time into (after Visual Basic for windows 3.11 in the 90's but I was a kid, not a professional or a student).
_pmf_ 6y ago
XUL could have been a tolerable cross platform toolkit. Still not sure how you can blow something like that.
- jmisavage 6y ago
  Remember XULRunner that was doing Electron stuff about 6-7 years before the first version came out. Mozilla has so many good ideas and such terrible execution.
  - Yoric 6y ago
    XULRunner was working great. Unfortunately, there were strategic decisions to basically never maintain it :(
  - roca 6y ago
    The problem is that XUL was a) nonstandard and b) pretty badly designed and implemented. (For example: XUL trees relied on Javascript callbacks being called at paint time in horribly unsafe ways; XUL flexbox never integrated well with CSS block layout.) It was mostly hacked together in a hurry to get Netscape 6 out the door (and we know how that went). It was XML-centric and the Web ended up going in a different direction. All in all, it was clear pretty early on that XUL was going to be a dead end. Most of the good parts of XUL were standardized as CSS features (or in a few cases, HTML features). Given more resources, Mozilla absolutely could have done a better job of transitioning faster from XUL to standards-friendly equivalents, and popularizing the latter in an Electron-like framework. But there was never a time when Mozilla had excess resources floating around, and other things took priority. (Also see my comment above about how architectural churn made it unattractive to support a stable embedding API.) As was pointed out in other comments, the benefits of regular Web market share tend to outweigh the benefits of embedding popularity.
- johnchristopher 6y ago
  Maybe they lacked resources and dev mind share ? Javascript of those days wasn't javascript of today ? “Apps” were almost just glorified shortcuts for some. Now that I think about it Winamp 3 had its own interesting application framework (https://en.wikipedia.org/wiki/Wasabi_(software) https://en.wikipedia.org/wiki/Wasabi_(software)).
m4rtink 6y ago
Yeah, the Sailfish OS project, which is an operating system for mobile devices. They use Gecko as engine for their default web browser, but are always lagging with engine updates as every time they have to painstakingly rebase all of their embedding patches on top of the new Gecko codebase.
- slezyr 6y ago
  Same thing happens with CEF, QtWebKit (sometimes they just drop some features to update to a new version)
- smnthermes 6y ago
  Why do they not use the ESR version?
  - m4rtink 6y ago
    I think they do, just an old one as ESR AFAIK does not guarantee you stability of the internal APIS needed for embedding between ESR versions. I think it's at least 45 ESR, as mentioned in release notes ~year ago: https://blog.jolla.com/hossa/ https://blog.jolla.com/hossa/ There is an issue tracking the Gecko update on the community discussion/bug reporting tool used for Sailfish OS: https://together.jolla.com/question/133621/update-gecko-in-the-browser/ https://together.jolla.com/question/133621/update-gecko-in-t... The source of the Sailfish OS browser lives here: https://github.com/sailfishos/sailfish-browser https://github.com/sailfishos/sailfish-browser (Even though Sailfish OS is sadly not fully open source, the browser is as are other core applications and frameworks.)
grizzles 6y ago
Yep - if they are finally open to third parties doing something interesting, why wouldn't they freshen their GeckoView on other platforms? Typical Mozilla bs.
taf2 6y ago
Thank you so much for creating GtkMozEmbed. I spent a good part of 2004 working with it. The most fun I had was hacking it to run on Windows. I recall having to inject a callback function into the win32 event loop with assembly. It was like the coolest just out of college project ever for me.
luka-birsa 6y ago
I wonder if they changed the licensing to something you can actually use in a non FOSS product. Way way back (8 years ago?) we were deciding between webkit and gecko for our solution (we needed a web engine for server side GFX rendering) and the licence made it very simple for us to decide - WebKit was MIT, Gecko wasn't.
- yjftsjthsd-h 6y ago
  > we needed a web engine for server side GFX rendering > the licence made it very simple for us to decide - WebKit was MIT, Gecko wasn't. ...So what? If it runs on your server, it could be just about anything and it wouldn't matter so long as it's not AGPL. Or was the server meant to belong to the customer?
- kick 6y ago
  It can be used in proprietary software. You shouldn't, because that's unethical, but the MPL isn't a strong copyleft. And even with strong copylefts, there are only three that I can think of that apply to software that won't end up on user devices.
- mook 6y ago
  Wasn't WebKit LGPL (because of the KHTML heritage)? I was under the impression that, for commercial usage, Gecko (with MPL) was more friendly. Either can be made to work, of course.
kodablah 6y ago
Yup, I built my little browser on Chromium due to ease of embedding though I would have loved to use FF. I am investigating a way to use FF on system as is though by providing a custom profile, a user.css to remove everything but the browser window itself (i.e. no tabs, toolbar, etc), capturing it as a native window (e.g. via QWindow::fromWinId and QWidget::createWindowContainer), and communicating with it via marionette or other remote approach. So far it seems to be ok, but it's a bit of a hack.
- solarkraft 6y ago
  Have you tried calling it with the same profile multiple times? I've been running into "Firefox is already running" a lot while trying to use it to integrate web apps with the OS ("site specific browser"). Also the WM-Class would never be set according to the command line parameters on the second call, but you probably don't care about that.
  - paulryanrogers 6y ago
    Stock Firefox has "-no-remote" option which allows running multiple instances.
    - iggldiggl 6y ago
      But not using the same profile.
  - kodablah 6y ago
    For my use case I don't want to call it w/ the same profile multiple times. Once I have the FF process, I'll work with tabs/windows via the remote protocol.
- 72deluxe 6y ago
  Not sure what language you are using but CEF was good for Chrome under C#. Might be available under C++ too I think. There was an equivalent Gecko one for Firefox but I could never get it working correctly so deferred to CEF under Visual Studio (think there's a nuget package for it, conveniently). Also wxWidgets under C++ offers ability to host a local WebView instance or Trident with wxWebView.
LockAndLol 6y ago
Preach. Not only is Gecko a nightmare to embed, Firefox is terrible for headless. It's why something like phantomjs even had to exist. An embeddable Gecko would've created a wonderful ecosystem around it, produced headless browsers, a much wider range of browser alternatives, and had much more leverage when it comes to standard. They had... 8 years? 5 years? on Chomium and now have one hell of a task to correct that error. Looking at the code of their new layout engine written in Rust, making it embeddable wasn't even remotely on their minds either. A real pity.

mintplant 6y ago

> As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app. This has been in the works since at least 2016. I believe conversations around improving the embedding story were happening before that, too.

GeneralMaximus 6y ago

I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web. As you said, this is too little, too late. I'm a Firefox user, but Chrome has pretty much won the browser wars. The only thing preventing it from achieving complete market dominance is the existence of Mobile Safari.

arghwhat 6y ago
Mostly because it is a lot of work and tends to lead to new and exciting compromises. This is for example why Chrome decided to fork WebKit. (I do believe that people messed around with Electron drop-in replacements, but it's probably hard to sell if it doesn't bring anything new to the table.)
- alexlarsson 6y ago
  It is expensive, but also it is a competitive advantage (of sorts), as we can see with electron. At the end of the day its just a strategic decision Mozilla made to focus on the application itself.
jefftk 6y ago
> If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web. People coding specifically to Chrome when writing Electron apps is way less harmful to the web than people doing the same with web pages. The latter case specifically hurts other browsers, because people who don't use Chrome can't use the site. Additionally, each Electron app represents a (smallish group of) developers. They're a very small number compared to all the developers writing public-facing websites that (should!) work in all commonly used browsers.
- thawaway1837 6y ago
  It makes a difference though. The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off. It’s likely they would have chosen something else if that wasn’t the case (or maybe continued with their own web tech).
  - roca 6y ago
    > The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off. What evidence do you have for this? AFAIK the main reason why Microsoft picked Chromium is that Web sites are pretty much guaranteed to work well in Chromium without Microsoft having to do any work.
    - leeoniya 6y ago
      > What evidence do you have for this? they stated that their experience with CEF (Chromium Embedded Framework) was instrumental in their decision. VSCode (built on electron) was probably the main PoC for them.
      - roca 6y ago
        OK. I doubt the absence of CEF would have changed their decision though.
    - alibert 6y ago
fouc 6y ago
It was funny when I realized that mobile-first also means safari-first for the iOS world.
roca 6y ago
Supporting embedding well is a lot of work, both to create the APIs and then deal with their constraints as the browser evolves. Mozilla has always been under-resourced compared to the competition (IE, then Chrome) and taking people off improving Firefox/Gecko to work on embedding never made the cut. I don't really regret those decisions. What made it extra unappealing for Mozilla was that we knew the Firefox/Gecko architecture needed lots of work that would destabilize an embedding API. Not much point in supporting an API that assumes single-process while you're moving to multi-process, or that exposes XUL which you know is a dead end, or that isn't compatible with off-main-thread rendering or GPU rendering, etc. Things are much better now that a lot of that debt has been paid off.
- asiachick 6y ago
  There's nothing stopping a 3rd party from making an Gecko version of Firefox. Electron is not run by Google nor the Chromium team. It's run by github (which only recently became Microsoft) That said, I'm not sure what the point is. I believe (but could be wrong) that Chromium has more features that Gecko doesn't? So if you're choosing one over the other I'm only guessing most people would choose Electron
  - sanxiyn 6y ago
    "Electron for Gecko" was in fact done. See Positron discussion below.
  - roca 6y ago
    I don't have any direct insight into why the Atom people chose Chromium but I can see a few reasons that are more likely than "features": -- Chromium was faster. (For Electron apps you don't really care about Web compat, where Firefox was ahead of Chromium for a while, but you do care about performance.) -- Chromium was already multiprocess and had some other architectural advantages where Gecko was still catching up. So, less upcoming architectural churn. -- Chromium had Google's resources committed to it. (Google's shine has worn off a bit since then but it's still a powerful effect.)
- pcwalton 6y ago
deleted 6y ago
[deleted]
Scaevus 6y ago
Considering the potential performance issues of Electron apps, I am still hopeful that someone can come up with an Electron alternative with the right engine, but I don't know if that engine is Gecko or not.
dhruvkar 6y ago
>> Chrome has pretty much won the browser wars Probably the same could have been said about IE ~20 years ago. This is less of a war, more of a never-ending race. Currently (temporarily?) Chrome is ahead.
slightwinder 6y ago
> I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web. On desktop Mozilla did that: https://en.wikipedia.org/wiki/XULRunner https://en.wikipedia.org/wiki/XULRunner It was quite successful und I never understodd what happend for them to abonded it and let mozilla run down so deep into s* as it is now.
- duskwuff 6y ago
  "Quite successful" is perhaps an exaggeration. Most of the projects using XULRunner were directly related to the Mozilla project (forks of Mozilla Navigator and Composer, Thunderbird, Chatzilla, etc). There are very few projects which independently chose to use XULRunner. https://en.wikipedia.org/wiki/Category:Software_that_uses_XUL https://en.wikipedia.org/wiki/Category:Software_that_uses_XU...

johnchristopher 6y ago

> As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app. Your comment reminds me of a 15 or 20 year old remark from Feeddemon and Topstyle author (Nick Bradbury) about how he gave up baking firefox preview into his CSS editor. https://nick.typepad.com/blog/2008/03/can-mozilla-be.html https://nick.typepad.com/blog/2008/03/can-mozilla-be.html I loved Topstyle. It was the first editor I invested time into (after Visual Basic for windows 3.11 in the 90's but I was a kid, not a professional or a student).

_pmf_ 6y ago

XUL could have been a tolerable cross platform toolkit. Still not sure how you can blow something like that.

jmisavage 6y ago
Remember XULRunner that was doing Electron stuff about 6-7 years before the first version came out. Mozilla has so many good ideas and such terrible execution.
- Yoric 6y ago
  XULRunner was working great. Unfortunately, there were strategic decisions to basically never maintain it :(
- roca 6y ago
  The problem is that XUL was a) nonstandard and b) pretty badly designed and implemented. (For example: XUL trees relied on Javascript callbacks being called at paint time in horribly unsafe ways; XUL flexbox never integrated well with CSS block layout.) It was mostly hacked together in a hurry to get Netscape 6 out the door (and we know how that went). It was XML-centric and the Web ended up going in a different direction. All in all, it was clear pretty early on that XUL was going to be a dead end. Most of the good parts of XUL were standardized as CSS features (or in a few cases, HTML features). Given more resources, Mozilla absolutely could have done a better job of transitioning faster from XUL to standards-friendly equivalents, and popularizing the latter in an Electron-like framework. But there was never a time when Mozilla had excess resources floating around, and other things took priority. (Also see my comment above about how architectural churn made it unattractive to support a stable embedding API.) As was pointed out in other comments, the benefits of regular Web market share tend to outweigh the benefits of embedding popularity.
johnchristopher 6y ago
Maybe they lacked resources and dev mind share ? Javascript of those days wasn't javascript of today ? “Apps” were almost just glorified shortcuts for some. Now that I think about it Winamp 3 had its own interesting application framework (https://en.wikipedia.org/wiki/Wasabi_(software) https://en.wikipedia.org/wiki/Wasabi_(software)).

m4rtink 6y ago

Yeah, the Sailfish OS project, which is an operating system for mobile devices. They use Gecko as engine for their default web browser, but are always lagging with engine updates as every time they have to painstakingly rebase all of their embedding patches on top of the new Gecko codebase.

slezyr 6y ago
Same thing happens with CEF, QtWebKit (sometimes they just drop some features to update to a new version)
smnthermes 6y ago
Why do they not use the ESR version?
- m4rtink 6y ago
  I think they do, just an old one as ESR AFAIK does not guarantee you stability of the internal APIS needed for embedding between ESR versions. I think it's at least 45 ESR, as mentioned in release notes ~year ago: https://blog.jolla.com/hossa/ https://blog.jolla.com/hossa/ There is an issue tracking the Gecko update on the community discussion/bug reporting tool used for Sailfish OS: https://together.jolla.com/question/133621/update-gecko-in-the-browser/ https://together.jolla.com/question/133621/update-gecko-in-t... The source of the Sailfish OS browser lives here: https://github.com/sailfishos/sailfish-browser https://github.com/sailfishos/sailfish-browser (Even though Sailfish OS is sadly not fully open source, the browser is as are other core applications and frameworks.)

grizzles 6y ago

Yep - if they are finally open to third parties doing something interesting, why wouldn't they freshen their GeckoView on other platforms? Typical Mozilla bs.

taf2 6y ago

Thank you so much for creating GtkMozEmbed. I spent a good part of 2004 working with it. The most fun I had was hacking it to run on Windows. I recall having to inject a callback function into the win32 event loop with assembly. It was like the coolest just out of college project ever for me.

luka-birsa 6y ago

I wonder if they changed the licensing to something you can actually use in a non FOSS product. Way way back (8 years ago?) we were deciding between webkit and gecko for our solution (we needed a web engine for server side GFX rendering) and the licence made it very simple for us to decide - WebKit was MIT, Gecko wasn't.

yjftsjthsd-h 6y ago
> we needed a web engine for server side GFX rendering > the licence made it very simple for us to decide - WebKit was MIT, Gecko wasn't. ...So what? If it runs on your server, it could be just about anything and it wouldn't matter so long as it's not AGPL. Or was the server meant to belong to the customer?
kick 6y ago
It can be used in proprietary software. You shouldn't, because that's unethical, but the MPL isn't a strong copyleft. And even with strong copylefts, there are only three that I can think of that apply to software that won't end up on user devices.
mook 6y ago
Wasn't WebKit LGPL (because of the KHTML heritage)? I was under the impression that, for commercial usage, Gecko (with MPL) was more friendly. Either can be made to work, of course.

kodablah 6y ago

Yup, I built my little browser on Chromium due to ease of embedding though I would have loved to use FF. I am investigating a way to use FF on system as is though by providing a custom profile, a user.css to remove everything but the browser window itself (i.e. no tabs, toolbar, etc), capturing it as a native window (e.g. via QWindow::fromWinId and QWidget::createWindowContainer), and communicating with it via marionette or other remote approach. So far it seems to be ok, but it's a bit of a hack.

solarkraft 6y ago
Have you tried calling it with the same profile multiple times? I've been running into "Firefox is already running" a lot while trying to use it to integrate web apps with the OS ("site specific browser"). Also the WM-Class would never be set according to the command line parameters on the second call, but you probably don't care about that.
- paulryanrogers 6y ago
  Stock Firefox has "-no-remote" option which allows running multiple instances.
  - iggldiggl 6y ago
    But not using the same profile.
- kodablah 6y ago
  For my use case I don't want to call it w/ the same profile multiple times. Once I have the FF process, I'll work with tabs/windows via the remote protocol.
72deluxe 6y ago
Not sure what language you are using but CEF was good for Chrome under C#. Might be available under C++ too I think. There was an equivalent Gecko one for Firefox but I could never get it working correctly so deferred to CEF under Visual Studio (think there's a nuget package for it, conveniently). Also wxWidgets under C++ offers ability to host a local WebView instance or Trident with wxWebView.

LockAndLol 6y ago

Preach. Not only is Gecko a nightmare to embed, Firefox is terrible for headless. It's why something like phantomjs even had to exist. An embeddable Gecko would've created a wonderful ecosystem around it, produced headless browsers, a much wider range of browser alternatives, and had much more leverage when it comes to standard. They had... 8 years? 5 years? on Chomium and now have one hell of a task to correct that error. Looking at the code of their new layout engine written in Rust, making it embeddable wasn't even remotely on their minds either. A real pity.