Intent to Prototype: Schemeful Cookie Same-Site

[Andrea Marchesini]

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 will now be considered
cross-site to each other. (Helpfully copied from a similar blink-dev email)

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1638358

Standard:
https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html#rfc.section.3.3

Platform coverage: all

Preference: network.cookie.sameSite.schemeful - this pref is set to true in
nightly and early beta to see the level of breakage.

DevTools: no extra work is required for devtools. A console message is
shown when a cookie is not shared/sent because of the schemeful comparison.

Other browsers:
- Chrome intent to prototype:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qB7DKqxkiaA
- Safari: no signal, yet.

web-platform-tests: no WPTs yet. I wrote a few xpcshell to test the cookie
DB migration and the sameSite comparison with and without schemeful, but no
WPTs have been implemented yet.

Mozilla standards position:
https://github.com/mozilla/standards-positions/issues/260
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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 Firefox, we call the policies to accept or deny cookies and
other storage APIs (indexedDB, localStorage, and so on) “cookie behaviors”.
Firefox implements several cookie behaviors, detailed below [2]. Before
Enhanced Tracking Protection (ETP), the default behavior was “0”
(BEHAVIOR_ACCEPT) -- everything was allowed by default. With the launch of
ETP last fall, the default cookie behavior became “4”
(BEHAVIOR_REJECT_TRACKER) - we deny the use of cookies and storage APIs for
any 3rd party contexts classified as trackers [3].

In order to prevent login and other flows from breaking, we added some
exceptions to cookie and storage blocking.  For example, if the website
called the Storage Access API [1] to request storage access or if the user
went through a flow that looked like a login, we would allow the
third-party cookie and storage access [0].

We also have a stricter cookie behavior “1” (BEHAVIOR_REJECT_FOREIGN) that
blocks all third-party cookies and storage, regardless of whether or not
Disconnect has classified the third party as a tracker.  We’ve seen this
setting cause breakage in the past. We’d like to see if the heuristic
exceptions we use in our tracking cookie blocking [0] will fix that
breakage.

We’ve added a new pref network.cookie.rejectForeignWithExceptions.enabled
to enable the cookie blocking exceptions for cookie behavior “1” so that we
can test the web compatibility effects of blocking all third-party cookies
when there are exceptions.  The pref will be enabled by default in Nightly
only. This means that if you have all third party cookies blocked in
Nightly, you may sometimes receive third-party cookies if you trigger
Gecko’s internal heuristics or the Storage Access API is called by the
website.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1625568

Preference: network.cookie.rejectForeignWithExceptions.enabled enables the
feature. It’s set to true on Nightly only.

Other browsers: Safari implemented and just released a similar feature by
default [4].  Safari blocks all third-party cookies and provides similar
heuristic exceptions and storage access API support.  Note that Safari
double keys other storage mechanisms, so the implementations are different.

--

[0]
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#Storage_access_grants


[1] https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API

[2]
https://searchfox.org/mozilla-central/rev/4ccefc3181f9d237ef4ca8bd17b4e7c101ddf7b5/netwerk/cookie/nsICookieService.idl#71-82

   - “0” (BEHAVIOR_ACCEPT) - accept all cookies
   - “1” (BEHAVIOR_REJECT_FOREIGN) - any 3rd party context doesn’t
   receive/send cookies and it’s unable to use storage APIs.
   - “2” (BEHAVIOR_REJECT) - cookies and storage APIs are disabled
   everywhere
   - “3” (BEHAVIOR_LIMIT_FOREIGN) - unknown 3rd party contexts do not
   receive/send cookies and they are unable to use storage APIs
   - "4” (BEHAVIOR_REJECT_TRACKER) - to simplify, we deny the use of
   cookies and storage APIs for any 3rd party contexts classified as trackers
   [3].
   - “5” (BEHAVIOR_REJECT_TRACKER_AND_PARTITION_FOREIGN) - it’s ETP, plus,
   dFPI (dynamic first-party isolation) for third-party contexts. This cookie
   policy is not yet exposed and is under active development.

[3]
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy

[4] https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cookies are no longer stored by nsIHttpChannel?

[Andrea Marchesini]

> 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
https://lists.mozilla.org/listinfo/dev-platform

Re: Cookies are no longer stored by nsIHttpChannel?

[Andrea Marchesini]

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, 2019 at 10:35 AM john.bieling--- via dev-platform <
dev-platform@lists.mozilla.org> wrote:

> Hi Andrea,
>
> I was already going thru that CookieSettings docuemnt, but are you sure
> that is alreadfy in the ESR68 branch? I tried to access
> loadInfo.cookieSettings and got back an error.
>
> Where can I find you on IRC? Which channel/nick?
> ___
> 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: Cookies are no longer stored by nsIHttpChannel?

[Andrea Marchesini]

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 nsICookieSettings is can
be found here:
https://searchfox.org/mozilla-central/rev/7ed8e2d3d1d7a1464ba42763a33fd2e60efcaedc/netwerk/cookie/CookieSettings.h#20

About your particular use-case, there are 3 ways to proceed:
1. create and set a cookieSettings object in the loadInfo of your channel
before calling asyncOpen()/open(). - hard to do because CookieSettings
cannot be created from JS yet.
2. create a channel from a document/worker. - recommended!
3. disable the cookieSettings block: see pref
network.cookieSettings.unblocked_for_testing - you don't want this!

We can move this discussion on slack/bugzilla/irc.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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.

Estimated or target release: 69

Preference behind which this will be implemented: none.

Do other browser engines implement this?
Chrome has already shipped these methods. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=945893
Safari hasn't started to work on them yet. See:
https://bugs.webkit.org/show_bug.cgi?id=196258

web-platform-tests: We have existing WPTs. See:
https://github.com/web-platform-tests/wpt/blob/master/FileAPI/blob

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: Cookie SameSite=lax by default and SameSite=none only if secure

[Andrea Marchesini]

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".
   Cookies that require cross-site delivery can explicitly opt-into
   such behavior by asserting "SameSite=None" when creating a
   cookie.
   2.  Require the "Secure" attribute to be set for any cookie which
   asserts "SameSite=None" (similar conceptually to the behavior for
   the "__Secure-" prefix).  That is, the "Set-Cookie" value
   "key=value; SameSite=None; Secure" will be accepted, while
   "key=value; SameSite=None" will be rejected."

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798

Platform coverage: all

Estimated or target release: 69 - behind pref

Preferences behind which this will be implemented:
 - network.cookie.sameSite.laxByDefault
 - network.cookie.sameSite.noneRequiresSecure (this requires the previous
one to be set to true)

Is this feature enabled by default in sandboxed iframes? yes.

Do other browser engines implement this?
 - Chrome is implementing/experimenting this feature:
https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
 - Safari: no signal yet.

web-platform-tests: There is a pull-request
https://github.com/web-platform-tests/wpt/pull/16957
Implementing this feature, I added a mochitest to inspect cookies via
CookieManager.

Is this feature restricted to secure contexts? no
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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
localStorage, IndexedDB, BroadcastChannel, etc).

As experience has shown blocking is not always the best path forward
because blocking of legitimate requests breaks current web architecture.
Hence, instead of blocking, we would like our tracking algorithm to be
smarter and hence we would like to partition the cookie jar.

To that end bug 1536411 decouples the nsIPrincipal to be used for the
cookie jar and the nsIPrincipal to be used for anything else (networking,
window and workers communications, and so on).

