Bugzilla

So, why is mSelCon null?  Well, the mousemove event triggers an event-handler in the testcase, which does:
```
 this.setAttribute('type','text')
```
As part of that setAttribute call, we call `HTMLInputElement::HandleTypeChange()`, which calls `mInputData.mState->SyncUpSelectionPropertiesBeforeDestruction()`, which calls `UnbindFromFrame()`, which sets `mSelCon = nullptr` here:
https://searchfox.org/mozilla-central/rev/2a355e56c490768be676689de18629485c9d699b/dom/html/nsTextEditorState.cpp#2015

Then we continue servicing the same mousemove event (looping in `EventTargetChainItem::HandleEventTargetChain`) and we trip over this newly-null pointer as shown in the backtrace here.

Trivial solution: maybe `HandleDrag` should just add a null check for `frameselection` and bail gracefully?  Or, is there something more sophisticated that we need to do for correctness?

So, why is mSelCon null?  Well, the mousemove event triggers an event-handler in the testcase, which does:
```
 this.setAttribute('type','text')
```
As part of that setAttribute call, we call `HTMLInputElement::HandleTypeChange()`, which calls `mInputData.mState->SyncUpSelectionPropertiesBeforeDestruction()`, which calls `UnbindFromFrame()`, which sets `mSelCon = nullptr` here:
https://searchfox.org/mozilla-central/rev/2a355e56c490768be676689de18629485c9d699b/dom/html/nsTextEditorState.cpp#2015

Then we continue servicing the same mousemove event (looping in `EventTargetChainItem::HandleEventTargetChain`) and we trip over this newly-null pointer as shown in the backtrace here, via the callstack described in comment 4.

Trivial solution: maybe `HandleDrag` should just add a null check for `frameselection` and bail gracefully?  Or, is there something more sophisticated that we need to do for correctness?