id2webidl

Hi all, this is my first email here. wow. I'm writing this email because I spent several months converting IDL components to WebIDL. It's hard to find how many components have been converted, what is still missing, etc, etc. So I wrote this:

New Promise Constructor

Hi all, I just want to inform that I'm landing a patch that changes the DOM Promise constructor. DOM Promise is disabled by pref but I know that there are a few existing pieces of code that already use them. The old constructor was based the PromiseResolver object. Now we get rid of this

style guide proposal

Hi, Writing a patch for bug 949488 I had to indent this piece of code: nsIScriptSecurityManager* ssm = nsContentUtils::GetSecurityManager(); if (NS_WARN_IF(NS_FAILED(ssm-GetSimpleCodebasePrincipal( originURI,

Intent to implement: BroadcastChannel API

Summary: (from the spec) Pages on a single origin opened by the same user in the same user agent but in different unrelated browsing contexts sometimes need to send notifications to each other, for example hey, the user logged in over here, check your credentials again. For elaborate cases,

Re: Intent to implement: BroadcastChannel API

My implementation supports sending blobs. However, the API is still disabled by pref. - Original Message - From: Jonas Sicking jo...@sicking.cc To: Andrea Marchesini amarches...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Wednesday, September 24, 2014 5:49:21 PM

Intent to implement and ship: User timing API in workers

Summary: user timing API in workers. We already have this API exposed to main-thread content but it's nice to have it also in workers, shared workers and service workers. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1155761 https://bugzilla.mozilla.org/show_bug.cgi?id=1158032 Link to

Re: Intent to implement and ship: User timing API in workers

Zbarsky bzbar...@mit.edu wrote: On 5/20/15 1:16 PM, Andrea Marchesini wrote: Link to standard: http://www.w3.org/TR/user-timing/ This standard does not define this API in workers. Have you reached out to the working group already? -Boris

StructuredCloneHelper

Hi all, In these days I landed quite a few patches to replace the use of JSAutoStructuredCloneBuffer with something "better": StructuredCloneHelper. First of all, the reasons why I did it, are: 1. we had many postMessage() methods fully out of sync in terms of which clonable/transferable

Re: StructuredCloneHelper

his stuff manually in ExportHelpers.cpp? > > On Fri, Sep 4, 2015 at 1:12 AM, Andrea Marchesini <amarches...@mozilla.com > > wrote: > >> Hi all, >> >> In these days I landed quite a few patches to replace the use of >> JSAutoStructuredCloneBuffer with some

about:profiles and the new profile manager

Hi all, This week I landed a set of patches to introduce 'about:profiles'. This page shows the list of existing profiles and gives the possibility to create new ones, delete them, rename them, change the default one. I wanted to work on this feature because I think having multiple profiles and

Re: about:profiles and the new profile manager

Hi Stephen, Can you tell us some more about next phases of this work before it would go > into the product? > Mainly fixing regressions and improving the usability. > Have you consulted anyone from the Firefox front-end or Firefox UX team > about this already? > Jeff Griffiths, but there is

Re: about:profiles and the new profile manager

> Also @Andrea are we going to change how profiles.ini is used? > > Hi, no, I'm not going to. Thanks I hope I can work closely with you here. > > Why not! I just want to receive more feedback about what we want to achieve from a UX point of view before changing the existing code. b

Re: Nightly Only Containers Feature

We use dom::security for any containers-related bug. Plus we have a meta bug: 1191418 Cheers, b On Mon, Jun 20, 2016 at 1:43 PM, Dirkjan Ochtman wrote: > On Thu, Jun 16, 2016 at 12:42 PM, Tanvi Vyas wrote: > > If this capability interests you, please try

Re: about:profiles and the new profile manager

Hey all, I filed this last week, but didn't assign it. I've been unable to > open nightly at all since the new profile manager launched. > > Hi John, I asked your a question on bugzilla. Can you take a look? Thanks. If you prefer we can talk on IRC. My nick name is 'baku'. bye b

No more custom worker WebIDL bindings

I want to inform that, the porting the last WebIDL interfaces using custom worker binding, is finished. URL and XMLHttpRequest APIs have been 'rewritten' in order to use the standard codegen output. Next step will be to simplify the WebIDL codegen.py removing all the custom 'worker' support. b

Re: about:profiles and the new profile manager

This is awesome! What about if you file a bug and you CC/NI me and :bram? We can continue the discussion on bugzilla. Thanks! b On Tue, Feb 9, 2016 at 3:36 AM, <noitid...@gmail.com> wrote: > On Monday, January 25, 2016 at 11:50:11 PM UTC-8, Andrea Marchesini wrote: > > Hi, I rever

Re: Intent to ship: Directory picking and directory drag-and-drop

I'm working on this. From an implementation point of view, we have almost everything done and behind pref. There are still some patches to review but it should not take too long. The only missing piece is to change form submission but I should be able to finish it for the next week. More

Intent to implement and ship: URLSearchParams from array or object

Summary: URLSearchParams constructor is changed in the latest URL spec. Now it's possible to create URLSearchParams objects starting from a string, an array and from an object. Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1330678

Intent to unship: WorkerGlobalScope.onclose

I'm planning to remove |partial interface WorkerGlobalScope { attribute EventHandler onclose; }|. This EventHandler has been in our code base since ever but it's not part of the Workers spec and no other browses implement it. In order to be compliant the spec, it's time to get rid of this. Any

Intent to ship: NetworkInformation

Our implementation of the NetworkInformation interface does not follow the latest version of the spec. I'm planning to work on it. Then, I would like to enable this interface by default - currently it's behind pref. Related Bugs: worker implementation:

Report about the NetworkInformation meeting

Today we had a meeting about the next steps for NetworkInformation API. The results of this meeting are: 1. we want to keep what we have in m-c. It means NetworkInformation enabled on fennec, main-thread and workers. It stays disabled on desktop. 2. we need more data about the usage and the

Re: Intent to Experiment: CSS Houdini Paint API Level 1

On Fri, Jan 6, 2017 at 9:19 PM, Boris Zbarsky wrote: > On 1/6/17 2:34 PM, Bill McCloskey wrote: > >> Are in-thread worklets a thing? >> > > Unclear. > Right. So far, I'm concentrating on having Worklet able to run out of main-thread. My goal is to have something ready for

intent to implement/ship: MediaQueryListEvent

Spec: https://drafts.csswg.org/cssom-view/#mediaquerylist and https://drafts.csswg.org/cssom-view/#mediaquerylistevent Summary: MediaQueryList interface has changed in the spec. I just landed (without sending this email before doing it) a patch that introduces such changes. Bug:

Re: Enabling filesystem read-restrictions for content process sandbox

There are some APIs able to read files in the content process using nsFileInputStream: FileReader is one of them. The file is opened on the parent process (because of a FilePicker, or Entries API), the file descriptor is sent to the content process where the reading happens. Is this supported yet?

Re: PBlob refactoring landed

I forgot to say that there is a meta bug for this PBlob refactoring: bug 1353629. On Wed, Apr 26, 2017 at 9:13 AM, Andrea Marchesini <amarches...@mozilla.com> wrote: > Hi all, > > In the last month I have worked on the refactoring of PBlob code and today > I'm very e

PBlob refactoring landed

Hi all, In the last month I have worked on the refactoring of PBlob code and today I'm very excited to announce that the first block of patches (20~) is finally in nightly. Everywhere in gecko, PBlob has been converted to IPCBlob, except for 2 components: FileHandle and IndexedDb. The former has

Re: Intent to ship: Abort API

:25 PM, Ben Kelly <bke...@mozilla.com> wrote: > On Tue, Aug 29, 2017 at 9:39 AM, Ben Kelly <bke...@mozilla.com> wrote: > >> On Tue, Aug 29, 2017 at 2:05 AM, Andrea Marchesini < >> amarches...@mozilla.com> wrote: >> >>> Abort API is alre

Intent to ship: Abort API

Standards: https://dom.spec.whatwg.org/#aborting-ongoing-activities https://github.com/whatwg/fetch/pull/523 Summary: In bug 1378342 I have been working on Abort API and its integration with Fetch API. There are 2 separate prefs: dom.abortController.enabled and dom.abortController.fetch.enabled

Re: Still-supported cases of out-of-tree XPCOM code?

> > My understanding is that the change in question here was not backed > out due to the extension being broken, and that should continue to be > the case. I'd love to be corrected here if I have this wrong! > You are right. Removing nsIJSON interface I broke ContextualIdentityService.jsm and

Re: All about Prefs

DOMPreferences was introduced (but it's not landed yet because of some mochitest failures) to cleanup how preferences are managed by workers. Preferences getters/setters are main-thread only and, currently, in order to propagate a white-list of prefs [1], we have to dispatch runnables to any

Re: Still-supported cases of out-of-tree XPCOM code?

Containers is not a 'normal' addon. It's an hybrid addon signed with the mozilla key and in its install.rdf it has hasEmbeddedWebExtension tag set to true. This means that it has and it executes bootstrap.js with chrome privileges. bootstrap.js is needed for FF versions <56: a couple of

nsIClearDataService

Hi all, As probably many of you remember, in the past we had several issues with deleting site data. The main reason was that we have too many ways to delete data and they were/are out of sync: ForgetAboutSite, Sanitizer.jsm for android, Sanitizer.jsm for desktop, etc (some data is deleted by

Intent to unship: File.lastModifiedDate

This attribute is not part of the FileAPI spec and it has been marked as deprecated in bug 1048291 the 31st of May 2016. It's currently used by the 0.01% of the pages:

'workers' namespace removed

I'm doing an important cleanup of the worker code and I have some points to share: . 'workers' namespace is (mainly - bug 1435174) gone. SharedWorker, WorkerPrivate, WorkerRunnable, and so on, are now part of 'mozilla::dom' namespace. . no needs to do LIBS+['workers'] in moz.build if you want to

Intent to implement: Clear-Site-Data header

Summary: The Clear-Site-Data header allows a secure origin to send a header requesting the deletion of its own browsing data. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1268889 Link to standard: https://w3c.github.io/webappsec-clear-site-data/ Platform coverage: all Estimated or

Re: Intent to implement: Clear-Site-Data header

Right, I saw bug 1479519. I'm going to implement some WPTs to cover that part of the spec. On Mon, Jul 30, 2018 at 9:39 PM, Boris Zbarsky wrote: > On 6/20/18 9:14 AM, Andrea Marchesini wrote: > >> Do other browser engines implement this? >> Shipped in Chrome 61. &g

Intent to ship: Clear-Site-Data header

I intend to turn Clear-Site-Data header on by default in 63. The last remaining dependency bug is going to land today; we pass all the WPTs. It has been developed behind the dom.clearSiteData.enabled preference. Chrome has this feature enabled since 06-2017. Bug to turn on by default: bug

WorkerRef classes

Hi all, I want to introduce a new way to deal with Web Workers that makes their lifetime management easier to understand and to use. In bug 1436784 I implemented a ref-counting approach for Web Workers. This is meant to replace WorkerHolder and WorkerPrivate raw pointers. If you want to play

Intent to unship: URL.createObjectURL(MediaStream)

Per spec ( https://w3c.github.io/mediacapture-main/ ), this was removed in 2013. I introduced a deprecated message in bug 1334564, the 7th, February 2017. I think it's time to remove this method completely. I wrote the patch in bug 1454889. About other browsers: . chrome has a deprecated

Intent to implement: Reporting API

*Summary*: Reporting API allows the page to receive notifications such as the usage of deprecated APIs and FeaturePolicy violations. I decided to implement this API, because it is required in the web-platform-tests for FeaturePolicy. Reporting API covers 2 different features: a. reporting to the

Re: Intent to implement: Reporting API

There is a proposal to support "report-only" violations for feature policy: https://github.com/WICG/feature-policy/blob/824de86f89599240c24b5ae3cd58d25984446af5/reporting.md I think we should implement this API for these reasons: a. it unifies the reporting of violations and interventions. At

Re: Intent to implement: Reporting API

> 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. > Well, in this way, these 2 APIs can test each other: we could use deprecated APIs to check ReportingObserver notifications, but there is not a common set of

Re: Cookie policy/permission in live documents - proposal

> You pointed out one case of unpredictable behaviour: a website's logic > cannot preserve assumptions across the entire duration of it's JS execution > context. But if we don't apply the policy instantly, isn't the reverse > situation also possible? With my proposal, you will have 2 tabs,

Cookie policy/permission in live documents - proposal

Hi all, When the cookie policy or a cookie permission changes, firefox applies the new behavior to any existing documents immediately. I would like to change this, applying the new behavior to new documents only. Let's start with an introduction. When I say cookies, I mean cookies, localStorage,

Intent to unship: x-moz-errormessage attribute

x-moz-errormessage attribute can be used to have a custom error message when validating a form field. This is a mozilla-only attribute which was rejected in 2010 by w3: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10923 Currently, a similar message can be set using setCustomValidity() method:

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

*Summary*: WebKit is experimenting an interesting feature: target=_blank on anchor and area elements implies ref=noopener. https://trac.webkit.org/changeset/237144/webkit/ *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1503681 *Link to standard*: https://github.com/whatwg/html/issues/4078

Re: Intent to implement: report-to header as part of Reporting API

/reporting/tests On Thu, Jan 10, 2019 at 1:38 PM David Burns wrote: > > > On Thu, 10 Jan 2019 at 12:27, Andrea Marchesini > wrote: > >> web-platform-tests: just a little support. I wrote several mochitests >> which >> can be converted to WPTs with a bit of

Intent to implement: report-to header as part of Reporting API

Summary: Reporting API offers 2 ways to obtain reports: ReportingObserver and Report-to Header. I implemented ReportingObserver months ago and I sent a separate intent-to-implement email about it. This email is about "report-to" header, which allows a server to specify a set of endpoints to

Re: Intent to implement: report-to header as part of Reporting API

> > > Sorry for my laziness not having scanned through the links below to find > the answer to this question, but how does this interact with the > same-origin policy, if at all? And if it does, is enabling it in sandbox > iframes without the allow-same-origin token the right thing to do? > It's

Intent to implement: Feature Policy

Summary: FeaturePolicy spec allows developers to enable or disable features (browser features ad APIs) for their website and for 3rd party contexts. FeaturePolicy consists in 3 mayor parts: * a HTTP header with the policy, similar to CSP header * an 'allowed' attribute for HTMLIFrameElements to

Re: Cookie policy/permission in live documents - proposal

On Fri, Jan 25, 2019 at 8:50 PM Daniel Veditz wrote: > > Your description equating cookies and storage within a document lifetime > makes sense. Is this intended to also apply to network requests? The > first-party document already has no access to 3rd party cookies so it > shouldn't matter at

Re: CookieSettings

> > > And, just to clarify, CookieSettings is not for use in browser front-end > code, right? So, about:preferences for example would still continue to flip > prefs and CookieSettings would reflect those prefs per document? > > Correct. ___ dev-platform

CookieSettings

Since the beginning of this week, we have CookieSettings in our codebase. CookieSettings is a snapshot of cookie policy and cookie permissions in a precise moment of time. This object is used by top-level documents to have a consistent cookie configuration also in case the user changes it. New

Re: Cookie policy/permission in live documents - proposal

> > Presumably if there is an opener relationship between the tabs, things > might be a little odd, because you can postMessage, but not use > localStorage. So I don't think that this is exactly like private-normal > browsing. > > Yes. This is right. But I don't think we should block

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

I intend to turn "implicit ref=noopener for anchor and area elements for target=_blank" on by default in 67. It has been developed behind the "dom.targetBlankNoOpener.enabled" preference and enabled in nightly for ~2 cycles (it landed in FF65). Safari has already shipped this feature:

Re: Cookie policy/permission in live documents - proposal

On Fri, Jan 25, 2019 at 11:55 PM Ehsan Akhgari wrote: > On Fri, Jan 25, 2019 at 2:51 PM Daniel Veditz wrote: > >> >> Your description equating cookies and storage within a document lifetime >> makes sense. Is this intended to also apply to network requests? The >> first-party document already

Implementing a new tracking blocking mechanism using a separate nsIPrincipal for cookie jar access: StoragePrincipal

Since Firefox 66, the anti-tracking project has been working on strategies to protect users against trackers. One of the solutions is the ‘cookie blocking for 3rd party trackers’. This is currently done denying 3rd party trackers access to their cookie jar (no cookies sent/received, no

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

Summary: implement and ship 3 new methods to read Blob contents: blob.text(), blob.arrayBuffer() and blob.stream(). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1557121 Link to standard: https://w3c.github.io/FileAPI https://github.com/w3c/FileAPI/pull/117 Platform coverage: all.

Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

Link to the proposal: https://tools.ietf.org/html/draft-west-cookie-incrementalism-00 Summary: "1. Treat the lack of an explicit "SameSite" attribute as "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will produce a cookie equivalent to "key=value; SameSite=Lax".

Re: Cookies are no longer stored by nsIHttpChannel?

The issue is about the use of nsICookieSettings. If you create a channel without an associated document, by default, we create a new nsICookieSettings which blocks cookies. The idea behind this decision is that chrome code, by default should not send/receive cookies. A good description of what

Re: Cookies are no longer stored by nsIHttpChannel?

Yes, nsiCookieSettings landed in FF67. And it's in ESR68: https://hg.mozilla.org/releases/mozilla-esr68/file/tip/netwerk/cookie/nsICookieSettings.idl What blocks your cookies is probably this: https://hg.mozilla.org/releases/mozilla-esr68/file/tip/netwerk/base/LoadInfo.cpp#l754 On Tue, Sep 17,

Re: Cookies are no longer stored by nsIHttpChannel?

> You said you would like to move this discussione to IRC, where can I find > you? > > Yes, let's continue this discussion on IRC. My nickname is "baku". Thanks for your help! > np ___ dev-platform mailing list dev-platform@lists.mozilla.org

Intent to prototype: cookie behavior "reject foreign" with storageAccess API and heuristic exceptions

Hi everyone, tl;dr; If you block all third-party cookies in Nightly, you're going to experience a slight change in behavior; Firefox will automatically unblock some third-party storage access based on gecko’s internal heuristics [0] and requests to the Storage Access API [1]. Summary: In

Intent to Prototype: Schemeful Cookie Same-Site

Summary: Modify the definition of same-site for cookies such that requests on the same registrable domain but across schemes are considered cross-site instead of same-site. E.g., http://site.example and https://site.example