Closed Bug 279400 Opened 20 years ago Closed 20 years ago

Select a username prompt doesn't highlight the first listed item

Categories

(SeaMonkey :: Passwords & Permissions, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 280754

People

(Reporter: mike, Assigned: dveditz)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050122 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050122 Between the 20050118 and 20050119 nightly builds the "select a username" prompt stopped highlighting the first item in the list when it was selected. When a subsequent item is chosen, it is highlighted correctly. Reproducible: Always Steps to Reproduce: 1. Store multiple userid/password entries for a site. 2. Go to site. Actual Results: Select a username dialog shows asking user to select a userid. The first item in the list is selected by default. However, it is not highlighted. Choosing another item with either the keyboard or the mouse highlights that item. When reselected the first item again does not highlight. Expected Results: Selecting any item in the list should show said item's selection as highlighted.
Keywords: regression
This bug is also materializing in the Mail/Newsgroup Spellcheck window where the first item in the suggested word list is selected but no highlight is shown.
Severity: minor → normal
Mike, what are the hour stamps on those builds?
I've only tried this on Win32 and Mac. The Win32 build on the 18th is 6:47 and the Mac build is 7:40. The Mac build on the 19th is 7:59 and the Win32 build is 8:02. Therefore, the change must have occurred between roughly 7:40 on the 18th and 7:59 on the 19th. However, since those are the times the files were put on the download server and not the times the checkout portion of the build started, it's possible it could have happened in the window between checkout and build finish on the 18th.
I'd actually spotted this somewhere, but forgot about it :-( It suspiciously resembles the profile manager listbox selection bug 120410.
selectDialog.xul is expecting the <listitem> XBL to be applied immediately. You can use about:config to demonstrate the bug. New -> Boolean -> "foo" Moving the the list.selectItem(elements[0]); to after window.sizeToContent(); will work around the bug because the latter forces a layout flush.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 280380 has been marked as a duplicate of this bug. ***
Ah, I see. This was being bitten by the listbox not creating frames till layout. The patch for bug 280754 fixes this, as far as I can tell. Which confuses me -- the regression range in comment 0 and comment 3 doesn't agree with the checkin that caused this bug (that happened at 2005-01-19 19:39).... Anyway, this worksforme in the build with bug 280754 fixed, so if it works for Mike in tomorrow's build this should be marked duplicate.
Depends on: 280754
The 2/5 nightly seems to fix the problem. Marking this as a duplicate of bug #280754. I would like to point out, however that this one was reported first! :) *** This bug has been marked as a duplicate of 280754 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Verified.
Status: RESOLVED → VERIFIED
No longer depends on: 280754
You need to log in before you can comment on or make changes to this bug.