Intent to implement and ship: Exposure of Geometry Interfaces to Workers
Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable structured cloning for them. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1420580 Link to standard: https://drafts.fxtf.org/geometry/ Platform coverage: all Estimated or target release: 69 Preference behind which this will be implemented: none Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: N/A Do other browser engines implement this? Chrome exposes them and supports structured cloning. web-platform-tests: https://github.com/web-platform-tests/wpt/tree/master/css/geometry Is this feature restricted to secure contexts? No ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: webkitURL
Summary: webkitURL will be implemented as a legacy compatibility alias of URL. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1366738 Link to standard: https://url.spec.whatwg.org/#url-class Platform coverage: All Estimated or target release: 69 Preference behind which this will be implemented: None Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: N/A Do other browser engines implement this? Answer with: shipped since Chrome 2 and Safari 6. web-platform-tests: https://w3c-test.org/url/idlharness.any.html Is this feature restricted to secure contexts? No ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: DOMQuad.prototype.bounds
DOMQuad.prototype.bounds is planned to be unshipped in Firefox 69. The live `bounds` attribute has been removed from the geometry spec and replaced by standard DOMQuad.prototype.getBounds(). It shows zero usage on web and no other browsers implements this property. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1454622 Telemetry: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-06-24&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F68&measure=USE_COUNTER2_DEPRECATED_DOMQuadBoundsAttr_PAGE&min_channel_version=nightly%252F60&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-05-21&table=0&trim=1&use_submission_date=0 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: DOMMatrix.prototoype.scaleNonUniformSelf()
The Geometry spec dropped scaleNonUniformSelf() in 2016 to replace it with scaleSelf(). As no other browsers implement this method, it's planned to be removed in Firefox 69. Spec change: https://github.com/w3c/fxtf-drafts/commit/99e3212469026b2f2f50926a41912d110a1741b7 Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1560119 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Documentation for IPDL needs some edit
I have started to learn about IPDL and am reading IPDL Tutorial (https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks like the document is old and needs some edits, but this is an area I'm still learning so I want to make sure: 1. Nearly all of the examples lack explicit modifier before message names. AFAIK messages are required to have `async` or `sync` before them since Bug 1240871, am I right? 2. The document says `rpc` shouldn't be used for general purpose but still the example in "Subprotocols and Protocol Management" section uses it for no explicit reason. I think it should use async instead as suggested, what do you think? 3. `rpc` is mainly for NPAPI per the document, but NPAPI is dead. Why do we still need it? Not sure this is the right place to discuss about documentations, if I posted to a wrong one please inform me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documentation for IPDL needs some edit
On Saturday, August 10, 2019 at 11:10:58 PM UTC+9, sasch...@gmail.com wrote: > I have started to learn about IPDL and am reading IPDL Tutorial > (https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks > like the document is old and needs some edits, but this is an area I'm still > learning so I want to make sure: > > 1. Nearly all of the examples lack explicit modifier before message names. > AFAIK messages are required to have `async` or `sync` before them since Bug > 1240871, am I right? > > 2. The document says `rpc` shouldn't be used for general purpose but still > the example in "Subprotocols and Protocol Management" section uses it for no > explicit reason. I think it should use async instead as suggested, what do > you think? > > 3. `rpc` is mainly for NPAPI per the document, but NPAPI is dead. Why do we > still need it? > > Not sure this is the right place to discuss about documentations, if I posted > to a wrong one please inform me. Or rpc semantics has already been removed since Bug 1049879? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documentation for IPDL needs some edit
On Monday, August 12, 2019 at 6:29:01 AM UTC+9, j.j. wrote: > Am Samstag, 10. August 2019 16:10:58 UTC+2 schrieb sasch...@gmail.com: > > I have started to learn about IPDL and am reading IPDL Tutorial > > (https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks > > like the document is old and needs some edits, but this is an area I'm > > still learning so I want to make sure: > > > > 1. Nearly all of the examples lack explicit modifier before message names. > > AFAIK messages are required to have `async` or `sync` before them since Bug > > 1240871, am I right? > > > > 2. The document says `rpc` shouldn't be used for general purpose but still > > the example in "Subprotocols and Protocol Management" section uses it for > > no explicit reason. I think it should use async instead as suggested, what > > do you think? > > > > 3. `rpc` is mainly for NPAPI per the document, but NPAPI is dead. Why do we > > still need it? > > > > Not sure this is the right place to discuss about documentations, if I > > posted to a wrong one please inform me. > > I can't answer any of your questions, but may be this is helpful in case the > docs are out of date: > https://developer.mozilla.org/de/docs/MDN/Feedback > where you can find this link to report a problem: > https://github.com/mdn/sprints/issues/new?template=issue-template.md&projects=mdn/sprints/2&labels=user-report Thanks, I filed https://github.com/mdn/sprints/issues/2006. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documentation for IPDL needs some edit
Okay, thanks for the confirmation! Will do some needed edits. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Document::ResolveWithBaseURI is just introduced to ease URL resolving
Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1572349 Previous discussion: https://groups.google.com/forum/#!msg/mozilla.dev.platform/y_eEf14fLu4/ECG_Mq7hAQAJ Based on the previous discussion, I added a helper method to ease URL resolving without forgetting about `document.baseURI`. This should help simplifying existing codes as well, so please try it whenever possible. Thanks to Marcos Caceres for mentoring! ___ 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 Friday, December 6, 2019 at 7:20:21 AM UTC+9, Geoff Lankow wrote:
> Hi all
>
> I'm redesigning a bunch of Thunderbird things to be asynchronous. I'd
> like to use Promises but a lot of the time I'll be far from a JS context
> so that doesn't really seem like an option. The best alternative I've
> come up with is to create some sort of listener object and pass it to
> the async function:
>
> interface nsIFooOperationListener : nsISupports {
>void onOperationComplete(
> in nsresult status,
> [optional] in string errorMessage
>);
> };
>
> ...
>
> void fooFunction(..., in nsIFooOperationListener listener);
>
> This works fine but I wonder if there's a better way, or if there's some
> established prior art I can use/borrow rather than find out the pitfalls
> myself.
>
> TIA,
> GL
I recently got a chance to play with MozPromise [0] in a pure C++ function to
access Windows API. It served my purpose well except that I had to use a bit
hacky way to pass `MozPromiseHolder` into a lambda expression.
[0]: https://phabricator.services.mozilla.com/D42484
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
