Intent to Prototype: beforeinput event (disabled by default even in Nightly channel)
Summary: "beforeinput" event is useful for web apps which manage input data into ``, `` and/or `contenteditable`. This event is fired before our editor modifies value or DOM tree and some types are cancelable. Therefore, if some user inputs are not acceptable for the web app, they can cancel it, and/or modifies the value or the DOM tree as they want. Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=970802 Standard: https://w3c.github.io/uievents/#event-type-beforeinput Platform coverage: all Preference: dom.input_events.beforeinput.enabled (false by default for now) DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1607686 -- Masayuki Nakano Working on DOM, Events, editor and IME handling for Gecko ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How best to do async functions and XPCOM?
On Thu, Dec 12, 2019 at 09:30:06AM -0500, Boris Zbarsky wrote: On 12/10/19 3:31 PM, Kris Maglione wrote: In what way is dom::Promise annoying to use from C++? The one thing I know about that's pretty annoying is if you receive the promise from someone else and want to add reactions to it. PromiseNativeHandler kinda works, but then you get JS::Values and have to extract the things you care about from them manually, which is a bit of a pain. Note that you can also use `ThenWithCycleCollectedArgs` and `ThenWithoutCycleCollection` to add reactions from native code, which is a lot easier than `PromiseNativeHandler`. You do still need to manually deal with JS::Values, though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Visibility of disabled tests
Hi folks, in the past I and other triage owners have experienced some frequently failing tests being disabled without a clear notice to the triage owner, component owner or test author. I've seen this specific pattern a few times: - An intermittent test starts failing very frequently very suddenly. - The Stockwell team reacts quickly (which is good) and disables the test, getting review from another sheriff or member of their team. - No analysis is done on the possible cause or regressing bug - The intermittent bug is left open without needinfo to anyone who could fix the test (some even with a P5 priority). This is problematic, since a) we're losing test coverage that way and b) these tests might be failing frequently because there's actually something wrong with the feature, not just a test issue. In most cases these get discovered sooner or later so I don't want to make this issue bigger than it is, but it's still suboptimal for some of us. It seems like we could easily remedy this by introducing a policy like: *For disabling tests, review from the test author, triage owner or a component peer is required. If they do not respond within 2? business days or if the frequency is higher than x, the test may be disabled without their consent, but the triage owner *must* be needinfo'd on such a bug in this case.* It would also be extremely helpful if Sheriffs could post a possible regression range for the frequent intermittent when disabling, where possible (because I assume that's also the best time to do a regression range). Any thoughts? Cheers. Johann ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
