But Mozilla CEO John Lily said that “it should come as no real surprise that Google has done something here – their business is the web, and they’ve got clear opinions on how things should be, and smart people thinking about how to make things better.” Lily believes that Chrome “will be a browser optimized for the things that they see as important, and it’ll be interesting to see how it evolves.”

The executive agrees that Google’s Chrome will have a competitive effect on Mozilla. “As much as anything else, it’ll mean there’s another interesting browser that users can choose,” he wrote in a blog post. “With IE, Firefox, Safari, Opera, etc — there’s been competition for a while now, and this increases that. So it means that more than ever, we need to build software that people care about and love. Firefox is good now, and will keep on getting better.”

That being said, Lily noted that” Mozilla and Google have always been different organizations, with different missions, reasons for existing, and ways of doing things.” While they are tied together in certain collaborative efforts such as security features as well as a financial commitment from Google until 2011, the executive hinted that the future relationship between the two organizations is not ironed out yet. “It’ll be interesting to see what happens over the coming months and years. I personally think Firefox 3 is an incredibly great browser – the best anywhere – and we’re seeing millions of people start using it every month,” he wrote in his blog

“It’s based on technology that shows incredible compatibility across the broad web – technology that’s been tweaked and improved over a period of years.”

Lily’s blog is carefully worded, but it surely seems that Google will be aiming to gain the upper hand in this relationship and at least ask Mozilla to adopt key features of Chrome features for Firefox. Mozilla could be caught between a rock and a hard place: Play with Google or compete against them and the mighty Microsoft? There is no need to answer this question immediately, as the first version of Chrome seems to be very rough around its edges and appears to be lacking key features that would let Google compete with Firefox 3 and IE8 in a much more serious way.

Original URL: http://www.tgdaily.com/html_tmp/content-view-39148-118.html

Beta 2 is aimed at a general audience; not just web developers who need early access to IE8 to find out what breaks (and what finally works), but a broader audience including IT staff evaluating the next browser version so they know whether to deploy it as well as end-users who just have to run the latest version of everything even if it isn’t quite finished yet. As well as the all-important standards compliance, IE8 brings a raft of new security, reliability, and management features. The official IE blog has described some of these already, and on Monday gave more details about what to expect in beta 2.

With IE8, Microsoft is attempting to solve one of the most annoying problems with today’s multi-window, multi-tab browsers; namely, the disastrous effect that a browser crash has. It is an unfortunate feature of most browsers that a crash in one tab takes down the whole browser instance. Whether the cause is a bug in the browser itself, a malicious script, or a badly-written plug-in, the effect is the same; not only does the tab that caused the problem disappear, so does the tab with your half-composed forum post, the train timetable you need to get home, and the audio stream you’re listening to.

IE8 tackles this by separating each tab into its own process, a feature it calls “Loosely Coupled IE.” Starting IE8 actually creates two processes; one process for the window frame, address bar, toolbar, and tab bar, and a second process for the tab itself. Subsequent tabs may also open in new processes. Running a tab in its own process allows that tab to crash (for any reason) without disrupting any other tab. This feature was present in Beta 1; in Beta 2, Microsoft has worked to reduce the overhead it causes and improve its performance. For example, now the processes creating the window frames are merged, so starting IE several times will only create new tabs in the existing frame.

The ratio between tabs and processes is not exactly 1:1; although this provides the most isolation, the ratio of processes to tabs will depend on machine capabilities. This process separation also resolves a major annoyance in IE in Windows Vista. In Vista, sites in different zones cannot be open in the same IE window. A file opened from the hard disk cannot coexist with a file opened from the Internet; instead, two different IE processes are required, one for each security zone. Because IE8 uses different processes for each tab, this restriction is lifted; different security zones will still use different processes behind the scenes, but they will be able to share the same window.

The final piece of the puzzle is Automatic Crash Recovery. As with LCIE, this was present in Beta 1, but has been improved for Beta 2. ACR is designed to improve the experience when the the inevitable occurs and a tab crashes. Instead of losing everything you were doing in the tab, ACR restarts the process and restores the tab’s context—in Beta 1, this meant it opened the same URL and kept the back/forward browser history.

ACR had promise in Beta 1; however, it neglected to recover the most important things—text entered into forms, and session cookies. Without these, the experience is a little frustratring; the browser reopens the right page, but you find yourself logged out and with your half-written e-mail gone. Beta 2 fixes this by recovering both form data and session cookies. This means that Beta 2 will be able to put you right back where you were before the tab crashed, with virtually no interruption.

As well as being incomplete, ACR in Beta 1 was not itself particularly reliable; it was easy to make the browser get into a never-ending cycle of crashing, restarting, recovering, and then immediately crashing (because the URL being recovered caused the crash in the first place). Microsoft has not said anything about whether this will continue to be a problem.

