LWN: Comments on "Mozilla kills embedding support for Gecko layout engine (The H)"

Mozilla kills embedding support for Gecko layout engine (The H)

nix — Mon, 06 Mar 2017 18:14:55 +0000

22.0? Seriously? Why not just send your machine's root password out to a bunch of dark web sites: it's probably about as secure.

Also your Github site appears to be just a README and, uh, judging from the content of that README you don't bother to provide source at all. (I didn't download it to find out because I am not insane.)

Plus it's Windows-focused and/or Windows-only.

If this is targetted it's terribly targetted. If this is spam, well, I can see why you can't sell it any other way. Assuming it's not malware in and of itself, which frankly shipping FF 22.0 at this late date damn nearly counts as on its own.

Mozilla kills embedding support for Gecko layout engine (The H)

yaolixing — Mon, 06 Mar 2017 15:07:18 +0000

Other Hill Gui Development Framework, abbreviation OHUI,embedding Gecko 22.0，developers can test html on ff22.0,then load it with OHUI.support all the same display effection as ff22.0，include html(5),css(3),js,flash, support js vs c++ call each other, about the limition of html5 and css3, you can refer firefox22.0.
https://github.com/yaolixing/OHUI/blob/master/README.md

Some clarifications and opinions

jthill — Fri, 08 Apr 2011 20:56:19 +0000

"As noted in at least one other bug, I will not accept a patch for this". Being usable for other programs is of "little benefit".

Well, one browser's UI isn't all that much different from another's. Too bad.

Mozilla kills embedding support for Gecko layout engine (The H)

jrn — Wed, 06 Apr 2011 23:25:36 +0000

> What should Mozilla do when they find a security related bug, fix it immediately and ship it out or go the idealist way?

I'm not advocating anything in particular, but the idealist way is:

1) fix immediately
2) send the fix upstream and listen to their feedback
3) meanwhile, ship it
4) make sure today's build system will allow using the upstream version once it's fixed

That way, you get feedback on the fix (so a better fix), other apps benefit from the fix, you are not making needless work for system integrators, and your app benefits from unrelated fixes submitted by developers of other apps.

Mozilla kills embedding support for Gecko layout engine (The H)

lotzmana — Wed, 06 Apr 2011 22:21:45 +0000

Firefox makes it hard on Linux distros by bundling system libraries, often modified and not upstreamed

There is no other practical way to write software that is both robust and would fit in some reasonable (if any) deadlines.

What should Mozilla do when they find a bug in a library?

The idealists approach would be to write to the owner upstream and fix it there, but then? How soon will this upstream percolate (if ever) to the current distributions out there?

What should Mozilla do when they find a security related bug, fix it immediately and ship it out or go the idealist way?

One thing that I like in Chrome is that it works out-of-the-box. You click, download, and start using it. This is the desktop experience. This is not possible without coupling of libraries, not for a browser.

Another scenario that supports the coupling. I use stable Ubuntu 10.04 (used to use Debian). There will be no new upstream in 2 years. What is any product that depends on upstream supposed to ship for 2 years, nothing?!

There should be a balance. Submit fixes to upstream but sever the dependence if it hinders progress. Contemporary Linux distributions force this behaviour by insisting that updating to new upstream sometimes would require you installing an entire new version of the distribution. That is unacceptable.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Wed, 06 Apr 2011 16:17:07 +0000

When one has nothing left to say...

Mozilla kills embedding support for Gecko layout engine (The H)

nye — Wed, 06 Apr 2011 15:58:03 +0000

Okay, clearly our difference of opinion is based on the fact that we don't live in the same universe.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Tue, 05 Apr 2011 23:56:58 +0000

As for your home and end comments, they're pretty unperceptive. Home and End mean go to the beginning and end. Backspace doesn't mean to go to the previous item.

When in a music player, backspace does not go to the previous entry. When in a mail reader, backspace does not go to the previous entry. When in adobe photoshop, the backspace shortcuts all have to do with removing, clearing, erasing, etc, none to do with prior items. Backspace has a clear semantic meaning established for decades and that meaning is to erase.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Tue, 05 Apr 2011 23:52:01 +0000

