<Glazblog/>

(Note: this article did not originally appear on planet ; but given the incredibly violent reactions to Gerv's article I read, I changed its category)

Associating Gervase Markham and the words "hate speech" or "a particular group of people are not human" are very clear indicators that the author (Tim Chevalier) of these words doesn't know our Gerv, should urgently cool down, vent his anger on something else or focus his energy on treating his own paranoia. And Tim is not the only one who should cool down. The reactions to Gerv's post are far too violent.

Associating Gervase Markham and the words "we’ve fired people who made bigoted remarks at work before, and we’ll do it again" seems to me a rather violent attack on Gervase's UK constitutional rights granted to all UK citizens physically in the UK to say what is legal is the UK on their UK blog. And even a US employer can't go against that inside the European Union. Associating Gerv and these words is a threat, and that threat is no better than the imaginary hate it calls against. That threat is, at least to me, unacceptable and has nothing to do with the Mozillian spirit.

Years ago, someone left hate messages on Gerv's blog abusing my identity. Gerv did the right thing : he pinged me instead of replying instantly with public hate himself. Why is so hard to do the same in the current case and solve the issue as ADULTS instead of draggling Gerv backwards and forwards in the mud?

Planet.mozilla.org syndicates blogs without filter. Fix planet, but stop harassing Gerv. Period. His blog, his web site, his freedom of speech, with perfectly legal words as a UK citizen. I don't agree with Gerv here, but I fail 100% seeing hate or humanity denial in his prose. And associating his own prose to Mozilla-the-corporation-and-the-foundation only because it appeared on an unfiltered pmo seems to me strict political correctness.

Today, on pmo, there's a blog article titled "Freelancing". It has nothing to do with Mozilla, strictly saying. It could be understood as an ad for the author. Syndicated too on Mozilla resources ; interestingly, nobody reacted to that one. The Mozilla Community is global? Show it. Show you're able to deal with other cultures, other law systems, other opinions. Debate. But don't silence people. Silencing legal opinions is dictatorship.

Anyway, I also wanted to tell my support to pmo peers ; staying onboard and keeping the boat sailing in the middle of such a ridiculous storm is not funny, not a nice moment. Thanks for doing your duty and remaining a voice of sanity, guys. Seriously.

That's in Firefox recent builds. Nice. In particular for dark images with a lot of alpha transparency Now click on the image below to see it standalone. I find the result incredibly disturbing in terms of contrasts. That will probably be a severe accessibility issue for contrast-impaired people. Why was such a change done instead of adding a new checkbox preference to the Content panel of the preferences window "View images over dark background", unchecked by default?

Exactly two years ago almost to the day, BlueGriffon started using Bespin for its source editor.

Two years and two name changes later, not only the project has drastically changed from its original codebase but the documentation for the project is still almost non-existent; lack of doc is already painful for a project like mine, a wysiwyg standalone editor, but it's awful for an embeddable project like Ace.

The complexity of the code and its architecture, it's monstruous size, the crazyness of themes in CSS themselves contained in JS and more make my every day's life with Ace more and more difficult every day.

I am pondering switching to another source code editor because of:

1. readability of the code; using Require.js all over the place helps the developer, rarely the user. The other embeddable editor I'm currently looking at is incredibly more readable than Ace. When I want to hack Ace, I'm totally lost and I never know if the code I'm writing will be correctly exposed to the external world. Even worse, I never know if a given function I was planning to use is exposed to me or how.
   
2. size of the code; the other embeddable editor I'm currently looking at is 4 times smaller than Ace... Sorry, but yeah, size matters.
   
3. theming is too complex for what it's worth in Ace. I want CSS and CSS only, like in any good web page.
   
4. speed - and I agree Ace is fast - is not an excuse. The other embeddable editor I'm currently looking at has no problem whatsoever dealing with a 35,000 lines javascript file.
   
5. embedding a grammar inside another one, and html documents can contain scripts and css while html file can also contain php, is vital to me. Doing that in Ace is, to say the least, totally cryptic to me.
   
6. autocompletion should not be complex to add. With Ace, it is complex. A good autocompletion for html or CSS should not be more than roughly 30 lines of very light JavaScript.

I understand this is not a positive message, but I wanted to share my concerns with you if that can help the project. Even if I may stop using it in the very near future, I wish Ace all the best.

Disruptive Innovations, home for BlueGriffon, Nvu and so many other projects, is 8 years old today So I spent more time in my own company than in any other company I worked for... What a ride !

Our content serializer has a lot of flaws. I could mention wrapping that often does not work as expected and should not wrap asian scripts, raw mode that is not really raw, and more. But one of the most painful bugs is a bug related to blank lines suddenly appearing in the serialization of HTML documents. To experience that bug with a modern gecko-based editor, launch BlueGriffon, click on the drop-down arrow of the New button and create a transitional HTML4 document. Switch to source view and back to wysiwyg a few times.

1. there is an extra blank line appearing between <head> and <meta> each time you switch to Source !
2. there are unexplainable blank lines after the paragraph

These are two different problems.... The latter one is weird and painful: if I load this trivial empty HTML4 document into Firefox and inspect it using the DOM Inspector or Firebug, I see a text node erroneously (in fact, it's erroneous for SGML parsing that applies to HTML 4, but that's the html5 parsing model) containing multiple CRs... In fact, the serializer here is not buggy, there are really multiple CRs after the end of the paragraph element. In fact all the nodes between just after </body> and the end of the document are appended to the body element in the DOM; adjacent text nodes are concatenated. So the serializer is not buggy here, it really sees blank lines. I will hack BlueGriffon source view to work around that.

<hsivonen> glazou: that's intentional, spec compliant and by design
<hsivonen> glazou: sucks for editors. makes sense for all other classes of products ingesting HTML
<hsivonen> glazou: this significantly simplifies dealing with random cruft after </body>
<hsivonen> glazou: WebKit has done this for years with great success
<hsivonen> glazou: this is the Web
<aja> "leave all sense of logic at the door" 

If I understand perfectly the rationale behind that parsing choice for browsers, it just sucks for non-browsers. It's a pain for editors, filters, all tools having to deal with source or exact DOM representation of the document instance. A text node can live in the DOM after the body or even the html elements. That's how we can have a xml-stylesheet PI or comments living before the root of the document...

I think the parsing model should be changed here, or adapted to be more precise : extra nodes after the body element should be appended to the body element if and only if they are not all blank (matching /^\s*$/) text nodes. If they are all blank text nodes, they remain in place and are ignored by the UAs or are deleted from the DOM. That would preserve the behaviour hsivonen needs above and would help a lot editors and transformation tools. A good compromise, in my humble opinion. At least a better one than the current one.

The head/meta problem is a weakness of Gecko's serializer: the mMayIgnoreLineBreakSequence attribute is not correctly used in nsHTMLContentSerializer and nsXMLContentSerializer. In particular, nsXMLContentSerializer::AppendToString should detect if the string to append contains CR or LF and contains only whitespaces (à la \s). If both are true, then mMayIgnoreLineBreakSequence should be set to true. Of course, AppendNewLineToString() should return without proceeding if mMayIgnoreLineBreakSequence is true, and AppendIndentation should probably not set it back to false. A few other spots have to be modified too but all in all it should be doable. I hope there won't be bad side effects for instance on some specific elements like pre. Stay tuned.

One thing I immediately missed under OS X Lion was the ability to scroll to the top or bottom of a document with three fingers. Since I browse a lot of long documents, for instance W3C specs, I really needed it back. Open OS X Preferences, show the trackpad panel, switch to the last tab, and select "4 fingers" for the Mission Control and Exposé trackpad shortcuts. Then your usual three-fingers scrolling gestures still work in Firefox.

Far beyond that, I have a question related to the new NSDocument features if you're a mac Mozillian: how could I enable the versioning and autosave features in BlueGriffon?

Note: I tried switching to the new scrolling beheviour of Lion. I really tried. Just could not. I switched back to the Snow Leopard behaviour unchecking the first checkbox in the second tab of the trackpad preferences panel...

I could have titled this article "I understand even less". Asa wrote the following in a comment on an article on Gerv's blog:

We have and we will break add-on API compatibility with every release, certainly binary add-on compat

I spent part of the night thinking about it but still, "Urgh..." is the only thing that comes immediately to my mind. I'm shocked, so shocked, you could not believe how shocked I am. Bumping version numbers every six weeks for strictly declarative (xul/js/css/xbl) add-ons is one thing and breaking binary compatibility for binary-based add-ons is another one. The former case is painful but doable in a lot of cases. I still think that add-on authors (I am an add-on author) will rapidly feel the pain but that's nothing in comparison with breaking binary compatibility every six weeks...

Some years ago, I contracted for Wengo, the VoIP division of a major telecom player here in France. We took their huge pile of binary libs, encapsulated them into binary components (painful but still simpler than js-ctypes) and I built both a SIP-based VoIP add-on for Firefox and a standalone application on that basis. Quite impressive, I must say. With a mandatory recurrent six weeks XPCOM component update/rebuild/reship process, my client would never have done that work because that's impossible to sustain.

On a more personal note, some of my personal add-ons to Firefox are binary-based, and there is no way I can dedicate time every six weeks to them. Most add-on authors work on add-ons on their personal time and will be in the same case.

Add-ons are the major plus Firefox and Thunderbird has over browser competitors. That ecosystem is unique. Harming that ecosystem is a counter-productive decision of such a magnitude I am completely lost these days reading Mozilla's strategic decisions. It seems to me the path taken is an engineer's path, not a market-based one. It seems to me based on a wrong analysis of the market, the competition, the users' needs and the marketable differentiating factors.

Our PR team and our Marketing team are happy with the current system and they're the ones on the front lines of "publicity". Also, that negative publicity has already happened. It's in the past. It may happen to a much lesser degree with 6 and probably even less with 7 and eventually it goes away as the version number disappearing act finishes

I think I see what's going on here. Asa is betting on the extinction of the criticisms over time. That's why despite of the incredibly negative press world-wide, we saw no serious reaction and why no improvement has been seriously discussed. The weekly meeting minutes of Moz are, from that perspective, incredible: almost no mention of the world-wide fuss Asa generated two weeks ago. First, that's certainly not how the community feels Mozilla should react. Gerv seems to agree (see comment starting with "That is one of the most depressing things I've seen you write in a long time"). This feels like an occasion long ago when Blake Ross was forced to "discuss in Bugzilla" something he had made a decision on, and responded by posting there one single word: "discuss."

At this point, and I never thought I could say that one day, I don't trust any more Mozilla's strategy for Firefox. I don't trust any more its Product Manager for Desktop Firefox. It's not the person, it's the strategy. I'm not angry, I'm incredibly sad. During all these years, I tried to draw the attention on markets addressable by Moz and not addressable by other browsers. I failed. During all these years, I did all my best to give my opinion about how to extend the ecosystem, the true cornerstone of Firefox's success. I succeeded implementing these ideas for my own product, BlueGriffon, but I failed for Firefox. I'm sorry, I'm so sorry.

At this point, I think the CEO of Mozilla should talk, loud and clear, and talk about this more with both the community and the users. Enough with corporate blah-blah, and I could say corporate bullshit.

The bird has left the nest : INSTANTBIRD 1.0, the Instant Messenging app based on Gecko/Xulrunner, IS NOW AVAILABLE !!! Mucho congrats guys !!!

Asa (recently named Product Manager for Desktop Firefox) commented a lot in Mike Kaply's recent blog entries following my own. I must comment myself on Asa's answers because some are just shocking.

Mike, you do realize that we get about 2 million Firefox downloads per day from regular user types, right? Your “big numbers” here are really just a drop in the bucket, fractions of fractions of a percent of our user base.

Uh !?!? We spend 8 to 10 hours per day (out of 16 hours awake) at work where the browser is one of the most important productivity tools ever, but corporate users are a drop in the bucket and therefore should not be addressed? Wow. Speaking of "drops in the bucket", I really wonder why accessibility is so important then... Oh, wait, there is a legal arsenal supporting accessibility. Even if localization is done by the community, Mozilla also spends resources to build and distribute Firefox in minor (in terms of speakers) languages like Basque or Breton. Who said drops in the bucket?

Speaking of drop in the bucket, I have an important question and I would like a firm, official and non politically correct answer: what is the future of Xulrunner?

Enterprise has never been (and I’ll argue, shouldn’t be) a focus of ours

We'll see. The day you understand that fighting Chrome with Chrome's strategy does not bring any differenciating factor and can only lead to the superiority of Chrome, you may change your view and finally discover there are important markets shares that are strictly not addressable by Chrome for various reasons. BTW, an old friend of mine, IT top manager for a 40,000+ employees, company called me yesterday. Verbatim: "once IE10 is out, we'll switch back to IE, the only browser that does care about corporate users despite of the issues it also raises ". Devastating... Already well heard in Redmond apparently.

A minute spent making a corporate user happy can better be spent making many regular users happy.

I dispute that. The finances and resources spent to implement and ship Panorama, an unfinished, unextensible, unlocalizable feature that drastically changes the center of gravity of the browser and was finally hidden would have been better spent on the production of a MSI package for corporate IT teams.

Firefox 6 will be the EOL of Firefox 5. And Firefox 7 will be the EOL for Firefox 6.

Here in France, Firefox is used by governmental agencies, Ministers and even the Gendarmerie Nationale. I think you just lost them, in the middle to long run. By the way, will Thunderbird follow the same path for versions EOL?

IE9 is a fine browser and probably better suited to those who want long-term support. It’ll always be behind the consumer browsers (Firefox, Chrome, Safari, and Opera)

WOW, to say the least. I would not bet a single cookie on that. And to be frank, I think IE10 will easily compete with the "consumer browsers". I even think IE10 and IE11 will start a frontal attack against the extensibility of Firefox and therefore a big part of its market share.

The Web platform is going to move forward at an increasingly swift pace, whether enterprises like it or not. There’s no stopping that. The Web is much bigger than the enterprise. It is a large and important piece of how we all live and it won’t be held hostage to the slow-moving dinosaurs of the past

Last time I checked, the companies you quite shockingly call "dinosaurs of the past" were still feeding us, providing your computer with electricity, allowing us to drive cars, to fly from a continent to another one, to buy flats or houses, manufacturing physical goods. And none of them releases a new version every six weeks. Browser vendors are extra-terrestrial aliens in this world. They think, because it's a browser war, users and web authors need 10 new browser versions per year. They don't. The only thing they really need is an interoperable Web and that's a totally different thing.

Basically, enterprises need to get more agile. They need to devote all that test/certify/train every three to ten years energy to continuous testing and roll-out system. It’s not more work or more money, it’s just a different schedule of work.

Winning a fight (hear a browser war) implies reaching new users. It also implies not letting existing users go. Asa thinks only individual users, I think all users. A blind user does not deserve less attention than a not visually impaired user ; similarly, a corporate user does not deserve less attention than others. And Corporations will not change the speed of their validation process because they just can't, they have too much to test with too small teams to achieve that validation in six weeks' time. Thinking they can shows only a total misunderstanding of what is an industry outside of the Computer Science domain and outside of the Bay Area's habits.

So Firefox 5 is about to ship. Before anything else, let me translate here two excerpts from this article in French about Firefox 5:

...this is not a major evolution of the browser but more an update to Firefox 4... No visible new feature...

I read and heard a lot about the good things coming from a faster release process. They are downsides too, and nobody really listed them in public. Given the impact on my own daily work, I think it's time to start the feedback loop. Reminder: criticism is always good, it helps spotting issues before they become too big and too painful.

1. version numbers become meaningless. Firefox 4 was released the 22nd of march; 4.01 the 28th of april. Firefox 5 is about to be released. Firefox 6 and 7 are already announced. But even the press says 5 does not deserve a major version bump. Why not a 4.2 ? What's the mood of a user receiving a Firefox 5 when he/she sees no immediate visible difference with a Firefox 4 and when even the web site he/she reads about it says "no visible new feature?".
2. corporations cannot follow that speed. Big corporations have to evaluate a new browser against their intranets and often with their corporate partners before allowing it. Even builtin update to minor versions is often forbidden because of corporate rules. Making version number evolve faster puts a huge burden on the IT departments of big corporations: the users see a bump from 4 to 5 and ask for it while a bump from 4.0 to 4.1 does not cause the same reactions.
3. Google does it. So what? Last time I checked, the Mozilla Manifesto was about openness, freedom of choice and innovation, not competition with WebKit.
4. the Mozilla ecosystem suffers. Users of tools embedding Gecko (for instance through XULRunner) want applications matching the modernity and security of the last version of Firefox. But it's very difficult for organizations that are most of the time much smaller than Mozilla itself to follow the trend. In the case of BlueGriffon, 1.0 was released the 10th of may. A v5 of Firefox released in the coming days will without any doubt trigger feedback from users wanting a version of BlueGriffon matching that v5's core and I am not ready yet, that's far too fast for me. Even if my tests show I can go on with the last xulrunner, my feature set did not improve that much to bump to 2.0. I can already hear the counter-argument: don't mention Firefox versions, mention Gecko versions. But guys, that's exactly what I said about the "Powered by Mozilla" stamp: a lot of people have just no idea what Mozilla or Gecko are! They know the name "Firefox", they partly ignore "Mozilla" and totally ignore "Gecko". Firefox is the only reference that does matter here.
   Anyway, moving to a new version of Firefox, its toolkit and Gecko will always require from 3rd-party embedders tests and often adaptations to their own code. That takes time, and the faster release process does not really care.
   By the way, don't the marketing teams at Mozilla suffer too? A major version every 16/18 weeks, wow...
5. Fragmentation and workload for embedders. If embedders want to anticipate just a little bit what's going to happen in Firefox or the toolkit or Gecko, the time investment just multiplied by 3 or 4. For most of us, that's just not feasible and we'll follow only the about-to-be-released tree and we will probably always lag. In other terms, we won't detect bugs caused by changes in the other ones, the to-be-released-in-16-and-32-weeks trees and we'll let pass regressions or issues that should probably be detected immediately.
6. Web authors will have to sniff even more browser versions. It's a browser war time and new cool kids are around the block. 3D Transforms, Animations, Reflections, Device APIS and many, many more. A faster release process means a greater fragmentation of the browser landscape and that's absolutely terrible for web authors.

I'm not saying a faster release process is 100% bad. I'm only saying here it has important downsides that are in my opinion important enough to trigger a feedback loop. Why not a faster release process but with minor version numbers instead of major version numbers? In particular, the side-effects on the Mozilla ecosystem and the Web authors' community seem to me really underestimated.

Update: I forgot to mention the huge impact on add-on authors... And add-ons are one of the most influential points in the success of Firefox in front of Chrome.