Opened 9 years ago

Closed 7 years ago

Last modified 6 years ago

#11064 closed defect (wontfix)

clicking disabled widgets focuses them (webkit)

Reported by: bill Owned by:
Priority: high Milestone: future
Component: Dijit Version: 1.5.0b1
Keywords: Cc:
Blocked By: Blocking:

Description

Clicking on a disabled widgets will still focus it on safari or chrome (and even the latest nightly build of webkit).

Problem seems to be a webkit bug that affects any elements that ever had a tabIndex setting, even if the tabIndex attribute has since been removed or set to -1. Setting to -1 is better than removing because at least it makes the field untabbable. Note though that apparently tabIndex=-1, while widely supported by browsers, is not part of the HTML spec) Note that I'm referring to tabindex setting on <span> or <div>, not on traditional form nodes like <input>.

So I don't think we can/should do anything to fix this, but rather wait for the webkit bug to be fixed. I'm filing this ticket for reference.

Attachments (1)

focusBug.html (1.0 KB) - added by bill 9 years ago.
test file I used for webkit bug

Download all attachments as: .zip

Change History (11)

Changed 9 years ago by bill

Attachment: focusBug.html added

test file I used for webkit bug

comment:1 Changed 9 years ago by bill

(In [22011]) Fixes so that disabled widgets don't get focus by mouse or keyboard:

  • Made focus manager ignore click events on disabled widgets. It still responds to actual focus events so that Menu still works (which focuses the disabled MenuItems). Clicking a disabled dijit.form.Button in an enabled TabContainer will call onFocus() on the TabContainer (and the ContentPane) but not the Button.
  • Fixed _FormWidget._setDisabledAttr() to set/remove tabIndex on all focusable nodes. Usually only focusNode is focusable, but ComboButton has two focusable nodes. Disabling a widget now sets tabIndex=-1 on nodes like <button> but removes tabIndex on nodes like <div>.
  • Added new method dijit.hasDefaultTabStop() to support above code.

The only remaining problem is webkit, where clicking widgets still gives them focus, but this is a webkit bug that doesn't seem feasible to workaround. I did add workaround code for webkit so at least keyboard works correctly, by using tabIndex=-1 instead of removing tabIndex (see #11064 for details).

Fixes #8903, #8923, #8595, #11053, refs #11064 !strict.

comment:2 Changed 9 years ago by Douglas Hays

(In [22139]) References #11064. Firefox has issues as well with focusing the disabled ComboBox? button since its an INPUT now.

comment:3 Changed 9 years ago by Douglas Hays

I think this has been fixed in Safari 4.1 & 5.

comment:4 Changed 9 years ago by bill

I don't think so, I just tried test_TabContainer.html in Safari5/mac and Safari5/win, and clicking the (initially) disabled left-scroll button puts the blue border around it.

Also, still, in the focusBug.html test case I attached, even after clicking "remove tabindex on second div" or "set tabindex=-1 on second div", clicking the second div (marked "two") gives it the blue focus outline.

comment:5 Changed 9 years ago by Douglas Hays

I tried test_validate.html using Safari5/win and I cannot focus the textboxes that are disabled, either initially disabled or programmatically disabled.

comment:6 Changed 9 years ago by bill

AFAIK there was never a problem with textboxes, even safari4 is working fine for me. The issue is with other widgets.

comment:7 Changed 8 years ago by Douglas Hays

(In [23424]) Fixes #12114, refs #11064. Only set -moz-user-input:none; input for the presentation INPUT nodes, not the real INPUT for readonly TextBox? widgets to allow for text selection and hint (title) popup text.

comment:8 Changed 8 years ago by bill

Still happens on chrome 13.

comment:9 Changed 7 years ago by bill

Resolution: wontfix
Status: newclosed

Marking as wontfix to get out of queue; we are waiting for chrome to fix their bug.

comment:10 Changed 6 years ago by bill

Note: still happens on Chrome 20.

Note: See TracTickets for help on using tickets.