[thelist] BUG: Broken Value Attribute for BUTTON Element in IE5+
Graham Leggett
minfrin at sharp.fm
Sun May 2 13:26:00 CDT 2004
Ken Schaefer wrote:
> a) the bug needs to be reproduceable. It also needs to be isolated (so you
> know the exact conditions under which is happens). It would help if you
> could post sample HTML, or a webpage, where you see this behaviour.
The sample webpage is part of a web application, so is not publically
accessible unfortunately. The problem is however reproduceable:
If a <BUTTON> tag is used, it operates correctly according to HTML
v4.01. If two or more <BUTTON> tags are used, and these are given the
same name (for example <BUTTON name="method" value="submit">Submit
Order</BUTTON> then <BUTTON name="method" value="cancel">Cancel
Order</BUTTON>) then suddenly the following happens:
- The button submits _both_ buttons when either is pressed, behaving
like type="button" instead of type="submit", which is the default in
HTML v4.01. Specifically setting type="submit" in button tag makes no
difference.
- Both submissions submit the content of the tag, and not the value as
specified by HTML v4.01. In other words, the webserver receives
"method=Submit%20Order&method=Cancel%20Order" instead of "method=submit".
> b) reporting it will depend on what channels you have access to (e.g. if you
> are a partner, you can use the partner newsgroups, if you are MSDN
> subscriber, use the MSDN managed groups. If you have nothing, try calling
> PSS)
PPS?
> c) It is unlikely that you'll get another other than a hotfix for this
> issue. It may be rolled into the next IE service pack, if there is one
> before Longhorn.
At the moment no such thing is likely to happen, unless someone can
point out to me the thing that I am missing - the mechanism Microsoft
uses to receive info about bugs. I have trawled their site for ages, and
the only mention of the word "bug" you'll find on their site is in their
knowledge base. :(
Anybody know?
> Not all are actually bugs in Microsoft products. Those that are need
> to be prioritised (so, security related bugs are always fixed, bugs that
> impact a large customer base are fixed, bugs that do not have work arounds
> are fixed etc).
Whether or not it gets fixed is up to them, all I want to do is get the
bug to them, in the hope that it receives due attention. This, I find is
difficult to do.
> So, some things just aren't fixed because of regression issues
> (instead, they'll be rolled forward into new versions of the product,
> eg see for a discussion of the problems with fixing bugs:
> http://weblogs.asp.net/chris_pratley/archive/2004/02/05/67871.aspx)
Reading through this, I now understand better why the software mentioned
never seems to work properly. There are two things missing: a test
suite, and programmer discipline. The test suite would have trapped the
bug I reported above - the test suite would have tested the browser
against HTML v4.01, and the resultant failure would have picked up the bug.
And the programmer disclipline: the is mention in the article of small
things that "have little to no customer impact, and that only a very
persistent customer would run into (like, typing 1,000,000,000,000,000
into the footnote number control causes the footnote format to look
incorrect - who cares?)".
The key word here is "who cares?". A programmer with the attitude that
the details are not important, is the programmer responsible for the
obscure hard to find bug that irritates the hell out of the end user
(otherwise known as "the customer", or "the person ultimately
responsible for financing the developer's salary").
We have a rule on our development teams: if a "broken window" is found,
in other words a little glitch or small oversight, it gets fixed there
and then, and the person responsible for checking in the "broken window"
is usually responsible for the bar bill that week, or at the very least
a clip around the ear by the person who fixed the broken window. As soon
as it becomes tolerable for small "who cares" glitches to exist in code,
they start to multiply as programmers say "I can be sloppy here too,
this code is such a mess anyway". And shortly after: the code becomes a
slum and needs to be rewritten.
Thanks for the link, it was very enlightening.
Regards,
Graham
--
More information about the thelist
mailing list