If you click on the Zotero translator icon immediately after it changes from the generic web image to the article icon, you will get the behavior you describe. You must wait until all of the ads on the page have loaded (a few seconds) only then will the metadata be downloaded. It appears that a premature click is not buffered so we must click again after the page has completely rendered.
Intermittently over the past 18 hours or so both DoubleClick and SiteScout connection issues have led to 4 to 6 second delays for us.
I have a weird situation. The first time I installed Zotero and the chrome plugin the pdf worked from Science Direct. All of the rest of the times I only get the cite and not the PDF. I read the above and tried everything. I also did the following to attempt to avoid conflicts and get the most recent code.
1. Pulled the most recent translators directly from github
2. Disabled all other extensions in chrome
3. Cross tested in Safari with no Add Ons.
4. Scrolled all the way to the bottom of the page to make sure everything was loading.
5. Disabled the Science Links Japan translator in case someone had not gotten the string parse in the code base right somehow and it was getting confused on the two translators named Science to start with.
This no PDF issue is consistent across the chrome and safari browsers on 10.10.5 OS systems in my belief.
Javascript isn't my strong suit but I can take a look at the code later and try and work out what's happening. If I get anywhere, I'll share it back.
-----
(a little update)
Ok - so I threw in a console.log to make sure the URL was correct (around line 249) and it is. From there I thought, "OK I can spend all day on this or test firefox b/c the code looks functional."
Tested in firefox. All is well. PDF download is fully functional. At this point, I'd bet it's something odd with how the other two browsers are possibly parsing javascript. Could something be type converting weird or something? No ideas really. I thankfully no longer have to code JS for my day job so the particular quirks of each browser are not in my head. Ooph. This one doesn't look so easy to deal with. Best of luck!
Upgrade Storage
Thank you for reporting! Let us know if you find something else that does not work.
If you click on the Zotero translator icon immediately after it changes from the generic web image to the article icon, you will get the behavior you describe. You must wait until all of the ads on the page have loaded (a few seconds) only then will the metadata be downloaded. It appears that a premature click is not buffered so we must click again after the page has completely rendered.
Intermittently over the past 18 hours or so both DoubleClick and SiteScout connection issues have led to 4 to 6 second delays for us.
edit @aurimus Thank you . our posts crossed.
Zotero does now create an entry from the Sciencedirect article, fails to download the PDF though. But I can absolutely live with that.
Thank you all again for your great work on Zotero!
1. Pulled the most recent translators directly from github
2. Disabled all other extensions in chrome
3. Cross tested in Safari with no Add Ons.
4. Scrolled all the way to the bottom of the page to make sure everything was loading.
5. Disabled the Science Links Japan translator in case someone had not gotten the string parse in the code base right somehow and it was getting confused on the two translators named Science to start with.
This no PDF issue is consistent across the chrome and safari browsers on 10.10.5 OS systems in my belief.
Javascript isn't my strong suit but I can take a look at the code later and try and work out what's happening. If I get anywhere, I'll share it back.
-----
(a little update)
Ok - so I threw in a console.log to make sure the URL was correct (around line 249) and it is. From there I thought, "OK I can spend all day on this or test firefox b/c the code looks functional."
Tested in firefox. All is well. PDF download is fully functional. At this point, I'd bet it's something odd with how the other two browsers are possibly parsing javascript. Could something be type converting weird or something? No ideas really. I thankfully no longer have to code JS for my day job so the particular quirks of each browser are not in my head. Ooph. This one doesn't look so easy to deal with. Best of luck!