Closed Bug 229877 (iecompatmanager) Opened 21 years ago Closed 13 years ago

implement Internet Explorer DOM features with a whitelist (site manager)

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: iamawalrus, Assigned: iamawalrus)

Details

Attachments

(1 file, 2 obsolete files)

patch
33.94 KB, patch
Details | Diff | Splinter Review 
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.
Attached patch patch (obsolete) — — Splinter Review 
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.
Whiteboard: DUPEME

*** This bug has been marked as a duplicate of 74201 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Attached patch patch (obsolete) — — Splinter Review 
fix an index typo in previous patch
Attachment #138265 - Attachment is obsolete: true
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.
Status: REOPENED → ASSIGNED
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
Alias: iecompatmanager
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
Summary: implement Internet Explorer DOM features with a manager → implement Internet Explorer DOM features with a whitelist (site manager)
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.
Attached patch patch — — Splinter Review 
The patch synced with trunk
Attachment #138514 - Attachment is obsolete: true
Comment on attachment 142296 [details] [diff] [review]
patch

seeking review
Attachment #142296 - Flags: review?(jst)
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.
Attachment #142296 - Flags: review?(jst)
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.

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.
Blocks: 240501
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?
No longer blocks: 240501
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.
QA Contact: ian → general
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 13 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: