Before, we were comparing Principals sent up from PluginContent against the
Principal of the selected browser - this was in order to account for races
(and intermittent oranges) where the browser has moved away from a page before
a CTP message has been received by the parent.
Comparing Principals works beautifully, except in the case of Data URIs, since
Data URIs inherit the Principals of the page they were linked from. That means
that if we're on a page with a link to a Data URI that embeds a plugin, if we
quickly browse to that page and back before a CTP message reaches the parent,
when the CTP message finally arrives, the Principals will match. We solve this
by sending the location as well as the Principal, to do a final comparison if
the Principals do match.
When the PluginRemoved event is fired when changing locations, it's fired
asynchronously such that the document that the plugin belongs to has already
been unloaded. This was causing the hidden plugin notification to appear in
some cases when users browsed away from documents that had hidden plugins
in them. Now we pass the Principal for the unloading document back to the
parent and do a comparison with the current browser Principal to ensure
that they match before showing the hidden plugin notification.
