commonsmachinery / elogio.browser Goto Github PK

When disabling the plugin, any images in loaded web pages which are matched against the catalog, still show the red outline until reload.

"1) panel.html#L147
We don't allow add-ons to use remote scripts because they create serious security vulnerabilities. We also need to review all of your add-on code, and this makes it much more difficult. Please insert those scripts locally from your add-on code.

Please fix them and submit again. Thank you."

When the toolbar icon is clicked for the first time, the side bar opens but just with the message that the page must be reloaded to activate elog.io. The current page should be processed automatically, since the user is likely interested in the images on it.

When the plugin finds images in feed-like pages it should try to determine the permalink for the post containing the image and pass that as the context URI parameter to the /lookup/TYPE methods.

This story should focus on facebook and twitter.

The feedback from Thomas Hirsch on October 17th 2014 was:

Metadata that is not present should be listed (or list-able):
Such as:
"Source URL: "
License, Author, ... not provided.

View it on Doorbell

If the sidebar is closed, the gear icon should open it so the image information can be shown.

While we can't (and shouldn't) arbitrarily add information from a user to our database, we should think about how we will eventually make this possible so that someone can find an image which is not included, and through the extension, add it to the database in some capacity. This will probably require authentication of the relevant API calls.

For the Firefox version, the review indicated that:

1. Your add-on prints debugging information to the Console, which is generally not allowed in production add-ons.

Could we figure out a way to remove the debug printing when doing "grunt dist:firefox", but include it if running a debug version with just "grunt run" for instance?

Check to see if reporting of metadata and app feedback/bugs can be done via doorbell.io. There's documentation of the JavaScript version here: https://doorbell.io/docs/javascript (implemented on commonsmachiney.se, see "Hello?" in the lower right corner).
There's also an API here: https://doorbell.io/docs/api that might be more relevant, to implement our own messaging dialogs but submit via that API.

Doorbell.io includes the option of sending custom properties with the issues. When clicking "Report" on an individual metadata entry, the identifier of that entry, as well as the URL of the visited web page, should be set as custom properties to aid debugging.

The feedback from Abigail Willemse on October 16th 2014 was:

Doesn't play nice with copy & paste into PowerPoint. The image & attribution come up in seperate 'boxes' but the text was overlaying the image and up on top of it - will send a screenshot to the email address. but love the idea!

View it on Doorbell

On a fresh checkout of master, a "grunt run" doesn't pull in bootstrap properly. I had to first to a "grunt build-minified", and then a "grunt run" to get bootstrap included.

In situations where the "Query Elog.io" matches several works, or
match a work with a larger distance, it's sometimes misleading to
blindly select the best match. We need to create something so that
when there are multiple matches,or a fuzzy match, the plugins show the
matches and ask the user to select which one it is. The logic is
something like this:

if (multiple_matches && !one_match_has_distance_0):
display_multiple_selections_and_ask_for_input
else if (!one_match_has_distance_0):
display_single_match_and_ask_for_confirmation
else if (one_match_has_distance_0):
display the match with distance 0

It would be good to make this behavior configurable in the settings,
so that the above is the default,
but that the user can set to "Automatically select best match" to do
what it does now: always select
the best match regardless of response.

While reviewing for #47, I caught this: https://github.com/commonsmachinery/elogio.browser/blob/master/elogio-chrome/main/main.js#L275

/lookup/blockhash returns an array, with "distance" for each returned work. But as far as I can tell, from looking at the code, it always picks the first work json[0]

It's very important to look at the "distance" field too, since we want to pick the work with the lowest distance. I did not check to see whether it's the same in the firefox code.

See http://docs.cmcatalog.apiary.io/#get-%2Flookup%2Fblockhash%7B%3Fhash%2Csrc%2Ccontext%2Cpage%2Cper_page%7D

src is optional in the API, but the plugin should always provide it so we can follow up weird hashes more easily.

Hello,

My team and I maintain a site that's used by at least one person who has the Elog.io extension installed on Chrome. Every time they load a page on our site, we get emails due to the extension making a request for https://example.com/chrome-extension://fggflpkcoiangfbhbekafhpkijbglcmi/img/icon_48.png, which, of course, doesn't exist. That fact that we get emails is our fault (our 404 handler should be better), but in tracing down the problem, I installed the plugin to test this behavior and noticed that it happens everywhere. For example, try loading this issue page itself with the plugin enabled, then check the developer console for a 404 error.

