[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