The nsIPrincipal for the cookie jar is now called ‘StoragePrincipal’ and it
can be obtained from the Document, from the WorkerPrivate, or from the
nsIScriptObjectPrincipal and it can be created from an nsIChannel by
nsIScriptSecurityManager::getChannelResultStoragePrincipal().

Normally, these getters return the regular nsIPrincipal of the resource. If
the  nsIChannel is classified by the URL-Classifier as a 3rd party tracking
resource then its StoragePrincipal will be a modified nsIPrincipal - which
is the ‘regular’ nsIPrincipal plus “First Party Isolation” (FPI) - See
below the differences between FPI and StoragePrincipal. More technical, its
OriginAttributes.firstPartyDomain attribute within the nsIPrincipal will be
set to the top-level domain. When a document is loaded, it takes the
StoragePrincipal by its nsIChannel and it propagates it to any storage API,
worker, and so on. Because of this, tracking resources will use a
partitioned cookie jar, unique for their origins, in that first-party
domain.

Also SharedWorkers and BroadcastChannels use the StoragePrincipal to
generate their ‘sharing’ keys in order to avoid the communication between
partitioned and non-partitioned contexts.

Everyone interested in reading code comments, I refer the reader to:

https://searchfox.org/mozilla-central/rev/0376cbf447efa16922c550da3bfd783b916e35d3/toolkit/components/antitracking/StoragePrincipalHelper.h#10

When storage access permission is granted (see StorageAccess API [1] or the
anti-tracking heuristic [2]), the StoragePrincipal getters will start
returning the ‘regular’ nsIPrincipal and any storage components exposed to
content, will be reset/recreated: they will behave like the first-party
resource’s one. This behavior is observable to content because, for
instance, the localStorage data before and after the permission will be
different. But, also the current approach [3] is observable to content:
localStorage throws exceptions before, and it works after.

The new storage partitioning mechanism is controlled by the pref:
privacy.storagePrincipal.enabledForTrackers, which is to false by default.

Difference between FPI and StoragePrincipal:

a. With storagePrincipal we have partitioned cookie jars just for tracking
resources. FPI has partitioned cookie jars everywhere, double-keying any
origin.

b. StoragePrincipal doesn’t break window-to-window communications because
the partitioning the partitioning happens at a cookie jar level and it’s
not spread to the ‘regular’ nsIPrincipal.

c. We can ‘revert’ this partitioning when needed (StorageAccess API).

[1] https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API

[2]
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#Storage_access_grants

[3]
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#What_does_the_storage_access_policy_block
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CookieSettings

[Andrea Marchesini]

>
>
> 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 mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

CookieSettings

[Andrea Marchesini]

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
cookie configurations will apply only to new top-level documents.

I wrote a long comment describing how this object is created, used and
propagated:
https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/netwerk/cookie/CookieSettings.h#20-100

CookieSettings has been introduced by bug 1525245 after the discussion
about "Cookie policy/permission in live documents". See
https://groups.google.com/d/msg/mozilla.dev.platform/qO6MserGVmk/vYHcDMdPCgAJ

Please, don't check the cookie behavior pref or cookie permissions directly
but use CookieSettings instead. This is available from Document,
WorkerPrivate and nsILoadInfo.

An interesting aspect of CookieSettings is that is propagated and used
everywhere (as I said, documents, workers and network channels). This makes
it a good candidate to bring more prefs and more permissions into it and,
maybe, change them for specific contexts.  Below I shortly describe 2 ideas:

- change the network settings when the URL-Classifier flags a document's
channel. This would allow us, for instance, to have custom network proxy
configuration for trackers. I have a proof of concept for this idea.
- custom audio settings: origin A is muted by default, origin B has volume
set to 0.5. See:
https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/dom/interfaces/base/nsIDOMWindowUtils.idl#1746-1757

b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cookie policy/permission in live documents - proposal

[Andrea Marchesini]

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 has no access to 3rd party cookies so it
>> shouldn't matter at that level if Necko's rules change "live". If I'm on
>> twitter/facebook (which make constant background requests) and I clear my
>> entire cookie jar those documents are going to break. If I just tossed all
>> my cookies that's what I want! Discovering that I'm still logged into those
>> sites would be disturbing. Similarly, if I flip the "block 3rd-party
>> cookies" pref I'm going to react negatively if I still see tracker cookies
>> showing up just because I've left an active page open somewhere.
>>
>
> Cookies have been dynamic and racey since the dawn of time, both at the
> HTTP layer and in their reflection in DOM (document.cookie).  Clearing your
> cookies isn't something that is changed by this proposal.  I'm not too sure
> how Andrea was planning to handle cookie policy at the Necko layer but we
> have a lot of flexibility here and pages also can probably tolerate dynamic
> changes to document.cookie.  I *think* handling the cookie policy globally
> at the Necko layer is probably easier but I'm curious to know Andrea's
> thoughts.
>

As Ehsan says, I don't want to change how we cleanup cookies but only how
we expose cookie policy and how to treat cookie permissions.
About the implementation, I would store the current cookie policy and
cookie permission into the nsILoadInfo object of a document/subdocument
nsIChannel. This information will be used in nsCookieService,
document.cookies() getter/setter and propagated to any
storage/communication API as described in this email thread (from
BroadcastChannel to localStorage). I also would audit any cookie-permission
check and any cookie-policy preference getter call.

In this way, when the cookie behavior or a cookie permission changes, the
document will not be affected because it has its own 'copy' of the previous
values.
We also need to improve the UI to communicate the the changes will apply at
the next reload of the current tabs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cookie policy/permission in live documents - proposal

[Andrea Marchesini]

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 that level if Necko's rules change "live". If I'm on
> twitter/facebook (which make constant background requests) and I clear my
> entire cookie jar those documents are going to break. If I just tossed all
> my cookies that's what I want! Discovering that I'm still logged into those
> sites would be disturbing. Similarly, if I flip the "block 3rd-party
> cookies" pref I'm going to react negatively if I still see tracker cookies
> showing up just because I've left an active page open somewhere.
>

Denying access to cookies doesn't make the user logged out from a website.
The website can still have tokens in memory and send them to servers, for
example. And also if the website is not able to identify you to the server,
it will probably show the same UI as you were still logged in. This is
extremely confusing. The only way to be sure you are logged out is a full
reload of the opened tabs.

Another good point to accept this proposal is that, when we will have the
StoragePrincipal in place, going from BEHAVIOR_ACCESS to
BEHAVIOR_REJECT_TRACKER would be actually a big problem without reloading
the tabs. If we try to apply the new cookie policy immediately, 3rd party
trackers in opened tabs should switch to a first-party-isolation storage,
but they could also have already data in memory (user-tokens), and populate
the new cookie jar consequentially. This would break the isolation. The
solution in this case, is to apply the change only after the reloading.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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:
https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1522083

This feature was previously discussed in this "intent to implement"
thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intent$20to$20implement$20rel$3D%7Csort:date/mozilla.dev.platform/d4R7WIHSOMY/iHBAH0koCgAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cookie policy/permission in live documents - proposal

[Andrea Marchesini]

>
> 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 postMessage(). Btw,
the same issue can be used as workaround for
document.requestStorageAccess().

I get that this is difficult, but can you talk a bit about what you think
> the driving principles are here?  You mention presenting a consistent
> experience with respect to access to state, which is a fine principle.  If
> we model access to that state as a permission that can be actively
> requested by a site - as per - document.requestStorageAccess - how does
> that fit?  (I confess to not having good kept up with developments on that
> API, so I apologize if this is off the reservation.)
>

