Closed Bug 455866 Opened 16 years ago Closed 15 years ago

PluginNotFound event is not being fired

Categories

(Firefox for Android Graveyard :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(fennec1.0b3+)

VERIFIED FIXED
Tracking Status
fennec 1.0b3+ ---

People

(Reporter: jmaher, Assigned: youwotma)

References

Details

(Whiteboard: mmtc)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080916182923 Fennec/1.0a1pre

If I add a listener for the event PluginNotFound: document.addEventListener("PluginNotFound", pluginNotFound, false);

I expect my function 'pluginNotFound' to be called when a plugin is referenced in a webpage, but not found.  In Fx3.1 this happens as expected, but in fennec, it never gets called.

Reproducible: Always

Steps to Reproduce:
1. Run pluginevent.html (attached)
2. expect alert to popup and say "found event"

Actual Results:  
my callback function is not called.

Expected Results:  
PluginNotFound event to be fired and javascript to call my callback function.

this is in reference to mochitest /tests/content/layout/base/test_bug425013.html which is preventing mochitests from passing.
I had messed up my cut & paste a bit and this is the real path of the mochitest that is failing:
/tests/content/base/test/test_bug425013.html
Confirmed on fennec debug build pulled on 2008-09-22.  Marking wanted as this causes some mochitests to fail, but I'm not entirely clear on what the plug-in story is going to be for fennec 1.0 (hence I don't *think* this is blocking yet until we get that sorted).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-fennec1.0?
Flags: wanted-fennec1.0? → wanted-fennec1.0+
Plan is to port over stuff from Firefox browser.js
Assignee: nobody → mark.finkle
nsObjectLoadingContent.cpp should be firing this event, not sure why we'd need to make any changes in Fennec code. I wonder if this is yet another case of there being some visibility check somewhere that our hidden browser is failing.

(See also bug 455956 about the missing plugin styling not being applied).
Blocks: 473558
tracking-fennec: --- → ?
tracking-fennec: ? → 1.0b3+
My first patch :)

This preference change fixes the event problem, and the bug 455866.

Should i add a notification informing of missing plug-in and UI for installing the missing plug-ins like in firefox?
(In reply to comment #6)
> My first patch :)
> 
> This preference change fixes the event problem, and the bug 455866.

Excellent
 
> Should i add a notification informing of missing plug-in and UI for installing
> the missing plug-ins like in firefox?

Yes. Try to add the UI. There should be code in Firefox that can help you.
(In reply to comment #6)
> Created an attachment (id=393166) [details]
> Set plugin.default_plugin_disabled to true
> 
> My first patch :)

Congrats!

> 
> This preference change fixes the event problem, and the bug 455866.
> 

I assume David want to say bug 455956 :)
First of all, sorry about my delay. I'm very very busy this days.

This is my WIP. It have a functional plug-in finder/installer wizard.

The UI/functions is in a xbl, so it will not be loaded until the wizard is visible.

I will continue improving this in my free time. Feedback is appreciated.
Hey David, thanks a bunch for looking into this! I think we should land the pref flip to fix this bug and bug 455956, and then move your WIP patch to bug 460137, just to avoid conflating the issues, sound OK? I'll get that pref flip landed.
Pushed to mobile-browser: https://hg.mozilla.org/mobile-browser/rev/6bfcbaf1c420

resolving fixed
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
verified with 20091001 1.9.2 beta4 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: