Annotator hover behaviour is too sticky

[orientalperil]

I noticed an issue when using Annotator. If I have a page with multiple annotations such as the canonical demo page, http://okfnlabs.org/annotator/demo/, and quickly move my mouse cursor between annotations, the popup stays on the first annotation.

I was able to narrow this problem down to this line: https://github.com/okfn/annotator/blob/16e3331e6392b085225ca0d0bb4d6333ae881d97/src/annotator.coffee#L496

It seems that Annotator checks if the cursor is over an annotation and if it is not, the popup gets hidden. However it seems that Annotator does not check if the annotation the mouse cursor is hovering over is the same as the annotation that it started on.

Maybe this behaviour is on purpose, but it is definitely confusing. In my opinion, if I move the cursor to another annotation I should see the popup associated with that annotation and the popup of the previously hovered over annotation should be hidden.

[tilgovi]

I agree. Would you like to contribute a patch?

[orientalperil]

Can you point me to the place in the code that sets the hover handler?

[tilgovi]

https://github.com/okfn/annotator/blob/cfbd11c903/src/annotator.coffee#L530

Edited so the link doesn't break as we change the file -- Nick

[nickstenning]

So, I'm not necessarily sure that the current behaviour is perfect, but it was added for a very specific reason, namely: it was far too easy to mouse off the viewer while trying to get the cursor up to the controls ("edit", "delete", etc.).

The viewer "hide timeout" as it's referred to in the code, was an attempt to emulate the behaviour of contextual menus on Mac OS X, where when dragging the cursor from menu to submenu, the cursor is allowed to go completely outside the bounds of the menus (and even over other menu items) for a short while, before the submenu is hidden.

If you think the current behaviour is too "sticky", I'd be interested in hearing the result of trying a bunch of different values of viewerHideTimeout. I'd be willing to bet that 0ms is more frustrating than the current value, so maybe a little user testing is required to find the right number!

[tilgovi]

@nickstenning the particular request here is not exactly for a change in timeout. @hekevintran noticed that there is no amount of time after which a the currently hovered annotation will be shown if the viewer is still stuck on a previous annotation because the user moved the mouse from one to another in < viewerHideTimeout.

A simple fix would be to always set the viewer hide timeout, but check, when it fires, if it should actually hide or if maybe a new viewer should be shown, etc.

I've been leaving this open because I want @hekevintran to try. Any luck?

[orientalperil]

Hi @tilgovi @nickstenning, I am interested in resolving this issue, but it is not a huge priority and at the moment I don't have the time to get into it.