Linux: type application/pdf cannot be handled natively

ngoonee
(5)(+0000000): SELECT IA.itemID FROM itemAttachments IA NATURAL JOIN items I LEFT JOIN itemData ID ON (IA.itemID=ID.itemID AND fieldID=1) LEFT JOIN itemDataValues IDV ON (ID.valueID=IDV.valueID) WHERE sourceItemID=? AND linkMode NOT IN (?) AND IA.itemID NOT IN (SELECT itemID FROM deletedItems) ORDER BY mimeType='application/pdf' DESC, value=? DESC, dateAdded ASC

(5)(+0000000): Binding parameter 1 of type int: 107

(5)(+0000000): Binding parameter 2 of type int: 3

(5)(+0000000): Binding parameter 3 of type string: ""

(3)(+0000003): MIME type application/pdf cannot be handled natively

So the mimetype of my PDF is found properly, but Zotero then informs me that it cannot be handled natively. I'd like to ask what mechanism is used to determine 'native handling' on Linux. As far as I know the closest thing to a standard is xdg-open, but that works fine (uses my selected default).

What happens after the above line is that the URI is passed back to Firefox to open using Firefox's default. Obviously, I have firefox's default set to 'let me choose' because I do want to download PDFs from time to time (and not have them all dumped in the same folder). Previously this used to work but it just recently stopped. This is probably more an issue with my system, but to debug it it'd help if I know exactly what zotero was trying to do to give the above line.
  • adamsmith
    http://www.zotero.org/support/kb/file_handling_issues
    this works in general on linux
  • ngoonee
    Not in my case, it used to do so. Thanks for the link though. If that did work, I would not be getting the last debug line in my original post (cannot be handled natively).
  • dstillman
    First, "cannot be handled natively" just means that Firefox can't handle the file itself and there's no plugin to handle it. (That line should really say "internally", and I've changed it to do so on the trunk.)

    If a file can't be handled internally, it's just passed to the OS. What happens next on Linux is mostly a mystery and depends on your OS, your window manager, and the current relative humidity, but in addition to the linked page there are various forum threads that detail some things you can check. You shouldn't get a Firefox prompt after that line above unless your OS is set to open files in Firefox.

    But make sure you've deleted (or moved) mimeTypes.rdf and restarted Firefox before trying anything else, since corruption there causes various weirdness.
  • ngoonee
    I've read the threads (http://forums.zotero.org/discussion/7250/linux-choose-program-to-open-pdf-files-from-zotero/#Item_16 was created by me, and another 2 that I read at that time are listed there).

    What you're basically saying is that my OS is passing the link back to firefox. I would have thought xdg-open would be the one handling this (esp since defaults.list keeps getting mentioned), but that works with file:/// links (I assume that's what zotero passes out).

    mimeTypes.rdf has been removed multiple times as well.

    How do I figure out what firefox is calling in my OS (and what, if any, results are returned)?
  • dstillman
    strace Firefox? You're pretty much on your own here. Known fixes have been documented, and beyond that there are too many variables on different Linux systems for us to advise you.

    There's a launch() method in Firefox. We call that. On some systems that might not be supported, in which case Zotero would pass a file:// URL to Firefox, but generally launch() is supported. There's no debug output there in release versions, but I've added a debug line to the trunk to indicate when the file:// fallback is being used.
  • ngoonee
    Thank you Dan, I just tested with trunk, indeed I get this:-

    launch() not supported -- passing file to loadURI()

    Sad to hear there's not much more I can do from the zotero end. Will continue to troubleshoot, thanks for your help.
  • dstillman
    So just to be clear, if that's the case then you can probably ignore all the stuff about OS-based launching, since then it really is just passing the file to Firefox.

    But while it's been a few years since I've looked into it, I didn't think launch() failed on all Linux systems, so I'd be curious whether other Linux users on the trunk (or in the next release) see that line. For what it's worth, here's the documentation for that method:
    Asks the operating system to attempt to open the file. This really just simulates "double clicking" the file on your platform and thus only works on platforms which support this functionality.
  • dstillman
    There's also another method we could use, though I'm not sure if it works for non-executable files. If someone curious wants to test this before we get to it, the relevant code is in viewAttachment() in zoteroPane.js.

    That page also notes this:
    This method is not implemented on all platforms, especially not on Unix/Linux!
    For the really curious, there's a 10-year-old Mozilla bug that talks more about the details. (But please don't post to it.)
  • fcheslack
    launch works for me in Ubuntu on firefox 3.6 but not 4rc.
  • ngoonee
    I'm recompiling my firefox4 with --with-system-nspr, will see if that helps. May simply be an incompatibility there. I'm pretty sure based on previous experience that firefox doesn't normally do desktop-specific stuff (so the fact that I'm using awesomewm rather than a 'normal' DE should not affect stuff).
  • ngoonee
    And the compilation just finished, that indeed solved things (for me). It now uses xdg-open (like it used to do with firefox3). Thanks a million Dan Stillman, could not have figured this out myself.
  • dstillman
    Great. For what it's worth, launch() works for me on Ubuntu with the stock Firefox 4 RC from mozilla.org.
  • ngoonee
    I'm on Arch Linux, I'm pretty sure the firefox4 downloads from mozilla.org have nspr (and other lib) versions which are compatible with the big distros. At Arch we get software just as soon as a stable is released (nspr 4.8.6 was on 18th August last year, nspr 4.8.7 was 1st Feb), so the compiled-in nspr in the firefox4 download was probably somehow incompatible.

    Normally to circumvent this we compile with as many system-libs as possible, have contacted the maintainer for firefox4 to ask him to change that. Thanks again.
  • rvandegrift
    I recently started having this issue as well, on Debian. Zotero has been working fine for months. I recently enable Firefox Sync. Is there any chance you started using Sync?

    I haven't tried disabling it yet.

    Ross
  • ngoonee
    No, it wasn't Sync (though I do use that). The new firefox4 package in my distro disabled gnomevfs and used gio instead, causing the difference.
Sign In or Register to comment.