| Summary: | www-client/chromium hangs while loading page in user mode, but not as administrator + workaround | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | George Reitsma <g.p.reitsma> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | andriy155, follettoonip, ian, jackdachef, notordoktor, phajdan.jr, voyageur |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | http://code.google.com/p/chromium/issues/detail?id=24507 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
George Reitsma
2010-03-13 08:48:18 UTC
Thanks for the report. This is really an upstream bug, but I've applied a workaround to chromium and chromium-bin ebuilds. There's now a blocker for gecko-mediaplayer if USE="plugins-symlink" is enabled (it makes the browser use the system plugins). If you want to have gecko-mediaplayer installed, please re-emerge the chromium package with USE="-plugins-symlink" and control its plugins manually. I am just curious, what mplayer plugin should i use with chromium now? mplayerplug-in was unfortunately removed from portage last year. (In reply to comment #1) > Thanks for the report. This is really an upstream bug, but I've applied a > workaround to chromium and chromium-bin ebuilds. There's now a blocker for > gecko-mediaplayer if USE="plugins-symlink" is enabled (it makes the browser use > the system plugins). > > If you want to have gecko-mediaplayer installed, please re-emerge the chromium > package with USE="-plugins-symlink" and control its plugins manually. > Andriy, I don't have a good idea. Hopefully we'll see more and more HTML5 audio/video support, and that would solve this problem. (In reply to comment #3) > Andriy, I don't have a good idea. Hopefully we'll see more and more HTML5 > audio/video support, and that would solve this problem. > Hope so! Dzieki, Pawel! (In reply to comment #1) Thanks for the workaround! Let's hope indeed for something like HTML5. Well, this was the only player plugin that actually did something with chromium... so, meh, wondering about alternatives as well. FWIW, I didn't have the issue described here at all. Since I know that you are involved with upstream, here are two suggestions: - why are these separate symlinks even needed for chromium. Can't it pick those up in /usr/$(get_libdir/nsbrowser/plugins like other browsers, without special symlinks? (Already noted that wrt the ffmpeg stuff, and that one's even in /usr/$(get_libdir) but chromium specifically chooses to ignore it, eh... - maintaining an internal blacklist of incompatible plugins and blocking those on runtime should be easy enough. Also, let users disable/enable plugins via some GUI, like it's already possible with chrome://extensions/ For the first problem, feel free to submit an upstream bug report. For the second one, see http://code.google.com/p/chromium/issues/detail?id=736 (In reply to comment #7) > For the first problem, feel free to submit an upstream bug report. Well, that boils down to - is a bad design choice a bug? :P > For the second one, see http://code.google.com/p/chromium/issues/detail?id=736 I know about that bug, that's one of those WTF ones, with neverending debate and nothing being done despite the issue being important for wide user community and easy to implement. Every project has this kind of bugs they stubbornly refuse to implement for some weird reason and keep people ranting about it over and over again. (In reply to comment #8) > Well, that boils down to - is a bad design choice a bug? :P Yes, it is. > > For the second one, see http://code.google.com/p/chromium/issues/detail?id=736 > I know about that bug, that's one of those WTF ones, with neverending debate > and nothing being done despite the issue being important for wide user > community and easy to implement. If you think it's easy, how about submitting a patch? http://www.chromium.org/developers/contributing-code (In reply to comment #9) > If you think it's easy, how about submitting a patch? > http://www.chromium.org/developers/contributing-code You know, being easy for people familiar with the code doesn't mean easy for generic public. :P Anyway, if I find enough motivation we could continue this debate on upstream bug. Meanwhile I've noticed the all-or-nothing approach (with all-or-nothing expections per site) has been implemented, which is another ugh... I don't believe anyone asked for that. People want per-plugin toggle button. Anyway, getting OT here, not Gentoo-specific. (In reply to comment #6) > Well, this was the only player plugin that actually did something with > chromium... so, meh, wondering about alternatives as well. I don't know if anyone tried. But on the gecko-media player message board (hosted on Google), they suggest that compiling this player with the "gconfd" disabled (in gentoo, -gnome use flag) the player is supposed to work. If that works, it would a whole lot nicer. (In reply to comment #11) > I don't know if anyone tried. But on the gecko-media player message board > (hosted on Google), they suggest that compiling this player with the "gconfd" > disabled (in gentoo, -gnome use flag) the player is supposed to work. > > If that works, it would a whole lot nicer. Well, that's what I have had here all the time, and... > FWIW, I didn't have the issue described here at all. :) (In reply to comment #11) > I don't know if anyone tried. But on the gecko-media player message board > (hosted on Google), they suggest that compiling this player with the "gconfd" > disabled (in gentoo, -gnome use flag) the player is supposed to work. Could you post a link to that message? (In reply to comment #13) > (In reply to comment #11) > > I don't know if anyone tried. But on the gecko-media player message board > > (hosted on Google), they suggest that compiling this player with the "gconfd" > > disabled (in gentoo, -gnome use flag) the player is supposed to work. > > Could you post a link to that message? > Of course, see the last message on this threat: http://code.google.com/p/gecko-mediaplayer/issues/detail?id=64 Regards, George (In reply to comment #14) > Of course, see the last message on this threat: > http://code.google.com/p/gecko-mediaplayer/issues/detail?id=64 I tested w/ all versions in portage, incl. 5.0.342.5 and can completely confirm the above. www-plugins/gecko-mediaplayer with USE=gnome (which makes it to do some weird gconf stuff) breaks it. Without this flag, no such issue arises. May I suggest tweaking the blocker like this? -!www-plugins/gecko-mediaplayer +!www-plugins/gecko-mediaplayer[gnome] That's what I've done in local overlay and have no issue with that. Thanks, I've updated the blocker. *** Bug 325867 has been marked as a duplicate of this bug. *** thanks for getting this to work ! Sorry to resurrect an old bug, but the newer versions of gecko-mediaplayer both have gconf permanently disabled (no more gnome USE flag) and have chromium as a permanent blocker. Does this mean that the new versions of Gecko Media Player kill Chromium even with gconf disabled? |