requestStorageAccess is part of the Storage API and it's meant to be used
by 3rd party contexts, marked as trackers by the URL-Classifier. We
deliberately block their cookie jar before document.requestStorageAccess()
or before the heuristic. So, trackers are a corner case. We are planning to
create a fully separate cookie jar for them and I'll tell you more at the
end of this email.

I think I described why we should go in the direction of my proposal, in
particular for normal websites: performance; less code complexity;
consistency in APIs.
I would like to add a couple of reasons more:

- security/privacy/bugs: at the moment, many APIs are not able to deal with
changes in cookie permission/policy: after the changes, they behave as
before. This is definitely a bug, but it's also true that it's hard to
support these changes correctly and consistently. I would say:
security/privacy because each 'broken' API can be used to workaround the
new cookie policy - at least until the page is reloaded.

- cookie permission vs other permissions: Let me compare geolocation and
cookie permissions: geolocation is strongly connected with 1 API and its
setting is usually triggered by that API (the user must accept it via
permission prompt, of course). The API knows that, in order to have geo
data, it must ask for it, and it must handle a possible rejection. The
workflow is: asking, permission granted or denied (callback-based, or
promise-based). This is a different model compared with cookie policy.
Cookie policy is a kind-of internal browser setting which should not be
exposed to webpages when changing. Cookie permission is a way to implement
exceptions on top of the cookie policy. We should not treat the cookie
policy as a normal permission setting.

For the anti-tracking project, we are planning to introduce the concept of
'StoragePrincipal' (Q2?). The details are not finalized yet, but here is
the rough idea: a StoragePrincipal is, for non-tracker documents, equal to
the document's origin, which, in gecko-world, is called the NodePrincipal
(nsIPrincipal interface). For trackers, before having the storage access
permission granted, StoragePrincipal will be the NodePrincipal plus
first-party-isolation. This means that trackers will have a separate cookie
jar, double-keyed with the top-level origin: same tracker, as 3rd party on
different websites, will have separate cookie jars. We want to use
StoragePrincipal everywhere we give access to the cookie jar, such as
storage APIs, network/image cache and messaging APIs (BroadcastChannel,
Reporting API and so on).
When the storage access permission is granted (by the heuristic or by the
Storage Access API), we reset the StoragePrincipal to be equal to the
NodePrincipal and we recreate sessionStorage, localStorage and so on. At
this point, the tracker will have access to its first-party cookie jar.

There are several comments to do here:
- localStorage objects (or any other storage API) before and after the
permission granted will be different and, both will work after, but
pointing to different cookie jars.
- postMessages between window will work as it does today, because it will
use the NodePrincipal, and not the StoragePrincipal.

I suspect that all of this is out of topic. StoragePrincipal has been
discussed during several anti-tracking meeting and with during the last
All-Hands too. If interested I can send a separate email when we will have
a concrete plan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cookie policy/permission in live documents - proposal

[Andrea Marchesini]

> 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, loading the same origin with 2
different cookie behaviors.
Let's assume that one is BEHAVIOR_ACCEPT and the other one BEHAVIOR_REJECT,
doesn't matter the order.
The 2 tabs will not be able to communicate to each other because:

- we don't dispatch storage events, and/or they will not considered by the
other tab.
- sessionStorage, localStorage, indexedDB, ... let's say storage APIs throw
exceptions in the tab with BEHAVIOR_REJECT policy.
- that tab will not be able to use APIs such as SharedWorkers, or
BroadcastChannels.

In general, we allow tab communication only if they have both
BEHAVIOR_ACCEPT cookie policy (or the corresponding permission:
ACCEPT_ALLOW).

Note that what I'm describing here already exists for private browsing
contexts which are unable to talk with same origins in normal contexts.

b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Cookie policy/permission in live documents - proposal

[Andrea Marchesini]

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, sessionStorage, indexedDB and so on: anything that composes
the cookie jar of a website (origin).

The user, in firefox, can choose between several cookie policies: They are:
- nsICookieService::BEHAVIOR_ACCEPT - the default one in release. Any
cookie is accept.
- nsICookieService::BEHAVIOR_REJECT - all rejected.
- nsICookieService::BEHAVIOR_REJECT_FOREIGN - 3rd party context's cookies
rejected.
- nsICookieService::BEHAVIOR_LIMIT_FOREIGN - 3rd part context's cookies
rejected if that origin has not been visited previously.
- nsICookieService::BEHAVIOR_REJECT_TRACKER - by default in nightly.
Cookies from trackers are rejected (it's a bit more complex than this, but
I need to simplify).

On top of this we have cookie permissions. They allow the user to set
custom cookie policies per origin. They are many, but, exposed to
UI/webextensions, they are only these:
- nsICookiePermission::ACCEPT_DEFAULT - follow the current cookie policy.
- nsICookiePermission::ACCEPT_ALLOW - accept all for this origin.
- nsICookiePermission::ACCEPT_DENY - reject any cookie for this origin.
- nsICookiePermission::ACCEPT_SESSION - accept cookies but make them
session only.

The reasons why I think we should not apply the new behavior to
live-documents are this:

*websites can break*
If we go from BEHAVIOR_ACCEPT to BEHAVIOR_REJECT (or ACCEPT_DENY), all the
storage APIs will start throwing exceptions (or reject promises). This is
an unpredictable behavior which can break the website's logic and makes the
storage APIs inconsistent. Note that this is different than blocking
cookies since the document loading.
Plus it doesn't give any extra security/privacy benefit: the website could
have already copied cookie data into local variables and it can still send
this data to the server.
If we go from BEHAVIOR_REJECT to BEHAVIOR_ACCEPT (or ACCEPT_ALLOW),
basically no website can "recover" itself without a reloading.

*complexity in our code base*
Some of our storage APIs have heavy code to switch between one cookie
behavior to another. For instance, sessionStorage and localStorage need to
choose the correct internal dataset at each getter/setter call, based on
the current cookie policy. They also need, in same cases, to move data from
1 dataset to another: for instance if we go from ACCEPT_DEFAULT to
ACCEPT_SESSION:
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/storage/LocalStorageCache.cpp#184-209
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/storage/SessionStorageCache.cpp#12-33

*performance*
This is not just a extra complexity, but it's also a performance issue:
checking the current cookie policy requires several steps: is the origin in
the content-blocking allow list? is the current window a 3rd party? is the
channel marked as a tracker? has this window being visited in the past? etc.
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/base/nsContentUtils.cpp#8085-8451
https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/toolkit/components/antitracking/AntiTrackingCommon.cpp#785-1429

What I would like to do is this: each nsIChannel loading a document or a
subdocument content, stores the cookie behavior (permission + policy) for
its principal at creation time. The policy is applied to the whole
document's cookie jar and it doesn't change.
For BEHAVIOR_REJECT_TRACKER, when the storage access is granted (see
AccessStorage API and the anti-tracking heuristics), we recalculate the
document's cookie policy.

When the cookie policy or a cookie permission is changed, we inform the
user that the current tabs must be reloaded in order to apply the new
settings.

Of course, I don't want to apply the same logic to other permissions, such
as 'geo', 'fullscreen' and so on, because them are strongly connected with
APIs, user-interaction and permission prompting.

I want to conclude describing what other browsers do:
- Safari does something similar to what firefox is currently doing: cookie
policy is immediately applied.
- Chrome does something similar to what I propose: cookie policy is applied
to new documents only.