In the modern internet, the majority of forms clear on javascript load, so it is the majority of cases where your text is trashed on back/forward.

There are other scenarios, but that gets most current interactions.

---

The browser IS a text editor, it has textarea fields. Thus a misclick of a pixel changes a text edit into data loss.

Mozilla kills embedding support for Gecko layout engine (The H)

nye — Tue, 05 Apr 2011 16:31:47 +0000

>backspace is destructive both in text entry fields and in the navigation context

Example? Given that 'back' is a reversible operation ('forward'), in what scenario is accidentally going back destructive? I'm trying to imagine some scenario involving POSTs and badly designed web applications, but the only thing I can come up with is some banking websites that intentionally break the back button and then close your session if any request is repeated (in the name of 'security').

>But its not reasonable and doesn't make sense. Backspace does not mean "go to the previous item", it means "erase the previous character."

A browser is not a text editor. Would you like Home and End to do nothing as well, based on the fact that they don't mean 'go to the beginning (resp. end) of the document'? Going to the beginning/end of a page can often be a destructive operation in that it destroys state - my position in a potentially huge document - and unlike back/forward has no undo.

It seems self-centred to me to be so opposed to a feature which is useful to probably tens of millions of people on other platforms, and which is not only optional but *disabled by default* on your platform of choice.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Tue, 05 Apr 2011 14:25:52 +0000

You can see why two comments up.

But its not reasonable and doesnt make sense. Backspace does not mean "go to the previous item", it means "erase the previous character."

Mozilla kills embedding support for Gecko layout engine (The H)

nye — Tue, 05 Apr 2011 12:24:04 +0000

>And maybe you should disable the broken backspace goes to the previous page behavior, which is only semi-reasonable on windows, where IE users might want it.

Aside from the fact that this is optional behaviour, as has been pointed out, why would it be considered 'broken'? Having a non-chorded key for 'back' is a great idea and other browsers use backspace since it makes perfect sense (at least Chrome and Opera, and you say IE as well). Why should Firefox be different?

Mozilla kills embedding support for Gecko layout engine (The H)

TRS-80 — Mon, 04 Apr 2011 16:05:52 +0000

That MozillaZine KB page claims "In Linux builds after 2006-12-07, the default is 2." and UTSL confirms this. Bug 358764.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Mon, 04 Apr 2011 15:53:34 +0000

Yes, the sane question is why it works that way on any platform. Its a huge UI gaffe since backspace is destructive both in text entry fields and in the navigation context. Attempting to edit your text can throw it away.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Mon, 04 Apr 2011 15:52:02 +0000

Yes, because iceweasel fixes the default.

Some clarifications and opinions

kripkenstein — Mon, 04 Apr 2011 03:10:01 +0000

> If you're going to advocate that I think you need to fix 352074. It's coming up five years old

I commented in the bug and I'll see what I can do.

Some clarifications and opinions

jthill — Mon, 04 Apr 2011 02:19:22 +0000

If you're going to advocate that I think you need to fix 352074. It's coming up five years old, and I doubt it's the oldest report. I don't think its reasonable to deny the option to control what happens when a url opens, and that means having working profile management.

Downstream developer ver

kripkenstein — Mon, 04 Apr 2011 01:39:30 +0000

>> Apps that use the Gecko platform, use it directly, using internal APIs (apps like Fennec and Songbird already do this).

> Songbird certainly doesn't; I doubt Fennec does, either. The whole not being part of libxul thing and all.

For Songbird I am just relaying what I was told - I guess that is incorrect then. I am a Fennec developer though: We definitely use the internal Gecko APIs, in fact we use them exactly as Firefox does.

My point is that it would be very feasible to write something like Camino in the same way as we write Fennec: use the Gecko platform, add a completely new UI on top of that.

> Except that people are _against_ putting more things in m-c - see pyxpcom, for example, which used to be in-tree before hg, or ipccode which isn't either.

