Problems with flash plugin with the web activity

[joaoboscoapf]

I installed the flash plugin from adobe in the web activity according to the instructions in http://wiki.laptop.org/go/Web_Browser#Flash_in_the_default_web_browser.

It works fine but when I right click on an animation, the browser crashs. The ouput I got is:

The program 'sugar-activity-factory' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 713 error_code 2 request_code 12 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Segmentation fault

I know that you don't plan to include adobe's flash in the browser but I think some people will do it.

Related to ticket #652.

I used a Q2B43 / 239 build laptop.

ps: To get the output I opened the developer's console and executed the following command:

   sugar-activity-factory foobarativity.FooBarActivity /usr/share/activities/FooBar.activity 

[joaoboscoapf]

The real command to get the output is:

sugar-activity-factory webactivity.WebActivity /usr/share/activities/Web.activity 

[jg]

The browser should certainly not crash in this situation.

[joaoboscoapf]

Some people will certainly use adobe's plugin instead of gnash until gnash is not ready. Don't you think this issue should be on trial-1 milestone? I think kids will certainly right click on contents and get really angry with crashes ... =(

[jg]

joaoboscoapf, is this still crashing?

If it is, please give us links to the sites which crash it.

Our (admittedly minimal) tests here did not crash, and I'm not about to send people on a hunt for pages without better information, and information based on build 368, rather than stuff from February.

clearly, plug in crashes should not take down the browser...

[joaoboscoapf]

It still crashes in build 368. You have to install Adobe's Flash plugin and right click on a flash animation.

All flash animations I tried crashes. Test case: http://www.adobe.com (right click on the first flash animation and it will crash the web browser).

[jg]

jg to bug Adobe.

marco or dcbw to see if there is something in our plug in infrastructure that needs fixing.

[tomeu]

Backtrace when running on the xo with:

python /usr/bin/sugar-activity --sync web

I breakpointed in gdk_x_error after installing gtk2-debuginfo-2.10.11-2.i386.rpm.

 #0  gdk_x_error (display=0x8931ef8, error=0xbfc94038) at gdkmain-x11.c:614
 #1  0xb7116cfa in _XError () from /usr/lib/libX11.so.6
 #2  0xb71187c4 in _XReply () from /usr/lib/libX11.so.6
 #3  0xb70fa2ac in _XGetWindowAttributes () from /usr/lib/libX11.so.6
 #4  0xb70fa402 in XGetWindowAttributes () from /usr/lib/libX11.so.6
 #5  0xb12adb94 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
 #6  0xb12ae005 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
 #7  0xb5328301 in XtUnrealizeWidget () from /usr/lib/libXt.so.6
 #8  0xb532873e in XtRealizeWidget () from /usr/lib/libXt.so.6
 #9  0xb532ef16 in _XtPopup () from /usr/lib/libXt.so.6
 #10 0xb532f025 in XtPopupSpringLoaded () from /usr/lib/libXt.so.6
 #11 0xb12ad1c3 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
 #12 0xb12b1af6 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
 #13 0xb12b1df2 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
 #14 0xb5320225 in XtDispatchEventToWidget () from /usr/lib/libXt.so.6
 #15 0xb5320cca in _XtSendFocusEvent () from /usr/lib/libXt.so.6
 #16 0xb531fb37 in XtDispatchEvent () from /usr/lib/libXt.so.6
 #17 0xb532c9be in XtAppProcessEvent () from /usr/lib/libXt.so.6
 #18 0xb5ecfbad in gtk_xtbin_set_position () from /usr/lib/xulrunner-1.9a3pre/libxul.so
 #19 0xb7924442 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
 #20 0xb792741f in g_main_context_check () from /lib/libglib-2.0.so.0
 #21 0xb79277c9 in g_main_loop_run () from /lib/libglib-2.0.so.0
 #22 0xb748a6d4 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
 #23 0xb77ea5b0 in init_gtk () from /usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so
 #24 0xb7e62f28 in PyEval_EvalFrame () from /usr/lib/libpython2.4.so.1.0
 #25 0xb7e641b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0
 #26 0xb7e64293 in PyEval_EvalCode () from /usr/lib/libpython2.4.so.1.0
 #27 0xb7e81078 in Py_CompileString () from /usr/lib/libpython2.4.so.1.0
 #28 0xb7e827b8 in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.4.so.1.0
 #29 0xb7e82e9a in PyRun_AnyFileExFlags () from /usr/lib/libpython2.4.so.1.0
 #30 0xb7e89825 in Py_Main () from /usr/lib/libpython2.4.so.1.0
 #31 0x08048582 in main ()

[marco]

The latest sugar rpm does not crash anymore, it will be in the next build.

Now that we don't crash we get a completely white menu. Probably someone at Adobe would be able to figure out what is going on.

[jg]

Keith Fieldhouse keith at rexmere reports: I've taken a look at the relevant code in the Flash plugin and it's certainly the case that things won't end well in the event that the font for the pop up menu isn't found. On a right click, XLoadQueryFont() is called for the following strings:

"-*-helvetica-medium-r-normal-*-10-*", "-*-serf-medium-r-normal-*-10-*", "-*-*-medium-r-normal-*-10-*",

If none of those result in a hit on the XO server, the behavior would be "undefined".

Keith

[jg]

OK, we definitely have a font problem. We only have a very few bitmap fonts present.

[olpc@xo-02-33-45 root]$ xlsfonts 
-misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1
-misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
6x13
cursor
fixed

[jg]

With the mkfontscale command, you can make a fonts.scale file for all the fonts in a directory; I did this for the deja-vu fonts. I then did a mkfontdir command to create the fonts.dir file. The last step is to get aliases for different sizes, since Flash is so antique as to not deal with scalable fonts (even in the old core font system), and worse, has pixel sizes specified.

With help from the wayback machine (www.archive.org), after extensive googling, I was able to find a script nice enough to generate a fonts.scale file for the deja-vu fonts. Bug 1291 has the more general problem, which is to provide aliases for all the old fonts.

[jg]

Oh, the final step is to add the deja-vu font directory to the font path using the "xset +fp /usr/share/fonts/deja-vu-lgc" command.

[jg]

See bug #1291 for a good project for someone to do "the right thing" for all the old bitmap fonts by aliasing.

Here's the scoop:

1. Add the following to your /etc/X11/xorg.conf:

Section "Files":
        FontPath "/usr/share/fonts/dejavu-lgc"
EndSection

Add to the directory the attached fonts.dir,fonts.scale,fonts.alias files.

Note that I only included the encoding for 8859-1, to keep the number of fonts returned by a query small, to keep antique application startup times reasonable. Otherwise, the aliases, for the 20 fonts here, end up exploding to more than 2000!

Also note I doubled the pixel size. The script for generating aliases can be found attached to #1291.

With these changes, adobe flash plug in menus will work, and have decent size bitmap fonts on the menu; the bitmaps will be derived from the fonts used elsewhere on the desktop and look sort of decent (no AA; just bitmaps). I've talked to adobe about their needing to update the flash plug in for I18N.

Coincidentally this should make many antique X applications work using our basic font set, as they may very well match against these fontnames.

[jg]

fonts.dir file for dejavu-lgc

[jg]

Fonts.scale file for dejavu-lgc

[jg]

fonts.alias file for dejavu-lgc

[dcbw]

At some point, possibly soon, we should have a flag day and pull the temporary X bitmap font stuff out again and make people fix the apps. If there's anything we shouldn't be supporting, it's apps that use the old X font APIs, because those apps have already shown they are not maintained enough to update to anything current, let alone take advantage of stuff we're shipping.

[jg]

I think we can do pull support occasionally in development builds, but the reality is that things like Flash, or Sun's Java, or other old applications exist, and may need the old fonts. Unfortunately, it will be years yet before the last of those bites the dust.

One can do it anyway just by using an "xset" command and removing the font directories, so the tests can be done by anyone at any tiem.

Anyone doing anything new is using modern toolkits anyway; I know of no significant developer activity using Xt/Xaw/Motif at this date.

[dcbw]

If flash doesn't fix themselves up, that's their problem. We're _not_ doing compatibility with old stuff just for compatibility's sake. If there are really, really good reasons to have the old bitmap font mappings, and I don't mean "so we're compatible with old applications", then maybe we'll keep them. But just so we're somewhat compatible with unnamed specific things that are of varying utility going forward isn't a good reason.

I consider the addition of mappings specifically for Flash in trial 1 an _anomoly_.

Again, just because we _can_ make something work doesn't mean we should. And I don't think in this case there's a good reason to keep this working. If people want their stuff to work on our platform, they should just not be doing some things, and this is one of them.

If you really, really want to keep this, please get a list of _specific_ applications that break, and we'll decided on a case-by-case basis whether or not we care about those applications.

[jg]

Adobe does plan to fix their player. They now understand that they can't meet the I18N requirements we have that Pango solves.

I consider it an anomaly that we don't support core fonts, at least the usual set. That something as important/common as Adobe Flash would crash is the tip of a much bigger iceberg; I expect old java applications would do likewise (those built against the original java toolkit). It is hard to eliminate the dependencies of 18 years of history, and takes a very long time to do so. Protocols never die, they just fade away....

And unfortunately, Flash is an application that we do care about: the free alternatives are not yet mature enough to deal with some of the educational content out there. I wish they were, and they are making very good progress, but they aren't there (yet).

[J5]

This is bringing down X:

Datal server error: could not open default font 'fixed'

Removing the FontPath option allows X to start up again. This needs to be figured out soon or I am taking it out of the build. I'm going ot dinner. Be back in a bit.

[jg]

Ouch. Sorry for the foul up.

Two possible fixes; it may be we need to add a "builtins" line to the xorg.conf file. But I'm not 100% sure that will fix it.

Easier, and safer, (and exactly equivalent to my testing) would be to say "xset +fp /usr/share/fonts/devjavu-lgc" and take the whole section with the font path definition out of the xorg.conf.

[jg]

Sufficient aliases for old X11 core fonts have been added that most applications not yet updated to the current X client-side font model should work: specifically, the menus in Adobe Flash 9 for Linux would crash the plug in and browser despite more than 4 years of deployment of the new X Window System font system.

Note that full internationalization is effectively using the old X Window System font system and that any application or library using them needs updating to modern standards. We see support of these fonts as a crutch that must be removed to meet OLPC's long term goals. To remove these aliases while testing, you can use the "xset -fp usr/share/fonts/dejavu-lgc" command.

"Fixed", or rather resolved, in build 385, until really fixed when Adobe Flash no longer relies on the old font system.

[frankprindle]

Since this seems to have been removed from Ship.2 (build 650), and since the latest Adobe flash plugin is not compatible with opera (so I need to use an old one), I tried to reinstate this fix, but alas the command "xset +fp /usr/share/fonts/devjavu-lgc" always fails with "bad font path element (#61)" (I event tried installing the old "misc" fonts, and it doesn't like that path either). The paths are valid, and contain fonts.*, but no-go!

jg (or others)... any clue why xset fp doesn't work? Thanks

SIDE NOTE: jg, your fonts.dir should have a 21 on the first line, not 20.

[jg]

Ugh. Someone "cleaned up" the font alias definitions the Adobe flash player needs, without thinking.....

Will be fixed in Update.1.

[frankprindle]

Sounds good... but I'm still perplexed why "xset -fp" does not work the way its man page says it should. Any clue?

[frankprindle]

Sorry, I meant "xset +fp" (I seem to have a mental block on typing this correctly!)

[bernie]

This new font path handling bug is a duplicate of #5775.