As we all know, mozilla does not implement some of the MS IE DHTML specific features. The bug 154589 has a patch that provide document.all and some other features. However, it does not provide a good strategy to apply them so that it will break if (document.all) { } else { } , which is not acceptable. My proposal is to add a manager to apply the w3c incompatible features. The manager maintains a list. Document.all is defined only for the urls in this list. For example, when a site has been spotted using the IE specifiec DTHML like document.all and can not work correctly with Mozilla, we can add it to the list and make it work. By this way, we won't break any good site but give the users a chance to view some incompatible site without the obligation to change to IE. It is even good for the evangelism. It can educate people that the sites can not work with mozilla is because they are w3c incompatible. Only not to implement them mostly makes people to think it is the fault of mozilla. Furthermore, we can even get some lists of the incompatible sites. It is an active way to push the evangelism.

This patch is based on bug 154589 but also provide a manager in the menu Tool->W3C Compatible Manager. You can use it to turn on/off the defination of document.all for the special url.

I'm quite sure this is a DUPLICATE of a bug marked as WONTFIX.

*** This bug has been marked as a duplicate of 74201 ***

This is not a dupe of bug 74201. Bug 74201 only request the implemention of document.all, which will break a lot of site that use document.all to identify the browser type. And that is the reason that bug has been marked as WONTFIX. This bug does not request implementing doucment.all mindlessly and won't break any w3c compatible site. Furthermore, there's a patch here.

fix an index typo in previous patch

With this fix, Mozilla might actually provide users of non-Windows platforms with the ability to access the whole web, not just to a subset of conforming websites. You got my vote. Prog.

You probably have a typo in the following comment: > +textW3CIncompat=Sites which contains W3C incompatible contends Shouldn't that be contents (or content)? Prog.

Prog, Thanks for your vote and comment! I will fix the typo.

Many sites that use document.all use other IEisms, for example quite a few sites in china doing fooElm.left = rather than fooElm.style.left =. This is a partial solution only to add doc.all and outerHTML. Robin - so the user (or vendor) has to specify what sites go into this mode, right?

Doron, You are right. User has to specify what sites go into this mode. It is a bit like the image manager and popup manager. Document.all will not be defined unless the user specifies the site is not W3C compatible by adding it to a black list :)

Most IE-only scripts uses document.NAME for everything, and so: document.getElementById('foo') -> document.foo document.forms['name'].elements['name2'] -> document.name.name2 JS scripts for animating -> behaviours -> filters and others... This is a swamp and this patch makes a step into it. As Doron mentioned in Comment #9 this patch won't help 95% of IE-only JS code, but will produce inifitiy number of bugs in bugzilla about bad work of manager. I'm stronly against "trying" in application. It _can_ do something or it cannot. If some code _can_ block popups (or 9x% of them), it's ok, but if such code can fix about 5-10% of scripts (those who ARE W3C ready, but with bad browser recognision) it's useless - and it'll add next manager to the list. Not good for clear UI.

Zbigniew, I understand what you mean. The patch does need improvement. Can we do it step by step as long as we lose and break nothing we have already had? Be 100% compatible with IE is not my goal. We can evaluate what should be in and what not depends on the severity. BTW, Document.NAME has been in the patch. If any bug will be reported to the manager, it mostly had already been reported to the browser or will be no matter if the manager exists, especially when the adoption of mozilla increases in normal users. And you seldom get any chance to educate the end users that these bugs are due to W3C incompatible. But this manager will. When some people report a bug to the manager, at least they know the reason, know whose fault it is and know the bug should be an RFE. I don't like *trying* in application as well as you. But when the *trying* is inevitable, what would you like the users to try? IE or a mode in mozilla?

As an end user, I appreciate this bug. If I do find sites that don't work in Mozilla, I would rather try a mode in Mozilla first, and then use IE if it still doesn't work. Either case it does not really matter if the mode in Mozilla is perfect or not. If it can make me view one more site in Moz that would normally require me to switch to IE, then it is already worth it.

Don't forget that what Mozilla supports implements what web pages do. If web authors think we support these IE-only features, then they become OK to use for more people, which makes it harder for anyone else implementing a web user agent and pushes the web closer to vendor lock-in.

