This engineering update is also available on the Platform/2015-03-03
wiki: https://wiki.mozilla.org/Platform/2015-03-03
# Firefox Release Schedule
The next merge date is March 30, just four weeks away. Firefox 37 and 38
releases have been moved up one week to avoid conflicts with holidays.
F
The web already has a bunch of features that require permission UI,
such as passwords, geolocation, notifications, WebRTC, etc.
With service workers this will grow with permissions for push,
persistent storage, one-off synchronization, and periodic
synchronization. And likely more going forward.
On Tue, Mar 3, 2015 at 12:40 PM, Anne van Kesteren wrote:
> I'd like to ask that we start investigating how to best present these
> to the user, including their persistence and implications. As well as
> strongly considering updating about:preferences to reveal how much we
> store for each page (a
The good news is that most of the complicated bits are already
implemented. See about:permissions.
Though it operates on hostnames and not origins (bug 1066517).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listi
On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun wrote:
> The good news is that most of the complicated bits are already
> implemented. See about:permissions.
That seems like a good start, although it fails to cover a number of
things, such as cache, storage APIs, and the notifications API. And we
On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren wrote:
> On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun wrote:
> > The good news is that most of the complicated bits are already
> > implemented. See about:permissions.
>
> That seems like a good start, although it fails to cover a number of
> t
On 2015-03-03 9:36 AM, Eric Rescorla wrote:
On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren mailto:ann...@annevk.nl>> wrote:
On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun mailto:fbr...@mozilla.com>> wrote:
> The good news is that most of the complicated bits are already
> implem
On 3/3/2015 2:46 AM, Chris Peterson wrote:
IndexedDB performance work will also land soon: bug 866846 will enable
SQLite’s WAL journal and bug 1112702 will change transactions to be
non-durable. These SQLite options favor performance over durability
like Chrome and IE do. They do not increase t
Yes, there will be a non-standard (for now) flag that you can pass in when
initiating a transaction to indicate that you want durability.
- Kyle
On Tue, Mar 3, 2015 at 8:05 AM, Joshua Cranmer 🐧
wrote:
> On 3/3/2015 2:46 AM, Chris Peterson wrote:
>
>> IndexedDB performance work will also land so
Support for the previously announced [1] intention to use moz.build to
define metadata for files has now landed on mozilla-central with the
landing of bug 1132771 [2].
This is important to you because there are plans to leverage this metadata
to make it easier to get stuff done. Some potential use
Anne van Kesteren schrieb:
I'd like to ask that we start investigating how to best present these
to the user, including their persistence and implications.
Note that one idea that I had about 5 years back is implemented by default in SeaMonkey
as "Data Manager" and available as a Firefox add-o
+1, Philipp has thought about this a lot. Also: I'm really glad we're
having this conversation. We want to tackle this sooner than later.
On Mar 3, 2015 6:48 PM, "Justin Dolske" wrote:
> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated
Is there any kind of existing code around that would look at the bugs for
the commits for the files in a directory and create some kind of count of
the components they were filed in? dom/ has something like 90
subdirectories, and it would be nice to be able to quickly get some kind of
census like
This spreadsheet contains a list of files and their most frequently
associated bug component from commits landed since 2014.
https://docs.google.com/spreadsheets/d/1cz2-UC_LN_OFM2q67rKi6Mo-2TpdN8fTiH8LstZJ4PM/edit?usp=sharing
If a file is missing, it likely hasn't been modified in the past ~14 mo
On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske wrote:
> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated bits." Quite the opposite, really: it
> was a useful experiment, but has some serious problems. I'd briefly
> summarize the two main
(Added dev.platform back.)
On Tue, Mar 3, 2015 at 7:04 PM, Shane Caraveo wrote:
> I tend to agree with Gerv, there should be an overly simplistic top level "I
> trust [social network name] to do something wrong but let them do it anyway"
> setting with a way to dig into more detailed settings if
16 matches
Mail list logo
