When translating a logical screen position (columns/rows) to a pixel
position, the editor now builds a temporary version of the line for the
given row. It then uses the DOM range API to insert an empty range
at the correct text node and offset for the given column and determines
the left position based on its clientRect.
Depending on the speed impact, we may want to optimize this by
recycling the existing line node if it exists on screen rather than
building a new one every time. We will still have to build one if the
line we're moving to isn't on screen yet. We could also increase the
chances of the line being on screen by autoscrolling to the vertical
position first, and *then* calculating the horizontal position. Lots
to explore here.
The event that triggers the package module to be activated is
now retriggered after the package module is initialized but without
any previously registered handlers. Instead only the handlers registered
by the package module will be triggered. The prior event handlers are then
restored after the event is retriggered.
This allows package modules to bind event handlers during initialization
that will be triggered by the same event that caused the package module
intialization to occur. This simplifies the common case of having the same
event cause a package module to initialize and attach.
Allowing root view to be focused was stealing focus away from the
editor whenever a click event made it to the root view. This unnecessary
switching of focus was interfering with the ability to drag tabs.
But if RootView can't be focused, focus ends up being returned to the
document body when there are no focusable elements. This would be fine,
except for the fact that we frequently bind global events on root view,
and so they aren't triggered when events are triggered on the body. We
could just bind all global events on the body, but this would require
us to always attach elements to the DOM during specs, which is a serious
performance killer in specs.
The workaround is in the keymap. When the keymap handles a key event
that was triggered on the body, it triggers the corresponding semantic
event on the root view anyway, so from the event perspective, it's as
if the root view actually had focus. The only place this might fall
down is if someone wants to capture raw key events. But that's the
keymap's job anyway, and we maybe add a hook on the keymap if such a
need ever arises.
- EditSessions destroy their Selections when they are destroyed
- Editors destroy their EditSessions when they are destroyed
- Editors unsubscribe from the document and window when they are
removed from the DOM.
- When an EditSession is destroyed via any code path, the Editor with
that EditSession removes it.
- Selections no longer trigger 'destroyed' events if their parent
EditSession has already been destroyed.
These are all really intertwined, so I'm doing them as one commit
since that was the only way to keep the specs green.
