Open Bug 748643 Opened 8 years ago Updated 7 years ago
scheme/protocol and mime type support not available on debian sid
1018 bytes, text/plain
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Build ID: 20120410121533 Steps to reproduce: installed xchat on Ubuntu GNU/Linux 12.04 xchat installs protocol handler here: /usr/share/gconf/schemas/apps_xchat_url_handler.schemas (attached) open irc:// scheme link Actual results: option for mibbit, but no xchat. Furthermore, as xchat does not support the simple "xchat $URL" format, selecting it by the file dialogue does not work, also, entering the above schemas file in the file dialogue does not work as is documented in the scheme file xchat needs "xchat --existing --url=%u" Expected results: it should have opened the irc channel in the existing xchat window as per the scheme file xchat installed -- this is a regression most likely caused by Bug 435687
BTW i reproduced this in a fresh profile
Can you try to find the exact regression range ? https://github.com/mozilla/mozregression helps with that.
nightly from 2009-02-07 (using mozregressions) clicking on IRC link loads http://www.%u.com/ in system firefox
nightly from 2009-02-07 (using mozregressions) clicking on IRC link loads http://www.%u.com/ in system firefox after clicking OK when seleted item in dialogue is "xchat" without a icon
i tried fallowing the clone() call that happens when you send the irc link with the external handler, but strace -f doesn't work cause way too much noise with normal fork()s.
mozregression should give you a last good, first bad and a pushlog link. Can you post this ?
Last good nightly: 2009-05-04 First bad nightly: 2009-05-05 im working on a full bisect
I am unable to complete a bisect because the old version wont compile on my computer with linux3+ ../coreconf/config.mk:71: ../coreconf/Linux3.2.mk: No such file or directory and then after using setarch, i still couldn't build ../../../dist/include/system_wrappers/gdk/gdk.h:3:26: fatal error: gdk/gdk.h: No such file or directory so i guess i just dont have the infrastructure for such old moziila
Thank you very much for narrowing down the regression range ! There is nothing in that pushlog that looks suspect to me. Maybe it's only the dialog that is not coming up ? Can you switch network.protocol-handler.warn-external-default to false in about:config in a not working build ? (change it please back to the default after testing)
First of all, the "Launch Application" dialog appears in ALL Firefox's that I tried (that didn't crash on startup) in 2009-05-04 the dialog contains "xchat" (without logo), and "Mibbit" (with logo). in 2009-05-05 the dialog contains only "Mibbit" (with logo). The Mibbit patch adds the Mibbit option, but doesn't not effect the "xchat" option. --- To be clear, even the builds 2009-05-04 and before (and all the way back to 2009-01-01, which is the earliest mozregression will go) don't actually launch xchat correctly, as is documented above, this could be to some assumptions in the way the external handler ( bug 33282 ) and multiple profiles / assumes it is installed system wide / assumes firefox is in the path (or the way in which mozregression works with profiles). I tried (above) to debug this, but was unsuccessful without a sufficient tool.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
QA Contact: untriaged → gtk
http://hg.mozilla.org/mozilla-central/rev/c2ba27e9e639 enabled libnotify support. Unfortunately libnotify changed its ABI (bug 628222) and so most modern distributions probably don't have the version that our builds need to use libmozgnome.so. That provides the GConf support. I guess we should use the DBus interface rather than libnotify. Haven't checked how stable that has been, but it may be easier to deal with variations through DBus.
Status: UNCONFIRMED → NEW
Component: Widget: Gtk → General
Ever confirmed: true
Product: Core → Toolkit
QA Contact: gtk → general
Summary: irc:// scheme broken on desktop linux → scheme/protocol and mime type support not available due to missing libnotify shared object
Version: 11 Branch → Trunk
# dpkg -L libnotify4 /. /usr /usr/share /usr/share/doc /usr/share/doc/libnotify4 /usr/share/doc/libnotify4/AUTHORS /usr/share/doc/libnotify4/NEWS.gz /usr/share/doc/libnotify4/copyright /usr/share/doc/libnotify4/changelog.Debian.gz /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libnotify.so.4.0.0 /usr/lib/x86_64-linux-gnu/libnotify.so.4 # lsof -p 14187 | grep libnotify firefox 14187 scientes mem REG 0,16 442340 /usr/lib/x86_64-linux-gnu/libnotify.so.4.0.0 (path dev=0,18)
Sounds like there are a couple of different issues here. The libnotify ABI change explains the regression range from nightly builds (comment 8). Mozilla builds need libnotify.so.1. The build in comment 0 is an Ubuntu build, I assume. Check about:buildconfig. I expect it is built with --enable-gio, and so it would check GIO for protocol handlers rather than GConf (which would read /usr/share/gconf/schemas/apps_xchat_url_handler.schemas). I wonder what Mibbit installs that GIO uses and xchat doesn't install?
--enable-gio in the ubuntu build the build running in comment 15 is also the Ubuntu build, and i did try with a new profile running the ubuntu build. (no dice) As a side note, there is zero irc:// scheme handling in fennec TRUCK AFAICT
If the file /usr/share/applications/xchat.desktop contained the line "MimeType=x-scheme-handler/irc;x-scheme-handler/ircs;" then things might work better. I'm not sure what updates /usr/share/applications/mimeinfo.cache though.
>I'm not sure what updates /usr/share/applications/mimeinfo.cache though. update-desktop-database http://library.gnome.org/admin/system-admin-guide/stable/mimetypes-registering.html.en --- that make XChat show up in the list alright, but its not right, as it launches a new xchat WITHOUT THE ASKED FOR CHANNEL instead of opening the channel in the existing xchat (if it exists), which takes special parameters the attached scheme file specifies (also the xchat manpage)
I expect there is a way to specify "xchat --existing --url=%u" with an Exec line in a .desktop file, but I don't know whether that can be done in the same .desktop file as used to first start xchat, or whether the idea is to use a separate .desktop file with a different exec line for the x-scheme-handler/irc(s) MimeTypes.
but why cant we expect firefox to work with the .scheme file without the mime type stuff being redundant?
Some (GNOME?) people have decided to deprecate GConf and move to a different system. The final move there was http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=f4ef02038a1f57edf7a23ba91829f15cddfc7eff They expect all applications to change and use the new system.
OK, also, the new system seems far less verbose, but only if it can fit in the application's .desktop file, so that makes me like it quite a bit more so i guess this is a bug in xchat (not supporting the new way), AND Firefox, (for not working with the old way since 2009)
(In reply to Karl Tomlinson (:karlt) from comment #22) > Some (GNOME?) people have decided to deprecate GConf and move to a different > system. For your interest, GNOME uses GSettings (part of Glib/Gio, see http://developer.gnome.org/gio/unstable/GSettings.html ) which supports backends such as gconf (deprecated) or dconf (the default in GNOME).
There is already an xchat bug for this: https://launchpad.net/bugs/933822 (In reply to Karl Tomlinson (:karlt) from comment #20) > I expect there is a way to specify "xchat --existing --url=%u" with an Exec > line in a .desktop file, but I don't know whether that can be done in the > same .desktop file as used to first start xchat, or whether the idea is to > use a separate .desktop file with a different exec line for the > x-scheme-handler/irc(s) MimeTypes. Normally, the application would supply a second desktop file with NoDisplay=true for this. Some applications already do this (eg, brasero)
I filed bug 750141 for the libnotify issue. Sounds like the bug described in comment 0 is the xchat package bug, so closing this report.
This bug is still present with nightlies on debian sid, as can be see with transmission-gtk which has this in the .desktop file MimeType=application/x-bittorrent;x-scheme-handler/magnet; and yet nightly doesn't recognize it as a provider of magnet links
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
hmm, doesn't work with iceweasel 25 either
Summary: scheme/protocol and mime type support not available due to missing libnotify shared object → scheme/protocol and mime type support not available on debian sid
You need to log in before you can comment on or make changes to this bug.