856171 - Content losing track of running plugins, possibly in relation to document active/inactive events

Status: RESOLVED DUPLICATE of bug 863792

(Core Graveyard :: Plug-ins, defect)

Description

[Bob Clary [:bc] (inactive)]

This may be a duplicate.

Fedora 18 x86_64 with Flash 11.2 r202

0. enable click to play in about:config plugins.click_to_play true
1, http://www.hermanmiller.com/content/hermanmiller/english/products/categories/seating/performance-work-chairs/embody-chairs.html
2, Click video in upper right corner: "Making of the Embody Chair"
3. A popup div appears, click activate Flash
4. popup div goes black. right click and see Movie not loaded

clear cache, disable click to play, repeat 1-4. Movie plays.

Comment 1

[John Schoenick [:johns]]

I can't reproduce this on Arch x64 w/ Flash 11.2 r202 with nightly or 19, the video seems to work properly.

Does this repro on a fresh profile and/or on nightly?

Comment 2

[Bob Clary [:bc] (inactive)]

Sorry, I forgot to mention that I was using today's Nightly. Also if you played the movie first with click to play disabled, then switched to click to play enabled, make sure to clear your cache.

I tried with a very recent debug build and a fresh profile.

0. enable click to play
1. load site
2. ignore the door hanger to activate flash
3. click movie

and it played. :-(

I shutdown the browser, restarted, cleared cache still with click to play enabled

1. load site
2. on the activation door hanger, chose Not Now
3. click movie

and it didn't play and showed Movie not loaded. I tried again after shutting down and clearing the cache and ignoring the door hanger again and it didn't load the movie.

I guess you need to shutdown and restart the browser after click to play is enabled.

Comment 3

[John Schoenick [:johns]]

Unfortunately I'm still not able to trigger this with the given steps on a fresh profile. I tried restarting, clearing cache, enabling click-to-play before and after restarting -- nothing :(

Does repeating these steps *slower* (e.g. stare at the click-to-play dialog for a few seconds) affect your success rate? I can maybe see how this could occur if you managed to request activation of the plugin while a channel request for that object tag was still pending.

If you have a debug build handy, can you try |export NSPR_LOG_MODULES="objlc:5,Plugin:5,PluginNPN:5,PluginNPP:5"| in your environment, and then paste the relevant "OBJLC [0x...]: Blah" spam corresponding to the bug occurring?

Comment 4

[Bob Clary [:bc] (inactive)]

Attachment: OBJLC log - no waiting

The bug showed up in this log. I didn't wait before clicking the activate notice.

Comment 5

[Bob Clary [:bc] (inactive)]

Attachment: OBJLC log - waiting

I waited before clicking the activate in this log. The first time it showed the bug. I tried again and waited again and it didn't show the bug and played the movie.

Comment 6

[John Schoenick [:johns]]

Okay, so, something broken is going on:

We see an embed with a flash type and a src URL. Since we know it's flash, we spawn it immediately, then open the channel:

> -179034304[d480b0]: OBJLC [337ce98]: Notifying about state change: (4, 800000000) -> (2, 0) (sync 0, notify 1)
> -179034304[d480b0]: OBJLC [337ce98]: Channel opened

Then a CheckPluginStopEvent fires. These are queued when a plugin loses its frame or is removed from the document - if they're not re-added by time the event loop spins, they despawn. So apparently the plugin is out of the document at this moment:

> -179034304[d480b0]: OBJLC [3948d50]: Unloading plugin outside of document
> -179034304[d480b0]: OBJLC [337ce98]: StopPluginInstance - Closing used channel
> -179034304[d480b0]: OBJLC [337ce98]: Closing channel

At this point the plugin should be stopped entirely. The channel we closed reaches OnStartRequest, probably with an error, and we ignore it (we un-loaded!)

> -179034304[d480b0]: OBJLC [337ce98]: Channel OnStartRequest

... But somehow there's a flash plugin running at this point? It lacks a channel, because we killed the load and never delivered it, but the log says we also tried to kill the plugin.

So, probably, something, somewhere, re-entered.

Comment 7

[John Schoenick [:johns]]

Attachment: Add a ton more debug logging

This adds a ton more debug spam around suspect points -- could you give a build with this patch a shot and see what the NSPR_LOG_MODULES="objlc:5" debug spam reveals?

Try:
https://tbpl.mozilla.org/?tree=Try&rev=92d66401dca2

Comment 8

[Bob Clary [:bc] (inactive)]

I can no longer reproduce this with an opt or debug Nightly or debug Beta, Aurora. I've tried new profiles in addition to the original profile where I first noticed this. I'll keep the patch in my debug Nightly and will try periodically to reproduce it. Sorry.

Comment 9

[John Schoenick [:johns]]

Bug 859099 is another bug about plugins getting their running state confused, that also doesn't repro anymore on trunk.

@bc - Does this still reproduce on aurora builds, by chance?

Comment 10

[John Schoenick [:johns]]

(In reply to John Schoenick [:johns] from comment #9)
> @bc - Does this still reproduce on aurora builds, by chance?

Sorry, that should be *beta* builds (21)

Comment 11

[Bob Clary [:bc] (inactive)]

I can't reproduce in Beta/21, Aurora/22, Nightly/23 debug builds on Linux x86_64. I also can not reproduce with Firefox 20 release. Shall we just mark this WFM and if I can reproduce later reopen?

Comment 12

[John Schoenick [:johns]]

(In reply to Bob Clary [:bc:] from comment #11)
> I can't reproduce in Beta/21, Aurora/22, Nightly/23 debug builds on Linux
> x86_64. I also can not reproduce with Firefox 20 release. Shall we just mark
> this WFM and if I can reproduce later reopen?

Given the logs you've posted here there is a significant bug in this code which might also be behind bug 859099.

Perhaps QA can work some magic and get repro based on c0

Comment 13

[Georg Fritzsche [:gfritzsche]]

(from comment #12)
> Perhaps QA can work some magic and get repro based on c0

Comment 14

[Paul Silaghi, QA [:pauly]]

I couldn't reproduce the issue on Fedora 15 x64, Ubuntu 12.04 and Win 7 both on latest nightly and 2013-03-29 nightly

Comment 15

[John Schoenick [:johns]]

So bug 859099 could indeed be the cause of this. A plugin runs script when it spawns, which inactivates the document, leaking the plugin instance. In 859099 we then cleanup the document and trip over the leaked instance, but in this case it sounds like the document gets re-used and the tag still has the "bad" instance. Said instance would not have a channel, but would otherwise still be alive, which matches the described behavior + logs.

Absent any other reports or ability to reproduce, I'm going to call this a dupe, but please file a new bug if you see any similar behavior