We can remove mDisplayName/Id and just use VRDisplayInfo to get these two values.
Differential Revision: https://phabricator.services.mozilla.com/D50870
--HG--
extra : moz-landing-system : lando
When JS is paused, VRService will automatically shutdown because the timer is not updated,
we used to create a new VRDisplay to JS. However, the page is still using the older VRDisplay,
so it can't get the newest VRDisplayInfo status. We should exit presentation and
apply the VRDisplayInfo status to the original VRDisplay instead of creating new one.
Besides, we also need to release the VR screen buffer after exiting the immersive mode to avoid eglMakeCurrent error.
Differential Revision: https://phabricator.services.mozilla.com/D50558
--HG--
extra : moz-landing-system : lando
This isn't checking 'liveness' anymore, and we don't need it to, so dropping
that part from the name of the function.
Differential Revision: https://phabricator.services.mozilla.com/D50433
--HG--
extra : moz-landing-system : lando
Since we're now allowing onStep when not live, it makes sense to do the same
for onPop, and since it does not have any implementation details preventing
setting it while the frame is dead, we might as well.
Differential Revision: https://phabricator.services.mozilla.com/D50432
--HG--
extra : moz-landing-system : lando
We want to be able to set onStep when generators are suspended, and since that
already requires changes, it is easy to expand that and allow setting onStep
even after a frame is entirely dead. This simplifies the implementation,
and better matches user expectations around object properties not throwing
or vanishing due to actions outside their control.
Differential Revision: https://phabricator.services.mozilla.com/D50431
--HG--
extra : moz-landing-system : lando
Since we want to start allowing onStep to persist even after the frame's
internal state has been cleared, we cannot use the presence on onStep to
indicate this flag anymore.
Differential Revision: https://phabricator.services.mozilla.com/D50430
--HG--
extra : moz-landing-system : lando
DebugScript::decrementStepperCount() cannot fail and
DebugState::decrementStepperCount() cannot either. Making this clearer allows
us to not seeming like we are silently ignoring the possibility of a 'false'
return value in 'maybeDecrementFrameScriptStepperCount()' since we don't
currently check the return value in there.
Differential Revision: https://phabricator.services.mozilla.com/D50434
--HG--
extra : moz-landing-system : lando
Dictionaries that we never initialize with JS values don't need a full-featured
Init() method. Instead, we output a cut-down Init() method that doesn't even
take a JSContext and Value as argument, and skips as much work as it can. It
uses constant-false for "is the value present?", but also, to avoid compilation
errors due to use of `cx` and `val` in now-dead conversion code, it tells the
native-to-JS conversion machinery that the value is always missing, which lets
it skip most of the the work it would normally try to do and just output
initialization to the default value. We only need to do this for members that
have default values; the others either remain no-passed or are required members
with no default-initialization behavior.
This saves about 330KB of codesize on Linux64 without PGO and 285KB with PGO.
Differential Revision: https://phabricator.services.mozilla.com/D48007
--HG--
extra : moz-landing-system : lando
This saves about 270KB of codesize on Linux64 without LTO, or 20KB with LTO.
The basic idea is that we can flag dictionaries that need to-JS conversion
(hence ToObjectInternal) based on various IDL uses (return value in normal
interface, argument in callback, etc) and then annotate the ones that are
converted to JS manually in C++ code.
The mozwebidlcodegen changes are needed because non-local changes (e.g. whether
a dictionary is used as a return value somewhere) can now affect the code
generation for a dictionary and hence whether the relevant binding file should
be regenerated. Since these changes can happen in any .webidl file, we need to
check for them. We can't track this via the dependency set on the dictionary
itself, because that would not notice new uses being added.
Differential Revision: https://phabricator.services.mozilla.com/D48006
--HG--
extra : moz-landing-system : lando
I don't know when we stopped raising them, but we did at some point.
I am leaving the capability to not generate a union's ToJSVal method, because I will need it soon.
Differential Revision: https://phabricator.services.mozilla.com/D48554
--HG--
extra : moz-landing-system : lando
This saves about 200KB of codesize on Linux64 without LTO. No effect with LTO,
but is needed for the following patches to work.
Very few dictionaries need these conversions, so explicit opt-in is fine.
Differential Revision: https://phabricator.services.mozilla.com/D48005
--HG--
extra : moz-landing-system : lando
Put them behind a MOZ_HASH_TABLE_CHECKS_ENABLED define, which right now is only
defined in DEBUG builds, preserving behavior.
MakeImmutable becomes an empty inline function when disabled, which should be
zero-cost.
Differential Revision: https://phabricator.services.mozilla.com/D50493
--HG--
extra : moz-landing-system : lando
Default constructors of members run if not specified there, and these ifdefs
are ugly.
Differential Revision: https://phabricator.services.mozilla.com/D50492
--HG--
extra : moz-landing-system : lando
I want to maybe enable some of these checks in DIAGNOSTIC_ASSERT builds.
The whole type is compiled out in release builds at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D50491
--HG--
extra : moz-landing-system : lando
Separating these changes out into a separate patch/bug makes them a
little easier to verify. Turning on C++17 support should then be just a
matter of updating expected results.
Differential Revision: https://phabricator.services.mozilla.com/D47324
--HG--
extra : moz-landing-system : lando
Revert the coreaudio-sys dependency changed in bug 1589514, which causes
a trouble when compiling with sccache
Differential Revision: https://phabricator.services.mozilla.com/D50529
--HG--
extra : moz-landing-system : lando
When copying from the input field, when the value has already been confirmed
by the user (either by picking a result or Enter), we cannot use the selected
result information, because it has already been cleared by _loadURL setting
the value to the final one.
If the page already finished loading, pageproxystate is valid and we can use
currentURI, but if the page takes a long time to load, or the load is canceled,
we need a fallback, because we don't want to interrupt the copy operation.
In this case, the current value can be either a valid url or a search string.
If it's a valid url, we can just go through the usual URI handling, trying to
make it nicer. After all, we'd do the same just after the page is done loading.
Otherwise, we fallback to the currently selected value.
This works also if the user is still in the process of selecting a result
and tries to copy from the input field, because on result selection we set
either a valid url or a non-url.
Differential Revision: https://phabricator.services.mozilla.com/D50832
--HG--
extra : moz-landing-system : lando
This passes the existing dirty rect for a picture cache update
through the native compositor interface, allowing compositors
to only update a sub-rect of a tile.
Also update the example to pass dirty rect to DirectComposition,
and add debug drawing for compositor redraw region.
Differential Revision: https://phabricator.services.mozilla.com/D50767
--HG--
extra : moz-landing-system : lando
