Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#8946 closed defect (fixed)

_Widget-ondijitclick: shift-enter causes button keypress (IE8)

Reported by: bill Owned by: Becky Gibson
Priority: high Milestone: 1.4
Component: Accessibility Version: 1.3.0b3
Keywords: Cc:
Blocked By: Blocking:

Description

On IE8 when running _Widget-ondijitclick.html, after focusing on the <div> typing shift-ENTER will "click" the <button> below the <div>.

Unclear if this is a problem with the test script or with ondijitclick, or with IE8... I can imagine shift-ENTER submitting a form but there are no forms in this test.

Change History (13)

comment:1 Changed 10 years ago by bill

There are tests for this in tests/robot/_Widget-ondijitclick_a11y.html.

I'm going to comment them out for now but they should be uncommented when this and #8978 are fixed.

comment:2 Changed 10 years ago by Becky Gibson

Milestone: tbd1.3.1

comment:3 Changed 10 years ago by bill

Milestone: 1.3.11.4

Talked with Becky about the ondijitclick bugs; agreed to move them to 1.4 since they aren't regressions

comment:4 Changed 10 years ago by Becky Gibson

Resolution: fixed
Status: newclosed

(In [17832]) fixes #8879, #8946, #8951, #8978, #8979, #9304, #9156 rework of ondijitclick event handler. Perform action only on keyup of enter or space. Track object that receives keydown and only invoke action on keyup when target matches the keydown object. Do not use ondijitclick for elements that already have onclick support for enter and space key press (button, links) or when that onclick event will bubble up to a parent element. Thus, changed button and combobutton templates to use onclick rather than ondijitclick. No longer need special case for submit and reset buttons in button.js _onButtonClick(). Updated button_a11y.html test file to include test of submit and reset buttons. Updated widget-ondijitclick.html to again include space and enter key testing. !strict

comment:5 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: closedreopened

I'm still seeing "plain button clicked" using IE8 after applying this change

comment:6 Changed 10 years ago by Becky Gibson

I can reproduce this on a nightly build - however, I can not reproduce locally on my machine??? Bill, can you try on your machine? It makes it very hard to debug when I can't reproduce it locally.

comment:7 Changed 10 years ago by Becky Gibson

ok, it gets stranger - it has something to do with security settings. If I put httparchive.dojotoolkit.org into my local intranet sites, then this bug is fixed in a nightly build after june 11. IOW pressing shift-enter does nothing - the button is not clicked and focus does not change.

comment:8 Changed 10 years ago by Becky Gibson

I can duplicate on my local server if I go to Tools Internet Options, security tab, select local intranet, click on Sites, and UNcheck Automatically detect intranet network. Makes no sense to me that shift-enter behaves differently with that checked but it does. At least I can debug the problem now.

comment:9 Changed 10 years ago by bill

Hmm, that's really weird. The shift-enter shouldn't even be firing the ondijitclick and thus the button below shouldn't even get focused.

Apparently shift-enter has some kind of special meaning in IE although I don't know what. The only thing I can find is about adjusting the address bar.

comment:10 Changed 10 years ago by Becky Gibson

I found the reference to the address bar as well. shift-enter seems to invoke the first button it finds on the page - still testing that out. It definitely isn't going through our ondijitclick code. Stupid IE!

comment:11 Changed 10 years ago by bill

Oh I see... probably then shift-ENTER submits a form.

Those <button> nodes don't have type=button on them so technically they are submit buttons, since type=submit is the default (although older browsers don't follow that rule).

Anyway, let's just change those buttons to be type=button if that fixes the test. I didn't mean to be testing submit button behavior. Actually, I don't think the shift-click testing is that important to begin with; I just copied it over from the original test.

comment:12 Changed 10 years ago by Becky Gibson

Resolution: fixed
Status: reopenedclosed

(In [18295]) fixes #8946 added a type=button to the buttons in this test so they would not be treated as the default of type=submit. Seems that IE8 thinks that shift-enter should activate submit buttons - although I can't find that documented anywhere. Putting the type on the button causes shift-enter to work as expected (do nothing) in IE8 and other browsers.

comment:13 Changed 8 years ago by bill

(In [24185]) Refactor parser to allow attributes (for a single node) to be partly specified in data-dojo-props, and partly specified directly ex: value=123. Uses node.attributes to detect which attributes are specified on a node, or for older versions of IE calls cloneNode(false) followed by some regex's on clone.outerHTML.

Due to lowercase/uppercase issues (ex: tabIndex, onClick), and for type conversion, the code still introspects each widget to get it's attribute metadata. In the future, would like to defer/avoid that in the common case. Fixes #10153, #12423, #12476, #10150, #9823, refs #11490 !strict.

Also fixes the problem on IE8 where a button without type=... defaults to type=submit rather than whatever the widget defines the default as, fixes #10163, refs #9334, #8946.

Future updates will be attached to ticket #12476.

Note: See TracTickets for help on using tickets.