Marking blocker because this bug is leading to annoying random changes to fields in Bugzilla, especially Target Milestone fields. DESCRIPTION: Sometimes the wrong thing shows up selected. STEPS TO REPRODUCE: * load http://bugzilla.mozilla.org/show_bug.cgi?id=17517 ACTUAL RESULTS: * it says "ActiveX Wrapper" and "M1" are selected instead of "XPApps" and "". DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-10-28-08-M11 WORKS CORRECTLY ON: * older builds ADDITIONAL INFORMATION: * I assume if you submit the form, these get changed, because I've had a number of fields changed by me that I didn't change.

Reassigning to Rod.

This is quite possibly due to a regression affecting Bug 15841, "SELECT has the first option selected when it should have none" - marked VERIFIED at present. If so, this is a DUP and Bug 15841 need REOPENing. That's as a Form Control bug. As a Mozilla/Bugzilla usage bug, this is a DUP of Bug 16719, if the OPTIONs that should not be active remain active upon form submission.

This is a very different bug from bug 15841. Bug 15841 was a simple code snippet that made the first option selected 100% of the time when *nothing* was initially selected. This seems to happen for very different reasons. Bug 16719 is not a bug against the Browser and is thus not appropriate to mark this bug as a duplicate of it.

Observed this on Windows apprunner 1999-10-30-09-M11. (On bug 16200, where only the Target Milestone field was wrong.) Marking All/All.

This may all be fall-out from the switch to incremental display a few days ago. Many details below, but this is looking like a race condition: either the display of the form control is fully updated by the time the display of the whole page is complete, or it isn't. If so, a temporary display glitch may appear, if not, the display glitch may be permanent. Proposed solution: rather than displaying a form control as soom as a <SELECT> element is opened, and updating what is displayed as the <OPTION> elements arrive, hold off displaying the Form Control until the end tag of the <SELECT> is parsed, to avoid updating the contents of the Form Control at all until its final display state is known. In a way, this is a workaround, but if the analysis below is correct, it should be a complete fix for any number of subtle display problems (the same sort of thing could appear to be a caching bug, for instance, once caching is working). The display problem with the testcase seems both reproducible as a permanent display problem and as a temporary display problem depending on whether it is arriving over a connection to a localhost webserver or a connection through the internet, respectively. On the other hand, for full Bugzilla Bug pages, those arriving over a connection to a localhost webserver show no display problem at all, whereas those arriving over the internet show the temporary display problem. For the testcase, the Form Control in question is the last element on the page, but it is relatively early in the page in live Bug pages. The Result dbaron saw with the testcase - a permanent display of "M1" in the "Target Milestone" Form Control, when it should be "", is reproducible if the page is fetched from a localhost webserver or from a file:/// URL, but not if the page arrives over a slow link, or if there is much more page to display after the "Target Milestone" <SELECT>, as is the case with a full Bugzilla Bug page. Viewing the live testcase - http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2515 - with 1999-10-30-08-M11 on Win NT, the "Target Milestone" control showed "M1" for a second, and then it went away. This seems to be reproducible for *any* live bugzilla page fetched over a slow link that has no defined Target Milestone, as well as for the testcase. STEPS TO REPRODUCE: 1. Start by using the slowest machine available, and a modem network link. 2. Load a Bugzilla Bug page in Mozilla. 3. Do something that will cause the CPU to be nearly maxed out for at least several seconds (reloading http://www.theregister.co.uk/ on a P100 machine works for me). 4. Reload the Bugzilla Bug page. (Steps 1 and 3 may not be necessary to see this, but will help slow things down enough for the temporary display problem to last for even an instant. If the page is fetched and displayed too quickly, however, the display problem may be permanent). ACTUAL RESULT: 1. The Bugzilla Bug page will reload slowly, with a hesitation after drawing the "Component" Form Control. 2. When the "Target Milestone" Form Control displays, it will initially display a narrow box, which will get wider to accommodate the display of "M1". 3. The Form control will get a little wider - about 1 character's worth (wide enough for "M10" through "M20"). 4. Finally, The Form Control will display "" in the wider box. EXPECTED RESULT: The Bugzilla Bug page will display, somewhat slowly, with all Form Controls showing their proper selected values, the first time. TESTED WITH: Windows NT 4.0sp3, mozilla.exe, 1999-10-30-08-M11 nightly binary. OTHER INFORMATION: In the source for Bugzilla Bug pages, the <OPTION SELECTED VALUE=" "> element in the "Target Milestone" <SELECT> is the *last* option. Quickly testing a tweaked testcase with the <OPTION SELECTED VALUE=" "> moved to the beginning of the list, neither the temporary nor the permanent display problems exist. ----- This bug may indeed not be bug 15841 again ... but given that the wrongly selected items quoted in the original report were all the first OPTION in their repective SELECTs, it seemed a reasonable first thing to check, non? I know, should have checked it myself before commiting the comment. As far as "As a Mozilla/Bugsilla problem..." goes, the original report did start by saying that this bug is important because of its effect on Bugzilla submissions, and Bug 16719 is a more general discussion of that problem. Sorry about the wording; didn't mean to suggest RESOLVing this bug report as a DUP of that, only that that aspect of this bug is similar to an already open bug. IMO dbaron is right that Form Control problems that impact the use of Bugzilla should be considered BLOCKERs.

