Re: Largest chunks of code that are likely to be removable?
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?
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 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: Intent to migrate the permissions database to use origins instead of host names
On Tue, Jun 30, 2015 at 3:55 PM, Martin Thomson m...@mozilla.com 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: Largest chunks of code that are likely to be removable?
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 https://bugzilla.mozilla.org/show_bug.cgi?id=mail-killrdf. 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: Intent to migrate the permissions database to use origins instead of host names
On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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(https://website.com, 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(https://website.com, 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 ehsan.akhg...@gmail.com 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 file 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
Re: Intent to migrate the permissions database to use origins instead of host names
On Tue, Jun 30, 2015 at 5:50 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
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 g...@mozilla.com: 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) luoyongg...@gmail.com 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?
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: web-platform-tests on debug builds running on try
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=8942921repo=try and https://treeherder.mozilla.org/logviewer.html#?job_id=8946879repo=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=8927888repo=try ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Hiroyuki Ikezoe hiike...@mozilla-japan.org ___ 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
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) luoyongg...@gmail.com 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
mozilla::TemporaryRef is gone; please use already_AddRefed
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
Intent to migrate the permissions database to use origins instead of host names
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 file 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
Secure contexts required for new web platform features
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: Largest chunks of code that are likely to be removable?
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
Largest chunks of code that are likely to be removable?
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
Re: Largest chunks of code that are likely to be removable?
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: Intent to migrate the permissions database to use origins instead of host names
On Tue, Jun 30, 2015 at 4:18 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
Re: Intent to ship Notification API on Web Workers
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
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
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
web-platform-tests on debug builds running on try
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=8927888repo=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
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 jo...@sicking.cc 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(https://website.com, 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(https://website.com, 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 ehsan.akhg...@gmail.com 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 file 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
