User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030106 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030106 If you use OnFocus with a form <select> element, when you click on the dropdown, the OnFocus executes, but none of the options are displayed. You must click the dropdown a second time for the form select options to appear. It's as if the element stops working after executing the OnFocus. Example: <select name="thingie" style="background-color: Silver;" onfocus="this.style.background='#ddd';" onblur="this.style.background='#ccc';"> Reproducible: Always Steps to Reproduce: 1. Click a form select dropdown that uses onfocus="something". 2. Click it again, <options> will appear. Actual Results: OnFocus executes (eg: background color is changed in my example), but the option list is not displayed. Click it a second time and the <options> display. Expected Results: OnFocus executes (eg: background color is changed in my example), followed by a the list of form select options dropping down (or up). See forthcoming testcase. Could this be related to a similar bug (185709) I reported a couple weeks ago? http://bugzilla.mozilla.org/show_bug.cgi?id=185709
this is a duplicate; the onfocus causes a reframe, which ends up confusing the event system...
Works For Me in Firefox 0.9, I'm assuming it works on the Trunk as well. Closing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
It doesn't work on trunk (tested with Linux trunk build 2004-07-09-07). Reopening.
Status: RESOLVED → UNCONFIRMED
OS: Windows 2000 → All
Hardware: PC → All
Resolution: WORKSFORME → ---
On Mozilla 1.7.3 on Linux this bug shows up. If you tab between fields to get to a select field - the bug does not show up, but if you use the mouse and click on the field you then require two more clicks to get the select list to drop down. This is using a similar onFocus handler that is changing the background colour.
Confirming and nominating for blocking1.8b2. If it is a dupe, it needs to be duped to the right bug, and most importantly: fixed. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217
Status: UNCONFIRMED → NEW
Ever confirmed: true
The core issue causing this can't possibly be fixed for 1.8 at this point... it's far too late in the cycle for focus-related changes. And yes, this needs to be duped. Which is why it was _not_ confirmed. Assigning to confirmer to dupe.
Assignee: layout.form-controls → per.angstrom
No, I don't wish to look blindly for a bug that may or may not be suitable for duping. Hopefully, now that this one's confirmed, someone who knows will know. Declining the assignment.
Assignee: per.angstrom → nobody
QA Contact: tpreston → layout.form-controls
The testcase above actually seems to be WORKSFORME with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051112 Firefox/1.5
Created attachment 205062 [details] This testcase points out a related problem, with a :focus CSS rule Yes, the test case works for me too, in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051205 SeaMonkey/1.5a. Anyway, I'm attaching a testcase that shows a similar problem, in the hope that somebody can point out the correct bug.
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: DUPEME → DUPEME [wanted-1.9]
Whiteboard: DUPEME [wanted-1.9] → DUPEME
Both testcases seem to work now on Mac and Windows.
Status: NEW → RESOLVED
Last Resolved: 15 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.