As far as I can tell, the plugin adds a button to every page in the upper right-hand corner, which is a clickable gear image. I believe the problem is that the button image is requested along with all the other images on the page as part of the extension's intended behavior. However, the URL used to request the button image doesn't resolve properly, so Chrome requests + , instead of just . I can't figure out why that's happening, and I started looking at the code in hopes of making a PR. However, it was taking me too long, so I thought I'd open an issue, instead.

The (undesirable) result is that the plugin is generating 404s whenever its users load a page. To be clear, I don't think it's a user experience problem, but rather a minor annoyance for people like me who maintain websites. Do you think you could either stop the extension from looking up its own button image, or fix how the button's URL is resolved when its being requested?

Thanks,

Eric

When the user clicks "Query" and gets an error because the image wasn't found, it's enough to show this in the side pane - the elog.io add-on icon doesn't need to indicate an error too. The elog.io add-on icon should change and display an error when there's a server error or something that prevents the add-on from working.

On Facebook, the context menu doesn't work at all in Firefox.

In Chrome, it works but clicking "Find in Elog.io" doesn't do anything, ie., it doesn't scroll to the correct place in the pane.

The endpoint, currently http://dev.commonsmachinery.se:8004/ should ideally be configurable from within the plugins, to allow this to be changed without recompiling the plugin. It would be useful to have radiobuttons or similar, where you can choose either "( ) Elog.io default production server, or ( ) custom server: [ ]" or similar.

When there's an error loading an image, the Firefox plugin accurately shows "Elog.io failed to load.. etc" when mouseover the add-on icon. When disabling and then enabling the plugin again to make it reload the page images, the icon changes to the default elog.io but the mouseover text stays the same, indicating an error.

For http://glipho.com/margaretsw/3-innocent-creatures-turn-evil, matching the image https://d2ia58550xamqo.cloudfront.net/fda1b9bcc91248c5b4020f9f24806b63.jpg, doesn't work because of the lack of CORS headers.

This may be possible to get around with HTMLCanvas or similar, see below discussion:

10:40 The Firefox addon SDK docs says this about using sdk/request from the chrome part of a scrtip: "Since the request is not being made by any particular website, requests made here are not subject to the same-domain restriction that requests made in web pages are subject to."
10:40 https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/request
10:43 It seemed that artemijan had problems with the JPG or PNG libs breaking down in the chrome context because one of them actually used document.canvas behind the scenes, and there's no document in chrome. But it should be possible to hack them to do a new HTMLCanvas() or something like that.

It's quite confusing sometimes that https://github.com/commonsmachinery/elogio.browser/blob/master/elogio-commons/data/js-modules/Annotations.js#L129 for instance, give the function name getCopyrightLink for the property copyright.holderLink, and policy.statementLink becomes getLicenseLink, for instance. These all need to be uniformly named so that it's easy to read and edit the templates.

We've implemented support for collections in the backend, which means that annotations about works return information similar to this to indicate which collection a work belongs to:

  {
     "collectionLink" : "http://commons.wikimedia.org",
     "value" : "Wikimedia Commons",
     "collectionLabel" : "Wikimedia Commons",
     "propertyName" : "collection"
  }

This should be used instead of the user gravatar for displaying an icon connected to the works displayed in the browser plugin. For the moment, the browser plugins should support the following collections:

http://commons.wikimedia.org - set with the logotype of Wikimedia Commons
http://commonsmachinery.se - set with CM's logotype from https://github.com/commonsmachinery/ci/blob/master/CommonsMachinery_Humphrey_Tin_LightBackground.jpg

Bug: Copy as JSON seems to copy both the html, plus the JSON structure. It should ONLY copy the JSON structure.

Add a context menu button to images, so that right click -> "Elog.io" or so will open the catalog sidebar and scroll to the image selected.

The label indicating the label now carries the default bootstrap blue. I'd like to change this so that it varies the color based on the license: green being fully free culture compatible licenses or public domain, yellow being open licenses with restrictions (CC -ND and -NC primarily) and red being anything else.

The HTML template should for copy should include CC-REL RDFa or similar metadata, e.g. schema.org.

Tasks:

• Define the format
• Implement it
• Publish (at least on blog)

Outlines doesn't change the layout like a border does:
https://developer.mozilla.org/en-US/docs/Web/CSS/outline?redirectlocale=en-US&redirectslug=CSS%2Foutline

The colour could change to an elog.io blue, too.

This took a while to find the culprit :-)
The issue tracker JIRA has a printable view of issues (basically an HTML table), which looks fine in the browser. However, when actually printing it, the printed page contains the text:

Hello! We'd be happy to connect.
At here will be message from doorbell
At here will be error message from doorbell

This text seems to come from the Firefox elig.io plugin!

To reproduce, pick any publicly available Jira project, perform any query, and click "export - printable" to receive a page like this:
https://enyojs.atlassian.net/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?jqlQuery=project+%3D+ENYO+AND+issuetype+%3D+Bug+AND+status+%3D+%22In+Progress%22+AND+resolution+%3D+Unresolved&tempMax=1000
Then, print this page, or call print preview in your browser, and scroll to the end of the page.

Seen with Firefox Developer Edition 37.0a2 on Gentoo Linux.

The image info in the side bar should be conciser:

• Smaller gravatar
• Remove the Owner field
• Remove the Added at field
• Instead of "Locator link", just make the title clickable
• If there isn't any title, show the locator link URL as is (clickable, of course)
• Instead of "License link", just make the license label clickable
• Add a "By" field showing either copyright holderLabel/holderLink, or if that is missing the creatorLink/creatorLabel

Jonaso, we need to implement our own bootstrap.css because this style breakups loaded page. Without this file sidebar looks like windows 95(

The feedback from Andre Costa on February 3rd 2015 was:

You currently have the report option twice in your context menu.

On a more subtle note all of the CC images from Wikimedia Commons use an incorrect version of the CC license abbreviations (e.g. CC-BY-SA-2.5 instead of CC BY-SA 2.5). This is due to an earlier bug in the MediaWiki software (see https://phabricator.wikimedia.org/T78433) and so should affect all images harvested previous to the patch being implemented.

View it on Doorbell

Since the production env is up, the plugin should switch to the real endpoint: https://catalog.elog.io/

When hovering over sidebar images, the cursor changes and the images get highlighted no matter if the pointer is somewhere around the image or over it.

Clicking the area around the image does nothing though. It could be a more consistent user experience, if the actions would show up when the user clicks anywhere in the region around image (as the hovering behaviour hints that clicking is possible here).

On http://ec.europa.eu/research/participants/portal/desktop/en/organisations/register.html if clicking "Search", there's a captcha field. Regardless of what you enter as a captcha answer, it replies that it's invalid. This is only true when the elog.io plugin is active. If disabling the plugin, that captcha field works as intended.

Enable localization in both extensions to be able to translate the messages into the user's language.

e10s (electrolysis) is an upcoming Firefox change that gives each browser tab it's own process, like Chrome does. With the event passing that is done in the addon, we should be fine, but it needs to be verified before e10s is rolled out.

Some info in this blog post:
https://blog.mozilla.org/addons/2014/10/01/compatibility-for-firefox-33/

Instead of querying just the elog.io catalog, we should setup a query chain so that several queries can be made to find accurate information. The initial URI lookup should continue as before to go to elog.io, but when a user presses "Query", the processing order should be:

1. RDFa/Open Graph with libgetmetadata.io
2. Elog.io Blockhash

If (1) returns information, we don't need to do (2). We may want to easily reconfigure this order in the future, or even have it as a configuration option, but for now it's enough to do it in this order.

Version 40.0.2214.10 beta (64-bit) on Ubuntu 14.04 results in "There was a problem adding the item to Chrome."

This breaks the sidebar:

• Go to http://commons.wikimedia.org/wiki/File:John_Ericsson.jpg
• Click elogio button to activate sidebar and locate images
• Image and thumbnail show up in sidebar, outline is added in the webpage
• Close sidebar
• Click on the image of John Ericsson to just show it in the browser window
• Go back to the previous page in the browser history
• Click gear icon on image
• Sidebar opens, but only contains the text "Elog.io Plugin:", and no disable button or image list

This error shows up in the browser console:

Error: The page is currently hidden and can no longer be used until it is visible again.
Stack trace:
processMessage@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:240:5
emitEventToContent@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:284:31
loadApplicationPreferences@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-geu6gwf8utdrqw-at-jetpack/elogio-firefox/lib/main.js:213:17
elogioSidebar<.onReady@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-geu6gwf8utdrqw-at-jetpack/elogio-firefox/lib/main.js:227:13
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:96:9
onWebPanelSidebarReady@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/ui/sidebar.js:139:15

If the sidebar is instead kept open:

• Go to http://commons.wikimedia.org/wiki/File:John_Ericsson.jpg
• Click elogio button to activate sidebar and locate images
• Image and thumbnail show up in sidebar, outline is added in the webpage
• Click on the image of John Ericsson to just show it in the browser window
• Sidebar contents are replaced with just the image
• Go back to the previous page in the browser history
• Sidebar isn't updated

When clicking the gear icon on image this error shows up in the browser log:

TypeError: imageCard.offset(...) is undefined
Stack trace:
panelController</self.openImage@resource://jid1-geu6gwf8utdrqw-at-jetpack/elogio-firefox/data/js/panel-script.js:164:21
panelController</self.init/<@resource://jid1-geu6gwf8utdrqw-at-jetpack/elogio-firefox/data/js/panel-script.js:211:21
onEvent@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/loader/sandbox.js -> resource://gre/modules/commonjs/sdk/content/content-worker.js:45:9
onEvent@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/loader/sandbox.js -> resource://gre/modules/commonjs/sdk/content/content-worker.js:45:9
onChromeEvent@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/tmplR7qiE.mozrunner/extensions/[email protected]!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/loader/sandbox.js -> resource://gre/modules/commonjs/sdk/content/content-worker.js:97:9

The /lookup/uri call may return the same work more than once, if the URI searched for is matched in several annotations of the same work.

The feedback from Thomas Hirsch on October 17th 2014 was:

The feedback field that pops up in the sidebar is too small. ;)
I would like to choose which format is copied to clipboard. If there are few formats, this could be just another item in the menu, if there are more, it could be a setting that is remembered.
For example, if I am a heavy word user, having the picture copied is nice.
If I often print my documents, I might rather want to have the URL printed below the image.
As a web developer, I might want to get a JSON blob instead of the image and subtitle.

View it on Doorbell

The feedback from Thomas Hirsch on October 17th 2014 was:

From the message "something is wrong" and the sidebar, it is not obvious what elog.io is trying to tell me. It should be made clear even to users who do not know what elog.io is doing (and possibly point to instructions how to remediate this).

View it on Doorbell

Reporting via doorbell.io on individual works as well as in feedback should contain additional parameters to assist. The context uri (web page) should always be included.

Since our focus is on openly licensed works, there'll be cases where our plugin, despite its best effort, doesn't match against the work the user wants to research. It'd be useful to offer to redirect/scrape information from image search services (like Google Image Search) and present that to the user.

There are no APIs that can be used for this, and so most people seem to implement scraping of the HTML to do this. There are some inherent problems with this, but we can borrow some ideas. For instance, if we do a search for a particular image, limiting to site:flickr.com, then if we get matches, we can be fairly certain the image exists in the non-open parts of Flickr, and similarly for iStockphoto and others.

Being able to tell the user "We don't have any information, but we think it's from iStockphoto" - with links to the search results and iStockphoto, would be useful.

The plugin doesn't work with NoScript active, and I actually think it might be difficult to make it work with NoScript. But how can it degrade gracefully so it's clear to the user what the issues are?

The feedback from mzeinstra on October 13th 2014 was:

This image https://commons.wikimedia.org/wiki/File:Arius.png gave a false positive to https://commons.wikimedia.org/wiki/File:Flag_of_et-Viljandi.svg

View it on Doorbell

On http://belar.coyote.org/~jonas/0.7.0-validation.pdf is an automated report from Mozilla with some warnings when uploading our xpi. I don't know which are relevant and which are not, but it would be good to go through them and validate it.

Doorbell.io supports automatically attaching a screenshot to an error/feedback report. This would be very useful indeed, but any feedback which happens inside of the panel submits a screenshot of only the panel, not the context page. Doorbell.io is using Niklas von Hertzen's excellent html2canvas library, perhaps something could be done to make it create a screenshot including the context page?