Issue Details (XML | Word | Printable)

Key: FDT-2436
Type: Bug Bug
Status: Closed Closed
Resolution: none
Priority: Minor Minor
Assignee: FDT Team
Reporter: Andreas Renberg
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
FDT

FDT won't launch the external player

Created: 17/Nov/11 04:04 PM   Updated: 28/May/13 05:15 PM
Component/s: External SWF Viewer
Affects Version/s: FDT 5.0
Fix Version/s: FDT 5.6
Security Level: public

Time Tracking:
Not Specified

Environment: Ubuntu 11.10
Issue Links:
Duplicate
 

Review Type: Review by Product Owner


 Description  « Hide
FDT will not launch an external player window when using "Run As > FDT SWF Application" or "Debug As > FDT SWF Application". The player will not show up in the list of running processes (as far as I can tell at least).

When using "Run as" the console will display "Launching External SWF Viewer", but will not cause any window to appear.
When using "Debug as", the console will give the following output (shortened down):
> [Info] Listening to port 7935.
> Using Flex SDK 4.5 Debugger Adapter.
> [Info] Could not connect to the player, will try to connect for the next 72000 ms
> [Info] Listening to port 7935.
> [Info] Could not connect to the player, will try to connect for the next 64000 ms
> [...]
> [Info] Could not connect to the player, debug session stopped. Maybe you do not have the Debug Flash Player installed.

FDT will still generate a SWF file in the "bin" folder which can be played without any problems in the browser.

I am using a fresh install of both FDT5 (free version), the Flex SDK 3.6, and the Flex SDK 4.5.1 and a new, emtpy workspace and projects. I am unsure of whether this is a fault of my own (incorrect settings somewhere) or if the problem lies with FDT. Do I need to install the desktop version of Flash Player somewhere on my machine, or is the one used by FDT included with and run from the SDK?

Previously I have been using "FB4Linux" (which is a hacked together version of Flash Builder designed to work in Linux) which is able to display an external player and debug the SWF without any issues.

If any further information is needed to fix this issue, I will gladly supply it.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Stephanie Swiderski added a comment - 08/Dec/11 10:27 PM
Could you please start FDT in a terminal. Then try to start a SWF in the External SWF Viewer.
FDT will give some logs directly to the terminal (stdout). Maybe you could give us these logs.

If the External SWF Viewer was ever visible you could try do delete this file:

FDT/plugins/com.powerflasher.fdt.ui.swfViewer/linux64/.SWFViewerCheck (contains the last used socket port)

and this directory:

FDT/plugins/com.powerflasher.fdt.ui.swfViewer/linux64/data (contains window placement, etc.)

After erasing these resources the External SWF Viewer should pop up again.

The External SWF Viewer uses a free socket connection (the port is the next available port in the system, chosen by the jvm) for communication between the already running instance and the new instance coming up from your last launch, to avoid another pop up of the viewer.


Andreas Renberg added a comment - 09/Dec/11 01:38 AM - edited
This is all the terminal output from FDT (starting up an existing project, and compiling it pretty much immediately)

(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed
(FDT 5:4995): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed

[STDOUT]: Check file
[STDOUT]: Found file
[STDOUT]: Could not instantiate Browser: No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)]
[ERROR]: Exception in thread "main" java.lang.NullPointerException
[ERROR]: at com.powerflasher.swfViewer.MainWindow.setUrl(MainWindow.java:238)
[ERROR]: at com.powerflasher.swfViewer.MainWindow.initValues(MainWindow.java:192)
[ERROR]: at com.powerflasher.swfViewer.MainWindow.open(MainWindow.java:176)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.openMainWindow(SWFViewer.java:190)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.start(SWFViewer.java:30)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.main(SWFViewer.java:22)


Andreas Renberg added a comment - 09/Dec/11 01:48 AM - edited
As for deleting the additional files, (I'm using a 32 bit computer, so I'm assuming the correct folder for me is linux32), I removed .SWFViewerCheck, but there was no data folder in either location, only swfViewer-linux.jar and swt-linux.jar.

Deleting that file made no difference (it still wouldn't display an external SWF window) and the terminal output was nearly identical to the previous output.

As I have mentioned before, "fb4linux" works without any problems (and I'm assuming it uses a similar system for debugging), so I'm guessing the problem does not arise due to sealed off ports. I also had a previous version of FDT 3.5 Pure which ran without hickups.


Stephanie Swiderski added a comment - 09/Dec/11 02:32 PM - edited
Thank you for your input. I think the problem boils down to this line:

[STDOUT]: Could not instantiate Browser: No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)]

The Browser could not be initialized since the path variable MOZILLA_FIVE_HOME is not set.
Here are some advices to this problem:

http://www.eclipse.org/swt/faq.php
FAQ: "What do I need to run the SWT Browser in a standalone application on Linux or Solaris?"

https://www-304.ibm.com/support/docview.wss?uid=swg21271865

http://www.linuxquestions.org/questions/linux-software-2/mozilla_five_home-environment-variable-123363/

in short you can try to set: export MOZILLA_FIVE_HOME=/path/to/mozilla
maybe that helps.

Please check also if the web browser inside of fdt (or eclipse) is working, since the External Swf Viewer uses the same. It seems like a setup problem with the XUL-Runner, but I am not quite sure.


Andreas Renberg added a comment - 12/Dec/11 04:41 AM
The internal web browser (as well as the welcome screen, which I'm assuming uses the same system) work just fine, even when debugging the SWF does not.

Regardless, the issue is resolved. After getting nowhere trying to properly set the MOZILLA_FIVE_HOME variable, I found a site which described how to install xulrunner http://www.samclarke.com/2011/11/how-to-install-aptana-studio-3-on-ubuntu-11-10-oneiric/ (see step #2, the rest can be ignored).

The debugger will now launch the SWF.


Andreas Renberg added a comment - 12/Dec/11 05:04 AM - edited
I still had one problem though (but solved it), the debugger would never correct properly.

I had to download the latest Flash Player Debugger (found at http://www.adobe.com/support/flashplayer/downloads.html ) and copy libflashplayer.so to /usr/lib/xulrunner-[version]/plugins/.

Just a side question, why does FDT use the flash player from xulrunner (or the whatever browser is used) rather than the debugger found in the SDK?

Also, I realize now that this was an eclipse (not FDT) issue, but thank you for guiding me through to the solution.


Philipp Arnolds added a comment - 12/Dec/11 12:43 PM
Andreas,

thanks a lot for doing this research and for sharing your findings! Your contribution is highly appreciated!
I'll sum it up for our documentation to help other users experience the same issues.
I'll leave this ticket as "under investigation", maybe we can find a way to avoid this issue.

regards,

Philipp


Andreas Renberg added a comment - 12/Jun/12 12:22 AM - edited
After a complete reinstall of Ubuntu 12.04 (32 bit) and using the latest FDT (I believe it is version 5.5 now, correct?) the problem has returned with the same error message of "MOZILLA_FIVE_HOME not set".

My previous solution won't work as "XUL-Runner" has a dependency on an older version of a library, and as the current version of that library is being used by other applications, I can't downgrade it. I'll try to find a different solution and report back if I find anything.

However, the compiler works just fine; it's just the "External SWF Viewer" that's giving me problems. I can still debug and run the application using the following steps:

  • If you have not already done so, download the "Projector Content Debugger" version of Flash Player from http://www.adobe.com/support/flashplayer/downloads.html and save it to the computer (I would recommend /usr/bin/flashplayerdebugger)
  • In FDT, go to Windows > Preferences, navigate to FDT > Tools > Flash, and fill in the location of the player in "Flash Player"
  • In the Debug/Run Configurations for the project, navigate to Start > Viewer and change the dropdown to "Adobe Flash Player".

The last change has to be made to every new project you create, as FDT always defaults to debugging with "External SWF Viewer" for all new projects.

Using that workaround, this bug can be changed from "Blocking" to "Major" or "Minor".


Andreas Renberg added a comment - 12/Jun/12 03:26 AM
More testing (or rather, re-trying things I had tested earlier).

I already have the up to date versions of FireFox and XULRunner installed on the system. I have tried setting MOZILLA_FIVE_HOME to both directories /usr/lib/mozilla/ and /usr/lib/xulrunner/ (separately, not at the same time). Both directories exist and contain plugin folders, where I placed libflashplayer.so among the other *.so files that existed there.

In both cases, I get a different error message from FDT when I run it from the command line

[ERROR]: java.io.FileNotFoundException: .SWFViewerCheck (No such file or directory)
[ERROR]: at java.io.FileInputStream.open(Native Method)
[ERROR]: at java.io.FileInputStream.<init>(FileInputStream.java:137)
[ERROR]: at java.io.FileReader.<init>(FileReader.java:72)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.readPort(SWFViewer.java:136)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.getConnection(SWFViewer.java:96)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.start(SWFViewer.java:31)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.main(SWFViewer.java:26)
[STDOUT]: No Socket.
[STDOUT]: Could not instantiate Browser: No more handles [MOZILLA_FIVE_HOME='/usr/lib/xulrunner/'] (java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
[STDOUT]: no swt-mozilla-gtk-3655 in java.library.path
[STDOUT]: no swt-mozilla-gtk in java.library.path
[STDOUT]: /tmp/swtlib-32/libswt-mozilla-gtk-3655.so: libxpcom.so: cannot open shared object file: No such file or directory
[STDOUT]: Can't load library: /tmp/swtlib-32/libswt-mozilla-gtk.so
[STDOUT]: )
[ERROR]: Exception in thread "main" java.lang.NullPointerException
[ERROR]: at com.powerflasher.swfViewer.MainWindow.setUrl(MainWindow.java:226)
[ERROR]: at com.powerflasher.swfViewer.MainWindow.initValues(MainWindow.java:185)
[ERROR]: at com.powerflasher.swfViewer.MainWindow.open(MainWindow.java:172)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.openMainWindow(SWFViewer.java:224)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.start(SWFViewer.java:45)
[ERROR]: at com.powerflasher.swfViewer.SWFViewer.main(SWFViewer.java:26)

I'm assuming the second error message ("No more handles") is the important one; the first one may go away after the .SWFViewerCheck directory has been created after successfully running SWFViewer once.

I guess this means more testing...


Andreas Renberg added a comment - 12/Jun/12 03:42 AM - edited
I tried another "solution" recommended several places on the internet; starting the application either with -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner or appending that same line to eclipse.ini.

Sadly, this did not work either, and gave the same error message as previously provided:

[STDOUT]: Could not instantiate Browser: No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)]

Setting both MOZILLA_FIVE_HOME and passing the additional parameter at the same time did not work either.

Yet another "solution" recommended adding -Dorg.eclipse.swt.browser.UseWebKitGTK=true to eclipse.ini. Again, this did not fix the issue, and gave the same error message as setting the XULRunnerPath variable.

I mentioned this before, but I'll bring it up again. The "Internal Web Browser" works just fine (and judging by the command line output, it seems to use the browser I instructed it to in eclipse.ini). It seems to only be a problem with SWT or SWFViewer.


Andreas Renberg added a comment - 12/Jun/12 06:03 AM
I searched the file system for libxpcom.so and found it in the two following locations.
  • /usr/lib/firefox
  • /usr/lib/thunderbird

So using the aforementioned method, I set MOZILLA_FIVE_HOME to /usr/lib/firefox which definitely gave a different result. However, the result was a full on fatal Java error.

