Closed Bug 539851 Opened 14 years ago Closed 14 years ago

"Plugin crashed" binding not attached until mouseover

Categories

(Core :: Layout, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 539828

People

(Reporter: Dolske, Unassigned)

References

Details

Bug 538910 adds an in-content binding to show UI when a plugin has crashed, similar to our existing "plugin not found" UI.

When I test this by crashing our testplugin, the region occupied by the plugin becomes blank, instead of being immediately replaced by the icon/text from the new binding. But as soon as I mouseover that area, the binding is attached and the UI appears. Resizing/scrolling the window won't trigger it, though.

The binding's not being attached until the mouseover, because I don't hit the crash in bug 539850 until that point. Maybe I'm missing something in bug 539828, which adds the pseudoclass used to hook up this event?
(In reply to comment #0)
> The binding's not being attached until the mouseover, because I don't hit the
> crash in bug 539850 until that point. Maybe I'm missing something in bug
> 539828, which adds the pseudoclass used to hook up this event?

Is a ContentStatesChanged notification being sent when the element goes into that state?  (I'd expect such a notification ought to be sent by nsObjectLoadingContent::NotifyStateChanged .)
Ah, that does seem to be the problem. This fixes it:

/content/base/src/nsObjectLoadingContent.cpp

 NS_IMETHODIMP
 nsObjectLoadingContent::PluginCrashed()
 {
+  AutoNotifier notifier(this, PR_TRUE);

I'll just roll this into bug 539828 if there are no objections. I don't think any of the other broken-plugin states can change dynamically like this, so this should be the only spot that potentially needs fixed.
They can in fact change dynamically, but nsObjectLoadingContent has auto-notifiers as needed.  I hadn't realized we had added a new place that wrote mFallbackReason.... I guess in bug 519541?

Note that UnloadContent (which is the very next thing called in PluginCrashed) does document that its callers are responsible for notifying.  Perhaps we should assert if UnloadContent is entered without an AutoNotifier on the stack?

In any case, rolling this into bug 539828 is ok with me.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.