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.
Ouch. What does Mozilla do about this?
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.
we should trigger IE's behaviour at least if the UA is set to UA.
Created attachment 9035 [details] Testcase or this bug with variants
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...
Created attachment 9036 [details] Testcase for this bug with variants (correct version)
I am against breaking a standard-defined behavior (DOM's getElementById) in order to emulate broken IE.
We could do it only in quirks mode.
*** Bug 94909 has been marked as a duplicate of this bug. ***
#94909 has it in the wild. With an XHTML strict DTD, no less.
This is really ugly (what are they smoking at Microsoft?) but ok, with a UA set to IE, why not.
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.
*** Bug 117098 has been marked as a duplicate of this bug. ***
@FiNeX: please don't change the version, when it is good like in this case...
> ------- 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 :)
> 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
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.