When fixing, also handle the bug where the document POR is not properly saved when menu items are activated, deactivated, and the focus returns elsewhere in the document.

Most user interaction with Firefox is through the review keys to browse through the text on a web page document. While the user is reviewing using the pointer, the application focus/caret remains fixed somewhere else in the app. 

For instance, when a new document loads the document frame gets focus. The user then begins to review the document. While reviewing, though, the application focus still remains on the document frame, not on the text the user is reviewing.

A problem arises when the user is in the middle of a review and either 1) activates a menu (e.g. Alt-F) or 2) switches away to another application (e.g. Alt-Tab). When the user closes the menu or returns to Firefox, the browser fires a focus change event *on the element that had application focus beforehand.* In the example above, this means focus returns to the document frame. When the user starts reviewing again, he's back at the beginning of the web page!

This situation is clearly unacceptable. The solution to this problem is to have FirefoxPerk try to cache the pointer POR and restore it when Firefox regains the view or a "floater" (e.g. menu) is deactivated. This is the current approach used in the Perk. Handling of floaters was never implemented. Restoring after Firefox regains the view was working, but now appears to be broken. Throwing away old PORs to closed or refreshed documents was also never implemented.

Works for menu, tab and application switching.  Bug report should remain incomplete until https://bugzilla.mozilla.org/show_bug.cgi?id=368322 is resolved.

Focus and view events in Firefox:

Tabbing: focus(doc frame), if manip is focused: focus(manip) .
Menu: if manip is focused: focus(manip) else: focus(doc frame)
App: View(frame), focus(doc frame), if manip is focused: focus(manip) .

Corrected Focus and view events in Firefox:

Tabbing: focus(doc frame), if manip is focused: focus(manip) .
Menu: if manip is focused: focus(manip) else: focus(doc frame)
App: View(frame), if manip is focused: focus(doc frame), focus(manip).

Focus and view events in Firefox:

Tabbing: focus(doc frame), if manip is focused: focus(manip) .
Menu: if manip is focused: focus(manip) else: focus(doc frame)
App: View(frame), if manip is focused: focus(doc frame), focus(manip).

From chrome element (address bar is entry element):
Tabbing: if manip is focused: focus(doc frame), focus(manip) else: focus(entry)
Menu:  focus(entry)
App: view

Firefox focus events

tab chrome to chrome: focus(new element)
tab chrome to doc frame: focus(doc frame) 
tab chrome to in-page: focus(new element)
tab in-page to in-page: focus(new element)
tab in-page to doc frame (bottom going forward): focus(document frame), focus(frame), focus(addressbar)
tab in-page to doc frame (top going backward): focus(document frame)
tab in-page to chrome: focus(frame), focus(entry)
tab doc frame to chrome: focus(frame), focus(document frame)
tab doc frame to in-page: focus(new element)

tab chrome to menu: focus(menu), focus(menu item)
tab in-page to menu: focus(menu), focus(menu item)
tab doc frame to menu: focus(menu), focus(menu item)
tab menu to chrome: focus(chrome element)
tab menu to in-page: focus(in-page element)
tab menu to doc frame: focus(document frame)

change view to chrome: view event only.
change view to doc frame: view event only.
change view to in-page: focus(document frame), focus(in-page element)

Checked into repository with the following notes:

1.  An application switch into Firefox when the user is not on the first tab is broken.  This problem will be resolved when the above mentioned Firefox bug is fixed.

2.  Excessive output occurs during the following situations:

- switching tabs from chrome in focus to tab with in-page focus.
- 1st time visiting doc frame.
- 1st time visiting page with manip in focus. 
- probably others.

These will be fixed when event chaining is implemented.  http://bugzilla.gnome.org/show_bug.cgi?id=405408

Most cases have been fixed in repository.  See http://bugzilla.gnome.org/show_bug.cgi?id=410101 for the final problem.