b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

>
>
> 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 possible to have cross-origin endpoints. And yes, we should not send
report in such sandboxed iframes. I'll file a spec issue if there is not
one yet.

I assume it is possible for foo.example to use this API to send a report to
> thirdparty.example (let's imagine thirdparty.example isn't on the
> Disconnect tracking proptection list.)  What data is leaked to
> thirdparty.example as part of those reports?  Do we send
> credentials/referrer?
>

A report contains the origin and the credentials, plus the body of course.
This doesn't seem different than a .

In general, I agree with your concern, and I would like more people to take
a close look at how Reporting API can be abused. As I said,
ReportingObserver seems fine. Report-to needs a better integration with
url-classifier and content blocking before being shipped.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

We have some WPTs here:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/content-security-policy/reporting-api/
My tests are here:
- gtests:
https://searchfox.org/mozilla-central/source/dom/reporting/tests/gtest
- mochitests:
https://searchfox.org/mozilla-central/source/dom/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 effort.
>>
>
> There don't appear to be any WPT if I am looking in the right place[1].
> Since Google are experimenting it feels like we have some WPT from the
> start, even if its a pure conversion of the mochitest, it would help make
> sure we interoperable with them.
>
> [1]
> https://searchfox.org/mozilla-central/source/testing/web-platform/tests/reporting/
>
> David
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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
retrieve reports. This is similar to "report-uri" directive for CSP.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1508310

Link to standard: https://w3c.github.io/reporting/

Platform coverage: All.

Estimated or target release: The code is landed in 65, disabled by pref. I
would enable it in 67/68 if there are no objections.

Preference behind which this will be implemented:
dom.reporting.header.enabled

Is this feature enabled by default in sandboxed iframes? yes.

DevTools bug: Not yet filed. Would be nice to expose the reporting queue
per domain somehow.

Do other browser engines implement this? Chromium is experimenting this
feature:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/V38Q47CxTIY
https://developers.google.com/web/updates/2018/09/reportingapi

web-platform-tests: just a little support. I wrote several mochitests which
can be converted to WPTs with a bit of effort.

Is this feature restricted to secure contexts? yes.

A bit of context: as you probably remember, I implemented ReportingObserver
because it was needed in order to run feature-policy WPTs.
ReportingObserver is still disabled by default in release and I haven't
sent a intent-to-ship email yet because I wanted to have a full
implementation of the reporting API before doing it. Now we have it and we
can discuss the next steps.

ReportingObserver is definitely useful, in particular for
DeprecationReportBody. It could also be interesting to use
InterventationReportBody for the anti-tracking project to inform trackers
that their cookieJar has been blocked/partitioned, or to inform when
autoplay is disabled for media elements.

Report-to is nice to have because it's similar to CSP "report-uri"
directive, which is already implemented and released (btw, CSP has
"report-to" directive to use the "report-to" header endpoints directly.
This is not implemented yet). A nice goal would be to unify reporting API
and CSP violation delivering in one single component. This could be a good
way to improve both features, for instance, using the URL-Classifier to
avoid the sending of reports to trackers.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: x-moz-errormessage attribute

[Andrea Marchesini]

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:
https://html.spec.whatwg.org/#dom-cva-setcustomvalidity

I intent to remove the support for x-moz-errormessage attribute in 66,
without any deprecation message because it's unlikely that it would break
websites. Let me know if you disagree.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1513890
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

*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

*Platform coverage*: everywhere.

*Estimated or target release*: 66 - after 1 cycle with this feature enabled
in nightly and beta only.

*Preference behind which this will be implemented*
:dom.targetBlankNoOpener.enabled

*Is this feature enabled by default in sandboxed iframes?* yes.

*DevTools bug*: no special support for devtools. Maybe we could dispatch an
Intervention report via Reporting API.

*Do other browser engines implement this?* Only safari at the moment:
https://trac.webkit.org/changeset/237144/webkit

*web-platform-tests*: none, yet, but I can convert my mochitest in a WPT
easily.

*Is this feature restricted to secure contexts?* no needs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Reporting API

[Andrea Marchesini]

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 the moment
we have FeaturePolicy, Interventions, crashes and deprecated APIs, but it's
easy to imagine reports coming from CSP violations, CORB, Origin-policy etc.

b. Often, when an intervention is made, the only thing a browser does is to
write a message in the console. autoplay heuristic and tracking protection
are just 2 examples. Here we can do something more: we can communicate
something to the page, using ReportingObserver.

c. it's a nice diagnostic tool for websites. In the 'report-to' HTTP
header, entry-points can be used as communication channel between the
browser and the server.


On Thu, Nov 15, 2018 at 5:25 PM Boris Zbarsky  wrote:

> 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 this an API we actually want to
> implement?  It seems like a fair amount of complexity and overhead and
> the one use case so far is for sites to have telemetry for when they're
> ending up with feature policy violations, 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: Reporting API

[Andrea Marchesini]

> 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 deprecated APIs across browsers.
And ReportingObserver is an easy way to test any feature-policy blocking
with a common code base. See:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/feature-policy/reporting
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: Reporting API

[Andrea Marchesini]

*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 current page, via ReportingObserver
b. reporting to a remote server, known via 'report-to' HTTP header.
My implementation covers only the first aspect. However I also have patches
for the second part, not in review yet.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1492036

*Link to standard*: https://w3c.github.io/reporting/

*Platform coverage*: everywhere.

*Estimated or target release*: unknown yet.

*Preference behind which this will be implemented*: dom.reporting.enabled

*Is this feature enabled by default in sandboxed iframes?* yes. The reports
are per contexts. (but not for workers or worklets yet. See
https://github.com/w3c/reporting/issues/131

*DevTools bug*: no supports for devtools. I don't think we need to do
anything for devtools.

*Do other browser engines implement this?*
Chrome shipped it in 69:
https://www.chromestatus.com/feature/4672626140119040
No other browsers.

*web-platform-tests*:
https://wpt.fyi/results/feature-policy/reporting?aligned=stable
https://wpt.fyi/results/reporting?aligned=stable
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: Feature Policy

[Andrea Marchesini]

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 define feature policies
for nested contexts.
* a WebIDL interface that allows querying the features.

My implementation covers all these 3 aspects.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801

Link to standard: https://wicg.github.io/feature-policy/

Platform coverage: everywhere.

Estimated or target release: I would like to enable this feature only in
nightly for a cycle after landing. This would probably be 65.

Preference behind which this will be implemented:
dom.security.featurePolicy.enabled

Is this feature enabled by default in sandboxed iframes? Yes, it is

DevTools bug: No devtools support.

Do other browser engines implement this? Chromium, since 63. Safari since
11.1 (partially - only 'allowed' attributed is supported).
web-platform-tests: There are several policy WPTs features. With my patches
we are almost green everywhere, ignoring payment API and picture-in-picture.

Is this feature restricted to secure contexts? No, it isn’t.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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.
>>
>
> It looks like there is no test coverage for various parts of this spec
> (e.g. the "clear-site-data-reload-needed" case)...   We should probably
> push to get that fixed.
>
> -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

Intent to ship: Clear-Site-Data header

[Andrea Marchesini]

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 1470111.

Spec: https://w3c.github.io/webappsec-clear-site-data/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: Clear-Site-Data header

[Andrea Marchesini]

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 target release: FF63

Preference behind which this will be implemented:
dom.clearSiteData.enabled

Do other browser engines implement this?
Shipped in Chrome 61.

web-platform-tests:
https://github.com/web-platform-tests/wpt/tree/master/clear-site-data


Secure contexts: Yes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsIClearDataService

[Andrea Marchesini]

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 some
components and not others). Plus, in the future we could have more
components which will need to delete site data.

