Crash When Showing but No Active Hover: Cannot read properties of null (reading 'data')

[speedplane]

I came across a crash while hovering over a number of items that have powertips. This is some sort of open/close race condition, because it doesn't happen often, although I can reproduce it somewhat easily.

The error message is: Cannot read properties of null (reading 'data')

• Update: Link to video of crash here

The image below illustrates the moment of the crash, the tip is open, but there is no active hover. Can it simply be fixed by changing:

				if (!session.isClosing) {
					hideTip(session.activeHover);
				}

to

				if (!session.isClosing && session.activeHover) {
					hideTip(session.activeHover);
				}

Using version 1.3.2

Callstack

hideTip (jquery.powertip.js:1021)
showTip (jquery.powertip.js:912)
queueTipInit (jquery.powertip.js:886)
dequeue (jquery.js)
r.complete (jquery.js)
l (jquery.js)
add (jquery.js)
Kn (jquery.js)
o (jquery.js)
dequeue (jquery.js)
o (jquery.js)
queueTipInit (jquery.powertip.js:887)
dequeue (jquery.js)
o (jquery.js)
queueTipInit (jquery.powertip.js:887)
dequeue (jquery.js)
r.complete (jquery.js)
l (jquery.js)
fireWith (jquery.js)
a (jquery.js)
v.fx.tick (jquery.js)
setInterval (async)
v.fx.timer (jquery.js)
Kn (jquery.js)
o (jquery.js)
dequeue (jquery.js)
o (jquery.js)
queueTipInit (jquery.powertip.js:887)
dequeue (jquery.js)
(anonymous) (jquery.js)
each (jquery.js)
each (jquery.js)
queue (jquery.js)
beginShowTip (jquery.powertip.js:885)
openTooltip (jquery.powertip.js:505)
apiShowTip (jquery.powertip.js:251)
show_docket_tip (user_code)

[stevenbenner]

Thanks for reporting the issue. Your suggested change seems like a good sanity check, but I'm hesitant to make such a change without first understanding the root cause.

A situation where PowerTip believes that a tooltip is open but doesn't know of any element that triggered it could cause other problems. Adding a sanity check like this could mask a more fundamental bug and make it harder to find the root cause in the future if someone runs into a different side-effect of the same root problem. So my goal would be to prevent it from getting in this unexpected state in the first place.

A couple requests:

• Can you provide steps for me to reproduce the issue (including setup code)?
• And/or provide a simple test page for me to reproduce the problem?

I'm interested in seeing the code used so I can better understand the paths that are being followed and how state is being changed along the way.

It would also help me debug if you could answer these questions:

1. How many elements with tooltips are there on the page?
2. Does there seem to be a minimum number of elements tooltips to make this happen?
3. You said "hovering over a number of items that have powertips", do you mean that there are multiple elements that are nested?
   (e.g. <div title="tip1">some text <span title="tip2">more text</span></div>)
4. Are you using the mouse cursor or keyboard cursor when this happens?
5. Does this happen when you move the cursor slowly from one tooltip to another or does it need to be fast?
6. Do you ever manually call the PowerTip hide method on the page?
7. Do you ever call the PowerTip destroy method on the page?
8. Do you ever remove DOM elements that have or previously had tooltips assigned to them?
9. Do you use any custom PowerTip events?
10. Do you use any custom PowerTip integration (i.e. manual: true)?
11. Does this happen in both Chrome and Firefox?

[speedplane]

Hi, Steven, it took some time to get back to this.

Video summary

I created a 2:00 video that should hopefully answer these questions and more: https://www.youtube.com/watch?v=gTexPznr8KY

Link to the page in question: https://www.docketalarm.com/cases/Michigan_Eastern_District_Court/1--20-cv-13025/B%26P_Littleford_LLC_v._Prescott_Machine_LLC_et_al/

Answers to your questions.

1. How many elements with tooltips are there on the page? - Many
2. Does there seem to be a minimum number of elements tooltips to make this happen? Not sure.
3. You said "hovering over a number of items that have powertips", do you mean that there are multiple elements that are nested? No ... no nested powertips that I'm aware of.
4. Are you using the mouse cursor or keyboard cursor when this happens? Mouse cursor.
5. Does this happen when you move the cursor slowly from one tooltip to another or does it need to be fast? Generally happens quickly.
6. Do you ever manually call the PowerTip hide method on the page? Yes... is that bad?
7. Do you ever call the PowerTip destroy method on the page? Yes, but only when powertip crashes.
8. Do you ever remove DOM elements that have or previously had tooltips assigned to them? I don't think this is happening.
9. Do you use any custom PowerTip events? No.
10. Do you use any custom PowerTip integration (i.e. manual: true)? No.
11. Does this happen in both Chrome and Firefox? So far, only Chrome. I've tried and been unable to reproduce in Firefox.

Follow-Up

I realize that this issue may be a duplicate, of the much older #169

• Uncaught TypeError: Cannot read property 'data' of null #169 (comment)

[speedplane]

Hi Steven,

I have an easier way to reproduce:

1. View this page
2. Hover over link in the center of the page
3. See error

Unfortunately, the production page is minified and does not have debug info, so the callstack is unreadable, but it is the same as the callstack shown in the video with the debug info.

[speedplane]

Here is the patch I will be making, with this, the bug goes away (and you won't be able to reproduce at the link above):

[stevenbenner]

Thank you for the additional information. That was very helpful. Especially the example link and video. I really appreciate you putting in the effort to put all of that together for me. The critical piece of information was that tooltips are being hidden then immediately shown again in the same function (your set_docket_tip() function). I would not have considered that possibility without the link and video.

I believe that I have found the issue.

Test case

Please try out my reduced test case to see if this matches the issue that you had been seeing:

• gh-184_reduced_test.zip

Issue

It appears that the PowerTip state can be put in an unexpected state if the API hide() method is invoked with immediate set to true at exactly the right (wrong) time during the tooltip life cycle.

I am able to reproduce this issue by rapidly showing and hiding a tooltip multiple times in quick succession. The linked test case demonstrates the minimum action needed to trigger this issue.

Repro steps

1. (start with open tooltip)
2. Call API hide() method with immediate set to true
3. Call API show() method
4. Call API hide() method with immediate set to true
5. Call API show() method

Repro rate is 100% in this case. For both Firefox and Chromium.

This cannot be reproduced if immediate is not set to true in at least one case. If only one hide() call has immediate set to true then it is more difficult to reproduce, but can be done by rapidly clicking the button in the reduced test case.

Diagnosis

This is basically a race condition.

I was able to determine that it is possible for the fadeOutCallback() to be queued and executed immediately after TooltipController.showTip() completes. This can happen if the API hide() method is called in the very narrow window of time during the tooltip being queued for open, but before showTip() is triggered.

Flow

Step	Function	Description	activeHover
1.	n/a	(start with open tooltip)	set
2.	hideTip()	API asks to close open tip (dev plans to update content and reopen the tip). Queues up the fadeOut() with state reset.	set
3.	beginShowTip()	API immediate asks to open new tip, adds showTip() to the queue (for content update from step 2). Queues up showTip().	set
4.	hideTip()	Another call to close a tooltip is triggered (maybe unrelated API or user mouse moves away). Queues up another fadeOut() with state reset.	set
5.	beginShowTip()	Second request to open tooltip occurs (maybe unrelated API or user mouse moves to another element). Queues up another showTip().	set
6.	fadeOutCallback()	Queue moves forward from step 2. The fadeOut() is completed and state is reset.	null
7.	showTip()	Queue moves forward one tick from step 3. PowerTip begins opening a tooltip and sets session.activeHover and session.isTipOpen.	set
8.	fadeOutCallback()	Queue moves forward from step 7. The fadeOut() requested in step 4 is completed and state is reset.	null
9.	showTip()	Queue moves forward one tick from step 8, and runs the request from step 5. The showTip() method finds that a tooltip is open/opening (session.isTipOpen is true) from step 7 and tries to close it, calling hideTip().	null
10.	hideTip()	Error! The session.activeHover was cleared in step 8. PowerTip has been asked to close a tooltip when there are none open.	null

Remedy

I think that the bug here is that opening tooltips is part of jQuery's .queue() system, but hiding tooltips is not when immediate set to true on the API hide() method. This allows operations to become out of order if hide() is called while there are functions waiting in the queue.

A simple patch can make the hide() calls be handled by the queue. Though, this will need some refactoring of the destroy() API method to make it fully compatible.

diff --git a/src/tooltipcontroller.js b/src/tooltipcontroller.js
index 136c696..3ca1eec 100644
--- a/src/tooltipcontroller.js
+++ b/src/tooltipcontroller.js
@@ -171,12 +173,26 @@ function TooltipController(options) {
         });
     }
 
