These browsers have bugs that occasionally cause typed array comparisons
to pass when they should fail, or vice versa:
* for...in loops sometimes omit keys, such that two typed arrays with
different lengths appear to have the same set of keys.
* Typed arrays sometimes have mulitple undefined keys (which is to say that
the key itself is undefined). Two typed arrays with identical length and
contents can compare unequal because of the spurious undefined keys.)
Those problems could be avoided by comparing keys 0...length-1 rather than
the actual set of exposed keys, but that would be a pretty nasty breaking
change for anyone whose code tacks extra properties onto typed arrays. So
far these bugs haven't been seen in anything newer than FF 128. Since the
affected browsers are all past end of life, the most sensible thing is to
just stop testing against them.
The old style of merging all of a function's variable declarations into
a single statement made some sense back in the days of var, but there's
no reason to keep doing it now that we use const and let.
Safari 16 and 17 runners are no longer reliably available in CI. Saucelabs
still provides them, but session creation failures have been frequent for
weeks now. When this has happened in the past, it's been a prelude to
Saucelabs dropping the affected Safari versions altogether.
We could live with retrying ~30-50% of test runs in the hope that things
might improve, but it's probably better to just rip the band-aid off.
* Assert that the right inner stack traces are in the right places
* Drop the integration tests. All of the AggregateError-specific code
is in ExceptionFormatter, so the integration tests just duplicate
existing integration tests and the ExceptionFormatter specs.
To support top level await, jasmine-browser-runner needs to be able
to delay env execution until after spec files have initialized. The
old-fashioned event listener style makes that straightforward.
jsApiReporter was initially added as part of the pre-1.0 Ruby based browser
runner. It looks like it was designed to resolve a race condition betweeen
jasmine-core's startup in the browser and the Ruby runner's startup. Modern
runners handle that either by buffering messages in a custom reporter (e.g.
jasmine-browser-runner's BatchReporter) or by calling env.execute() after a
communication channel has been set up (e.g. the old Jasmine ruby gem). In
any other context, a custom reporter is easier to use than jsApiReporter
because it doesn't require polling.
Adding jsApiReporter to the env imposes small but measurable penalties in
time and space, both of which are proportional to the size of the test
suite.
Other than jasmine-py and Testdouble's jasmine-rails gem, neither of which
ever supported jasmine-core 4 or later, I can find scant evidence of
interest and no evidence of usage after about 2012.
This isn't comprehensive but it should be broad enough to ensure that most
people who would be affected by blocking monkey patching see a warning.
Covers the jasmine namespace as well as classes that are monkey patched by
zone.js.
Replacing globals (describe/it/etc) doesn't trigger a warning because they
belong to the user and are expected to be replaced.