Of course, while better handling of crashes is no bad thing, it would be even better for the browser not to crash in the first place. Microsoft has long had an (opt-in) system for reporting crashes and hangs back to the company—Windows Error Reporting (aka, Watson). This data allows the company to locate bugs and determine which are in need of the most attention. On the blog, the IE team stated that they have committed to fixing the top 50 percent of all the Watson errors they have; this should provide a significant boost to reliability.

When IE8 is released later this year it will undoubtably be the best version of Internet Explorer ever. IE’s competition is improving all the time, and gaining in popularity, and—at least when it comes to standards compliance—is already superior today to what IE8 will deliver later in the year. Microsoft’s uphill battle to stop the rot and turn IE around is far from over.

Original URL: http://arstechnica.com/news.ars/post/…/recovery-tweaks.html

Of course, Mozilla has already fixed over 11,000 bugs, according to Mozilla developer Asa Dotzler. Even so, that doesn’t answer the apparent fact that the Firefox development community is planning to ship a product before a wide range of known blocker bugs are resolved. (Firefox 3 meeting notes can be perused here.)

For now, the mountain to climb appears quite high, as the New York Times notes:

As Mozilla pushes to post Beta 1 of Firefox 3.0, it has asked developers to prioritize already-identified bugs so that the most important can be fixed. But according to notes of yesterday’s Firefox 3.0 status meeting, that will leave about eight in 10 [remaining] bugs untouched.

“We have 700 bugs currently marked as blockers,” the notes read. “That’s too many. We’re asking [requiring] component owners to set priorities on blockers, as a first pass of what bugs should be Beta 2 blockers. You want it to be about 10% of blockers, or what you can get done in four weeks.”

On the positive side (and I mean that sincerely), Firefox 3.0 continues to miss its stated deadlines. I think this is good. It means that, in fact, Mozilla is prepared to put quality of code before an arbitrary release schedule. My life will go on if I continue using Firefox 2.0. In fact, Firefox 2.0 works exceptionally well.

What I don’t want is to transition to a presumably “ready” Firefox 3.0 only to have it routinely die on me. Fix the bugs first, Mozilla. There’s just no need to hurry the release.

Original URL: http://blogs.cnet.com/8301-13505_1-9818903-16.html

The vast majority of web developers acknowledge that JavaScript in its current form is anachronistic compared to modern dynamic scripting languages. The ECMAScript 4 draft process hopes to resolve weaknesses with the language by adding additional syntax elements, many of which are heavily influenced by Java and Python. ECMAScript 4 is largely backwards compatible with conventional JavaScript, which means that it provides a clean glidepath for updating legacy code.

Critics like Microsoft and Yahoo argue that certain characteristics of the language (particularly the prototype-oriented object model) make it impossible to add modern language features to ECMAScript without dramatically increasing the complexity of the language, breaking existing code, and creating new interoperability problems. Such critics believe that the focus should be on improving interoperability between existing ECMAScript 3 implementations and that modern scripting capabilities would be best provided by using a completely different scripting language.

Although this approach could provide a cleaner language for web scripting, it would mean that all existing JavaScript code would be trapped forever in the ECMAScript 3 standard and would have to be completely rewritten in order to benefit from much-needed modern language features. There are also serious concerns that new alternative languages would be less standards-oriented than ECMAScript.

“[T]he ES4 proposal introduces a lot of new language functionality that essentially changes the character of the language,” wrote Wilson in a recent blog entry. “I don’t personally have a problem with that language as a language—but I think grafting that different-in-character-language together with a compatible-and-performant implementation of the Javascript of today is both super-hard (if even possible) to get right, and is ignoring the bigger problems of language-for-web, namely interoperating with all the script that is out there.”

The accusations fly
Wilson and other critics have complained that their concerns are being suppressed and ignored by Brendan Eich and others. Several participants in the ES4-discuss mailing list claim that Adobe and Mozilla are authoring the spec in a manner that best suits their interests without consensus and that other parties are simply shouted down or ignored.

“I think it’s a shame that dissenting opinion has been hidden from view, and not publicized,” said Wilson. “I also think it’s a shame that the response to any dissent has equated to shouting the dissenters down. The string of blog posts over the last week, and the immediate and somewhat incendiary comments from ES4 proponents, has been a good example of that.”

Eich and those who are satisfied with the current process and direction regard those allegations as FUD—baseless nontechnical criticisms that add nothing of value to the ECMASCript 4 process. In an open letter to Chris Wilson, Eich criticizes Wilson and accuses him of dishonesty.

