Closed Bug 152780 Opened 22 years ago Closed 18 years ago

Support ATK Table-related events

Categories

(Core :: Disability Access APIs, defect)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: zhayupeng, Assigned: Louie.Zhao)

References

Details

(Keywords: access)

row_inserted : important for dynamic content or editing
column_inserted : important for dynamic content or dynamic tables
row_deleted : see above
column_deleted : see above
row_reordered : important if the view changes
column_reordered : important if the view changes
Blocks: 136315
QA Contact: dsirnapalli → jessie.li
Thanks for aaronl's suggestion,
I will implement these event through Mutation event.
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents
Depends on: 152786
aaronl,
I think nsIDOMMutationEvent is different with TableChange Event.
To fire TableChange Event, we need to store the startIndex and number of row/col
be changed in the event. nsIDOMMutationEvent only have prevValue, newValue and
attrName and they are all string. Shall I store above information to them?
Although I can store int value to string, it's not a good idea I think... What's
your opinion on this?
Pete,

I was thinking you would use these events:
DOMSubtreeModified, DOMNodeInserted and DOMNodeRemoved.

For any DOM event, you can get the target node, which is what you will need to
translate into row, column coordinates. See nsRootAccessible::GetTargetNode().

This seems like a lot of unnecessary work to me. This is a really difficult
feature to add, and it might never be used. I don't know of any web pages that
currently manupulate tables dynamically in this way. Maybe you should check with
Bill Haneman and Peter Korn to see if these events are important in the Mozilla
ATK support, especially in the first release. It seems like these events are
meant to be thrown by spreadsheet and database programs, not by a web browser.

That is also why I don't think it's a good idea to add new table events to the
core Gecko architecture. We must not add unnecessary bloat to those core
libraries, or even to the accessibility libraries. I cannot think of a situation
where an assistive technology will use this in a web browser.

Anyway, hope this helps if you decide this is still needed.
These events may not be needed for HTML tables which are static, but they are 
definitely important for table widgets (e.g. in Messenger, in the list of e-mail 
headers).
Good, that will save some work.

We use <outliner> for XUL tables, so we'll have to support nsIAccessibleTable
for XUL:outliner, but not for HTML tables.

Still, even in the XUL outliner, it makes more sense to me to support deleting
and inserting of rows, as opposed to columns. I suppose the user can set
preferences to view or not view certain columns as well, though.


Someone will have to look at outliner to see what events are supported.

XUL <tree> has its own selection change events for row insert/delete.
sorry, selection change is different from insert/delete. I'll find out which 
event was fired for tree insert/delete.
Summary: Support Table-related events → Accessibility: Support Table-related events
Blocks: gnoper
Whiteboard: sunport17
Assignee: zhayupeng → Louie.Zhao
Whiteboard: sunport17
Keywords: access
OS: All → Linux
Summary: Accessibility: Support Table-related events → Support ATK Table-related events
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Since this bug was written in 2002, I feel this bug probably has been resolved,
so I am closing out this bug, if you feel that this has been done in error,
please reopen the bug and explain.
No specific bug / patch referenced as the fix.

-> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.