[pulsar-next] Getting the core specs passing

[savetheclocktower]

Another draft PR, but this time focusing on the core specs. Some annoying discrepancies between my local machine and CI!

[savetheclocktower]

For posterity, here are the main categories of things that needed to be addressed:

• The vast majority of legitimate, not-just-happening-in-a-testing-environment bugs were related to Chromium now reporting values for line-height that are arbitrary numbers, not integers (or increments of physical pixels). This is great in the sense that it's more precise, but not great in the number of headaches it creates for us — each of which is the product of a specific assumption that Atom made in line-height–related code that is now incorrect.

  The fixes for these had to be handled on a case-by-case basis; but they mainly involved manually adjusting some line-height, height, or scrollTop values to snap to a pixel grid using roundToPhysicalPixelBoundary, ceilToPhysicalPixelBoundary, or floorToPhysicalPixelBoundary, depending on the situation.

• On Linux — and only Linux, for some reason — headless tests ran into timeouts in certain places because (as far as I can tell) Etch's scheduler uses requestAnimationFrame, and requestAnimationFrame is famously designed to fire much less often than the standard “once per 16.666ms” if it thinks that the web page is in the background somehow. I could trace some test failures to the fact that TextEditorComponent::getNextUpdatePromise() was taking almost exactly one second to resolve every time through.

  Amazingly, I was able to fix this by overriding the default scheduler for certain tests so that it used the more primitive (but much more predictable and consistent) setTimeout with a timeout of 0.

• Specs all over the app have had to be updated to work better with my total rewrite of pathwatcher. There's still a pain point when we run any spec suite that involves subscribing to, and unsubscribing from, the same file over and over again. I haven't tracked it down yet, but I suspect there's some sort of strange whiplash effect from when we ask pathwatcher to do this too often.

  It can be worked around in specs — usually by making afterEach async, then having it do something as simple as wait(50) in between tests — but I might try to fix this in pathwatcher itself by doing a two-phase unsubscribe: after initial unsubscribe, we just stop reporting the events to the consumer, but the actual native watcher wouldn't get unsubscribed for another second or two just in case we need to resubscribe in a minute.

• There's a nightmare scenario of a bug in TextEditorComponent::screenPositionForPixelPosition. That method has a happy path in which the pixel position is visible on screen and we can just call document.caretRangeFromPoint; and a sad path where we pick a line in the editor, then grab all the text nodes and basically bisect our way toward the correct screen position.

  Weirdly, in a couple of scenarios that are somehow triggered by the drag-to-select-text specs, the happy path is being used — but is producing incorrect results! I was able to fix this by making the happy path a bit more rigorous; I do a sanity check on the return value of caretRangeFromPoint just to ascertain that that range's getBoundingClientRect contains the point in question. If it doesn't, we fall back to the sad path, which is still better than a happy path that's wrong.

• To fix the TypeScript transpilation test, I wrote a new implementation of “simple” TypeScript transpilation, since the typescript-simple package we've been using hasn't been updated in seven years. It works well enough to pass the specs, but I do wonder if anyone uses it. I doubt it supports TSX out of the box and all the packages I've seen that are written in TypeScript just choose to transpile their own code. Still, it's in the spec suite, so it's my job to get it green.