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

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

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: 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

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: 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: 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: 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!

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

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/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/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: 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 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: 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

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: 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

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: 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

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

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

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

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: 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

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

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

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: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

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: 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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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: Intent to unship:

On 6/14/19 7:02 AM, Henri Sivonen wrote: Thanks for the removal. Do we have enterprise Web developer-facing documentation on 1) how TLS client cert enrollment should work now or 2) if there is no in-browser client cert enrollment path anymore, what concretely should be used instead? For what

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

On 6/14/19 6:23 AM, violet wrote: Preference behind which this will be implemented: layout.css.overflow-logical.enabled Thank you. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

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

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: NS_NewURI is now thread-safe

On 6/10/19 4:07 PM, Valentin Gosu wrote: which means nsIURI can now be safely used and created on any thread via NS_NewURI. That's awesome news! and if you want to add any other special scheme to Gecko you should do so in NS_NewURI in nsNetUtil.cpp Here "special" is in the sense of

Re: Intent to implement and ship: blob.text(), blob.arrayBuffer(), blob.stream()

On 6/7/19 8:47 AM, Andrea Marchesini wrote: Summary: implement and ship 3 new methods to read Blob contents: blob.text(), blob.arrayBuffer() and blob.stream(). Looks good to me. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

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: 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: 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: Apple Notary Service and Debugging Impact

On 4/11/19 3:07 AM, Haik Aftandilian wrote: With notarization, Nightly channel builds will not be debuggable unless the system is booted with system integrity protection (SIP)[1] disabled. Do you know whether sampling via Activity Monitor's "Sample Process" option or via Instruments will

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

On 4/9/19 10:37 AM, Brian Grinstead wrote: I'll think some more about if there’s a way to limit the risk of losing test coverage. One simple thing is to restrict the change to

Re: Intent to deprecate - linux32 tests starting with Firefox 69

On 4/5/19 10:20 AM, Kartikaya Gupta wrote: If we can drop that then we can remove a bunch of complexity and code paths. Are we talking about just dropping linux32 _tests_, or dropping linux32 _support_? Because if we're keeping support, and linux32 is the only non-APZ confiration, then not

Re: Intent to deprecate - linux32 tests starting with Firefox 69

On 4/5/19 9:35 AM, jma...@mozilla.com wrote: As our next ESR is upcoming, I would like to turn off linux32 on Firefox 69 and let it ride the trains and stay on 68 ESR. This will allow builds/tests to be supported with security updates into 2021. The only thing I've used the linux32 tests

Re: Creating a new mach command for adding tests

On 4/1/19 2:36 PM, Brian Grinstead wrote: When you run the command it will create a file with the appropriate boilerplate and add it to the manifest file (chrome.ini, mochitest.ini, browser.ini depending on the type). Brian, thank you for putting this together! I have one concern with the

Re: How to reliably make an ArrayBufferView wrapped?

On 3/25/19 11:22 AM, violet.bugrep...@gmail.com wrote: I think it should be a browser test, because I need to call IndexedDB. OK, makes sense. In that case, the simplest option is to pick a browser test that involves Xray wrappers and modify it so you have an Xray to an ArrayBufferView.

Re: How to reliably make an ArrayBufferView wrapped?

On 3/25/19 4:22 AM, violet.bugrep...@gmail.com wrote: In the test, I want to make sure the object is indeed a wrapped one. Is there a reliable way to write JavaScript code to achieve this? Are you trying to write a JS shell test or a browser test? -Boris

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

On 3/7/19 7:31 PM, Ehsan Akhgari wrote: *web-platform-tests*: This is an intervention which different engines do not agree on yet. Creating a web-platform-test for it would be very simple but it will be failing in the engines that do not agree with the intervention. I'm not sure what the

Re: Intent to ship: Dynamic module imports (JS 'import()' syntax)

On 3/7/19 10:27 PM, Martin Thomson wrote: Is there a way that doesn't rely on eval or eval-like mechanisms? I suspect the only detectable thing here (and Jon might wake up tomorrow and tell me I'm wrong!) is that import('stuff') is a syntax error without the support but is not a syntax error

Re: Intent to ship: Dynamic module imports (JS 'import()' syntax)

