Closed
Bug 418405
Opened 16 years ago
Closed 15 years ago
Table with aria-role='log' not updated after inserting a row with a cell with <br> tags in it
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: Gijs, Assigned: Gijs)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file)
16.16 KB,
application/zip
|
Details |
STR: 1. Open ChatZilla (0.9.81 or trunk) on a recent trunk build. 2. Go to irc://moznet/foo (or wherever) 3. Send a message, eg. "hello" 3a. Observe that the message shows up in the accessible tree in accexplorer. 4. Hit ctrl+up-arrow to use the multiline input box, and send a message: "foo\n bar" 4a. Observe that the message does not show up in the accessible tree. 5 (optional). Send another 'normal' message, eg. "foo". 5a (optional). Observe that this message does not show up in the accessible tree either. I would write a minimal testcase, but I really don't project to have time before sunday, and b4 freeze is next week, so if we want this fixed it had better be quick. :-( (if someone else wants to do it, the testcase in bug 404881 should be very easy to adapt for this bug)
Flags: blocking1.9?
Assignee | ||
Comment 1•16 years ago
|
||
Oops, tweak deps...
Assignee | ||
Comment 2•16 years ago
|
||
Ah, yes. I requested blocking because this, too, is important to make ChatZilla Just Work as far as accessibility is concerned, as per the STR in comment #0. Sorry for spam.
Comment 3•16 years ago
|
||
Is this a regression?
Comment 4•16 years ago
|
||
Marco, have you idea what we do not do on our side? Do we expose some accessible incorrectly or miss events or?
Comment 5•16 years ago
|
||
(In reply to comment #4) > Marco, have you idea what we do not do on our side? Do we expose some > accessible incorrectly or miss events or? We are basically doing the same thing that bug 404881 started out with: If a row with a td in it that contains a br is added to the table, a11y does do exactly NOTHING. It behaves as if that change never happened. DOM tree gets updated, a11y tree doesn't.
Comment 6•16 years ago
|
||
Based on comment 5 I don't think this blocks. Aaron knows how to renominate if I'm wrongthinking, here.
Flags: blocking1.9? → blocking1.9-
Comment 7•15 years ago
|
||
Gijs, is this still a problem?
Assignee: aaronleventhal → gijskruitbosch+bugs
Assignee | ||
Comment 8•15 years ago
|
||
(In reply to comment #7) > Gijs, is this still a problem? Well, I wouldn't know, in fact - because we worked around it. I hacked ChatZilla to not insert <br /> for messages containing newlines - because in fact, in IRC, messages can't actually contain newlines, so the insertion of these messages as one 'thing' into the table, including newlines was deceiving anyway. Instead, the messages are now split into several different table rows, eliminating the practical problem. It should be fairly trivial to hack a page which auto-spammed a table with "messages", that I sent Marco a while ago for a JAWS issue, to test this.
Assignee | ||
Comment 9•15 years ago
|
||
Aforementioned quick possibility for testing. I can't actually verify whether that works, someone else will have to do this - I'm on mac and DOMI seems unwilling/unable to provide me with any a11y info (this is on 3.0.5)...
Assignee | ||
Comment 10•15 years ago
|
||
Tested this on a uni machine. It WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090216 Minefield/3.2a1pre Marco, it might still be worth doing a unit test for this? Or not? Do we know what fixed it, specifically?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Comment 11•15 years ago
|
||
I think it's worth to check bug 472662 - we missed reorder event that might lead some windows screen readers don't update a11y tree
You need to log in
before you can comment on or make changes to this bug.
Description
•