Closed GerHobbelt closed 5 years ago
Fixed in commit SHA-1: c28eb11f56529af7d6f6497b08505288fef7546c. I hope.
The side-effect is that for proper PDF fetches (via the PDFInterceptor class), the PDF is fetched from the website twice. However, this is not a problem as Qiqqa includes dedup logic hence does download the second copy, but then will discard it as URL+fingerprint will match with the PDF imported just before.
Snippet from the GoogleBibTexSnifferControl code:
// When PDFs are viewed in Gecko/Firefox and somehow things went wrong the first time around,
// but **not enough wrong** so to speak, then the PDF is **cached** by Gecko/FireFox and it WILL NOT
// show up as one of the URIs being fetched for a page reload! The PDF will only show up **here**,
// as a completely loaded document.
//
// Meanwhile the Acrobat Reader in there will cause the `ObjWebBrowser.CurrentPageHTML` to render
// something like this:
//
// <html><head><meta content="width=device-width; height=device-height;" name="viewport"></head>
// <body marginheight="0" marginwidth="0"><embed type="application/pdf"
// src ="https://escholarship.org/content/qt0cs6v2w7/qt0cs6v2w7.pdf"
// name ="plugin" height="100%" width="100%"></body></html>
//
// !Yay! /sarcasm!/
The fix impacts #52. Double-check that one before marking this one fixed.
Related: #56 -- another case of not fetching the PDF
I bet this got fixed as part of the #56 fix activity in commit SHA-1: b3f1f2d88ebec67c4a18df94207716fe70da2256
Marking this one FIXED given the commit mentioned above: web imports shouldn't be silent no more. And when they are, I'ld better file a fresh PR.
Closing and decluttering the issue list so it stays workable for me: fixed in https://github.com/GerHobbelt/qiqqa-open-source mainline=master branch, pending #15 / any maintainer rights/actions.
Happens on rare occasions, e.g. bad connections or some other "weird failures".
The recurring theme here is that going back&forth in the browser pane is of no use: the PDF will load/show, but will NOT import. ðŸ˜