This patch reverts parts of changeset e87e706def11 (bug 1425031).
The problem in bug 1425031 was that when the content process set a cookie
a notification was sent to the parent process. This notification was then
forwarded to all the content processes, including the one it originated from.
The solution was to not forward cookies that originated from a content
process, but this causes the current bug.
The correct fix is to forward the cookie changes to all content processes
except the one they originated from.
The test for bug 1425031 remains, and should keep passing.
MozReview-Commit-ID: 1P6JwHQDy93
--HG--
extra : rebase_source : 85845c93059004836e14d5a46f2df881237fad6e
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
Chromeutils.RequestPerformanceMetrics() is now composed of two parts:
- calls content processes via IPDL to get their counters
- directly dispatch counters from the parent process
MozReview-Commit-ID: HlgcEOzkyAq
--HG--
extra : rebase_source : 60e81a27cd3a1bf1378e6b977529964507633b63
This new module simplifies how we interact with PerformanceInfo counters:
- CollectPerformanceInfo: returns all PerformanceInfo instances
- NotifyPerformanceInfo: converts PerformanceInfo in XPCOM and notify them
MozReview-Commit-ID: JedKEtsbQTF
--HG--
extra : rebase_source : c87ad34f116a789f909c480963fb99cae3fafa6d
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
The current code is a bit of a mess. This patch does the following.
- Changes the processing from backwards to forwards. This avoids the need for
all the `found` booleans, because if a flag is present multiple times, the
last one will naturally override.
- Tightens up the checking. It now doesn't use assertions, but instead returns
false if any of the options are missing arguments, or have malformed
arguments, or any of the mandatory flags are missing. (It assumes that
-appdir and -profile are optional.)
- Renames the loop variable `idx` as `i`.
- Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer.
- Avoids a redundant nsCString when handling -appdir.
The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It
holds the appModelUserId argument, which XRE_InitChildProcess() always expects
is present in the command. But it's only set to a non-empty value in
InitWindowsGroupID(), which is only called for plugin processes. So in lots of
cases the appModelUserId argument was missing, and a different argument would
be interpreted as the appModelUserId argument (seemingly without noticeable ill
effect).
The patch changes things to mGroupId defaults to "-", which means it's always
present in the command.
Note: all this explains why the old code for ContentProcess::Init() started
processing from argument aArgc, instead of aArgc-1 as you might expect -- it
had to read one extra arg in order to see the argument following -appdir,
because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId
argument even when that argument wasn't present. The new code for
ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId
fix ensures the appModelUserId argument is always present.
MozReview-Commit-ID: 8a8k6ABYMgo
--HG--
extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
Valentin Gosu
Steve Fink
Stephen A Pohl
Nika Layzell
Jonathan Watt
Sebastian Hengst
Alex Gaynor
shindli
Tristan Bourvon
arthur.iakab
Ryan VanderMeulen
Bob Owen
Gurzau Raul
Csoregi Natalia
Andreea Pavel
Boris Zbarsky
Doug Thayer
Mike Conley
Tarek Ziadé
Peter Van der Beken
Tom Ritter
Xidorn Quan
Nicholas Nethercote