I want to introduce nsIClearDataService. A new service that cleans up data.
See bug 1422365.

ForgetAboutSite and Sanitizer.jsm have been already ported to
nsIClearDatService. The next task will be to change Sanitizer.jsm for
android (bug 1466130).

This service can delete data by nsIPrincipal, or by hostname, or by time
range, or all the data. With bitmap flags it's possible to specify what
needs to be deleted. E.g. CLEAR_COOKIES | CLEAR_NETWORK_CACHE |
CLEAR_IMAGE_CACHE | CLEAR_DOM_STORAGES. See patch 1 for the full list of
flags.

Not all the components are able to delete data by nsIPrincipal, or hostname
or by time range. For this reason, nsIClearDataService uses a
"is-this-a-user-request" boolean parameter. The idea behind this is: if the
user wants to delete data, more is better than less. E. g., if we cannot
delete _foobar_ data by nsIPrincipal, let's try to delete by host. If also
this is not possible, better to delete all _foobar_ data for any
host/principal/time range.

On the other hand: if the request comes from an API or an exposed component
(Clear-Site-Data spec for instance), less is better than more: if we cannot
delete _foobar_ by host, definitely we don't want to delete all the
_foobar_ data for any host/principal/time range.

Of course the plan is to support delete-by-host, delete-by-principal and
delete-by-range for each component. This will be done in follow up bugs.

I implemented this feature exactly for Clear-Site-Data spec where a website
can delete all its data passing a HTTP header in the response
(Clear-Site-Data is not ready to land yet).

I hope you find this component useful.

Note for the DOM/QuotaManager/ServiceWorker people: this component covers
all the DOM storages under 1 single flag: CLEAR_DOM_QUOTA. This is done
because I know that the integration of localStorage and
ServiceWorkerRegistrar into QuotaManager is in progress. Plus, there are no
reasons to delete just localStorage, or just ServiceWorkers or just IDB
data.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: File.lastModifiedDate

[Andrea Marchesini]

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:

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2018-04-30=__none__!__none__!__none___channel_version=nightly%252F61=USE_COUNTER2_DEPRECATED_FileLastModifiedDate_PAGE_channel_version=null=*=Firefox=1_keys=submissions_date=2018-03-12=0=1_submission_date=0

Currently only Chrome and Firefox support this attribute.

Firefox bug: 1458883.
Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=839372
WPT: https://github.com/w3c/web-platform-tests/pull/10821
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: URL.createObjectURL(MediaStream)

[Andrea Marchesini]

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 message as well but the method has not removed
yet: https://bugs.chromium.org/p/chromium/issues/detail?id=591719
. safari throws
. I haven't checked edge (I don't run windows locally)
. We have WPT.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

WorkerRef classes

[Andrea Marchesini]

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 with Web Workers, now you have 3 new classes, each one
for a different scenario.

StrongWorkerRef - ref-counted object, non-thread-safe.  You can pass a
callback to the CTOR in order to notified when the Web Worker starts the
shutdown procedure. To obtain a WorkerPrivate, just call its Private()
method.
Keeping this object alive means keeping the Web Worker thread alive.
Note that the Web Worker can start the shutdown procedure at any time.
After the shutdown notification, no more WorkerRunnable objects will be
scheduled and no JS code will be executed on that Web Worker thread. But
having a StrongWorkerRef object allows you to dispatch
WorkerControlRunnables and to have access to WorkerPrivate safely.

WeakWorkerRef - a ref-counted object, non-thread-safe. Also here you can
pass a callback to the CTOR in order to notified when the Web Worker starts
the shutdown procedure.
>From this object, you can obtain a WorkerPrivate pointer calling:
GetPrivate(). This returns a nullptr if the Web Worker is already gone.
If you are familiar with WorkerHolder, this is similar to its
AllowIdleShutdownStart behavior.

ThreadSafeWorkerRef - ref-counted thread-safe object. Built on top of
StrongWorkerRef, it doesn't support  notification callbacks, but it can be
sent to any thread. It keeps the Web Worker alive. To obtain a
WorkerPrivate, just call its Private() method.
This is meant to be used in code that can be sent cross-threads.

More documentation can be found here:
https://hg.mozilla.org/integration/mozilla-inbound/file/tip/dom/workers/WorkerRef.h#l18
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

'workers' namespace removed

[Andrea Marchesini]

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 use worker
headers. Just include the headers. They are all under "mozilla/dom/".

. Functions such as GetWorkerPrivateFromContext() and
GetCurrentThreadWorkerPrivate() will be soon under a 'workerutils'
namespace (bug 1435174). They are all available including
"mozilla/dom/WorkerCommon.h"

b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All about Prefs

[Andrea Marchesini]

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 active workers each time one of them changes.
DOMPreferences uses atomic prefs getters introduced by bug 1417741 to avoid
all of this.

We can continue the discussion of this feature on bugzilla. I'll NI you
there.

[1] https://searchfox.org/mozilla-central/source/dom/workers/WorkerPrefs.h

On Sun, Dec 17, 2017 at 9:38 PM, Nicholas Nethercote  wrote:

> Hi,
>
> I recently became the module owner of Prefs, and there are several peers.
> In the past it was an ill-maintained module, but that is no longer the
> case.
>
> I have been doing a bunch of work to improve Prefs. As part of this I wrote
> a document that describes how they currently work, and some of their
> problems:
> https://docs.google.com/document/d/1V5Wc9bXwfgMG2JOsswvDPVwZl_
> xiaSBxwJXf3fiEaU8/
>
> I am working on a redesign that will fix a lot of the problems. There was a
> meeting about this in Austin. I hope to implement this in Q1 2018.
>
> By chance, I just discovered that a new DOMPreferences class has been
> created in bug 1419771.
> As far as I can tell, it was created and reviewed by DOM peers without any
> input from Prefs peers. Although the changes are all within dom/, it was
> still an unpleasant surprise, because this is an additional thing I'm going
> to have to deal with in my redesign, on top of the existing gfxPrefs and
> MediaPrefs classes.
>
> If you have changes related to Prefs, please let me (or another Prefs peer)
> know about it. Thanks.
>
> Nick
> ___
> 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: Still-supported cases of out-of-tree XPCOM code?

[Andrea Marchesini]

>
> 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 this has been fixed by bug 1416468.
The bootstrap.js error and the other one are not directly connected.
This also means that it made sense to back out the patch from beta.

Sorry for the confusion.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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 preferences are
set, some CSS, some SVG...

But in that file, in FF57 and 58 there was a bug: it was trying to load an
addon-sdk resource: resource://gre/modules/commonjs/toolkit/loader.js in
order to be able to use TextDecoder and TextEncoder.
The loading fails in 57 and 58 and the execution of bootstrap.js terminates
with an exception. Totally fine: we don't need this file for such FF
versions.
See commit:
https://github.com/mozilla/multi-account-containers/commit/a7be3c9935ac42469a1030c3714c656d6e6d0948

In bug 1347515 I removed nsIJSON interface and I introduced the use of
TextDecoder in ContextualIdentityService.jsm in order to retrieve JSON
objects from files.
But the failure in bootstrap.js, made 'TextDecoder' to be null in
ContextualIdentyService.jsm. The result is that the default containers were
restored.

