This is the most important part of the patch series. It removes the
PScreenManager protocol and use ScreenManager directly in the content
processes.
Initial and subsequent updates are sent via PContent::RefreshScreens.
struct ScreenDetails are kept to serialize Screen over IPC.
nsIScreenManager::ScreenForNativeWidget is removed because
nsIWidget::GetWidgetScreen can replace it. nsIScreen::GetId is removed
because it's not useful for the more general Screen class.
MozReview-Commit-ID: 5dJO3isgBuQ
--HG--
extra : rebase_source : 06aa4e4fd56e2b2af1e7483aee7c0cc7f35bdb97
This merges two existing off-main-thread sync IPCs into a single operation. We
will change them into a single async operation in a follow up.
MozReview-Commit-ID: EfMozbRysGR
--HG--
extra : rebase_source : c7f5c395a719b9f3f13d398f8ca976b09f25ce49
- There appears to be no issues with simply changing
SetHaveEventListener from sync to async.
MozReview-Commit-ID: 3LKgDx9AZnm
--HG--
extra : rebase_source : 6c706f592f71a8c967a58f6906861fcff2525ebf
- PVRManager::GetDisplays was a sync IPC that was part of an optimization
for a use case that has been eliminated by changes to the WebVR spec.
- This was an optimization for Navigator.activeVRDisplays that would allow
enumeration of displays active in any content process without powering
on any additional VR hardware. This will no longer be necessary as the
activeVRDisplays has been restricted to returning only the displays
active in the current javascript context.
MozReview-Commit-ID: F6sOtM9nups
--HG--
extra : rebase_source : bd8967fab9677206d998eea922c8d1640551de1c
An IPDL unit test that is intended to fail should check that the
reason the test fails matches the expected reason for failure. We have
had a number of cases where some change, like renaming a keyword,
causes tests to start failing for the wrong reason, which means they
are no longer testing anything useful.
To support this, each file in error/ must contain one or more error
annotations. An error annotation is a line starting with "//error:",
followed by whatever the rest of the expected error is. For every one
of these annotations that a file has, the stderr output of compiling
the test must contain the specified string, including the "error:". It
is also an error for an error/ file to not contain an error
annotation.
To generate the initial set of annotations, I just copied and pasted
the error that each test produced. I did some light auditing to check
that the errors are reasonable, which did turn up one minor error
which I fixed as part of bug 1347527.
This patch does not check that every error produced by compiling the
file is in the list of expected errors. I think that's less of a
problem if it does occur.
MozReview-Commit-ID: BrePLGPPRil
--HG--
extra : rebase_source : 0ddb2f866c4b4ab74b7e975ce5877568c8cc3b62
- Eliminated the VRDisplay.GetImmediateSensorState sync call
and associated code as it is no longer needed.
MozReview-Commit-ID: 7BsCKC9EbsY
--HG--
extra : rebase_source : ae2de369d156e397d919d83b6c63b10374953bae
Adding this unused message prevents a compiler warning
about the private field mState being unused.
Also, get rid of some trailing whitespace.
MozReview-Commit-ID: Lb43JQhIbJU
--HG--
extra : rebase_source : c76eb5383a1535c79f2a66d3d6f8454e5b61d945
Using a separate error function will distinguish mismatched sentinels
from other errors, such as array length problems.
MozReview-Commit-ID: Gl8swNhqLns
--HG--
extra : rebase_source : 494759b105086c6c26f3ac53fb644bbf51c12800
Instead of initializing DataStorage objects on demand in the content
process, we initialize them at content process startup by getting the
parent to send down the information about the existing DataStorages at
child process startup. After that point, the dynamic change
notifications added in bug 1215723 will take care of keeping the
information in sync.
The parser always sets the first value of the tuple .nestedRange to
NOT_NESTED, so there's no need to actually store it. Instead, we
create a range when we're creating the ProtocolType. This makes it
clearer what is happening. The range is needed for the type because
the nesting pair is compared with those from messages, where the first
element can be something else.
Prior to bug 1306708, the lower range could be specified in the IPDL
file, but all uses were NOT_NESTED, so I suppose that is why it was
eliminated.
Note that the constructor for Protocol sets .nested to NOT_NESTED, but
prior to my patch, the field was never used. The constructor also
never initialized .nestedRange, but the parser always sets it so that
isn't much of an issue.
MozReview-Commit-ID: FMnoZRrkfoA
--HG--
extra : rebase_source : 3adb64b27d4a7a4e9c6c7695b145136813dbed5d
Phil Ringnalda
Bill McCloskey
David Anderson
Kan-Ru Chen
Chris Pearce
Andrew McCreight
Carsten "Tomcat" Book
Eric Rahm
Wes Kocher
Michael Layzell
Ehsan Akhgari
Kearwood Gilbert
Andrea Marchesini
Eitan Isaacson
David Parks
Kartikaya Gupta
Blake Kaplan
Bevis Tseng