This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
* A memory leak occurs when this happens in the content process
* I added an assertion that we only create it in the parent process
MozReview-Commit-ID: 1UTyusRg0qx
--HG--
extra : rebase_source : 400cfb21ee094ad33e15681f213af6dbe20ebbf5
Conceivably, we could allow a few more prefetches than this would (based
on the headers in the original request matching up to a header listed in
the Vary response header), but this is safer in case (for example)
future requests of this resource end up sending a cookie that wasn't set
on the original request. In practice, the difference is likely to be
small enough that this broader stroke won't make a huge impact on the
number of things we do or don't prefetch.
MozReview-Commit-ID: GhD9mZR6aOX
--HG--
extra : rebase_source : 13a2edb99485c73db902d2ec8b0f2b5b1d437abe
After data delivery for a request has been retargeted, there's no reliable way
to get the appropriate event target to re-dispatch data events after
asynchronous processing.
While it's technically possible to retrieve the current thread from
OnDataAvailable callbacks and re-use that for later dispatch, that approach
has some issues:
1) It's not currently possible to reliably map the current thread to the
thread pool that owns it. That means that if data delivery is being targetted
to a thread pool, attempts to redispatch events to the previous delivery
thread might lead to long delays when one thread in a pool is blocked.
2) If a filter wishes to dispatch data events to the wrapped listeners before
it's recieved any data (as extensions StreamFilters sometimes do), there's no
way to determine the proper event target without waiting for initial data to
be received.
Simply returning the correct event target from the request solves both of
these problems.
MozReview-Commit-ID: CJxq7O4399R
--HG--
extra : rebase_source : db2f659ecad16daafdbcc108d7b1a51ea1af31f9
nsHttpHandler is designed only for `getService` but we do not protect against `createInstance`.
The singleton of nsHttpHandler will be replaced by new instance created via `createInstance`.
gHttpHandler will hold a dangling pointer after the new instance is destroyed.
MozReview-Commit-ID: DQV6pmb5BUK
--HG--
extra : rebase_source : a6ab90038853e057c632efb5206cc26dcd71b897
This test turns the existing stand alone test for the FTP directory
listing parser into a gtest.
MozReview-Commit-ID: 7n60TfcTXTJ
--HG--
extra : rebase_source : 79c88708a9bf9bee6c27a82f2c93a95016e063dd
If the year is omitted from a listing, then the parsing code assumes
that the date occurred within the last year. To compute what the year
should be, the code thus needs to know what the current year, month
and day are. This patch parameterizes ParseFTPList over a function
that returns a PRTime. This will allow the gtest to pass in a fixed
time. Firefox itself will continue to use PR_Now to get the current
time.
MozReview-Commit-ID: 8IbVWbUBHYs
--HG--
extra : rebase_source : 41cc70a044bc19cb8556677cd3502bab3d6c95a4
In a few places, the FTP parser needs to know the time zone and
daylight savings time correction, encapsulated in
PRTimeParamFn. Before this patch, it would use the time zone of the
current machine, which would obviously make automated testing
difficult. This patch allows a caller to pass in a PRTimeParamFn,
which will allow the gtest to use GMT instead of whatever the local
time is.
MozReview-Commit-ID: 81R3Zbndr43
--HG--
extra : rebase_source : 274c3724259bc2f03f6a9b529ec005421c7c3ae2
After the automatic fixes in the previous patch, a few of the times in
late March and early April are still off by an hour. Maybe this was
affected by the changes in when daylight savings time or some bug in
my conversion script. I have no idea. This patch just fixes the test
to match the actual output.
MozReview-Commit-ID: IghWfkWfxvi
--HG--
extra : rebase_source : ef2e8c6c3d5fbe3d50443ac0042d139e5da44d64
The dates in the input for this file are specified as seconds since
Jan 1, 1970 or whenever. The conversion to a normal date depends on
the current time zone. The original output seems to have been
generated using GMT+1, with adjustments for daylight savings time at
the appropriate parts of the year. To make this easier to test, this
patch changes all of the times to GMT, without any daylight savings
time adjustment.
This change was automatically created by the Python script attached to
the bug.
MozReview-Commit-ID: 3uSAGtJYsMW
--HG--
extra : rebase_source : 2bdf3dd8f7d7b07320a19c4710ded75e4d0a86d1
D-WinNT: The parser treats <JUNCTION> without an arrow as junk for
some reason. Chrome's FTP directory listing parser doesn't seem to
support <JUNCTION> at all, so it can't be too important. I just
deleted that from the expected output to match Firefox's current
behavior. I also added basic tests for three bugs that were fixed
without any tests landed.
E-EPLF.out: Add a license to the top.
U-WinNT.out: We're not testing junk or comment output, and we don't
use the list: prefix, so remove all of those. Also, we now output the
proper year (2000 instead of 00, for instance), so fix that in the
test output. Finally, the time in the output for this test is
formatted differently, for whatever reason, so change it to match the
actual output.
V-VMS-mix.out: Fix file sizes. File sizes on VMS can only be
approximated. When the FTP tests initially landed in 2002, this was
handled by not trying. Bug 22299 landed in 2003 and changed our
behavior to approximate the size, but the tests were not
updated.
MozReview-Commit-ID: 1DVfBfHh82y
--HG--
extra : rebase_source : 623ac06cb62497b8fc3db01f73c18b3cf0df6783
strtoul returns an |unsigned long|, and clamps the return value to
ULONG_MAX if the input is out of range. This means that the value
returned for large numbers differs between 32-bit and 64-bit
systems. To make testing easier, this patch clamps the return value to
UINT32_MAX, ensuring that 32-bit and 64-bit builds of Firefox will be
consistent.
Explicitly declaring that the intermediate value numBlocks is a
uint64_t also avoids (well-defined) integer overflow in the case of a
large file.
This patch also changes PRId64 to PRIu64, because the value being
printed is unsigned. However, this should not make a difference in
practice, because, with clamping, the maximum value being printed is
|UINT32_MAX * 512|.
I also cleaned up the comment that was a little garbled and contained
information about both the old and new ways this was handled, and
removed some code that has been ifdef'd out for at least 14 years.
MozReview-Commit-ID: HELmWmtx24O
--HG--
extra : rebase_source : d7a9f5ab09fcb97d5f6319e5fa1fca1a4f72aa52
