Sending it back via the parent process ensures that it will take the same path
that regular touch events do, and so guarantees that the Tap event won't overtake
the touch events and get dispatched to content first.
MozReview-Commit-ID: 8TiHY2PFPvE
The parameter is always true if the tap type is a eSingleTap and false in
all other cases, so it's redundant. As it was added as an optimization in bug
1020199 removing it should be safe.
MozReview-Commit-ID: IPB8BUagQl6
MultipartBlobImpl always requires copying the incoming BlobImpl array.
This copying, and its associated refcounting, is unnecessary in many
cases, as we're just going to delete the copied-from array anyway. We
might as well pass in ownership when creating the multipart blob and
avoid all the overhead associated with copying and refcounting.
This array only exists to be initialized fallibly so we can swap it into
the infallible array we actually want to use. But we can fallibly
initialize the infallible array directly, so let's do that.
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
Passes the profile dir to the content process as a -profile CLI
option so that the correct profile dir can be used in the OS X content
sandbox rules. Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected
from the content process (apart from a few profile subdirectories) even
when they don't reside in ~/Library.
xpcshell tests invoke the content process without providing a
profile directory. In that case, we don't need to add filesystem
profile dir. read/write exclusion rules to the sandbox.
This patch adds two new macros to the content sandbox rule set:
|profileDir| holds the path to the profile or the emptry string;
|hasProfileDir| is a boolean (1 or 0) that indicates whether or
not the profile directory rules should be added. If |hasProfileDir|
is 0, profile directory exclusion rules don't need to be added
and |profileDir| is not used.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : 3d5b612c8eb3a1d0da028eba277cd9d6f0c9ac00
We currently allow nested event loop to delay ContentChild::RecvShutdown
which in turn might cause content process shutdown hang. This patch
attempts to annotate the crash report that a shutdown hang was after we
have received RecvShutdown but never reach SendFinishShutdown or the
hang happened before or after RecvShutdown.
MozReview-Commit-ID: 8pGqwzLlYpK
--HG--
extra : rebase_source : 78fdec0c29ded1abbd6651c67fe5c97f63555635
We currently make the initial browser in a window remote by default. If early
on in the session, that one remote browser goes away (and the content process
was still booting), there's about 5 seconds before the shutdown kill timer
will take that content process out for not quitting fast enough.
There are some cases during startup where the content process is waiting
on information from the parent, so it cannot respond to the request to
quit in time. The parents shutdown kill timer goes off, and the shutdown
kill occurs.
In this bug, what's happening is that the initial browser flips remoteness
from remote to non-remote when it goes to about:sessionrestore. This starts
the shutdown kill timer. The content process runs out of time, and the
shutdown kill timer fires, killing the content process. The TabParent::ActorDestroy
method (which still exists, even though the browser is no longer remote),
interprets this as an abnormal shutdown, and bubbles the oop-browser-crashed
event to the associated <xul:browser>, which causes the page to browser to
about:tabcrashed, when it had already loaded about:sessionrestore.
This patch makes it so that the TabParent::ActorDestroy method first checks
to ensure that the associated remote frameloader is still the one that the
frameloader owner cares about. If not (because, say, the remoteness has
flipped and a new non-remote frameloader has been created), then the
event is not fired, since the user has moved on.
MozReview-Commit-ID: G4jmR6lMMFl
--HG--
extra : rebase_source : 7e752d9854d6c17b2b346cc986c0fbad00292848
We currently make the initial browser in a window remote by default. If early
on in the session, that one remote browser goes away (and the content process
was still booting), there's about 5 seconds before the shutdown kill timer
will take that content process out for not quitting fast enough.
There are some cases during startup where the content process is waiting
on information from the parent, so it cannot respond to the request to
quit in time. The parents shutdown kill timer goes off, and the shutdown
kill occurs.
In this bug, what's happening is that the initial browser flips remoteness
from remote to non-remote when it goes to about:sessionrestore. This starts
the shutdown kill timer. The content process runs out of time, and the
shutdown kill timer fires, killing the content process. The TabParent::ActorDestroy
method (which still exists, even though the browser is no longer remote),
interprets this as an abnormal shutdown, and bubbles the oop-browser-crashed
event to the associated <xul:browser>, which causes the page to browser to
about:tabcrashed, when it had already loaded about:sessionrestore.
This patch makes it so that the TabParent::ActorDestroy method first checks
to ensure that the associated remote frameloader is still the one that the
frameloader owner cares about. If not (because, say, the remoteness has
flipped and a new non-remote frameloader has been created), then the
event is not fired, since the user has moved on.
MozReview-Commit-ID: G4jmR6lMMFl
--HG--
extra : rebase_source : 7e752d9854d6c17b2b346cc986c0fbad00292848
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
Kartikaya Gupta
Andrea Marchesini
Matt Woodrow
Carsten "Tomcat" Book
Bill McCloskey
Nathan Froyd
Andi-Bogdan Postelnicu
David Anderson
Tooru Fujisawa
Aaron Klotz
Chris H-C
Phil Ringnalda
Wes Kocher
Haik Aftandilian
Kan-Ru Chen
Mike Conley
Michael Layzell
Chun-Min Chang
Boris Zbarsky
Jimmy Wang