This is why we had this issue. It should not be impossible for a 'standard'
webextension to generate such mess.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Abort API

[Andrea Marchesini]

I spoke with Ben yesterday and today and we decided that bug 1394102 should
not block the shipping of this feature. That bug will be fixed as part of
the Service Worker refactoring.
Abort API and the Fetch() integration should be enabled by default in the
next nightly.

On Tue, Aug 29, 2017 at 4: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 already part of the DOM spec and I would like to enable it
>>> by
>>> default everywhere in our codebase (dom.abortController.enabled). Abort +
>>> Fetch integration is not part of the spec yet. There is a read-ish
>>> pull-request, but as soon as it is merged, I would like to enable the
>>> second pref as well (dom.abortController.fetch.enabled).
>>>
>>
>> I don't understand why we would potentially ship these separately.
>> AFAICT the abort API is only really useful if its integrated into something
>> like fetch().  Currently the Fetch API is the only part of the platform
>> that uses it.
>>
>> Also, we have seen people do thing like feature detect for ReadableStream
>> and assume Response.body can be a ReadableStream.  This is why we are not
>> shipping the js ReadableStream until the fetch body stream can ship as
>> well.  I worry that people would do a similar kind of feature detection
>> with Abort API.
>>
>> Also, while the fetch+abort spec change has not landed yet, we pretty
>> much have consensus.  There are WPT tests in the tree already.  I don't
>> think this is what is blocking shipping the fetch+abort code.  To me its a
>> bigger issue that we still don't pass many of those WPT tests.  If we
>> passed the tests then I think we could reasonably ship it given the current
>> level of consensus on the spec.
>>
>
> I spoke with Andrea and Jake (the spec author on this feature) a bit this
> morning.  Our current test failures are all reasonable for different
> reasons:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1394085#c4
>
> So I would just like to see bug 1394102 land before we let abortable fetch
> ride the trains.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Abort API

[Andrea Marchesini]

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 both set to false in release, and to true
in nightly. These allow the enabling of Abort API independently, and the
enabling of Abort + Fetch.
Abort API is a simple API that can be used separately, but when integrated
with Fetch, if a fetch() operation is aborted, this involves the canceling
of the networking, and the body consuming, and the ReadableStream (if
involved and enabled).

Abort API is already part of the DOM spec and I would like to enable it by
default everywhere in our codebase (dom.abortController.enabled). Abort +
Fetch integration is not part of the spec yet. There is a read-ish
pull-request, but as soon as it is merged, I would like to enable the
second pref as well (dom.abortController.fetch.enabled).

Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1394085
https://bugzilla.mozilla.org/show_bug.cgi?id=1378342

Other vendors:
Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=750599
I haven't found anything about Edge and Safari.

Estimated target date: Firefox 58.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling filesystem read-restrictions for content process sandbox

[Andrea Marchesini]

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?

On Fri, Jul 21, 2017 at 3:44 PM,  wrote:

> As a follow-up to this, tomorrow's (2017-07-22) Nightly will have this
> enabled for the Windows content process sandbox as well.
>
> On Windows this removes access that the User gains via their own SID.
> So generally things under their home directory (C:\Users\\).
> With exceptions for the Firefox installation directory and the chrome
> directory in the profile.
>
> There are a few other restrictions included as well, for example reading
> and writing to the clipboard.
>
> If you hit any issues on Windows after tomorrow that disappear when you
> set the pref security.sandbox.content.level to 2 or lower, please file a
> bug to block https://bugzilla.mozilla.org/show_bug.cgi?id=1366697.
>
> Cheers,
> Bob
>
>
> On Thursday, 6 July 2017 15:07:50 UTC+1, Alex Gaynor  wrote:
> > Hi dev-platform,
> >
> > On behalf of the Runtime Content Isolation (aka sandboxing) team, I'm
> > delighted
> > to announce that starting later this week, our macOS and Windows nightly
> > builds
> > will prohibit read access to most of the filesystem in the content
> process!
> >
> > What does this mean for you? First and foremost, a more secure browser!
> > Second,
> > it means that if you see bugs, please report them, our goal is to put
> this
> > on
> > the trains for 56! If you run into anything, please file it as a blocker
> for
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1377522 .
> >
> > Finally, it means that in code you're writing, you should not expect to
> be
> > able
> > to read from the filesystem in the content process -- with the exception
> of
> > inside the .app bundle, or in the chrome/ subdirectory of the profile
> > directory.
> >
> > If you need access to a file in content, you should plan on remoting that
> > to the
> > parent process. When designing these APIs, please be careful to ensure
> the
> > parent process is able to perform appropriate permissions checks such
> that
> > the
> > IPC mechanism isn't able to bypass the sandbox's goal of preventing a
> > malicious
> > content process from accessing the entire file system.
> >
> > This represents the culmination of a lot of work by a lot of folks, both
> on
> > our
> > team and on many other teams who helped out with refactoring their code
> --
> > thank
> > you!
> >
> > We're looking forward to also shipping this for Linux soon.
> >
> > Cheers,
> > Alex
>
> ___
> 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: PBlob refactoring landed

[Andrea Marchesini]

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 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 patches in review, the
> latter, patches are in testing.
>
> The reason why I started this refactoring are mainly 3:
>
> 1. PBlob code has/had sync IPC calls for retrieving remote inputStreams
> (bug 1350644) PBlob has also other sync IPC calls, and all of them have
> been removed in the refactoring: https://dxr.mozilla.org/
> mozilla-central/source/ipc/ipdl/sync-messages.ini#810-817
>
> 2. A consequence of point one is not just a performance issue, but we have
> bugs where those IPC calls cause deadlocks when those are executed on the
> main-thread, during a sync event loop of a workers, on a PBlob generated in
> workers (super racy but still possible).
>
> 3. PBlob code is hard to maintain, it doesn't have enough comments and it
> has some open issues such as: bug 1304056 and bug 1272078
>
> 4. We have crashs in the use of remoteInputStream in PBlob: bug 1349685
>
> The new source code gets rid of PBlob completely. A good description of
> how it works can be found here:
>
> https://dxr.mozilla.org/mozilla-central/source/dom/
> file/ipc/IPCBlobUtils.h#12
>
> If you need to pass Blobs via IPC, please, use IPCBlob. There are useful
> methods in mozilla/dom/IPCBlobUtils.h for serializing and deserializing
> blobs into/from IPCBlob.
>
> Cheers,
> b
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PBlob refactoring landed

[Andrea Marchesini]

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 patches in review, the
latter, patches are in testing.

The reason why I started this refactoring are mainly 3:

1. PBlob code has/had sync IPC calls for retrieving remote inputStreams
(bug 1350644) PBlob has also other sync IPC calls, and all of them have
been removed in the refactoring:
https://dxr.mozilla.org/mozilla-central/source/ipc/ipdl/sync-messages.ini#810-817

2. A consequence of point one is not just a performance issue, but we have
bugs where those IPC calls cause deadlocks when those are executed on the
main-thread, during a sync event loop of a workers, on a PBlob generated in
workers (super racy but still possible).

3. PBlob code is hard to maintain, it doesn't have enough comments and it
has some open issues such as: bug 1304056 and bug 1272078

4. We have crashs in the use of remoteInputStream in PBlob: bug 1349685

The new source code gets rid of PBlob completely. A good description of how
it works can be found here:

https://dxr.mozilla.org/mozilla-central/source/dom/file/ipc/IPCBlobUtils.h#12

If you need to pass Blobs via IPC, please, use IPCBlob. There are useful
methods in mozilla/dom/IPCBlobUtils.h for serializing and deserializing
blobs into/from IPCBlob.

Cheers,
b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

intent to implement/ship: MediaQueryListEvent

[Andrea Marchesini]

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: https://bugzilla.mozilla.org/show_bug.cgi?id=1354441

Details:

The main differences between the previous version and the current one are:

. addListener/removeListener are 'alias' of
addEventListener/removeEventListener

. the spec also introduces a new event called MediaQueryListEvent: the
function argument will be this event and not the MediaQueryList object as
it was before. This could introduce a compatibility break.

Chromium implements the same behavior, since 2014.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: URLSearchParams from array or object

[Andrea Marchesini]

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

https://bugzilla.mozilla.org/show_bug.cgi?id=1330699
https://bugzilla.mozilla.org/show_bug.cgi?id=1331580

Link to standard:
https://url.spec.whatwg.org/#interface-urlsearchparams

Platform coverage: all platforms

Estimated or target release: Fx53

Preference behind which this will be implemented: none

DevTools bug: no need

Do other browser engines implement this? I don't know this, yet

Tests: WPT

Security & Privacy Concerns: none
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

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 audioWorklet, then, I want to have
something able to run on any thread.
The code is not ready yet, but the main idea is to have worklet thread
agnostic.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Report about the NetworkInformation meeting

[Andrea Marchesini]

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 use-cases of this API before
taken further steps.
Marcos will probably help with this. After that, we can probably organize
another meeting and/or continue the discussion here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: NetworkInformation

[Andrea Marchesini]

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: https://bugzilla.mozilla.org/show_bug.cgi?id=1323172
spec updates: https://bugzilla.mozilla.org/show_bug.cgi?id=1323658


Spec: https://w3c.github.io/netinfo/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: WorkerGlobalScope.onclose

[Andrea Marchesini]

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 objection?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

No more custom worker WebIDL bindings

[Andrea Marchesini]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Only Containers Feature

[Andrea Marchesini]

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 out the feature and provide
> us
> > with feedback[1].  We want to ensure that the OriginAttributes
>
> What's the proper Bugzilla component for bugs/feature requests related
> to this? I got a bug triage email about
> https://bugzilla.mozilla.org/show_bug.cgi?id=1280697 which is
> currently categorized as Widget: Cocoa due to some OS X-specific
> ideas, but I think will have a better chance of getting attention in a
> Containers-focused component.
>
> Cheers,
>
> Dirkjan
> ___
> 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 ship: Directory picking and directory drag-and-drop

[Andrea Marchesini]

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 important is the security implications for the directory picker: bug
907707.

b


On Fri, Apr 15, 2016 at 5:31 AM,  wrote:

> Am Mittwoch, 23. September 2015 02:33:52 UTC+2 schrieb Jonas Sicking:
> > On Tue, Sep 22, 2015 at 11:16 PM, Eric Rescorla  wrote:
> > >> The api has been extensively discussed with all browser vendors and
> has
> > >> changed substantially in response to this
> > >
> > > Can you please point me to those changes and to the security analysis?
> >
> > Security wasn't discussed much in these conversations, and the changes
> > were all syntactical and didn't affect security. That's not to say
> > that no one has cared about security or been unaware about the
> > security implications, it's more due to the fact that any security
> > aspects here are likely to influence the API or the normative spec
> > text.
> >
> > But yes, I agree that we should have the security team look at this
> feature.
> >
> > / Jonas
>
> Any updates on this? How is the status? Feature is not shipped even in
> version 45 :(. Thanks.
> ___
> 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: about:profiles and the new profile manager

[Andrea Marchesini]

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 reverted the changes about the new ProfileManager and I'm
> > collaborating with Bram for a better UX.
> > about:profiles is still there and you can use it to manage your profiles
> > once FF is running.
> > I marked as duplicates all of those bugs.
> >
> > The new profileManager will be implemented here: bug 1240022
> > b
> >
> > On Tue, Jan 26, 2016 at 12:16 AM, Karl Dubost <kdub...@mozilla.com>
> wrote:
> >
> > > Andrea,
> > >
> > > Le 19 déc. 2015 à 02:17, Andrea Marchesini <amarches...@mozilla.com> a
> > > écrit :
> > > > This week I landed a set of patches to introduce 'about:profiles'.
> > >
> > > Where is the initial bug?
> > > With the change, we got a couple of orphaned bugs related to the new
> > > profile manager (old-new, I should say. it's gone from nightly, back
> to the
> > > old one.)
> > >
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1235832
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1235295
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1235284
> > >
> > > --
> > > Karl Dubost, Mozilla
> > > http://www.la-grange.net/karl/moz
> > >
> > >
>
> Hey Andrea, I have a cross platform (almost release) beta ready. I
> uploaded it to AMO as beta:
>
> https://addons.mozilla.org/en-US/firefox/addon/profilist/
>
> Please scroll down to the bottom of AMO listing and install Development
> Channel
>
> http://i.imgur.com/GJkQt56.png
>
> http://i.imgur.com/gNhLIv6.png
>
> After install please navigate to about:profilist?html to use/see it in
> action.
>
> To access the options page, please go to about:profilist - from here you
> can create desktop shortcuts.
>
> One massive issue is something I'll have to submit a patch to Firefox for.
> It's on Mac: Anything that is launched from the Profilist menu or a desktop
> shortcut created by Profilist, has some internal paths that are wrong. Each
> launcher is an app bundle which consists of symlinks to the original
> Firefox app bundle. The issue is Firefox isn't reading through those
> symlinks. But it works pretty decently, the update mechanism is broken, but
> I hope to try to get a patch in on Firefox for this.
>
> Here's a screenshot of it in action: http://i.imgur.com/jAimWMb.png
> ___
> 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: about:profiles and the new profile manager

[Andrea Marchesini]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: about:profiles and the new profile manager

[Andrea Marchesini]

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 not a serious plan about improving the UX of
the ProfileManager, yet.

b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: about:profiles and the new profile manager

[Andrea Marchesini]

> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

about:profiles and the new profile manager

[Andrea Marchesini]

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 manage them with a simple UI is extremely useful and it's important for
web developers who want to test a websites with different logins, people
who care about privacy and want to have different profiles for different
use-case, and so on.

This page/feature is not meant to be a replacement of containers:
containers have a completely different workflow, it's a major feature of
firefox and I want to see it enabled by default on nightly :)

I also landed a replacement of the existing ProfileManager, built on top of
about:profiles: instead having a XUL UI, we show a XUL browser element
rendering |about:profiles?manage|. This new profile manager offers the same
features of the previous one.

There are still a couple of open issues, and maybe more will come. But I'm
working on them and I'm having good feedback.

b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: StructuredCloneHelper

[Andrea Marchesini]

Yes, absolutely.
I'll file a bug for this.

On Tue, Sep 8, 2015 at 7:11 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:

