[thelist] BUG: Broken Value Attribute for BUTTON Element in IE5+

[Ken Schaefer]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Graham Leggett" <minfrin at sharp.fm>
Subject: Re: [thelist] BUG: Broken Value Attribute for BUTTON Element in
IE5+


: 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".
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Please post some sample HTML (including DOCTYPE), and some information about
your setup (e.g. IE version).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: > 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?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PSS - Product Support Services.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: > 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. :(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are lots of ways to "report" bugs. As mentioned, if currently have
channels into Microsoft (eg as a partner, or MSDN subscriber, you will have
information about how best to contact Microsoft). If you have no contact
with Microsoft, your best bet might be to call PSS. That that you have a bug
in IE, and you want to resolve it. Best to call on the phone (not to use
their online help). You will not be charged if there is a real bug in MS
product.

There is a tool currently in beta that will be placed into MSDN to allow
developers to report bugs. It will be tied to the internal bug tracking
databases that Microsft has so that you can get some idea of what is
happening with the bug.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: > 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is because you don't understand the scale of Microsoft's operations.
They literally get millions of reports across a multitude of products every
year. There is no "submit a bug to Microsoft" page at the moment because
there isn't the backend infrastructure to:
a) receive these bugs
b) categorise and route them to the appropriate people
c) people to examine multitude of mostly erroneous reports
d) report back to the original submitters (this is important - so that
people can see that something is happening to their report, and it's not
disappearing into a blackhole someplace).

There are plenty of people/ways to submit bugs:
a) there are official alpha/beta programs for many, many products.
Participants get access to newsgroups, or online forums, lists, to report
bugs.Some of these programs are open, some are closed.
b) Certified Partners, MCSEs/MCSDs etc get access to groups, product teams
etc.
c) MVPs get access to some internal information
d) MSDN Subscribers get managed newsgroups
e) You can hang-out where the development teams (or relevant support people)
hang out - e.g. MS newsgroups, or check their blogs etc
f) Contact someone who knows the relevant person at Microsoft, and have them
pass on your concerns. Posting here is likely to help because most people
here are not pro-Microsoft, and thus do not spend their time at Microsoft
conferences/training events, watch webcasts etc, so they don't know anyone
at Microsoft (or anyone that does).

I am NOT an IE expert, but if we can determine what causes the problem, the
extent of the problem etc, I may be able to get someone interested in the
issue. However, all you may get is a hotfix, unless another SP comes out for
IE before Longhorn.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:  > 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you think that, then you really don't know much about Microsoft. In the
past year, I've seen two test labs that Microsoft runs. One is for the
ASP.NET team, and one is for the IIS team. Imagine a room packed with
500-600 machines. This labs runs several thousand test cases (in the ASP.NET
team's case - 7,000 tests) a day. Every week, they run a 22,000 test case
suite against the last checked in build.

Microsoft also hires some of the best programmers in the business.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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".
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That opinion indicates to me that you don't know much about managing large
commercial software projects...

What if you have hundreds, or even thousands of bugs? And the bugs are not
even in the software that you have written (but in some component you are
using)? And that fixing a bug could potentially result in 10 more bugs? [1]
There comes a point when you have to ship the product, and as you approach
that deadline you need to evaluate the risks involved in fixing an issue. Is
the issue severe enough that we can risk creating more issues by attempting
to fix it.

And if you only have enough bugs that one person is picking up the weekly
bar bill, then you don't have enough lines of code.

Lastly, there are some things that even programmers do not know about.
Here's a question: how many different types of the letter "i" (as in, after
h, and before j in the Roman alphabet) are there in Turkish? Because someone
didn't know about this issue, VS.NET was delayed in shipping. Not everything
has to do with "lazy programming" - sometimes people don't even know about
certain things. Additionally, certain assumptions need to be made when
writing code (consider the Y2K issue - that was certainly an infamous
assumption made by many, many programmers). Someone may have made an
assumption about how many pages there would be in a document. Perhaps they
assumed no one would have more than an unsigned long (approx 4 billion
pages). So, if someone *manually* types in page number 5,000,000,000, there
might be an overflow (and it'll revert to 1,000,000,000), or maybe the
number might truncated when you get to 10,000,000,000 because there isn't
enough space to display it. That has nothing to do with "lazy programming" -
you can't cater for every possible situation under the sun. Even military
contractors, and government space agencies, with almost limitless budgets,
unlimited time, and custom, purpose built applications that only run a few
thousand lines of code occaisionally make mistakes.

Cheers
Ken

[1] The programmer's song
99 little bugs in the code,
99 bugs in the code,
Fix one bug, compile it again,
101 little bugs in the code