Today on MozNews we ran a story on a couple browser-related interviews. In this one, Gary Schare blows more FUD smoke to confuse the issue, and generally lies.

Such as this: “For architectural reasons, it turns out you can’t just add tabs via an add-on into the IE app itself. You can get tabs by running a different app like those other browsers that build on the IE platform, so it’s a nice option for people.” Bullshit. That’s just bunk. IE is just a shell that calls mshtml.dll and shdocvw.dll for rendering content inside the viewport. They could add tabs exactly like other IE browsers have done, ones that they even mention. You can’t add tabs to mshtml.dll, but then again, why would you? That’s the renderer, not the UI.

I rant more, and address a number of issues in detail below. click Read More for the rest.

Or this gem: “We’ve looked at whether you can add tabs through a browser helper object or some other way of extending IE, and it turns out you can’t.” Ok, then why do you show how other folks do it? In fact, you could code up a shell that is identical to IE that no one would ever be able to distunguish without examining the source or the binary files, and then add tabs to it and not break a thing. So they’re lying about their own product.

“We could change the CSS support and many other standards elements within the browser rendering platform. But in doing so, we would also potentially break a lot of things.” Yeah, if you finally fixed some of your CSS bugs it would break other people’s hacks toget around your bugs, but you could still fix them, and degrade gracefully, like we do with Gecko. You could also add new CSS support that wouldn’t break anything, or fix your atrocious PNG alpha support.

“That’s something I think the Mozilla guys have had a bit of a free ride on, until now. Every time they ship a new version they break all their extensions and break a bunch of things because they were in beta. Now they’ve got a product out there that’s a 1.0, and people will look at it as “Okay this is 1.0, I’m going to count on this and I’m going to expect some backwards compatibility for some time forward.” And that has not been the hallmark of open source software in general. If you go look at OpenOffice for example, that’s one of the things that has not proven out.”
Betas are allowed to break because they’re not production code. I can’t count how many apps were broken in various beta versions of Miscrosoft operating systems. I can’t think of how many billions of documents would be broken if using a beta of Word of Excel. Further, I can’t think of how many apps have been broken with final, non beta versions of Windows upgrades. How many features, and thus systems were broken with OS upgrades and service packs. So, this is one soap box Microsoft really shouldn’t be preaching from. Not counting how many apps were broken by finally fixing IE’s horrendous security with Windows XP SP2.

“We’re committed to that, and we get criticized for it on some dimensions. They say “You’re not innovating as rapidly,” Well that’s true, but when you have actual customers who rely on your software you have those tradeoffs and we’re very diligent on how we make those tradeoffs.” Sure, if it’s for IE, the tradeoff is to not bother because it doesn’t make any money. If it’s Windows, do whatever you have to do to get them to upgrade though, because that’s revenue. This is where Mozilla.org has a huge headstart. With no products to have to sell, there’s no revenue stream to worry about or threaten. It’s all donations of people like what they do and feel the work is worth it. And open source allows people to fix the problems that go unaddressed by the market.

“One of the hallmarks of Windows is this very, very broad ecosystem of developers who build on the Windows platform, and that has been one of the things that has made Windows so successful over the years. So from one standpoint we’re happy to have even more developers adding value onto the Windows platform and giving users a choice of software to pick.” But from another, if you feel a vendor has too popular an application, you crush them, even though it won’t threaten Windows itself.“Sometimes developers build things that Microsoft doesn’t do, and other times they build things that compete directly with things Microsoft does do. In this case, it’s something that competes with something we offer.” Usually it’s the other way around. I can’t think of a single market Microsoft was the first to address. MS sees an attractive or potentially threatening market, and attacks.

“Again, if you compare how much Firefox has gotten out there, talking all about the 5 million downloads of the preview release, at the same time we did like 100 million of SP2 with the new version of IE. We do operate on a slightly different scale, a different order of magnitude frankly.” People didn’t download SP2 to get IE, they downloaded SP2 to fix the IE they already had by your forcing it on them with Windows. And 100 is twice an order of magnitude of 5.

“Frankly a lot of work we do will probably help the Mozilla guys too, but it’s not clear they’re going to be able to drive this kind of an effort on behalf of their products. Nor is it clear how they are going to respond to threats that come up once they do have an actual installed base of customers using their product. You can’t just put a patch out overnight and say you’re done. You have to actually test hundreds of thousands of scenarios and put a process in place before you release these things.” Ahh, but we have proven ourselves with a huge userbase, via the suite and Netscape (with tens of millions of users). And a unified codebase that is not integrated with the base OS goes light years towards making sure a fix actually fixes the issue without compounding more. Plus, our issues are rarely of the severity IE holes are. I have yet to see a bug where merely having Mozilla or Firefox installed causes security flaws with no user action is necessary. I can fire up Firefox, and let it sit there, knowing it don’t do anything to allow crackers to breach my computer’s security. Windows and IE on the otherhand require the user to use a firewall just to prevent the numerous worms out ther efrom invading. As a test this spring, I had to reformat and reinstall Windows on a client’s machine. I installed Windows XP, applied the appropriate patches, then I imaged it, and then plugged it directly into the net. In less than a minute it was infected. After I erased the hard disk and redeployed from the clean image, I installed the appropriate firewall and AV software. that was bad enough. But now there are exploits of the JPEG rendering code! Merely visiting a website will now infect mashines! I don’t see that happening with Firefox.

“There you’re only look at one dimension, which is the dimension of features. You’re saying, “If I can get tabs in Maxthon, well I can go get tabs in Firefox, therefore I am going to switch.” But that does away with all of the security stuff that we’ve just talked about, all those processes, the maturity of IE itself and the IE rendering engine, the compatibility with Internet sites, the compatibility with corporate applications – many of which use custom ActiveX controls that wouldn’t run in Firefox in the first place.” You’re right, Gary, by jumping ship, we leave behind the headaches of IE’s security and lack thereof, SP2 not withstanding. SP2 doesn’t fix everything that can be fixed by moving to Firefox. And on top of being safer, I still get more features than IE, equal to better performance, and the knowledge that I’m not giving OS level priviledges to any page I may visit. Not having ActiveX isn’t a drawback.

The_Decryptor had this to say,

"We’re committed to that, and we get criticized for it on some dimensions. They say "You’re not innovating as rapidly," Well that’s true, but when you have actual customers who rely on your software you have those tradeoffs and we’re very diligent on how we make those tradeoffs."

I interpret this different as admission that further development on IE is next to impossible. IE’s entire code base is geared toward backward-compatibility and error handling. IE applies complicated heuristics on everything it encounters, standard compliant or not. Given the complexity, the heuristics is bound to have bugs. Unfortunately, overtly aggressive error handling make browser bugs and features (error handling) impossible to differentiate. The result: massive layout code that cannot be improved without breaking some sites.

The only way out of this mass is to create a new engine (aka strict mode). Unfortunately, by stopping developming for so long, MS has created a whole new set of standards, or workaround practices that Webmasters employ to make sites work in IE’s (almost-)strict mode.

So, what’s next? Create a third-layer of layout code?

The architecture obstacle to tabbed browser attest to this. IE’s layout engine was designed as a layout engine and nothing else. It’s simply not extensible like Mozilla.

The "architectural reasons" why you adding tabs to IE is non-trivial are mostly related to toolbar extensibility. It would be relatively easy to add tabs if we were willing to break compatibility with existing third party toolbars. We’re not going to do that, so it’s more difficult.