Enable Hover and Click Events Anywhere by alexshoe · Pull Request #7707 · plotly/plotly.js

alexshoe · 2026-02-12T02:46:04Z

Description:

Added 2 new boolean attributes to the layour object: hoveranywhere and clickanywhere, which respectively allow plotly_hover and plotly_click events to be received anywhere in the plot area and not just over traces.

When hovering/clicking on empty space and with no nearby trace, the events will fire with an empty points array but includes xvals, yvals, xaxes, and yaxes so you still get cursor coordinates in data space. When hovering/clicking over a trace, the event behaves as before with full point data.

Example:

layout: {
  hoveranywhere: true, // enables hover events anywhere, even on empty plotting area
  clickanywhere: true // same for click events
}

See this codepen for an interactive demo of this feature

New API:

hoveranywhere

Type: boolean
Default: false
When true, plotly_hover events fire for any cursor position within the plot area, not just over traces. Events on empty space include an empty points array plus xvals and yvals with cursor coordinates in data space.

clickanywhere

Type: boolean
Default: false
When true, plotly_click events fire for any click position within the plot area, not just over traces. Events on empty space include an empty points array plus xvals and yvals with click coordinates in data space.

…ents in empty plot space

…anywhere

alexcjohnson · 2026-02-24T05:11:38Z

@alexshoe this looks great! Really nice codepen, does a great job showing the feature and how to use it 🎉 But the pseudo-spikeline is a little off. There are actually two ways you might want this to behave, and both have some issues today.

(1) Follow the cursor even if there's a data point to hover on. That's mostly what happens in the codepen as written right now, except that when you DO get a data point, we stop emitting hover events until you get a different data point. This means that the pseudo-spikeline gets stuck at the first mouse position where plotlyjs picked a particular data point, until you get to a position where it picks a different data point. Seems to me when we have hover anywhere - and maybe also when we have spike lines snapping to the cursor? - this means we need to emit a hover event, and update the hoverdata so the click event will get the proper coordinates, on every mouse move even if the hovered data point exists and has not changed.

(2) Stick to the data point when you're hovered on one, or follow the cursor when not near a data point. For this flavor I think we have all the events we need, and if you make the pseudo-spikeline out of a shape, I think we have all the information we need in the event. But if you make the pseudo-spikeline out of a raw DOM element, d.event.offsetY isn't correct when you have a data point, you need the actual pixel position of the data point. Personally I could probably get this using things like fullLayout.yaxis.d2p and fullLayout.yaxis._offset but we probably don't want our users to have to use our internals like this; better would be to publish the mouse location of the actual hover point as part of the event data.

alexshoe · 2026-02-24T20:38:54Z

@alexcjohnson Thanks for the comment and for going in depth in those two use cases. Do you think we should enable both of these modes with another attribute or maybehoveranwhere allows you to pick a mode where data points are non-sticky?

For point two, by "mouse location of the actual hover point", do you mean the pixel position of the mouse or the data point that we are close to? I think if we published the latter, we would be able to easily modify my CodePen such that the spikeline follows the cursor when not near a data point, then snaps to the exact position of the nearest data point, when close enough.

For point 1, there's a function in hover.js called hoverChanged. When the mouse moves but the closest data point hasn't changed, hoverChanged returns false and hover event emission is skipped. So we can just set it to NOT skip emission if hoveranywhere is true.

Curious to know what you think

alexcjohnson · 2026-02-26T14:48:09Z

Do you think we should enable both of these modes with another attribute or maybehoveranwhere allows you to pick a mode where data points are non-sticky?

I don't see that we need any new attributes here, just more events and more data in the existing events.

For point two, by "mouse location of the actual hover point", do you mean the pixel position of the mouse or the data point that we are close to? I think if we published the latter, we would be able to easily modify my CodePen such that the spikeline follows the cursor when not near a data point, then snaps to the exact position of the nearest data point, when close enough.

Yes, the latter. Specifically I guess the position where we would draw the spikeline, which can be different from the position of the data point or the position of the hover box in certain cases, like grouped bars where the data point and hover box are drawn to the bar, wherever it's aligned, while the spikeline is drawn to the data value.

For point 1, there's a function in hover.js called hoverChanged. When the mouse moves but the closest data point hasn't changed, hoverChanged returns false and hover event emission is skipped. So we can just set it to NOT skip emission if hoveranywhere is true.

That seems likely to give the behavior we want!

…en if near trace

alexshoe · 2026-02-26T19:55:38Z

@alexcjohnson thanks for the clarification. I've made both changes so that:

Hover events ALWAYS fire if hoveranywhere is on, even if near a data point
Expose x- and. y-pixel values data points

I updated this codepen to reflect these changes too. You'll notice the spikeline now follows the cursor at all times, regardless of proximity to data points. There is also a new hover label that does snap to nearby datapoints, and shares the same color as the trace it references.

…anywhere

alexcjohnson · 2026-02-27T17:32:57Z

Excellent, thanks @alexshoe! The updated code and the new behavior in the codepen both look good to me now.

…on-cartesian shapes

alexshoe · 2026-03-06T16:26:33Z

@camdecoster and @emilykl, whenever you get a free moment, would you mind taking a look at this PR? Thank you so much!

emilykl · 2026-03-10T16:08:20Z

@alexcjohnson It occurs to me that perhaps these properties (hoveranywhere and clickanywhere) should be part of config rather than layout -- do you have thoughts on which location is more appropriate?

emilykl · 2026-03-10T16:14:59Z

src/components/fx/hover.js

                y1: y1 + gTop
            };

+            eventData.xPixel = (_x0 + _x1) / 2;


@alexshoe what's the purpose of these lines?

emilykl · 2026-03-10T16:20:34Z

src/components/fx/hover.js

        }
    }

+    // Save coordinate values so clickanywhere can be used without hoveranywhere


Should we only do this step if clickanywhere is enabled? Does it matter?

emilykl · 2026-03-10T16:31:21Z

src/components/fx/hover.js

+        if (fullLayout.hoveranywhere && !noHoverEvent && eventTarget) {
+            gd.emit('plotly_hover', {
+                event: evt,
+                points: [],
+                xaxes: xaArray,
+                yaxes: yaArray,
+                xvals: xvalArray,
+                yvals: yvalArray
+            });
+        }


It would be more maintanable to have this gd.emit('plotly_hover', ...) (for the hoveranywhere case) closer to the gd.emit('plotly_hover', ...) for the normal case (which I believe is on line 950-957). To ensure that the same keys are included in both objects, etc.

I realize we do want to keep the early return on line 801.

Maybe you could add a emitHover() function akin to emitClick(), and then call it in both cases (both here and on line 950).

emilykl · 2026-03-10T16:52:12Z

src/components/fx/hover.js

+    if (!eventTarget || noHoverEvent || (!_hoverChanged && !fullLayout.hoveranywhere)) return;

