hypothesis / browser-extension

The Hypothesis browser extensions.

Hypothesis browser extension(s)

The Hypothesis browser extensions allow you to annotate web documents using your Hypothesis account.

Choose your browser below

Chrome	Firefox
Now available	In development

Development

The code for the extensions is in the src/ directory, and can be built into a browser extension by running:

make build

Once this is done you should be able to load the build/ directory as an unpacked extension.

The extension code has a test suite, which you can run using:

make test

Note that the browser extensions are for the most part just a wrapper around the Hypothesis client. Depending on what you're interested in working on, you may need to check out the client repository too. Once you have checked out and built the Hypothesis client, you can use it by running the following command in the browser-extension repository:

yarn link ../client

Where "../client" is the path to your Hypothesis client checkout. After that a call to make build will use the built client from the client repository. Please consult the client's documentation for instructions on building the client in a development environment.

Tip: To unlink your dev browser extension from your dev client run yarn unlink hypothesis in your browser extension directory (see the yarn uninstall docs).

See Building the extension for more information.

Community

Join us on Slack for discussion. Please see our contact page for details of how to register.

For help using the extension, please see our Help pages.

If you'd like to contribute to the project, you should consider subscribing to the development mailing list, where we can help you plan your contributions.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

License

The Hypothesis browser extensions are released under the 2-Clause BSD License, sometimes referred to as the "Simplified BSD License". Some third-party components are included. They are subject to their own licenses. All of the license information can be found in the included LICENSE file.

browser-extension's Issues

Extension fails to inject after enabling it, then activating on previously open tab

Steps to reproduce:

1. Install the extension but disable it from chrome://extensions by unchecking the "Enable" box next to the extension's details
2. Open a tab at some HTTP URL
3. Re-enable the extension
4. Switch back to the tab and click the extension's toolbar button

Expected result:

The extension activates and injects the client into the page

Actual result:

The extension's toolbar button activates but the client is not injected into the page. After reloading the page, the client is successfully injected.

The problem only affects tabs that were opened prior to re-enabling the extension.

Console warnings about devtools failing to load sourcemaps

When activating the Hypothesis extension on a page, I'm seeing a bunch of browser warnings about the devtools failing to load sourcemaps:

If I click on the links in those errors however, the file loads successfully in a new tab.

Extension version: 1.320.0.0 (QA build)
Chrome version: 82.0.4056.3 (Official Build) dev (64-bit)

Why does Chrome browser extension ask for geolocation, camera & microphone settings access?

While adding the Chrome plugin this morning from the Chrome store, I received the message below that states that the extension needs to be able to change website's access to geolocation settings, camera, and microphone.

I'm assuming that this message appears because of how these permissions are bundled, but from a functional place,

I'm assuming that this is a non-issue related more to how the Chrome store auto-generates messages based on what permissions are requested, but given that the message pops up on install, I'd love to know more about:

• why does the annotation plugin need to be able to access geolocation, camera, or microphone settings?
• if the plugin does need to be able to adjust access to these settings, how are users notified that their defaults are getting changed?
• does any data collected via mic/camera/geolocation get sent back to hypothes.is servers (in addition to the originating web site)?

Thanks for any info you can provide here.

Also, some general technical details: I'm running Ubuntu Linux 16.04, latest Chrome - glad to share additional technical details privately if they are helpful/relevant.

Keyboard shortcuts for annotating and deleting an annotation

Annotating by mouse and deleting an annotation by mouse need much tedious effort, especially when I need to modify these annotations frequently. Keyboard shortcuts for annotating and deleting an annotation will significantly alleviate these problems. Therefore, is there any possible way to use keyboard shortcuts do these operations? Such as use "Alt+Q" for annotating selected text, and "Alt+E" for deleting the selected annotation.

1.81.0.0: Uncaught ReferenceError: annotator is not defined

(Chrome 66, Linux)

Majority of the functionality seems to work, but sidebar numbered tabs are failing to trigger opening the sidebar. Stack trace:

bucket-bar.coffee:1 Uncaught ReferenceError: annotator is not defined
    at HTMLDivElement.<anonymous> (bucket-bar.coffee:1)
    at HTMLDivElement.dispatch (jquery.slim.js:5206)
    at HTMLDivElement.v.handle (jquery.slim.js:5014)
(anonymous) @ bucket-bar.coffee:1
dispatch @ jquery.slim.js:5206
v.handle @ jquery.slim.js:5014

