By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
We enable compilation of FOG/Glean on _all_ platforms.
We disable Glean initialization and metric recording on Android (GeckoView) by respecting MOZ_GLEAN_ANDROID.
This way GeckoView just works, consumers don't need to think about it (except in tests, these need to be disabled for Android builds).
Stubbing out the metric implementations will happen in the commits after
this one.
Differential Revision: https://phabricator.services.mozilla.com/D106766
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Preserve the last state of when we focused the element in that window,
if the focus method is unknown.
Depends on D104861
Differential Revision: https://phabricator.services.mozilla.com/D104863
When binding delegates blur() to BrowsingContext::Blur, the remote side skips
the check given that there is no js on the stack, but we should not skip the
check. This only affects design-mode which allows the focus moving to the root
element.
Differential Revision: https://phabricator.services.mozilla.com/D104008
When binding delegates blur() to BrowsingContext::Blur, the remote side skips
the check given that there is no js on the stack, but we should not skip the
check. This only affects design-mode which allows the focus moving to the root
element.
Differential Revision: https://phabricator.services.mozilla.com/D104008
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
Covers adding the new JS global `GleanPings` for JS, the new structs for C++ at
mozilla::glean_pings, ping-id and string-table-index codegen, the usual
boilerplate for JS and C++ stuff, and tests.
Unresolved:
* What happens if we call this on a non-parent process?
(This isn't a supported mode of operation)
Differential Revision: https://phabricator.services.mozilla.com/D98671
Headers we want our consumers to use remain in mozilla/glean,
but scaffolding now lives in mozilla/glean/bindings.
This will allow me to have a binding for the GleanPings global in GleanPings.h
AS WELL AS a GleanPings.h which is the C++ consumer API for custom pings.
Differential Revision: https://phabricator.services.mozilla.com/D98670
Only for top windows because for nested iframes they could get around
this without being noticed by reloading themselves which is not great.
Differential Revision: https://phabricator.services.mozilla.com/D98775
Currently, the gamepad code uses a uint32_t as a handle and does some trickery
with it by trying to create a unique ID and adding an offset to it for VR code.
This can (and has) led to errors where the developer forgets to perform the
arithmetic and sends the wrong number to the wrong manager.
This change created a strongly-typed handle that remembers which service it
belongs to. This should eliminate such accidents.
Differential Revision: https://phabricator.services.mozilla.com/D96273
On Nightly, for now. This allows websites to get the real viewport size.
The rounded size has caused problems in the past (see bug 1648298 / bug
1648265), and changing it would be ideal.
I told the CSSWG that we can experiment with this on Nightly to
alleviate (or prove) compat concerns, in which case we'd need to use a
different solution, see https://github.com/w3c/csswg-drafts/issues/5260.
Differential Revision: https://phabricator.services.mozilla.com/D96826
This is only the basic outline.
It doesn't do anything yet, but compile.
As there are no metrics generated for it it can't look up anything.
To note: Actual metric types are implemented in XPIDL later.
The following (priviliged) JavaScript code will soon work (if the
corresponding metrics would be defined):
const { Glean } = ChromeUtils.import("resource://gre/modules/Glean.jsm");
Glean.shared.test_only.count_things.add(1);
Differential Revision: https://phabricator.services.mozilla.com/D92211
Before applying this patch, `ContentMediaController` is per process, it might contains `ContentMediaControlKeyReceiver` coming from different browsing context, and we are not able to treat those receivers differently based on the browsing context they exist in.
The goal to change `ContentMediaController` per inner window is to allow us to have an ability to treat receivers in different browsing context with different operations without interering each other.
As the `ContentMediaController` control the media playback in web context, which life cycle is tight to the inner window, that is why I choose to create `ContentMediaController` on the inner window.
In addition, update the comment to make its up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D87142
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
Popup permissions initialized with the result of checking if the
constructing WindowContext's principal is allowed to open a popup. The
field is updated for all WindowContexts sharing a principal whenever
the popup permission for that nsIPrincipal changes.
Differential Revision: https://phabricator.services.mozilla.com/D86378
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