It really depends on what.

Regarding pyxpcom specifically, I am not sure, but I seem to recall the issue was that it lacked a maintainer?

> But what people _want_ is embedding, because they want to be able to control the browser

There are lots of different use cases here. I agree my suggestions don't cover them all. I do think though that they would cover most of them, but that is of course debatable.

Downstream developer ver

Mook — Mon, 04 Apr 2011 01:13:41 +0000

> Apps that use the Gecko platform, use it directly, using internal APIs (apps like Fennec and Songbird already do this).

Songbird certainly doesn't; I doubt Fennec does, either. The whole not being part of libxul thing and all.

> This obviously means they need to keep up to date if they are out of tree, or that they should be in-tree (in the mozilla-central repo).

Except that people are _against_ putting more things in m-c - see pyxpcom, for example, which used to be in-tree before hg, or ipccode which isn't either.

> (2) to provide a very simple, very stable, very high-level API, *not* for embedding

But what people _want_ is embedding, because they want to be able to control the browser - where it navigates to, when it tries to launch the system browser instead for off-site links, what context menu gets shown. Just slamming a remoted Firefox bitmap in doesn't provide enough controls. At this point, of course, any new projects would be better off using WebKit (via Gtk/Qt/Cocoa bindings) or IE (IWebBrowser).

Downstream developer ver

Mook — Mon, 04 Apr 2011 00:13:58 +0000

> Sorry if I wasn't clear, what I meant was more in regards to people developing device drivers for Linux. There isn't a stable API for that, http://www.kroah.com/log/linux/stable_api_nonsense.html

Sure, and that's why nobody has had a successful run at developing drivers out-of-tree other than perhaps nVidia (with their _own_ stable API layer). People who develop on top of Mozilla can't just use some limited subset of API, because they're not developing device drivers that only ever need to talk to one thing.

> Not sure what you mean about Fennec here - I'm a Fennec dev, and we track mozilla-central very closely. We use the same mozilla-central for our releases as desktop (perhaps a few commits earlier or later though). Point updates might end up a little different, but overall, we use mozilla-central just like desktop Firefox does.

Firefox (desktop) always releases on a branch. Fennec, last I checked (I may be wrong!) was going to release off 2.1. I was going by http://oduinn.com/blog/2011/03/09/branch-mechanics-for-fi... which was what I last saw on planet.m.o. Fennec also gets the advantage here of actually being on a tinderbox people (vaguely) care about when they checkin.

> I would argue here, that they take so long *because* they fork the browser. If instead things like RockMelt started out as a Firefox addon, they could be finished much earlier. Yes, as you say they would need to keep up to date with new Firefox versions, but the benefits of that outweight the disadvantages.

No, you can't sensibly build a product (or a house) with a shifting foundation. Let's pretend they started at Firefox 4 beta 1 (roughly 9 months ago). They would have been bitten by UI changes such as the total revamp of the status bar, the randomly-reset toolbars, the whole Firefox button deal, the on-again-off-again web console. With the sort of UI changes they want that don't sound fun. And that's just the major frontend changes, not including things like the repeated JS engine changes that - while making Firefox faster - kept adding limitations that Firefox happened to not care about.

> The primary reason Flock and RockMelt are browsers, and not browser plugins, *is not technical*. The main reason is financial: Their business model is (or, for Flock, was) in large part identical to Firefox's: Revenue sharing with search engines. Only the browser itself participates with that, not addons, so they are forced to release entire browsers, with all the technical burden that that brings.

I would agree that that's probably a large reason, yes. But imagine they were doing this an extension. Your app will now completely not work on timelines you have no control over (when a new Firefox is released), with no way to even tell the user that might be bad. If you tried to prevent the app from updating, you can bet you are going to get blocklisted (regardless of whether you distribute on addons.mozilla.org, the blocklist affects everybody - it's the same mechanism they use to block malware). When things break for you, you can't change the code to suit you, because you don't ship it, and if you submit patches, they languish until after the next Firefox release is out because it's not a blocker for Firefox.

