GNOME Bugzilla – Bug 500016
Reading web pages by line in Firefox 3 is slow
Last modified: 2008-07-22 19:32:55 UTC
We need to improve performance when accessing web page content by line (Up/Down Arrow).
A couple great examples of this problem are: www.tigerdirect.com and www.overstock.com. Scott tells me that tiger direct has some nasty javascript that slows down the site even without orca running. For me simply arrowing down through either of these sites is quite sluggish at several points. What I notice is after pressing down arrow there are times where I will have to wait up to two seconds before hearing speech. Note I am using both speech and braille for my testing.
Created attachment 99751 [details] [review] And thus it began.... Putting this here first and foremost for "safe keeping"; secondarily to answer the question, "Is Joanie REALLY working on this issue?" ;-) ;-) ;-) This is a debugging, work-in-progress patch not ready for testing. getLineContentsAtOffset() gets called *constantly*. Every single time we update braille (left arrow, right arrow, tab, etc.), it gets called. The label guessing stuff uses it. And if we just moved by line or by using structural navigation, it gets called twice (once for speech, once for braille). Each time it gets called, it uses findPreviousCaretInOrder() to backtrack to the beginning of the line, then findNextCaretInOrder() to locate the end of the line, checking extents all along the way. This also seems to be why we feel the need to descend combo boxes, focusable lists, etc. when we really shouldn't be doing so. My theory <fingers crossed> is that we will see an improvement in performance if we do the following: 1. Make the method more efficient. Aaron claims getText*Offset() is a viable option now whereas it wasn't before. 2. Call the method once instead of twice whenever possible. 3. Stop descending focusable lists and combo boxes. :-) My plan was/is this: 1. Create alternative methods that come reasonably close to obtaining the same list of tuples that getLineContentsAtOffset() does. This was not *quite* as simple as I initially thought, but the attached patch is well on its way to achieving that. It currently calls both the old and new methods and prints out differences as you navigate should you be curious. Some of the differences are intentional changes/corrections; others are things I'm not doing quite right but simply haven't figured out yet. 2. Once it's "close enough," add a setting to allow one to toggle which method gets used and run performance testing on straightforward pages to see if the getTextAtOffset() approach really is better. I think I'm finally close enough and plan to do this bit tomorrow evening. 3. Proceed/scrap the above accordingly based on the test results. 4. Call whatever method we're going to use once. 5. Look at caching line contents as Will suggested via phone today. Thanks Will! Stay tuned....
I just finished running performance analysis using the Firefox html* tests using a slightly modified version of the patch. The modification was to add a setting called performanceEnhancements. If set to False, getLineContentsAtOffset() does it's thang just like it always does (aside from checking the value of peformanceEnhancements). If set to True, getLineContentsAtOffset() still gets called, but it immediately calls altGetLineContents() and returns those results instead. I also did a second round of the tests without performance analysis so that I could diff the speech output to be sure that we were more or less providing the same information. We are. Granted, it's just a handful of tests (simple tests at that!).... The one *significant* difference on this front was that something in my version reliably caused Orca to feel compelled to start reading the page contents after saying "Loading please wait" but before saying "Finished loading." I don't know why, and I'm not yet at the point where I feel like worrying about it. ;-) What is important now is that both versions move to the same places within the test documents and speak the same things. I'm not familiar with performance analysis, but the following data seem relevant: Current Orca (CO) 4337764 function calls (4317715 primitive calls) in 448.729 CPU seconds Experimental Orca (EO) 2446142 function calls (2434766 primitive calls) in 473.568 CPU seconds (Huh? Significantly fewer calls, but it took 5% more CPU time?? Spoiler alert: EO sleeps more. Dunno what that means.) ~~~~~~~~~~~~ CO - getLineContentsAtOffset() ncalls tottime percall cumtime percall 288 0.630 0.002 42.115 0.146 EO - getLineContentsAtOffset(), plus altGetLineContents() and getObjectsFromEOCs() ncalls tottime percall cumtime percall 286 0.004 0.000 2.895 0.010 286 0.101 0.000 2.890 0.010 1115/298 0.210 0.000 2.120 0.010 ~~~~~~~~~~~~ CO - findNextCaretInOrder(), findPreviousCaretInOrder() ncalls tottime percall cumtime percall 27964/26120 0.824 0.000 28.322 0.001 2054/1215 0.101 0.000 4.175 0.003 EO - findNextCaretInOrder(), findPreviousCaretInOrder() ncalls tottime percall cumtime percall 845/778 0.046 0.000 1.113 0.001 215/191 0.007 0.000 0.226 0.001 ~~~~~~~~~~~~ CO - getExtents() ncalls tottime percall cumtime percall 27938 5.847 0.000 9.657 0.000 EO - getExtents() ncalls tottime percall cumtime percall 2435 0.687 0.000 1.007 0.000 ~~~~~~~~~~~~ CO - queryNonEmptyText() ncalls tottime percall cumtime percall 91783 0.819 0.000 11.015 0.000 EO - queryNonEmptyText() ncalls tottime percall cumtime percall 10481 0.098 0.000 1.318 0.000 ~~~~~~~~~~~~ The rest of the calls and the total time taken in their execution is comparable between versions -- with one exception: CO - time.sleep ncalls tottime percall cumtime percall 92087 371.802 0.004 371.802 0.004 EO - time.sleep ncalls tottime percall cumtime percall 108053 435.109 0.004 435.109 0.004 If EO had only slept the same amount as CO, EO would have come in first on all counts. I'm sure there's a moral in that somewhere.... So what do these numbers boil down to? (i.e. Do they indicate that a refactor of getLineContentsAtOffset() is warranted or not?)
Created attachment 99881 [details] [review] Second verse, same as the first (mostly) This doesn't introduce any new functionality or fixes really. It just has the aforementioned performanceEnhancements setting and some debugging lines removed. This is the what I used during the previous performance tests as well as during some manual testing on reading line by line. More details and data to follow.
Created attachment 99882 [details] profiler data from the previous test and a line-by-line test Will patiently went over things with me on the phone. :-) Thanks Will!! As requested, I ran a couple of manual tests to get more data on the impact of changes to getLineContentsAtOffset() on reading a page line by line. The test conditions were as follows: 1. Orca was launched via the test/harness/runprofiler.py script. 2. The Firefox window was maximized to ensure at least some nice, long lines of text. The screen resolution used was 1680 x 1050. The default font size and other settings were used. 3. Before launching Orca, I had navigated to the main page of our wiki (http://live.gnome.org/Orca). 4. Upon launching Orca, I pressed Alt+Tab to give focus to the FF window. Then I pressed Control+Home to move to the top of the page. Finally I arrowed down line by line until I reached the bottom of the page. Current Orca: 1784800 function calls (1780068 primitive calls) Experimental: 845569 function calls (843572 primitive calls) ncalls tottime percall cumtime percall function 64 0.010 0.000 27.844 0.435 goNextLine(CO) 64 0.009 0.000 12.322 0.193 goNextLine(EO) So it looks like this makes things a little over twice as fast. Not as dramatic as I would have hoped.... But I think we'll see more of an improvement once find{Next,Previous}Line() are not using find{Next,Previous}CaretInOrder() to the degree which they are now. I have attached the data from these runs as well as the data from the previous performance testing: * Previous: harness-no-patch.txt, harness-patch.txt * Line testing: line-no-patch.txt, line-patch.txt
> So it looks like this makes things a little over twice as fast. Not as > dramatic as I would have hoped.... But I think we'll see more of an improvement > once find{Next,Previous}Line() are not using find{Next,Previous}CaretInOrder() > to the degree which they are now. This is looking really good. A 2X performance improvement in this space is great. Your patch took the percall time of goNextLine from 0.435 to 0.193. That is quite a noticeable improvement for end users and is approaching the magic 1/10th of a second number. I think you are correct in that fixing find{Next,Previous}Line will have a dramatic effect on performance. In looking at the below, those functions definitely seem pretty expensive. Another no-shocker is getUnicodeText. I believe it's now expensive because we don't cache the value any more. But, let's hold off on fixing that until the real killers are solved first. bash-3.2$ echo; for foo in `echo getLineContentsAtOffset goNextLine findNextLine getExtents getUnicodeText`; do echo $foo:; grep $foo *patch.txt; echo; done getLineContentsAtOffset: line-no-patch.txt: 130 0.248 0.002 16.775 0.129 /usr/lib/python2.5/site-packages/orca/Gecko.py:6799(getLineContentsAtOffset) line-patch.txt: 130 0.002 0.000 1.152 0.009 /usr/lib/python2.5/site-packages/orca/Gecko.py:6799(getLineContentsAtOffset) goNextLine: line-no-patch.txt: 64 0.010 0.000 27.844 0.435 /usr/lib/python2.5/site-packages/orca/Gecko.py:7528(goNextLine) line-patch.txt: 64 0.009 0.000 12.322 0.193 /usr/lib/python2.5/site-packages/orca/Gecko.py:7528(goNextLine) findNextLine: line-no-patch.txt: 64 1.004 0.016 9.131 0.143 /usr/lib/python2.5/site-packages/orca/Gecko.py:7426(findNextLine) line-patch.txt: 64 0.969 0.015 8.833 0.138 /usr/lib/python2.5/site-packages/orca/Gecko.py:7426(findNextLine) getExtents: line-no-patch.txt: 13753 3.343 0.000 5.188 0.000 /usr/lib/python2.5/site-packages/orca/Gecko.py:4758(getExtents) line-patch.txt: 5329 1.377 0.000 2.127 0.000 /usr/lib/python2.5/site-packages/orca/Gecko.py:4758(getExtents) getUnicodeText: line-no-patch.txt: 14796 2.949 0.000 4.899 0.000 /usr/lib/python2.5/site-packages/orca/Gecko.py:4577(getUnicodeText) line-patch.txt: 4950 0.946 0.000 1.574 0.000 /usr/lib/python2.5/site-packages/orca/Gecko.py:4577(getUnicodeText) Nice work, Joanie! I haven't looked at the code yet, though. I suspect it's probably good and you are being very careful about not introducing regressions.
> Nice work, Joanie! Thanks! > I haven't looked at the code yet, though. Great! 'Cause it's not ready for being looked at yet. ;-) Or rather, it's ready for being looked at from a curiosity perspective, but not a reviewing perspective or even a testing perspective. Rich once gave me "Burridge's Rules of Programming": 1. Get it working 2. Get it better 3. Get it faster 4. Get it smaller I'm still on #1 and will ask for feedback, review, and testing when I begin #2. :-) Those blasted little embedded object characters make things challenging, and just when I think I've got the last "special case" pinned down, I find a new one (or an exception to the rule of an existing one). That said, I'm definitely getting there.... Thanks again!
> Great! 'Cause it's not ready for being looked at yet. ;-) Or rather, it's > ready for being looked at from a curiosity perspective, but not a reviewing > perspective or even a testing perspective. OK - just let me know when you want me to look. :-) Thanks! The performance work in this space is very important.
Here's another specific example that might be related. It comes from Michael Whapples on the orca-list: "The example I am going to give here is related to firefox and web browsing. There are some pages (some parts of some pages) where orca is extremely slow. An example is at (http://www.traveline.org.uk), select the "East midlands" area and then select plan a journey. Navigate that page. At the section where you specify time and date of the journey, orca becomes really slow. You may also have noticed another bug on that page, for some reason Orca will not allow cursoring down beyond that first text box amongst the main navigation links, and only pressing tab will get you beyond it, and once beyond it you can continue to cursor down."
From Michael, where "that bug" is this bug: "Yes my example may fall under the topics in that bug, but I think there may be something else in there as well, as pressing tab to move between page elements also leads to a slow response around the time/date section of that page, so not just moving line by line as described in that bug report and what it seems to be trying to solve, although it may come down to the same reason (I just don't know enough of the internal workings of Orca to actually know). One thing I did notice in that bug report is something to do with combo boxes, that example I give does have two combo boxes with quite a number of items each on the same line, might this be part of the problem?"
traveline.org.uk is a heavily nested table page. I don't know if this is playing a role in the performance problem but I thought it is noteworthy.
Some interesting numbers: On traveline.org.uk I navigated strictly by using Tab and Enter to answer the question of "is this issue really line navigation?" Normal Orca: 1873878 function calls (1872229 primitive calls) in 116.359 CPU seconds Alternative Orca: 555087 function calls (554689 primitive calls) in 68.186 CPU seconds Focus-related event handling (Normal): ncalls tottime percall cumtime percall 107 0.005 0.000 28.138 0.263 Gecko.onFocus 115 0.007 0.000 28.021 0.244 orca.setLocusOfFocus 54 0.001 0.000 27.972 0.518 focus_tracking_presenter. locusOfFocusChanged 53 0.005 0.000 27.948 0.527 Gecko.locusOfFocusChanged 53 0.009 0.000 27.535 0.520 default.locusOfFocusChanged 84 0.002 0.000 27.252 0.324 default.onFocus Focus-related event handling (Alternative): ncalls tottime percall cumtime percall 109 0.006 0.000 5.489 0.050 Gecko.onFocus 117 0.007 0.000 5.386 0.046 orca.setLocusOfFocus 58 0.001 0.000 5.337 0.092 focus_tracking_presenter. locusOfFocusChanged 56 0.005 0.000 5.294 0.095 Gecko.locusOfFocusChanged 57 0.009 0.000 4.920 0.086 default.locusOfFocusChanged 91 0.002 0.000 4.822 0.053 default.onFocus Updating braille (Normal): ncalls tottime percall cumtime percall 68 0.040 0.001 26.306 0.387 Gecko.updateBraille Updating braille (Alternative): ncalls tottime percall cumtime percall 69 0.034 0.000 3.679 0.053 Gecko.updateBraille find{Next, Previous}CaretInOrder (Normal): ncalls tottime percall cumtime percall 7249/6334 0.263 0.000 12.636 0.002 findNextCaretInOrder 3096/2529 0.120 0.000 5.824 0.002 findPreviousCaretInOrder find{Next, Previous}CaretInOrder (Alternative): ncalls tottime percall cumtime percall 200/176 0.009 0.000 0.303 0.002 findNextCaretInOrder 37/32 0.002 0.000 0.055 0.002 findPreviousCaretInOrder And just a personal observation: When tabbing amongst the combo boxes without the patch, the delay was unbelievable. With the patch, there was a delay but not nearly as much of one. As a reminder, the patch I'm working on at the moment is strictly looking at making an efficient getLineContentsAtOffset(). Bugzilla's advanced form will still be bad I'm afraid. One problem at a time.... :-)
Created attachment 101253 [details] [review] The first "might be fit for human consumption" revision While I think we're still in "hard hat territory," I am pleased to utter the following words: Mike please test this. <smile> A couple of things worth noting: 1. I noticed that we've starting repeating lines that begin with a link that began on the previous line. Then I tried it without the patch and got the same thing. So yes there's a bug somewhere, but it's not this patch. I'll look into it. 2. You might notice some changes and think they are bugs when they are not. <smile> For instance, when you're filing a new bug you will now hear the reporter and the product on the same line. Similarly, you will now hear the version and component lists on the same line. These things *are* on the same line and we just haven't been treating them as such. I think this patch preserves much more of the spatial layout of a page. Of course, on the flip side, there's a healthy chance that I screwed something up, <grin> so feel free to give me a holler if you want a description of the layout of any given page that is being handled differently. Thanks!!
(In reply to comment #12) > Some interesting numbers: > On traveline.org.uk I navigated strictly by using Tab and Enter to answer the > question of "is this issue really line navigation?" I have just done some further tests of my own. If I use tab to enter the section regarding time/date of the journey on www.traveline.org.uk, there is a delay, but both the speech and brille make the information available together (or close enough for me as a human to know), where as if I use the cursor keys, I get a long delay and then the braille display shows the line, and then after a further delay the speech then speaks the line. I believe whilst the delay is possibly not all due to what this bug is trying to solve, there is certainly some relevance. > Normal Orca: > 1873878 function calls (1872229 primitive calls) in 116.359 CPU seconds > Alternative Orca: > 555087 function calls (554689 primitive calls) in 68.186 CPU seconds > Focus-related event handling (Normal): > ncalls tottime percall cumtime percall > 107 0.005 0.000 28.138 0.263 Gecko.onFocus > 115 0.007 0.000 28.021 0.244 orca.setLocusOfFocus > 54 0.001 0.000 27.972 0.518 focus_tracking_presenter. > locusOfFocusChanged > 53 0.005 0.000 27.948 0.527 Gecko.locusOfFocusChanged > 53 0.009 0.000 27.535 0.520 default.locusOfFocusChanged > 84 0.002 0.000 27.252 0.324 default.onFocus > Focus-related event handling (Alternative): > ncalls tottime percall cumtime percall > 109 0.006 0.000 5.489 0.050 Gecko.onFocus > 117 0.007 0.000 5.386 0.046 orca.setLocusOfFocus > 58 0.001 0.000 5.337 0.092 focus_tracking_presenter. > locusOfFocusChanged > 56 0.005 0.000 5.294 0.095 Gecko.locusOfFocusChanged > 57 0.009 0.000 4.920 0.086 default.locusOfFocusChanged > 91 0.002 0.000 4.822 0.053 default.onFocus > Updating braille (Normal): > ncalls tottime percall cumtime percall > 68 0.040 0.001 26.306 0.387 Gecko.updateBraille > Updating braille (Alternative): > ncalls tottime percall cumtime percall > 69 0.034 0.000 3.679 0.053 Gecko.updateBraille > find{Next, Previous}CaretInOrder (Normal): > ncalls tottime percall cumtime percall > 7249/6334 0.263 0.000 12.636 0.002 findNextCaretInOrder > 3096/2529 0.120 0.000 5.824 0.002 findPreviousCaretInOrder > find{Next, Previous}CaretInOrder (Alternative): > ncalls tottime percall cumtime percall > 200/176 0.009 0.000 0.303 0.002 findNextCaretInOrder > 37/32 0.002 0.000 0.055 0.002 findPreviousCaretInOrder > And just a personal observation: When tabbing amongst the combo boxes without > the patch, the delay was unbelievable. With the patch, there was a delay but > not nearly as much of one. As a reminder, the patch I'm working on at the > moment is strictly looking at making an efficient getLineContentsAtOffset(). > Bugzilla's advanced form will still be bad I'm afraid. One problem at a > time.... :-)
Michael, thanks so much for that additional information! It's a big, multi-faceted issue that we need to fully understand. Adding a note to self here: I added a hack and a comment about "bogusity" that needed to be sorted out. I just sorted it out. It's a Firefox bug. I just filed it here. https://bugzilla.mozilla.org/show_bug.cgi?id=409009. I'll update the comments, etc. accordingly in the next revision, after Mike tests.
I have just looked at the last patch submitted. Running this here and performing navigation of www.traveline.org.uk in both ways (cursor keys and tabbing only) reveals the following (as detectable by myself). In general the delay is much less for both. If tabbing, both speech and braille appear to respond at the same time, after a short delay. If using cursor keys, at the particular part which is bad (the time/date options) there is a slight delay still (no where as bad as before) and whilst braille shows the line first, it is now only just before speech starts. These observations are only as a human, and you probably would want to get some more accurate figures, but I would say that the patch is certainly improving things for the traveline case.
Woo hoo!! Michael Whapples, you just made my day. Thanks!! <smile>
I have to say, this patch has improved nearly every page I have tried. This is a mighty happy day in orca land.
Cool beans! Thanks Mike! So, Will, I'm going to create a new version that has better comments, is pylinted, and has been verified on the regression tests. Beyond that, do you think we should keep this setting in place or not? Rip out the existing code or not?
Created attachment 101275 [details] [review] Revsion 2 of the "real thang" I was just chatting with Will. We're going to leave the temporary performanceEnhancements setting in Gecko.py for now. I renamed a snarkily-named variable, removed debugging print statements, retested and pylinted. I still need to run some regression tests. However, that will require looking over things closely to see if changes are regressions or improvements (like reading a full line whereas before we were not). I didn't want to wait until all that was done for Will to review it -- 'tis a big change to the code.... Thanks Will!
I feel bad being the bringer of bad news, but since the patch, some pages which read fine before the patch, now don't seem to read correctly. The case I am referring to unfortunately I can only find on a restricted site (one which is part of some training material for a company I am training with, and is only accessible with a password), so I can't give you a link to it. I have tried to find a similar case somewhere I could freely give you a link, but I currently can't find one. To describe, it seems to be where there are some blanks on the line (they appear as dots 78 on my braille display) followed by a link. When this problem shows itself, only the blanks are shown. pressing down does not reveal the link, the only way to find the link is to cursor right. A similar case is where there is a row of links in a menu/selection bar, and for this only the first is spoken. As it is part of the same website, it could be the same problem. As I said this was not so before the patch. I can ask the company if I could copy the HTML source for a page where there is no actual information (purely a navigation page), otherwise I will need to hunt out another example, or try and examine the source myself and create my own example using the same style and see if I can cause the problem.
Michael, please don't feel bad. It's awesome that you're catching this stuff before the code has been checked in. We want to work out as many "kinks" as we can before it hits trunk -- and then be sure the rest are gone well before the final 2.22 release. I will see if I can create a sample based on your description, but if there's any way you can get me actual html (or a public example of the problem), that would be wonderful! Thanks again!!
I have just looked at the source myself, and have thoughts as to what html may be causing it. Question to myself, whether to use that source and just mangle the text so that the information which could be read does not resemble the original or that links won't possibly lead to anything I shouldn't point people to (whilst being syntactically the same), or to try and write a new example. Anyway this is a task for tomorrow.
Created attachment 101285 [details] [review] revision 3 Michael, in thinking about your description and doing some testing, I believe I found the same thing on Peter Korn's blog. For some reason he has empty anchors at the beginning of each title. Please give this version a spin. Mike if you could do the same. Thanks guys!
Created attachment 101286 [details] [review] Minor tweak to the last version I had forgotten that Firefox sometimes gives us all 0 extents for list items some times. *sigh*. This version checks for a 0 sized object that has screen coordinates. If it has coordinates but no size, remove it from our list of objects.
Created attachment 101289 [details] HTML where patch does not read properly as previous orca normally does This file contains two problems where the patch does not read correct. Firstly in the navigation menu, only the campus link is read where as the whole row was spoken, and the row where the link for take course is used to be entirely spoken.
Michael thanks so much for doing that. And the latest patch doesn't seem to solve it either as I can confirm exactly what you describe. I need to run out for a bit this evening, but then I'll see about fixing it. Keep those bug reports coming!! <smile>
Created attachment 101339 [details] [review] fix the bugs Michael pointed out plus one more This patch should fix the two bugs Michael pointed out. The process of figuring out the second issue he reported, caused a lightbulb to go off in my head about why we weren't picking up the the search form on live.gnome.org. Solved that here as well. Please test. Thanks everyone!
This patch is such a vast improvement over what we've had I'm infavor of it being checked in.
(In reply to comment #29) > This patch is such a vast improvement over what we've had I'm infavor of it > being checked in. > I think it looks pretty good as well, especially since it's been beat on pretty well I say commit. :-) Thanks!
Patch committed. Slapping a [testing required] on it rather than [pending]. It's a big change and there are likely other "special cases" that we hadn't thought of/run across yet. I'll post an announcement to the list.
And you're right to think that there might be cases where things don't work as they used to. OK it works for the two I previously pointed out, but there is another problem (which I thought before this would be the same sort of reason as the other two, obviously not). Unfortunately these look harder for me to get an example as it is again in a passwotf protected site and the contents seems to be in a frame, so I need to see the source for the frame (only if they had used SSI instead). If failing getting the actual source causing this, what tools are there which I could use to examine the page structure? (In reply to comment #31) > Patch committed. Slapping a [testing required] on it rather than [pending]. > It's a big change and there are likely other "special cases" that we hadn't > thought of/run across yet. I'll post an announcement to the list.
> an example as it is again in a passwotf protected site and the contents seems > to be in a frame, I wonder if the problem is the frame itself rather than what is inside of the frame. Do you have access to the source of the page that contains the frame, or is it something being generated by javascript? If the former, could you create a simple example where the main page has that structure and the page in the frame is another simple page, or a page we know to be accessible like the Orca wiki? > used SSI instead). If failing getting the actual source causing this, what > tools are there which I could use to examine the page structure? Firefox's DOM inspector seems to be pretty accessible. But I don't know if it descends frames or not. I'll have to create some test cases on my end and see. And also see if Orca ignores the frame contents. <smile> If you have access to the source, you might be able to find out what the URL of the page inside the frame is. If so, you could load that URL to see the embedded contents. Hope this helps. And at the risk of repeating myself, thank you so much for your work on this Michael!!
(In reply to comment #33) > > an example as it is again in a passwotf protected site and the contents seems > > to be in a frame, > I wonder if the problem is the frame itself rather than what is inside of the > frame. I don't think that it is the frame itself. Reasons are that the whole page is made up of frames (including a menu system, in fact the same one as in the other example) and it reads that frame fine, and orca before the patch read it fine. Do you have access to the source of the page that contains the frame, > or is it something being generated by javascript? If the former, could you > create a simple example where the main page has that structure and the page in > the frame is another simple page, or a page we know to be accessible like the > Orca wiki? Unfortunately the contents is made up from a java script file (.jsp) according to viewing the page source in the src attribute for the frame. > > used SSI instead). If failing getting the actual source causing this, what > > tools are there which I could use to examine the page structure? > Firefox's DOM inspector seems to be pretty accessible. But I don't know if it > descends frames or not. I'll have to create some test cases on my end and see. > And also see if Orca ignores the frame contents. <smile> If you have access I will try the DOM inspector. > to the source, you might be able to find out what the URL of the page inside > the frame is. If so, you could load that URL to see the embedded contents. > Hope this helps. And at the risk of repeating myself, thank you so much for > your work on this Michael!! Unfortunately the src attribute for the frame is relative for their server (eg. of the form src=/frameContentFile.jsp?options=values). Only if browsers had a way to view source as it would be when actually producing the output, like viewing source of SSI pages is.
Created attachment 101430 [details] [review] We can't assume the parent of a table cell is the table Patch committed. Michael, when you get a chance please see if this solves your latest bug. Thanks!!
The latest patch exposes a crash in Firefox, tracked in Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=409439.
Created attachment 101440 [details] [review] Don't tick off Firefox 3. <grin> I saw what we were doing to make Firefox so unhappy. Marco, thanks for prodding me on this one. This version should solve the most recent problem Michael reported and also not crash Firefox. <smile> Please keep testing! And thanks! (patch is already committed to trunk)
(In reply to comment #37) Has solved the particular issue we were trying to solve, but I got some other problems now. In attachment http://bugzilla.gnome.org/attachment.cgi?id=101289 I have noticed when pressing up arrow not all these lines are read fully. Cursor below the "sql plus" line, now cursor up, you would expect the same output, I get "l plus". There was another problem I found at the actual website where this came from, but can't replicate it in this attachment, what's going on as these are the same structurally. To describe, it seemed like pressing down was moving through the cells of the row, but reading the line. > Created an attachment (id=101440) [edit] > Don't tick off Firefox 3. <grin> > I saw what we were doing to make Firefox so unhappy. Marco, thanks for > prodding me on this one. > This version should solve the most recent problem Michael reported and also not > crash Firefox. <smile> > Please keep testing! And thanks! > (patch is already committed to trunk)
Created attachment 101442 [details] [review] handle more table bogusity We have just reached the point where my brain cannot remember all of the special cases. <smile> So after I look at Michael's most recent report, I'm going to pause briefly to write some regression tests that I can run to see the impact of any further changes. This patch is already committed to trunk.
Michael, I cannot reproduce your "l plus" error. Sorry, I'll keep an eye out for it. As for your observation on the second bug: If a table cell has line breaks in it, our current caret navigation model will not treat the entire row as a line, but rather stop at the line break before moving on. (Revamping caret navigation is next on my list -- after writing regression tests). Our brand-new line-reading functionality (this bug) does it's darnedest to report the full line contents. As a result, until I get the new caret navigation stuff done, if you come across a table with line breaks in it, you'll get the behavior you reported. Sorry!!! Have you tried reading such a table using the table navigation commands instead (Alt + Shift + Arrows)? Thanks!
Puzzled more, I am getting different results for what are structually the same file. If I use attachment http://bugzilla.gnome.org/attachment.cgi?id=101289 from a local file, I get a problem where the text is truncated when I cursor up (instead of "sql plus" I get "l plus"), if I view it directly online, I get no problems and if I go back to the website where I found the problems initially which was why I created attachment http://bugzilla.gnome.org/attachment.cgi?id=101289 I get Orca moving cell by cell in a row when pressing up or down cursor and when cursoring up I get truncation of text (worse than for the local file eg. instead of "sql plus" I get "s"). This using trunk r3402.
(In reply to comment #40) > Michael, I cannot reproduce your "l plus" error. Sorry, I'll keep an eye out > for it. Have you tried it in a local file? See my other comments regarding differences in when these bugs show. > As for your observation on the second bug: > If a table cell has line breaks in it, our current caret navigation model will > not treat the entire row as a line, but rather stop at the line break before > moving on. (Revamping caret navigation is next on my list -- after writing > regression tests). Our brand-new line-reading functionality (this bug) does > it's darnedest to report the full line contents. As a result, until I get the > new caret navigation stuff done, if you come across a table with line breaks in > it, you'll get the behavior you reported. Sorry!!! I will describe this further. It is in the menu system of the page (the bit where you have the "cmpus" link, "classroom" link, etc), at the actual website only (unfortunately) but the structure I thought was the same in http://bugzilla.gnome.org/attachment.cgi?id=101289, and previously Orca treated it as one line until trunk r3401. Also orca reads the whole row when you move to it, but when you press down cursor it finds itself in the next cell and speaks the whole row again. > Have you tried reading such a table using the table navigation commands instead > (Alt + Shift + Arrows)? No, as it previously wasn't needed until trunk r3401. > Thanks!
I'm at a loss. For me, both online and local Orca, both up and down, Orca is reading each line as a line and not getting stuck on any cells. I'll try going back to revision 3400 and re-approaching the problems differently and see if that makes any difference.
(In reply to comment #43) I'm sorry about this, http://bugzilla.gnome.org/attachment.cgi?id=101289 now seems to be fine for me. I still seem to be getting problems at the actual website where I first found the problems which lead to that attachment. What's the difference? Is there a bit of it where it uses css? Would css mke a difference? If yes then the css file isn't available here on locally, but it will be at the website. May be a get of source via DOM inspector again. > I'm at a loss. For me, both online and local Orca, both up and down, Orca is > reading each line as a line and not getting stuck on any cells. I'll try going > back to revision 3400 and re-approaching the problems differently and see if > that makes any difference.
> I'm sorry about this, http://bugzilla.gnome.org/attachment.cgi?id=101289 now > seems to be fine for me. Phew! <smile> > I still seem to be getting problems at the actual > website where I first found the problems which lead to that attachment. What's > the difference? Is there a bit of it where it uses css? Would css mke a > difference? CSS can make a huge difference, actually. There are some styles that totally break caret navigation for instance. If you do a save as of the page, you should also get the CSS files. It could also be that the site is dynamically loading content that is not getting loaded in saved version.
Created attachment 101446 [details] A slightly modified version of the problem html for orca This has not really had any changes other than to make it suitable for local viewing with the css file I will post. This and the css file should cause the moving along a row cell by cell when pressing down or up cursor.
Created attachment 101447 [details] The problem css This is the css for attachment #101446 [details]. Download both files and place this in the same directory as attachment #101446 [details] and rename this css file to campus.css. Hopefully when you read the menu/navigation links now the cursor will move between cells of the row whilst reading the rest of the row (ie. it reads the whole row for the first cell).
Thanks Michael! While you were doing that, I was getting to the bottom of your travel site's form fields. Guess what? It's a CSS problem. <smile> Mozilla bug filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=409497
Michael, I just downloaded your two files as you described. Things are still working for me: It reads that initial row of links as a single row. If I down arrow, I find one or more links based on which of the four top links I pressed Enter on or hovered the mouse over. Orca is reading those correctly for me as well. I build Firefox from source and I haven't built it in the past couple of days. So I'm going to start a build now and call it an evening. In the meantime, if you wouldn't mind attaching a full debug.out to this bug that would be awesome. In your ~/.orca/user-settings.py file, uncomment the following three lines by removing the initial # characters: orca.debug.debugLevel = orca.debug.LEVEL_ALL orca.debug.eventDebugLevel = orca.debug.LEVEL_OFF orca.debug.debugFile = open(time.strftime('debug-%Y-%m-%d-%H:%M:%S.out'), 'w', 0) Startup Orca and Firefox again, and reproduce the problem. Then quit Orca. Relaunch it, comment the lines back. Having done the above, you should find a couple of files in your home directory (or wherever you launched Orca from if you manually launch it) that begin with "debug" end with ".out" and have a time stamp in between. I need the first one. Hopefully that will shed some light on things. Thanks!!
Michael sent me a debug.out via email (Thanks!!). And with the latest build of FF3, I can also reproduce the problem. Funny what a difference two days makes. Anyhoo... I can also reproduce the problem with revision 3400 although we speak less with that revision because of some bugs I've since fixed. Looking at the screen, here's what's going on: Before when the user pressed down arrow, we moved to the next line immediately; now we move to the end of the table cell but stay on the same line. In other words, something in Firefox has changed and whatever that something is, it's effecting where we land when we arrow. All of the changes made in the patches for this bug have nothing whatsoever to do with our caret navigation. They're all about what we should speak and braille once our caret navigation has done it's thing and moved us to the new location. The reason we're seeing a difference with the "performance enhancements" is because the performance enhancements cause us to obtain the contents of the current line far more accurately than we were doing before. Without performance enhancements, we're only reading the current cell. (All those cells are on the same line btw) So.... We need to update Orca's caret navigation to handle this new situation. Making find{Next,Previous}Line more performant is next on my agenda (after writing regression tests for the new getLineContentsAtOffset()). I will look into this problem in conjunction with that.
The one accessibility fix that got into Firefox 3 with Thursday's nightly build is the fix for this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=405248. This has to do with missing spaces between two links.
I'm trying to write regression tests and keep arrowing to spaces at the end of lines that I wasn't finding before. Maybe I'll see about fixing this issue first so that I don't have to re-write a bunch of regression tests in a few days.... :-)
Okay, I've just opened a bug and attached a patch for the new space at the end of the line: http://bugzilla.gnome.org/show_bug.cgi?id=505102 Michael, that stops the problem of getting stuck on cells for me, mind giving it a spin? (Note that the patch has *not* been checked into trunk. When I mess with our caret navigation, I like lots of testing and Will to review first.) Thanks!
Created attachment 101486 [details] [review] hopefully solve Michael's truncation problem; also the space issue from 505102 Michael, I hope this will solve the truncation problem you reported. Please let me know. (This patch has already been committed to trunk.) Note that the fix for the caret navigation problem introduced by recent Firefox builds (i.e. bug 505102) has *not* been checked in. I'll create a new trunk-compatible patch momentarily.
Mike and I are on the phone. In Thunderbird, when reading a bugzilla message, we are speaking the space the precedes the URL. I need to look into that.
Created attachment 101691 [details] [review] handle the thunderbird issue Mike, this solves the problem for me. It's also pylinted and regression tested. Mind giving it a spin before I check it in? Thanks!
Works great! thanks much
Thanks Mike. Patch committed.
Created attachment 101762 [details] [review] yet another tweak While working on performance enhancements for caret navigation, I discovered a slight change I need to make here. It's regression tested and pylinted, but Mike if you wouldn't mind taking it for a spin before I check it in, that would be awesome. Thanks!
Scratch the previous request. It doesn't do what I want it to do 100% of the time. And some times it does something I don't want it to do. Sorry! I'll find a different work-around.
Created attachment 101926 [details] [review] yet another tweak I discovered that an object can implement the text interface and contain a lone space. We don't want to do our "space" trimming in that case. Patch pylinted, regression tested, committed.
Created attachment 102420 [details] [review] proposed addition/change Currently our new method for obtaining the line contents starts with the current object and offset and moves forward. The attached changes (should) cause it to get the full line contents period. I need this functionality in order to implement some other performance enhancements. Pylinted and regression tested, but I'd like some additional testing. Thanks.
So far I haven't seen any new problems related to this patch. I'd say check it in and we'll keep testing.
Created attachment 102441 [details] [review] revision number .... I've lost count ;-) This patch contains the changes from the previous patch along with a couple of others which should help ensure that we only read the full line when it truly makes sense to do so. Cases were it does not make sense include: * Table cells where the text in one or more cells in the row spans multiple lines * Sections which have been placed side by side via CSS * Panels Mike if you could test this to be sure it does not introduce any regressions, that would be great. Based on my testing, it should serve as a solid basis from which I can easily implement a decent fix for bug 506360 (which will cause the double-speaking of lines to go away in addition to improving performance). Thanks!!
Created attachment 102448 [details] [review] slightly more defensive version to deal with FF bug
Created attachment 102490 [details] [review] revision next Seems I need to add some SayAll regression tests. From actual usage I found a regression from the last patch. This patch fixes the regression and doesn't seem to introduce any new ones.
I just tested this patch after giving the previous one several hours of testing. I can't find any new problems. Looks great to me.
The remainder of the work and tweaks related to line navigation performance are being made in bug #506360. Therefore, I'm closing this one out as FIXED.