Reusing the same op object for each iteration can result in very weird
behaviors because previously yielded op objects will get a surprise
mutation.
It is unclear why the code was written to reuse the same object. There
was no comment, nor is there a commit message providing rationale (it
has behaved this way since the very first commit). Perhaps the objects
were reused to improve performance (fewer object allocations that need
to be garbage collected). I do expect this change to reduce
performance somewhat, but not enough to warrant reverting this commit.
Safari takes a while to initialize `document.styleSheets`, which
results in a race condition when loading the pad. Avoid the race
condition by accessing the CSSStyleSheet objects directly from the
HTMLStyleElement DOM objects.
This change makes no visual difference right now, but will matter (for
reasons I don't understand) once we change `ace.js` to build the
iframes by constructing elements in JavaScript (vs. writing HTML).
* Add the class "pad" to the `<html>` tag in `pad.html` (the outer
iframe's parent).
* Change the CSS selector that refers to the `<html>` tag in
`pad.html` from `html:not(.inner-editor)` to `html.pad`.
* Change the class name of the outer iframe's `<html>` tag from
"inner-editor" to "outer-editor".
* Update CSS rules to use the new class name.
This reverts commit a17f9bf3cf, which
caused a mysterious bug with the line numbers. Revert to avoid
blocking a new release while I figure out the bug.
There are two main benefits:
* HTML is no longer printed in the startup debug logs.
* `require()` is no longer called on client-side files. This
eliminates "Failed to load <file> for <plugin>: ReferenceError:
window is not defined" errors when users visit
`/admin/plugins/info`.
The intention of the deleted code was to reduce the number of fetches,
but it only saved a single fetch due to implementation flaws. The
right way to reduce the number of fetches is to use a bundling
technology such as webpack, and this change makes it easier to do so.
This isn't strictly necessary right now, but will become
necessary (due to a Safari quirk) when we change to building the
iframes programmatically (vs. the current `document.write()`
approach).
