Horizontal / vertical scrollbars render a 'corner' on the lower right
when they would otherwise overlap. I previously relied on drawing both
dummy scrollbars at their full width/height so the corner got rendered,
but that interfered with the display of the horizontal scrollbar in
certain circumstances because it was too wide to scroll. This commit
provides that behavior with an absolutely positioned div with the same
dimensions as the intersection of scrollbars when both are visible.
This entailed quite a few changes to dial in scrollbars. The scrollbars
are now adjusted in size to account for the width of the opposite
scrollbar. If the width or height are not explicitly constrained and we
are scrollable in the opposite direction that is constrained, we account
for the width of the opposite scrollbar in assigning a natural height
or width based on the content.
We set overflow to hidden in the opposite scroll direction only if we
can't actually scroll in that direction, causing the white square where
neither scrollbar overlaps to appear at the lower right corner.
The space-pen view is now a simple wrapper around the entire React
component to integrate it cleanly into our existing system. React
components can't adopt existing DOM nodes, otherwise I would just have
the react component take over the entire view instead of wrapping.
With Node.js baked in, there's no water-tight way to prevent users from
evaluating code at runtime, at least with CSP alone. This is because
node exposes a 'vm' module that allows scripts to be compiled. There's
also `module._compile`, etc.
I think a reasonable compromise is to protect users from eval'ing code
by accident. This commit adds an atom.allowUnsafeEval method which
re-enables eval in the dynamic scope of the given function.
I then use this to compile the keystroke grammar which saves us the
complexity of pre-compiling it during specs.
What do people think?
Ben Ogle