Bug 1070053 - Notification to allow plugins on the next page
What does Aurora do? Interesting… it throws an exception because apparently event.target is a dead object.
But with my patch… there's a race. At the time of PluginRemoved, the
document isn't necessarily a dead object for some reason. I guess the
PluginRemoved event is fired, and because it's handled in the content
script, it delays destruction of the document right away.
Anyhow, the good news is that the docShell is aware that it's being
destroyed, and I can use nsIDocShell::isBeingDestroyed to detect that.
If so, don't update the notifications (since the click-to-play
notifications are cleared automatically by TabsProgressListener via
removeTransientNotifications in it's onLocationChange handler.
So, I guard the call to updateNotificationUI behind a check for the docShell being destroyed and we're peachy.
Patch posted! (and just in time - my row was just called to board an airplane.)
Ah - a better idea. The PluginRemoved event is targeted on the
unloading document, so if I pass that to updateNotificationUI, we can
send that document's principal up and do comparisons with it in the
parent process. gfritzsche likes the idea - let's see if I can write a
test.
Funny… I'm having trouble writing a test. It seems the PluginRemoved event isn't being fired in my test case… why not?
I think just browsing to another page doesn't guarantee that
PluginRemoved will be called. With lldb attached, it looks like it's
often fired during a garbage / cycle collection. So my solution is to
force a plugin remove event by actually removing the plugin element
before browsing away. I can successfully reproduce the problem in this
way, and I can confirm that my patch fixes it. Nice!
Test posted. gfritzsche has given me r+ on the fixing patch, now just waiting for review on the test.
Try push:
remote: You can view the progress of your build at the following URL:
remote: Alternatively, view them on Treeherder (experimental):
Guh, whoops - forget to fix a thing.
remote: You can view the progress of your build at the following URL:
remote: Alternatively, view them on Treeherder (experimental):
Ok, expanding on my tests a little bit as per gfritzsche's request. I'm
adding a new test that is similar to the first one, but instead of
moving to about:mozilla, it moves to a data URI that shows the Test 2
plugin at a very small size, trigger the hidden plugin notification. We
want to test that the notification is displayed, and that it shows the
right information for test plugin 2, and not the first one.
Now what the hell is this?
Ah - that was from
https://hg.mozilla.org/integration/fx-team/rev/9debd2833863
, which snuck in under my rebase.
Ok, cleaned up the test again. Let's see what gfritzsche thinks.
He digs it! Just some clean-up, and I can land.
CLOSED TREE. BRAWRARARARR - why you gotta rob me of my satisfaction??