> Reading that makes me unhappy too. As I said above, I agree that we need to improve with that stuff. Can you please link me to the quote's source, so I can see the whole picture and try to help?

Ping me on IRC? I'm dumb enough to use the same name. The guy saying that has historically been nice with external developers, but like everyone he needs to meet timelines so things like reviewing patches without considering what app it's for isn't going to happen without an organizational change.

Downstream developer ver

kripkenstein — Mon, 04 Apr 2011 00:01:43 +0000

I guess I presented my point poorly: I don't think that Mozilla is a *perfect* parallel to Linux, just that there is a major similarity here. Specifically, the aspect I meant is summarized very well by gkh in that link, which is why I provided it:

>> "Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly."

Similarly, Mozilla is moving forward very fast, and a fixed, stable embedding API would slow that down. The proper solution, I personally think, is (1) Apps that use the Gecko platform, use it directly, using internal APIs (apps like Fennec and Songbird already do this). This obviously means they need to keep up to date if they are out of tree, or that they should be in-tree (in the mozilla-central repo). And the other part of the solution is (2) to provide a very simple, very stable, very high-level API, *not* for embedding, but for Firefox (and other browsers) to provide rendering services for other apps (on Linux, using DBUS). It should be just a few lines of, say, Python, to get a rendered page given a URL, with the browser doing all the work.

Downstream developer ver

jrn — Sun, 03 Apr 2011 23:47:35 +0000

> Sorry if I wasn't clear, what I meant was more in regards to people developing device drivers for Linux. There isn't a stable API for that, http://www.kroah.com/log/linux/stable_api_nonsense.html

There are some (stable) APIs for developing device drivers in userspace. But you have not mentioned the main point of that document, which is that (at least according to Greg) an out-of-tree device driver in kernel space is a Bad Idea.

Is the same true for gecko embedders? Is it fair to declare that any (say) help browser ought to be developed in the mozilla tree and that the mozilla team will help maintain it? If so, then you would have a good analogy.

Downstream developer ver

kripkenstein — Sun, 03 Apr 2011 20:45:27 +0000

> Not at all; there's nothing like the syscall API Linux has.

Sorry if I wasn't clear, what I meant was more in regards to people developing device drivers for Linux. There isn't a stable API for that, http://www.kroah.com/log/linux/stable_api_nonsense.html

> 1) there is no stable API, so downstream is forced to go from one branch to the next (and not stay on mozilla-central) - see, for example, Fennec itself which is going to take the Gecko 2.1 number.

Not sure what you mean about Fennec here - I'm a Fennec dev, and we track mozilla-central very closely. We use the same mozilla-central for our releases as desktop (perhaps a few commits earlier or later though). Point updates might end up a little different, but overall, we use mozilla-central just like desktop Firefox does.

> 2) You can submit patches all you want, but unless there's a clear benefit to Firefox, you just won't get it in.

I agree with this point and I'm concerned about it. We need to improve about that.

> That, to me, shows a lack of understanding of how they work. In case you haven't noticed: all those apps are large enough that getting a first useful version out takes longer than one Firefox version.

I would argue here, that they take so long *because* they fork the browser. If instead things like RockMelt started out as a Firefox addon, they could be finished much earlier. Yes, as you say they would need to keep up to date with new Firefox versions, but the benefits of that outweight the disadvantages.

The primary reason Flock and RockMelt are browsers, and not browser plugins, *is not technical*. The main reason is financial: Their business model is (or, for Flock, was) in large part identical to Firefox's: Revenue sharing with search engines. Only the browser itself participates with that, not addons, so they are forced to release entire browsers, with all the technical burden that that brings.

> Sorry, I might be bitter right now because, I quote: "I can appreciate why this is very useful to you guys but it isn't something that we need in the main project right now so all it will represent is added maintenance costs as we do further development"

Reading that makes me unhappy too. As I said above, I agree that we need to improve with that stuff. Can you please link me to the quote's source, so I can see the whole picture and try to help?

