modebar always visible in FF and IE

[alexcjohnson]

only in Chrome does the modebar hide when you mouse away, as it should - in FF and IE it's always present. Looks like that's because has-hover doesn't work correctly in those browsers (both of its matchMedia(...).matches calls return false there).

cc @dfcreative

[etpinard]

@dfcreative can you try to get a fix in for this today or tomorrow?

[rreusser]

Testing the negation, i.e. !window.matchMedia('(hover: none)').matches seems like it might be more reliable. Works in firefox, chrome, safari, and the iOS simulator for me.

[dy]

@rreusser fixed by your method, thank you! dy/has-hover@d835404

[farhadfarhadii]

https://codepen.io/eiymba/pen/WOEzKz?editors=0010

Hi All,

I appear to be having this issue on chrome version 60 now. As you can see from the GIF, the mode bar persists even when the mouse is not hovering on the element.

[alexcjohnson]

@eiymba strange, I cannot reproduce this with your codepen. What kind of hardware & OS are you using? Can you try https://codepen.io/alexcjohnson/pen/yoaxBw and tell me what message you see at the bottom? Should be:

false (should be false in a desktop browser, true on touch)

[farhadfarhadii]

@alexcjohnson Thanks for responding! I'm using a surface pro 3 + Win 10. The value is true. I'm sorry I couldn't capture the mouse position for some reason.

Hah! I guess this has become somewhat a headache for you, since desktop devices could have touch input as well 😄.

Edit: Here's my pen and your pen side-by-side

[alexcjohnson]

@eiymba thanks for the clarification. That's weird - you run your pen and the modebar doesn't hide, but then you run mine - which is identical to yours, I just added

document.write(matchMedia('(hover: none)').matches +
    ' (should be false in a desktop browser, true on touch)')

at the end - and the modebar does hide but the message at the bottom indicates that it shouldn't.

@dfcreative dunno if you have any thoughts on how this could happen - matchMedia responding differently to the same query within one session? Perhaps during loading the page couldn't decide whether the trackpad was present or not?

But I'm frankly not sure we really want the modebar to hide on a hybrid device like a surface - using it without a keyboard/trackpad is a totally valid mode of operation, and in that case a hidden modebar would simply be inaccessible so the plot would not function as expected. See eg http://www.stucox.com/blog/the-good-and-bad-of-level-4-media-queries/#multiplicity - hover is only supposed to be truthy if you have a mouse and no touch interface.

[farhadfarhadii]

@alexcjohnson hmm, that is a valid point. I'm not too sure what testing conditions are available to the dev team, however, using an older version of plot.ly, I am able to view the modebar on both my surface and android phone (with chrome) simply by tapping on the graph once.

https://codepen.io/eiymba/pen/NvbqJR

my tap gestures have also been captured! 😁

[rreusser]

@eiymba I think that's a result of how touch devices handle hover. On iOS at least, it behaves more like focus. Tapping once bubbles up and activates hover. Tapping elsewhere deactivates hover. I often find it a bit unpleasant, though here it seems like it might actually be a good fit. Do you think the discoverability of knowing you can tap to reveal the modebar is a problem?

[rreusser]

There's has-touch in addition to has-hover, but thinking through all four cases:

	has-touch	!has-touch
has-hover	your device	desktop
!has-hover	mobile	💀

Maybe then it hinges on which behavior your device supports. If it's more like desktop (tap-to-display), then has-hover seems more appropriate. If more like mobile (always visible), then has-touch seems more appropriate. (To be honest, this seems backwards… I need to double check this against the above description of how has-hover works on your device)

[farhadfarhadii]

Okay, I figured out the issue here.

When I plug in my surface to the dock, I flip the keyboard back which deactivates it (i use an external keyboard/mouse). This is usually how I have it set up at a desk. Moronically, it did not occur to me that I should try this with the typecover not flipped back before writing here. so my apologies in causing such a stir, it wasn't my intention 😞 . With the keyboard not flipped back, the mode bar works as expected!

Although, the presumption that touch devices wouldn't have a trackpad isn't quite true, when you consider devices like iPad pro. I have a tablet with a bluetooth keyboard and trackpad, and the mode bar remains persistent. In general, I'm not particularly a fan of using hover states to provide functionality. I guess I'll have to have a dig around the API to find out how I can reroute that mode bar functionality into an external component.

Thanks for your help guys!