s/implements/influences/ s/for more people/for more authors/

To Robin Lu: can you please make me an xpi extension that would add this manager? I would love to download this... :)

dbaron, I want the mozilla to influence people too, even more, but not in the defensive way. This manager is like a ruler to measure the website. We have that ruler in our mind. Now we give it to the end users. When they know what is right and what is wrong, the influence would be many more times than us. It is not an honour to be in the "W3C Incompatible List". What would influence the authors more? Less than 10% browsers can not render their pages or more and more people know they are not qualified? Bamm, An xpi extension is not enough. I will find a place to upload my private build of mozilla for linux and let you know as soon as possible.

Robin: ok, comparing to bug 154589 this one is smarter, but how many web-authors will say "why should I change my code if You can use feature in Your Mozilla to make it work like standard IE" ? I'm afraid many. (yesterday's anwser on evangelization mail): "We strongly suggest You change Your browser to IE, because Mozilla browser is not best tool in fact of lack compatiblity with many standards that IE supports." I'm afraid that this will sacrifice standard promotion in the name of Mozilla's promotion. If we would invent how to make sure nobody will think about it as "Mozilla's experimental standard compilance - at least" then it'll really help without side effect i think

experimental builds can be found at: http://eri.sun.com.cn/Download/moz/mozilla-i686-pc-linux-rh9.tar.gz http://eri.sun.com.cn/Download/moz/mozilla-sparc-sun-solaris2.8.tar.gz

Can you give an example of a site you have found where this fix actually makes the entire site? Is there really a site that only uses the document.all IEism and everything else is standards compliant? I like the idea, but I think this is the tip of the iceberg....

I tested all links from www.osiolki.net (Polish site made by Opera/Mozilla supporters to list all non-W3C sites and try to fix their problems) - i wasn't able to fix any of this site with this manager. Still same problems - window.event, myDiv.innerHTML, window._content, some sites founded me with Server-side, and profiled NS4 code.

I think time should be spent on fixing all Mozilla bugs. When all bugs are gone, and I can write valid code that looks fine in Mozilla - specially in RTL - then go and do whatever you like. To be specific, fix the RTL list bug. Failing to render a list in RTL page is really basic thing. Then fix the slow editing of Hebrew text on Mac OS X. Today I tried to type few letters in a big wiki page, and I had to wait more then 30 seconds after each character looking at the spinning beach ball.

> It can educate people that the sites can not work with mozilla is because they are w3c incompatible. How on earth can it possibly educate people that sites can't work with Mozilla... if you make them work? > It is an active way to push the evangelism. We have seen in the past from an evangelism standpoint that once you make it work, sites have no motivation or practical reason to change at all. This in fact would be a major deterrent to the evangelism campaign against document.all.

For more W3C incompatible features, welcome to report new bugs that depend on this bug.

I could, however, see this as quite an asset to DOM Inspector.

M.Kaply wrote, in comment #20: > Is there really a site that only uses the document.all IEism and everything > else is standards compliant? There are several sites that Mozilla can't currently handle due to document.all, but are perfectly usable in Opera 7.50 - citypay.co.il, mybills.co.il and homeless.co.il are typical examples (see Bug 221311, Bug 208676 and Bug 213804). Most end-users will do without full IE compatibility as long as the number of websites that remain accessible and usable is within reason. Fixing this bug will bring us into that realm, but we're not there yet. Prog.

Here's a suggestion on how to communicate with the regular user: I use a Firebird extension called "JavaScript Console Status" that displays a red "X" in the status bar whenever a JS error occurs in a page. Clicking it opens the JS Console. It's rather unobtrusive. Something similar that would open the "Proprietary J(ava)Script Manager" instead would be an easy and clean way to convey to the normal user that her/his problem with the functionality in a page might be solvable.

I'd like to see more evidence than the three sites given in comment 26, for the claim that supporting document.all (and maybe a few more IE quirks) gains us a number of working sites that leaves the non-working IE-only site tally "within reason". Maybe we can even agree on what number or fraction that phrase means! I meddled with the Summary to make it more precise; I left the "manager" keyword in it in case people use that along with the alias. If we used the whitelist sparingly, only for those sites for which there is (a) no hope of reform; (b) easily achieved compatibility, then I personally would consider taking the patch into the default build. Other drivers@mozilla.org should weigh in. /be

