- 31 May, 2017 3 commits
-
-
Sean Hammond authored
There are two reasons for renaming the `options` object to `config`: **First**, it's more consistent. The file that creates this object is called `config.js`, and the function that creates the object is called `configFrom()`, and yet the object ends up getting called `options` (but you have to look in another file, `main.js`, to find this out). `config` is also used elsewhere as the name for the main configuration object, for example in Pyramid/h, in the client docs ("Configuring the Client", "configuration settings") and public API (`class="js-hypothesis-config"` scripts and `window.hypothesisConfig()` functions), etc. These "options" that the `src/annotator/` code reads from the host page also end up getting renamed to `hostPageConfig` when they get passed over in to the `src/sidebar/` code. **Second**, it's more unique. There are a number of other objects in the `src/annotator/` code that are called options, sometimes the main options object and another local options object are even used in the same function. There's no other objects called config.
-
Sean Hammond authored
This makes it easier to grep for uses of this function.
-
Sean Hammond authored
Rename the `config()` function that creates the `options` object to `configFrom()`. This is because I want to rename the `options` object to `config` in a future commit, so I need the `config()` function to be called something else. I think `configFrom(window)` is also clearer (that this is a function that returns a `config` object created from the given window) than `config(window)` (which could be read as configuring the window, for example).
-
- 25 May, 2017 2 commits
-
-
Sean Hammond authored
Improve the `src/annotator/config.js` unit tests
-
Sean Hammond authored
The main change is to make the tests much more detailed by adding more unit tests describing and testing more of the code's behaviour. But also: * Remove some test fakes which implemented non-trivial fake behaviour: `fakeScriptConfig`, `fakeQuerySelector`, `fakeWindowBase`. Just use simple stubs instead. * Make each test test just one thing (previously many of the tests for one part of the code could fail if another part of `config.js` was broken). * Isolate the `config.js` unit tests from `src/shared/settings.js` and `extract-annotation-query.js`. Previously the `config.js` tests could fail if `settings.js` or `extract-annotation-query.js` were broken, and implementation details of `settings.js` and `extract-annotation-query.js` were coded into the `config.js` tests. * Fix an issue with one test that if it failed a `window.document` would be left modified
-
- 23 May, 2017 6 commits
-
-
Sean Hammond authored
A few followup fixes to "Allow publishers to customize user menu links followup"
-
Sean Hammond authored
Prevent Adder toolbar from inheriting CSS property values from host page
-
Robert Knight authored
-
Robert Knight authored
-
Robert Knight authored
The adder toolbar uses Shadow DOM or `!important` to prevent CSS rules in the host page from directly affecting the styling of the toolbar. However even inside Shadow DOM elements can still inherit CSS property values from parent elements [1]. This commit fixes that problem for current browsers (except Edge [2]) by using `all: initial` on the Adder's root element. [1] See https://github.com/w3c/webcomponents/issues/314 [2] http://caniuse.com/#feat=css-all Fixes #382
-
Sean Hammond authored
Add config option to show highlights only when sidebar is open
-
- 22 May, 2017 12 commits
-
-
Sean Hammond authored
Update jQuery to current version & slim build
-
Sean Hammond authored
-
Robert Knight authored
-
Sean Hammond authored
Instead of two different js-* classes. Simplifies the JavaScript code.
-
Sean Hammond authored
According to our CSS guidelines, use js-* CSS classes as handles for JavaScript to find HTML elements.
-
Robert Knight authored
-
Robert Knight authored
Allow publishers to customize log out, profile and help links
-
Robert Knight authored
-
Robert Knight authored
-
Robert Knight authored
Convert the "showHighlights" option from a boolean into an enum with three values: "always", "never" and "whenSidebarOpen". When the last mode is selected, highlights will only be shown when the sidebar is open.
-
Robert Knight authored
Stubbing `getComputedStyle` in the pointer events test resulted in the test failing after the jQuery update in the previous commit because the `css(..)` jQ method used by that test depends on `getComputedStyle` internally.
-
Robert Knight authored
Use `serviceConfig()` everywhere
-
- 20 May, 2017 1 commit
-
-
Robert Knight authored
Update our horrifically old jQuery build which included workarounds for browsers we no longer support to the current stable version of jQuery. Also switch to using the slim build which excludes features we don't use. This reduces the size of the minified jQuery bundle from 96KB to 68KB.
-
- 19 May, 2017 7 commits
-
-
Sean Hammond authored
Always use `serviceConfig()` instead of accessing `settings.services` directly.
-
Sean Hammond authored
If the user is logged in to a third-party account and the host page has provided an `onHelpRequest` callback function, then call this function when the _Help_ button in the sidebar's login menu is clicked, instead of doing the button's normal behavior.
-
Sean Hammond authored
Enable partner sites to customize the behavior of the user profile link in the sidebar's login menu. The current behavior of this link is: * If the user is logged out it doesn't show * If the user is logged in to a first-party account it does show, and links to their https://hypothes.is/users/<username> page * If the user is logged in to a third-party account then it does show, and displays their username, but it is just an unclickable `<span>` not a link This commit changes it so that if the user is logged in to a third-party account and the host page has provided an `onProfileRequest` callback function, then the profile link will be clickable and clicking it will call this callback function instead of linking to a hypothes.is user page. If the user is logged in to a third-party account but no `onProfileRequest` function has been provided, then the link will be shown unclickable as before.
-
Sean Hammond authored
The current behavior of the log out button in the sidebar is: * If the user is logged out it doesn't show * If the user is logged in to a first-party account it does show * If the user is logged in to a third-party account it **does not** show Change the log out button to show when the user is logged in to a third-party account **and the host page has provided an onLogoutRequest callback function**. When clicked the log out button will call this callback function, instead of doing the normal (first-party) log out procedure. If the user is logged in to a third-party account and no `onLogoutRequest` callback function has been provided, then the log out button will not be shown (as before).
-
Sean Hammond authored
When a on*Request callback function is provided by the host page (for example onLogoutRequest) add a corresponding onLogoutRequestProvided boolean to the settings object. This is because the on*Request functions don't get passed from the host page context into the sidebar code, because functions aren't JSON stringifiable, so the sidebar code has no way of knowing whether or not a callback function was provided. We're going to be adding code to the sidebar that does need to know this, so add on*RequestProvided settings to tell it.
-
Sean Hammond authored
Reorganize the tests according to the components (the different items in the login menu) instead of by context. Instead of: when a first party user is logged in it shows the profile, account settings, help and log out buttons when a third party user is logged in it only shows the profile button (but disabled) and the help button username etc We now have: describe: the profile button when the user is logged out it does not show when a first party user is logged in it shows the enabled profile button when a third party user is logged in it shows the enabled profile button etc describe: the log out button etc etc This will make the tests easier to write as we're going to be adding more complex behavior to some of the buttons, both logic about when the buttons do and don't show and are enabled or disabled, and logic about what happens when a button is clicked. It'll be easier to manager if all the tests for each button are grouped together. eorganize tests by component
-
Sean Hammond authored
There's no need for this function to use `new` or `this`.
-
- 18 May, 2017 8 commits
-
-
Sean Roberts authored
Some minor docstring fixes
-
Robert Knight authored
Show an error message to the user when getting or refreshing an OAuth access token fails
-
Sean Hammond authored
-
Sean Hammond authored
-
Sean Hammond authored
-
Sean Hammond authored
When the client is embedded in a page that includes a services configuration setting then it logs in to Hypothesis using OAuth, getting an access token from the Hypothesis API. The Hypothesis API's OAuth access tokens currently expire after an hour and must be refreshed by the client before then. When the request to refresh an access token fails the client continues to look and work exactly as before from the user's point of view, except that all actions that require communicating with the API such as creating an annotation fail and show error messages. Some actions, such as dismissing the sidebar tutorial, fail with no error message. Currently we only try the refresh request once for each access token and don't retry is the request fails. Even if we did retry the refresh request can't succeed after the access token has expired - it's always possible for the client to get into a situation where the access token is expired and can no longer be refreshed. The only fix (currently) is for the user to reload the page which will re-do the initial grant token request to get a new access token. So when a refresh request fails show an error message to the user telling them that they need to reload the page.
-
Sean Hammond authored
Show an error if the initial request for an OAuth access token fails. When the client is embedded in a page that includes a services configuration setting (see <http://h.readthedocs.io/projects/client/en/latest/publishers/config/#cmdoption-arg-services>) then it tries to login to Hypothesis using OAuth, exchanging the grant token from the services config setting for an access token from the Hypothesis API. If this request for an access token fails (for example, if the Hypothesis server responds with an error) then the client ends up in an invalid state. Some of the sidebar components are not fully rendered, with visible parts missing, no annotations are shown, and actions such as trying to create an annotation fail in broken ways. We should really fix the completely broken appearance and behavior of the client in this state, but that'll be a big job. For now, at least show an error message to the user telling them that they need to reload the page. There's currently no facility to retry the access token request but if the user reloads the page the whole process will begin again and the request will be tried again.
-
Robert Knight authored
Do not let authors flag their own annotations.
-
- 17 May, 2017 1 commit
-
-