+    /**
+     * Queues up the hideTip function.
+     * @private
+     * @param {jQuery} element The element with the tooltip to hide.
+     */
+    function beginHideTip(element) {
+        // hide tooltip, asap
+        tipElement.queue(function queueTipHide(next) {
+            hideTip(element);
+            next();
+        });
+    }
+
     /**
      * Hides the tooltip.
      * @private
@@ -415,6 +432,6 @@ function TooltipController(options) {
 
     // expose methods
     this.showTip = beginShowTip;
-    this.hideTip = hideTip;
+    this.hideTip = beginHideTip;
     this.resetPosition = positionTipOnElement;
 }

I suspect that this patch would fix the issue that you've been seeing. Could you give it a try?

[speedplane]

Hi @stevenbenner,

Apologies on the long iteration times. I applied your patch, removed my null checks, and unfortunately, I still see the exception.

Screenshot of New Crash

Notes on Screenshot

• Again, this occurred when multiple powertips were opening/closing, somewhat intermittent
• Exception corresponds to the second null check I added in the screenshot above
• Note line 1273: It has your new patch
• I hovered over the session variable so you can see it's contents, but happy to provide additional info.

[speedplane]

Another video demo

Powertip Library - Demo of Crash - 2nd Iteration - 2023-05-11

• https://youtu.be/T2dKdnzSF3w

Notes:

• In the video, the procedure is to:
  • hover over a button that has a powerTip
  • press it
  • the resulting action of pressing the button causes a 2nd powertip to be triggered
  • There are other tips on the page, but I think these are the main 2.
• I applied your patch to the code in this video
• For reference, below is a screenshot of the changes in my checkout

[jendave]

Any possible update on this issue? I am seeing it as well.

[stevenbenner]

@jendave Can you try out the remedy patch that I included in the above comment to see if it has any effect? If it fixes your problem then please let me know and I'll try to polish it up and include it in the next release. If it doesn't fix your problem, then could I ask you to provide me with a test case that I can run in my browser to reliably reproduce the problem?

This issue stalled out because after a lot of investigation I only managed to find that one bug. But the person who reported this problem said that my patch did not resolve it. So they must be encountering a different bug that I have never been able to reproduce. And the bug that I did find, no one has ever encountered - or at least no one has opened an issue for it.

I don't mind taking another look at this either way. But I don't think that I can go any further debugging it without a test case with actual code that reproduces the problem, which I can breakpoint and step through. Videos and screenshots are immensely helpful, but with a hard-to-find race condition issue like this, all I can do without a repro is guess at potential problems and try to poke potential weak points in the program. But that is incredibly time consuming - with no guarantee of ever actually encountering the issue.

[jendave]

Thanks for the comment. I tried the patch from you and also the fix suggested by speedplane. Neither one worked for me. I'll see if I can create a test case but it may not be possible since I am encountering the issue using paid software. Specifically, I use FoundryVTT, a virtual tabletop program for games like Dungeons & Dragons that runs in a browser. I created a add-on that pops up information when you hover over icons on the board. If you move your mouse too quickly, the error occurs. Thanks again and I'll see what I can do.

[stevenbenner]

That seems to be the situation where this problem manifests. Lots of tooltips created on a page, -possibly with elements being added, hooked up, and destroyed during operation- and then forced to open/close many tooltips very rapidly. Unfortunately I have never been able to make this error happen with any test page that I have concocted. So I suspect that it must be a specific combination of options and DOM changes - but that is just an educated guess with nothing more than the info in this issue.

You could try making a super-simple HTML document that only has a dozen or so elements with tooltips. Then copy/pasting your PowerTip setup code -with identical options- and seeing if you could reproduce the issue. If it doesn't repro then it might be related how the DOM is changing while PowerTip is in operation. I don't know how FoundryVTT mutates the DOM while running, but if you could consider that and perhaps try to simulate the changes on the test page then you might get a repro.

I did take a quick look into FoundryVTT. Neat software. It seems to be a fairly complex web app combining DOM with canvas, with lots of DOM mutations while the player is interacting with it. I can't understand from demo exactly how the web app works - at least not enough to guess at lifecycle/mutation/structure. So I can't make any informed guesses for your specific case. And $50+tax is just a bit too much for me to shell out to try to reproduce a bug.

[jendave]

Thanks for looking into this further. I completely understand that buying FoundryVTT just to possibly debug the issue is not worth it. I am testing a workaround that gets me close. In my code, I was allowing the end-user more control over how fast the tooltip opens and closes. That apparently exacerbated the issue. I am testing a fix in my code that removes some of that customization. Now, it is much harder to reproduce the bug. If that works I'll probably leave it at that unless someone else files a bug for my project. Thanks for all of your help (and speedplane's) on this.

If you are curious to see how PowerTip is being used in the FoundryVTT realm, my project is Token Note Hover. I took inspiration from another project that also uses PowerTip called Pin Cushion.

Thanks again. I appreciate all of the help.