Bug 79897 - [testcase] document.getElementById() bug compatibility with Internet Exploder
Summary: [testcase] document.getElementById() bug compatibility with Internet Exploder
Status: RESOLVED INTENTIONAL
Alias: None
Product: konqueror
Classification: Applications
Component: khtml ecma (show other bugs)
Version: 3.2.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 94909 117098 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-18 17:53 UTC by Alain Knaff
Modified: 2011-01-08 16:53 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Testcase or this bug with variants (1.24 KB, text/html)
2005-01-11 01:29 UTC, Roger Larsson
Details
Testcase for this bug with variants (correct version) (1.25 KB, text/html)
2005-01-11 01:41 UTC, Roger Larsson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alain Knaff 2004-04-18 17:53:07 UTC
Version:           3.2.1 (using KDE 3.2.1, SuSE)
Compiler:          gcc version 3.3.1 (SuSE Linux)
OS:          Linux (i686) release 2.6.4

Internet Exploder's implementation of document.getElementById() looks up elements by name if an element with a matching id cannot be found.

Example:

<form>
<input type="text" name="myname" id="myid"></input>
</form>

<script type="text/javascript" language="Javascript1.1">
  document.getElementById("myname").value="zozo";
</script>

In IE, this sets the form field to "zozo", even though myname matches the name, rather than the id.

Konqueror is much more strict here, and fails with a null pointer error.

Unfortunately, there are pages out there (for example on https://ebanking.bgl.lu/reb0201/WebBanking/ihb/transfers/express/TransfersExpress.do) which do contain such errors (confusion between id and name, in this case currency and amount_currency), and which render fine in IE. Needless to say, BGL's customer support, which are Giants in stubbornness and wear the Crown of Microsoft-friendliness, won't budge on the issue.
Comment 1 David Faure 2004-09-24 16:43:34 UTC
Ouch.
What does Mozilla do about this?
Comment 2 Koos Vriezen 2004-09-25 13:14:56 UTC
Mozilla also gives an error. Might be more convincing to metion firefox (because of the IE alert) to the bank (or else asked them why a _bank_ doesn't care about security flaws).

Of topic, if javascript were truely functional, one could think of alternative paths in case of errors, which is unfortunately not the case.
Comment 3 Stephan Kulow 2004-09-27 15:52:20 UTC
we should trigger IE's behaviour at least if the UA is set to UA.
Comment 4 Roger Larsson 2005-01-11 01:29:46 UTC
Created attachment 9035 [details]
Testcase or this bug with variants
Comment 5 Roger Larsson 2005-01-11 01:32:05 UTC
I have run into this too on a configuration page for a recent firmware to a
TOPCOM Skyr@cer Pro WBR 654. (I thought the reason was that getElementById did
not recurse into forms). But reading this bug report I now know what the problem really is:

This is from its form (note no id="ip" field)
              <input type="text" name="ip" size="16" maxlength="15" value="192.168.1.1" onchange="changeIp()">

Later it calls getElementById("ip") [in an internal function called get_by_id]

Made a testcase with original and my problem.

Note: this does not work in Mozilla 1.7.2 either...
Comment 6 Roger Larsson 2005-01-11 01:41:23 UTC
Created attachment 9036 [details]
Testcase for this bug with variants (correct version)
Comment 7 David Faure 2005-01-11 21:20:15 UTC
I am against breaking a standard-defined behavior (DOM's getElementById) in order to emulate broken IE.

Comment 8 Allan Sandfeld 2005-01-12 00:06:46 UTC
We could do it only in quirks mode.
Comment 9 Maksim Orlovich 2005-01-12 00:15:08 UTC
*** Bug 94909 has been marked as a duplicate of this bug. ***
Comment 10 Maksim Orlovich 2005-01-12 00:17:31 UTC
#94909 has it in the wild. With an XHTML strict DTD, no less.
Comment 11 David Faure 2005-01-12 00:21:46 UTC
This is really ugly (what are they smoking at Microsoft?) but ok, with a UA set to IE, why not.
Comment 12 Allan Sandfeld 2005-01-12 00:37:14 UTC
This is exactly the same as what we already do in HTMLCollectionImpl::namedItem(), and I don't think it is the only place we use names as a fallback for ID. 
Comment 13 Maksim Orlovich 2005-11-26 18:11:56 UTC
*** Bug 117098 has been marked as a duplicate of this bug. ***
Comment 14 Pino Toscano 2008-04-04 01:22:22 UTC
@FiNeX:
please don't change the version, when it is good like in this case...
Comment 15 FiNeX 2008-04-04 10:24:53 UTC
> ------- Additional Comments From pino kde org  2008-04-04 01:22 -------
>  FiNeX:
> please don't change the version, when it is good like in this case...


Ok :)
Comment 16 Gérard Talbot (no longer involved) 2010-03-30 06:13:31 UTC
> with a UA set to IE, why not.

One problem with such policy is that Microsoft IE Team has fixed a good set of DOM bugs in IE8 (including that getElementById() bug) and now fixes bugs many more DOM (Core, HTML, Events, Traversal, Range) bugs in IE9.

So, imitating/mimicking the getElementById bug in IE7 may not be wise if more and more people are upgrading to IE8 (that is the case) and if web authors are adjusting accordingly (that is to expect). Right now, overall stats say that IE8 is the most popular IE version in use.

Imitating/mimicking the IE bugs is definitely not recommendable if IE8 (and eventually IE9) has fixed such bugs.

regards, Gérard
Comment 17 Samuel Brack 2011-01-08 16:53:17 UTC
I recommend closing this as wontfix basically because of the reasons listed by Gérard in comment 16. Imitating bugs of IE that are being closed in the recent version is not a good idea any more.