GNOME Bugzilla – Bug 410101
Firefox save document POR problem (doc frame to chrome)
Last modified: 2011-07-06 06:41:30 UTC
I don't know if something changed in Firefox or this case slipped through, but the POR is not being saved when tabbing from a page with focus within doc frame to a page with focus in the chrome.
There are still two cases which have no solutions yet: 1. Application switching when Firefox is not on the first tab. This happens when there is not a control in focus on the document frame that is becoming visible resulting in Firefox not firing a focus event. This situation can be resolved with only a view event but is much too inefficient. This case may be fixed or will certainly be easier to fix when http://bugzilla.mozilla.org/show_bug.cgi?id=371045 is resolved. 2. Tab switching from doc frame to chrome in focus. This problem is caused by the pointer being moved to the chrome element before being saved in the focus lost event. The goal here is to figure out what is moving the pointer before the focus lost event and try to work around it.
Case #2 (see comment #1) is fixed and checked into repository. Fixed involved caching pointer in a CaretEvent. This was necessary because caret events were moving the pointer before the focus event RememberDocumentPOR was fired.
The use of relations to find the active doc frame was introduced in bug #412260. This new technique for finding the active document frame greatly increases performance so it makes sense to utilize here. Both the View and Focus tasks concerning the saved POR code now take advantage of this new code in there executeGained method. It cannot be used in the executeLost code because the relation has already changed to the new document frame. The code has been greatly simplified and is more responsive, but the following problem still exists: Tab switching to a page with the chrome in focus does not restore the saved POR. Instead, focus is placed on the chrome element (often url bar). This is due to only receiving focus events with PORs outside the document frame, thus not restoring the saved POR with the current code. This case is a balancing act with menu selection, which also receives focus events outside the document frame and the need to announce the focus event in BasicSpeechPerk.HandleFocus.
New version checked into repository. Only problem is scenerio 24. http://live.gnome.org/LSR/RestorePOR. Here, Firefox does not trigger a focus event if setAccFocus(doc frame) has been called. Keep an eye on the Firefox bug listed in comment #1.
About to become unblocked. We should plan to land a final version of this feature in 0.5.2 in about a month or so. After that, our restore/save logic should be solid. Any regressions in what events we are seeing should be considered bugs in Firefox at that point.
Fixed most restore scenerios. There are still two cases where restoration does not occur: 1. Tab browsing from a page with focus in the chrome to another page with focus in the chrome. The focus will be on the URL bar in most cases. However, if both pages have focus on the same accessible there will be no focus event triggered. 2. Menu selection when focus is in the chrome. The logic differentiates tab/tab-shift events from tab browsing events for all focus events. Menu selection is interpreted as a tab/tab-shift event in the logic because the user never leaves the current active doc frame. The problem is that you don't want to restore a saved por on all tab/tab-shift events. I was able to further separate tab/tab-shift events based on the location of the previous POR in focus to the location of the current POR. This allowed me to save on menu selections when focus is within the doc frame, however this case is still not acted upon.
Case 2 from comment #6 should be fixed with the following Firefox bug is fixed. https://bugzilla.mozilla.org/show_bug.cgi?id=363214 . Committed to repository.
Now restoring only when focus is within doc frame. Check into repository.
monitor Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=382007
Comment #9 refers to the case where focus is in an multiline entry and the user switches tabs. In this case an extra focus(doc frame) on previous page occurs which causes the saving part of the routine to save the wrong POR. Bug push back to 0.5.4.
lsr (Linux Screen reader) development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.