When the inspector is in landscape mode, it will first try to toggle on the 3 pane mode by
creating a middle/bottom-left panel with the same sidebar width, but if doubling the
original sidebar width will be bigger than half of the toolbox's width, we will instead
toggle on the 3 pane mode with all panels being of equal widths.
When the inspector is in portrait mode, it will just toggle on its T shape pane such that
the 2 bottom panes are equal widths.
We also increased the breakpoint width of the toolbox's side view to 1000px so that it
will keep its T shape in portrait mode until the toolbox's width is bigger than 1000px.
This creates a simulcast stream with an odd resolution. This previously would
have caused a runtime assertion failure and crash.
MozReview-Commit-ID: IsywVOu6UeV
--HG--
extra : rebase_source : 7ad1cbe7dd36ccdd7a05e0c0a83db98a36c8c416
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : b13b7acdac7f1e0b6016417b83bbe97dc2417a92
The security checks outer window did here don't seem right, because the whole
point is that this method is only called by C++ code for its own purposes.
We're not adding random untrusted listeners via addSystemEventListener!
MozReview-Commit-ID: JdS5gTESclu
The CanCallerAccess check in the "webidl" version of
nsGlobalWindowOuter::AddEventListener was pointless, because bindings never
call things on outer windows.
MozReview-Commit-ID: 1CGMJ277bPu
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
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
At least some non-zero payloads confuse GDB and make it iloop on the
breakpoint instruction rather than break to the command line as it
should. There seems to be no reason not to use a zero payload.
--HG--
extra : rebase_source : 6d6f9aa2911b86b02572f88948d48bc2238c6353
extra : amend_source : 9fed9235d481a9eadafc4a3e0075c9fef8b6050d
The patch also adds more `const` to txCoreFunctionDescriptor.
MozReview-Commit-ID: 6VFyAcjD98F
--HG--
extra : rebase_source : db054286e7e236775d686e406c6e05a18d5b5f35