I guess bug 994190 accidentally removed this test from mochitest.ini.
MozReview-Commit-ID: FeqJY5V0GXH
--HG--
extra : rebase_source : f2c75f7b56e25c28a7863d1db101c1bbdf43a9a8
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
This patch makes it possible to collect code coverage for xpcshell tests using the linux64-jsdcov build. It also enables the use of a 'coverage' flag to disable tests when they are instrumented with the js debugger for code coverage. Lastly, it uses the 'coverage' flag to disable certain tests.
MozReview-Commit-ID: 97VFkJmlwQn
--HG--
extra : rebase_source : 26c841f5a68f927889c0903e701bfde4b7ca84ac
IndexedDB database operations are written such that they must execute
synchronously. For this reason, the add/put operation reads/writes its
Blobs to disk in a synchronous fashion. However, with the introduction
of SendStream-backed Blobs for large (>1 MiB) blobs whose contents are
streamed to the parent replacing nsStringInputStream-backed Blobs
(whose contents were sent up in a single IPC message that might exceed
the size limit and cause a crash), this has no longer been a safe
assumption. However, the problems weren't immediately obvious because
most pre-WASM Blobs are smaller than the 1MiB threshold and even when
they exceeded the size, their memory-backed contents could rapidly be
sent to the parent via IPC, making NS_BASE_STREAM_WOULD_BLOCK errors
rare/hard to reproduce. (rr and its enforced single-threading is a
good way to reproduce, however. Also, see the testing patch on the
bug that introduces artificial delays into SendStream.)
Included SpecialPowersObserver.jsm minor changes to "CreateFiles":
- appendRelativePath is used instead of appendPath because appendPath
only allows a single path component to be appended. In other words,
file creation is limited to files at the root of the profile
directory using appendPath, which is needlessly limiting.
- outStream is now closed even if no data is provided. This is
essential on windows where file deletion only occurs when all handles
are closed. Without this fix, "RemoveFiles" side-effect of deleting
the created files might not take effect until garbage collection runs
and collects the outStream.
IndexedDB database operations are written such that they must execute
synchronously. For this reason, the add/put operation reads/writes its
Blobs to disk in a synchronous fashion. However, with the introduction
of SendStream-backed Blobs for large (>1 MiB) blobs whose contents are
streamed to the parent replacing nsStringInputStream-backed Blobs
(whose contents were sent up in a single IPC message that might exceed
the size limit and cause a crash), this has no longer been a safe
assumption. However, the problems weren't immediately obvious because
most pre-WASM Blobs are smaller than the 1MiB threshold and even when
they exceeded the size, their memory-backed contents could rapidly be
sent to the parent via IPC, making NS_BASE_STREAM_WOULD_BLOCK errors
rare/hard to reproduce. (rr and its enforced single-threading is a
good way to reproduce, however. Also, see the testing patch on the
bug that introduces artificial delays into SendStream.)
Included SpecialPowersObserver.jsm minor changes to "CreateFiles":
- appendRelativePath is used instead of appendPath because appendPath
only allows a single path component to be appended. In other words,
file creation is limited to files at the root of the profile
directory using appendPath, which is needlessly limiting.
- outStream is now closed even if no data is provided. This is
essential on windows where file deletion only occurs when all handles
are closed. Without this fix, "RemoveFiles" side-effect of deleting
the created files might not take effect until garbage collection runs
and collects the outStream.