Closed Bug 418405 Opened 12 years ago Closed 11 years ago
Table with aria-role='log' not updated after inserting a row with a cell with <br> tags in it
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)
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.
Is this a regression?
Marco, have you idea what we do not do on our side? Do we expose some accessible incorrectly or miss events or?
(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.
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-
Gijs, is this still a problem?
Assignee: aaronleventhal → gijskruitbosch+bugs
(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.
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)...
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: 11 years ago
Resolution: --- → WORKSFORME
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.