ACM Digital Library translator fails when HTTPS Everywhere is enabled

Saving from the ACM Digital Library reliably fails when the Firefox Add-On HTTPS Everywhere is enabled. There are no error messages reported to the console, which is why I did not submit an error report. The symptom is an empty white box in the lower right corner, which disappears after ~60sec, presumably when the request for the resources which HTTP Everywhere redirects times out.

Reproducible: always

Steps to reproduce:
1. Install the HTTPS Everywhere add-on (https://www.eff.org/https-everywhere)
2. Try saving any item from ACM Digital Library (e.g. https://dl.acm.org/citation.cfm?id=567085, but I tried various, it is *not* an item-specific issue)

Disabling HTTPS Everywhere (which is obviously not an option for me) reliably solves the issue.
  • so, when you go to the link above - i.e. the address with https - but with the add-on disabled, this works for you?

    I doubt we can do much about this. The translator is very clean code, there aren't any hardcoded http or so in there, so if it doesn't work with https everywhere that most likely means the acm site doesn't play well with https everywhere.

    What the translator does is switch the site to single-field mode and then export the bibtex and download it - I'd be curious if that works if you do it manually with the add-on enabled.
  • Yes, it works from the link above with the add-on disabled. I can also manually download the file with the add-on enabled, so that seems not to be the issue.

    I've now managed to get some errors logged to the console, which seems to relate to an image rather than the PDF. I'm seeing this error a few dozen times:

    Timestamp: 24/07/12 09:50:18
    Error: [Exception... "'Image HTTP->HTTPS redirection to https://dl.acm.org/images/ACM_mini.jpg' when calling method: [nsIContentPolicy::shouldLoad]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no]

    I doubt it's caused by zotero though, since when I clear the console and try to save the citation to zotero no errors are logged.

    Also clicking on the PDF link and then selecting "Save to Zotero" from the context menu works fine. It's really the translator that fails it seems.
  • the relevant info for Zotero would be in the debug log:
    http://www.zotero.org/support/debug_output
    but the error log seems to indicate that it is indeed the site that's not working well with https everywhere. Since Zotero's translator makes additional http(s) requests it could well be that something breaks on the way, but I really can't think of anything we could do about that. You can try reporting this to ACM and https everywhere.
  • I've uploaded a debug log: D1584276364

    This time the white box did not disappear - left it running for > 30min and it's still there.

    I'll report to ACM and HTTPS Everywhere. Presumably they'll also want some debug information.
  • I've reproduced this with HTTPS Everywhere installed.

    Here's the relevant debug output:
    zotero(4)(+0006848): Translate: Parsing code for ACM Digital Library

    zotero(3)(+0000001): Translate: Beginning translation with ACM Digital Library

    zotero(3)(+0000001): Translate: bibtex URL: http://dl.acm.org/exportformats.cfm?id=567085&parent_id=567067&expformat=bibtex

    zotero(3)(+0000001): HTTP GET http://dl.acm.org/exportformats.cfm?id=567085&parent_id=567067&expformat=bibtex

    TypeError: sink.asyncOnChannelRedirect is not a function
    That last error is from HTTPS Everywhere. Simon might have some ideas here, but if that error doesn't happen under any other circumstances I'd guess that this has something to do with the translator sandbox.

    Also, for reference, kynan's post to the HTTPS Everywhere tracker: https://trac.torproject.org/projects/tor/ticket/6499
  • I looked into this, and it's definitely not our bug. I filed Mozilla bug 780529 on the primary cause. The secondary cause seems to be an issue with error handling; I'm not sure who to blame for that.
  • I'm also observing the same bug with the same workaround, reliably.
    Thanks to the HTTPS Everywhere and Mozilla folks who are working on it.
Sign In or Register to comment.