I tried to keep the changes to existing tests as minimal as
possible. There were a few exceptions, though:
* test_update_ignorecompat.js was completely broken. I couldn't
figure out why it was suddenly failing after I changed it to use
`add_test`, and it turned out that it had been failing all along,
but in a way that the harness didn't pick up.
* I changed most of the `do_throw` in update callbacks to `ok(false`
because it took me about an hour to figure out where the test was
failing when I hit one of them.
* I made some changes to sync `test_update.js` and `test_update_ignorecompat.js`
where one appeared to have been changed without updating the
other.
* I made `promiseFindAddonUpdates` a bit more generic, because I was
planning to convert most of `test_update.js` to use it, rather
than nested callbacks. I changed my mind a quarter of the way
through, but decided to keep the changes, since they'll probably
be useful elsewhere.
Looking at a preference file read with strace typically looks like:
open("...", O_RDONLY) = X
...
read(X, "...", SIZE) = SIZE
read(X, "...", SIZE) = 0
...
There's no reason to call Read() and make another syscall to determine
there's no data left for reading. We can keep track of how much we've
read at minimal cost and thus determine for ourselves when we are done.
Calling nsIInputStream::Available on nsIFileInputStreams is relatively
expensive, as it requires three system calls: one to determine the
current file position, one to seek to the end file position, and one to
rewind to the previous file position.
We can do better by asking the file for its size directly, prior to
opening the stream. This only requires one system call, stat, and is
thus superior--at least in considering the number of system calls.
In particular, we want to prevent requesting a snap in the scenario that a wheel
block gets prevent-defaulted. In general the function is really only relevant
for touch input and there's no need to run it for other types of input.
When a make target is generated with FileAvoidWrite, this can cause targets to
get rebuilt perpetually when a prerequisite is updated, because FileAvoidWrite
will leave the target's mtime older than the prerequisite's when the target's
contents are unchanged. To avoid this issue, GENERATED_FILES is modified to
unconditionally update its target's mtime.
Bug 118468 landed an option for FileAvoidWrite to always write to an output
file, whether or not the contents would be changed. This was to address a
problem caused by not updating mtimes when building GENERATED_FILES, but
undoes the purpose of FileAvoidWrite and isn't really necessary.
This is addressed in a subsequent commit by unconditionally updating
mtimes when processing GENERATED_FILES.
GENERATED_FILES and accessible/xpcom/Makefile.in add to EXTRA_MDDEPEND_FILES, but for
targets that run during export. Export doesn't include EXTRA_MDDEPEND_FILES, so none
of them is ending up with correct dependencies. The EXTRA_EXPORT_MDDEPEND_FILES variable
could be used for this purpose, but given the circumstances this variable is removed,
and EXTRA_MDDEPEND_FILES is instead included unconditionally.
