Skip to content

C
coopwire-hypothesis
Switch branch/tag
  1. 07 Feb, 2022 9 commits
  3. 04 Feb, 2022 4 commits
    • Eduardo Sanz García's avatar
      Show buckets in the bucket-bar for VitalSource · c3f6ebe9
      Eduardo Sanz García authored 
      Background information

Currently, the bucket-bar should display anchor positions only from a
_single_ guest frame. This is because there is no merging mechanism for
anchor positions from multiple guest frames.

Before this PR

* The host frame listened for `anchorsChanged` events from
_all_ the guest frames.

* Only _one_ guest frame sent this event. We referred to this guest
  frame as having the 'main' annotatable content.  The 'main'
  annotatable guest frame was identified by not having a
  `subFrameIdentifier` (a configuration option added to a guest frame
  when the Hypothesis client was injected). Hence, the 'main'
  annotatable guest frame was always the frame where the Hypothesis
  loaded initially (in contrast with the injection mechanism).

In this PR

We have reversed the logic of how the `anchorChanged` RPC
events are send and received:

* _Every_ guest frame sends `anchorsChanged` RPC events to the host
  frame.

* The host frame chooses to listen to only _one_ guest frame for the
  `anchorsChanged` RPC events: the guest frame that connects first with
  the host.

For non-VitalSource case, the first guest frame that connects to the
host frame is the one where the Hypothesis client was initially loaded
(doesn't contain `subFrameIdentifier` option).

For the VitalSource, because of #4176, there is no guest frame in the
host frame. This allows the guest frame in the book content, where the
Hypothesis client was injected, to send anchor positions, and positions
to be reflected in the host's bucket-bar.
      c3f6ebe9
    • Eduardo Sanz García's avatar
      Improve consistency on bucket hovering and focusing · 259d695e
      Eduardo Sanz García authored 
      On #4069, we introduced a small improvement when hovering a left-pointed
bucket: focus the corresponding annotation card, in addition to the
anchor's highlight.

In this PR, we introduce the same improvement to the up and down-pointed
buckets.

In addition, I have realised we handled `onBlur` but not `onFocus`
events. I have added more complete support for keyboard navigation.

I substituted `onMouseMove` for `onMouseEnter` because it is triggered
less frequently.
      259d695e
    • Eduardo's avatar
      Apply suggestions from code review · 6ed8c93b
      Eduardo authored 
      Co-authored-by: 's avatarRobert Knight <robertknight@gmail.com>
      6ed8c93b
    • Eduardo Sanz García's avatar
      Do not create a `Guest` instance in the VS container · 1b8e8a4d
      Eduardo Sanz García authored 
      In order to not create an unnecessary `Guest` instance in the
VitalSource container we needed to do the following:

* The `VitalSourceContainerIntegration` is stripped down and converted
  to a class, `VitalSourceInjector`, that does not implement the
  Integration interface but is only responsible for injecting the client
  into content frames.

* The host frame checks the VS frame role and either constructs a Guest
  or sets up the `VitalSourceInjector` as appropriate.

* The `HypothesisInjector`-related logic in `Guest` is extracted out of
  that class and set up in the annotator entry point instead.
      1b8e8a4d
  5. 03 Feb, 2022 4 commits
  7. 02 Feb, 2022 8 commits
    • Robert Knight's avatar
      Revise comments for `frameForAnnotation` · 4c9bdda1
      Robert Knight authored
      4c9bdda1
    • Robert Knight's avatar
      Explain why new guests must be added to `_guestRPC` map immediately · 3ddf3cff
      Robert Knight authored
      3ddf3cff
    • Robert Knight's avatar
      Add test to check that annotations are only sent to expected frame · 71476ef9
      Robert Knight authored
      71476ef9
    • Robert Knight's avatar
      Only send annotations to matching frame · 0a1077b3
      Robert Knight authored 
      When the sidebar is connected to multiple guest frames it will send all
incoming annotations to all frames. The result is typically that the
annotation will anchor in one frame and orphan in the others. Depending
on what order this happens in, the annotation will non-deterministically
show up as an Annotation or Orphan in the sidebar.

In order to determine which frames an annotation should be sent to in
all cases, we'd either need the backend to return information about which
search URIs an annotation matches or make a separate search request for
each frame and record the associated frame with the results. This
will require some significant refactoring of the annotation search
service.

As an interim step, make `FrameSyncService` send annotations only to a
single frame based on matching URL, with a fallback to sending to the
main frame if there is no exact match. This will work as expected for
most pages, and is at least deterministic when it does fail. When we
have a solution for being able to match annotations to frames more
generally, we can adapt this code to use it.

This is a partial solution to https://github.com/hypothesis/client/issues/3992.
      0a1077b3
    • Robert Knight's avatar
      Add a note about a race condition in port discover vs unloading · 9465de91
      Robert Knight authored
      9465de91
    • Robert Knight's avatar
      Move some variables closer to first use and update a test description · ebe7e380
      Robert Knight authored
      ebe7e380
    • Robert Knight's avatar
      Add test for handling of `frameDestroyed` event from guest in host frame · 41bad1f9
      Robert Knight authored
      41bad1f9
    • Robert Knight's avatar
      Revise how guest notifies host and sidebar when it is unloaded · 4b021476
      Robert Knight authored 
      Change how the guest notifies other frames, specifically the sidebar and host,
when it is unloaded. The host and sidebar now receive a `frameDestroyed` message
from the corresponding guest port, which allows them to easily close the right
port and remove it from the list of active guest ports.

Due to a Safari bug (see code comments) we can't send the `frameDestroyed`
messages from the guest frame while it is being unloaded. However it is possible
to first transfer the port to the host frame and then have the host frame send
the message on the same port. I also tried sending the message from the guest
frame, and then transferring the port to the host frame but that didn't work.
This workaround has the advantage that it is transparent to the receiver of the
`frameDestroyed` message.

This change is also a step towards possibly not relying on user-provided guest
frame identifiers in the sidebar, which only become available once the
`documentInfoChanged` call has been received. Instead the sidebar could
use its own internal IDs for guest frames, avoiding the possibility for
conflicts.

Changes in detail:

 - Add `disconnect` method to PortRPC

 - When guest is unloaded, transfer ports to the host frame in a
   `hypothesisGuestUnloaded` message, and make the host frame dispatch
   `frameDestroyed` calls on these ports.

 - Handle `frameDestroyed` in sidebar by closing port, removing it from
   the active guest list and removing the associated frame from the
   store

 - Handle `frameDestroyed` in host frame by closing port and removing it
   from the active guest list
      4b021476
  9. 01 Feb, 2022 15 commits