- 17 May, 2017 3 commits
-
-
Robert Knight authored
-
Robert Knight authored
Annotator removal cleanup
-
Robert Knight authored
-
- 16 May, 2017 12 commits
-
-
Sean Roberts authored
-
Sean Roberts authored
Cleaning up: moving constructor to be first function in Guest class and removing unused wrapper html field
-
Sean Roberts authored
Remove dependency Annotator.js
-
Sean Hammond authored
Switch package management from npm to yarn
-
Sean Hammond authored
Fix refreshing access tokens when laptop suspends
-
Sean Hammond authored
This commit fixes an issue that refresh token requests were being sent too late if a laptop was suspended, even if the laptop was resumed again in time to do the refresh. For example if a laptop was suspended for 10 mins, then the refresh request would be sent 10 mins later than it should have been and the access token and refresh token would have already expired before the refresh request was attempted. The bug was due to a misunderstanding about how `window.setTimeout()` works: If you, say, use `setTimeout` to call a function in 10 minutes time, then wait 5 minutes, then put the laptop to sleep for an hour, then wake it up, **it will wait another 5 minutes and then call the function**. That is, the time that the laptop spent asleep does not count towards the timeout, it pauses the timer and then continues the timer again when the laptop wakes. This will also happen if the browser or OS suspends the tab or app. I've verified this behaviour in Chrome and Firefox on Linux, and it also agrees with [this StackOverflow answer](http://stackoverflow.com/questions/6346849/what-happens-to-settimeout-when-the-computer-goes-to-sleep/6347336#6347336) and [the HTML5 spec on `setTimeout`](https://www.w3.org/TR/2010/WD-html5-20101019/timers.html#timers): "wait until the Document associated with the method context has been fully active for a further timeout milliseconds (not necessarily consecutively)." This means that if you want to definitely call a function at a given time (say 55 mins in the future) you can't just use `setTimeout` to set a single timer for 55 mins like our code was doing - if the laptop is suspended during those 55 mins then the timer won't go off until 55 mins + however long the laptop was suspended for. To fix this change the code to repeatedly poll, every few seconds, whether the current time is later than the access token expiry time minus 5 minutes. If it is, then try to refresh the access token. I'm using repeated calls to `window.setTimeout()` to implement this, rather than one call to `window.setInterval()`, because with `setTimeout()` it's easier to do a couple of things that the previous implementation was already doing: 1. Not make any more refresh token requests while one is still in flight 2. Stop making further refresh token requests when one fails
-
Robert Knight authored
Update lockfile with result of running `yarn install` with yarn v0.23.2.
-
Robert Knight authored
-
Robert Knight authored
Package installation fails with Node v6.2 due to an incompatible "check-dependencies" package. See https://travis-ci.org/hypothesis/client/jobs/228937886
-
Robert Knight authored
There were a couple of issues with the initial Yarn lockfile created via `yarn import`: 1. `yarn check` reported several inconsistencies. 2. `phantomjs-prebuilt` needed to be upgraded to resolve a compatibility issue with Yarn. This commit resolves these issues by just removing and recreating the Yarn lockfile. In the process all dependencies have been upgraded to the latest versions compatible with the constraints in package.json.
-
Robert Knight authored
Yarn provides much faster package installation, better resilience to npm registry connection issues and most importantly for us, a much better lockfile format. This commit: 1. Replaces the npm shrinkwrap with the yarn lockfile using the following steps: 1. Checkout latest version of master 2. Remove node_modules folder and re-run `npm install` 3. Run `yarn import` to generate a lockfile 2. Modifies the Makefile, Jenkinsfile, package.json and .travis.yml scripts to run `yarn` instead of `npm`.
-
Robert Knight authored
-
- 15 May, 2017 3 commits
-
-
Robert Knight authored
-
Robert Knight authored
Clarify in tooltip what flag button does
-
Robert Knight authored
Branding updates
-
- 12 May, 2017 7 commits
-
-
Juan Corona authored
-
Sean Roberts authored
* master: Rename DO_{LOGIN,SIGNUP} to {LOGIN,SIGNUP}_REQUESTED Allow third-party annotation services to customize sign-up link handling
-
Sean Roberts authored
-
Sean Roberts authored
-
Sean Hammond authored
Allow publishers to customize "Sign up" link handling
-
Juan Corona authored
Increases coverage, tests calls spawned in annotator/main.js `appLinkEl.addEventListener('destroy`, `window.annotator.destroy();`
-
Juan Corona authored
-
- 10 May, 2017 1 commit
-
-
Juan Corona authored
This fixes the remaining failing tests. When compiled from coffeescript the initial `{}` value was at the prototype level instead of scoped at the function level. It looked like I was declaring it as an instance variable, but it was more like a class variable.. coffeescript is weird to me..
-
- 09 May, 2017 8 commits
-
-
Juan Corona authored
-
Juan Corona authored
Failing tests and what was fixed: 1. Sidebar was not closing when the user taps or clicks in the page. - Function that set up event handlers used to be called by the `Annotator` base class, now called directly in `Sidebar` 2. Config params used in the passed options to the sidebar iframe leaked a new property (`pluginClasses`) used by the refactoring - Filter that property in `Host` 3. `Guest` was missing `deleteAnnotation` function implementation that used to be in `Annotator` Now only 2 tests should be failing
-
Juan Corona authored
-
Robert Knight authored
-
Robert Knight authored
-
Robert Knight authored
Use consistent past-tense naming for all events in `bridge-events`.
-
Robert Knight authored
Allow third-party annotation services to define a callback which is invoked to handle the "Sign up" link in the client, in a similar way to how the "Login" link is handled in this case.
-
Juan Corona authored
In order to avoid heavy refactoring some classes from Annotator were moved over to this codebase. This includes the class for the `Document` plugin and Annotator’s base class `Delegator`. The class `Guest` is now responsible for loading the remaining Annotator-style plugin modules. The base class for `Guest` is now `Delegator` instead of `Annotator`.
-
- 04 May, 2017 2 commits
-
-
Robert Knight authored
Improve error when flagging when logged out
-
Robert Knight authored
Don't show duplicate toastr messages at once
-
- 27 Apr, 2017 2 commits
-
-
Sean Hammond authored
-
Sean Hammond authored
Improve the error message that's shown to the user when trying to flag an annotation while logged out. Instead of showing a "404 Not Found. Either the resource you requested doesn't exist, or you are not currently authorized to see it." error from the server, show a friendlier "You must be logged in to report an annotation" message. This is done client-side by checking whether the user is logged in when they click the flag button, and if not showing an error instead of sending the flag request to the API. This is because the API doesn't respond with a unique "You must be logged in to flag" error that the client could depend on, it just returns a 404, which could be for a number of reasons (e.g. the annotation no longer exists).
-
- 26 Apr, 2017 1 commit
-
-
Sean Hammond authored
The flag button on an annotation has a tooltip that says simply "Flag" (or "Annotation has been flagged" if it's already flagged) but there's no indication to the user what flagging is or does (even when they click the button, all that happens is the flag turns red). "Flagging" can certainly be misinterpreted. I think some apps use it as a way to keep track of "special" or "favorite" items (usually called "starring" in most modern apps), or have a variety of different "flags" that you can apply to an email or whatever it is (important, work, personal, etc, this is usually called "tagging" or "labelling" in most modern apps). This commit changes the tooltips to clarify that what the button does is report the annotation to the moderators. I've used the verb "report" rather than "flag" as I think "Report this annotation to the moderators" sounds better than "Flag this annotation to the moderators". Either way I think "to the moderators" is important to clarify that this button sends a message to the moderators and isn't, for example, just flagging for personal use like starring / tagging / labeling.
-
- 24 Apr, 2017 1 commit
-
-
Sean Hammond authored
Use `this` or `self` to refer to the controller instance in annotations
-