136041 - Accesskey fires when within visibility:hidden or display:none elements (does not fire in IE)

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[George G. Bolgar]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9+) Gecko/20020406
BuildID:    2002040608

I have a script that starts with a number of DIV sections positioned to the same
screen location (all within the same TABLE <TD></TD> section).  Each of these
DIV sections is selectively (depending upon required state) hidden or visible,
with only one of them visible at one time.

1) Although all 3 of the <DIV> sections starts as visible, but the onLoad event
invokes a function that switches 2 of the DIV sections to hidden.  On IE5.5 and
Opera, the <TD> section width is set to the width of the widest of the DIV
sections.  With Mozilla, the <TD> section (as shown by background colour of
associated with the <TD> section) is set the width of the DIV section that
remains visible after loadeding.  When this DIV section is later hidden, and
another DIV section becomes visible, the new DIV section is larger than the <TD>
section in which it is contained.

2)  The DIV sections contain links, and these links have ACCESSKEY keyboard
shortcuts set.  These shortcuts invoke links, even where the links are hidden.

3)  When DIV sections are switched between hidden and visible, it invokes an
error in the CHROME.  I have disabled the viewing of CHROME errors, but this
still causes a blank error screen to be displayed.

Reproducible: Always
Steps to Reproduce:
1.Invoke HTML document.
2.Click on 'Add New Group'
3.Press Alt/U key combination (this should invoke 'Update' function, but that
function is missing from the dispolayed screen, and should not be invoked at
this time.

If you require a copy of the HTML (it is quite complex, and I have not had time
to create a stripped down version of the script to highlight the specific
problems) then let me know.

You can reach me on [e-mail]

Comment 1

[George G. Bolgar]

Attachment: Source files used to create problems

The attached file is a zip file containing the source code (several interelated
files) which I was developing that caused the initial problem to occur.

Comment 2

[Hixie (not reading bugmail)]

(Note: A small testcase would help expedite the triage process -- see 
   http://www.damowmow.com/mozilla/css-testing.html
...for hints on writing useful test cases.)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Am I missing something? I do "add new group".  The display changes.  I do Alt-U.
 I get an alert.  The rendering looks fine throughout.

Could you please provide a clear reproduction scenario (possibly with
screenshots)?  Could you provide something resembling a testcase?

Comment 4

[George G. Bolgar]

The problem is that the alert you are getting is perfectly valid execution of 
the code for ALT/U, but that the element to which ALT/U is associated has its 
CSS visibility attribute set to 'hidden', and as such you are using a keyboard 
shortcut to something that is (correctly) inaccessible through the screen 
interface.  I would assume that when you cannot click on an element, you should 
also not be able to use a keyboard shortcut to the element.  This, by the way, 
is exactly what IE5.5 does (i.e. ALT/U is only functioning when the associated 
element is visible on the screen).

If you wish to see a situation where the ALT/U should be legal, then  perform 
the following actions:

   Click on 'Add New Group'
   Enter some text in the text field (e.g. 'zzzzzz')
   Click on 'Add to List'

You should now see the 'Update' link rendered on the screen, and in this 
context I should consider it legal to be able to use ALT/U.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah.  OK.  So this is an accesskey problem.  Resummarizing so and assigning to 
keyboard navigation.

George, if there are other problems here than the accesskey issue, please file 
separate bugs on them (one bug per problem), as they are somewhat likely to 
belong to different components...

Comment 6

[Aaron Leventhal]

Gilbert, can you take this one?

Comment 7

[Gilbert Fang]

okay, i will take it 

Comment 8

[Bill Mason]

Attachment: New testcase

This bug was noted today on the CSS-Discuss list with the observation that the
accesskey will also work when within an element styled display:none.  This
testcase reflects both display:none and visibility:hidden elements.

Comment 9

[Bill Mason]

Tweaking summary to match testcase.
Also, the current target milestone (1.2a) is badly out of date now.

Comment 10

[Daniel Gotilla]

I don't think this is a bug. Actually, IE's beahvior is un-intuitive. If an 
author is using scripts to show/hide elements he should also enable/disable 
accesskeys on those elements or child elements through scripts, if he so 
wishes. To automatically disable an accesskey just because its related item is 
not visible is not expected UI behavior.

For example: An online application might use a drop-down menu system for 
navigation on all its pages. Some of the menu options could have accesskeys 
attached so that users might activate those links through a key combination 
instead of a couple of clicks (one to open the menu and one to activate the 
menu option). No OS on no platform that I know requires users to open menus in 
order to activate a menu through a key combination. The whole point is not to 
open the menu. 'Fixing this bug' would actually make Mozilla LESS accessible.

Comment 11

[George G. Bolgar]

I understand what you are saying with regard to drop down menus, but hiding
sections of the screen have much wider application than simply hiding sub-menus.

I was looking at using for overlaid panels (similar to the Java does its card
layout), and in this context there could be far too many fields to be constantly
switching accesskeys on each of them in a practical manner - even more of a
problem is that it would not be possible to create generic functions that
switched between sub-screens that were not customised to each sub-screen.

Nor is the issue with menu's as straight forward as you make out.  If I open
Word for Windows, although Ctrl/N will always open a new document, if I wish to
close a document, I have to type Alt/F and C, because although the Close
function has a hot key of 'C', this is only local to the File menu, and it has
no global shortcut.  So the question is whether you are trying to emulate the
functionality of the global shortcuts (with the Ctrl key) or the hot keys (using
the Alt key functionality).



It would also be intolerable, whichever solution were chosen, it would be
intolerable if it only worked on one browser and not another.  In the absence of
any W3C directive, it seems IE has set a de-facto standard.

Comment 12

[Marco Zehe (:MarcoZ)]

I can no longer reproduce the access keys firing using Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0. Is any of this still valid? If not, please close as "Worksforme".

Comment 13

[George G. Bolgar]

As far as I can see the problem has not so much been fixed as avoided by creating a wider problem - accesskeys simply do not work at all now in FireFox, so the fact that they worked wrong seems unimportant if they do not work at all.

Comment 14

[Marco Zehe (:MarcoZ)]

(In reply to comment #13)
> As far as I can see the problem has not so much been fixed as avoided by
> creating a wider problem - accesskeys simply do not work at all now in FireFox,
> so the fact that they worked wrong seems unimportant if they do not work at
> all.

Can you be more specific? I use access keys all the time successfully. Where do they not work for you?

Note that Firefox 3 introduces the Alt+Shift+<accesskey> key combination to avoid menu bar key conflicts.

Comment 15

[George G. Bolgar]

Sorry, I had not realised the change in accesskey usage.

Taking that into account, I see no change on FireFox 2.0, but do not have 3.0 here (I hear it will be available on 17th June)

Comment 16

[George G. Bolgar]

OK, have downloaded FireFox 3.0, and you seem to be correct, the problem seems to have been fixed.