It seems like openannotation/annotator#615 has been working on it on client side, but as we seem to be shipping our own jQuery here, why would this error occur?

don't cover page content

Hello :-) The sidebar currently slides over the page content from the right. If the user can't simply shift page content to the left, annotation may be hindered because content is hidden. Please consider options like sidebar placement: left | right or [ ] shift page content (like side-by-side fullscreen view of two windows in macOS) to prevent content being hidden.

“Account settings” and “logout” menu items missing

Steps to reproduce

• Visit any page using the browser extension while logged into Hypothesis
• Open up the user menu

Expected behavior

• The four options in the menu are “[username]”, “Account settings”, “Help” and “Log out”

Observed behavior

• The “Account settings” and “Log out” items are missing

Other notes

This happens when using the browser extension, but doesn’t happen when using the embedded client or via.

Not active by default

I use Chrome extension. Every time I want to see the annotations, I have to click Hypothes.is Chrome's button first:

Only after clicking that, the annotations and the sidebar appear.

Is it intended behavior (why?) or bug?

Highlights disappear

https://drive.google.com/file/d/0B6uExxPqihrdMEpWTzNweXBZMDA/view

Take a look. Though both numbers are highlighted separately only one remains highlighted.

[bug] Highlighting only keeps the most recent highlight

Version: Hypothesis Chrome extension 1.40.0.0

Steps to repro
I have found this behavior happens after I "Highlight" something, then click on it again and edit the contents in the sidebar to add an annotation. So adding an annotation to a Highlight. Then trying to highlight new text leads to this problem.

Expected behavior
Highlighting some text on a website and clicking "Highlight" should color the text and should not affect previous highlights.

Observed behavior
Only one new highlight is allowed at a time. Highlighting new text overrides the previous highlight.

Other notes

Refreshing the page fixes it and causes the expected behavior again, but only saves the most recent highlight from before the refresh. (The overriding bug is persistent, ie. not just a display error).

Annotation count is not displayed in toolbar for local PDFs

