16719 - Form Bugs causing lost OS and Component data in bug reports

Status: VERIFIED FIXED

(mozilla.org :: Miscellaneous, task, P3)

Description

[Sean Richardson]

I can't be sure, but I think that some of the bug reports may be losing
Component and OS data due to the problem identified in item 2 under
"Expected behavior" in the original entry in Bug 16152.

This problem, if it exists, will be hindering the engineering workflow
by depriving engineers of information that should have been captured
by enter_bug.cgi.

To be specific, in current win32 builds (at least, I'm guessing Linux
on PC at least as well, maybee ALL) of Mozilla, if a combobox cannot be
fully displayed on the screen, activating the combobox may change
the selected item in the combobox to the top (or other, yikes) item
regardless of what was previously selected (or prestuffed).

In practice this will happen up to a screen size of 1024 by 768
with the Win95 shell (or, presumably, fvwm95 in X) for at least
the OS combobox, if the scrollbar is not moved before the combobox
is activated.

I am seeing way too many "all" and "other" for OS, especially from Linux
bug reports, and "ActiveX Wrapper" for component, when they are not
appropriate and, at least for OS, should have been something else,
based on enter_bug.cgi's field initialization.

Bug 16631 and Bug 16663 seem to show this problem, among others.

The only way I can think of to test this is to enter bug reports using
mozilla, intentionally activate comboboxes that are "too close" to the
bottom of the screen after the proper selection has been made, without
making a selection, and carefully observe what show_bug.cgi shows
to see if any of the comboboxes are showing the wrong item.

Needless to say, if this is really happening, somebody may want to
up the priority on bug 16152.

Comment 1

[Sean Richardson]

There is a much more likely cause for most of these badly filled enter_bug.cgi
SELECT elements: with M10, possibly earlier, and possibly later, the first (or
in some cases the last) OPTION value in a FORM SELECT element is always
initially selected, even if it should not be (no SELECTED attribute on
that OPTION). This was Bug 15841, FIXED, and VERIFIED 1999-10-18.

This shows up especially well viewing http://bugzilla.mozilla.org/query.cgi,
but it also affects http://bugzilla.mozilla.org/enter_bug.cgi?,
and the selected items there are the same ones that have been cropping up -
Component:ActiveX Wrapper, Platform:Other, OS:other - in naive bug reports.

Current builds for at least the last several days do not have this problem,
at least for Win32.

Evidently people have either not been seeing the message [e-mail]
has added to the end of the http://bugzilla.mozilla.org/enter_bug.cgi?
page about prestuffed fields, or have not been bothering to fix their forms
when they see the discrepancy.

Three possiblilites,

(A) As a workaround, I don't suppose HTML has an UNSELECTED attribute available
for SELECT OPTIONS? If it was applied to all the OPTIONS... but that would be
too easy! :-)
(Checked http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.6 - no luck)

(B) One way to try to hold down the number of these might be to move this
message (possibly reworded some to ask people to pay attention) above the
SELECT elements in the FORM where it might be seen and do some good, for the
duration that people are downloading and trying out M10
(i.e., until M11 comes out.)

(C) Another option, much more work, would be to require onchange or onclick
events for the SELECTS from M10 browsers before submission.

Okay, (A) was a joke, but (B) could probably be put into effect immediately.
(C) is probably too much work for too little gain, and may not be possible.

I suppose (B) is an RFE (Creating Bug report for RFE, Bug 16755).
The idea is to reduce the number of unuseable bug reports from first-time
bug reporters, and IMO, anything easy that can help here is worth trying.

Adding [e-mail] to Cc: list. Amending Summary Line.

Comment 2

[Sean Richardson]

Suggest checking for Bug 15841 Regression before public release of each
Milestone to avoid these problems with invalid data in bug reports.
This is a FIX for this bug, and would render RFE 16755 irrelevant as a
workaround for M11 and later releases.

Removing [e-mail] from Cc: list.

Comment 3

[Sean Richardson]

Moving to the newly-available and more cogent "Server Operations" Component.

Comment 4

[Mitchell Baker]

Reassigning to dmose, not sure if he's the correct person, but he's closer than I
am.

Comment 5

[Eric Pollmann]

See bug 17591 - this was just fixed or M12, but there may still be some problems
in M11.  :(

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

pollman, is that the bug number you intended? it was just a webshell leak
tracking bug.

Comment 7

[Sean Richardson]

pollman must have miskeyed: Bug 17519 is cogent here. For the reasons
given below I think it's important that that fix for 17519 be applied to
the M11 branch and verified before M11 is released.

No matter how many times or how many ways first-time users of Bugzilla are
pointed to the bug-writing guidelines, there will be some valid bugs reported
poorly just after each milestone, and especially after the public betas, by
people who have tried out that release on the pages and sites they consider
important. In those cases, the data in the <select>s may not be repeated
inside the report; if that data is corrupted, it is lost.

This happened with M10; IMHO it's worth some attention to prevent in the future.
It is a QA concern with the whole public bug-reporting process: who is the
QA person most responsible for that?

The focus of this bug is *any* Mozilla bug that causes data corruption
using Bugzilla with a Milestone release. Once Mozilla is more stable on the
Bugzilla cgi-generated pages, especially enter_bug.cgi, this could be expanded
to all builds, but it is a major concern for the milestones and betas.

Comment 8

[Risto Kotalampi]

Ooops...I didn't mean to change this.

Comment 9

[leger]

*** Bug 18590 has been marked as a duplicate of this bug. ***

Comment 10

[Risto Kotalampi]

Moving this away from Server Operations.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

Since 17519 has long since been fixed on the tip, I'm marking this bug fixed. 
If that's the wrong thing to do, feel free to re-open.

Comment 12

[Sean Richardson]

Just when I thought this problem was gone forever, up it popped again, for one
build. See bug 25624, "2000012808 submitting first, not SELECTED item in 
<SELECT>", FIXED. It looks like this is getting checked for after any change
to the code handling <SELECT>s, so this can probably be safely closed now.
VERIFYing.