On 3/7/19 6:14 PM, rekt...@gmail.com wrote: Is there any way to feature detect support for import() syntax? In Firefox, yes, as far as I can tell: try { new Function("import('')"); // supported } catch (e) { // not supported } -Boris

Intent to ship: aligning with the spec on document.open behavior and removing wyciwyg

Summary: historically in Gecko document.open created a new global and new session history entry (unless "replace" was passed). We also stored the written data in a "wyciwyg" cache entry so it could participate meaningfully in session history. I plan to change these behaviors and simplify the

Intent to ship: sharing compartments across globals on the web and adjusting document.domain behavior

Summary: We plan to place multiple globals in a single compartment to reduce the memory overhead due to cross-compartment wrappers and the performance overhead of traversing those wrappers. Globals will be placed in the same compartment if: (1) they are same-origin (ignoring document.domain)

Re: Intent to Unship: Fake Plugins

On 2/21/19 3:44 PM, Kyle Machulis wrote: and Pdf.js is still shipping as a stream handler for the time being. Note that there are a bunch of issues with that (e.g. around window.print()), which we were hoping fake plugins would solve. If that plan has been abandoned, it might be worth

Re: C++ method definition comments

On 1/30/19 10:19 AM, Ehsan Akhgari wrote: What tool do you use which has difficulty showing function names in diffs right now? It seems to work fine for me both in git and hgweb... "hg diff" and "git diff" both fail at this over here when there is a /* comment */ before the function name.

Re: Does mozilla allow modification of Strings

On 1/29/19 4:37 AM, Nanday Dan wrote: I added the variable to FakeString. But still application crashes. Sure, unless you also fixed the Rust interop issue. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Does mozilla allow modification of Strings

On 1/28/19 7:51 AM, edusubscr...@gmail.com wrote: Building was successful. I'm really surprised the static assert at https://searchfox.org/mozilla-central/rev/4faab2f1b697827b93e16cb798b22b197e5235c9/dom/bindings/FakeString.h#146-147 did not trigger, given the changes you described...

Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

On 1/14/19 9:09 PM, fantasai wrote: I have no idea why I did that. Fixed. Thank you! Yes, the spec reflects general consensus, and has been explicitly cleared for shipping by the CSSWG (as of several years). See issue at the bottom of the intro:   https://www.w3.org/TR/css-logical-1/#intro

Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

On 1/14/19 12:58 PM, Mats Palmgren wrote: Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline Two quick questions on the spec: 1) 'padding-block-start' is defined as: Value: <‘padding-top’> while 'padding-block' is defined as: Value: <‘padding-left’>{1,2}

Re: Intent to ship: TextEncoder.encodeInto() - UTF-8 encode into caller-provided buffer

On 1/14/19 4:28 AM, Henri Sivonen wrote: This is now an "intent to ship". The feature landed in the spec, in WPT and in Gecko (targeting 66 release). Where do other browsers stand on this feature, do you know? -Boris ___ dev-platform mailing list

Re: XPCOM Tidying Proposal

On 1/10/19 6:15 PM, Kyle Machulis wrote: - Removal of [noscript] methods in interfaces in favor of direct calls via Cast() where possible. This seems generally reasonably, though I'd like to put in a bit of a vote for the pattern I recently used for nsIPrincipal::IsSystemPrincipal, which

Intent to implement and ship: forced case-sensitive attribute selector matching

Summary: When matching CSS attribute selectors against HTML, some attribute names lead to case-sensitive value matching, while others use ASCII-case-insensitive matching. The proposed feature adds an 's' flag on attribute selectors that forces case-sensitive matching, just like the existing

Re: The upcoming C/C++ coding style change

On 11/29/18 11:40 AM, Ehsan Akhgari wrote: Yes, that is true sadly. But to be fair here, old mq patches that do not apply due to age are already beyond saving with any kind of automated tooling, and they require manual work to get them applied first. :-/ Sure. That's not true.

Re: The upcoming C/C++ coding style change

On 11/29/18 11:40 AM, Ehsan Akhgari wrote: Yes, that is true sadly. But to be fair here, old mq patches that do not apply due to age are already beyond saving with any kind of automated tooling, and they require manual work to get them applied first. :-/ Sure. That's not true.

Re: The upcoming C/C++ coding style change

On 11/29/18 11:12 AM, Ehsan Akhgari wrote: * Pull from a pre-reformat of the tree, run ./mach bootstrap to install hg-formatsource. * Do a one-time translation of your mq queue to a set of commits. * Pull from hg.mozilla.org to pick up the reformat commit. * Do a one-time translation

Re: The upcoming C/C++ coding style change

On 11/29/18 7:38 AM, Sylvestre Ledru wrote: This extension will automatically rebase the local changes to avoid conflicts. Sylvestre, Will it also update mq patches, or just in-repo commits? -Boris ___ dev-platform mailing list

Re: Rationalising Linux audio backend support

On 11/24/18 6:35 AM, susa...@gmail.com wrote: It is strange to hear "we are misserable impotent at ALSA" from Mozilla devs... Well, anyway, 2 years after your decision - how is feeling each time alsa-only user courses you? Enjoy! I'm sorry to have to say this, but the post above fails to

Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