I have placed the terminal output as well as the contents of the "log" file created by Java in this Gist:
https://gist.github.com/2914804


Andreas Renberg added a comment - 12/Jun/12 06:44 AM
I'm getting a very similar error, which I do believe is related, when I debug an FDT Plugin.

The full error message can be found in this Gist (and it includes what I find to be an amusing output of "I am here. Bring it on.")
https://gist.github.com/2915057


FDT Team added a comment - 02/Jul/12 08:16 PM
Thanks, we'll continue to look into this.

Does it still happen with FDT 5.5.2?


Andreas Renberg added a comment - 03/Jul/12 03:56 AM - edited
Is FDT 5.5.2 the version that is currently available in the "Buy & Download" section?

Then yes, the same error is still occurring. For the previous comments, I tried all these tests with a fresh install from which ever version was up for download on 2012-06-12. I tried it again today with another fresh install, and am still getting the same results.

The problem doesn't affect "standard development" as much as I can always use the Flash Player used by Adobe (a workaround described in my previous comments). However, it seems that FDT plugin development is impossible thanks to this bug (which is a shame, I was looking forward to trying that).


FDT Team added a comment - 03/Jul/12 03:00 PM
Hey Andreas,

Thanks for the info. We just talked about it and we're digging into it.

Thanks for the update.


Stephanie Swiderski added a comment - 04/Jul/12 12:40 PM
Andreas,

First of all thanks a lot for doing this research.
I looked into the issue again and maybe you could verify the following:

1. Start FDT and compile a test project into a SWF
2. Try to start it with the external swf viewer (which would fail of course, as you describe before)
3. Open a terminal and change to the plugin-directory of FDT
4. Change to directory com.powerflasher.fdt.ui.swfViewer/linux?? (where ?? is 32 or 64, for 32 or 64-bit os)
5. Now start the external swf viewer with the following call (this is done normally by FDT)

java -cp swt-linux.jar:swfViewer-linux.jar com.powerflasher.swfViewer.SWFViewer -file=file:////pathToWorkspace/project/bin/project.swf -width=550 -height=400

As you can see we call directly the SWFViewer class of our swfViewer-linux.jar and also the swt-linux.jar is added to the classpath. I expect that the external swf viewer could not open its browser widget. But maybe you can try to adapt this call with additional parameters as you suggest above:
-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner
or
-Dorg.eclipse.swt.browser.UseWebKitGTK=true

If this works for your linux version I am going to implement an additional a preference page for the next FDT where those extra parameters could be added to the call of the external swf viewer.

regards,

Stephanie


Andreas Renberg added a comment - 04/Jul/12 08:41 PM - edited
Stephanie,

I'm still getting the same results as the output in FDT I'm afraid, even using the additional parameters makes no difference; I still get the "MOZILLA_FIVE_HOME not set" error:
https://gist.github.com/3048738#file_fdt5+output+1

So, I set MOZILLA_FIVE_HOME to /usr/lib/firefox, and as before, received this error message:
https://gist.github.com/3048738#file_fdt5+output+2

I'm not sure which file the error is talking about when it says that it "is missing", but I can guarantee, libxpcom.so does exist inside of /usr/lib/firefox.


Andreas Renberg added a comment - 04/Jul/12 09:31 PM - edited
Did some searching and some testing, as long as MOZILLA_FIVE_HOME is set properly, the error message looks much like this one:
https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/728825

Though, rather than look in ~/.swt/lib/linux/x86, FDT will look in (and create, it seems) /tmp/swtlib-32/.

I tried the same workaround as noted in the bugtracker, but rather than copy to the home folder, I copied to the "tmp" folder (In fact, I did both just to be on the safe side. I also had to install libswt-gtk-3-jni)

It results in the same error message, "UnsatisfiedLinkError: Could not load SWT library.". No change.

Would it perhaps make a difference with a newer version of Eclipse or SWTLib? There is a very good chance that this may not be an FDT problem. I would be happy to run any "test builds" if it helps.


