Flash plugin crashes consistently with fullscreen and keyboard combination [@ mozilla::plugins::PPluginInstanceChild::FatalError] "error deserializing (better message TODO)"

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: juanb, Assigned: Josh Aas)

Tracking

({regression, stackwanted})

Trunk
x86
Mac OS X
regression, stackwanted
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [4b2])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
While testing Fx4b2, I can crash Flash consistently with the following steps:

1. Go to youtube and play a video.
2. Use the video's full screen button to go into full screen.
3. Get out of full screen the same way
4. Click on the page to regain tab focus
5. Press Command-shift

Flash 10.1.53.64

Reproducible 100% on Mac. I could not reproduce the problem on Linux, nor Win7, nor XP. I used command-shift because I was trying to full screen the browser, but noticed that only command-shift did the trick.
(Reporter)

Updated

7 years ago
Whiteboard: [4b2]
blocking2.0: --- → ?
Josh, can you have a look? Sounds like something we need to fix for Firefox 4.
Assignee: nobody → joshmoz
blocking2.0: ? → betaN+
Keywords: regression

Comment 2

7 years ago
https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report
Keywords: stackwanted
(Assignee)

Comment 3

7 years ago
Created attachment 461561 [details]
plugin process stack from debug build

I can reproduce this easily, this is a stack trace from gdb attached to a debug build.

Updated

7 years ago
Attachment #461561 - Attachment is patch: false

Updated

7 years ago
Summary: Flash plugin crashes consistently with fullscreen and keyboard combination → Flash plugin crashes consistently with fullscreen and keyboard combination [@ mozilla::plugins::PPluginInstanceChild::FatalError] "error deserializing (better message TODO)"
(Assignee)

Updated

7 years ago
Duplicate of this bug: 581254
(Assignee)

Updated

7 years ago
Assignee: joshmoz → b56girard
The problem is that we are trying to serialize an invalid NPCocoaEvent instance.

The event is being generated from an nsChildView that is not the plug-in's view:
mPluginEventModel = NPEventModelCarbon
mIsPluginView = NO

Thus the event pointed by nsGUIEvent.pluginEvent is a Carbon event.

Then in nsPluginInstanceOwner::ProcessEvent the event is converted to a void* and is treated as a NPCocoaEvent:
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#4498

I don't understand how different nsChildView's using different event models is supposed to work. One fix is we can add nsGUIEvent to somehow type pluginEvent and handle the conversion as needed in nsObjectFrame, or make sure pluginEvent never points to a carbon event.
With a recent trunk build I can no longer reproduce the crash. However the first time I press CMD+SHIFT+F, it quickly enters/exits full-screen. After pressing it the second time it stays in full-screen.
Bug 584965 was backed out and now the crash is reproducible again. Adding bug 584965 to dependencies.
Depends on: 584965
(In reply to comment #5)

> The event is being generated from an nsChildView that is not the
> plug-in's view:
> mPluginEventModel = NPEventModelCarbon
> mIsPluginView = NO

I've noticed this part of the bug, too, and am trying to track it down
(it impacts the new JEP).  (By the way, the nsChildView in question is
the plugin view's superview.)

So far I've found the following regression range:

firefox-2010-07-15-03-mozilla-central
firefox-2010-07-16-03-mozilla-central

And I've found that the following patch in this range is what
triggered this problem:

http://hg.mozilla.org/mozilla-central/rev/a78221e8bde4

This is the patch (from bug 564991) that turned on retained layers.

Once I've found out what the connection is, I'll open another bug.
(Following up comment #8)

> http://hg.mozilla.org/mozilla-central/rev/a78221e8bde4

By the way, to make this patch compile you'll need to add the
following:

/**
 * The address of gColorLayerUserData is used as the user
 * data pointer for ColorLayers
 */
static PRUint8 gColorLayerUserData;

beneath the following line in layout/base/FrameLayerBuilder.cpp:

static PRUint8 gThebesDisplayItemLayerUserData;
(Assignee)

Comment 10

7 years ago
Fixed on mozilla-central by the patch in bug 584965.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Assignee: b56girard → joshmoz
You need to log in before you can comment on or make changes to this bug.