On 11/22/18 1:06 AM, Ehsan Akhgari wrote: Can one do noreferrer with window.open()? Yes, by passing 'noopener' in the features argument: https://html.spec.whatwg.org/multipage/window-object.html#apis-for-creating-and-navigating-browsing-contexts-by-name:disowned-its-opener But we're trying

Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

On 11/21/18 11:50 PM, Ehsan Akhgari wrote: Would it be OK if the answer to that question be "use window.open()"? Can one do noreferrer with window.open()? Also, if your thing doing the navigation is a , not , then window.open is pretty hard to use for that. Then again, target="_blank"> is

Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

On 11/21/18 2:22 PM, Daniel Veditz wrote: "opener" doesn't exist It does in WebKit's proposed changes and in our implementation of them. You'd specify a target name other than "_blank" to indicate it's a context you care about This seems backwards. What matters is whether the context

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

On 11/20/18 9:19 AM, Anne van Kesteren wrote: Similar, e.g., https://bugs.chromium.org/p/chromium/issues/detail?id=872772. Doesn't seem like a high priority for anyone to fix. Well... If: 1) All the browsers agree here (do they?) 2) There are concerns that there may be sites depending on the

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

On 11/20/18 8:55 AM, Honza Bambas wrote: because comma can be contained in a single header value (against what the spec says).  We can't correctly separate the headers by commas, potentially even opening security holes if we do that blindly. Do we know what other UAs do here? -Boris

Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

On 11/19/18 5:07 PM, john.biel...@googlemail.com wrote: WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic realm="Newcastle" I expect this would work if you sent it as: WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle" WWW-Authenticate: Basic realm="Newcastle" Yes, per

Re: Intent to implement: Reporting API

On 11/15/18 4:17 PM, Andrea Marchesini wrote: I think we should implement this API for these reasons: OK. I guess we should keep an eye on the privacy implications, but otherwise probably fine to go ahead. -Boris ___ dev-platform mailing list

Re: Intent to implement: Reporting API

On 11/15/18 9:52 AM, Ehsan Akhgari wrote: The idea is to use Feature Policy in report-only mode There is no report-only mode in the Feature Policy spec, nor in our implementation. See the note at the end of https://wicg.github.io/feature-policy/#reporting So I'm back to my question: is

Re: Intent to implement: Reporting API

On 11/13/18 4:33 AM, Andrea Marchesini wrote: I decided to implement this API, because it is required in the web-platform-tests for FeaturePolicy. Is it needed for any other reason? If not, this seems like a bug in the tests: they should not be coupling the two specs together. -Boris

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

Re: PSA: searchfox now indexing Windows Rust/C++ code

On 11/2/18 11:32 AM, Kartikaya Gupta wrote: Those of you working in Windows-only Rust and C++ code will probably be happy to hear that as of today searchfox is indexing the Windows-only bits of our codebase as well. This is awesome. Thank you! -Boris

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

On 10/19/18 8:42 AM, Philip Jägenstedt wrote: That's a bit odd, the is in the markup and would be when running manually or under automation. Are you sure that explains the difference? Yes. I filed https://github.com/web-platform-tests/wpt/issues/13625 -Boris

Re: Intent to implement: Dynamic module imports (JS 'import()' syntax)

On 10/18/18 10:45 AM, Jon Coppeard wrote: DevTools bug: I don't know whether there is DevTools work to do here or not.. I can think of several devtools things that would be nice to have: 1) A log of which modules got loaded (and when?) 2) Ability to break in a module once it gets loaded but

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

On 10/13/18 3:27 AM, Philip Jägenstedt wrote: Fiddling with these rules can reveal lots more potential issues, and if you like I could provide reports on that too. I would be pretty interested in that, yes. In particular, a report where there is 1 "not PASS and not FAIL" and 3 "PASS" would

Re: Intent to implement and ship: HTMLMarqueeElement

On 10/12/18 1:56 PM, Brian Grinstead wrote: Summary: Motion is a key component of modern web design, and is the premier... Fire. The premier fire so we can have fire and motion [1]. Or maybe it's just a dumpster fire? ;) The proposed change looks great to me. -Boris [1]

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1498357 to track these failures. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

On 10/11/18 4:22 PM, Philip Jägenstedt wrote: https://gist.github.com/foolip/a77c88e62aa3cfc461c2879f3e5d4855 is a list of tests that fail in Firefox Nightly, but pass in stable versions of Chrome, Edge and Safari. Or more precisely have some sub-test that has that property, right? Thank you

Re: Intent to implement and ship: WebP image support

On 10/11/18 11:43 AM, Andrew Osmond wrote: We are facing a growing number of webcompat reports against our Gecko-derived Android offerings, where web developers assume Android and/or mobile implies support for WebP. In the past, I believe we objected to adding WebP for various reasons. Do we

  1   2   3   4   5   6   7   8   9   10   >