I you annotate a pdf document in a group (perhaps also for other visibility settings, haven't tested) and open this document online, the hypothesis extension icon will have a blue rectangle with the number of annotations:

If you open the same document offline, the annotation count is missing.

Browser-extension api changes from hypothesis server api to localhost

I wanted to make changes to browser extension to point to my local system (server) is there any document which can point me to it?

I see there in app.html apiUrl points to "https://hypothes.is/api/" & as per the h documentation, h runs at port 5000 so what exact changes should be made?

When sharing an annotation, Tweet, Facebook, and Email buttons lead to blank sidebar

A user found a possible bug in our Chrome extension when clicking the Tweet button when sharing an annotation. He's using Brave, and I replicated on Chrome. I could not replicate it on FF.

User's video using Brave:https://drive.google.com/open?id=1t0Oov03tW8JkxYI2OnebAUIBkciYiCOa

My vide on Chrome: https://drive.google.com/file/d/1bh2GZW1ZcjlJa3oHEqIoWIY5MWEv4kk5/view?usp=sharing

Error with the Facebook button:

Error with the email button:

Note that this only occurs in the Chrome extension. Lyza says this bug is a result of an oversight in which these links do not open in a new window. They do not have target="_blank".

Update development docs to include OAuth client registration

The development docs for building the extension for development do not mention anything about registering an OAuth client, which is now a mandatory step.

Initial work for Firefox and Edge extensions

With the new extensions API, we can now consolidate and ship firefox and edge extensions along side our chrome.

I have worked through getting local versions of the extensions up and running. There are a few checks and balances that are checked when uploading to the addon/extension stores but those offer very explicit changes if any. Here are the things we need to do to get the extensions up and running:

Firefox seems to support the extension as is but had an issue with our incognito mode setting. They require "spanning".

Edge is still missing support for some features.

• The main one is storage.sync. Which based on our current usage of it, we can look to see if the api is available and only use that feature if it is available.
  https://github.com/hypothesis/browser-extension/blob/master/src/common/hypothesis-chrome-extension.js#L268

Edge is not supporting the chrome namespace so we can add two things to support this:

• The bridges: https://gist.github.com/Scrxtchy/f1322606285af3c26d1d along with this addition to the manifest

  "-ms-preload": {
    "backgroundScript": "backgroundScriptsAPIBridge.js",
    "contentScript": "contentScriptsAPIBridge.js"
  },

• Add var chrome = root.chrome || root.browser || root.msBrowser; to extension aware scripts (extension.bundle.js and embed.js)

Edge is not liking some stuff as well:

• polyfills.js module needs to actually return something. So add module.exports = {} stops a thrown error
• this might be the same as this: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities#JavaScript_APIs and we need to just use the right hook. I don't know that these functions are critical for first pass (used to show annotations count) but an error is thrown from:

chromeBrowserAction.setBadgeText({tabId: tabId, text: badgeText});
chromeBrowserAction.setIcon({tabId: tabId, path: activeIcon});
chromeBrowserAction.setTitle({tabId: tabId, title: title});

list of chrome compatibility diffs if needed:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities
https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/extensions/guides/porting-chrome-extensions/

edge api support:
https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/extensions/api-support/supported-apis/

Ideally, we can also upgrade our build process to make having three extensions easier to manage - but definitely a follow up

undo & redo highlighting through CTRL+Z & Shift+CTRL+Z

These shortcuts work within the annotation editor. Would it be possible / feasible to enable them on the page as well, for removing the last highlighting and redoing it?

Slack , Jira and linkedin are not working when extension is enabled

In Slack the following is the type error

modern.vendor.49add0bd8ef35e9c43a7.min.js:1 TypeError: TS.redux.dispatch(...).then(...).tap is not a function
at Object.call (application.ce2d72fd3a8e3d0aff65.min.js:1)
at e (rollup-secondary_a_required.a20d36d85375b0ec0521.min.js:1)
at modern.vendor.49add0bd8ef35e9c43a7.min.js:1
at e (modern.vendor.49add0bd8ef35e9c43a7.min.js:1)
at modern.vendor.49add0bd8ef35e9c43a7.min.js:1
at r (modern.vendor.49add0bd8ef35e9c43a7.min.js:1)
at application.ce2d72fd3a8e3d0aff65.min.js:1
at modern.vendor.49add0bd8ef35e9c43a7.min.js:1
at modern.vendor.49add0bd8ef35e9c43a7.min.js:1
at e (modern.vendor.49add0bd8ef35e9c43a7.min.js:1)
at modern.vendor.49add0bd8ef35e9c43a7.min.js:1
at application.ce2d72fd3a8e3d0aff65.min.js:1
at modern.vendor.49add0bd8ef35e9c43a7.min.js:1
at modern.vendor.49add0bd8ef35e9c43a7.min.js:1
at Object.fetchHistory (modern.vendor.49add0bd8ef35e9c43a7.min.js:1)
at t.e (application.ce2d72fd3a8e3d0aff65.min.js:1)

In Jira the following is the type error

Uncaught (in promise) TypeError: n.split is not a function
at r (batch.js:35)
at p (batch.js:35)
at s (batch.js:35)
at window.require (batch.js:38)
at s (polyfills.bundle.js?f568b9:1)
at s (chrome-extension://adlmdfpekolopjajcfpgannkanmkmemm/client/build/scripts/jquery.bundle.js?026e70:1)
at s (chrome-extension://adlmdfpekolopjajcfpgannkanmkmemm/client/build/scripts/jquery.bundle.js?026e70:1)
at a (batch.js:8752)
at batch.js:8752

Background page errors when closing PDF tab in Chrome extension

Originally opened as hypothesis/h#3095 by @robertknight.

Steps to reproduce

1. Go to any PDF document, e.g. http://www.orimi.com/pdf-test.pdf or http://users.clas.ufl.edu/burt/KafkaKierkegaardBible/BorgesTheCircularRuins.pdf
2. Activate the H Chrome extension
3. Open the background page for the extension under chrome://extensions
4. Close the tab opened in step 1.

Expected behaviour

No errors in the Chrome extension background page

Actual behaviour

This error is seen in the Chrome extension background page and reported to Sentry:

Unchecked runtime.lastError while running browserAction.setBadgeText: No tab with id: 614.
    at BrowserAction.update (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3313:25)
    at TabState.onTabStateChange [as onchange] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3689:21)
    at TabState.setState (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:4560:12)
    at Object.updateTabDocument [as callback] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3800:13)
_generated_background_page.html:1 Unchecked runtime.lastError while running browserAction.setTitle: No tab with id: 614.
    at BrowserAction.update (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3315:25)
    at TabState.onTabStateChange [as onchange] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3689:21)
    at TabState.setState (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:4560:12)
    at Object.updateTabDocument [as callback] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3800:13)
