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.
Summary: Bug 16152 causing lost OS and Component data in bug reports? → Form Bugs causing lost OS and Component data in bug reports
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 firstname.lastname@example.org 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 email@example.com to Cc: list. Amending Summary Line.
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 firstname.lastname@example.org from Cc: list.
Moving to the newly-available and more cogent "Server Operations" Component.
Reassigning to dmose, not sure if he's the correct person, but he's closer than I am.
See bug 17591 - this was just fixed or M12, but there may still be some problems in M11. :(
pollman, is that the bug number you intended? it was just a webshell leak tracking bug.
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.
Ooops...I didn't mean to change this.
*** Bug 18590 has been marked as a duplicate of this bug. ***
Moving this away from Server Operations.
Component: Server Operations → Miscellaneous
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.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.