This means the callsites don't need to use getter_Copies(). This roughly halves
the number of calls to getter_Copies() in the tree.
The patch also removes the bool return value from these functions, because it's
not used.
--HG--
extra : rebase_source : 9281411f959282b4ff33e18205ce647f963f0108
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
The tm_year field of PRExplodedTime is an absolute year, not years
since 1900, so fix a few places that try to do the latter.
I also made the conversion of 2 digit years more consistent.
MozReview-Commit-ID: GetS2wmXHhA
--HG--
extra : rebase_source : abdec76586add29b9741db5237bce77d976c8cdc
When a WyciwygChannel is canceled, but WyciwygChannelParent::RecvCancel happens
after WyciwygChannelParent::SendOnStartRequest, it would send statusCode=NS_OK
to WyciwygChannelChild::OnStartRequest. So we should not apply the statusCode
if mCanceled, just like how HttpChannelChild handles it.
MozReview-Commit-ID: 5H3PUrlArIA
--HG--
extra : rebase_source : 9e8b034d293dc50d126327dc6452e95335e35ae6
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Also adds the necessary methods to rust-url-capi and fixes a bug in rusturl_set_username
MozReview-Commit-ID: 9rsPIQAbWBJ
--HG--
extra : rebase_source : a1dee0b0e26a5c816f47a7c7c779c2454f87f51f
Also adds the necessary methods to rust-url-capi and fixes a bug in rusturl_set_username
MozReview-Commit-ID: 9rsPIQAbWBJ
--HG--
extra : rebase_source : 550aafbfb1d57257db49897a7506ebb9f038021f
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
When for some reason the target of a resource: substitution doesn't end
with a / (which can happen when e.g. building a FileURI with a path
that doesn't exist), relative path resolution of the resource URLs end
up rooted under the parent of the non-existing directory.
e.g
resource://foo/bar is substituted with /path/for/bar if
resource://foo/ is registered for file:///path/for/foo (instead of
file:///path/for/foo/)
--HG--
extra : rebase_source : b59dae0337a707a96adfc1c89c27235a856ec58e
When for some reason the target of a resource: substitution doesn't end
with a / (which can happen when e.g. building a FileURI with a path
that doesn't exist), relative path resolution of the resource URLs end
up rooted under the parent of the non-existing directory.
e.g
resource://foo/bar is substituted with /path/for/bar if
resource://foo/ is registered for file:///path/for/foo (instead of
file:///path/for/foo/)
--HG--
extra : rebase_source : 9907f7c54f43851ba1a956a5d278d301013204d2
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
When for some reason the target of a resource: substitution doesn't end
with a / (which can happen when e.g. building a FileURI with a path
that doesn't exist), relative path resolution of the resource URLs end
up rooted under the parent of the non-existing directory.
e.g
resource://foo/bar is substituted with /path/for/bar if
resource://foo/ is registered for file:///path/for/foo (instead of
file:///path/for/foo/)
--HG--
extra : rebase_source : 50a329318a2424bc5679a2e026e755271214224a
