[thelist] BUG: Broken Value Attribute for BUTTON Element in IE5+
Graham Leggett
minfrin at sharp.fm
Mon May 3 10:30:56 CDT 2004
Ken Schaefer wrote:
> : - 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).
The user agent string is "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.0; .NET CLR 1.1.4322)". This is IE v6 on Win2k. IE v6 on XP shows same
problem.
The doctype is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
The form is like this:
<form name="accountingBordereauPremiumForm" method="post"
action="/patricia/accounting/bordereaupremium.do">
<button type="submit" name="method" value="downloadpdf"
class="wide"><div class="wide">Get Pdf</div></button>
<button type="submit" name="method" value="downloadhtml"
class="wide"><div class="wide">Get Html</div></button>
</form>
The purpose of the DIV tags is to apply a "look and feel" to the button
using stylesheets, while the text of the button is specified. Works
great in Mozilla and IE, except for the submit problem in IE.
> 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.
Currently what's working against me is that I am based in ZA, and the
local M$ support operation is hopeless at best (long history of problems
getting any kind of help out of them). This is why I was looking for a
web or email based forum allowing me to bypass them and get hold of
people who are actually interested in the problem.
> 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.
This is good news.
> : 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.
I have a very good understanding of the scale of the operations, what I
don't understand is how they can possibly operate without an efficient
means of getting customer problem data fed back to developers. Yes, it
is a difficult job to manage this on a large scale, but to not have such
a system is cause for disaster.
> 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.
A "good" programmer or "bad" programmer is not going to make a
difference to the project if the support systems in that project are
themselves broken, as I believe them to be.
It's good to hear that there is a test suite (the link you posted
implied there was no test suite), however a test suite is only effective
if the test is run at build time - not after the fact in some lab
somewhere. By that point if a test fails it's too late. Any test failure
must be found as soon as possible after the test breaks, preferably
before the code is checked into the source repository. Then the
programmer can take immediate action. If this doesn't happen, you get
bugs that multiply.
> : 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...
On the contrary, I have significant experience in large projects - and
have significant experience in why they don't work.
And the bigger the project, the bigger the need for project discipline.
Programmers with a "who cares" attitude are a liability.
> What if you have hundreds, or even thousands of bugs?
Then you bite the bullet, realise the code is a liability and not worth
fixing, you throw it away and you build it again.
On large software projects it is often difficult to convince people to
make the decision to cut one's losses, chalk the experience up to "that
was attempt 1.0, lets move on to attempt v2.0", and get a better
iteration out the door.
There is a point reached where the weight of the bugs in code is so
great that any further development of that code is impossible. At this
point it's less money and less time to rewrite. The trick is identifying
this point in time.
> 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]
This is where the importance of fixing "broken windows" comes in. If
there is a bug in a component, that bug must be fixed there and then. If
the programmer instead works round the bug, what he has done in the
process is create an extra bug - which will only surface when the
original bug is fixed.
None of these concepts are new. They are all principles of ISO9000
quality management that was taught to us at university way back when. It
always amazes me that these concepts are still not practiced by software
teams, and it amazes me even further that the continued failure of
software quality is not addressed properly.
> 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.
Our most succesful experience with shipping projects on time was when we
applied extreme programming principles to the project. Suddenly
development was done on time, under budget, and what that means to the
project manager is simply "the code ships on time".
The key thing was pair programming - we found that the second person in
the pair would not allow the first person to get away with sloppy short
cuts. If the cause of a problem was a third developer in the team, two
people coming down on them was a lot more effective than one.
> 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.
It's not about making mistakes, it's about catching mistakes. Usually
people with limitless budgets on money and time have no incentive to
catch the mistakes, so bugs multiply. I believe this is why Microsoft
ships buggy code - because the mistakes their developers make are not
trapped and fixed in time. Work on a project with higher stakes, such as
"if this code doesn't work, our client's business does not function, we
lose the contract or our client's business fails", and suddenly the
approach to project discipline takes on a whole new meaning.
> [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
When the above is true, it is time to throw away the code and start again.
Regards,
Graham
--
More information about the thelist
mailing list