Closed Bug 145388 Opened 23 years ago Closed 23 years ago

[FIX]Can't tab out of content area or use accesskeys when in print preview mode

Categories

(Core :: Print Preview, defect)

Product:
Core
Component:
Print Preview
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: samir_bugzilla, Assigned: rods)

References

Details

(Keywords: access)

Attachments

(1 file)

patch
935 bytes, patch
dcone
: review+
attinasi
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review
It appears that the content calls nsIDOMEvent::preventDefault() (even with a mouse move) in its print preview incarnation. This prevents the user from tabbing out of the content area or from using accesskeys to get to the toolbar buttons (page setup, print, and close). We need a strategy for the content to allow an include list of keystrokes to perform functions in an accessibility-compliant fashion.
Nominating for RTM. Transferring access and sec508 keywords from bug 133506 which is blocked by this bug. Is there a performant way to handle this in the front-end instead?
Depends on: 133506
Keywords: access, nsbeta1, sec508
Not sure if there is much we can do....
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Attached patch patch — — Splinter Review
The allows TAB events to be processed. This seems to work fine, because the forms controls can never get focus. I did a lot of testing and the focus goes to the toolbar and doesn't go to any forms controls. Low risk
Summary: Can't tab out of content area or use accesskeys when in print preview mode → [FIX]Can't tab out of content area or use accesskeys when in print preview mode
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Comment on attachment 84438 [details] [diff] [review] patch r=dcone
Attachment #84438 - Flags: review+
If you are looking for a checkin to the document viewer version 1.273, it was really for Bug 132672. The checkin comment incorrectly referenced this bug.
What about links? Can they get focus with this change?
No it doesn't go to links, I tested that and form controls.
Comment on attachment 84438 [details] [diff] [review] patch sr=attinasi
Attachment #84438 - Flags: superreview+
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
verified in 5/23 trunk build.
Status: RESOLVED → VERIFIED
What about accesskeys? That is, the ones attached in the patch for bug 133506. Does the user need to tab to the toolbar before s/he can use the accesskeys? aaronl, would the latter be acceptable for ``access'' and ``sec508'' requirements?
Blocks: 143047
Keywords: adt1.0.0 → adt1.0.1
Whiteboard: [adt2] → [adt2 RTM]
Removing nsbeta1+, adt1.0.1 nomination since Rod and I discussed that the front-end can handle the ``include'' list and preventDefault() for all other keydown events. Will be handled entirely by bug 133506 for this revised strategy.
Keywords: adt1.0.1, nsbeta1+
Comment on attachment 84438 [details] [diff] [review] patch a=chofmann for 1.0.1 add the fixed1.0.0 keyword when the checkin is completed on the branch. thx
Attachment #84438 - Flags: approval+
Whiteboard: [adt2 RTM]
is this on the 1.0 branch? if so, pls mark as fixe1.0.1. thanks!
Keywords: adt1.0.1, mozilla1.0.1, nsbeta1
Whiteboard: [adt2 RTM]
Whiteboard: [adt2 RTM] → [adt2 RTM] [ETA 06/27]
This fix is no longer need because of 133506, marking as nsbeat1- and removing other keywords
Keywords: adt1.0.1, mozilla1.0.1, nsbeta1 → nsbeta1-
removing ADT grafitti becasue this problem was addressed in bug 133506.
No longer blocks: 143047
Whiteboard: [adt2 RTM] [ETA 06/27]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: