Closed
Bug 136041
Opened 22 years ago
Closed 16 years ago
Accesskey fires when within visibility:hidden or display:none elements (does not fire in IE)
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ggb.mzl, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
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 ggb.mzl@bolgar.co.uk
Reporter | ||
Comment 1•22 years ago
|
||
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•22 years ago
|
||
(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.)
Keywords: qawanted
Comment 3•22 years ago
|
||
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?
Reporter | ||
Comment 4•22 years ago
|
||
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•22 years ago
|
||
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...
Assignee: jst → aaronl
Status: UNCONFIRMED → NEW
Component: DOM Style → Keyboard Navigation
Ever confirmed: true
Keywords: qawanted
OS: Windows NT → All
QA Contact: ian → sairuh
Hardware: PC → All
Summary: CSS visibility switched between hidden/visible → accesskey in visibility:hidden div fires (does not fire in IE)
Updated•22 years ago
|
Blocks: atfmeta
Severity: normal → minor
Status: NEW → ASSIGNED
Priority: -- → P5
Target Milestone: --- → mozilla1.2alpha
Comment 6•22 years ago
|
||
Gilbert, can you take this one?
Assignee: aaronl → gilbert.fang
Status: ASSIGNED → NEW
Comment 7•22 years ago
|
||
okay, i will take it
Comment 8•21 years ago
|
||
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•21 years ago
|
||
Tweaking summary to match testcase. Also, the current target milestone (1.2a) is badly out of date now.
Summary: accesskey in visibility:hidden div fires (does not fire in IE) → Accesskey fires when within visibility:hidden or display:none elements (does not fire in IE)
Comment 10•21 years ago
|
||
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.
Reporter | ||
Comment 11•21 years ago
|
||
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.
Updated•17 years ago
|
Assignee: gilbert.fang → nobody
Severity: minor → normal
Priority: P5 → --
QA Contact: bugzilla → keyboard.navigation
Target Milestone: mozilla1.2alpha → ---
Comment 12•16 years ago
|
||
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".
Reporter | ||
Comment 13•16 years ago
|
||
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•16 years ago
|
||
(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.
Reporter | ||
Comment 15•16 years ago
|
||
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)
Reporter | ||
Comment 16•16 years ago
|
||
OK, have downloaded FireFox 3.0, and you seem to be correct, the problem seems to have been fixed.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Resolution: FIXED → WORKSFORME
Updated•9 years ago
|
Attachment #78113 -
Attachment mime type: application/octet-stream → application/zip
Assignee | ||
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•