Open editor will move when someone else annotates

[dwhly]

Steps to reproduce

1. Select text and click to annotate midway down on a reasonably well annotated page, like this: https://via.hypothes.is/https://www.commonsense.org/education/privacy/blog/digital-redlining-access-privacy
2. Wait for someone else to make an annotation on the page while the editor is open

Expected behaviour

My editor should stay put, so I can compose my annotation

Actual behaviour

It jumps around, occasionally scrolling out of view

Browser/system information

Modern chrome, via.

Additional details

Video: https://drive.google.com/file/d/0B0yW-dSdEYAcM1BWMTZUUGpRWVk/view

cc @jeremydean

[robertknight]

Which version of the client did you test with? Hypothesis v0.39 (released earlier today) has much less disruptive behavior when annotation edits/additions happen while you are interacting with the page. Edit: Just read your last comment on #83

I can see that new annotations could still result in the editor being moved, if the new annotations are added above the position of the editor. In that case we would need to scroll the sidebar to guarantee that the current editor remains visible, and we're not currently doing that.

[dwhly]

In that case we would need to scroll the sidebar to guarantee that the current editor remains visible, and we're not currently doing that.

Yep. The more of these "flash mobs" that happen, the more important it will be that the editor stays put while folks are annotating. :)

[jeremydean]

it's not just flash mobs, it seems reasonable that a class should be able to annotate together in class.

not to mention a flash mob is just a way of saying what happens when we have millions of users all annotating the latest speech by president trump...

[jeremydean]

i think i have reproduced the situation here using two h accounts in two separate windows (both chrome, one ext, one via incognito) on the same doc in the same group:

http://screencast.com/t/mt5fMYyN

what i see here is the open composition window from browser/user a moves each time i create an annotation browser b by user b, eventually moving out of site.

a second issue occurs which is suddenly multiple composition windows open at once in browser b while annotating, but that hasn't been reported by users.

[robertknight]

I'd like to clarify more precisely what the expected behavior is at the moment, and verify that everyone is seeing the same thing. It would be helpful for me if others could verify that they see the same behavior and not something worse. Please try out the steps under the Testing protocol section below.

With the default configuration of the client, annotations are sorted in order of document location. When new annotations arrive, they are inserted into the list in the appropriate position and the current scroll position of the sidebar is not adjusted. The expected behavior therefore is that with Hypothesis v >= 0.39:

1. A new annotation added above an annotation that you are editing will therefore cause the editor window to shift down by the height of the new annotation.
2. A new annotation added below an annotation that you are editing will not result in the editor window moving.
3. An edit to an annotation below the annotation you are editing will not result in the editor window moving
4. An edit to an annotation above the annotation you are editing may result in the editor window moving

The behavior with notes is not properly specified in the code, resulting in different behavior when notes are initially loaded versus when new notes are added later. The current behavior is that notes go to the top of the list when they are created, which seems unhelpful.

Testing protocol:

On a web document or PDF (please specify the URL you used when testing) with v0.40 and the Annotations tab selected:

1. In tab A, start an annotation in the middle of the document, leave the editor open.
2. In tab B, create an annotation anywhere after the text being annotated in tab A. Expected behavior: In tab A, the editor window stays where it is.
3. In tab B, create an annotation before the text being annotated in tab A. Expected behavior: In tab A, the editor window shifts down by the size of the annotation added in tab B

[dwhly]

Thank you Robert, I'll be in a place where i can test in about an hour.

[dwhly]

Testing on this PDF:
http://docdrop.org/pdf/The-Rime-of-the-Ancient-Mariner-text-of-1834-by-Samuel-Taylor-Coleridge---Poetry-Foundation-jKwov.pdf/

I have verified exactly the behavior you've just suggested. The primary issue is when annotations come in to my sidebar higher than an editor I have open.

As a side note, Remi Holden also complained about general jumpiness of the sidebar even when reading-- which suggests that perhaps a strategy to stabilize cards regardless of whether they're editors would be interesting. I know it's probably tricky, since there might be 3 or 4 or more cards visible in the sidebar at once.

A strategy might be:

• If there's an editor open and a card enters the sidebar above it, then scroll the sidebar up so that the editor does not appear to move. Otherwise...
• If a card enters above the top card in the sidebar, scroll the sidebar up by the height of the entering card-- so that the sidebar in the viewport appears to stay put, Otherwise...
• No change to the current behavior.

Of course I have no idea how difficult any of this is.

[judell]

http://jonudell.net/h/reply-vanishes-under-concurrency.mp4 illustrates this in the brand new v0.40 extension.

1. Begin a reply
2. Run a script that pumps in annotations

[jeremydean]

but @judell does vanish mean gets closed and lost or moved out of sight? neither is acceptable, but can you scroll to it?

[lenazun]

Defer applying realtime updates

[judell]

@jeremydean yes you can scroll to it.

[robertknight]

This issue was fixed by simply not updating the sidebar automatically when new annotations are added on a page you are viewing. Instead an icon in the toolbar indicates that new annotations are available and the user has to click it to see them.