Notification boxes can appear on the wrong tab

[daveschaefer]

The dropdown notification boxes that display messages and buttons don't always appear on the correct tab. They appear on whichever tab you're currently browsing. This should be fixed.

This includes notifications with the messages such as "Perspectives received no notary replies. This may be an attack or you may be behind a firewall/proxy that blocks notary requests" and "Suspected attack: Perspectives was unable to verify the security of your connection to this website".

Repro steps:

• Open a few tabs, either blank or for any website
• In a new tab, go to a site that displays a "Connection is untrusted" message from Firefox
• Once you hit Enter and the Perspectives notary lookup has begun, quickly switch back to one of the unrelated tabs
• Wait 5 seconds
• The notification appears on your current tab, not the https tab

From the reporter: "any action such as whitelisting takes the URL from the new tab, not the old one."

Note This only affects the notification message. The notary results (under 'View Notary Results') still display the correct set of data for each tab.

[daveschaefer]

Technical note: This might be because we're passing the incorrect window object to Pers_notify.do_notify() - passing the window instead of the tab. We need to pass the specific tab. See https://developer.mozilla.org/en-US/docs/XUL/notificationbox .

This will be much easier to reproduce and possibly to fix if we complete #74 to refator the unit tests and part of #26 - refactoring process_notary_results() into two functions, one to do the calculations and one to apply the results. We could then add a simple test to trigger these notifications at any time.

[daveschaefer]

To fix this we need to update our API usage / implementation of nsiWebProgressListener in the notaryListener object. The onLocationChange/onStateChange/onSecurityChange functions should be updated to accept the current API parameters, including aBrowser. We can then get a hook into the specific browser tab/object that's being updated and display the window there.

This change would touch a lot of fundamental perspectives internals. We may want to pass the browser object to updateStatus() instead of the window and let other sub-functions called off that grab the window instead. We'll need the browser object to store in ti.browser.

[daveschaefer]

Watch how this behaves with the fix for #103 - if we fix the callback filter behaviour we may be receiving fewer events.