ResolvingLoader takes a list of resolvers, not paths (to allow for custom overrides)
ResolvingLoader and ArcWarcRecordLoader support 'no_record_parse' on load to not parse http headers from stream
auth resolver can be used by setting 'cookie_resolver: false' explicitly. when using auth resolver,
don't set proxy magic path as switching collections or datetime is not possible with auth resolver
closes#160
For Via, we want rel=canonical links to resolve to the same
absolute URL as it did on the original page.
For absolute URLs, no rewriting is necessary. If the original
rel=canonical URL was relative however, it needs to be resolved
relative to the original URL.
See https://github.com/hypothesis/via/issues/65 for context.
The values returned by getting the 'href' and 'toString'
properties of an anchor element should be the same.
This inconsistency broke the URL polyfill in
https://github.com/inexorabletash/polyfill under Microsoft Edge
* Increase the default timeouts to account for the relative
slowness of setting up connections to remote browsers.
* Change the URL into which Wombat JS is loaded for
tests to be a valid URL. Under Microsoft Edge, the JS
code in the page is not run if the URL fetch returns a 404.
* Change assert.equal() implementation to avoid confusion due
to Karma's reformatting of URLs in exception error messages.
Wombat overrides document.baseURI and <base>.href in order
to return the original URL rather than the proxied URL.
The <base>.href override however ended up making a writable
attribute read-only, which could trigger script errors
in strict-mode JS.
Fix this by avoiding replacing the setter for a DOM property
if no replacement setter is provided.
Fixes an error loading Hypothesis under Microsoft Edge.
Rather than specifying the username and encrypted
key in the Travis config, we just enable Sauce Connect
and require SAUCE_USERNAME and SAUCE_ACCESS_KEY env vars
to be set.
This is so that the Karma tests have the same env vars
available to them which they can use to check whether
to run against Sauce Labs or not.
For some Karma tests, we can run them faster by running
against a local browser in the Travis CI instance rather
than Sauce Labs.
This is also useful for:
- Contributors wishing to run
the Travis tests against their own forks and have not
set up Sauce Labs credentials.
- Running Karma tests against Pull Request builds where
Sauce Connect is not available.
* Provide a fallback mode in the Karma tests which tests
against a local browser (defaults to Firefox) if Sauce Labs
credentials are not set.
This is useful for local testing for contributors who
might not have a Sauce Labs account.
* Add Safari under OS X to the set of Sauce Labs browsers
that the Karma tests are run against, following the merge
of the WombatJS fixes for Safari and Edge.
Although Edge now works under manual testing, automated
testing against Sauce Labs is not yet working for reasons
yet to be determined.
Detect in the test whether overriding of DOM properties
is supported in the current environment and skip testing
for the baseURI override in that case.
In Safari 9, Object.getOwnPropertyDescriptor(domObject.prototype, prop)
returns descriptors which have the correct structure but undefined
getters and are marked as unconfigurable.
See https://bugs.webkit.org/show_bug.cgi?id=49739#c19
for details. The getters cannot be retrieved via obj.__lookupGetter__()
either.
* Resolve the issue by skipping overrides for DOM properties
where the property is not configurable, or the original getter for
a property could not be retrieved.
* Lookup the 'baseURI' property on the correct prototype (Node,
not document)
This fix also resolves the problem where accesses to document.baseURI
on Edge would fail.
Existing JS files in this repo use Python-esque spacing
and naming conventions (4 spaces, snake_cased) rather than
JS conventions (2 spaces, camelCased).
This gives us the capability to test the client-side JS
rewriting against a suite of different browsers on different
platforms.
Note that getting Karma running on Travis CI requires some
additional configuration documented at
github.com/karma-runner/karma-sauce-launcher/issues/73
which is not made clear in the original documentation.
In order to run the Karma tests, the Sauce Labs username
and access keys need to be passed in via the SAUCE_USERNAME
and SAUCE_ACCESS_KEYS env vars.
* Add a Karma configuration for unit/integration tests
for the client-side pywb code.
* Add an integration test suite which creates an <iframe> loads
the client-side rewriting code (wombat.js) in it and
then executes a test script.
Since wombat.js monkey-patches the DOM and the exact behavior
of DOM objects varies between browsers, which we want to test,
the suite does not mock the DOM but instead runs
a set of tests in an isolated environment against
the DOM.
* Add Travis config to run the Karma tests