I think we have three separate problems here. First is how to implement it, not to make it destructive for w3c standards. Second, is there any real reason to work on it. Third, how this can influence standard compatibility on web pages. I think that first problem is easies one. I really like laszo's idea from Comment #27 about some box in status bar. Second is not so easy. Because empty words about "whole world IE-only compilant" doesn't match with mine experiences (and not only mine). The number of web pages that are IE-only is falling down everyday. And third is the most problematic one. We never ever will be able to explain to "big world" that it's only option. We will be judged as "IE compilant" and we will be cursed by this forever. Also nobody will care that "it has to be turned on" - bas webdesigners (and Microsoft itself) will reach one more reason for their way.

The patch synced with trunk

Comment on attachment 142296 [details] [diff] [review] patch seeking review

IMHO we should not take this without: (a) a _significant_ study into the effects of the patch (b) a specification stating exactly what it is we implement and how (c) a test suite testing that we implement what our spec says I am generally against any modal standards support, as it makes testing orders of magnitude harder, makes the code harder to maintain, and makes us less predictable for authors. If we were to implement this, it would IMHO have to be on all pages, not just a subset of those that need it. I am generally against any hard-coding of specific sites in our behaviour. Doing so makes evangelism very hard ("just add us to the list!"), raises concerns of complaints from sites that do not want to be libelled ("remove us from the list or we'll sue you for saying we aren't standards compliant!"), and makes testing and authoring harder. I am generally against any new UI for esoteric features such as this. Users don't have the first clue as to what this kind of thing is and they should not need to ever know. See also comment 14 and comment 23. In conclusion I recommend WONTFIX.

Re: comment 29: "The number of web pages that are IE-only is falling down everyday." If that's really true, then we should not mitigate that trend by supporting IE-only features. But is it true? Comment 32's "(a) a _significant_ study into the effects of the patch" is necessary for the patch to move forward. Who will do this study? /be

Comment on attachment 142296 [details] [diff] [review] patch There's a lot of questions that need to be answered here before it's worth reviewing this, especially comment 28, and I must say that I agree with everything Ian says in comment 32. In short, I'm generally against this, I think I'd rather see Mozilla get a well-documented document.all property than one that's conditionally turned on or off on a per site basis.

The sites that Mozilla can't handle but work with the patch: mail.263.net 263 is one of the the biggest ISP in Beijing, China. It's their mail service website. www.5460.net one of the most famours alumnus site in China www.dangdang.com China amazon www.tianyaclub.com a famous Chines Forum ...

