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
In order to optionally report the full hash back to Google, we need to keep it
around in the callback. While a prefix is not the same as a full hash (multiple
full hashes can map to the same prefix), in this case, the callback will only be
called when the full hash matches.
MozReview-Commit-ID: F4WSLZpYrXB
--HG--
extra : rebase_source : da3b16b00729d0aa6ff1765a135b751fcf44c012
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
For netwerk/cache2/CacheFileInputStream.cpp:148 and netwerk/protocol/http/nsHttpHeaderArray.cpp:358,
missing "()" in the if statement.
For netwerk/base/rust-url-capi/test/test.cpp:29, netwerk/streamconv/converters/nsHTTPCompressConv.cpp:297,
and netwerk/streamconv/converters/nsHTTPCompressConv.cpp:300, null pointer will be returned but the
original memory buffer will not be freed if |realloc| fails. We should remember the original memory
buffer and free it if error is detected.
MozReview-Commit-ID: 2ggXsL73jYV
--HG--
extra : rebase_source : e47e41f2b37f717207bd13990efead22a14db1c0
* 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 : 646c1c82d141cadc6c1b19843b4cc750e1a1ce59
This new COOKIE_SCHEME_HTTPS telemetry probe reports the same information as the COOKIE_SCHEME_SECURITY probe, but also categories cookies by whether they are set from an HTTP or HTTPS origin.
MozReview-Commit-ID: IWg8dycCzwq
--HG--
extra : source : 94708be3f00796680377b3235b78f7db70c34510
extra : intermediate-source : eaf32e92b13d54a8e8d70a7b8caf420800641d49
"Nonsecure HTTP" here just means regular, not-HTTPS HTTP. It doesn't mean HTTPS without the `Secure` cookie flag. Honor the expiration time of third-party cookies set over HTTPS, whether or not they have the `Secure` cookie flag. If a third-party cookie is set over HTTPS and then later sent in nonsecure HTTP request (which is allowed for cookies without the `Secure` cookie flag), the cookie won't be turned into a session cookie unless the nonsecure HTTP response sets a new cookie value.
This feature is controlled by the pref "network.cookie.thirdparty.nonsecureSessionOnly".
MozReview-Commit-ID: HlCg21JyvNC
--HG--
rename : extensions/cookie/test/unit/test_cookies_thirdparty_session.js => extensions/cookie/test/unit/test_cookies_thirdparty_nonsecure_session.js
extra : source : d1be2e4265201efd3ee93e965ac68561f548fd05
extra : intermediate-source : f5b382fa1b70e30a907b1f10d74f8c0c6dff344e
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: L9UE3gXHG4Q
--HG--
extra : source : 37d74bf745b23542251cc6b021d6aabb5ffadea1
extra : intermediate-source : 0402b4bd34c293b44c76de22418899420c8e405b
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: H9I6vNDMdIr
--HG--
extra : rebase_source : cf537a1f65af003c6c4f8919b925b0f305c1dd4d
extra : source : 13b89ce4e6a66c840f82a335c71f5a12938aba22
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: DbTW5Bhd9E1
--HG--
extra : rebase_source : b27f666e5ca832d814fb6846208474e1ec66e5f4
extra : source : 9ff4e11402a9a43ed90298a9c354b0164cf9414f
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: F750v6NN81s
--HG--
extra : rebase_source : 714dd78df0f4c33e23e5b117615bd8fd561674c5
extra : source : 742bda9e6b1ddaf34d09894204ad18ce798b79b7
OnStartRequest callback chain is interrupted by add-on during the "http-on-modify-request" observer event.
Therefore, nsInputStreamPump think OnStartRequest is finished. After resuming http channel, nsHttpChannel
asynchronously continue the OnStartRequest procedure and synchronously resume the nsInputStreamPump. Before
nsDocumentOpenInfo invoke the next OnStartRequest on the listener chain, sync XHR in web content is executed
on the call stack. This will spin main thread event queue and will eventually callback OnDataAvailable/OnStopRequest
on the same call stack.
nsHttpChannel should not resume the nsInputStreamPump before |mCallOnResume| is complete, to ensure that
no input stream event can interrupt the resumed call stack before it finished.
MozReview-Commit-ID: 6Q9EtMhcff9
--HG--
extra : rebase_source : 5685bacd9fbc95207a2a1349a8db66d53e3cc524
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
Race only when we're going to read from the disk cache storage. Also skip racing if we're going to write to the offline cache, because we need the cache entry which would be ignored if network wins the race.
