Closed Bug 17519 Opened 25 years ago Closed 25 years ago

[DOGFOOD] selects showing up with wrong thing initially selected


(Core :: Layout: Form Controls, defect, P1)






(Reporter: dbaron, Assigned: rods)



(Whiteboard: [PDT+])


(1 file)

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.

 * load

 * it says "ActiveX Wrapper" and "M1" are selected instead of "XPApps" and "".

 * Linux, apprunner, 1999-10-28-08-M11

 * older builds

 * 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.
Assignee: karnaze → rods
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.
OS: Linux → All
Hardware: PC → All
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

Viewing the live testcase  - -
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.

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
   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).

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.

The Bugzilla Bug page will display, somewhat slowly, with all Form Controls
showing their proper selected values, the first time.

Windows NT 4.0sp3, mozilla.exe, 1999-10-30-08-M11 nightly binary.

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.
Closed: 25 years ago
Resolution: --- → FIXED
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.
*** Bug 17363 has been marked as a duplicate of this bug. ***
Resolution: FIXED → ---
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.
Priority: P3 → P1
I am seeing this on linux in tinderbox TM field,
P1 to match blocker sev.
Summary: selects showing up with wrong thing initially selected → [DOGFOOD] selects showing up with wrong thing initially selected
Target Milestone: M11
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

(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.
Whiteboard: [PDT+]
Putting on PDT+ radar.
*** Bug 18600 has been marked as a duplicate of this bug. ***
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
they should initialize correctly now - fixed
Blocks: 16719
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
QA Contact: cpratt → elig
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

(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
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  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  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.
Blocks: 21549
No longer blocks: 21549
You need to log in before you can comment on or make changes to this bug.