Downstream developer ver

Mook — Sun, 03 Apr 2011 19:00:49 +0000

I am a downstream developer.

In other words, you *can* still write Gecko apps, but you must integrate tightly with Gecko. This is sort of like the Linux kernel not committing to a stable API, things change as needed (people sometimes complain about that, but overall it lets the kernel move forward faster). Similarly, for Mozilla moving forward is much easier without committing to stable APIs for embedding. But again, you can still write apps that use Gecko without such APIs, just like you can write code for Linux

Not at all; there's nothing like the syscall API Linux has. Pretty much any developer doing anything has to end up forking Mozilla, for two reasons: 1) there is no stable API, so downstream is forced to go from one branch to the next (and not stay on mozilla-central) - see, for example, Fennec itself which is going to take the Gecko 2.1 number. 2) You can submit patches all you want, but unless there's a clear benefit to Firefox, you just won't get it in.

For empirical evidence: Songbird, Flock, Netscape 8, Komodo, MicroB (the browser on Nokia Maemo devices) all have patchsets they need to apply.

2. Second, to clarify the term 'killed' that the article used: If someone steps up to maintain the embedding APIs, they can continue. So in that sense nothing is 'killed'. It is just that Mozilla itself, however, isn't focusing on them, for the reasons I mentioned before.

That has worked out well for a number of things - http://hg.mozilla.org/ipccode/, http://hg.mozilla.org/pyxpcom/, http://hg.mozilla.org/chatzilla/, http://hg.mozilla.org/venkman/. By which I mean, of course, "continually broken because they don't test building them and don't care at all when they break". How's javaxpcom with Eclipse been working out? Unless you happen to actually work on Firefox or Fennec, (or, to a lesser extent, Thunderbird), you are probably not going to keep your code working.

Current applications that embed web browsers, like say Songbird, could today be websites or browser plugins, as browser capabilities have improved so much recently. For that matter, alternative browsers like Flock and RockMelt could be browser plugins.

That, to me, shows a lack of understanding of how they work. In case you haven't noticed: all those apps are large enough that getting a first useful version out takes longer than one Firefox version. Coupled with the complete lack of a stable API on the Firefox side, this means if you build them as an extension, you'll only ever be able to release it for the previous version of Firefox. The early adopters needed to get an application off the ground are unlikely to be doing that - would you, today, install an extension that completely changed Firefox into Songbird, if it required you to be using Firefox 3.6 rather than Firefox 4? Songbird is on Gecko 1.9.2.

Sorry, I might be bitter right now because, I quote:

I can appreciate why this is very useful to you guys but it isn't something that we need in the main project right now so all it will represent is added maintenance costs as we do further development

That's just the latest from trying to push changes upstream and watching them rot in bugzilla. If you are starting a new project, I would highly recommend you go use WebKit - at least they don't pretend they are trying to help external contributors.

Mozilla kills embedding support for Gecko layout engine (The H)

kripkenstein — Sat, 02 Apr 2011 16:37:12 +0000

Do you have mozilla bug numbers for those? I'm curious as to why they aren't fixed, discussion in the bugs might explain.

I'm more a platform guy than frontend, so not sure I can fix these myself, but if it's feasible I would try.

Mozilla kills embedding support for Gecko layout engine (The H)

mpr22 — Sat, 02 Apr 2011 12:47:54 +0000

You answer your own question. If nobody who cares about the project is in a position to provide the necessary resources (labour, web presence) to support and distribute the project (while not neglecting their other priorities), it dies. Even if it is FOSS - though a FOSS project is likely to be more resurrectable.

Mozilla kills embedding support for Gecko layout engine (The H)

mpr22 — Sat, 02 Apr 2011 12:44:37 +0000

Being a multi-platform user, I vote for Firefox's default configuration being as consistent as reasonably possible across platforms.

Some clarifications and opinions

justincormack — Sat, 02 Apr 2011 11:31:41 +0000

