- 15 Jun, 2017 7 commits
-
-
Sean Hammond authored
Update docs to mandatory apiUrl field in the service.
-
Sheetal Umesh Kumar authored
-
Robert Knight authored
Enable reading openLoginForm and openSidebar from the host page
-
Sean Hammond authored
Whitelist the openLoginForm and openSidebar settings as being readable from the host page even when the client is in a browser extension. When you first install the Chrome extension it opens the /welcome page in a tab, and it injects the openLoginForm and openSidebar settings into the /welcome page in order to get the sidebar and login form to automatically open on that page. A previous change to prevent the Chrome extension from reading settings from the page broke this /welcome page behaviour. Fix it again by whitelisting the two required settings. Of course this means that any page on the internet, not just the /welcome page, and control these two settings, which is not what we want, but it will do for now.
-
Sean Hammond authored
Add an allowInBrowserExt boolean option to hostPageSetting() so that some host page settings can be white-listed as readable from the host page even when the client is in a browser extension.
-
Sean Hammond authored
-
Robert Knight authored
(config 4/n): Introduce hostPageSetting() method
-
- 14 Jun, 2017 15 commits
-
-
Sean Hammond authored
Fixing js error on :3000 page
-
Sean Roberts authored
-
Sean Hammond authored
Add Symbol polyfill
-
Sean Hammond authored
Use the new `settings.hostPageSetting()` method in `index.js`. This means that `index.js` no longer uses `shared/settings.js` (`jsonConfigsFrom()`) or `configFuncSettingsFrom()`. These are both encapsulated in `hostPageSetting()`. Previously `index.js` blindly assigned a lot of property names and values fo the `config` object using a couple of `Object.assign()` calls: Object.assign(config, sharedSettings.jsonConfigsFrom(window_.document)); Object.assign(config, configFuncSettingsFrom(window_)); These `Object.assign()`s are now gone, and instead it explicitly assigns each property to the `config` object by name: var config = { app: settings.app, query: settings.query, ... openLoginForm: settings.hostPageSetting('openLoginForm'), openSidebar: settings.hostPageSetting('openSidebar'), ... }; (Some of these settings were already being assigned in this way, but the ones that uses `hostPageSetting()` are new.) This also means that `index.js` no longer uses `isBrowserExtension()`. Previously `index.js` contained logic to return early, declining to read various config settings from the host page using its `Object.assign()`s, if the client was running in a browser extension. This logic is also now encapsulated in the new `settings.hostPageSetting()` method and so is removed from `index.js`.
-
Sean Hammond authored
Add code to the `settings.annotations()` method so that, instead of reading the setting from the URL only, it reads the annotations setting from the `js-hypothesis-config` scripts in the host page or, failing that, tries to read it from the URL. In `index.js`, after `settings.annotations()` is called, there are two `Object.assign()` calls that overwrite values already in the `config` objects with any returned from `js-hypothesis-config` scripts or the `window.hypothesisConfig()` function in the host page. So a `config.annotations` setting from `settings.annotations()` already gets overwritten by a `annotations` setting in a `js-hypothesis-config` script or `hypothesisConfig()` function. This commit makes that overwriting explicit, encapsulates it in the `annotations()` method, and unit tests it. Note that the two `Object.assign()`s are still present in `index.js` so the `config.annotations` setting returned by the `annotations()` method still gets overwritten by them, but this now has no effect as the `annotations()` method will already have set `config.annotations` to the same value that it will be overwritten with. In a future commit the `Object.assign()`s will be removed and there won't be any overwriting. Note that **this will change the behaviour of the code** once the `Object.assign()`s have been removed: the `annotations()` method reads the annotations setting from `js-hypothesis-config` scripts but does not read it from `window.hypothesisConfig()` any longer. I don't believe it's necessary to read `annotations` from `hypothesisConfig()`.
-
Sean Hammond authored
Add code to the `settings.query()` method so that, instead of reading the setting from the URL only, it reads the query setting from the `js-hypothesis-config` scripts in the host page or, failing that, tries to read it from the URL. In `index.js`, after `settings.query()` is called, there are two `Object.assign()` calls that overwrite values already in the `config` objects with any returned from `js-hypothesis-config` scripts or the `window.hypothesisConfig()` function in the host page. So a `config.query` setting from `settings.query()` already gets overwritten by a `query` setting in a `js-hypothesis-config` script or `hypothesisConfig()` function. This commit makes that overwriting explicit, encapsulates it in the `query()` method, and unit tests it. Note that the two `Object.assign()`s are still present in `index.js` so the `config.query` setting returned by the `query()` method still gets overwritten by them, but this now has no effect as the `query()` method will already have set `config.query` to the same value that it will be overwritten with. In a future commit the `Object.assign()`s will be removed and there won't be any overwriting. Note that **this will change the behaviour of the code** once the `Object.assign()`s have been removed: the `query()` method reads the query setting from `js-hypothesis-config` scripts but does not read it from `window.hypothesisConfig()` any longer. I don't believe it's necessary to read `query` from `hypothesisConfig()`.
-
Sean Hammond authored
Add a new `annotator.config.settingsFrom#hostPageSetting(settingName)` method that encapsulates a bunch of logic in one method: - It always returns null if the client is from a browser extension. Browser extensions don't read settings from the host page. - If the host page's `window.hypothesisConfig()` function returned a value for the requested setting, `hostPageSetting(settingName)` returns that value. - If `hypothesisConfig()` doesn't return the setting it looks for it in `js-hypothesis-config` scripts in the host page - If the setting isn't defined in either place it returns `undefined`.
-
Robert Knight authored
(config 3/n): Turn the settings obj into a settingsFrom function
-
Sean Hammond authored
annotator.config.settings currently exports an object containing individual standalone functions for returning different settings' values: module.exports = { app: appFunction, annotations: annotationsFunction, ... }; Change it to export just a single constructor function - settingsFrom() - that returns an object containing the previously-exported functions as methods: function settingsFrom(window_) { ... return { get app() { return app(); }, get annotations() { return annotations(); }, ... }; } module.exports = settingsFrom; Note that ES5 getters are used so that, even though app() and annotations() are methods rather than simple properties now, they can still be accessed as properties - settings.app not settings.app(). This makes the code that uses this object slightly simpler, and makes mocking this object in unit tests simpler. The diff of this commit looks big, because the indentation of a lot of code is changed, but it really is just changing functions into methods and not actually changing the code of any of those functions. The reason for turning functions into an object with methods is so that the object that settingsFrom() returns can have state (by having closure variables inside the settingsFrom() function). We don't make any use of this state yet but future commits will do.
-
Robert Knight authored
(config 2/n): Move configFuncSettingsFrom() into its own file
-
Robert Knight authored
This is needed for various ES6 language constructs, such as `for ... of` loops, to work because the transpiled code depends on references to properties of the `Symbol` object (eg. Symbol.iterator).
-
Sean Hammond authored
Cut-paste the configFuncSettingsFrom() function and its unit tests out of settings.js and into its own config-func-settings-from.js file. This is because in a future refactoring index.js isn't going to call configFuncSettingsFrom() anymore, only settings.js will call it, which would make configFuncSettingsFrom() a private helper function of settings.js, but I don't want to lose configFuncSettingsFrom()'s unit tests so I'm moving it into its own file from where settings.js (in the future, index.js currently) can import and use it. This way configFuncSettingsFrom() remains part of the public API of its containing module and can have unit tests.
-
Robert Knight authored
(config 1/n): Move isBrowserExtension() into own file
-
Sean Hammond authored
Upgrade gulp-sass
-
Sean Hammond authored
Convert tags service to JS
-
- 13 Jun, 2017 5 commits
-
-
Robert Knight authored
This fixes a build error with Node v8.
-
Robert Knight authored
-
Robert Knight authored
-
Sean Roberts authored
Multiple frame detection and injection
-
Sean Roberts authored
Enable ES2015 transpilation in the client
-
- 12 Jun, 2017 13 commits
-
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
(was testing `srcdoc` and forgot to remove this before pushing)
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
-
Juan Corona authored
-
Sean Hammond authored
Tweak `isBrowserExtension()` to take just the `config.app` string that it needs and not the entire `config` object as argument. This is necessary for `isBrowserExtension()` to be called by `settings.js` instead of `index.js` (as I want it to be in the future) - when it's called by `settings.js` the `config` object as a whole won't be available (and hasn't been constructed yet).
-