Open Bug 543547 Opened 14 years ago Updated 2 years ago

Keyboard movement through a select list cannot be prevented

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Platform:
x86
Windows Vista
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: anthony.h.garrett, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)

Cancelling the keydown and keypress events on a SELECT tag fails to prevent the action. This applies to both arrow keys and value selection.

Reproducible: Always

Steps to Reproduce:
Steps apply to sample code below:

1. Tab to the drop down box.
2. Press down arrow (or 1,2,4 or 5).
3. Respond with mouse to alert boxes.
Actual Results:  
Select box selected option changes as requested.

Expected Results:  
Select box option should remain unchanged as both keydown and keypress events are cancelled.

I have read a lot of debate about whether cancelling one event should cancel all in these circumstances. This bug is only loosely related because the both events are being separately cancelled.

This code has been shown to work in the current versions of Opera, Chrome and Safari (Windows).

Test case:

<html>
 <head>
  <title>Test</title>
  <script type='text/JavaScript'>
    function stop(evt) 
	{alert(evt.type);
	 evt.preventDefault();
	 evt.stopPropagation();
	};
   </script>
 </head>
 <body>
  <select onkeydown='stop(event);' onkeypress='stop(event);'>
		<option>1</option>
		<option>2</option>
		<option selected="selected">3</option>
		<option>4</option>
		<option>5</option>
	</select>
 </body>
</html>
18 Days and nobody's picked this up. This is blocking a software release.
Almost 5 months since this was originally posted and it's not even picked up yet. Does this system of reporting bugs actually work?
While there may be a bug here, I still have to ask why you would you want or need to do this. It's horrible design that breaks accessibility.
Thanks for commenting Stephanie.

The code is just a test case designed to show the problem. In the actual code it implements (rather than breaks) accessibility. I am inhibiting the default behaviour in order to provide a consistent alternative behaviour that is logical in the specific circumstances of the code.

It works in most other mainstream standards-based browsers therefore failing to prevent the action becomes de facto "non-standard". What I would like to see is consistent behaviour across all those standards-based browsers.

As it is now a year and a half since discovering the bug, I have found a way to force the correct behaviour (a work-around), however, it would still be great to remove this inconsistency with those other browsers.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.