Interestingly on iOS, WebOS etc embedding HTML rendering is a core part of application development, often the main way of doing rendering. Dismissing this as not necessary, just open a browser seems short sighted. In principle you can extend the Javascript environment too. I dont think we should just mismiss this model.

Mozilla kills embedding support for Gecko layout engine (The H)

TRS-80 — Sat, 02 Apr 2011 10:57:19 +0000

browser.backspace_action appears to default to 2 in iceweasel 3.5.16 in lenny, and has for four years according to http://kb.mozillazine.org/Browser.backspace_action

No argument that in general Firefox is worse on Linux than Windows; I now run NoScript for performance as well as security.

Mozilla kills embedding support for Gecko layout engine (The H)

Hausvib6 — Sat, 02 Apr 2011 05:14:07 +0000

How can an open source software (or parts of it) be killed... Someone who needs the functionality can fork and maintain it. Yes, it needs resources.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Sat, 02 Apr 2011 05:13:18 +0000

And maybe you should disable the broken backspace goes to the previous page behavior, which is only semi-reasonable on windows, where IE users might want it.

There a lot of other windows-oriented defaults shipped on Linux that I could dig up given a bit.

Mozilla kills embedding support for Gecko layout engine (The H)

k8to — Sat, 02 Apr 2011 05:09:49 +0000

Maybe you should fix the bug where firefox raises itself to the top when it finishes rendering a page, only on X. It's been outstanding for years now.

Mozilla kills embedding support for Gecko layout engine (The H)

kripkenstein — Sat, 02 Apr 2011 00:13:00 +0000

> It seems to me that Mozilla thinks that everything should be done via the web, and sees the desktop as competition. And why support the competition by giving them a rendering engine to use where they see fit?

I don't think this is so absolute, but I see your point. Mozilla is definitely focused on the web. But it does have the Thunderbird project for example, so Firefox and the web isn't everything.

> If everything is done via the web, why care about the OS, why not just support the most popular one and reduce the needed effort? The freetards have access to the code and can port it if they like.

But the fact is, many or even most of the Firefox devs *are* 'freetards' and *are* Linux fans. Like me. It's possible we don't post as much on planet.mozilla.org, though...

> As far as Mozilla and on Linux history, it just my impression:

> * Firefox makes it hard on Linux distros by bundling system libraries, often modified and not upstreamed

True, but this is hard to do properly. Chrome does it even worse than we do, for example.

> * Trademark disputes also make it hard for the distros. IceWeasel etc.

That was definitely regrettable.

> * The focus was not on OpenGL for HW acceleration but proprietary non-portable graphics APIs. Sure the open source GL drivers aren't great yet, but that was only brought to attention of X.org in the last few weeks (in a year+ Firefox dev cycle)

I agree, the focus on Direct2D was not to my taste either. However, it was crucial in order to equal or beat IE9 on graphics performance, and performance is currently what users appear to care about. If we ignored Direct2D, the headlines on Firefox 4's release would have been "Firefox 4 is slower than IE9"...

> * The Linux chrome is the last to get attention and comparatively less.

True, and this annoys me as well.

Platform devs like me, who write mainly C++, tend to be Linux users. But frontend people who write mainly JS and xul tend to favor other OSes, it seems.

> * Songbird ditched Linux support

They aren't a Mozilla project. I don't know what their reasons were.

> I know a few Mozilla devs run Linux. Doesn't make it a tier 1 platform in users eyes.

> I get the feeling that Mozillans in general don't give a crap about Linux.

Again, it isn't a few Mozilla devs - many or most of us run Linux. Very few of us run Windows, btw - we have a hard time getting our devs to do that (most of the non-Linux people here use OS X).

I do see though that the viewpoints on planet.mozilla don't necessarily reflect that. I always suspected it is simply that the more geeky engineers like me that use Linux, don't blog as much. But I don't know.

> That's fine, miniscule market share and all that but it's a bit hypocritical to be all about the free web but work against the free desktop.

I really object to that. First of all, Linux is officially a tier-1 platform, one of 3. Second, Mozilla joined OIN, whose goal is to protect Linux. Third, as I said, many or most of us devs here at Mozilla run Linux and love it.

I agree that sometimes the bigger platforms get a little more focus - like frontend stuff. But overall we, including me personally, put a lot of effort into getting Firefox to work well on Linux, and that's why I was unhappy to see that you believe we don't care about it.

Mozilla kills embedding support for Gecko layout engine (The H)

tetromino — Fri, 01 Apr 2011 23:29:13 +0000

> The focus was not on OpenGL for HW acceleration but proprietary non-portable graphics APIs.

Because those proprietary non-portable graphics APIs are (a) fundamentally easier to use than OpenGL for the specific set of tasks that Firefox is trying to accomplish, and (b) are implemented by drivers that are reliable, widely deployed, and don't have a ridiculous number of untested corner cases that result in random web pages crashing the user's kernel.

If Linux had a less terrible graphics stack, Mozilla could have focused on it. But it doesn't, and so Mozilla didn't.

Mozilla kills embedding support for Gecko layout engine (The H)

Zizzle — Fri, 01 Apr 2011 23:10:49 +0000

Disclaimer: I'm posting this from FF4 and read planet mozilla every day.

It seems to me that Mozilla thinks that everything should be done via the web, and sees the desktop as competition. And why support the competition by giving them a rendering engine to use where they see fit?

I can see their point.

If everything is done via the web, why care about the OS, why not just support the most popular one and reduce the needed effort? The freetards have access to the code and can port it if they like.

As far as Mozilla and on Linux history, it just my impression:

* Firefox makes it hard on Linux distros by bundling system libraries, often modified and not upstreamed
* Trademark disputes also make it hard for the distros. IceWeasel etc.
* The focus was not on OpenGL for HW acceleration but proprietary non-portable graphics APIs. Sure the open source GL drivers aren't great yet, but that was only brought to attention of X.org in the last few weeks (in a year+ Firefox dev cycle)
* The Linux chrome is the last to get attention and comparatively less.
* Songbird ditched Linux support
* Now this no embeddeding policy... "its Firefox or nothing".

I know a few Mozilla devs run Linux. Doesn't make it a tier 1 platform in users eyes.

I get the feeling that Mozillans in general don't give a crap about Linux.

That's fine, miniscule market share and all that but it's a bit hypocritical to be all about the free web but work against the free desktop.

Mozilla kills embedding support for Gecko layout engine (The H)

kripkenstein — Fri, 01 Apr 2011 17:29:57 +0000

> Has anyone from the WINE project commented?

Yes,

http://www.winehq.org/pipermail/wine-devel/2011-April/089...

Wine is like SongBird, in that it is not affected by this change (and unlike Camino).

Mozilla kills embedding support for Gecko layout engine (The H)

kripkenstein — Fri, 01 Apr 2011 17:09:57 +0000

> This wouldn't be so bad if Mozilla treated Linux as a first class citizen with Firefox but it doesn't.

I'm a Firefox dev. Assuming you are being serious here - why do you think that?

I run Linux on my desktop, as do many (perhaps most) Firefox devs. So we care about running well on Linux both because it's one of our tier-1 platforms (alongside Windows and OS X) but also because we use it on that platform ourselves.

Mozilla kills embedding support for Gecko layout engine (The H)

Zizzle — Fri, 01 Apr 2011 15:35:18 +0000

This wouldn't be so bad if Mozilla treated Linux as a first class citizen with Firefox but it doesn't.

Mozilla is supposed to be all about freedom of the web but it has disdain for the free desktop users.

I guess Chromium/WebKit is the free desktop user's main hope now.

Mozilla kills embedding support for Gecko layout engine (The H)

rahulsundaram — Fri, 01 Apr 2011 09:11:01 +0000

That would be more like bundling and forking.

Mozilla kills embedding support for Gecko layout engine (The H)

nirbheek — Fri, 01 Apr 2011 08:35:23 +0000

However, embedding occurs outside of Linux too :)