Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On 6/11/19 7:49 AM, Kartikaya Gupta wrote: IIRC another difference between prefs in all.js and gfxPrefs was that if a pref was not listed in all.js, you couldn't use it in the {test-,ref-,}pref(...) annotations in reftest.list files. That restriction is due to the code at

Re: Intent to implement and ship: Exposure of Geometry Interfaces to Workers

On 6/17/19 11:02 AM, saschan...@gmail.com wrote: Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable structured cloning for them. Note that this also allows storing these objects in IndexedDB, via implementing the equivalent of

Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

On 6/13/19 4:15 AM, violet wrote: Preference behind which this will be implemented: none. It's probably a good idea to have a pref controlling whether these get parsed, so we can disable if needed if there's an issue, given that no one has shipped these yet in a final release. Or are there

Intent to unship: DOMError

We plan to unship DOMError in Firefox 69. This type has been removed from all specs and our code; the only way to get one is to construct one explicitly from JS. The constructor telemetry at

Re: Outline of a plan to remove all XUL documents from mozilla-central

On 5/14/19 11:32 AM, Brian Grinstead wrote: 3. For files where there are no (important) XUL elements in the markup, rename .xul->.html. Brian, Could you expand on why this is preferable (when possible) to renaming them to .xhtml? Are there benefits to .html over .xhtml for our

Re: Removing --enable-shared-js [Was: Rust and --enable-shared-js]

On 5/21/19 9:55 PM, Mike Hommey wrote: Considering this has apparently been broken for so long, I guess nobody will object to me removing the option for Gecko builds? It's probably fine, yeah... -Boris ___ dev-platform mailing list

Re: Changes to how we track regressions in Bugzilla

On 4/29/19 6:15 PM, Emma Humphries wrote: We’re replacing the regression and regressionwindow-wanted keywords, and the has-regression-range field with is_regression Emma, Thank you, the new setup seems a lot clearer about the state of the bug in terms of regression tracking! -Boris

Re: Resolving URLs in c++

