GNOME Bugzilla – Bug 520760
(ff3) read document ignoring remainder of object when first subelement is non-text.
Last modified: 2008-04-01 19:57:25 UTC
Please describe the problem: Please see attached testcase. Given a column in a table, if the first object in the cell is a link, then when using read-document we seem to be ignoring the remainder of the column. Same seems to be true for paragraphs. Havent looked to see if further objects do the same. Steps to reproduce: open up attached html in ff3. posision ourselves at first line. orca shortcut for read-document. Actual results: not all of the text is being spoken Expected results: We would like to hear the same as if we arrowed down line by line. Does this happen every time? yes Other information:
Created attachment 106685 [details] promissed testcase.
The testcase should be a stripped down version of the problem described in the mailing list: http://mail.gnome.org/archives/orca-list/2008-March/msg00173.html Thanks Garrett
Another example where read-document fails to read remaining block, this time from the BBC: http://news.bbc.co.uk/1/low/world/americas/7308779.stm with the following markup: --cut-- <P><img src="http://newsimg.bbc.co.uk/media/images/44507000/jpg/_44507216_obama_ap203b.jpg" align="left" width="203" height="152" alt="Barack Obama, 20 March 2008" border="0" vspace="4" hspace="4"> The state department has not revealed which company the contractors worked for. --cut-- (nope i didnt miss the closing </p>, the bbc just dont use xhtml :( ) Thanks to Jonathan Duddington from the mailing list.
Jon, thanks for filing these. I'm going to make this weekend SayAll weekend and hopefully get rid of these issues. :-)
ok, got some more intresting info, its the read by sentance thats causing it, when we switch to read by line, the <p<a ..>bob</a> ... </p> is all there. although i seem to have stumbled across another related 2 bugs, 1. When we are in read-by-line, we read "another link (pause) link to google in the middle link" the "in the middle" is on the next line, so we shouldnt be reading it. 2. after reading "in the middle" in the previous case, the read-doc stops, as if there isnt anything else to read. do you want these as a seperate bug? (they are read-by-line rather than by sentance.
i wonder why ff3 doesnt expose standard text as objects. It would make it less necessary to jump through all this number of hoops. so: <p>some text <img ...> some more text would be exposed as a paragraph with 3 children. Everything else is being exposed as objects, so why should text be diffrent. Yes it isnt how the markup is done, but its implicit.
Thanks for the extra info Jon! For now, no separate bugs are needed. I appreciate the offer though. Tomorrow I'll triage. If they are indeed separate bugs that require unique fixes, I'll split them apart.
Created attachment 107847 [details] [review] revision 1 Pylinted; still needs to be regression tested. In the meantime, please test. Thanks!!
(Passes the regression tests).
Excellent work Joanie, works well. bonus: even reads the missing text for bug http://bugzilla.gnome.org/show_bug.cgi?id=519478 (in read-doc) mode), no change in line-nav which the report is for.
So far this one is looking good to me. Lets get the community beating on it. I'd say it's good to check in.
Thanks guys. Patch committed to trunk. Jon, the skipped line bug is next on my list. I'm getting there... <smile>
Patch also committed to the 2-22 branch.
Hi Joanie, Its a very good improvement, but two issues. long pauses between objects: although we seem to have generally longer pauses, especially around consecutive links. back to our regular example, www.bbc.co.uk/radio4/ the links at the top read reasonably fine. then we go down to the search text, then the "go" button. The space between the text field and "go" is very long, and so is the pause between "go" and "accessibility help" ok, we have empty column tables inbetween etc so maybe that could explain some of it. but there are long pauses between "Accessibility Help" and "Text only", same with "BBC homepage" stuckage: yes, more of our beloved stuckage :( its happening on "Listen on Digital Radio, Digital TV and Online link"
sorry, forgot to say, clean rev 3753.
I've also heard what Jon is talking about here. I'm going to put this one back to testing required until Joanie has a chance to take a look.
I'm afraid I'm not seeing the long pauses. But I'll look some more later. If we have empty cells with non-breaking space characters in them, we are (presumably) reading those (which we'd read by saying nothing since it's a space). As for that "beloved stuckage". I found one place where we get stuck on the radio4 site. However if I reverse the patch to this bug (you can get a clean trunk, apply the patch, and when it gives you the following prompt: "Reversed (or previously applied) patch detected! Assume -R? [n]", type y followed by return) I still get stuck at the same point. Which is bad of course, but it's not a consequence of this patch. Sadly, I don't see the link you're referring to (Listen on Digital Radio, Digital TV and Online link.) Jon, what I'd ask you to do -- and you as well Mike since you can reproduce it as well -- is to reverse the patch as I described and see if the problems persist. If they do, then we should open new bugs (one for the stickage; another for the melodramatic pauses). If they do not persist, then we've narrowed it down (yea!), but I will need more details in order to reproduce the problems here. Thanks guys very much!!
ok, clean 3753 sayall has problems. reversing patch 107847 on 3753 does not hickup on the bbc. No matter though, it seem to be out of the system when i update to 3782. i'll close this one off and get back to the pausing issue another time/elsewhere.
Thanks Jon. We typically go from testing required to pending to verified (done by Mike after it's been in trunk for a while and tested and nothing explodes). Back to pending it goes.
As per Mike in team meeting, closing this as FIXED.