client
client copied to clipboard
Annotations don't anchor in iframe if fetched based on Dublin Core identifier
Minimum Example: I have two file test1.html and test2.html each contain an iframe using srcdoc or src with
<head>
<meta name='dc.identifier' content='test'>
<meta name='dc.relation.ispartof' content='strcutseeker'>
</head>
Highlight/annotation inside one iframe become orphan for another iframe.
I suspect the cause is that when receiving annotation from server, the target property of annoation is usually url rather than fingerprint-like urn:x-dc:....
Note that even if i am not using srcdoc, using src with even the same link still cause similar phenomenon; also setting test1.html and test2.html with the same dublin meta data can't fix the problem.
I can reproduce as follows:
- Save the files below locally
- Serve with
python -m http.server 3011 - Navigate to http://localhost:3011/parent1.html. Activate client and annotate text "Child 1"
- Go to http://localhost:3011/parent2.html. Observe that an orphan appears.
parent1.html
<html>
<body>
<iframe src="child1.html" enable-annotation></iframe>
</body>
</html>
parent2.html
<html>
<body>
<iframe src="child2.html" enable-annotation></iframe>
</body>
</html>
child1.html
<html>
<head>
<meta name='dc.identifier' content='test'>
<meta name='dc.relation.ispartof' content='strcutseeker'>
</head>
<body>Child 1</body>
</html>
child2.html
<html>
<head>
<meta name='dc.identifier' content='test'>
<meta name='dc.relation.ispartof' content='strcutseeker'>
</head>
<body>Child 2</body>
</html>
Notes:
The DC metadata here becomes part of the uri query params that are sent to the server as part of /api/search requests. The problem comes when routing the loaded annotations back to the appropriate frames. The logic to route an annotation to the appropriate frame only works if there is an exact URL match between the frame's URI and the annotation's target URI, otherwise it tries to anchor the annotation in the main (parent) frame. See https://github.com/hypothesis/client/blob/fa34788406839e778cac02c9862bbdfb251f003d/src/sidebar/services/frame-sync.ts#L62.
This is a known limitation of Hypothesis's iframe support, described in https://github.com/hypothesis/client/pull/4131.
Is fixing the problem in near future? The feature would be quite helpful.
This is not something we're planning to work on soon. I think the basic approach will involve changing the code that fetches annotations so that it performs a separate fetch per frame and can therefore associate all the annotations from a response with a particular frame. A similar change would need to be made to the WebSocket.
epub.js embed epub primary id and particular file name of page as dublin meta data into the iframe. The feature is very helpful as it would immediately enable annotation function for epub.js based reader.
There is more to EPUB support than just injecting the client into content iframes. If you do that you'll get something that seems to sort-of work but Hypothesis won't understand the relation between the different frames and the parent book, which will lead to some functionality not working as you might expect. The only supported EPUB reader currently is VitalSource. The implementation is in src/annotator/integrations/vitalsource.ts.
Unfortunately, the online vitalsource reader can't sideload epub and can only read what publisher sells on vitalsource platform...
Indeed, VitalSource is not a general-purpose solution for EPUBs. The reason it was implemented is because that's what Hypothesis's education customers needed. An integration with an open source EPUB reader would look similar to the VS one though.