Weekly Edition
Return to the Development pageRecent Features
| |||||||||||||
Mozilla kills embedding support for Gecko layout engine (The H)
The H describes Mozilla's plans to remove the ability to embed the Gecko layout engine into other programs. This will affect projects like the Galeon browser and other programs that currently embed Gecko. "In a posting to mozilla.dev.embedding, Embedding Module owner Benjamin Smedberg said that Mozilla had been considering the future for embedding Gecko in other applications. He cites the difficulty involved to date, the expected complexity of moving to a multiple process model and the desire to "strongly prioritize" Firefox as the key product of Mozilla. There is a possibility that embedding support could return in the future after Mozilla has moved Firefox to a multi-process model, but the developers are not going to [prioritize] that as a goal in their design work."
(Log in to post comments)
Mozilla kills embedding support for Gecko layout engine (The H) Posted Mar 31, 2011 22:12 UTC (Thu) by JohnMorris (subscriber, #73531) [Link]
I can understand Mozilla's desire to focus on Firefox above all else, but wonder if that leaves the other programs with the choice of Webkit or nothing?
Having said that, a few years ago I needed an embedded layout engine in a project, and having tried both Gecko and Webkit, found the latter much more amenable to being bent to my needs. Though that experience is a little old - things may have changed.
Mozilla kills embedding support for Gecko layout engine (The H) Posted Mar 31, 2011 23:04 UTC (Thu) by nirbheek (subscriber, #54111) [Link]
Galeon has been dead upstream, and on life support in distros for a very long time. I don't think there are any real users of gtkmozembed anymore.
The javascript engine (mozjs) is still being used in a few places (most notably in GNOME Shell via gjs). But if they continue being apathetic, I guess we'll have to move to WebKit/seed.
I do wonder what effect this will have on xulrunner-dependant projects such as Songbird will they permanently fork off xulrunner?
Mozilla kills embedding support for Gecko layout engine (The H) Posted Mar 31, 2011 23:09 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Songbird has been dead on Linux for a long time.
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 8:35 UTC (Fri) by nirbheek (subscriber, #54111) [Link]
However, embedding occurs outside of Linux too :)
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 9:11 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
That would be more like bundling and forking.
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 1:53 UTC (Fri) by roc (subscriber, #30627) [Link]
This announcement was about Gecko only. Embedding of the Javascript engine (Spidermonkey) will still be supported.
Using xulrunner to run applications like Thunderbird and Songbird will still be supported too.
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 0:09 UTC (Fri) by butlerm (subscriber, #13312) [Link] If you read the original post, what is really being killed isn't embedding support per se, but rather in process embedding support. Out of process embedding support may be added in the future. That seems like the right way to do it to me.So presumably all of these alternative browsers could, in the future, host a Gecko process that actually does html rendering and javascript execution, without adopting the user interface aspects of Firefox at all.
Some clarifications and opinions Posted Apr 1, 2011 1:41 UTC (Fri) by kripkenstein (subscriber, #43281) [Link]
I'm a developer at Mozilla. It looks like there is some confusion about this announcement.
1. Most importantly, *it is still possible to create applications that use Gecko*. Even without the Gecko embedding APIs, you can write such apps. For example, there are two separate Mozilla-supported apps that use Gecko: Firefox and Fennec (mobile Firefox). There is also Songbird, which is written in a similar way (the article mistakenly implies Songbird will be negatively affected by this announcement, which is not true - the situation for them is very different than for Camino, for example).
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.
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.
So, where does this leave things? If you want to write an app that embeds an HTML engine, you can still choose Gecko or WebKit. WebKit is easier to embed, but that has a price. As an example, look how quickly Google added cross-process support to Chrome, without any stable API promises and without anything but Chrome benefiting; Apple is adding cross-process support to WebKit itself, with a stable API, but it is still not complete as the process takes much longer.
I would argue, however, and this is totally my personal opinion - not Mozilla's - that all of this *doesn't really matter*. The places that need to embed a web browser are decreasing, not increasing, because things are moving *into* web browsers, not vice versa. What I am trying to say, is that these days people fire up their web browser and do everything from read news to check email to play games. They don't have separate apps for each that embed a web browser, they have a single web browser for all their activities.
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 leaves projects like Camino and Epiphany that provide much better OS integration than cross-platform browsers like Firefox or Chrome. There is a place for such OS integration. Some of it can be achieved with browser plugins, but I concede that it might be necessary in some cases to do more. I think that such work code be done with the upstream projects, though, to get the best results, as opposed to separate projects that just embed rendering engines. For example, Firefox can render using Qt on Linux, but it needs more love - would be great to see more Qt hackers contribute upstream on that, and to get Firefox/Qt stable.
Some clarifications and opinions Posted Apr 1, 2011 1:54 UTC (Fri) by jrn (subscriber, #64214) [Link]
I don't mind this change, but I don't want to let the following verbal trick stand:
> 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).
Um, no, it's not like that. The userspace API is stable (and indeed sometimes features need to be dropped, which would be a better analogy).
Some clarifications and opinions Posted Apr 1, 2011 1:57 UTC (Fri) by jrn (subscriber, #64214) [Link]
Sorry, bad reading comprehension on my part. I suppose what you meant is that in the _future_ there will still be an internal Gecko API, not that the Gecko API was already private.
Some clarifications and opinions Posted Apr 1, 2011 3:04 UTC (Fri) by tetromino (subscriber, #33846) [Link]
> The places that need to embed a web browser are decreasing, not increasing, because things are moving *into* web browsers, not vice versa.
There are many, many use cases for an HTML viewer widget. The most common one is documentation viewers, since documentation files can typically be converted to HTML on the fly, or even come in HTML form in the first place. Think of generic user documentation viewers (Yelp, KHelpCenter), specialized developer documentation tools (Devhelp, Monodoc, Pod Browser), as well as the help file viewers used by individual applications (LibreOffice, the GIMP, etc.).
Then there are various sorts of feed viewers that must be displayed inside a particular application. Say you have a full-screen, graphically intensive multiplayer computer game. To make sure that the players are up to date with any sudden changes, you need to display an RSS feed from the developers and server administrators in the game itself on login. The most natural way to do so would, of course, be an HTML viewer widget (with an OpenGL backend).
I am assuming that for all of these cases, using Gecko would now be more trouble than it's worth, and that you want the developers to embed the only other cross-platform alternative (Webkit)?
Some clarifications and opinions Posted Apr 1, 2011 4:05 UTC (Fri) by kripkenstein (subscriber, #43281) [Link]
> There are many, many use cases for an HTML viewer widget. The most common one is documentation viewers, since documentation files can typically be converted to HTML on the fly, or even come in HTML form in the first place.
I agree that HTML is a great format for documentation. However, I would argue that you would best view it in a complete web browser. The user has one anyhow, and it is most likely even running. And, you save development time that would be spent in writing a documentation viewer.
I realize there are reasons for embedding a documentation viewer inside an IDE or integrating it in some other manner with the OS or development environment. What I am arguing is that you can do that integration with a complete web browser with less effort (I agree it takes effort - but less) and better results.
> Then there are various sorts of feed viewers that must be displayed inside a particular application. Say you have a full-screen, graphically intensive multiplayer computer game.
I agree that this is a great example of something that needs to show web content in an unconventional place (and I actually worked on such an embedded web viewer, using PyQt - http://www.youtube.com/watch?v=tV7ei1Z40fQ - so I know how hard doing this is). I would again argue - at the risk of being predictable ;) - that instead of integrating a complete web browser in your game, we should have a simple way of fetching content from a running web browser, using standard methods for communicating between apps (like DBUS). With not a lot of work, we could add such a thing to the main open source web browsers, and apps that need it could render web content much more easily.
> I am assuming that for all of these cases, using Gecko would now be more trouble than it's worth, and that you want the developers to embed the only other cross-platform alternative (Webkit)?
Not at all, I would argue that *both* WebKit and Gecko would take much more effort that you should spend on this. First off, you need to write a lot of code to do it. Second, you need to bundle that code with your app, or depend on it in your distro's repos. Third, code isn't all of it: You also need to set up proxies, caching settings, and so forth, all of which is already working properly in the user's browser.
The alternative, as I said above, is to use the existing, likely anyhow running web browser already on the machine. We need a simple way to connect to it and render content from it in other apps. That would be much easier and effective.
Some clarifications and opinions Posted Apr 4, 2011 2:19 UTC (Mon) by jthill (guest, #56558) [Link] 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.
Some clarifications and opinions Posted Apr 4, 2011 3:10 UTC (Mon) by kripkenstein (subscriber, #43281) [Link]
> 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 Posted Apr 8, 2011 20:56 UTC (Fri) by jthill (guest, #56558) [Link] "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.
Some clarifications and opinions Posted Apr 2, 2011 11:31 UTC (Sat) by justincormack (subscriber, #70439) [Link]
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.
Downstream developer ver Posted Apr 3, 2011 19:00 UTC (Sun) by Mook (guest, #71173) [Link] 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.
Downstream developer ver Posted Apr 3, 2011 20:45 UTC (Sun) by kripkenstein (subscriber, #43281) [Link]
> 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 Posted Apr 3, 2011 23:47 UTC (Sun) by jrn (subscriber, #64214) [Link]
> 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 Posted Apr 4, 2011 0:01 UTC (Mon) by kripkenstein (subscriber, #43281) [Link]
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 Posted Apr 4, 2011 1:13 UTC (Mon) by Mook (guest, #71173) [Link]
> 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 Posted Apr 4, 2011 1:39 UTC (Mon) by kripkenstein (subscriber, #43281) [Link]
>> 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 Posted Apr 4, 2011 0:13 UTC (Mon) by Mook (guest, #71173) [Link]
> 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.
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 2:07 UTC (Fri) by marduk (subscriber, #3831) [Link]
Well most things seem to be switching to webkit anyhow...
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 4:24 UTC (Fri) by pabs (subscriber, #43278) [Link]
Another reaction to this news:
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 4:48 UTC (Fri) by pabs (subscriber, #43278) [Link]
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 7:04 UTC (Fri) by xanni (subscriber, #361) [Link]
Note that since many Windows applications presume the availability of a web browser, WINE emulates MSIE using Gecko:
Has anyone from the WINE project commented?
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 1, 2011 17:29 UTC (Fri) by kripkenstein (subscriber, #43281) [Link]
> 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) Posted Apr 1, 2011 15:35 UTC (Fri) by Zizzle (guest, #67739) [Link]
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) Posted Apr 1, 2011 17:09 UTC (Fri) by kripkenstein (subscriber, #43281) [Link]
> 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) Posted Apr 1, 2011 23:10 UTC (Fri) by Zizzle (guest, #67739) [Link]
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
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) Posted Apr 1, 2011 23:29 UTC (Fri) by tetromino (subscriber, #33846) [Link]
> 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) Posted Apr 2, 2011 0:13 UTC (Sat) by kripkenstein (subscriber, #43281) [Link]
> 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) Posted Apr 6, 2011 22:21 UTC (Wed) by lotzmana (subscriber, #3052) [Link] Firefox makes it hard on Linux distros by bundling system libraries, often modified and not upstreamedThere 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) Posted Apr 6, 2011 23:25 UTC (Wed) by jrn (subscriber, #64214) [Link]
> 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
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) Posted Apr 2, 2011 5:09 UTC (Sat) by k8to (subscriber, #15413) [Link]
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) Posted Apr 2, 2011 5:13 UTC (Sat) by k8to (subscriber, #15413) [Link]
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) Posted Apr 2, 2011 10:57 UTC (Sat) by TRS-80 (subscriber, #1804) [Link] 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_actionNo 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) Posted Apr 4, 2011 15:52 UTC (Mon) by k8to (subscriber, #15413) [Link]
Yes, because iceweasel fixes the default.
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 4, 2011 16:05 UTC (Mon) by TRS-80 (subscriber, #1804) [Link] 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) Posted Apr 2, 2011 12:44 UTC (Sat) by mpr22 (subscriber, #60784) [Link] Being a multi-platform user, I vote for Firefox's default configuration being as consistent as reasonably possible across platforms.
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 4, 2011 15:53 UTC (Mon) by k8to (subscriber, #15413) [Link]
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) Posted Apr 2, 2011 16:37 UTC (Sat) by kripkenstein (subscriber, #43281) [Link]
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) Posted Apr 5, 2011 12:24 UTC (Tue) by nye (guest, #51576) [Link]
>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) Posted Apr 5, 2011 14:25 UTC (Tue) by k8to (subscriber, #15413) [Link]
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) Posted Apr 5, 2011 16:31 UTC (Tue) by nye (guest, #51576) [Link]
>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) Posted Apr 5, 2011 23:52 UTC (Tue) by k8to (subscriber, #15413) [Link]
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) Posted Apr 5, 2011 23:56 UTC (Tue) by k8to (subscriber, #15413) [Link]
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) Posted Apr 6, 2011 15:58 UTC (Wed) by nye (guest, #51576) [Link]
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) Posted Apr 6, 2011 16:17 UTC (Wed) by k8to (subscriber, #15413) [Link]
When one has nothing left to say...
Mozilla kills embedding support for Gecko layout engine (The H) Posted Apr 2, 2011 5:14 UTC (Sat) by Hausvib6 (guest, #70606) [Link]
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) Posted Apr 2, 2011 12:47 UTC (Sat) by mpr22 (subscriber, #60784) [Link] 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.
|
|||||||||||||