GNOME Bugzilla – Bug 554831
Google calendar unusable with orca
Last modified: 2008-11-13 22:31:44 UTC
Please describe the problem: When using google calendar with orca in firefox, orca tends to repeat information (not allowing to arrow down keeping reading the same information for exampple) and sometimes even crashing orca itself, when reading controls like the calendar view. Steps to reproduce: 1. Using firefox 3, Go to http://www.google.com/calendar and login to a existing google account 2. Arrow down through the page and find a line with the current week dates (if orca keeps repeating same lines use tab to navigate to the next controls). 3. Arrow down one more time and orca should speak "00:00". 4. Now try arrowing up and down, orca should become slow or even crash making the desktop unusable. Actual results: Orca becomes slow, using much CPU and turning even the desktop unusable until going out of firefox or restarting orca. Expected results: Orca reading the calendar don't crashing! Does this happen every time? The slowness heappens evrytime. Other information:
I can confirm at least one instance of a hang. :-( Targetting for 2.24.1
Created attachment 119993 [details] [review] Part 1: Just stop the hang Looking at this bug, there seem to be two issues which fall under the category of "Google calendar unusable with orca": 1. Giving focus to the focusable table results in a hang. 2. We don't provide access to the contents of the calendar well (month grid) or at all (day, week grid). The latter is extremely unfortunate and something we definitely need to work out, and soon. It may be related to the Thai menu bug and something else I noticed, which boils down to: We don't always navigate successfully into sections which are nested in other objects, like tables. The former is what makes this bug "critical". Who knows where we might find a focusable table? We shouldn't hang. Period. This patch is designed strictly to stop the hang, which seems to be caused by findNextCaretInOrder() returning the table each time it tries to find the next caret in order for a table. As a happy side effect, there are a couple of headings at level 2 (My calendar and other calendar) which we weren't speaking upon focus before, but are speaking now. What this patch does *not* do is make any attempts whatsoever at making Google calendar actually usable. You'll Tab and/or Arrow, you'll not be able to access the calendar grid, you'll curse my name, but you'll be able to Tab around and navigate to other pages, and continue to access your computer. <smile> I will continue to work on the broader access issue of this bug. In the meantime, please test to see if this patch stops the hang (if we're silent, press Tab and see if we start speaking again), and that it doesn't break anything else. Thanks!
Hi, I confirm orca doesn't crash with this patch applied, with some patience I can read the cock times in the day view (00:00, 00:30). Thanks!
> I confirm orca doesn't crash with this patch applied, with some patience I can > read the cock times in the day view (00:00, 00:30). Thanks! Thanks Rui! And I'm definitely working on the the other issues you point out. Being able to access Google calendar in an efficient and timely fashion is a must-have. This patch was just the "oh my goodness, we're hanging!" interim fix. Given that this patch changes a couple of fundamental methods in the Gecko script, it should probably be tested a bit more across the board in Firefox before I check it in. Rui if you have the time to do so, that would be awesome. Mike and Jon, can I ask you to also beat on this patch?
(In reply to comment #4) > > Given that this patch changes a couple of fundamental methods in the Gecko > script, it should probably be tested a bit more across the board in Firefox > before I check it in. Rui if you have the time to do so, that would be awesome. > Mike and Jon, can I ask you to also beat on this patch? > Is there any specific tests I should perform? or just navigating around and try to find some kind of regressions?
I've been testing this patch all morning and haven't seen any ill side effects. I'll keep testting though.
> > Is there any specific tests I should perform? or just navigating around and try > to find some kind of regressions? > Joanie runs the regression tests after she creats a patch so just testing with your day to day work should be good.
I think this one seems safe to commit.
Created attachment 120250 [details] [review] Ever-so-slight tweak to Part 1 In doing some functional testing I discovered that if a line began with a link and that link began on the previous line and the next line was blank, this patch would cause us to repeat the line in question before moving to the blank line. My kingdom for a single, silver bullet, universal regression test.... Anyhoo, the only difference between this patch and the version y'all tested is this: Original patch: Block of code executed if the focus event is for an object within the document and we're not in an ARIA widget. This patch: Block of code executed if the focus event is for an *non-link* object within the document and we're not in an ARIA widget. Current Orca: Block of code doesn't exist. ;-) So the change between patches is conservative. Pylinted, re-regression tested, re-functionally tested. Passes everything and still stops the hang. Therefore, committed to trunk.
I took a look at the definitions of severity and priority according to GNOME. Based on those definitions and the fact that the hang seems to be taken care of, I am lowering the severity to normal because looking at Orca taken as a whole, Google Calendar access is a "minor part of the component." But I am raising the priority from normal to high because there is *not* a fairly straightforward workaround and functionality *is* very important and undoubtedly *would be* frequently used were it working. :-)
Created attachment 122329 [details] [review] provide access to the Day grid This patch makes it possible to arrow into the Day grid. Pylinted, regression tested, please test. Note that the way the Google Calendar guys structured this grid is to put all of the times (12 am, 1 am, 2 am, etc) in sections (within sections) in one table cell. Then they put actual appointments (12pm - 1pm Lunch) in sections in another table cell. As a result, arrowing takes you through all of the times first and then to all of the appointments. We have no programmatic way of identifying that such a structure should be read from left to right (i.e. if we changed the Gecko toolkit's script to handle this grid, we'd undoubtedly break access to a bunch of other sites). This is really a job for per-URL scripting (bug 404422). As a related aside, I was curious to see if JAWS handled the Day grid differently. At least in version 9, you also hit all of the times first (although JAWS treats them as if they are all on a single line, which they're not) and then you hit the appointments.
Hi, I confirm that at least all day apointments are now anounced by Orca, before clock times. I can also click in those events and read their details.
Thanks Rui. Patch committed to trunk. After it gets more testing, we can commit it to the gnome-2-24 branch as well.
I'm seeing no problems related to this patch. As it helps with google I'd say it should go into 2.24.2 as well.
Thanks Mike. Patch committed to the gnome-2-24 branch. Closing as FIXED.