Test fails when running locally:
./mach test netwerk/test/unit_ipc/test_original_sent_received_head_wrap.js
Error: cannot open file '/home/user/mozilla-central/obj-ff-dbg/_tests/xpcshell/netwerk/test/unit/test_original_sent_received_head.js' for reading at /home/icecold/mozilla-central/testing/xpcshell/head.js:648
MozReview-Commit-ID: DcOWOWlH5ch
--HG--
extra : rebase_source : 30c5e28c61adace06cd49ca216108a277e37d58d
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
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
In child process, during shutdown, it's possible that IsNeckoChild() is true but gNeckoChild is null. When this case happens, it is necessary to return early in RequestContext::BeginLoad to avoid modifying mAfterDOMContentLoaded.
Add calls to OnStartRequest() and OnStopRequest() to properly handle async
read failures for remote JAR's and remote unpacked extension resources.
MozReview-Commit-ID: Dcg0LDht9B9
--HG--
extra : rebase_source : fef29e1601c1a53d3b7ff3a9d96450b3ab8fe003
This patch enables support for setting prefs with the pattern
permissions.default.* to provide a custom default permission
for arbitrary permission types in nsPermissionManager.
The previous default of UNKNOWN_ACTION is honored if no pref is set.
A default value is provided if no permission entry can be found in the db.
Accordingly, the patch does not affect the behavior of functions
that return permission objects from the db such as GetPermissionObject,
which returns null if no entry was found.
MozReview-Commit-ID: 3JECI6kXqGf
--HG--
extra : rebase_source : 9fbcfc740a85c02cf4245956e69ae13c8f90b5ab
Tom Schuster
Jorg K
Sebastian Hengst
Liang-Heng Chen
Ben Kelly
Andrea Marchesini
Dragana Damjanovic
Phil Ringnalda
Nicholas Hurley
Valentin Gosu
Patrick McManus
Kris Maglione
Jesse Ruderman
Junior Hsu
Tom Ritter
Chris Manchester
Alex Gaynor
Gregory Szorc
Nika Layzell
Andrew McCreight
Sylvestre Ledru
Nicholas Nethercote
Jeff Hemphill
Masatoshi Kimura
Andi-Bogdan Postelnicu
Dragana Damjanovic dd.mozilla@gmail.com
Randell Jesup
Makoto Kato
Ryan VanderMeulen
Jonathan Kew
Shih-Chiang Chien
Ho-Pang Hsu
Samael Wang
Honza Bambas
David Keeler
Mike Hommey
Michal Novotny
Amy Chung
Wes Kocher
hanbinchang
Kershaw Chang
Chris Peterson
Haik Aftandilian
Johann Hofmann