On 7/12/19 1:57 AM, mcace...@mozilla.com wrote: Do we have an equivalent in Gecko? No, but it would no be a bad idea to add something... Right now, in Gecko, I'm having to do this: Yeah, that's kinda ugly... rv = NS_NewURI(getter_AddRefs(resolvedUri), aData.mUrl.Value(), nullptr,

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

On 7/4/19 10:11 PM, Gerald Squelart wrote: - I found plenty of `unsigned`s around, more than `uint32_t`s. How many are in code that predates the ability to use uint32_t, though? - Our latest coding style [1] points at Google's, which has a section about Integer Types [3], and the basic gist

Re: Group email address

On 7/16/19 10:01 AM, Mahmood Naderan wrote: When I post an email to mozilla.dev.platf...@googlegroups.com from my gmail account The right e-mail address for this list is dev-platform@lists.mozilla.org. -Boris ___ dev-platform mailing list

Re: Intent to ship: multi-keyword values on the CSS 'display' property

On 8/14/19 12:37 PM, Mats Palmgren wrote: This first patch set adds support for the new syntax only, but no new box types (I'll add those separately in a bit). In general, it seems like we should think about how to integrate this stuff into layout in a better way than anonymous boxes

Re: Intent to ship: multi-keyword values on the CSS 'display' property

On 8/19/19 3:42 PM, Mats Palmgren wrote: Your point is well taken but it's an independent issue. Sure. I'm just saying that I suspect some of the combinations may be hard to implement using anon boxes, depending on what combinations are allowed. For example, can one have a thing which is

Re: Intent to Ship - Support XCTO: nosniff for navigations

On 9/5/19 9:20 AM, Sebastian Streich wrote: In Firefox 70 I intend to enable nosniff support for page navigations by default. We're still doing stream converters for navigations even if that header is sent. Is that intended? I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1579176 to

Re: New Web IDL constructor syntax

On 9/13/19 3:54 AM, Christopher Mills wrote: I've updated the MDN WebIDL guide to include a section on the new syntax: Chris, Thank you! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: The sec-approval process makes users safer

On 9/10/19 3:53 PM, Daniel Veditz wrote: Other groups must be using that flag also Sure, it just means "this needs a test checked in". "Only" 718 fixed bugs with a sec- keyword have that flag. A mere trifle! ;) -Boris ___ dev-platform mailing

Re: The sec-approval process makes users safer

On 9/10/19 12:16 PM, Dan Mosedale wrote: Seems like it ought to be straightforward to do something to cause in-testsuite? flags to send mail occasionally, or show up on some dashboard, or... Could be worth it. I just checked, and there are currently 826 bugs that have "in-testsuite?" set on

Re: The sec-approval process makes users safer

On 9/10/19 12:30 PM, Boris Zbarsky wrote: I just checked, and there are currently 826 bugs that have "in-testsuite?" set on them where I am the flag requester. And overall there seem to be ~7300 bugs that have that flag set. -Boris ___ de

Please aim to add informative messages to your exceptions

Hello, ErrorResult has two kinds of exception-throwing APIs on it: the older ones that don't allow specifying a custom message string, and newer ones that do. People should use the newer ones where possible. That means not using the following when throwing nsresults/DOMExceptions:

Re: Intent to Prototype: Have window.outerHeight/outerWidth lie and report the innerHeight/innerWidth

On 9/8/19 8:28 AM, Andreas Tolfsen wrote: It would be fine of course to move the existing behaviour to chrome-only mozOuterWidth/mozOuterHeight For what it's worth, out current outerWidth/outerHeight getters already check who the caller is and don't apply the Tor bits if the caller is system

New Web IDL constructor syntax

As of today, the syntax for Web IDL constructors no longer involves an extended attribute on the interface. There's now something that looks more like a method named "constructor" with no explicitly-defined return type. So this: [Constructor(DOMString str)] interface MyInterface {}; is

ChromeConstructor has been removed

With the new constructor syntax described in , we no longer have a [ChromeConstructor] extended attribute. If you want to make an interface only constructible from system code, you can do: interface

Re: Native actor refcounting support in IPDL

On 8/1/19 3:11 PM, Nika Layzell wrote: Bug 1550560 (https://bugzilla.mozilla.org/show_bug.cgi?id=1550560) landed recently, adding native support for declaring actors as *refcounted*. Would that allow us to add MOZ_CAN_RUN_SCRIPT bits to the generated code for those cases? -Boris

Re: Firefox command seems to be a wrapper

On 7/20/19 9:04 AM, Mahmood Naderan wrote: However, I am not sure if the tracer logs *the process that fetches data from web* or not. Using the definite article ("the") there, is fundamentally wrong. When you load a web page in Firefox, there are at least 2 processes involved in "fetching

Re: Firefox command seems to be a wrapper

On 7/15/19 11:51 AM, Mahmood Naderan wrote: Overall, firefox command is a wrapper and I am seeking for a way to access the main firefox. Is just "the main firefox" enough for the tracing you want to do? Note that all the website rendering happens in separate processes, not the Firefox UI

Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

On 7/25/19 6:22 AM, Tom Schuster wrote: After asking the Chrome team for clarification (https://github.com/whatwg/html/issues/3255), they are interested in shipping this, but need more time and information. So I propose restricting this change to Beta/Nightly and to wait for them or until we see

Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

On 7/22/19 6:22 AM, Tom Schuster wrote: This was also discussed at https://github.com/whatwg/html/issues/3255. It seems like Chrome does NOT plan on shipping this at the moment. Does "at the moment" mean they are open to shipping it in the future if we ship it and don't run into web compat

Re: Web IDL interfaces now require explicit [Exposed] annotations

On 10/1/19 5:58 AM, Christopher Mills wrote: I've removed the mention of PrimaryGlobal from https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file. It was only a small mention. I also removed the separate mention of the

Re: Web IDL interfaces now require explicit [Exposed] annotations

On 10/1/19 11:39 AM, Eric Shepherd (Sheppy) wrote: Is the page “WebIDL bindings” up to date as well? That page describes gecko-specific aspects of IDL, so usually does not need to be updated for spec changes. That said, it looks like it was never updated for

Web IDL interfaces now require explicit [Exposed] annotations

Starting today (on autoland,coming to m-c soon), there is no more [PrimaryGlobal] extended attribute on interfaces in our Web IDL, and therefore all interfaces need an explicit [Exposed] annotation saying where they are exposed (e.g. [Exposed=Window] for the case that used to not have any

Re: Intent to unship SVGZoomAndPan interface

On 9/28/19 11:41 PM, Cameron McCormack wrote: Both Chrome and Safari still implement the zoomAndPan IDL attribute. The actual functionality behind the zoomAndPan="" attribute was never implemented in any browser. Ah, ok. In that case, removing seems pretty reasonable. It would be good to

Web IDL now uses mixin syntax, not "implements"

The way mixins are done in IDL has changed syntax somewhat. Instead of having a [NoInterfaceObject] interface and an "implements" statement, the new setup looks like this: interface A {}; interface mixin B { void somethingMixedIn(); } A includes B; In-tree IDL has been updated

Re: Intent to unship SVGZoomAndPan interface

On 9/28/19 9:41 AM, longs...@gmail.com wrote: In [1] I intend to unship the SVGZoomAndPan interface. To be clear, this is unshipping that interface _and_ the mixin onto elements that adds a `zoomAndPan` attribute on them, right? The SVG WG decided to remove this interface in [2] as it's

Re: Intent to ship: Add image/webp to default Accept header

On 10/31/19 7:31 PM, Junior Hsu wrote: However, it doesn't not align the spec Is that covered by https://github.com/whatwg/fetch/issues/274 or is there a new spec issue needed? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to ship: Promise.allSettled

On 10/30/19 6:19 PM, Jan-Ivar Bruaroey wrote: This always seemed trivial to me to do with:     Promise.all(promises.map(p => p.catch(e => e))) This has different semantics from Promise.allSettled, right? In particular, it effectively treats rejected promises as resolved with the rejection

Re: Changes to tab min-width

On 12/5/19 6:51 AM, smurf4234332342342342342...@gmail.com wrote: This re-introduced setting doesn't seem to exist It's there in about:config... are you not seeing it there? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to prototype: Character encoding detector

On 12/2/19 7:42 AM, Henri Sivonen wrote: Since there isn't a spec and Safari doesn't implement the feature, there are no cross-vendor tests. Could .tentative tests be created here, on the off chance that we do create a spec for this at some point? -Boris

Re: How best to do async functions and XPCOM?

On 12/5/19 5:20 PM, Geoff Lankow wrote: 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 Is that because both the implementation of the API and the consumer of the API will be C++? For what it's

Re: Intent to prototype: Character encoding detector

On 12/9/19 6:24 AM, Henri Sivonen wrote: Good point. I'll use tentative WPTs for end-to-end automated tests. Thank you! -Boris ___ 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 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

Elements no longer have a QueryInterface method in JS

Hello all, Now that we no longer have xbl implements="" to worry about, I have landed patches to remove the QueryInterface method from Element instances [1] and the infrastructure for exposing QueryInterface on Web IDL objects in general [2]. There may still be cases in which custom element

Re: String contenation and temporaries

On 10/16/19 10:11 AM, Simon Giesecke wrote: I am wondering if the following is supposed to be safe: I would think so, yes. That said, using string types as return values is not that common (using an outparam is the normal way they are used), and so may be under-tested. On the treeherder

Some changes to how errors are thrown from Web IDL methods

Hello all, I just checked in some improvements to how we report exceptions on ErrorResult and in promise rejections [1]. Summary: 1) The public ThrowDOMException method that takes an nsresult and a string is gone. Instead, there are methods like ThrowIndexSizeError,

Re: Improvements to Web IDL exception message strings

On 2/8/20 2:31 PM, Domenic Denicola wrote: Would you consider using something that avoids the confusion with static methods/properties? E.g. - InterfaceName's methodName() - InterfaceName's attrName getter - InterfaceName's attrName setter We could think about doing that, yes. If we do, we

Improvements to Web IDL exception message strings

Hello all, We just made some changes to how exception strings from ErrorResult get formatted [1]. The changes apply to both the Throw* DOMException methods and ThrowTypeError/ThrowRangeError. In the new setup, exception messages have "%s: " prepended to them, where %s is replaced with one

Re: Intent to prototype and ship: lazy load images

On 2/6/20 5:26 PM, Hiroyuki Birchill Ikezoe wrote: Is this feature enabled by default in sandboxed iframes?: no, as of now there is no proposed flag to enable this feature in sandboxed iframes. But is it disabled by default there? I would assume not, unless it's specifically gated on

Re: Some changes to how errors are thrown from Web IDL methods

On 2/11/20 8:57 AM, Anne van Kesteren wrote: I don't know how much work this is, but ideally the signature is something like throwType(safeMessage, consoleMessage), whereby consoleMessage defaults to safeMessage or some such. We can certainly do that. It's "some" work for DOMException:

Re: Improvements to Web IDL exception message strings

On 2/10/20 9:57 AM, Anne van Kesteren wrote: Would using Document.prototype.getElementById be too long? That is a good question. I'm going to do a bit of refactoring so we only need to change one place to try these ideas out and would love some feedback! In the meantime, someone who wants

Re: Some changes to how errors are thrown from Web IDL methods

On 2/7/20 10:13 AM, Nathan Froyd wrote: If you have other things you'd like this static analysis to be used for, please file dependencies on bug 1613440. Nice! I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1614548 -Boris ___ dev-platform

Re: Proposed W3C Charter: Audio Working Group

On 1/16/20 11:21 PM, Karl Tomlinson wrote: Would it be appropriate to state that we don't intend to implement the Audio Device Client API in Gecko because we don't see a need for this additional/parallel audio API? Does anyone other than Google want the Audio Device Client API? * Something

Re: PSA: You can use UTF8String from WebIDL

On 1/20/20 8:44 PM, Marcos Caceres wrote: Is there a proposal to add this to the WebIDL spec In the IDL spec, the USVString type is representation-agnostic: it's Unicode on the IDL side, and doesn't say whether you represent Unicode as UTF-16, UTF-8, UTF-7, UCS-32, or whatever. So it

Re: PSA: Dispatching background tasks just got easier!

On 12/13/19 2:25 PM, Kristen Wright wrote: Now that Bug 1584568 just landed I wanted to mention the new background thread pool for general purpose and blocking IO runnables. Kristen, The new setup sounds awesome. Thanks to you and Nathan for working on this!

One more round of improvements to Web IDL exception messages

Hello all, We just made some more changes to Web IDL exception messages: 1) When calling ErrorResult::ThrowTypeError/ThrowRangeError, you now pass regular string literals or nsACString, not u"" or nsAString. Not only is this more convenient for the literal cases, but the JS engine was

<    5   6   7   8   9   10