Can you explain (bearing in mind I don't read Chinese) which parts of those sites are broken, and what parts of the code it is that makes them break? Have those sites been evangelised?

(In reply to comment #32) > I am generally against any hard-coding of specific sites in our behaviour. It's not hard-coding of specific sites. The list is maintainable by the users. > or we'll sue you for saying we aren't standards compliant!"), If so, I think image blocker may get more chance to be sued. > I am generally against any new UI for esoteric features such as this. It could be an esoteri feature. But it give the user a chance to just swith a status in mozilla instead of switch to IE, which is more ugly and unacceptible. And it won't affect the user in any way if the sites work just fine. > Users don't have the first clue as to what this kind of thing is and they should not need to ever know. Do you mean the evangelism work should only be done to the website developers? Then I think you might just miss the real power that pushes the web world.

> Do you mean the evangelism work should only be done to the website developers? > Then I think you might just miss the real power that pushes the web world. This makes no sense. Most end users have no clue about what is web standard and what is not. Trying to get them to learn is like trying to teach a pig to sing -- it does you no good and it annoys the pig. The big problem with any emulation of document.all, whether on a site whitelisted basis or for all sites, is that it means no site webmaster ever hears complaints or otherwise feels pain about using a non-standard IE feature. It's true that by making end users feel pain, enough that some of them might complain to the webmaster, we hurt our reputation with many end users who cannot tell what's wrong, and simply blame Mozilla. That's the rub, and that's why I prefer a site whitelist approach. If we just make document.all work across the board, other sites than those we'd whitelist will never be evangelised, that otherwise would have been. I must have misread this bug, tho -- a whitelist should be maintained by an open evangelism group, and shared among all instances of Mozilla, or at least all that come from a particula distributor associated with the evangelism group. It's crazy to make end-users hand-craft their own personal whitelists. What's the point? There isn't even a way to collect and collate all such lists. jst: if we allow document.all to work for all sites, many will then want document.id or even window.id to work, no? We would be on the slippery slope for all offending sites, not just for those that are hopelessly immune to evangelism. Yeah, I'm arguing here that some such sites can be identified up front. At least the whitelist could evolve over time, even if it wrongly listed a site that *could* have been evangelised, provided some evangelist tried in spite of the whitelist entry to change the site's webmaster's mind. /be

> if we allow document.all to work for all sites, many will then want > document.id or even window.id to work, no? Brendan, I think there is some confusion about Robin's proposal. When I looked over this patch a while back, it looked to me like it was doing far more than just document.all[]. I read comment 1 to mean that only the document.all parts are allowed to be switched off. This is what the patch seemed to do too. For example, I recollect it unconditionally implemented outerHTML. It also did some classinfo foo that sure looked to me like an attempt at window.id and document.id support. I suspect, most of the sites that work because of this patch, are not just dependant on document.all[]. I must add that I did not read too carefully, and that I am not exactly a classinfo guru. Robin, please do correct me if I am misreading your patch and proposal. I second what Hixie said in comment 32. If this is going to be done, we need to start with a spec that more precisely defines this "mode", and some tests to go along with it.

Harshal, You are right about the patch. The patch is based on the one for bug 154589. It implements document.all, outHTML and document.id. The main concern in that bug is that document.all will cause regression to the sites which use it to identify the browser type. So, I made a manager for document.all to make it work conditionaly. If you think the strategy is acceptible, we can work together to determine which should be controled by the manager and which shouldn't. Also, if the community wants to "start with a spec that more precisely defines this "mode", and some tests to go along with it", I can't be more happy. Brendan, My thought on the whitelist is different from you. The control of the list is in the users. The user scenario is: the user meets a site that can't work, then he/she tries to the incompatible mode for the site. Actually, It is an inevitable trying. Currently, the user will try IE and the trying doesn't give them the truth. Why don't we give them a chance to try with the truth? You can see it as a bonus to let the users know W3C in the same time. It's not like teaching pig to sing.

Suggestion for how to balance the evangelism aspect with the "make it work, dammit" aspect: Implement a customized whitelist, as discussed above. When a webpage tries to use (say) document.all, open an HTML popup or dialog that says the following: The web page has attempted to use browser functionality which violates web standards, thus causing the following error: document.all has no properties * For more information see <a href="...">here</a>. <!-- link to explanation about importance of standards --> * To see a detailed explanation which you can send to the web site owner, look here <a href="...">here</a>. <!-- shows the error info along with some brief generic evangelism text and tells the user to paste it into a message to the webmaster. --> * [Enable] the use of standard-violating extensions for this web site. <!-- whitelist --> * [Ignore] this error for this site. I'll leave it to the keener to rearrange this into a sane and guideline-conforming UI, but you get the idea.

> The web page has attempted to use browser functionality which that is not a good idea, considering code like if (document.all) { ... } else if (document.getElementById) { ... } which would trigger such a warning.

> that is not a good idea, considering code like > if (document.all) { ... } > else if (document.getElementById) { ... } > which would trigger such a warning. Special-case that. Trigger the evangelism/whitelist popup only if a field of a (non-overriden) document.all is accessed.

Guys, guys, guys. Get real. We're not adding UI for something like this. Users should never be exposed to the underlying Web technologies. As far as the user is concerned, things should just work. Now, if we want to implement document.all or anything else, we need a spec for it first. Then we could get this spec into a W3C spec, and we could ensure interoperability among the modern browsers. So if you want this: Write a spec. Write a test suite for the spec. ...then come back to this bug. Without a spec and something to test its implementations, there is no real point even discussing this.

Hixie, do you happen to know what spec does Opera rely on in its implementation of document.all? Prog.

It doesn't have one, which is one of the reasons some people here have suggested that future versions of Opera should remove the document.all support altogether.

(In reply to comment #43) > Special-case that. Trigger the evangelism/whitelist popup only if a field of a > (non-overriden) document.all is accessed. Uh, you want document.all be undefined, but document.all["foo"] to invoke some code? I don't know spidermonkey, but this sounds to me like it would require ugly hacks.

Reply to comment #47: Maybe this will work? http://bugzilla.mozilla.org/show_bug.cgi?id=154589#c62

Ian, I have to say that that would _greatly_ increase the chance of evangelism succeeding... I've often been told by web site owners "but it works in Opera and Safari! Why not in Mozilla?"

Re: comment 47 and comment 48: ECMA-262 specifies that object converts only to boolean true, never to false. We would have to hack SpiderMonkey to do anything that overloads false and an array on document.all, depending on context. I don't think such overloading is a good idea, in any event. I am still against enabling document.all support across the board. I would love to see Opera reverse itself, but I wonder whether "some people" in comment 46 is a set larger than {Hixie} ;-). How do we get KTHML/Safari to reverse course? I agree we don't want any UI in the user's face. If you are doing a hardcore geek evangelist Mozilla distribution, then sure, knock yourself out. Not in the main products. /be

As far as I know, safari doesn't have document.all, though khtml does. At least hyatt said so. :) The patch seems to be China-oriented, as I wrote an XBL back at Netscape that added all of these IEisms for the china effort back then, and it did fix a lot of stuff.

If it's really China-oriented, than meaby make extension instead pushing it to main source? Then any Chinese lozalization would be able to add this by default, and evangelization wouldn't suffer so much.

(In reply to comment #52) > If it's really China-oriented, than meaby make extension instead pushing it to > main source? It's *not* only China-oriented. There are currently 14 open evangelism bugs in bugzilla for Israeli websites with ducument.all: http://snipurl.com/il_document_all A trivial note: the population of China is 200 times bigger than Israel's... Prog.

(In reply to comment #52) > If it's really China-oriented, than meaby make extension instead pushing it to > main source? I don't think that's possible.

Re: http://bugzilla.mozilla.org/show_bug.cgi?id=229877#c53, what else besides document.all do those sites depend on in the way of IE quirks and extensions? /be

Shosh, perhaps you can answer comment 55 and provide a general analysis on what is currently required (besides document.all) to properly render the sites in http://snipurl.com/il_document_all Prog.

I'm voting for this bug-I want mozilla to be as usable as possible even for the many websites that won't even consider the possibility that there's a browser besides IE.

For those who care, bug 248549 might be of interest.

Robin, can you update the patch against the trunk?

I surely appreciate the work that is done here but I really hope that this bug will be marked as WONTFIX. If it was possible to vote against a bug I'd surely vote against this one. Such things should be made as an extension IMHO. Even using a whitelist system I don't think it is worth adding all this code into the browser; Mozilla is all about standards. It would be really bad to start seeing some site saying: "This site is compatible with Microsoft Exporer only. It seems you are using a mozilla browser; you can enter this site if you add it to your IE Dom whitelist" Let put some pressure on webdevelopers that are not standards aware (and don't move this pressure on mozilla developers instead). With such features they'll never learn. If it simply doesn't work in non-ie broswers I don't think they will let 25% of the webusers to not enter their sites. If it works also in mozilla browsers thanks to the whitelist feature, why would webdeveloper bother to rework their site ?

(In reply to comment #60) > never learn. If it simply doesn't work in non-ie broswers I don't think they > will let 25% of the webusers to not enter their sites. If it works also in Well, that's the chicken. The egg, of course, is to get 25% of browser marketshare into non-IE browsers, at which point this entire issue becomes virtually moot.

Just a note in regards to the very high "IE" percentages reported by websites. It's worth noting the widely available ability to change the ID your browser reports. We don't know how many of those "IE" users are actually using Konqueror or Mozilla, impersonating IE. Since that suffices for a large number of broken websites (and is standard advice often given out), it may be quite common.

IE9 Standards Mode is more like Gecko, Presto and WebKit. Presto has shifted over time to implement less IE stuff in order to be more compatible with the Web. WebKit prefers to reverse engineer Gecko over Trident. I think it's time to WONTFIX.

I agree, esp. since we certainly have >25% non-IE market share now. ;)

Indeed.