> Awesome, thanks for working to unify this stuff baku!
>
> Can this stuff be applied to StackScopedClone (used by Cu.cloneInto etc),
> which currently does this 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 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 objects we were supporting. Now MessagePort,
>> BroadcastChannel, window and worker and (partially) IPC share the same
>> code
>> base.
>>
>> 2. We had several regressions about memory management of
>> clonable/transferrable objects. At least now we have only 1 code base to
>> maintain and fix.
>>
>> How it works:
>>
>> 1. StructuredCloneHelperInternal is base class that uses
>> JSAutoStructuredCloneBuffer internally and exposes the
>> JSStructuredCloneCallbacks as virtual methods.
>> For some custom use of JSAutoStructuredCloneBuffer (like Console API in
>> workers or PromiseWorkerProxy  - bug 1198814) you can use this class.
>>
>> 2. Probably what you really want to use is StructuredCloneHelper. In its
>> CTOR you must decide if:
>> a. you want to support the cloning of DOM objects (such as Blob, FileList,
>> ImageData, FormData, etc...): CloningSupported/CloningNotSupported
>> b. if you want to support the transferring of DOM objects (currently only
>> MessagePort): TransferringSupported/TransferringNotSupported
>> c. what is the most generic context where the "Read" could run. Here we
>> have 3 options: SameProcessSameThread (window to window for instance),
>> SameProcessDifferentThread (window to worker), DifferentProcess
>> (MessagePort? ipc? all that stuff).
>>
>> 3. For IPC communication we have a particular class:
>> StructuredCloneIPCHelper.
>>
>> Next steps:
>>
>> I'm currently (on vacation, but) working on another step: I want to remove
>> JSAutoStructuredCloneBuffer, OwningSerializedStructuredCloneBuffer and
>> SerializedStructuredCloneBuffer from IPC serialization. Bug: 1201806.
>> Please, avoid the use of JSAutoStructuredCloneBuffer in DOM tree. And if
>> you have a particular use-cases where StructuredCloneHelper doesn't work,
>> let me know and we can find a solution.
>>
>> b
>> ___
>> 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

StructuredCloneHelper

[Andrea Marchesini]

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 objects we were supporting. Now MessagePort,
BroadcastChannel, window and worker and (partially) IPC share the same code
base.

2. We had several regressions about memory management of
clonable/transferrable objects. At least now we have only 1 code base to
maintain and fix.

How it works:

1. StructuredCloneHelperInternal is base class that uses
JSAutoStructuredCloneBuffer internally and exposes the
JSStructuredCloneCallbacks as virtual methods.
For some custom use of JSAutoStructuredCloneBuffer (like Console API in
workers or PromiseWorkerProxy  - bug 1198814) you can use this class.

2. Probably what you really want to use is StructuredCloneHelper. In its
CTOR you must decide if:
a. you want to support the cloning of DOM objects (such as Blob, FileList,
ImageData, FormData, etc...): CloningSupported/CloningNotSupported
b. if you want to support the transferring of DOM objects (currently only
MessagePort): TransferringSupported/TransferringNotSupported
c. what is the most generic context where the "Read" could run. Here we
have 3 options: SameProcessSameThread (window to window for instance),
SameProcessDifferentThread (window to worker), DifferentProcess
(MessagePort? ipc? all that stuff).

3. For IPC communication we have a particular class:
StructuredCloneIPCHelper.

Next steps:

I'm currently (on vacation, but) working on another step: I want to remove
JSAutoStructuredCloneBuffer, OwningSerializedStructuredCloneBuffer and
SerializedStructuredCloneBuffer from IPC serialization. Bug: 1201806.
Please, avoid the use of JSAutoStructuredCloneBuffer in DOM tree. And if
you have a particular use-cases where StructuredCloneHelper doesn't work,
let me know and we can find a solution.

b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: User timing API in workers

[Andrea Marchesini]

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 standard:  http://www.w3.org/TR/user-timing/

Platform coverage:  all platforms

Other browser support: not in workers as far as I know.

Thanks,
andrea
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrea Marchesini]

Not yet but the editor is in CC to the first email of this thread.
About navigationStart, bkelly is right: in my patch I keep the
navigationStat from the window performance object. When we don't have the
window I take the creation time of the WorkerPrivate.

On Wed, May 20, 2015 at 7:12 PM, Boris 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
 ___
 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: BroadcastChannel API

[Andrea Marchesini]

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
 Subject: Re: Intent to implement: BroadcastChannel API
 
 Yes!
 
 Though as previously expressed, I don't think we should ship this until it
 supports sending Blobs.
 
 But we should definitely land preffed off as soon as patches are reviewed.
 
 / Jonas
 On Sep 24, 2014 3:45 AM, Andrea Marchesini amarches...@mozilla.com
 wrote:
 
  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, e.g. to manage locking of shared state, to manage
  synchronisation of resources between a server and multiple local clients,
  to share a WebSocket connection with a remote host, and so forth, shared
  workers are the most appropriate solution.
  For simple cases, though, where a shared worker would be an unreasonable
  overhead, authors can use the simple channel-based broadcast mechanism
  described in this section.
 
  Link to standard:
  http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts
 
  Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=966439
 
  Platform coverage: All
 
  Preference behind which this will be implemented:
  dom.broadcastchannel.enabled
 
  Note: Actually I've already implemented this API but I forgot to send this
  intent to implement email months ago. It has received the first positive
  review. I hope to land this API soon, if there are no objections.
  ___
  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

Intent to implement: BroadcastChannel API

[Andrea Marchesini]

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, e.g. to manage locking of shared state, to manage 
synchronisation of resources between a server and multiple local clients, to 
share a WebSocket connection with a remote host, and so forth, shared workers 
are the most appropriate solution.
For simple cases, though, where a shared worker would be an unreasonable 
overhead, authors can use the simple channel-based broadcast mechanism 
described in this section.

Link to standard: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=966439

Platform coverage: All

Preference behind which this will be implemented: dom.broadcastchannel.enabled

Note: Actually I've already implemented this API but I forgot to send this 
intent to implement email months ago. It has received the first positive 
review. I hope to land this API soon, if there are no objections.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

style guide proposal

[Andrea Marchesini]

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,
   getter_AddRefs(providedPrincipal) {

It seems that our style guide does not say anything about how indent this 
tricky case.
So, talking with bholley we decided to write an email proposing something like 
this:

1. if they can, all the params on the same line. max 80 chars.

2. otherwise multiple lines, aligned with the beginning of the params list.

es: obj-ThisIsALooongNameMethod(longParam1,
 loogParam2);

3. if 1 param alone goes over 80chars, it must be aligned in order to stay in 
the 80chars and the rest of the params must be aligned with it.

  nsIScriptSecurityManager* ssm = nsContentUtils::GetSecurityManager();
  if (NS_WARN_IF(NS_FAILED(ssm-GetSimpleCodebasePrincipal(
   originURI,
   getter_AddRefs(providedPrincipal) {
 // 80chars here ^

This approach is already used in dom/workers and IndexedDB.
https://mxr.mozilla.org/mozilla-central/source/dom/workers/RuntimeService.cpp#1647

How does it sound?
b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New Promise Constructor

[Andrea Marchesini]

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 object and the new constructor works in this way:

callback PromiseInit = void (object resolve, object reject);
[Constructor(PromiseInit init)]
interface Promise {...}

Best Regards,
Andrea


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

id2webidl

[Andrea Marchesini]

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:
https://people.mozilla.com/~amarchesini/code/idl2webidl.rb

This ruby script generates an HTML page:

https://people.mozilla.com/~amarchesini/code/idl2webidl.html

(this page is not up-to-date)

I know that we don't want to convert all the existing interfaces to WebIDL, but 
I still think this report is useful to choose which interface is available to 
be converted.

Bye,
b
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform