DEC
20
2007
|
Why Flash sucksAs one of my colleagues notes, this statement holds true on its own. However, for those like me too blind to see some things, there are two things about Flash you should know:
Do the maths yourself. Or just watch it happen as soon as your distribution's update hits your machine. I'm not going to comment on the first one, but, as a person who has spent a good portion of the last two weeks trying to find a solution, I know some things about the second. First of all, this is apparently perfectly fine with Adobe. According to their system requirements page, they care only about Firefox, Mozilla or SeaMonkey. Tough luck if you use something else (by the way, according to the latest Linux desktop survey, this something else is at least a quarter of Linux users). Imagine a critical security issue that will exist only when using Flash in Konqueror or Opera but not in Firefox (for whatever reason, like Adobe testing Flash only in Firefox) - care to guess what happens in such case? After all, you can give it a little test - just try to find out what happens if you complain to them that Flash doesn't work for you in Konqueror. You know, I haven't been a huge fan of Moonlight, but there's definitely at least one thing to like about it - it's open source. Doesn't work? Have a look at the code. Not so with Flash player. The reason why the latest Flash doesn't work originally appeared to be its new support of some Mozilla XEmbed-based extensions to the plugins API (funny thing about that link is, it says that it finally makes it work with Opera, while in fact it's exactly the opposite). After adding XEmbed support to Konqueror, it still didn't work. The page about the XEmbed extension has demo code hardcoding a hard dependency on Gtk2, so maybe adding Glib2 eventloop support will make it work? After all, the Flash system requirements page mentions this (well hidden in a footnote, if you look close enough), but not really, tough luck, even though the DiamondX testing plugin already works. Do you know what a ballistic approach to debugging is? You either hit, or you don't. Here next hit is that this Flash version doesn't handle properly repeated NPSetWindow() calls, which however happens to be the case with Konqueror. So finally, does it work? Well, kind of, if you don't mind it crashing everytime you leave a page. And it crashes in XtRemoveTimeOut() (incidentaly, a function that should not be called by a Gtk2-based plugin). That's been already taken care of as well - it's enough to give Flash the user agent string from Firefox, suddenly, no crash (I have no idea how Maksim managed to find this out - probably involved sacrificing chicken or something). So, when can you expect the latest Flash to work with KDE? I have no idea. There are some preliminary patches I've made and committed to SVN, those may or may not work for you, depends on how lucky you'll get. Given that people report random crashes with those, I really meant to say lucky. Right now I'm trying to debug another issue where a proper fix that should remove a race condition actually prevents it from working. I also can't get keyboard focus right, even though debug output from DiamondX seems to look correct and I can't see any significant difference to Firefox. Maybe my fault ... maybe not, given what I know about how Flash handles keyboard input (you don't want to know).Opera people apparently have been more lucky with dealing with this, their latest beta should work better, but I could notice some problems there as well. So, sorry. E.g. OpenSUSE will probably ship KDE updates for this tomorrow, but I suppose you'll be better off using the one true browser for the time being, if you need Flash. Next time I provide KWin videos only on youtube, somebody please yell at me. A lot. I'll deserve it. PS: Yes, I know a Flash developer contancted kfm-devel somewhen in the past asking about XEmbed support. That still doesn't make debugging Flash any less painful, which is why the workarounds for it will take unknown time. It also doesn't change anything about Adobe not really giving a damn about Konqueror or Opera, if they could suddenly drop backwards compatibility (even though the code is probably still there, if it can still call XtRemoveTimeOut() and crash on it).
|
![]() |
Comments
Sorry to hear, but...
Sorry to hear that depressing news. I beliece that it is very frustrating to debug something you cannot even look at properly.
However, you can be sure of one thing: the people using Konqueror with the new Xembed support are very thankful for what you've did - even if it does not work properly in all cases, it is definitely working in several cases, and you make many people happy.
Thanks for that!
Use Stage 6, please
Please, remember that Stage6 allows you to dowload the video in a normal file format (i.e., a fileformat that you can open in kaffeine, and seek back and forward), and that doesn't requires flash at all.
I have flash completely disabled in Konqueror, and only enabled in a i386 chroot, so this stuff you explain is only another drop in a lake full of inconvenience and problems.
Interesting note on multiple NPSetWindow...
Will try to check whether trunk does that... I guess I should play with DiamondX a bit too, completely forgot about it, and I don't have your X skills to deal with this sort of stuff...
whoha!! that really stinks,
whoha!! that really stinks, I ve been getting sigsev signals on konqui.. Now I've been using gnash-kde for quite a while, and apart from not supporting ActionScript3 it rock solid, it easy on cpu while doing compositing. I 'm not saying gnash it's the all in one/magical solution (tm), at this point it lacks some "must have", but It wouldn't surprise me if next year gnash would be default in every distro and, besides maybe getting some more fancy features than adobe's, as it is open source.
cheers
here is the homepage if someone wants to try out
http://www.gnu.org/software/gnash/
ick.
oh god... I've been seeing little things that make me uncomfortable for a while, but this is a huge one. it feels like browser lock-in all over again - but this time with firefox instead of IE. you'd think an open source browser wouldn't be able to achieve lock-in... but... I'm not so sure any more. I hope I'm just being paranoid.
of course, the real solution is for some brilliant people to make the open source plugin work, and work well. such a shame that so much coding time has to be spent working around proprietary nonsense. I wonder just how hard it is...
swfdec
My wish is that people starts looking more closely at swfdec :
http://swfdec.freedesktop.org/wiki/
It is far from being a perfect Flash implementation (yet?), but at least :
- it is free,
- it works on amd64,
- i did not try yet, but i presume it works with non-gecko browsers.
I installed swfdec on Debian testing/amd64 in order to download a mp3-player firmware from this d****ed flash-only site :
http://prod-media.samsungmobile.fr/microsite/firmwares
(BTW, amazing how Microsoft and its partners are pushing for MTP protocol over UMS regarding mp3 players.)
wow
For a security fix this update sure broke alot. Is there any news on this working any time soon?