Closed
Bug 386027
Opened 17 years ago
Closed 8 years ago
No state changed event for STATE_EDITABLE when MIDAS is set to readonly
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)
References
(Blocks 1 open bug)
Details
(Keywords: access, Whiteboard: [auto-closed:inactivity])
Try http://www.mozilla.org/editor/midasdemo/
Mark "Readonly" checkbox.
Check with accerciser.
185 editor->GetFlags(&flags);
186 if (0 == (flags & nsIPlaintextEditor::eEditorReadonlyMask)) {
187 *aExtraState |= nsIAccessibleStates::EXT_STATE_EDITABLE;
188 }
should be copied/moved to nsDocAccessible.cpp
We need a general fix for EXT_STATE_EDITABLE and STATE_READONLY.
Assignee: aaronleventhal → ginn.chen
Updated•17 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 2•17 years ago
|
||
Bug 390767 fixes the state but we need to keep this open for the STATE_EDITABLE state change event.
Keywords: access
Summary: Still get STATE_EDITABLE when MIDAS is set to readonly → No state changed event for STATE_EDITABLE when MIDAS is set to readonly
Comment 3•17 years ago
|
||
Here's the code in the testcase which switches the rich text area to readonly:
It does that via
document.getElementById('edit').contentWindow.document.execCommand("readonly",
false, !(source));
I'm not sure how we can detect that.
Comment 4•17 years ago
|
||
It's worse for chrome; making an editor readonly is as simple as
editor.flags |= nsIPlaintextEditorMail.eEditorReadonlyMask;
So you would need to update nsEditor.cpp to dispatch some sort of event.
Comment 5•17 years ago
|
||
Fire an event from nsTextEditRules::SetFlags(), so we get events for plaintext and html editors and it looks it's all sort of editors mozilla uses. Then catch event in ally and fire state changed events. Though then we don't need to fire state changed events based on attribute changing to avoid
dublication. Though how can we fire an event from nsTextEditRules::SetFlags(), should be the event sync or async?
Comment 6•17 years ago
|
||
Surkov, this isn't a priority for Firefox 3.
Comment 7•14 years ago
|
||
(In reply to comment #2)
> Bug 390767 fixes the state but we need to keep this open for the STATE_EDITABLE
> state change event.
still a problem
Blocks: eventa11y
Comment 8•8 years ago
|
||
AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [auto-closed:inactivity]
You need to log in
before you can comment on or make changes to this bug.
Description
•