_generated_background_page.html:1 Error in response to tabs.get: TypeError: Cannot read property 'id' of undefined
    at Object.updateTabDocument [as callback] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3792:28)
    at TabState.onTabStateChange [as onchange] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3690:18)
    at TabState.setState (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:4560:12)
    at Object.updateTabDocument [as callback] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3800:13)
_generated_background_page.html:1 Unchecked runtime.lastError while running tabs.get: No tab with id: 614.
    at TabState.onTabStateChange [as onchange] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3690:18)
    at TabState.setState (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:4560:12)
    at Object.updateTabDocument [as callback] (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/extension.bundle.js:3800:13)
_generated_background_page.html:1 Unchecked runtime.lastError while running browserAction.setIcon: No tab with id: 614.

Browser/system information

Reported on Chrome 50 under Ubuntu 15.10.
Verified on Chrome 58.0.3013.3 (Official Build) dev (64-bit) under Mac OS X 10.12.3.

Additional information

Apparently this was at some point reported to Sentry, but I can't find evidence of that at the moment.

Changes the url while reading pdf

I mostly use this extension while reading papers and I face the following

If I turn it on, it changes the URL of the page (I am not sure whether this happens on all the sites but I can confirm that this happens when I read papers on arxiv). So if I need to share the paper with someone, I am forced to turn off the extension to get the url, refreshing the the page/pdf twice in the process. So I am forced to scroll back to the section which I was reading. It would be better if the extension does not change the url at all.

Screenshot

Also, one more thing. somehow it can't search for a word while I am reading a pdf with 'Hypothesis' turned on.
Screenshot2

As you can clearly see, there is a word diffuse in the highlighted sentence but the search cannot find it. Also, I tried to search for the word without 'Hypothesis' on, and it works as intended.
Here is the paper link if you want to replicate this issue.

Allow for browser-extension plugins

It would be really nice to augment the functionality of the browser extension through plugins and well defined extension points. Annotator.js offers plugins ... perhaps the hypothesis extension can expose this as well as extension points for actions, adding new functionality via buttons and hooks etc. This could help third parties rapidly integrate Hypothesis with existing applications.

Forgive me if this is already being considered. I have not found anything on it yet. The thought occurred to me while wishing for GitHub Projects/Issues integration with Hypothesis.

Sign in issue on localhost

One doubt, I deployed browser extension changing the apiUrl to localhost but now that I try to sign in it says unauthorized, is it necessary for every user to have OAuth to sign in? Can't a user directly just login after sign up?

Upgrade PDF.js to the latest version

This is part of hypothesis/product-backlog#1062

• Upgrade the version of PDF.js shipped with the browser extension to the latest v2 release
• Ensure there are tools in the repository to make upgrading PDF.js to the latest version easier in future
• Ensure there is a clear separation between any PDF.js files that come from a pre-built package and any local modifications we have made

See also the PRs that upgraded PDF.js in Via: hypothesis/via#178, hypothesis/via#179 and hypothesis/via#180.

Since we've deployed PDF.js v2 to a wide audience already at this point (Via users, lms app users) I think we can do so without a feature flag in the Chrome extension.

One piece of logic that Via has that won't be needed for Chrome are the IE 11 Promise polyfill workarounds from pdfjs-init.js.

Be more vocal about highlighting while not being logged in