Good analysis. Having worked on the simplified test case, I'm almost sure you're right, because anytime I changed anything before the select, the bug didn't show up anymore. This sounds like it could be a somewhat complicated problem. Is there any way for a select to know that all of its children haven't been delivered yet? The default backwards-compatible behavior (for non-multiple selects -- the previous bug dealt with multiple selects) should be that when nothing is selected, the first option should be selected. However, this shouldn't happen if all of the options aren't in yet. Is this problem better solved in the content sink? That is, should the select not be created until all of its children have arrived? It certainly shouldn't be displayed -- think how that could confuse the user if there were a long network delay. Are there any other elements that need to be handled similarly? cc:ing vidur.

I am sorry a lot time was spent on this bug when I have the fix in my tree. I really do apprecriate the extra work everyone does to help me out with the bugs. I will make sure I always update the whiteboard status when I am working on or I have a fix for a bug. This problem is caused by the incremental switch being thrown. There was an assumption made that when the select gets its initial child list it can be initialized. This is no longer true. The last item of the list may come in afterward and the entire list will then need to be reinitialized. Which is what my fix is. Also, it appears that it is being told to create the frames twice. Vidur and I have talked about this and he is looking into it.

I added code so when ever a new option is add to the list and the option has as its default as being selected, the list's default selections are reinitialized. Fixed

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

Clearing FIXED resolution due to reopen. If this is definitely fixed now, please mark again.

Sorry, I should have added a comment when I reopened. The fix to this bug ended up causeing a the crasher after other code was checked in. It did crash at the time I checked this fix in. Now, we have had to regress and open this bug, but at least this one does crash. All these problem with the select stems from the incremental loading of content.

I am seeing this on linux in tinderbox TM field, P1 to match blocker sev.

dogfood, adding paul mac. Do we need this for M11 now that bugzilla almost works?

If this is, as it seems to be, a display problem only, then it would have no potential to cause data corruption in bugzilla like Bug 15841 did with the M10 release... based on that, this may not be a serious blocker. If there is any chance that on form submission the incorrectly highlighted <option> could be SELECTED, however, it is a blocker: Making sense of Newbies' bug reports with invalid info due to two SELECTED options in a non-MULTIPLE <select>, no fault of the newbies' (though they still ought to see and fix such), is no fun. Rod, can you say if it a display-only problem for sure, or will some form submissions when the bug is showing itself be needed to answer the question unequivocably? (A display-only problem would prompt the observant to re-select the <option> that is already SELECTED, an annoyance, but no problem if done or not done.)

This does cause data corruption. I had to stop using Mozilla to work on Bugzilla because of it.

Yes, I know it is bad, but the crashers were worse. It should be fixed relatively soon.

Putting on PDT+ radar.

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

they should initialize correctly now - fixed

rods, was this checked in on the M11 branch or the M12 tip? I think shipping M11 without this fix would be a _really_ bad idea.

Adding chofmann, who should comment on the m11-branch status for this bug.

I strongly support getting this in to M11. If it's not, M11 will wreak havoc on Bugzilla.

Pratt is out of town --- QA Assigning to self.

dbaron & sidr, I just stepped onto this bug since cpratt is out of town, and defer to your expertise. Does this appear fixed to either of you? I've checked the 1999111218 builds (M11 candidate) on Win32/Linux, and I'm seeing the behavior described an "M1" milestone initially appearing in the Milestone SELECT prior to the actual content appearing. (My understanding from chofmann's post is that this is slated for going into M11, but it wasn't entirely clear.)

It seemed fixed to me on the M12 build yesterday. I didn't try the M11. If you see the M1 there and it *stays* there when the page is done loading, it's not fixed.

Ah. I see it for a split second, and then it's replaced with the correct content.

Two points: 1. If were seeing "M1" staying after page loading is done, the bug is biting, but if it is temporarily showing I think it may still be latent. I was able to get both behaviours from the same page with an earlier build by manipulating how loaded down the modem link and processor were on a slower machine. If you are seeing "M1" incorrectly at all, it may stay permanently in some circumstances and cause the data corruption. 2. Quoting from bug 16719: >------ Additional Comments From pollmann@netscape.com 11/11/99 16:14 ------- >See bug 17591 - this was just fixed for M12, but there may still be some >problems in M11. :( >------- Additional Comments From sidr@albedo.net 11/11/99 17:27 ------- >pollman must have miskeyed: Bug 17519 is cogent here, and 17591 is NEW. Pollman must have been referring to the fix that has been applied to M12 for this bug. Probably only Rod can tell you how much work is involved to get the fix into the M11 build. Downloading 1999-11-12-18-M11 now to check on this bug.

With the current M11 build: For the testcase: "M1" appears and then disappears iff the testcase is loaded from a file:/// ; the Target Milestone shows "" if loaded over the 'net. For this page: the Target Milestone shows "", then "M1", then "M11" before page loading stops iff loaded from a file:/// ; the Target Milestone shows "M11" initially if loaded over the 'net. This is the same behaviour seen in the "ACTUAL RESULT" section of my 10/31/99 15:00 comment. Tested with 1999-11-12-18-M11 nightly binary on Windows NT 4.0sp3.

Yes, but are there any cases where it stays wrong? That's the real problem (that can't be shipped in M11), and that's the problem I think Rod fixed.

Per dbaron's comments, I'm verifying this as fixed; the form pop-up menus only display the incorrect values for a split second, and are then replaced by the correct content. (on all 3 platforms, current M12 candidates.) sidr & dbaron, you're the experts on this bug. Please re-open with your comments if I've missed the big picture.