Re: Largest chunks of code that are likely to be removable?

[Mike Hommey]

On Mon, Jun 29, 2015 at 11:19:08PM -0700, Nicholas Nethercote wrote:
> Hi,
> 
> I'm wondering what the largest chunks of code there are in the
> codebase that are candidates for removal, i.e. probably with a bit of
> work but not too much.
> 
> One that comes to mind is rdf/ (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1176160#c5) though I
> don't have a good understanding of how much stuff depends on it, even
> having seen https://bugzilla.mozilla.org/show_bug.cgi?id=420506.

See the dependencies of bug 833098.

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

Re: Largest chunks of code that are likely to be removable?

[Bobby Holley]

There's a bunch of XPConnect code that can go away when we finally kills
nsDOMClassInfo. We're 95% of the way there, just lacking will to push it
over the line.

On Mon, Jun 29, 2015 at 11:19 PM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:

> Hi,
>
> I'm wondering what the largest chunks of code there are in the
> codebase that are candidates for removal, i.e. probably with a bit of
> work but not too much.
>
> One that comes to mind is rdf/ (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1176160#c5) though I
> don't have a good understanding of how much stuff depends on it, even
> having seen https://bugzilla.mozilla.org/show_bug.cgi?id=420506.
>
> Any other candidates for removal?
>
> 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: Largest chunks of code that are likely to be removable?

[Kearwood "Kip" Gilbert]

Would anyone be opposed to combining the Matrix4x4 class and gfx3DMatrix?  
Rather than adding support for transforms and projections that involve vertices 
behind the w=0 plane to gfx3DMatrix, it may be cleaner to refactor affected 
call-sites to use Matrix4x4 instead.  The remaining references to gfx3DMatrix 
would be very few and easily replaced as well.

Cheers,
  - Kip

> On Jun 29, 2015, at 11:19 PM, Nicholas Nethercote  
> wrote:
> 
> Hi,
> 
> I'm wondering what the largest chunks of code there are in the
> codebase that are candidates for removal, i.e. probably with a bit of
> work but not too much.
> 
> One that comes to mind is rdf/ (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1176160#c5) though I
> don't have a good understanding of how much stuff depends on it, even
> having seen https://bugzilla.mozilla.org/show_bug.cgi?id=420506.
> 
> Any other candidates for removal?
> 
> 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: Largest chunks of code that are likely to be removable?

[Axel Hecht]

On 6/30/15 9:13 AM, Mike Hommey wrote:

On Mon, Jun 29, 2015 at 11:19:08PM -0700, Nicholas Nethercote wrote:

Hi,

I'm wondering what the largest chunks of code there are in the
codebase that are candidates for removal, i.e. probably with a bit of
work but not too much.

One that comes to mind is rdf/ (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1176160#c5) though I
don't have a good understanding of how much stuff depends on it, even
having seen https://bugzilla.mozilla.org/show_bug.cgi?id=420506.


See the dependencies of bug 833098.

Mike



Note, that bug has the dependencies to move rdf/ from mozilla-central 
into comm-central. mail has many more dependencies on RDF, I think.


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

Re: Largest chunks of code that are likely to be removable?

[kgupta]

On Tuesday, June 30, 2015 at 3:41:43 AM UTC-4, Kearwood "Kip" Gilbert wrote:
> Would anyone be opposed to combining the Matrix4x4 class and gfx3DMatrix?  
> Rather than adding support for transforms and projections that involve 
> vertices behind the w=0 plane to gfx3DMatrix, it may be cleaner to refactor 
> affected call-sites to use Matrix4x4 instead.  The remaining references to 
> gfx3DMatrix would be very few and easily replaced as well.
> 

I think dzbarsky was in the process of converting gfx3DMatrix use to Matrix4x4, 
I'm not sure what happened or if he's still working on it. I think people would 
be quite happy if you finished it off. CC'ing dzbarsky to see if he has any 
updates.

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

Re: How create a full copy of mozbuild and dependencies at https://github.com/html-shell/mozbuild

[Gregory Szorc]

The mozbuild Python package is available on PyPI:
https://pypi.python.org/pypi/mozbuild

It's also possible to obtain an archive of the source from hg.mozilla.org.
See the instructions for the "archive" command/URL at
https://hg.mozilla.org/mozilla-central/help/hgweb.

I would strongly prefer to not extract the files into a standalone GitHub
project, as that will make merging differences harder and could lead to a
permanent fork, which isn't conducive to the health of mozbuild at this
juncture, IMO.


On Mon, Jun 29, 2015 at 10:36 PM, 罗勇刚(Yonggang Luo) 
wrote:

> I think doing this can getting mozbuild can be used
> as a independent software without the gecko source tree.
>
>
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
> ___
> 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 migrate the permissions database to use origins instead of host names

[Ehsan Akhgari]

Historically our permissions database has used host names as part of the
permission entry, which means that if we stored a permission for
http://example.com, it would also apply to https://example.com (and
http://example.com:8080 for that matter).  This is undesirable specially
once you note that this potentially makes us store permissions for MITMed
connections and later on use them even for secure origins.

Michael has been working on fixing this over in bug 1165263.  We expect to
land this change within the Firefox 42 timeframe.  Here is the details of
the changes we are planning to make:

1. Instead of storing a host name, appId and isInBrowserElement flag for
each entry, we will store the full origin (including the origin attributes.)
2. Fix up the places where the permission manager APIs expose the notion of
host/appId/isInBrowserElement to the consumers.
3. Drop the "" hack from the permissions manager (bug 817007.)

We're going to use the following algorithm for migrating the existing
permission entries:

 * If the entry takes the form of a valid URI (such as entries for file://
URIs), then just insert it directly
 * For each host name foo, check to see whether the Places database
includes a visit to that domain or any subdomain.
  * For each found entry in the Places database, we inject a permission for
the visited origin, with the appId and isInBrowserElement origin attributes
from the original permission.
  * If there are no existing visited entries, inject one permission for
http://foo, and one for https://foo.

The interesting part of how the migration step works is that we have no
good way to know what origins need the permission after the upgrade by just
looking at the host name, so we try to find something in the Places
database that would help answer this question, and at the lack of that, we
assume that the two common origins that can be constructed from the host
name (namely the http and https origins with the default ports) can have
the permission, which is our best guess.  This means that in some edge
cases such as the user having a foo.com permission that belongs to an
origin such as http://foo.com:8080 but not having visited foo.com recently
(by default in the last 180 days) we will lose the stored permission.  We
hope that these edge cases will happen very rarely in practice.

Please let me know if you have any questions or concerns.

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

mozilla::TemporaryRef is gone; please use already_AddRefed

[Nathan Froyd]

Bug 1161627 has landed on inbound, which converts all uses of
mozilla::TemporaryRef to already_AddRefed and removes TemporaryRef.
(already_AddRefed moved to MFBT several months ago, in case you were
wondering about the spreading of XPCOM concepts.)  TemporaryRef was added
for easier porting of code from other engines, but as it has not been used
much for that purpose and it led to somewhat less efficient code in places,
it was deemed a failed experiment.

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

Secure contexts required for new web platform features

[Richard Barnes]

As a next step toward deprecating non-secure HTTP [1], we are making the
following two changes to how we develop new web platform features,
effective immediately:

First, when we work on developing specifications for new web platform
features, we will make sure that these specifications require secure
contexts [2].

Second, when we implement new web platform features, they will be enabled
only on secure contexts.  Exceptions can be granted, but will need to be
justified as part of the Intent to Implement [3] and Intent to Ship process.

[1]
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
[2] http://www.w3.org/TR/powerful-features/
[3] https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship Notification API on Web Workers

[smaug]

yes, please!


On 06/30/2015 06:46 AM, nsm.nik...@gmail.com wrote:

Hello,

Target release: Firefox 41
Implementation and shipping bug: 
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=916893
Specification: https://notifications.spec.whatwg.org/

Gecko already implements support for the Notification API on window behind the 
dom.webnotifications.enabled pref, and this has been enabled by default for at 
least a year. This is the intent to ship the same API on workers, guarded by 
the same pref, so it will be enabled by default.

The patches landed on central on July 29, 2015. These patches implement support 
for the Notification constructor on dedicated and shared workers. This is 
exposed via the Notification constructor.

The Service Worker parts of the Notification API are not shipping yet due to 
breaking some Gaia tests. That implementation is tracked in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1114554

Potential for abuse?
This API allows workers to abuse the user. There are some safeguards in place.
1) Notification.requestPermission() which prompts the user to grant permission 
is only available on window. This means the website cannot secretly acquire 
permission. It is also clear to the user which origin is requesting the 
permission.
2) Each notification displays the origin it came from. The user can revoke 
permission using the standard user agent mechanisms (Page Info in Firefox).

Platforms: All platforms.

Support in other engines:
Blink - shipped - 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/4WNnq8BIydI
Webkit - I don't have a way to try this out, but from the Blink intent to ship, 
it seems it isn't supported.
Edge/Trident: not supported

Developer documentation: 
https://developer.mozilla.org/en-US/docs/Web/API/Notification/Notification, the 
doc has not been updated for worker support yet.





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

Re: Secure contexts required for new web platform features

[Boris Zbarsky]

On 6/30/15 5:00 PM, Richard Barnes wrote:

Second, when we implement new web platform features, they will be enabled
only on secure contexts.


Might I ask who this "we" is (I don't recall general DOM module owner 
buy-in on this, but maybe I missed it?) what the definition of "new web 
platform features" is (e.g. does the webperf translateTime thing count? 
 What about adding the performance timing APIs we already ship for 
Window to workers?), and whether there's actually a stable definition of 
secure contexts that everyone agrees on?



Exceptions can be granted


Who makes that call?  Based on what criteria?

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

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

[Robert O'Callahan]

Will it ever be possible to eliminate TemporaryRef and use moves instead?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

[Jeff Muizelaar]

I believe this is predicated on removing the implicit conversion from
nsRefPtr to T*

-Jeff

On Tue, Jun 30, 2015 at 5:28 PM, Robert O'Callahan  wrote:
> Will it ever be possible to eliminate TemporaryRef and use moves instead?
>
> Rob
> --
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> owohooo
> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> oioso
> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> owohooo
> osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
> ooofo
> otohoeo ofoioroeo ooofo ohoeololo.
> ___
> 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: Largest chunks of code that are likely to be removable?

[David Zbarsky]

On Tuesday, June 30, 2015 at 9:01:45 AM UTC-4, kgu...@mozilla.com wrote:
> On Tuesday, June 30, 2015 at 3:41:43 AM UTC-4, Kearwood "Kip" Gilbert wrote:
> > Would anyone be opposed to combining the Matrix4x4 class and gfx3DMatrix?  
> > Rather than adding support for transforms and projections that involve 
> > vertices behind the w=0 plane to gfx3DMatrix, it may be cleaner to refactor 
> > affected call-sites to use Matrix4x4 instead.  The remaining references to 
> > gfx3DMatrix would be very few and easily replaced as well.
> > 
> 
> I think dzbarsky was in the process of converting gfx3DMatrix use to 
> Matrix4x4, I'm not sure what happened or if he's still working on it. I think 
> people would be quite happy if you finished it off. CC'ing dzbarsky to see if 
> he has any updates.
> 
> kats

I ran out of time to finish this up and I'm not sure when I'll be able to get 
back to it.  Anyone who wants to should feel free to take over.

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

Re: Intent to migrate the permissions database to use origins instead of host names

[Jonas Sicking]

There are actually one downside with this change.

It means that if a user denies access to https://website.com to use
cookies, then http://website.com will still have full ability to use
cookies since it's a different origin.

For a DENY policy it often makes more sense to deny a whole domain
name, since more often than not the http and https website are run by
the same people.

Whereas for an ACCEPT policy, it very often makes more sense to only
allow a given origin.

The problem stems from that the permission manager doesn't store
policies, but rather stores unformatted data that is then up to the
*reader* to interpret as a policy.

I.e. right now you just call
pm.add(, "camera", ALLOW);

It is then up to the reader to interpret this as either "camera is
available only for https://website.com"; or "camera is available for
https://website.com and any subdomain". This is decided by either
calling testPermission or testExactPermission.

Most developers do not know about this difference and so I have
uncountably many times had to tell people to use testExactPermission
to get desired behavior. Obviously this is extra bad because
testPermission is the function people jump most immediately to due to
its simpler name.

What I think the permission manager really needs to do is to have an API like:

pm.addOriginRule(, "camera", PROMPT);
pm.addDomainRule("domain.com", "cookies", DENY, INCLUDE_SUBDOMAINS |
OVERRIDE_EXISTING);
pm.testPermission(myprincipal, "geolocation");

/ Jonas


On Tue, Jun 30, 2015 at 11:58 AM, Ehsan Akhgari  wrote:
> Historically our permissions database has used host names as part of the
> permission entry, which means that if we stored a permission for
> http://example.com, it would also apply to https://example.com (and
> http://example.com:8080 for that matter).  This is undesirable specially
> once you note that this potentially makes us store permissions for MITMed
> connections and later on use them even for secure origins.
>
> Michael has been working on fixing this over in bug 1165263.  We expect to
> land this change within the Firefox 42 timeframe.  Here is the details of
> the changes we are planning to make:
>
> 1. Instead of storing a host name, appId and isInBrowserElement flag for
> each entry, we will store the full origin (including the origin attributes.)
> 2. Fix up the places where the permission manager APIs expose the notion of
> host/appId/isInBrowserElement to the consumers.
> 3. Drop the "" hack from the permissions manager (bug 817007.)
>
> We're going to use the following algorithm for migrating the existing
> permission entries:
>
>  * If the entry takes the form of a valid URI (such as entries for file://
> URIs), then just insert it directly
>  * For each host name foo, check to see whether the Places database
> includes a visit to that domain or any subdomain.
>   * For each found entry in the Places database, we inject a permission for
> the visited origin, with the appId and isInBrowserElement origin attributes
> from the original permission.
>   * If there are no existing visited entries, inject one permission for
> http://foo, and one for https://foo.
>
> The interesting part of how the migration step works is that we have no
> good way to know what origins need the permission after the upgrade by just
> looking at the host name, so we try to find something in the Places
> database that would help answer this question, and at the lack of that, we
> assume that the two common origins that can be constructed from the host
> name (namely the http and https origins with the default ports) can have
> the permission, which is our best guess.  This means that in some edge
> cases such as the user having a foo.com permission that belongs to an
> origin such as http://foo.com:8080 but not having visited foo.com recently
> (by default in the last 180 days) we will lose the stored permission.  We
> hope that these edge cases will happen very rarely in practice.
>
> Please let me know if you have any questions or concerns.
>
> Cheers,
> --
> Ehsan
> ___
> 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 migrate the permissions database to use origins instead of host names

[Martin Thomson]

I wonder, has the subject of double-keying been raised in this
context?  It comes up frequently in this context. And when I say
double-keying, I mean forming a key from the tuple of the requesting
principal and the top level browsing context principal (though origin
may suffice).

If there are disruptive changes afoot, then segregating based on what
is shown to the user might be sensible.

On Tue, Jun 30, 2015 at 3:04 PM, Jonas Sicking  wrote:
> There are actually one downside with this change.
>
> It means that if a user denies access to https://website.com to use
> cookies, then http://website.com will still have full ability to use
> cookies since it's a different origin.
>
> For a DENY policy it often makes more sense to deny a whole domain
> name, since more often than not the http and https website are run by
> the same people.
>
> Whereas for an ACCEPT policy, it very often makes more sense to only
> allow a given origin.
>
> The problem stems from that the permission manager doesn't store
> policies, but rather stores unformatted data that is then up to the
> *reader* to interpret as a policy.
>
> I.e. right now you just call
> pm.add(, "camera", ALLOW);
>
> It is then up to the reader to interpret this as either "camera is
> available only for https://website.com"; or "camera is available for
> https://website.com and any subdomain". This is decided by either
> calling testPermission or testExactPermission.
>
> Most developers do not know about this difference and so I have
> uncountably many times had to tell people to use testExactPermission
> to get desired behavior. Obviously this is extra bad because
> testPermission is the function people jump most immediately to due to
> its simpler name.
>
> What I think the permission manager really needs to do is to have an API like:
>
> pm.addOriginRule(, "camera", PROMPT);
> pm.addDomainRule("domain.com", "cookies", DENY, INCLUDE_SUBDOMAINS |
> OVERRIDE_EXISTING);
> pm.testPermission(myprincipal, "geolocation");
>
> / Jonas
>
>
> On Tue, Jun 30, 2015 at 11:58 AM, Ehsan Akhgari  
> wrote:
>> Historically our permissions database has used host names as part of the
>> permission entry, which means that if we stored a permission for
>> http://example.com, it would also apply to https://example.com (and
>> http://example.com:8080 for that matter).  This is undesirable specially
>> once you note that this potentially makes us store permissions for MITMed
>> connections and later on use them even for secure origins.
>>
>> Michael has been working on fixing this over in bug 1165263.  We expect to
>> land this change within the Firefox 42 timeframe.  Here is the details of
>> the changes we are planning to make:
>>
>> 1. Instead of storing a host name, appId and isInBrowserElement flag for
>> each entry, we will store the full origin (including the origin attributes.)
>> 2. Fix up the places where the permission manager APIs expose the notion of
>> host/appId/isInBrowserElement to the consumers.
>> 3. Drop the "" hack from the permissions manager (bug 817007.)
>>
>> We're going to use the following algorithm for migrating the existing
>> permission entries:
>>
>>  * If the entry takes the form of a valid URI (such as entries for file://
>> URIs), then just insert it directly
>>  * For each host name foo, check to see whether the Places database
>> includes a visit to that domain or any subdomain.
>>   * For each found entry in the Places database, we inject a permission for
>> the visited origin, with the appId and isInBrowserElement origin attributes
>> from the original permission.
>>   * If there are no existing visited entries, inject one permission for
>> http://foo, and one for https://foo.
>>
>> The interesting part of how the migration step works is that we have no
>> good way to know what origins need the permission after the upgrade by just
>> looking at the host name, so we try to find something in the Places
>> database that would help answer this question, and at the lack of that, we
>> assume that the two common origins that can be constructed from the host
>> name (namely the http and https origins with the default ports) can have
>> the permission, which is our best guess.  This means that in some edge
>> cases such as the user having a foo.com permission that belongs to an
>> origin such as http://foo.com:8080 but not having visited foo.com recently
>> (by default in the last 180 days) we will lose the stored permission.  We
>> hope that these edge cases will happen very rarely in practice.
>>
>> Please let me know if you have any questions or concerns.
>>
>> Cheers,
>> --
>> Ehsan
>> ___
>> 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 migrate the permissions database to use origins instead of host names

[Ehsan Akhgari]

On 2015-06-30 6:04 PM, Jonas Sicking wrote:

There are actually one downside with this change.

It means that if a user denies access to https://website.com to use
cookies, then http://website.com will still have full ability to use
cookies since it's a different origin.


That is a good point.

Are you more worried about importing existing DENY entries, or recording 
new ones?



For a DENY policy it often makes more sense to deny a whole domain
name, since more often than not the http and https website are run by
the same people.

Whereas for an ACCEPT policy, it very often makes more sense to only
allow a given origin.


Unfortunately I can't think of a clean way to support this off the top 
of my head.  Michael's current patches move us to store an origin field, 
potentially with some trailing origin attributes.  I can't think of any 
way to make DENY work across schemes and port numbers other than 
inventing custom catch-all entries for such entries  :(


Another complication is how should we treat cross-app origins?  Do we 
want to treat a DENY entry for one app override all others?  If not, do 
we want to treat appId/isInBrowserElement specially here?  What about 
future other origin attributes?


Can you think of a clean way to address this?


The problem stems from that the permission manager doesn't store
policies, but rather stores unformatted data that is then up to the
*reader* to interpret as a policy.


Indeed.


I.e. right now you just call
pm.add(, "camera", ALLOW);

It is then up to the reader to interpret this as either "camera is
available only for https://website.com"; or "camera is available for
https://website.com and any subdomain". This is decided by either
calling testPermission or testExactPermission.

Most developers do not know about this difference and so I have
uncountably many times had to tell people to use testExactPermission
to get desired behavior. Obviously this is extra bad because
testPermission is the function people jump most immediately to due to
its simpler name.

What I think the permission manager really needs to do is to have an API like:

pm.addOriginRule(, "camera", PROMPT);
pm.addDomainRule("domain.com", "cookies", DENY, INCLUDE_SUBDOMAINS |
OVERRIDE_EXISTING);
pm.testPermission(myprincipal, "geolocation");


I'd really prefer if we addressed this without attempting to make big 
changes to the permission manager API, as that is a much bigger project 
than what we have been planning to do here and will require the 
consumers to be rewritten.



On Tue, Jun 30, 2015 at 11:58 AM, Ehsan Akhgari  wrote:

Historically our permissions database has used host names as part of the
permission entry, which means that if we stored a permission for
http://example.com, it would also apply to https://example.com (and
http://example.com:8080 for that matter).  This is undesirable specially
once you note that this potentially makes us store permissions for MITMed
connections and later on use them even for secure origins.

Michael has been working on fixing this over in bug 1165263.  We expect to
land this change within the Firefox 42 timeframe.  Here is the details of
the changes we are planning to make:

1. Instead of storing a host name, appId and isInBrowserElement flag for
each entry, we will store the full origin (including the origin attributes.)
2. Fix up the places where the permission manager APIs expose the notion of
host/appId/isInBrowserElement to the consumers.
3. Drop the "" hack from the permissions manager (bug 817007.)

We're going to use the following algorithm for migrating the existing
permission entries:

  * If the entry takes the form of a valid URI (such as entries for file://
URIs), then just insert it directly
  * For each host name foo, check to see whether the Places database
includes a visit to that domain or any subdomain.
   * For each found entry in the Places database, we inject a permission for
the visited origin, with the appId and isInBrowserElement origin attributes
from the original permission.
   * If there are no existing visited entries, inject one permission for
http://foo, and one for https://foo.

The interesting part of how the migration step works is that we have no
good way to know what origins need the permission after the upgrade by just
looking at the host name, so we try to find something in the Places
database that would help answer this question, and at the lack of that, we
assume that the two common origins that can be constructed from the host
name (namely the http and https origins with the default ports) can have
the permission, which is our best guess.  This means that in some edge
cases such as the user having a foo.com permission that belongs to an
origin such as http://foo.com:8080 but not having visited foo.com recently
(by default in the last 180 days) we will lose the stored permission.  We
hope that these edge cases will happen very rarely in practice.

Please let me kn

Re: Intent to migrate the permissions database to use origins instead of host names

[Ehsan Akhgari]

On 2015-06-30 6:55 PM, Martin Thomson wrote:

I wonder, has the subject of double-keying been raised in this
context?  It comes up frequently in this context. And when I say
double-keying, I mean forming a key from the tuple of the requesting
principal and the top level browsing context principal (though origin
may suffice).


Yes, this was discussed the last time we discussed permissions on this 
list, IIRC, and this idea was brought up.


I personally am not sure if that is a sound idea for all permission 
types.  It's probably the right thing for geolocation, but not for cookies.


This is also another part of the bigger problem here that the permission 
manager doesn't store policies.



If there are disruptive changes afoot, then segregating based on what
is shown to the user might be sensible.

On Tue, Jun 30, 2015 at 3:04 PM, Jonas Sicking  wrote:

There are actually one downside with this change.

It means that if a user denies access to https://website.com to use
cookies, then http://website.com will still have full ability to use
cookies since it's a different origin.

For a DENY policy it often makes more sense to deny a whole domain
name, since more often than not the http and https website are run by
the same people.

Whereas for an ACCEPT policy, it very often makes more sense to only
allow a given origin.

The problem stems from that the permission manager doesn't store
policies, but rather stores unformatted data that is then up to the
*reader* to interpret as a policy.

I.e. right now you just call
pm.add(, "camera", ALLOW);

It is then up to the reader to interpret this as either "camera is
available only for https://website.com"; or "camera is available for
https://website.com and any subdomain". This is decided by either
calling testPermission or testExactPermission.

Most developers do not know about this difference and so I have
uncountably many times had to tell people to use testExactPermission
to get desired behavior. Obviously this is extra bad because
testPermission is the function people jump most immediately to due to
its simpler name.

What I think the permission manager really needs to do is to have an API like:

pm.addOriginRule(, "camera", PROMPT);
pm.addDomainRule("domain.com", "cookies", DENY, INCLUDE_SUBDOMAINS |
OVERRIDE_EXISTING);
pm.testPermission(myprincipal, "geolocation");

/ Jonas


On Tue, Jun 30, 2015 at 11:58 AM, Ehsan Akhgari  wrote:

Historically our permissions database has used host names as part of the
permission entry, which means that if we stored a permission for
http://example.com, it would also apply to https://example.com (and
http://example.com:8080 for that matter).  This is undesirable specially
once you note that this potentially makes us store permissions for MITMed
connections and later on use them even for secure origins.

Michael has been working on fixing this over in bug 1165263.  We expect to
land this change within the Firefox 42 timeframe.  Here is the details of
the changes we are planning to make:

1. Instead of storing a host name, appId and isInBrowserElement flag for
each entry, we will store the full origin (including the origin attributes.)
2. Fix up the places where the permission manager APIs expose the notion of
host/appId/isInBrowserElement to the consumers.
3. Drop the "" hack from the permissions manager (bug 817007.)

We're going to use the following algorithm for migrating the existing
permission entries:

  * If the entry takes the form of a valid URI (such as entries for file://
URIs), then just insert it directly
  * For each host name foo, check to see whether the Places database
includes a visit to that domain or any subdomain.
   * For each found entry in the Places database, we inject a permission for
the visited origin, with the appId and isInBrowserElement origin attributes
from the original permission.
   * If there are no existing visited entries, inject one permission for
http://foo, and one for https://foo.

The interesting part of how the migration step works is that we have no
good way to know what origins need the permission after the upgrade by just
looking at the host name, so we try to find something in the Places
database that would help answer this question, and at the lack of that, we
assume that the two common origins that can be constructed from the host
name (namely the http and https origins with the default ports) can have
the permission, which is our best guess.  This means that in some edge
cases such as the user having a foo.com permission that belongs to an
origin such as http://foo.com:8080 but not having visited foo.com recently
(by default in the last 180 days) we will lose the stored permission.  We
hope that these edge cases will happen very rarely in practice.

Please let me know if you have any questions or concerns.

Cheers,
--
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https

Re: Intent to migrate the permissions database to use origins instead of host names

[Martin Thomson]

On Tue, Jun 30, 2015 at 4:18 PM, Ehsan Akhgari  wrote:
> I personally am not sure if that is a sound idea for all permission types.
> It's probably the right thing for geolocation, but not for cookies.

As I understand it, the key for permission manager is a simple string.
Rather than make new APIs and restructure in a way that is perhaps
incompatible with existing users, could you make a set of different
key builders to serve all these ends:

pm.addRule(pm.makeOriginRule(uri), "camera", blah)
pm.addRule(pm.makeDomainRule("example.com", INCLUDE_SUBDOMAINS),
"cookies", DENY)

The plan to migrate to an origin basis is OK without this, of course.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

web-platform-tests on debug builds running on try

[James Graham]

Web-platform-tests are now running in debug builds on try only. However 
due to some teething problems, they are not currently all green. This is 
expected to be fixed in the next 24 hours but, in the meantime, if you 
see some orange that seems unrelated to your change, particularly orange 
that looks like [1], please don't panic; it's likely safe to ignore (if 
there is a sheriff reading this, we should possibly hide those jobs 
temporarily).


Sorry for the inconvenience this has caused.

[1] https://treeherder.mozilla.org/logviewer.html#?job_id=8927888&repo=try
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to migrate the permissions database to use origins instead of host names

[Jonas Sicking]

On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari  wrote:
> On 2015-06-30 6:04 PM, Jonas Sicking wrote:
>>
>> There are actually one downside with this change.
>>
>> It means that if a user denies access to https://website.com to use
>> cookies, then http://website.com will still have full ability to use
>> cookies since it's a different origin.
>
>
> That is a good point.
>
> Are you more worried about importing existing DENY entries, or recording new
> ones?

But I guess.

But I agree I don't see a way to address this without changing the
nsIPermissionManager API.

/ Jonas

>> For a DENY policy it often makes more sense to deny a whole domain
>> name, since more often than not the http and https website are run by
>> the same people.
>>
>> Whereas for an ACCEPT policy, it very often makes more sense to only
>> allow a given origin.
>
>
> Unfortunately I can't think of a clean way to support this off the top of my
> head.  Michael's current patches move us to store an origin field,
> potentially with some trailing origin attributes.  I can't think of any way
> to make DENY work across schemes and port numbers other than inventing
> custom catch-all entries for such entries  :(
>
> Another complication is how should we treat cross-app origins?  Do we want
> to treat a DENY entry for one app override all others?  If not, do we want
> to treat appId/isInBrowserElement specially here?  What about future other
> origin attributes?
>
> Can you think of a clean way to address this?
>
>> The problem stems from that the permission manager doesn't store
>> policies, but rather stores unformatted data that is then up to the
>> *reader* to interpret as a policy.
>
>
> Indeed.
>
>> I.e. right now you just call
>> pm.add(, "camera", ALLOW);
>>
>> It is then up to the reader to interpret this as either "camera is
>> available only for https://website.com"; or "camera is available for
>> https://website.com and any subdomain". This is decided by either
>> calling testPermission or testExactPermission.
>>
>> Most developers do not know about this difference and so I have
>> uncountably many times had to tell people to use testExactPermission
>> to get desired behavior. Obviously this is extra bad because
>> testPermission is the function people jump most immediately to due to
>> its simpler name.
>>
>> What I think the permission manager really needs to do is to have an API
>> like:
>>
>> pm.addOriginRule(, "camera", PROMPT);
>> pm.addDomainRule("domain.com", "cookies", DENY, INCLUDE_SUBDOMAINS |
>> OVERRIDE_EXISTING);
>> pm.testPermission(myprincipal, "geolocation");
>
>
> I'd really prefer if we addressed this without attempting to make big
> changes to the permission manager API, as that is a much bigger project than
> what we have been planning to do here and will require the consumers to be
> rewritten.
>
>
>> On Tue, Jun 30, 2015 at 11:58 AM, Ehsan Akhgari 
>> wrote:
>>>
>>> Historically our permissions database has used host names as part of the
>>> permission entry, which means that if we stored a permission for
>>> http://example.com, it would also apply to https://example.com (and
>>> http://example.com:8080 for that matter).  This is undesirable specially
>>> once you note that this potentially makes us store permissions for MITMed
>>> connections and later on use them even for secure origins.
>>>
>>> Michael has been working on fixing this over in bug 1165263.  We expect
>>> to
>>> land this change within the Firefox 42 timeframe.  Here is the details of
>>> the changes we are planning to make:
>>>
>>> 1. Instead of storing a host name, appId and isInBrowserElement flag for
>>> each entry, we will store the full origin (including the origin
>>> attributes.)
>>> 2. Fix up the places where the permission manager APIs expose the notion
>>> of
>>> host/appId/isInBrowserElement to the consumers.
>>> 3. Drop the "" hack from the permissions manager (bug 817007.)
>>>
>>> We're going to use the following algorithm for migrating the existing
>>> permission entries:
>>>
>>>   * If the entry takes the form of a valid URI (such as entries for
>>> file://
>>> URIs), then just insert it directly
>>>   * For each host name foo, check to see whether the Places database
>>> includes a visit to that domain or any subdomain.
>>>* For each found entry in the Places database, we inject a permission
>>> for
>>> the visited origin, with the appId and isInBrowserElement origin
>>> attributes
>>> from the original permission.
>>>* If there are no existing visited entries, inject one permission for
>>> http://foo, and one for https://foo.
>>>
>>> The interesting part of how the migration step works is that we have no
>>> good way to know what origins need the permission after the upgrade by
>>> just
>>> looking at the host name, so we try to find something in the Places
>>> database that would help answer this question, and at the lack of that,
>>> we
>>> assume that the two common origins

Re: Intent to migrate the permissions database to use origins instead of host names

[Jonas Sicking]

On Tue, Jun 30, 2015 at 3:55 PM, Martin Thomson  wrote:
> I wonder, has the subject of double-keying been raised in this
> context?  It comes up frequently in this context. And when I say
> double-keying, I mean forming a key from the tuple of the requesting
> principal and the top level browsing context principal (though origin
> may suffice).
>
> If there are disruptive changes afoot, then segregating based on what
> is shown to the user might be sensible.

Bobby Holley has added infrastructure on nsIPrincipal called
"OriginAttributes" which is intended to be an extension hook to allow
things like double keying. As long as we use the 'origin' attribute on
nsIPrincipal, and make sure that all callers pass in an nsIPrincipal
rather than an nsIURI, then we should be able to relatively easy add
double keying in the future.

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

Re: Intent to migrate the permissions database to use origins instead of host names

[Jonas Sicking]

On Tue, Jun 30, 2015 at 5:50 PM, Jonas Sicking  wrote:
> On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari  
> wrote:
>> On 2015-06-30 6:04 PM, Jonas Sicking wrote:
>>>
>>> There are actually one downside with this change.
>>>
>>> It means that if a user denies access to https://website.com to use
>>> cookies, then http://website.com will still have full ability to use
>>> cookies since it's a different origin.
>>
>>
>> That is a good point.
>>
>> Are you more worried about importing existing DENY entries, or recording new
>> ones?
>
> But I guess.
>
> But I agree I don't see a way to address this without changing the
> nsIPermissionManager API.

That should say "Both I guess".

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

Re: How create a full copy of mozbuild and dependencies at https://github.com/html-shell/mozbuild

[Yonggang Luo]

Well, the https://pypi.python.org/pypi/mozbuild is not enough to building
mozilla source tree, that's why I created mozbuildfull package.

The intention of mozbuildfull is to creating tags version of
mozbuild that can building related version of mozilla source tree and
distributed with
XUL SDK, so we can building other projects that dependent on
mozilla gecko engine
For example mozbuildfull 38.1 can used with
xulrunner SDK 38.1, So we can easily developing things
without the need of full gecko source tree. (It's really to big(2.4GB)!)



2015-07-01 0:19 GMT+08:00 Gregory Szorc :
> The mozbuild Python package is available on PyPI:
> https://pypi.python.org/pypi/mozbuild
>
> It's also possible to obtain an archive of the source from hg.mozilla.org.
> See the instructions for the "archive" command/URL at
> https://hg.mozilla.org/mozilla-central/help/hgweb.
>
> I would strongly prefer to not extract the files into a standalone GitHub
> project, as that will make merging differences harder and could lead to a
> permanent fork, which isn't conducive to the health of mozbuild at this
> juncture, IMO.
>
>
> On Mon, Jun 29, 2015 at 10:36 PM, 罗勇刚(Yonggang Luo) 
> wrote:
>>
>> I think doing this can getting mozbuild can be used
>> as a independent software without the gecko source tree.
>>
>>
>>
>> --
>>  此致
>> 礼
>> 罗勇刚
>> Yours
>> sincerely,
>> Yonggang Luo
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Largest chunks of code that are likely to be removable?

[Joshua Cranmer 🐧]

On 6/30/2015 6:01 AM, Axel Hecht wrote:

On 6/30/15 9:13 AM, Mike Hommey wrote:

On Mon, Jun 29, 2015 at 11:19:08PM -0700, Nicholas Nethercote wrote:

Hi,

I'm wondering what the largest chunks of code there are in the
codebase that are candidates for removal, i.e. probably with a bit of
work but not too much.

One that comes to mind is rdf/ (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1176160#c5) though I
don't have a good understanding of how much stuff depends on it, even
having seen https://bugzilla.mozilla.org/show_bug.cgi?id=420506.


See the dependencies of bug 833098.

Mike



Note, that bug has the dependencies to move rdf/ from mozilla-central 
into comm-central. mail has many more dependencies on RDF, I think.


The mailnews catch-all bug for removing RDF is 
. Off the top 
of my head, the biggest use is as a hashtable for folder URIs to folder 
objects (which could easily be replaced in a pinch), but it's also used 
in a minor way in the account creation dialog, as well as the backing 
store for RSS. The RDF templating widget feature, though, is used in 
about four places in Thunderbird and much, much more in SeaMonkey.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

[Joshua Cranmer 🐧]

On 6/30/2015 4:35 PM, Jeff Muizelaar wrote:

I believe this is predicated on removing the implicit conversion from
nsRefPtr to T*


You'd get the same benefit, I think, by making operator T*() && = 
delete;, syntax which is accepted on gcc 4.8.1+, clang, and MSVC 2015 IIRC.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: web-platform-tests on debug builds running on try

[Hiroyuki Ikezoe]

Hi!

Just FYI

The try result [1] shows only
/html/semantics/embedded-content/the-img-element/current-pixel-density/basic.html, 
but /service-workers/service-worker/fetch-csp.https.html is another 
suspicion.


See
https://treeherder.mozilla.org/logviewer.html#?job_id=8942921&repo=try
and
https://treeherder.mozilla.org/logviewer.html#?job_id=8946879&repo=try

On 07/01/15 08:35, James Graham wrote:

Web-platform-tests are now running in debug builds on try only. However
due to some teething problems, they are not currently all green. This is
expected to be fixed in the next 24 hours but, in the meantime, if you
see some orange that seems unrelated to your change, particularly orange
that looks like [1], please don't panic; it's likely safe to ignore (if
there is a sheriff reading this, we should possibly hide those jobs
temporarily).

Sorry for the inconvenience this has caused.

[1] https://treeherder.mozilla.org/logviewer.html#?job_id=8927888&repo=try
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


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

Strange Error: Reentrancy error: some client,attempted to display a message to the console while in a console,listener

[ishikawa]

Hi,

I am not sure where to ask and so ask three mailing lists.

First off, TB 38.0.1 after many months of waiting  solved many outstanding
issues,
Great.
I hope we can correct many remaining issues in the months ahead.

I am testing full debug build of C-C TB locally.
This is done by running
|make xpcshell-tests| to run xpcshell unit tests.

I have noticed a few new errors in the last week or so after the code
has been refreshed.

These errors/warnings are new additions and I am trying to eliminate them.

A case in point. A strange error I have never seen before.

PROCESS | 14289 | [14289] WARNING: Reentrancy error: some client
attempted to display a message to the console while in a console
listener. The following message was discarded: "[JavaScript Error:
"TypeError: do_print is not a function" {file:
"/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js" line:
130}]": file
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/base/nsConsoleService.cpp,
line 198


I looked at nsConsoleService.cpp:
comm-central/mozilla/xpcom/base/nsConsoleService.cpp, line 198


193   if (NS_IsMainThread() && mDeliveringMessage) {
194 nsCString msg;
195 aMessage->ToString(msg);
196 NS_WARNING(nsPrintfCString("Reentrancy error: some client attempted "
197   "to display a message to the console while in a console listener. "
198   "The following message was discarded: \"%s\"", msg.get()).get());
199 return NS_ERROR_FAILURE;
200   }

My understanding: It looks that when a thread tries to print
something to the console while it is in a console listener, the
code, in this case, C-C TB suppresses/discards the new message because
such printing may lead to an infinite recursion as in this case.

Basically, here a warning is going to be printed by the routine that
was invoked, but then since |do_print| is not deemed a function in
JS-side of execution, and the thread would have called the display
routine again, and during new invocation, there probably this warning
about missing function
definition of |do_print| is regenerated, ... ad infinitum. (This is a
possibility and the code tries to avoid invoking output to the console
recursively.)


Now, this warning about suppressing/discarding error message is only
printed for DEBUG BUILD (|NS_WARNING| is used).

I think that is why not many people seem to have noticed this issue.

I am afraid this is a serious issue since a proper error message about
printing mechanism is getting lost.

So anyway, then I checked head.js. That is where mysterious errors are produced.

comm-central/ mozilla/ testing/ xpcshell/ head.js

I found the situation strange because |do_print| is declared as a
function at the top level if I am not mistaken.

Maybe the error is generated before |do_print()| is defined?


621 /**
622  * Prints a message to the output log.
623  */
624 function do_print(msg, data) {
625   msg = _wrap_with_quotes_if_necessary(msg);
626   data = data ? data : null;
627   _testLogger.info(msg, data);
628 }

And it was referenced in |observe|

129 observe : function (msg) {
130   do_print("CONSOLE_MESSAGE: (" + levelNames[msg.logLevel] + ")
" + msg.toString());
131 }


Funny, thought I. This is because |do_print| ought to be visible to
|observe| (*IIF* it has been defined at runtime before |observe| is called.)
I moved the definition of |do_print| to an earlier position, but
It did not seem to make any difference.

But I thought, OK, here is a listener, and maybe the runtime
context/closure/whatever under which |observe| may operate is not
quite the same as that of the definition time, and I copied the
|do_print| definition to |observe| body so that it *IS* always visible.

This was done by adding the following inside|observe| body just before
|do_print| is called.

  let do_print = function (msg, data) {
msg = _wrap_with_quotes_if_necessary(msg);
data = data ? data : null;
_testLogger.info(msg, data);
  }

Of course, this shut up the warning/error about |do_print|.
But then I have complaints about |_wrap_with_quotes_if_necessary| and
|_testLogger| naturally.

When I copied the definition of other functions such as
|_wrap_with_quotes_if_necessary| and |_testLogger|, using "id =
function (arg) {...}" construct one by one as the error message
suggests |observe| is missing, eventually I could eliminate all the
warnings except for one about |Components|

PROCESS | 3996 | JavaScript error:
/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js, line
159: TypeError: Components is undefined

At this point, finally, I said, this IS strange (!)
|Components| ought to be visible to all JS code (?!)
Or isn't it implicit and the file needs an import or something?
Or am I missing something?
Or maybe now head.js is invoked in an incorrect manner by the test
framework?

Since the errors are rather new, I checked the log.
I noticed this "head.js" have a four patches applied in the last two months, and
one of them was as foll

Re: Secure contexts required for new web platform features

[Anne van Kesteren]

On Tue, Jun 30, 2015 at 11:18 PM, Boris Zbarsky  wrote:
> On 6/30/15 5:00 PM, Richard Barnes wrote:
>> Second, when we implement new web platform features, they will be enabled
>> only on secure contexts.
>
> Might I ask who this "we" is (I don't recall general DOM module owner buy-in
> on this, but maybe I missed it?)

Platform. There was no strong opposition to the "Intent to deprecate:
Insecure HTTP" thread and in Whistler everyone attending the
deprecating non-secure HTTP session agreed. Do you think this needs to
be approached differently?


> what the definition of "new web platform
> features" is (e.g. does the webperf translateTime thing count?

Yes, anything for which Platform creates Intent to Implement/Ship threads.


> What about
> adding the performance timing APIs we already ship for Window to workers?),

The idea is that you indicate in the Intent to Implement/Ship thread
whether you want an exception to the secure context restriction. The
module owner based on input from dev.platform then decides whether an
exception is warranted.


> and whether there's actually a stable definition of secure contexts that
> everyone agrees on?

There's a definition Google and us use to implement service workers.
That definition has been fairly stable though there are some small
issues to be sorted out.


>> Exceptions can be granted
>
> Who makes that call?  Based on what criteria?

Module owners, based on dev.platform input to the Intent to
Implement/Ship threads. No criteria were established. Hopefully
something that can be learned over time.


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

Re: Strange Error: Reentrancy error: some client, attempted to display a message to the console while in a console,listener

[Robert Strong]

I've only seen those when anything tries to print to the console after a
test has called do_test_finish and in that case I suspect it is due to
xpcshell shutting down, etc.

Robert

On Tue, Jun 30, 2015 at 11:35 PM, ishikawa  wrote:

> Hi,
>
> I am not sure where to ask and so ask three mailing lists.
>
> First off, TB 38.0.1 after many months of waiting  solved many outstanding
> issues,
> Great.
> I hope we can correct many remaining issues in the months ahead.
>
> I am testing full debug build of C-C TB locally.
> This is done by running
> |make xpcshell-tests| to run xpcshell unit tests.
>
> I have noticed a few new errors in the last week or so after the code
> has been refreshed.
>
> These errors/warnings are new additions and I am trying to eliminate them.
>
> A case in point. A strange error I have never seen before.
>
> PROCESS | 14289 | [14289] WARNING: Reentrancy error: some client
> attempted to display a message to the console while in a console
> listener. The following message was discarded: "[JavaScript Error:
> "TypeError: do_print is not a function" {file:
> "/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js" line:
> 130}]": file
> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/base/nsConsoleService.cpp,
> line 198
>
>
> I looked at nsConsoleService.cpp:
> comm-central/mozilla/xpcom/base/nsConsoleService.cpp, line 198
>
>
> 193   if (NS_IsMainThread() && mDeliveringMessage) {
> 194 nsCString msg;
> 195 aMessage->ToString(msg);
> 196 NS_WARNING(nsPrintfCString("Reentrancy error: some client
> attempted "
> 197   "to display a message to the console while in a console
> listener. "
> 198   "The following message was discarded: \"%s\"", msg.get()).get());
> 199 return NS_ERROR_FAILURE;
> 200   }
>
> My understanding: It looks that when a thread tries to print
> something to the console while it is in a console listener, the
> code, in this case, C-C TB suppresses/discards the new message because
> such printing may lead to an infinite recursion as in this case.
>
> Basically, here a warning is going to be printed by the routine that
> was invoked, but then since |do_print| is not deemed a function in
> JS-side of execution, and the thread would have called the display
> routine again, and during new invocation, there probably this warning
> about missing function
> definition of |do_print| is regenerated, ... ad infinitum. (This is a
> possibility and the code tries to avoid invoking output to the console
> recursively.)
>
>
> Now, this warning about suppressing/discarding error message is only
> printed for DEBUG BUILD (|NS_WARNING| is used).
>
> I think that is why not many people seem to have noticed this issue.
>
> I am afraid this is a serious issue since a proper error message about
> printing mechanism is getting lost.
>
> So anyway, then I checked head.js. That is where mysterious errors are
> produced.
>
> comm-central/ mozilla/ testing/ xpcshell/ head.js
>
> I found the situation strange because |do_print| is declared as a
> function at the top level if I am not mistaken.
>
> Maybe the error is generated before |do_print()| is defined?
>
>
> 621 /**
> 622  * Prints a message to the output log.
> 623  */
> 624 function do_print(msg, data) {
> 625   msg = _wrap_with_quotes_if_necessary(msg);
> 626   data = data ? data : null;
> 627   _testLogger.info(msg, data);
> 628 }
>
> And it was referenced in |observe|
>
> 129 observe : function (msg) {
> 130   do_print("CONSOLE_MESSAGE: (" + levelNames[msg.logLevel] + ")
> " + msg.toString());
> 131 }
>
>
> Funny, thought I. This is because |do_print| ought to be visible to
> |observe| (*IIF* it has been defined at runtime before |observe| is
> called.)
> I moved the definition of |do_print| to an earlier position, but
> It did not seem to make any difference.
>
> But I thought, OK, here is a listener, and maybe the runtime
> context/closure/whatever under which |observe| may operate is not
> quite the same as that of the definition time, and I copied the
> |do_print| definition to |observe| body so that it *IS* always visible.
>
> This was done by adding the following inside|observe| body just before
> |do_print| is called.
>
>   let do_print = function (msg, data) {
> msg = _wrap_with_quotes_if_necessary(msg);
> data = data ? data : null;
> _testLogger.info(msg, data);
>   }
>
> Of course, this shut up the warning/error about |do_print|.
> But then I have complaints about |_wrap_with_quotes_if_necessary| and
> |_testLogger| naturally.
>
> When I copied the definition of other functions such as
> |_wrap_with_quotes_if_necessary| and |_testLogger|, using "id =
> function (arg) {...}" construct one by one as the error message
> suggests |observe| is missing, eventually I could eliminate all the
> warnings except for one about |Components|
>
> PROCESS | 3996 | JavaScript error:
> /NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js, line
> 159: TypeErro

Re: Intent to migrate the permissions database to use origins instead of host names

[Michael Layzell]

The patches I am working on already use Bobby Holley's OriginAttributes, in
fact we use the origin attribute on the nsIPrincipal, and only expose an
nsIPrincipal from the API.

Internally, we use the origin attribute for serialization, but to external
consumers of the API, all that is available are APIs for adding and
removing permissions VIA nsIPrincipal, and some convenience methods which
exist for legacy reasons which allow you to add/remove permissions via
nsIURIs, creating NoAppCodebasePrincipals for them. You are right, that if
we decide that double keying is something we want, that it would be
possible to add it to the permission manager by simply modifying
nsIPrincipal's OriginAttributes.

In terms of a mechanism for DENY being treated differently, it would be
possible (albeit very hacky) to always insert DENY entries for URIs with a
host property at http://HOST, and then, during the lookup, also check
http://HOST, and if it is DENY, expose a DENY for the other origin. I don't
really like this solution, as it creates lots of edge cases and other
complications which I'm not sure if we want to expose to API consumers, as
well as making the semantics of permissions diverge from nsIPrincipals,
(the coherence of the new semantics with nsIPrincipal is something I quite
like).

On Tue, Jun 30, 2015 at 8:53 PM, Jonas Sicking  wrote:

> On Tue, Jun 30, 2015 at 3:55 PM, Martin Thomson  wrote:
> > I wonder, has the subject of double-keying been raised in this
> > context?  It comes up frequently in this context. And when I say
> > double-keying, I mean forming a key from the tuple of the requesting
> > principal and the top level browsing context principal (though origin
> > may suffice).
> >
> > If there are disruptive changes afoot, then segregating based on what
> > is shown to the user might be sensible.
>
> Bobby Holley has added infrastructure on nsIPrincipal called
> "OriginAttributes" which is intended to be an extension hook to allow
> things like double keying. As long as we use the 'origin' attribute on
> nsIPrincipal, and make sure that all callers pass in an nsIPrincipal
> rather than an nsIURI, then we should be able to relatively easy add
> double keying in the future.
>
> / Jonas
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform