Opened 10 years ago

Closed 10 years ago

#13790 closed defect (fixed)

filteringselect focus problem

Reported by: gerhard presser Owned by: bill
Priority: high Milestone: 1.6.2
Component: Dijit Version: 1.6.1
Keywords: dijit dijit.form filteringselect focus Cc:
Blocked By: Blocking:


I have a standard-html-input field and an dijit.form.FilteringSelect? on the same page.

If I enter some data into the input-field, and submit the form, the data I entered will be offered as dropdown-values at the input-field. if I now focus the input-field, and click the down-arrow on the filteringselect, to display all possible options - a dropdown appears on both, the input-field and the filteringselect. a testsuite can be found at:

steps to reproduce
1) enter some data into the inputfield
2) hit the submit-button
3) perform step 1) and 2) another time
4) click onto the input-field
5) click onto the filtering-select's down arror

Attachments (1)

focus problem.png (4.6 KB) - added by gerhard presser 10 years ago.

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by gerhard presser

Attachment: focus problem.png added

comment:1 Changed 10 years ago by Douglas Hays

Probably a Firefox bug related to autocompletion. Adding autocomplete="off" to the native INPUT avoids this problem. Firefox thinks the click on the FilteringSelect? is a click on the native INPUT since focus doesn't change. This is probably a wontfix.

comment:2 Changed 10 years ago by rmaccracken

I am having the exact same problem, but you can also reproduce it with two FilteringSelect? controls. I think there should be something done to address the issue because of the two use cases below. Use the following fiddle to play along...

Use case 1:
1) Click on the text field portion of the first widget and you will notice it has focus with the blinking cursor.
2) Click on the drop-down arrow of the second widget. You will notice the first widget still has focus (well, blinking cursor). If you do this in Chrome, the gold outline of the element in focus is on the second widget.

Use case 2:
1) Select one of the options in the second widget and then click on the input part so that the cursor is blinking.
2) Click on the drop-down of the first widget and start typing. You should notice that the drop-down list of the first widget is covering up what you are typing on the second widget.

I think this behavior is pretty strange and would I think work much better if the text of the widget is selected/highlighted when you click on the drop-down button. If you start typing, then it should replace the existing text and search for matches.

If you do basically the same thing with the HTML input and select controls at the bottom of fiddle, you will notice that the input field will lose focus (and blinking cursor) when you click on the select control.

Can this be fixed?

I overrode the widget and added the following two lines of code to _onDropDownMouseDown to do what I want and it seems to work well:

Last edited 10 years ago by rmaccracken (previous) (diff)

comment:3 Changed 10 years ago by Douglas Hays

Component: Dijit - FormDijit
Milestone: tbd1.6.2
Owner: changed from Douglas Hays to bill
Status: newassigned

Clicking on the down arrow button changes focus in 1.6.0 but not 1.6.1. This regression seems to be caused by [24132] which added stopEvent instead of preventDefault. This is already fixed in 1.7 but it wasn't backported to 1.6.2.

comment:4 Changed 10 years ago by bill

Resolution: fixed
Status: assignedclosed

In [28814]:

Backport [27394] to 1.6 branch, using preventDefault() rather than stopEvent(), fixes #13790, refs #12517, #14408, #14410 !strict.

Note: See TracTickets for help on using tickets.