“You seem to be repeating falsehoods in blogs since the Proposed ECMAScript 4th Edition Language Overview was published, claiming dissenters including Microsoft were ignored by me, or ‘shouted down’ by the majority, in the ECMAScript standardization group. Assuming you didn’t know better, and someone was misinforming you, you (along with everyone reading this letter) know better now. So I’ll expect to see no more of these lies spread by you,” wrote Eich in his open letter to Wilson. “At best, we have a fundamental conflict of visions and technical values between the majority and the minority… There certainly was no shouting down of the dissenters—that’s a bold lie in view of the well-attended and friendly dinners sponsored by the face-to-face meeting hosts.”

A way forward?
Although Microsoft representatives haven’t stated outright what they would propose for a new web scripting solution, the writing is pretty much on the wall. Microsoft’s Silverlight rich Internet application framework uses .NET and the Dynamic Language Runtime, which brings support for IronPython and IronRuby to web scripting. Using languages based on Python and Ruby for next-generation client-side scripting solutions makes a lot of sense on many different levels. A growing number of developers already have experience with those languages and many tools already exist to ease development with them. A single multilanguage runtime could be used in the browser to support JavaScript as well as more modern scripting languages.

Mozilla has already tacitly endorsed this approach with its own (prodigiously cool) IronMonkey project, which aims to build a bridge between Microsoft’s open-source Dynamic Language Runtime and Mozilla’s Tamarin virtual machine, which will be used to run ECMAScript 4 code. When we reported on IronMonkey back in July, more than a few Ars readers posted comments expressing a desire for a future in which client-side web scripting could be done entirely with Python and Ruby rather than with JavaScript.

As a developer with experience in Python, Ruby, and JavaScript myself, I know that I would definitely prefer Python and Ruby to a new dialect of JavaScript that liberally incorporates features of those languages. That said, it is worth noting that advancing JavaScript with the ECMAScript 4 standard as envisioned by Mozilla and Adobe doesn’t preclude the possibility of adopting multilanguage web scripting platforms.

The real question is whether or not it still makes sense to extend ECMAScript regardless of whether or not alternate languages are made available as well. Eich argues that ECMAScript 4 is important for furthering standards-based web scripting, but critics are still concerned that extending ECMAScript in the manner proposed by Eich will fail to address critical security and interoperability issues while putting backwards compatibility at risk. Eich still doesn’t believe that anybody has adequately articulated these problems in a way that shows real concern about the technical merits of ECMAScript 4.

Meanwhile, parties on both sides of the debate are becoming increasingly accusatory and have taken to publicly criticizing each other’s motives. Web scripting needs to move forward, and it’s unfortunate that the process has become mired in controversy.

Original URL: http://arstechnica.com/news.ars/post/20071102/…/scripting.html

Mozilla has recently hired two new developers to help work on the project and plans to release Mobile Firefox some time in the next year or two.

The iPhone, Apple Inc.’s popular new mobile phone, in part contributed to the renewed interest in mobile browsing at Mozilla. “The user demand for a full browsing experience on mobile devices is clear,” Mike Schroepfer, vice president of engineering at Mozilla Corp. wrote in his blog on Tuesday. “If you weren’t sure about this before, you should be after the launch of the iPhone.”

As Mozilla continues to develop Mozilla2, the second version of the platform on which Firefox is built, it will add mobile devices as a category. That means developers of Mozilla2, which is expected to be complete in early 2009, will keep mobile phones in mind as they build the new platform, Schroepfer wrote.

He didn’t get more specific on a release date for the mobile browser other than to say “not before 2008.” Schroepfer also said Mozilla hadn’t yet decided which mobile phones the browser would work on.

Depending on compatibility, Mozilla could face competition from companies such as Microsoft Corp. and Apple that include their own browsers in phones running their operating systems, as well as from third parties such as Opera Software ASA that have been fine-tuning their mobile browsers for years now.

The announcement comes after the release earlier this year of a new version of Minimo, a Mozilla-based mobile browser for Windows Mobile devices. A few months prior to the release, the lead developer of Minimo said he wouldn’t be spending much time on the project in the future. On Tuesday, Schroepfer said that there are no plans to further develop Minimo.

Mozilla also offers Joey, a project in development that lets users clip and save text, photos, videos and other content while using a PC and then access that content through a browser on a cell phone.

Mozilla is also involved with a group of companies including Arm Ltd. and MontaVista Software Inc. that is developing an open-source Linux-based platform for devices that are bigger than a cell phone but smaller than a laptop. Mozilla is developing a browser for the platform and has already built one for a similar device, the N800, from Nokia Corp.

The new Mozilla hires who will contribute to the mobile Firefox initiative are Christian Sejersen, who recently worked for Openwave Systems Inc., and Brad Lassey, who worked for France Telecom R&D, which has been very active in mobile Linux initiatives.

Original URL: http://www.pcworld.com/article/id,138313-c,mozilla/article.html