Re: New CEnum enumeration type in XPIDL
OMG, this is amazing work! Thanks a lot for working on this! On Tue, 6 Nov 2018 at 19:37, Kyle Machulis wrote: > Since just about forever (no, really: > https://bugzilla.mozilla.org/show_bug.cgi?id=8781), there's not really > been > an enum type in XPIDL. This means that we have a lot of interfaces with > lots of similarly named consts, that are usually passed around in C++ as > uint32_t's, though sometimes we redefine them as enums in C++ too and then > mix everything together. This can get extremely confusing, especially in > situations involving multiple enums from multiple interfaces. > > Having run into this problem while doing docshell work, I talked to Nika > about adding enums to XPIDL. With copious amounts of help from her since > this is my first foray into the XPIDL parser, I've now managed to land a > new type, called CEnums. > > CEnums are exactly what they sound like, c-style enums in XPIDL. For C/C++, > they'll turn into enums on the Interface class type. In Javascript, they'll > continue to be constants on the interface, and should not require any > changes to code referring to the enum values. Enum member value assignment > follows the C/C++ specs, where any unspecified value is incremented from > the value of the previous enum member. > > There are examples of how CEnums look and work in our tests: > > > https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/js/xpconnect/tests/idl/xpctest_cenums.idl > > https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/js/xpconnect/tests/components/js/xpctest_cenums.js > > https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/js/xpconnect/tests/components/native/xpctest_cenums.cpp > > Note that the type names differ between C++ and XPIDL. In C++, the enum > name is the type, within in the interface class. When referring to the enum > type in XPIDL, the format is [interface]_[enum], e.g. > nsIXPCTestCEnums_testFlagsExplicit when passed as an interface method > argument in xpctest_cenums.idl. > > I'll have the XPIDL MDN pages updated with this information soon. > > There is a metabug at https://bugzilla.mozilla.org/show_bug.cgi?id=1503630 > for converting const lists to CEnums. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: img decode API support
Ah, my bad. Yes, if scripts are available, this is available. It doesn't allow you to do anything new, aside from forcing a decode to start (which you could do by adding the image to the DOM tree, assuming it is visible) and knowing when the decode has completed. The usual content restrictions will continue to apply. On Wed, Nov 7, 2018 at 11:23 AM, Boris Zbarsky wrote: > On 11/7/18 11:15 AM, Andrew Osmond wrote: > >> This is simply a >> new method for JS on image elements, so it should be unavailable. >> > > Script can run in sandboxed iframes, depending on sandboxing flags. > > It sounds like this feature is enabled by default in sandboxed iframes, as > long as script is enabled, right? > > -Boris > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: img decode API support
On 11/7/18 11:15 AM, Andrew Osmond wrote: This is simply a new method for JS on image elements, so it should be unavailable. Script can run in sandboxed iframes, depending on sandboxing flags. It sounds like this feature is enabled by default in sandboxed iframes, as long as script is enabled, right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: img decode API support
Web authors would like a way to guarantee an image has been fully decoded and will display immediately when inserted into the DOM. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1501794 Link to standard: https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode Platform coverage: All Target Release: 65 Do other browser engines implement this?: Chrome 64, Opera 51, Safari 11.1. Is this feature enabled by default in sandboxed iframes?: This is simply a new method for JS on image elements, so it should be unavailable. Is this feature restricted to secure contexts?: No. This already ships on Chrome and Safari in an insecure context. web-platform-tests: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/the-img-element/decode/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: MediaStream.currentTime
This has landed on central, and a note has been published on fxsitecompat.com [0]. Thanks, Paul. [0]: https://www.fxsitecompat.com/en-CA/docs/2018/mediastream-currenttime-has-been-removed/ On Wed, Oct 31, 2018 at 4:36 PM Paul Adenot wrote: > This member has never been specced, never been implemented by any other > implementors, and I can't find usage in public code anywhere apart from our > Mochitests. > > jib tells me that he's confident we can remove this without deprecating it > first. > > The code pattern to use is to assign a particular MediaStream to an > `HTMLMediaElement,srcObject` and query the `currentTime` property of the > `HTMLMediaElement`, or to use `AudioContext.createMediaStreamSource`, and, > again, to query the `currentTime` property of the `AudioContext`. Gecko has > always supported those code patterns. Also, the notion of a `currentTime` > without playing the `MediaStream` somewhere does not even make sense, since > we wouldn't know what clock domain this `MediaStream` is associated with. > > This is being tracked in bug 1502927. > > Thanks, > Paul. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
