Tooltip returns error after "removing" it

[FeNoMeNa]

Before opening an issue, make sure to read the contributing guide and understand this is a bug tracker, not a support platform.

Please make sure to check the following boxes before submitting an issue.
Issues opened without using this template will be closed unless they have a good reason not to follow this template.

• All peer dependencies are installed: React, ReactDOM and Leaflet.
• Using a supported version of React and ReactDOM (v15.x or v16.x).
• Using the supported version of Leaflet (v1.2.x) and its corresponding CSS file is loaded.
• Using the latest stable version of React-Leaflet.
• The issue has not already been reported.
• Make sure you have followed the quick start guide for Leaflet.
• Make sure you have fully read the documentation and that you understand the technical considerations.

Expected behavior

The leaflet tooltip should be closed successfully after component unmounting (e.g. when someone change the app route, /map --> /settings).

Actual behavior

After component unmount I'm getting the following error

warning.js:33 Warning: unmountComponentAtNode(): The node you're attempting to unmount was rendered by React and is not a top-level container. Instead, have the parent component update its state and rerender in order to remove this component.

warning.js:33 Warning: unmountComponentAtNode(): The node you're attempting to unmount was rendered by React and is not a top-level container. Instead, have the parent component update its state and rerender in order to remove this component.

leaflet-src.js:6374 Uncaught TypeError: Cannot read property '_targets' of null
    at NewClass.removeInteractiveTarget (leaflet-src.js:6374)
    at NewClass.closeTooltip (leaflet-src.js:10122)
    at NewClass.unbindTooltip (leaflet-src.js:10045)
    at Tooltip.componentWillUnmount (Tooltip.js:95)
    at callComponentWillUnmountWithTimer (react-dom.development.js:8760)
    at HTMLUnknownElement.callCallback (react-dom.development.js:540)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:579)
    at invokeGuardedCallback (react-dom.development.js:436)
    at safelyCallComponentWillUnmount (react-dom.development.js:8767)
    at commitUnmount (react-dom.development.js:8893)

Steps to reproduce

Render marker with tooltip children

    <Marker position={...}>
      <Tooltip permanent interactive direction='right' offset={[10, 15]} className={className}>
        <span>title</span>
      </Tooltip>
    </Marker>

Environment:

• linux / osx
• react 16
• leaflet - 1.2.0
• react-leaflet 1.7.4

[FeNoMeNa]

This bug is related with permanent and interactive behavior of the tooltip.

[tedcurrent]

Tested this and seems to be an issue with interactive only.

[PaulLeCam]

Thanks for the details, it should be fixed in v1.7.5, please try it out!

[FeNoMeNa]

Thanks for the fix! Now interactive works correctly, but when I set permanent then the component prints the following error on unmount

Warning: unmountComponentAtNode(): The node you're attempting to unmount was rendered by React and is not a top-level container. Instead, have the parent component update its state and rerender in order to remove this component.

[FeNoMeNa]

I'm sorry, the bug is related with the marker cluster component (internal implementation). The issue can be closed, thanks!

[tedcurrent]

Thanks @PaulLeCam it works now! :)

[FeNoMeNa]

@PaulLeCam,

there is an issue when some external resource fire tooltipopen or tooltipclose events. Actually these events are fired from onAdd / onRemove methods in Leaflet/Tooltip.js. When the onTooltipClose callback in the Tooltip component is invoked we are getting this error:

Warning: unmountComponentAtNode(): The node you're attempting to unmount was rendered by React and is not a top-level container. Instead, have the parent component update its state and rerender in order to remove this component.

React 16 related issue.

[PaulLeCam]

Please open a separate issue with a minimum way to reproduce in WebpackBin or similar if it is breaking anything but I don't think this warning is any issue, it's likely just a side-effect of the way it's implemented.