This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
--HG--
rename : dom/file/nsHostObjectProtocolHandler.cpp => dom/file/BlobURLProtocolHandler.cpp
rename : dom/file/nsHostObjectProtocolHandler.h => dom/file/BlobURLProtocolHandler.h
Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
--HG--
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/MessageBroadcaster.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/MessageBroadcaster.h
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/ParentProcessMessageManager.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/ParentProcessMessageManager.h
rename : dom/base/ChromeMessageSender.cpp => dom/base/ProcessMessageManager.cpp
rename : dom/base/ChromeMessageSender.h => dom/base/ProcessMessageManager.h
extra : rebase_source : c9b0c543f9f367535919a6c6840e5ba038023112
extra : histedit_source : 7749f98e11e25423fcf414cc1f0415104343798a
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This is currently a no-op, but the idea here is to make sure to set the
process to "active" when we're about to use it for something.
MozReview-Commit-ID: 2QUlALhfD4k
--HG--
extra : rebase_source : 13a67e9353bb47593b1394ce7ae7a7b6eef6e381
This is fairly straightforward, other than the fact that the
nomenclature gets a bit awkward with the aForce parameter on
the ForcePaint methods. I'm not sure which direction to go with
this - "aForce" seems a fairly intuitive name for what we want,
and I'm kind of inclined to say the existing ForcePaint mechanic
should be renamed to something like PaintWithInterrupt, or
PaintWithPriority.
MozReview-Commit-ID: Bj9DROug1pC
--HG--
extra : rebase_source : a3d91fec940d83325d36bafb13fe892e9c9530e8
When memory-pressure events were first used in an e10s environment it was
to implement memory minimization from about:memory. However when low memory
detection was first introduced in Firefox OS an issue arised with this scheme:
every process was using a kernel-based low-latency mechanism to detect low
memory scenarios and send memory-pressure events; but the main process events
were also being forwarded to all child processes causing listeners to be
triggered twice. Because of this -no-forward events were introduced and used.
Currently however low-memory is detected via polling, so there will always be
a significant delay between the beginning of the low-memory scenario and its
detection. Because of this there is no value in having content processes poll
on their own and it's best to have only the main process do it and then
forward the memory-pressure events to all child processes.
MozReview-Commit-ID: AMQOsEgECme
--HG--
extra : rebase_source : 1b408b31dd27940981407f50f2e5f07e354b16d7
PerformanceCounters are currently disabled in two ways:
- a preference that's off by default "dom.performance.enable_scheduler_timing"
- calls made only for nightly using #ifndef RELEASE_OR_BETA
In order to simplify the code, let's remove the #ifndef and rely only on the pref.
That will also allows us to use the feature in every version going forward.
The performance will not be impacted since the current code is already using
the (cached) pref value to determine if the counters are used.
MozReview-Commit-ID: 47t2M1O13aH
--HG--
extra : rebase_source : e129e1829f1dc37c019e50e156474c4876d6d6cb
This is necessary to avoid web platform test failures for tests that rely on layout calculations occurring
inside a recently opened tab or window. Originally, the layout flush was happening "accidentally" within
the StatusPanel that displays loading status for the browser. That flush is being removed in another patch
in this series.
MozReview-Commit-ID: IUxiBS9CDRY
--HG--
extra : rebase_source : 1174290fc6fa8da68bfe383e79daa417bbb8de39
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 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
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