Sometimes (I suppose when you haven't used extension for a while), you get automatically logged out off Hypothesis. The problem is when you want to highlight something, you get no notification that you are not logged in. After you leave the page and return, the highlights are not saved. What is interesting is that with annotations, you would get a sidebar warning that you are not logged in. Shouldn't the behavior for highlights and annotations be consistent?

1.69.0.0: https://10.241.109.147:5000/welcome connection timeout

1. https://addons.mozilla.org/addon/annotons-nos-contenus/
2. install version 1.69.0.0

Result

3. in a new tab, https://10.241.109.147:5000/welcome times out.

Test environments

• Waterfox 56.1.0_7
• Firefox 59.0.2_4,1

– both on FreeBSD-CURRENT.

Is there a way to stay logged in longer in the Chrome Extension?

I feel like I get logged out fairly quickly (perhaps one a day or two)

I would love if we could just stay logged in and not have to constantly log back in.

Could not load manifest

I am trying to build my own application based on hypothesis (editing only the client: https://h.readthedocs.io/projects/client/en/latest/developers/developing/#running-the-client-from-the-browser-extension) and therefore trying to load the (unchanged duplicate of the chrome) extension into Chrome: https://github.com/hypothesis/browser-extension/blob/master/docs/building.md.
The path of the file I am trying to load unpacked is ../browser-extension/src/chrome.
However, I get the error message "Manifest file is missing or unreadable. Could not load manifest."
Do I need to transform the manifest.json.mustache file into a .json file?

Firefox extension does not work with local PDF files

Steps to reproduce

1. Download latest and install latest build of Firefox extension (eg. from the link at the bottom of the build output here). Note: You'll need to download the .xpi file first and then load it via File -> Open File
2. Open a local PDF file in Firefox
3. Activate Hypothesis

Expected behaviour

Hypothesis should load the PDF in a new tab using its bundled version of PDF.js

Actual behaviour

Hypothesis fails to activate and displays an error icon on the badge. Additionally clicking the badge does not show the error details page.

Browser/system information

Firefox Nightly v52a1

Additional details

Same steps but with a PDF hosted on a HTTP URL works

Automate the extension release process

Problem

Currently our browser extension release process doesn't use the CI/CD Jenkins setup. Releasing the browser extension is therefore a more manual process, which can mean that not all team members can release the extension, or feel comfortable releasing the extension.

What's Needed

After talking with @robertknight, we agreed that we should move the extension release process into the current CI/CD process that we're already using for other apps. This will help automate the process so that everyone can release the extension as needed.

Sub-tasks

• Add Jenkins project to build, test and deploy the browser extension (#300, #301)
• Add method to create a new browser extension version with the latest Hypothesis client (#307, Slack thread)
• Trigger an update of the QA browser extension when a new Hypothesis client version is released to production. Production releases of the browser extension will still require manual intervention (hypothesis/client#1877)
• Update documentation in playbook repository, SO4T to reflect extension release process changes (https://github.com/hypothesis/playbook/pull/270)
• Figure out why the process of uploading, signing and then downloading the Firefox extension using web-ext is taking such a long time (see comment)
• Make a decision about whether to keep or remove the Travis build for the time being (nb. The main affordance Travis provides is that it is accessible to non-Hypothesis developers, whereas Jenkins is not) (@robertknight - I'm proposing to keep this for now. We can always revisit later. See #311)

Follow-up work

(Check items when either done or filed as an issue and scheduled for future)

• Rename the "stage" extension to "QA" everywhere in the browser-extension repo, as it is confusing that we use the term "QA" for all other projects but "stage" for the browser extension pre-prod release in some places (#309)
• Make it easier to update the QA extension after a new release (@robertknight - this is currently a PITA that requires me to log into the Chrome Web Store, remove and re-add the extension) (Update: A solution for this is to create a new Chrome profile which is connected to your Hypothesis Google account. This will enable Chrome's extension auto-update to work for the Hypothesis QA extension - @robertknight)
• Filter out progress logs from web-ext sign (it currently prints many "frames" of a progress. bar as if the Jenkins output log was an interactive terminal) (#317)
• Optimize the process of uploading+signing+download the Firefox extension (see comment for ideas) (#317)
• Make it possible to publish the prod extension directly from Jenkins
• Remove need for Chrome extension to request broad permissions upon installation as this makes compliance reviews of new updates more likely which in turn affects our ability to ship new releases promptly

Icon count report multiple annotations, but then there is none

Different pages show a number of annotations, in the toolbar icon card, but when clicking it and opening the extension there is no annotation listed for the page.

I tried to switch group but still the annotations are not there.

Is it a bug?

Are the annotations hidden or there are no annotations at all and the count is wrong?

Running Chrome Version 78.0.3904.108 (Official Build) (64-bit), on macOS Mojave.

Enable Sentry integration for client

hypothesis/client#1320 integrated the new Sentry JS SDK into the Hypothesis client to capture details of crashes and report them to us automatically. In order to benefit from this in the context of the browser extension we need to add the necessary configuration to the settings/chrome-{prod, stage}.json config files.

I would suggest that we use the same Sentry project for the Hypothesis client across all delivery methods (via, embed, extensions) so that reports are combined together. However we can use the environment config option to differentiate between reports from dev, qa and prod environments and to differentiate between reports from the embedded client vs. the Chrome extension.

We can either use the same DSN as for the embed or create a new DSN specifically for the extensions.

Note that this issue is separate from enabling Sentry for the code that runs in the privileged context of the extension's background page.

Extension fails to inject client on tabs that were open prior to installing extension

Steps to reproduce:

1. Uninstall Hypothesis extension and open a new window
2. Open a couple of tabs
3. Install the Hypothesis extension
4. Switch back to the tabs opened in step (2) and try to activate Hypothesis

Expected result: Sidebar appears
Actual result: The browser action lights up but the sidebar does not appear

I believe what is happening is that the TabState data structure which holds Hypothesis-related state for each open tab does not get populated with state for existing tabs. Therefore state.getState(<some existing tab ID>)>.ready returns false on this line:

browser-extension/src/common/hypothesis-chrome-extension.js

Line 222 in c2617c3

if (!state.getState(tab.id).ready) {

and injecting the sidebar bails out early.

The fix would be to populate the TabState store for existing tabs when the extension loads.

Docs should be improved to register extension with h/

It's not clear that the browser extension needs it own oauth client registered in h. Both the docs and the readme files should make mention of this so its clear how to set up a custom client in a browser extension running on a local instance of h.

For example
http://localhost:5000/admin/oauthclients

Where the redirect URL is the local unpacked browser extension loaded from the /build dir inside the browser extension repo (after you run make)

We should also make clear that the oauthClientId in the settings .json used when building the extension should point to this oauthclient. Namely, the Client Id returned when registering the new client in the h/ admin UI.

e.g.

{
  "buildType": "dev",

  "apiUrl": "http://localhost:5000/api/",
  "authDomain": "localhost",
  "bouncerUrl": "http://localhost:8000/",
  "serviceUrl": "http://localhost:5000/",
  "websocketUrl": "ws://localhost:5001/ws",

  "googleAnalytics": "UA-26026798-6",

  "browserIsChrome": true,
  "appType": "chrome-extension",
  "oauthClientId": "6cf635cc-d318-11e9-bbf2-977360331651"
}

Deactivating extension can remove embedded Hypothesis

The browser extension has some logic so that activating it on a page which already embeds Hypothesis does not result in the extension's copy of the sidebar being run alongside the embed. This is handled by canceling activation if an embedded client is detected in the page.

De-activating the extension however does not perform the counterpart check to see whether it is the extension's copy of the client that is loaded into the page.

We should make the behaviour more consistent. A caveat is that the current behaviour may be useful since it allows the embed to be replaced with the extension in a roundabout way so we might want to think twice before just preventing the extension ever being used on a page that embeds the client.

Steps to reproduce

1. Go to a page that embeds Hypothesis
2. Activate the extension
3. De-activate the extension

Expected result

If step (2) does not replace the embed, then step (3) should not remove the embed.

Actual result

Step (2) does not replace the embed but step 3 does remove it.

User testing sessions with assistive technology users

• Complete test session with JAWS user
• Share meeting recording with team
• Synthesize notes; break up recording into smaller videos
• Create list of development tasks that will make h screen-reader compliant

Firefox Bookmarklet has stopped working on many websites

This morning, I found that the Firefox bookmarklet isn't working anymore on Github.com, Gmail.com, HackerNews and then some. I am using Firefox 72.0.2 (64-bit) on Ubuntu. I started Firefox in safe-mode also (hence all add-ons disabled), and yet it was the same. It continues to work for these sites on Chrome, however.

In the browser console, it was showing this warning:

Loading failed for the <script> with source “https://cdn.hypothes.is/hypothesis/1.307.0/build/scripts/jquery.bundle.js?3746d4”.

Allow client to remain logged in when 3rd party cookies are blocked

This comes out of a user question in hypothesis/product-backlog#872 - Why does Chrome extension log out on each page load if 3rd party cookies are not allowed by default?

Answer:

Third-party cookie blocking typically prevents third-party iframes (ie. those with a different origin than the tab itself) from storing data in local storage as well, because otherwise that would be used to bypass cookie blocking. The end result is that the client typically cannot persist the login if third-party cookies are blocked... We probably could make use of extension-specific APIs to avoid this problem. I think Nick suggested doing that aeons ago.

Logging this as a feature request so we can track if/when other users start to ask about this.

Firefox Bookmarklet not working on LA-Times website

The Firefox bookmarklet is not working on some pages of Los Angeles Times (e.g. this article page). There may be more websites where it would not be working. The Chrome extension however works fine on the website.

I am using Firefox 69.0.1. I have adblocker, but disabling it doesn't change anything.

Add option to save annotations to personal server

Hey there. I really enjoy annotating with the Chrome Extension. I even think it's cool that other users in the hypothes.is network will see them.

But I also want to make sure that all my annotations are stored somewhere safe, someplace I can control and build programs around, like my personal server.

It would be super amazing if this extension included a configuration option where I could enter an additional URL to send my annotations too (e.g. in OA JSONLD format or a Web Annotation Protocol Container).

Just wondering, but is that type of feature within the realm of hypothes.is' mission? Helping me post annotations outside of the hypothes.is social network?

Regardless, I'd be willing to work on adding it, but I'm not intimately familiar with Annotator.js or Chrome Extensions. It would be an immensely helpful kickstart if someone who is familiar with those components could briefly explain how I could go about building this sort of thing. I imagine something like

MVP, build extra annotation server in at extension build-time:

• Hook into the Annotator.js used by this extension, and whenever an annotation is posted, call a callback defined by this extension. That callback will do some AJAX to the annotation server. *This is what I'd most like advice on.

After MVP, make the extra annotation server configurable in extension:

• Chrome option for the API to hit with my annotation - I can probably rtfm on extensions and figure this out
• Read that value (from chrome.storage?) instead of hardcoding it at build time.
• Remove "You must be logged in to create annotations.", which would not strictly be true any more.

If PDF.js places page to left rather than centered there'd be more space for hypothesis

The PDF.js widget places the rendered pdf page in the middle of the browser window, but isn't aware of the hypothesis sidebar. If instead the page was placed as far left as it could go, there would be more room for the hypothesis sidebar, and it would be less likely to overlap the page content.

I realize maintaining a more invasive patch to PDF.js might be a pain. This enhancement would be a nice-to-have, if it isn't too difficult. Presumably the change would also benefit the viewer that the hypothesis web client includes, wherever it gets it from.

Extension fails to activate on PDFs in current Firefox versions

Attempting to activate the Firefox extension on a PDF fails, with an exclamation icon being displayed on the badge. Clicking the badge a second time for more details results in an error "Missing host permissions for tab".

Steps to reproduce:

1. Build Firefox extension and load it in Firefox
2. Open a PDF in a new tab and try to activate the extension

Notes:

Using the debugger shows that the error is happening when trying to determine the content type. Specifically the executeScriptFn call here fails with a rejected promise. Some Googling found this forum thread which indicates that this is not a bug but a restriction on activating Firefox extensions on protected pages, including the built-in PDF viewer.

I think what we'll need to do instead is implement some fallback method of detecting the content type and then replacing the tab, much like we do in Chrome.

The simplest fallback we can implement is to use the URL, although not all PDF URLs contain paths that end with .pdf. If we can't get access to the actual content type, one option might be to simply assume that any file or http URLs that trigger this error (ie. not a protected scheme) are PDFs. I expect there will be a small number of HTTP URLs (Mozilla-specific ones) which are restricted, as is the case in Chrome, but it is much more likely that the content is a PDF.

Anchoring failures after PDF.js update

After testing a bunch more PDFs against the recent PDF.js update, I found a case where annotations that were anchored in the previous version are now not anchored: #9

Steps to reproduce:

Using a production build of the Chrome extension and Hypothesis client >= v0.47.0:

1. Open https://www.jyu.fi/edu/laitokset/okl/koulutusala/vkluoko/tietopankki/tutkimusta/viittomakielinen_juhlajulkaisu_nettiversio.pdf
2. Activate Chrome extension
3. Watch the bucket bar counter in the bottom-right corner of the screen increment as annotations are anchored. Wait until it stops increasing.
4. Sort annotation list by location, scroll it to the bottom and click on it to scroll to the last annotation in the document

Expected: Annotation counter matches the number of annotations on the page as displayed in the sidebar (79 at the time of writing). Clicking on the annotation at the bottom of the sidebar scrolls the PDF viewer.
Actual: Annotation counter stops at a much smaller number (10 at the time of writing), clicking on the annotation at the bottom of the sidebar scrolls the PDF viewer

Notes

Compare with Via which is running an older version of PDF.js. On Via, after the document opens, 79 annotations anchor - indicated by the counter in the bucket bar. With newer PDF.js, that counter only ever gets up to 10.

Hypothesis fails to detect PDF in Chrome

Tested by me with Chrome v78.0.3895.5 and @dwhly with Chrome 76.0.3809.132 on macOS.

Steps to reproduce

1. Install H Chrome extension
2. Go to http://researchoninnovation.org/patent.pdf
3. Click H icon to activate extension

Expected result: H loads the PDF in its custom PDF.js viewer, with the Hypothesis sidebar active
Actual result: The H sidebar appears in the native PDF viewer, as if the page were an HTML page. Since this is not our custom PDF.js viewer, annotation doesn't work.

Slack thread: https://hypothes-is.slack.com/archives/C4K6M7P5E/p1567444151094900

Technical notes

Using Chrome dev tools with the extension's background page I've narrowed the issue down to the tab content type detection returning the wrong result ("HTML" instead of "PDF"). The browser extension detects the content type by running a script (the detectContentType function) in the context of the tab's top-level HTML document.

In the Chrome context, it looks for an element matching the selector embed[type="application/pdf"][name="plugin"].

When I looked at the actual HTML of the top-level frame in the PDF tab just now, the embed is present, but the embed does not have a name attribute:

I don't yet know the last Chrome version where this worked. My guess at the moment is that a recent change removed the name attribute.

Location changes not respected when using History API

Hi,

the browser extension does not seem to recognize window.location changes made via History API, therefore annotations are not loaded when using pushState (e.g. in single page apps). I think listening to the popstate event and updating/reloading annotations accordingly should do the trick. Is there any way I can work around this? Is there an event I can trigger so that the browser extension reloads?

Thanks & Best
Morris

Problem running make

I'm trying to build the project but I have a problem running the command make on the problem. I have this log :
node_modules/.bin/browserify -t babelify -d src/common/ex
es/.bin/exorcist build/extension.bundle.js.map >build/ext
'node_modules' not recognized as an internal or external command
make: *** [build/extension.bundle.js] Erreur 255

Can anyone help?

Building extension for publishing on chrome store

Do we need any changes in make , gulp .. files to create extension which can be published on chrome store. Google Chrome Web Store team rejected as the submitted extension contain minified or obfuscated code which is not human readable. An example of one such file in your package is content/build/pdf.worker.js,content/web/compatibility.js.

Integration with the Urantia Book Explorer

I and a few others started using Hypothesis Chrome extension on our web application called "The Urantia Book Explorer http://urantiaexplorer.org and the way our website works is that in each of the four possible text columns it loads a single paper (out of 197) of text in the chosen language for that column. Any part of the text could be annotated, in principle. This implies that at any time most of the annotations would be considered "Orphan" by Hypothesis and placed in the "Orphan" tab. That is fine in itself and we use this as an indicator that the corresponding text should be loaded in one of the columns and Hypothesis plugin restarted (just by clicking twice on the "h." symbol in the upper right corner). However, unfortunately, Hypothesis considers a "close enough match" to be a success and does NOT place the corresponding annotation in the Orphan category, thus creating a false positive. Also, in our case, all annotations in Orphan category are perfectly valid and just require loading the appropriate text, so seeing the text selection striken out is not convenient. It would be nice to get rid of this "striking text out" feature or at least make it configurable somehow. Thus, my two suggestions are:

1. Do NOT consider inexact matches. If no absolutely exact match is found, then place the annotation in the Orphan tab.

2. Do NOT strike the text out for Orphan annotations. The reason why the annotation is Orphan is obvious anyway, so there is no need to emphasise it by striking the text out.

Update the extension logo that appears in the extension tab

While the app's mini logo has been updated, we also need to update the main logo for the extension that appears in the chrome://extensions/ tab.

h logo svg
https://gist.github.com/jaredpdesigns/626aa057417f7c82bfe352557cc9c93a

note: we made need to convert to a png

Related to: hypothesis/product-backlog#1006

Canonical link should be used instead of URL for badge

Adding a canonical link like <link rel="canonical" href="http://example.com/"> is the one way to provide the authoritative URL for the hypothesis client, in case the URL itself contains additional query parameters that do not identify the page. This link is currently ignored when the annotation count for the badge is determined.

Extension fails to log in

Steps to reproduce:

1. Open the sidebar using the extension and log out.
2. Click the Log in button
3. The authorization window opens and immediately closes.
4. Delete cookies from hypothes.is
5. Press log in again
6. The authorization window stays open.
7. Log in via the window.
8. The sidebar still doesn't log in.

No annotate/highlight button in google docs

OS: Ubuntu 16.04
Browser: Chrome 62.0.3202.75 (Official Build) (64-bit)
Version: Hypothesis - Web & PDF Annotation 1.48.0.0 (Official Build)
Steps to reproduce:
Open any google doc and try to annotate something