Firefox 3.6b4 displays flash components as black boxes if loaded as an element of a toolbar addon

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
9 years ago
2 years ago

People

(Reporter: elijah.bowen1, Unassigned)

Tracking

unspecified
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.2 ?

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6.3; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4

I am using Shockwave Flash 9.0.246.0
This problem does not occur when loading the same flash URL in the browser window itself or in previous versions of Firefox. I have observed the problem both with my own Flash as well as with flash objects loaded within youtube.

Example to add to XUL: 
<iframe src="http://www.tizag.com/pics/example.swf" flex="1" height="28" width="225"/>   
Note that the flash at http://www.tizag.com/pics/example.swf works fine when loaded in the main browser window, but is completely black when loaded through the xul of a plugin. This is true for all swf files.



Reproducible: Always

Steps to Reproduce:
1.Create a custom toolbar which contains an iframe within a toolbaritem in the main xul file (sized to fit the toolbar).
2.Point this iframe's src to any remote swf file.
3.Build and install the xpi file.
Actual Results:  
Flash AS3 code appears to be executing but the flash region is entirely black. 

Expected Results:  
Flash should have displayed exactly like Firefox 3.5 displays it.
(Reporter)

Updated

9 years ago
Flags: blocking-firefox3.6?

Comment 1

9 years ago
Did you try iframe type="content"?

This is a quite unusual situation and it is not a blocker.
Flags: blocking-firefox3.6? → blocking-firefox3.6-
(Reporter)

Comment 2

9 years ago
Great suggestion! Thanks, that fixed the problem.

Is it still a bug that type="content" is required in the xul case but not the browser case?

Comment 3

9 years ago
Well... when writing chrome code and loading content in an iframe, you should always use type="content" (for security reasons). It's surprising to me that this affects plugin loading, but that's probably related to compositor... I'm not sure.
There is probably a regression from the 3.6 compositor work. I'll look into it.

Does it work if the plugin is in windowless mode?
Component: Extension Compatibility → Plug-ins
Flags: blocking-firefox3.6-
Product: Firefox → Core
QA Contact: extension.compatibility → plugins
Assignee: nobody → roc
Flags: wanted1.9.2?
Hmm, seems to work for me on trunk with a simple test added to layout/base/tests/chrome.
(Reporter)

Comment 6

9 years ago
When flash is in windowless mode I get the same results - works with type="content" fails without.
Mats, can you look into this?
Confirming based on very similar bug 529263.
Blocks: 529263
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 550786
Duplicate of this bug: 556242

Comment 11

9 years ago
I'm still having problems related to this.  I have an extension that uses Flash in a sidebar for a GUI; it needs to communicate with the Javascript for the extension to do what I need it to do.  However, if I embed the SWF in the sidebar, it will not be visible, even though it loads and makes the connection with the Javascript; if I embed the SWF using an iframe of type="content", then I can see the visualization, but cannot use it as an interface, since it won't communicate properly with the rest of the extension.

In 3.5, I can get it to work in an iframe or directly embedded in the sidebar.  In 3.6.3, I can choose between seeing it or having it be able to communicate with the rest of the extension but only show up as a blank box.

I have a trimmed down extension at http://cs.indiana.edu/~hroinest/sidebarflash.xpi to show the problem.

In 3.5, this adds a sidebar (opened with Shift-Alt-Q or the View>Sidebar menu) that shows a network of tags ans favicons; when it loads, the Flash tells the sidebar to alert that it loaded; clicking on a tag in the visualization calls an alert with the tag's name, and then Javascript tells the Flash to highlight the tag.  (In the full extension, the Javascript has more to do when a tag is clicked, so just having the Flash do the highlighting without the indirect call would not solve the problem.)

In 3.6, the same sidebar shows up as a big black box.  The alert indicating that the SWF loaded and called the Javascript works.

If I put the SWF in an iframe of type="content" in 3.6, the visualization will show up, but it will not communicate with the Javascript, eliminating the interaction that is the reason it is there.
Can you make a standalone XUL file that shows the problem with loaded with the -chrome parameter?
Also, are you able to use windowless mode to work around the problem? wmode="opaque" or wmode="transparent"?

Comment 14

9 years ago
I had exactly the same problem. But loading the flash in windowless mode, either opaque or transparent solves the issue for me. 
That's still a regression as it was working in 3.5 even in window mode, but at least, there is a work around. 
However comment #6 seems to say it did not solve the issue, but I'm now running 3.6.3 which may be the difference.

Comment 15

9 years ago
wmode=opaque seems to work around the issue for me.

Comment 16

8 years ago
We're facing the same problem...not able to get flash to work in a sidebar.  To see the problem, anyone can try installing the add-on youplayer into 3.6.3...videos shouldn't play. 

We've found that setting type="content-primary" is a workaround for our problem (to enable flash to work in the sidebar), but it's not the solution.
Duplicate of this bug: 566002
Duplicate of this bug: 542289

Updated

4 years ago
Assignee: mats → nobody

Comment 19

2 years ago
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.