I can see that this problem existed before with _startBookmark/_endBookmark, but _marker can be undefined or null, so that should be checked here to prevent a NPE.

I don't think it can ever be null - cm.markText() always returns a TextMarker instance, and we initialize it in the constructor and only .clear() it on close, so when could this ever be null?
Of course, this._marker.find() can be null.

I just tested this - as long as the InlineColorEditor is open, this._marker is always an instance of TextMarker.

Yes, I'm certain that this._marker will never be null in the current code. But the constructor does not enforce that a valid marker is passed in and you can see some unit tests where creating new InlineColorEditor() does not pass any parameters (i.e. marker is undefined). This is just to be safe for any future usage.

Ah yeah, now that makes sense. Changed.

@marcelgerber Would you be interested in making a similar cleanup to the easing function editor at some point? Bonus points for finding a way to share some bookmark-management code between the two :-)

I did that and found that there's a lot of shared code in getCurrentRange - where to put shared utility functions for Inline Editor Extensions?