Unable to generate Report

When attempting to generate a report firefox gives the following 'Alert' error message:

"Firefox doesn't know how to open this address, because the protocol (zotero) isn't associated with any program."

Can somelone let me know what setting I need to fix to resolve this problem?

  • edited October 28, 2009
    There's some sort of problem in your Firefox profile. Try deleting compreg.dat and xpti.dat and restarting Firefox. If that doesn't help, try disabling your other Firefox extensions.
  • After yet annother re-start of firefox, the error has changed.
    Error ID generated by program is: 1652893910

    Error produced by right-click and choosing ot generate a report form one particular folder of collection.

    Error no longer produces seperate window, but the following output on the web page generated:

    XML Parsing Error: not well-formed
    Location: data:application/xhtml+xml,%3C!DOCTYPE%20html%20PUBLIC%20%22-%2F%2FW3C%2F%2FDTD%20XHTML%201.0%20Strict%2F%2FEN%22%20%22http%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2FDTD%2Fxhtml1-strict.dtd%22%3E%0A%3Chtml%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22%20xml%3Alang%3D%22en%22%3E%0A%3Chead%3E%3Cmeta%20http-equiv%3D%22Content-Type%22%20content%3D%22text%2Fhtml%3B%20charset%3Dutf-8%22%20%2F%3E%0A%3Ctitle%3EZotero%20Report%3C%2Ftitle%3E%0A%3Clink%20rel%3D%22stylesheet%22%20type%3D%22text%2Fcss%22%20href%3D%22zotero%3A%2F%2Freport%2Fdetail.css%22%2F%3E%0A%3Clink%20rel%3D%22stylesheet%22%20type%3D%22text%2Fcss%22%20media%3D%22screen%2Cprojection%22%20href%3D%22zotero%3A%2F%2Freport%2Fdetail_screen.css%22%2F%3E%0A%3Clink%20rel%3D%22stylesheet%22%20type%3D%22text%2Fcss%22%20media%3D%22print%22%20href%3D%22zotero%3A%2F%2Freport%2Fdetail_print.css%22%2F%3E%0A%3C%2Fhead%3E%0A%0A%3Cbody%3E%0A%3Cul%20class%3D%22report%20combineChildItems%22%3E%0A%0A%3Cli%20id%3D%22i140%22%20class%3D%22item%20journalArticle%22%3E%0A%3Ctable%3E%0A%3Ctr%3E%0A%3Cth%3EType%3C%2Fth%3E%0A%3Ctd%3EJournal%20Article%3C%2Ftd%3E%0A%3C%2Ftr%3E%0A%3Ctr%3E%0A%3Cth%3EDate%20Added%3C%2Fth%3E%0A%3Ctd%3ETuesday%2C%206%20October%202009%2010%3A58%3A32%20PM%3C%2Ftd%3E%0A%3C%2Ftr%3E%0A%3Ctr%3E%0A%3Cth%3EModified%3C%2Fth%3E%0A%3Ctd%3ETuesday%2C%206%20October%202009%2010%3A58%3A45%20PM%3C%2Ftd%3E%0A%3C%2Ftr%3E%0A%3C%2Ftable

    ... [total output too long to post, so have deleted middle chunk] ...

    Line Number 338, Column 103:http://heinonline.org.ezp.lib.unimelb.edu.au/HOL/Page?handle=hein.journals/glj94&div=10&;
  • thanks for the speedy response Dan. Deleted the files, but problem remains. Sent annother error report, Number 434318733.

    Have been to Preferences and clicked 'Check Database Integrity', but it said no errors were found.

    A report on the parent folder works fine, including the items in this folder. tried copying all items in this folder into a new folder, but problem persists.
  • edited October 28, 2009
    Can you find a single item that causes the problem? E.g., the HeinOnline item referenced above? You can select items in halves to quickly find the smallest possible set that still produces the error.
  • found a group of items, all last modified on 17 october 2009 falling between 07:40:00 to 07:50:00.
    deleting them works, but duplicating doesn't help. restoring from trash recreates the problem.
  • I think I have found the problem.
    All of them had dates that were in the format '2003-2004'. this was inserted by the translator. changing this to a single year, eg '2003' fixes the problem.
    The code may need to be changed to restrict the date formats.

    thanks for your help in de-bugging
  • Spoke too soon - problem re-appeared, however deleting the URL does seem to have fixed it.

    In case there is something in the URL that is a problem for Zotero, I have added a few examples for you.

    http://heinonline.org.ezp.lib.unimelb.edu.au/HOL/Page?handle=hein.journals/nclr85&div=48&collection=journals&set_as_cursor=20&men_tab=srchresults&terms=89 Cornell L. Rev. 621&type=matchall

    http://heinonline.org.ezp.lib.unimelb.edu.au/HOL/Page?handle=hein.journals/glj94&div=10&collection=journals&set_as_cursor=6&men_tab=srchresults&terms=89 Cornell L. Rev. 621&type=matchall

    http://heinonline.org.ezp.lib.unimelb.edu.au/HOL/Page?handle=hein.journals/ukalr53&div=22&collection=journals&set_as_cursor=12&men_tab=srchresults&terms=89 Cornell L. Rev. 621&type=matchall

  • Yes, the URL was the problem. We'll fix it. Thanks.
  • Fixed in the latest dev build.

    As a temporary workaround, you could replace the spaces in the URLs above with the "+" (plus) character, which is equivalent and should allow the URLs to still load properly. (The translator should probably do that itself for URLs with spaces, anyway.)
  • Thanks Dan.

    There is also a problem with re-naming a file from parent meta data. It usually works, but not with HeinOnline. Thought I should mention it if you are doing a Hein fix.

    More generally, although the re-naming works outside of Hein, it doesn't add meta data to the file properties (which is useful if you use an e-book reader or similar software as they display be author and title form the file properties meta data (at least the Sony one does).

  • There is also a problem with re-naming a file from parent meta data.
    I suspect you're just seeing this behavior, which will be changed. If the file itself isn't actually being renamed, you'll need to provide a Report ID.
    although the re-naming works outside of Hein, it doesn't add meta data to the file properties
  • I am not consistently able to generate a report. Some articles seem to produce this error message:
    XML Parsing Error: not well-formed
    Location: data:application/xhtml+xml,%3C!DOCTYPE%20html%20PUBLIC%20%22-%2F%2FW3C%2F%2F [snip] E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E
    Line Number 84, Column 335:<p>Accession Number: 41552379; Authors: Cunningham, Matthew 1; Affiliations:  1: Victoria University of Wellington, New Zealand.; Subject: KENNEDY, John F. (John Fitzgerald), 1917-1963; Subject: SPACE flight to the moon; Subject: OUTER space -- Exploration -- Economic aspects; Subject: UNITED States. National Aeronautics & Space Administration; Subject: OUTER space -- Exploration -- Public opinion; Subject: MILITARISM; Subject: PRESTIGE; Subject: GLENN, John, 1921-; Subject: OUTER space; Subject: UNITED States; Number of Pages: 14p</p>

    The Line Number, Column number, and the subsequent information vary depending on which article _appears_ to be the 'cause' of the problem. Approximately one quarter of the articles I had grabbed were troublemakers.... I have not noticed any commonalities between the offending articles....
  • UPDATE: It _appears_ that the problem is in the automatically generated notes folder. If I copy the contents of that note folder (Accession Number: 24441837; DeGroot, Gerard 1; Affiliation: 1: Professor of Modern History, University of St Andrews; Source Info: Mar2007, Vol. 57 Issue 3, p11; Subject Term: SPACE race; Subject Term: OUTER space -- Exploration; Subject Term: UNITED States; Company/Entity: UNITED States. National Aeronautics & Space Administration; NAICS/Industry Codes: 927110 Space Research and Technology; People: KENNEDY, John F. (John Fitzgerald), 1917-1963; Number of Pages: 7p; Document Type: Article; Full Text Word Count: 3923), delete the folder, and then create a new note folder and paste the information in it I am able to generate a report with no difficulty........ But if I don't do that I get the error message described above.
  • I'm having the same problem. I'm running Zotero 2.1.6 with Firefox 3.6.16 . The issue seems to be an embedded ampersand.

    Here's a two-line test import file:

    TY - JOUR
    N1 - Copyright & Business

    Removing the & eliminates the error message. I also see one in Chris' file above, "National Aeronautics & Space Administration", more or less where the ---^ points.

    This is probably one of those common HTML processing errors — if an input & isn't stored as the character entity "&amp;" or converted to it on output, it will be interpreted as the beginning of another character entity when it's processed.
  • Looks like this happens with imported notes containing special XML characters before the notes are loaded into the note editor, at which point TinyMCE converts them to entities in order to produce valid XHTML.

    We'll have to figure out the best place to deal with this. In the meantime, viewing the note should fix the problem.
  • We've put in a temporary workaround to address this, available in the latest 2.1 Branch dev XPI. It'll be in 2.1.7.
Sign In or Register to comment.