[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