-    if (oldhoverdata) {
+    if (oldhoverdata && _hoverChanged) {


Does this mean that when hoveranywhere is enabled, we emit plotly_unhover any time the hover data changes? That doesn't seem like the right behavior to me. Let me know if I'm misunderstanding.

emilykl · 2026-03-10T16:59:31Z

@alexshoe Can you document somewhere what xPixel and yPixel mean? I assume they're the pixel position of the hover/click, but relative to what? The upper left corner of the plot div?

emilykl · 2026-03-10T17:19:33Z

test/jasmine/tests/hover_click_anywhere_test.js

+            expect(hoverData).toBeDefined();
+            expect(hoverData.points).toEqual([]);
+            expect(hoverData.xvals.length).toBe(1);
+            expect(hoverData.yvals.length).toBe(1);
+            expect(typeof hoverData.xvals[0]).toBe('number');


Should verify exact values of all hoverData keys here, for thoroughness. No reason not to. Same goes for all of these tests.

emilykl · 2026-03-10T17:20:17Z

test/jasmine/tests/hover_click_anywhere_test.js

+    beforeEach(function() { gd = createGraphDiv(); });
+    afterEach(destroyGraphDiv);
+
+    function _hover(xPixel, yPixel) {


Do we not have a _hover() utility function elsewhere in the tests we can use here?

emilykl · 2026-03-10T17:21:45Z

test/jasmine/tests/hover_click_anywhere_test.js

+        .then(done, done.fail);
+    });
+
+    it('does not fire on empty space by default', function(done) {


Suggested change

it('does not fire on empty space by default', function(done) {

it('does not emit plotly_click event on empty space when clickanywhere is false', function(done) {

emilykl · 2026-03-10T17:22:44Z

test/jasmine/tests/hover_click_anywhere_test.js

+        .then(done, done.fail);
+    });
+
+    it('does not fire on empty space by default', function(done) {


Suggested change

it('does not fire on empty space by default', function(done) {

it('does not emit plotly_hover event on empty space when hoveranywhere is false', function(done) {

alexcjohnson · 2026-03-10T17:23:40Z

@alexcjohnson It occurs to me that perhaps these properties (hoveranywhere and clickanywhere) should be part of config rather than layout -- do you have thoughts on which location is more appropriate?

Oh that's a good point - the original concept of config vs layout is anything that's not portable, ie it depends on the context in which you're displaying the plot, belongs in config. And these clearly aren't portable, because they depend on event handlers being attached to the plot. I'm not sure if this distinction is meaningful or intuitive to users (or as important as it what many years ago when we created it and Chart Studio, with its sharing and separate view, edit, and embed views, was the main consumer of these plots), and we've broken that convention with good reason when the context-dependent attribute is scoped to a particular component like one shape, subplot, or trace - certainly don't want to implement a parallel object structure just for config!

All that to say I don't feel strongly about it, but if you think these would be easier to find in config I can get on board.

emilykl · 2026-03-10T17:24:11Z

test/jasmine/tests/hover_click_anywhere_test.js

+            gd.on('plotly_click', function(d) { clickData = d; });
+
+            var s = gd._fullLayout._size;
+            click(s.l + 250, s.t + 50);


Isn't this clicking outside the plot div?

emilykl · 2026-03-10T17:34:20Z

@alexshoe I've finished my first pass review! All looks good, left some fairly minor comments.

Ideally this feature should add (almost) zero additional overhead when hoveranywhere and clickanywhere are false. Do you know whether that's the case? I'd have to do another pass through to confirm but maybe you've thought about this already.

alexshoe added 4 commits February 11, 2026 19:34

Add hoveranywhere and clickanywhere attributes to emit hover/click ev…

5ab032d

…ents in empty plot space

Add jasmine tests for hoveranywhere and clickanywherer

8d4562a

Update schema

a92246d

Merge remote-tracking branch 'origin/master' into hover-click-events-…

1eb8d6e

…anywhere

alexshoe requested a review from emilykl February 13, 2026 18:20

alexshoe linked an issue Feb 13, 2026 that may be closed by this pull request

[FEATURE]: Enable click and hover events anywhere #7699

Open

alexshoe marked this pull request as ready for review February 13, 2026 18:20

alexshoe requested a review from alexcjohnson February 16, 2026 17:05

camdecoster assigned emilykl Feb 18, 2026

alexshoe added 2 commits February 18, 2026 15:06

Merge remote-tracking branch 'origin/master' into hover-click-events-…

fb4ccbe

…anywhere

Merge remote-tracking branch 'origin/master' into hover-click-events-…

a981ca5

…anywhere

Expose pixel coordinates of hover event data and fire hover events ev…

2ba5ddb

…en if near trace

alexshoe added 2 commits February 26, 2026 14:59

Merge remote-tracking branch 'origin/master' into hover-click-events-…

19ac09c

…anywhere

Add new attributes to map test

5ba0f25

alexshoe requested a review from camdecoster February 27, 2026 17:24

alexshoe added 5 commits February 27, 2026 13:40

Add xPixel and yPixel to tests

78305ac

AddxPixel and yPixel to more tests

7868ae9

Add xPixel and yPixel to remaining tests

dae94d4

Remove xPixel and yPixel from funnelarea and pie tests, as they are n…

7dfecf6

…on-cartesian shapes

Update map_custom-style baseline

e93310f

This comment was marked as spam.

Sign in to view

emilykl reviewed Mar 10, 2026

View reviewed changes

src/components/fx/hover.js

y1: y1 + gTop

};

eventData.xPixel = (_x0 + _x1) / 2;

Copy link

Contributor

emilykl Mar 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexshoe what's the purpose of these lines?

emilykl reviewed Mar 10, 2026

View reviewed changes

	it('does not fire on empty space by default', function(done) {
	it('does not emit plotly_click event on empty space when clickanywhere is false', function(done) {

	it('does not fire on empty space by default', function(done) {
	it('does not emit plotly_hover event on empty space when hoveranywhere is false', function(done) {

Uh oh!

Conversation

alexshoe commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description:

New API:

Uh oh!

alexcjohnson commented Feb 24, 2026

Uh oh!

alexshoe commented Feb 24, 2026

Uh oh!

alexcjohnson commented Feb 26, 2026

Uh oh!

alexshoe commented Feb 26, 2026

Uh oh!

alexcjohnson commented Feb 27, 2026

Uh oh!

This comment was marked as spam.

Uh oh!

alexshoe commented Mar 6, 2026

Uh oh!

emilykl commented Mar 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emilykl commented Mar 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcjohnson commented Mar 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emilykl commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

alexshoe commented Feb 12, 2026 •

edited

Loading