Stephanie Swiderski added a comment - 05/Jul/12 08:21 PM
Andreas

Maybe you could also verify the following idea.
The position of the argument is of relevance, so the JVM arguments have to be at the beginning to take effect, so maybe try this call:

java -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner -cp swt-linux.jar:swfViewer-linux.jar com.powerflasher.swfViewer.SWFViewer -file=file://~/Testbench.swf -width=550 -height=400

"Would it perhaps make a difference with a newer version of Eclipse or SWTLib?"
Yes this could be an idea:
Feel free to replace the swt-linux.jar in linux64 directory with plugins/org.eclipse.swt.gtk.linux.x86_64_????.jar of any eclipse instance you like, it contains the swt framework.
Maybe the version we ship in linux64 directory is to old for your linux distribution.

Regards,
Stephanie


Andreas Renberg added a comment - 05/Jul/12 09:40 PM
Oddly enough, changing the parameter orders gives a new error message:
https://gist.github.com/3048738#file_fdt5+output+3
(this is despite MOZILLA_FIVE_HOME not being set in this terminal session)

Maybe the version we ship in linux64 directory is to old for your linux distribution.

Actually, I'm using 32 bit Linux (on a 32 bit machine), but it should be the same for both versions so long as the paths are changed, correct?

I apologize for the inconvenience this is causing.

Has no one else reported this error as well? I do find it odd that I'm the only person with this problem. I would assume it was due to user error, conflicting program, or a problem with installation, but the issue persisted even after a complete system reinstall.


Andreas Renberg added a comment - 05/Jul/12 09:47 PM
Success!

I did as you said, replacing swt-linux.jar with the version from my Eclipse for Java installation and it worked like a charm! (tested from inside of FDT, not running SWFViewer separately)

... well, sort of like a charm. The SWF runs just fine, but I'm not getting any output from "trace" (the process shows up as <terminated> from the console inside of FDT) and I'm getting another error from the terminal:
https://gist.github.com/3048738#file_fdt5+output+4

But the SWF works, and that's good enough for me. I could always use tools such as Doomsday Console for on-screen terminal output.

In case it is of any use, the SWT library was version gtk.linux.x86_3.7.2.v3740f from an Eclipse Indigo installation for Java.


Stephanie Swiderski added a comment - 05/Jul/12 10:39 PM
Andreas,

thank you for all this work, this was very helpful.
We will update the shipped swt library within the linux32 and linux64 directory.

Another question: Is debugging possible ?
The trace outputs are only shown if the debug player is installed, maybe you could change the start location
in the project launcher to "http://www.playerversion.com" . Then you could verify if the debug player is used
in this browser instance of the external swf viewer.

Also you could change the start location to "http://www.whatismybrowser.com/"
to see which browser is really used and maybe you could add the necessary .so of the flashplayer to this browser engine.

Regards,
Stephanie


Andreas Renberg added a comment - 05/Jul/12 11:32 PM - edited

Another question: Is debugging possible?

Actually, this one was my mistake. In Java, you can get the console output with either "Run as" or "Debug as". Without thinking, I used "Run as" in FDT when testing. I did not realize that trace would only work with "Debug as".

Everything is running like a charm (for real, this time).

Thank you very much for taking the time and effort to get this matter sorted out!

On a related note, if you need any beta testers for Linux builds of future versions of FDT, I would be very glad to assist.


FDT Team added a comment - 06/Jul/12 02:22 PM
Thanks for the offer Andreas.

We would love your help.

We'll keep you posted.


FDT Team added a comment - 09/Jul/12 07:15 PM
Fixed for 5.6

cmacisaac added a comment - 28/May/13 05:13 PM
Looks like 1.13.201.1608. It's the one downloaded fresh from your main site.

cmacisaac added a comment - 28/May/13 05:15 PM
oopse, wrong issue, sorry.