We are pre-allocating shmems in the content process for use by the CDM in the
GMP process. We guess the size of shmem required. However if we guess wrong,
currently we always end up taking the non-shmem path for video frames to
return to the content process, which results in us sending another shmem
(of the wrong size) to the CDM, and this continues until we hit the limit
on the number of shmems that we tolerate the CDM asking for.
So in this patch, I change our behaviour to detect when we're allocating
shmems that are too small, whereupon we purge the existing shmems and switch
to allocating them at the size being requested by the CDM.
This means we recover from incorrectly guessing the size of shmems required
by the CDM. The overhead of an incorrect guess should be one video frame
transferred via the nsTArray path.
MozReview-Commit-ID: 8o1s7FI2UBd
--HG--
extra : rebase_source : 0612d199686278612e8c58dc97e96a9304ea3ee9
When profiling nsDocumentEncoder::EncodeToStringWithMaxLength for text/plain, 25% is Preferences::GetBool into nsPlainTextSerializer::Init. So we should use AddBoolVarCache for it.
MozReview-Commit-ID: 9CVd4OZzzr5
--HG--
extra : rebase_source : 6b860927b64109ae41a07a161f47612df2f176b7
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
--HG--
extra : rebase_source : 4b29b859aa5745fabe3db0fe68742328fc0af175
The test doesn't verify that the exceptions are reported to the browser console,
but I manually checked that they are. Adding a test for that part could be
pretty annoying.
The JS engine has a notion of ZoneGroup that we plan to use as
the unit of threading for Quantum DOM. We want to create one
ZoneGroup per TabGroup so that the two concepts are 1:1.
MozReview-Commit-ID: IDmGGRZBNpQ
If a child-to-parent IPCBlob is more than 1mb, we end up using a pipe stream.
If that ipcBlob is sent to a different process, we need to implement asyncWait
correctly: we need to call the remoteStream->AsyncWait().
nsInputStreamPump should use the stream as nsIAsyncInputStream if available.
In order to do so, we need to wrap a BufferedStream around it.
MediaResource cannot use a simple sync nsIInputStream when BlobURL are involved
in the content process.
This patch will go away when I'll finishing the removing of PBlob. Currently,
when a PBlob is sent from child to parent, we use PMemoryStream in order to
recreate the inputStream on the parent side. PMemoryStream sends the data in
chunks.
But if PBlob is dealing with a IPCBlobInputStream, it doesn't have access to
the real data. In this case, we must send data using IPCStream. In this way,
Note that thisIPCBlobInputStream will send its ID, and the parent will take the
real inputStream from the IPCBlobInputStreamStorage. Note that I check the
size to be 1mb instead 0. No particular reasons, but better to avoid the use of
PMemoryStream for nothing.
Currently FileReader API uses a nsITransport. This is not needed if the
inputStream is a nsIAsyncInputStream already, and IPCBlobInputStream is always
a nsIAsyncInputStream.
Note that, we must create a bufferedStream in order to use ReadSegments in case
the remote inputStream, received by IPCBlobInputStream, is a FileInputStream.
This was not needed with nsITransport.
IPCBlobInputStream must implement nsIIPCSerializableInputStream interface.
When this is done, the child sends the internal ID of the IPCBlobInputStream to
the parent.
An IPCBlobInputStream can be sent back to the parent process (not implemented
in this patch). When this is done, we basically send only the internal ID.
From this ID, we can retrieve the original inputStream because any
IPCBlobInputStreamParent actor has previously registered it into a singleton:
IPCBlobInputStreamStorage.
So, if we have a IPCBlobInputStreamParent, we have an inputStream, and this
inputStream is known by IPCBlobInputStreamStorage. This will be useful in the
next patches.
IPCBlobInputStream is a new type of nsIInputStream that is used only in content
process when a Blob is sent from parent to child. This inputStream is for now,
just cloneable.
When the parent process sends a Blob to a content process, it has the Blob and
its inputStream. With its inputStream it creates a IPCBlobInputStreamParent
actor. This actor keeps the inputStream alive for following uses (not part of
this patch).
On the child side we will have, of course, a IPCBlobInputStreamChild actor.
This actor is able to create a IPCBlobInputStream when CreateStream() is
called. This means that 1 IPCBlobInputStreamChild can manage multiple
IPCBlobInputStreams each time one of them is cloned. When the last one of this
stream is released, the child actor sends a __delete__ request to the parent
side; the parent will be deleted, and the original inputStream, on the parent
side, will be released as well.
IPCBlobInputStream is a special inputStream because each method, except for
Available() fails. Basically, this inputStream cannot be used on the content
process for nothing else than knowing the size of the original stream.
In the following patches, I'll introduce an async way to use it.
This is the first use of IPCBlob: ClonedMessageData.
ClonedMessageData is used for BroadcastChannel, MessagePort and any
postMessage() communication. This patch changes StructuredCloneData in order to
use IPCBlob instead of PBlob.
BroadcastChannel has a custom way to manage Blobs because when the parent
receives them from a content process, it must send them to any other
BroadcastChild actor duplicating the serialization.
This first patch introduces the basic idea of the refactoring. Instead of
having a PBlob protocol, here we have a simple IPC struct: IPCBlob.
When a Blob is sent to a different process, we move an IPCBlob struct with
type, size, some specific File properties, and an inputStream as IPCStream.
We need 'dom.animations-api.core.enabled' preference to test animation.
In this patch, set the preference before DOMWindowUtils test with animation.
MozReview-Commit-ID: 9lz0hWvyo83
--HG--
extra : rebase_source : 1972bab70063a354efb57115b8ffed9e1bb41623
This patch replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
For testing IMEContentObserver, text change, selection change and position change notifications should be exposed to JS with nsITextInputProcessorNotification.
MozReview-Commit-ID: 3PUhKXRwnAn
--HG--
extra : rebase_source : fce7a73683a2d4811070453629ef48d3ad15c8c8
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
This filtering is no longer necessary now that the fix for Bug 1338897 has landed and has gotten rid of the CRLF behaviour.
MozReview-Commit-ID: 9OKmrtQN3Cq
--HG--
extra : transplant_source : %C2%CD%AC%F6j%F5%D0%00%7E%AC%D2j%ACW%83%60%3B%F0%ED%CC
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
IMEContentObserver can store pointer of IMENotificationRequests of its mWidget. Therefore, it can check the requests dynamically when it receives content change or layout change.
This patch makes IMEContentObserver stores IMENotificationRequests as pointer and check it at every change notification received. Additionally, notification request may be changed due to focus move or something. Therefore, this patch makes IMEContentObserver and IMEContentObserver::IMENotificationSender() check if the notifications are still necessary.
MozReview-Commit-ID: 2uU2wN15D8v
--HG--
extra : rebase_source : 6086e0293343632df43087c767ad00521e764476
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
The dialog functionality of the non-standard window.find API has been broken
with e10s since it shipped, and bug 1182569 or bug 1232432 (or both) have
broken it for non-e10s.
This patch remove showDialog support entirely, for both e10s and non-e10s,
in a more deliberate way. We now ignore the argument.
MozReview-Commit-ID: 1CTzgEkDhHW
--HG--
extra : rebase_source : 9aa9623ef649fb2c42ad22738130c361acf6b8cc
We only need metric from top level content document, but we dont have
any information about it in nsDOMNavigationTiming, so I add a weak
reference which points to nsDocShell.
MozReview-Commit-ID: GiJigRLYHNV
In bug 1241783 and Github issue #186[1] it was decided to update the WebIDL in
the Web Animations spec so that instead of using a mixin as the type, we instead
use a suitable union type.
This patch removes the comments that indicated that the Gecko WebIDL definition
need to be updated to match the spec, since the spec has now been updated to
match the Gecko WebIDL definition instead.[2]
[1] https://github.com/w3c/web-animations/issues/186
[2] a07f609270d0445d2a46
1. using media::TimeUnit to save some typing.
2. replace TimeUnit() with TimeUnit::Zero().
3. replace TimeUnit::FromXXX(0) with TimeUnit::Zero().
4. replace TimeUnit::FromMicroseconds(std::numeric_limits<int64_t>::max()) with TimeUnit::FromInfinity().
5. replace some uses of int64_t with TimeUnit.
6. replace t > TimeUnit() with t.IsPositive().
MozReview-Commit-ID: 6hC94PXx86i
--HG--
extra : rebase_source : 1ea3b409e6ec12915f3e1a00359d6ff4152c8917
extra : intermediate-source : e31a12ad0e7a4840119036f261ed17eaaff85734
extra : source : ae07ee48000c4a52da0e4fd502b4d690ec51ce1f
media::TimeUnit can take its place. We don't want 2 things for the same purpose to cause confusion.
MozReview-Commit-ID: 3z6hbgXFsxP
--HG--
extra : rebase_source : 0b472e351abdc48e337aaf645ae8be467e8a300f
extra : intermediate-source : 4e2156ec04fd30af6cf59adfd1390cf67f411d4c
extra : source : bf5b035c7041a892517373dd566d2a7d7ec60c72
This is because it does ensure both, and some of the callers care about
size and some care about position.
MozReview-Commit-ID: 3e8II6Lf72X
--HG--
extra : transplant_source : %EE%5E%87%1D%AA%EB%B9%22%D9%D6%D2%9D6U%C4%2A%CA%A1r%E9
This reduces the amount of flushing we do when these APIs are called on
the root document, but increases the amount of flushing we do (probably
fixing existing bugs) when these APIs are called in a document at depth
three or more (if you consider the root depth one).
I considered the idea of adding a EnsurePositionUpToDate alias, but it
seems that some of the existing users of EnsureSizeUpToDate actually
care about position (e.g.,
nsLayoutUtils::GetDeviceContextForScreenInfo), so I just added a comment
instead.
MozReview-Commit-ID: B3L5DDQ5krc
--HG--
extra : transplant_source : J%05%F1%20M%40%88Wz%F5s_%FB%0D%0C%D6%F2%103%9B
Editor uses weak reference for nsIDocument. But nsDocumentEncoder has strong reference of nsIDocument. So to recycle nsIDocumentEncoder, editor wants the option that nsIDocumentEncoder releases nsIDocument into nsDocumentEncoder after EncodeTo* is called.
MozReview-Commit-ID: K3E9XhgD8FY
--HG--
extra : rebase_source : d37983705d574a2443c8f7504c7f5e3f35470ef1
There was a race where ending the track before removing the direct listener here,
allowed the source to append more data (notifying the direct listener)
after the consumer had been notified of the ending track.
MozReview-Commit-ID: E08UeMNQhGx
--HG--
extra : rebase_source : 740c4fde40b9e19974922cd893618032c683493d
There was an indirect race from destroying this MediaInputPort before removing
the direct listener.
MozReview-Commit-ID: 7rPzsLL4EvG
--HG--
extra : rebase_source : 6271778593079609119153ce8b81587a9188d8ba
Opening pages in a new tab might suffer an extra delay from e10s-multi because
the new process has to start up and then run all the process / frame scripts
before it can react on the request from the parent to load the first page.
There are two code paths. Either we start the tab with a remote browser and
then the RemoteWebNavigation will send the request. Or we start with a non-remote
browser and have to change the remoteness flag on it, and then the SessionStore
will send the request.
In each cases we start the timer on the parent side, send it with the message,
and when the child receives it it stops the timer and reports the measured delay.
This code only became dead very recently; in the first patch improving this
issue (which fixed an underlying issue with the code, but not the tests).
r=baku
MozReview-Commit-ID: 3QP5LrNPstJ
--HG--
extra : rebase_source : 845856d77640cf94b074dc0b9f976ae1a1fb927a
This also happens to fix other bugs, like making display: contents pseudos
animatable, which weren't before.
MozReview-Commit-ID: LhwTPNbFvSZ
--HG--
extra : rebase_source : 785105b08d6bfa15ad257e61b769a263c6810ad0
Use the new helper functions instead of calling libvpx directly.
This simplifies adding other codecs in the future.
MozReview-Commit-ID: 8VX0d5S50EE
--HG--
extra : rebase_source : c870b32bac6b924188dd722c052fb88156ad96c8
Encapsulate code from WebMDemuxer to query keyframe and frame
resolution inside VPXDecoder, so we have a clean wrapper for
all the libvpx functions we use.
MozReview-Commit-ID: ASRRhNl0A41
--HG--
extra : rebase_source : a1421462f6fc66a2abd965782ec408a8bcf7fe1f
Use the enum we already have here instead of converting
to an int when we pass it around, giving us better
type checking.
MozReview-Commit-ID: Gj4xmtQnzw2
--HG--
extra : rebase_source : 95f582e655f1a942dfb68cbba588c44afbb8a38f
This simplifies the comparison and update logic.
MozReview-Commit-ID: A6YII8tlEUn
--HG--
extra : rebase_source : ddf4304298209e515eb44962e8bc9ccd38c9956f
I wasn't able to measure any performance improvement on talos. I
haven't tried to measure anything more specific.
However, it seems like avoiding a hashtable lookup should be worthwhile.
(At one point I thought I saw nsINode::GetProperty show up as
significant in a profile, but then I concluded I was mislead, I think
because I had focused on a very small slice of the profile and the
numbers weren't significant. I don't entirely remember since this was a
while ago.)
MozReview-Commit-ID: A9OoL9qV02D
--HG--
extra : transplant_source : 2%B15e1%F3%D7%BD%EFW%9C%97%BC5%BC%BB%943%E57
Also ResolveStyleForFilter is renamed to ResolveFilterStyle for consistency.
MozReview-Commit-ID: IEOxNexpnl5
--HG--
extra : rebase_source : bd806654b3e5462b3abb4fc226b3824bc0acb71f
Chris Pearce
Kaku Kuo
Makoto Kato
David Anderson
Wes Kocher
Kartikaya Gupta
Christoph Kerschbaumer
Dragana Damjanovic
Tobias Schneider
Andrea Marchesini
sotaro
Boris Zbarsky
digitarald
Carsten "Tomcat" Book
Iris Hsiao
Yoshi Huang
Bill McCloskey
Michael Layzell
Munro Mengjue Chiang
Sebastian Hengst
Bob Clary
Shawn Huang
Daisuke Akatsuka
Ehsan Akhgari
Ehsan Akhgari
Stone Shih
Masayuki Nakano
Jan Varga
Cykesiopka
Masatoshi Kimura
David Anderson
Jon Coppeard
Shing Lyu
Nicholas Nethercote
Daosheng Mu
Phil Ringnalda
JW Wang
Emilio Cobos Álvarez
Nicolas B. Pierron
Marco Bonardo
Alessio Placitelli
Michael Kaply
Mike Conley
Tom Tung
Wei-Cheng Pan
Petr Sumbera
John Dai
Olli Pettay
Brian Birtles
bechen
L. David Baron
Mats Palmgren
Andreas Pehrson
Kevin Chen
Xidorn Quan
Jim Mathies
Gabor Krizsanits
Jonathan Watt
Alex Gaynor
Ralph Giles
Hiroyuki Ikezoe
Florian Queze