Closed
Bug 372367
Opened 17 years ago
Closed 17 years ago
nsIAccessible::isEditable is dead
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
People
(Reporter: surkov, Assigned: surkov)
References
Details
Attachments
(2 files, 2 obsolete files)
3.50 KB,
text/plain
|
Details | |
13.07 KB,
patch
|
ginnchen+exoracle
:
review+
|
Details | Diff | Splinter Review |
Bug 340829 killed doc accessible implementation of isEditable for nsDocAccessible but it is still used in nsLinkableAccessible. 1) We can kill isEditable at all since it isn't used at all excepting of nsLinkableAccessible and use nsDocAccessible::GetState() & STATE_READONLY check instead. 2) Rehabilitate isEditable for nsDocAccessible. Also nsDocAccessible::isEditable checked for states of editor: mEditor->GetFlags(&flags); *aIsEditable = (flags & nsIPlaintextEditor::eEditorReadonlyMask) == 0; but nsDocAccessible::state check for editor itself: nsCOMPtr<nsIEditor> editor = GetEditor(); if (!editor) { *aState |= STATE_READONLY; } Is the check of nsDocAccessible::state enough for us?
Assignee | ||
Comment 1•17 years ago
|
||
Attachment #258091 -
Flags: review?(aaronleventhal)
Assignee | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Comment 2•17 years ago
|
||
Comment on attachment 258091 [details] [diff] [review] patch Isn't it faster to specifically support nsIAccessibleEditableText in nsHTMLTextFieldAccessible? The "smart QI" impl in nsHyperTextAccessible requires it to look at the accessible children of the textfield. But I don't really know if either is that much better.
Attachment #258091 -
Flags: review?(aaronleventhal) → review+
Assignee | ||
Comment 3•17 years ago
|
||
(In reply to comment #2) > (From update of attachment 258091 [details] [diff] [review]) > Isn't it faster to specifically support nsIAccessibleEditableText in > nsHTMLTextFieldAccessible? The "smart QI" impl in nsHyperTextAccessible > requires it to look at the accessible children of the textfield. No, it checks whether mEditor is editable. I changed this because you said on irc nsIAccessibleEditableText should be exposed only if state is not readonly IIRC :).
Comment 4•17 years ago
|
||
Makes sense, actually. Go ahead and check in. One thing -- supposedly according to rules of COM, the interfaces an object supports should remain the same throughout its lifetime. We probably break that rule if something changes its readonly property.
Assignee | ||
Comment 5•17 years ago
|
||
checked in (In reply to comment #4) > One thing -- supposedly according to rules of COM, the interfaces an object > supports should remain the same throughout its lifetime. We probably break that > rule if something changes its readonly property. > Looks reasonable. Once I got nsIAccessibleEditableText then I can try to use it even if the current state is readonly.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
patch backed out due to a regression, firefox crashes when clicking links in webpages.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•17 years ago
|
||
Damn. Apparently bug 264599 will fix this problem. And it should be right fix. For sure we can reintroduce again isEditable method and this will fix this bug too. Though it's not nice solution I guess. Let me look whether bug 264599 can be fixed easy enough.
Assignee | ||
Comment 9•17 years ago
|
||
I meant bug 344674.
Assignee | ||
Comment 10•17 years ago
|
||
Attachment #258091 -
Attachment is obsolete: true
Attachment #260357 -
Flags: review?(ginn.chen)
Assignee | ||
Updated•17 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 11•17 years ago
|
||
Attachment #260357 -
Attachment is obsolete: true
Attachment #260358 -
Flags: review?(ginn.chen)
Attachment #260357 -
Flags: review?(ginn.chen)
Attachment #260358 -
Flags: review?(ginn.chen) → review+
Assignee | ||
Comment 12•17 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Comment 13•17 years ago
|
||
This is consistently causing crashes at startup for me when Window-Eyes is running. I'm not sure if it's the only thing causing bug 376239, but it's one cause. Backing out until Surkov can look at it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 14•17 years ago
|
||
I was wrong, it looked like it fixed the problem because I hadn't rebuilt all the dependencies on nsIAccessible. Reversing the backout and marking FIXED again. Sorry about that.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•