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!

[alexcjohnson]

I think @rreusser is right to point to discoverability in touch environments. Seems like in general then we should leave it as is. I guess if anyone feels strongly that they'd STILL like the modebar hidden until you tap the plot, we could add a config option like displayModeBar: 'hover-touch' but I'll wait until this idea gets a few 👍 's before doing that.

[farhadfarhadii]

I'd leave it as is, if it's not a big issue for others 😄 .

I personally don't believe the current modebar implementation has any place in a touch UI environment, to be honest. On small, touch screens, the modebar overlaps the xaxis when it's set as side:top

This isn't a big deal, since I can just hide the modebar and implement my own, but it's worth noting.

[Braintelligence]

Is this issue still prevalent? I can't get it to work like this in FF or Chrome on Windows 10:

 Plotly.newPlot(graph, data, baseLayout, {
    displaylogo: false,
    modeBarButtonsToRemove: [ list_of_options ],
    displayModeBar: "hover",
})

The modebar stays visible no matter where the mouse is.
Also another question because the documentation on the modebar is really, really scarce: How would I go about removing the background opacity?

[antoinerg]

@Braintelligence you are right that the documentation is still scarce for modebar. As of right now, you can customize its appearance using the following layout attributes:

plotly.js/src/plots/layout_attributes.js

Lines 373 to 411 in cc45972

	modebar: {
	orientation: {
	valType: 'enumerated',
	values: ['v', 'h'],
	dflt: 'h',
	role: 'info',
	editType: 'modebar',
	description: 'Sets the orientation of the modebar.'
	},
	bgcolor: {
	valType: 'color',
	role: 'style',
	editType: 'modebar',
	description: 'Sets the background color of the modebar.'
	},
	color: {
	valType: 'color',
	role: 'style',
	editType: 'modebar',
	description: 'Sets the color of the icons in the modebar.'
	},
	activecolor: {
	valType: 'color',
	role: 'style',
	editType: 'modebar',
	description: 'Sets the color of the active or hovered on icons in the modebar.'
	},
	uirevision: {
	valType: 'any',
	role: 'info',
	editType: 'none',
	description: [
	'Controls persistence of user-driven changes related to the modebar,',
	'including `hovermode`, `dragmode`, and `showspikes` at both the',
	'root level and inside subplots. Defaults to `layout.uirevision`.'
	].join(' ')
	},
	editType: 'modebar'
	},

I hope this helps!

[Braintelligence]

Thank you @antoinerg 😸.
I've found this bit already, but I thought this would also work:

plotly.js/src/components/modebar/modebar.js

Line 56 in 673b542

if(context.displayModeBar === 'hover') this.element.className += ' modebar--hover ease-bg';

How can I make it appear only on hover?

[etpinard]

FF or Chrome

@Braintelligence could you tell us which version of FF and Chrome you're using? Thank you!

[Braintelligence]

@etpinard FF 64.0.2 and Chrome 71.0.3578.98