GNOME Bugzilla – Bug 750088
Clearing the cache is needed to enable navigation in dynamic web pages
Last modified: 2015-09-04 15:12:47 UTC
Created attachment 304218 [details] A full debug.out file this interesting issue related Dear Joanie, I yesterday wrote an issue in Orca list, some time possible grab the caret navigation and structural navigation content with the focused webpage content. An example website is the www.edigital.hu website. Testcase: 1. Launch firefox. 2. Open the www.edigital.hu website. 3. Press CTRL+F keystroke, type extre characters and press the escape keystroke. 4. Open the focused link. 5. Press c keystroke, press two tab keys and try scrolling the content with down arrow key. Usual the page scrolling works good this website, but when I captured the full debug.out file, the caret grab the "kosárba" labelled push button. If I try doing some up arrow key press and down arrow key press, after Orca speaks and presents the "kosárba" push button again, the caret not moved down with remaining part. The interesting remaining part in the debug file beginning after the 31908 line when Orca first time speaks and presents braille the "kosárba" push button. I have possibility only this day and saturday to test bug fixes, between sunday and june 15TH I will not near internet connection. Attila
See what I stated in bug 751523 comment 2, and please let me know if you still see this problem in master. Thanks!
Hi Joanie, Me with edigital.hu website related the testcase now doesn't reproducable. Until monday if not problem I leave this bug status with needinfo state. Attila
Hi Joanie, Now, when I opened http://vs.hu website, the website generating more refreshing before page loads is finished. Because too early I begin using the structural navigation keys before Orca says the download is finished, the caret grabbed, and Orca begin producing the similar issue with you solved when download is finished. This situation when download is finished you clear the cache. If I tryed reproducing this type testing with a debug.out file, Orca of course not produced this issue, because happened an Orca restart, and the cache of course cleared. What happening if you clear the cache when a new download is beginning (for example when happening a page redirection or a refresh, or an user opening a new webpage)? Some time webpages want loading more resources (Google ads, external resources, etc), so this is possible not a good solution. This is decreasing the performance drastical? Some time I experienced in Bugzilla this caret grabbing related problem, but normal bug reading related. Fortunately this issue is more fewer time happening since you clearing the page cache when the download is finished. I using simple with arrow keys this situation, but possible not enough careful and not wayt the download is real finished. This situation the ALT+TAB keystroke helps too. The good news: Since you doed this cache clear related fix when download is finished, my experience now possible using master branch Orca version more hours with web browsing without this issue happening. Usual this issue some time happening when a webpage want loading more resources. This situation some time the text content already accessible with Orca, but the download real not finished yet. When an Orca user begin using normal arrow keys this situation or structural navigation keys, have chance this issue will happening, but very difficult to reproduce this partial issue. Attila
Could you give me concrete steps to reproduce the issue on vs.hu? I cannot read Hungarian visually; so trying to understand where I am non-visually by listening to eSpeak is pretty much impossible for me. Sorry about that! But when you give me very concrete steps so I know what to look and listen for, things tend to work better. BTW, thank you for your English. <smiles>
Created attachment 308115 [details] A debug.out file with hopeful shows the vs.hu page related issue Hi Joanie, I attaching a full debug.out file with vs.hu page related. After I wrote the vs.hu URL address and pressed the enter key, I simple begin press more the h keystroke until the download is not finished. When I doed this extreme test, I have possibility to read the caret content after I pressed the TAB key when the download is finished. Entire loading related informations begin the debug.out file after I think the 8660 line. The first keyboard event processing beginning in the debug.out file the 9164TH line. The debug.out file have more traceback error messages (gi._glib.GError: The process appears to be hung exceptions), the first error message present the debug.out file the 11323TH line. In the debug.out file I see an interesting message the 11609th line: "WEB: Updating loading state and resetting live regions ERROR: Could not process document:load-complete" Hopeful will you see some good informations with future cache handling related (what other situations you need clearing the cache). Now, I think you clear the cache when the download is finished. Yes, with english is not my primary language, some time I using wrong grammatic sentences. If you sending private what my mistake and what the correct sentence, I will careful this future. but I understanding your smiley after previous comment. :-):-) Attila
So I tried pressing h a bunch of times immediately after pressing return after typing vs.hu in the address bar. Even though the page had not finished loading, I was able to navigate to all the headings and wrap to the top. No tracebacks. No stuck caret. Having said that.... Looking at your debug.out, I don't think clearing Orca's cache will help. The error message about the process appears to be hung comes from AT-SPI2 and it means the application (in this case Firefox) is not responding to AT-SPI2. It has nothing to do with Orca's cache of objects. So.... If you can get me steps to reproduce the problem which I can use to make the problem happen on my machine, that would be great. Otherwise, I'm not sure what I can do to fix it for you.
Sorry to be spammy. But if, when the problem you're seeing on vs.hu happens, you can fix it by Alt+Tabbing into and out of Firefox, then clearing Orca's cache may help. If Alt+Tab doesn't fix it, then clearing Orca's cache won't help.
Attila: The tracebacks in your debug.out should be gone. I hope that handling the error will fix the bug too. Could you please test and let me know? Thanks!
See for bug 751523 report last comment, now more better with Orca web usage I think. Four hour continuous Orca usage this type issue happened only two time, both two situations the window switch and switch back to firefox resolve this issue. I think this problem is a mistific issue. Possible better to close now this reports, and if we lucky and happening this issue again a default awailable debug session, we see what possible doing. But, if four hour continuous Orca usage happening only two time this issue, continuous debug session resulting a very large debug file. I have an ydea, what do you think: Possible happening this type issues because I using Ubuntu 14.04 with At-spi2 3.14 series? I think with at-spi2 future 3.18 version containing some object caching related changes (tree views absolute sure). When you not succesfully reproduced this type issues, what at-spi2, ATK and at-spi2-core components using, and used Noscript and Adblock popup blockers? Me very suspicious in Orca lists more fever time reports Orca users this type issues, so possible my system need updating the proper components to we equals components version testing this issue. Attila
Created attachment 310301 [details] Again happened this issue when Orca lands the "regszám kereső" string Hi Joanie, Now my system latest uptodated Orca version again happened this issue a webpage content when the caret lands the "Regszám kereső" string. Testcase: 1. Launch Firefox. 2. Open following website: http://www.oc.hu/ingatlan/H280443 3. Press CTRL+F keystroke, type mecseki text, and press ESCAPE key. 4. Use simple the down arrow keystroke. Me some time the caret grabs the "regszám kereső" label, or the +1 related clickable element or another clickable elements. This situation when I created the full debug.out file the caret grabs the Regszám kereső label, and the caret not scrolled down the edit box above the label. When I switch a window and switch back with Firefox, the issue is resolved. The interesting part beginning possible in the debug.out file after the 6819 line. My debug.out file what showing before I doing the window switch when trying scrolling the grabbed content? I using at-spi2 and ATK 2.14 series, Firefox 40.0 and Orca latest master branch version, Noscript and Adblock popup blockers. Attila
*** Bug 751523 has been marked as a duplicate of this bug. ***
Ok, I'll look at your latest debug.out on Monday. Clearing the NEEDINFO. BTW, if you could go through the other NEEDINFO bugs you have filed and see if they are fixed, that would be great. Thanks!
Ok, I will looking you wrote reports next week absolute sure. Attila
I was able to reproduce the +1 issue and fixed that. Only one time so far have I been able to reproduce the entry issue, but I'll try some more. In the meantime, hopefully the fix I committed will make life generally better.
Ok, I *think* I've figured out a way to solve it. It works for me, anyway. If you look in your debug.out you'll see: vvvvv PROCESS <ENUM ATSPI_KEY_PRESSED_EVENT OF TYPE ATSPIEVENTTYPE> 'Down' (116) vvvvv WEB: Current context is: [list item | Regszám. kereső], 0 WEB: Line contents for [list item | Regszám. kereső], 0: [[<Accessible object at 0x7fa9c66df1f8 (AtspiAccessible at 0x26f6620)>, 0, 15, 'Regszám. kereső']] WEB: Last context on line is: [list item | Regszám. kereső], 14 WEB: Next context is: None, -1 WEB: Could not get line contents for None, -1 TOTAL PROCESSING TIME: 0.0084 ^^^^^ PROCESS <ENUM ATSPI_KEY_PRESSED_EVENT OF TYPE ATSPIEVENTTYPE> 'Down' (116) ^^^^^ So Orca tried to get the next line after the "Regszám. kereső" list item, but couldn't as a result, things stopped. Now when that happens, Orca will clear the cache and try one more time. Here's an example in which I got stuck: vvvvv PROCESS <ENUM ATSPI_KEY_PRESSED_EVENT OF TYPE ATSPIEVENTTYPE> 'Down' (116) vvvvv WEB: Current context is: [list item | Ossza meg másokkal!], 0 WEB: Line contents for [list item | Ossza meg másokkal!], 0: [[<Accessible object at 0x7fe5c43befc0 (AtspiAccessible at 0x55a58bd3a4a0)>, 0, 19, 'Ossza meg másokkal!']] WEB: Last context on line is: [list item | Ossza meg másokkal!], 18 WEB: Next context is: None, -1. Trying again. WEB: cleaning up cached objects WEB: Next context is: [link | E-mail], 0 (after this is a ton of debugging output in which Orca gets the full line with all those social networking links and then speaks that line). So, like I said, I think I have *finally* solved it. Please let me know. Thanks!!
Joanie, with last testcase related fix works perfect. Possible we you yesterday founded entire why happened previous this type issues, because previous some social networks related links Orca not speaks and present braille this website. I need little time to detailed testing the new change. If this type issue not happening again, I will closing happy this issue with friday afternoon. Thank you the committed fix, Attila
Created attachment 310603 [details] Debug file with Storm reported issue related Hi Joanie, Storm founded again this bug related issue, he wrote Orca-list with following: "Howdy, On this page: http://eyes-free.blogspot.com/ When it finishes loading, if you press down arrow to read through the stuff, it reads the line that starts with: "go to blogger.com, search ..." over and over." I succesfully reproduced this issue without Noscript and Adblock extensions, but I need doed more refresh cicle. Fortunatelly my Orca running this test cicle now with full debug level. My attached debug file the interesting part beginning after the 19651 line. Look between the 19721 and 19726 lines, 19763 and 19770 lines. Orca two time not succesfully found the next line content and trying cleaning the cache I think, possible without popup and unwanted script blocker extensions this webpage loading little slower. What possible doing this situation? Attila
This is a completely different issue and will require a completely different fix. Are there any other cache-clearing related issues?
No, feel free you close this bug with resolved, fixed state. Thank you the monday committed fix, and sorry to I yesterday missunderstand Storm reported issue when tryed looking the last attached debug.out file the cache cleanup related parts. Attila
No problem. And I'll still fix the issue Storm reported. :) Thanks!