H activation fails at abcnews.go.com #2397
Comments
|
|
|
Minimal repro case: <html>
<meta charset="UTF-8">
<body>
<script>
self = {}; // global = {} produces the same result
// Hypothesis bookmarklet
(function(){window.hypothesisConfig=function(){return{showHighlights:true};};var d=document,s=d.createElement('script');s.setAttribute('src','https://hypothes.is/app/embed.js');d.body.appendChild(s)})();
</script>
</body>
</html>Happens in any context where This happens due to assumptions in browserify-shim about global, self and window: // require('annotator') function from hypothesis.min.js:
(function(global) { // global === window.self
...
(function browserifyShim(module, exports, require, define, browserify_shim__define__module__export__) {
(function() {
...
this.Annotator = Annotator; // this === window.self
...
}).call(this);
// neither Annotator nor window.Annotator defined here
browserify_shim__define__module__export__(typeof Annotator != "undefined" ? Annotator : window.Annotator)
}).call(global, undefined, undefined, undefined, undefined, function defineExport(ex) {
// sets exports of 'annotator' module,
// called as browserify_shim__define__module__export__(), with ex being undefined
module.exports = ex
})
}).call(this, typeof global !== "undefined" ? global : typeof self !== "undefined" ? self : typeof window !== "undefined" ? window : {}) |
|
It's not straightforwardly browserify-shim. It's because browserify-shim uses |
The frame-rpc module is a proper CommonJS module and it's footprint is really tiny. Its protocol is simpler. It doesn't handle connection and buffering, but with our onConnect callback we don't need buffering. The connection handshake that jschannel did was so trivial it's been re-implemented here (each side tries to connect to the other once). We have to handle timeouts ourselves, but that's all hidden in the bridge code. In exchange, we get a simpler API, we get rid of the call/notify distinction in favor of just passing a callback or not and we avoid the excess overhead of the recursion guard in the serialization code that was giving us false positive issues with the document title. This is one step toward removing all the browserify-shim requiring libraries from the injected bundle, which will eventually fix #2397.
The frame-rpc module is a proper CommonJS module and it's footprint is really tiny. Its protocol is simpler. It doesn't handle connection and buffering, but with our onConnect callback we don't need buffering. The connection handshake that jschannel did was so trivial it's been re-implemented here (each side tries to connect to the other once). We have to handle timeouts ourselves, but that's all hidden in the bridge code. In exchange, we get a simpler API, we get rid of the call/notify distinction in favor of just passing a callback or not and we avoid the excess overhead of the recursion guard in the serialization code that was giving us false positive issues with the document title. This is one step toward removing all the browserify-shim requiring libraries from the injected bundle, which will eventually fix #2397.
The frame-rpc module is a proper CommonJS module and it's footprint is really tiny. Its protocol is simpler. It doesn't handle connection and buffering, but with our onConnect callback we don't need buffering. The connection handshake that jschannel did was so trivial it's been re-implemented here (each side tries to connect to the other once). We have to handle timeouts ourselves, but that's all hidden in the bridge code. In exchange, we get a simpler API, we get rid of the call/notify distinction in favor of just passing a callback or not and we avoid the excess overhead of the recursion guard in the serialization code that was giving us false positive issues with the document title. This is one step toward removing all the browserify-shim requiring libraries from the injected bundle, which will eventually fix #2397.
The frame-rpc module is a proper CommonJS module and it's footprint is really tiny. Its protocol is simpler. It doesn't handle connection and buffering, but with our onConnect callback we don't need buffering. The connection handshake that jschannel did was so trivial it's been re-implemented here (each side tries to connect to the other once). We have to handle timeouts ourselves, but that's all hidden in the bridge code. In exchange, we get a simpler API, we get rid of the call/notify distinction in favor of just passing a callback or not and we avoid the excess overhead of the recursion guard in the serialization code that was giving us false positive issues with the document title. This is one step toward removing all the browserify-shim requiring libraries from the injected bundle, which will eventually fix #2397.
|
I'll double check but don't think this can be closed yet. My commit message said "This is one step toward removing all the browserify-shim requiring Only one step. |
|
I don't know what fixed this but it is fixed. The repro that @robertknight posts still causes problems. I've opened thlorenz/browserify-shim#183 to discuss, but given that we don't have an actual site report here for a real-world case where |
|
Looks like the code which triggered the issue in the 3rd-party website was rewritten from merlin.js to merlin-core.js, removing the assignment to the global |
URL: http://abcnews.go.com/Politics/lindsey-graham-destroyed-cellphone-spite-donald-trump/story?id=32621487
Symptom: Hypothesis does not activate
Console error in hypothesis.min.js:
Uncaught TypeError: Cannot read property 'Util' of undefined8.../annotation-sync @ hypothesis.min.js?bc659cac:2s @ hypothesis.min.js?bc659cac:1e @ hypothesis.min.js?bc659cac:1(anonymous function) @ hypothesis.min.js?bc659cac:1
The text was updated successfully, but these errors were encountered: