Re: [meta] "Intent to implement" and Security & Privacy concerns
On 01.04.2015 08:28, Tantek Çelik wrote: > One of the suggested additions to "intent to implement" emails: > > https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement > > is a statement regarding Security & Privacy concerns, because those > have often been noted as brief summary statements in some past "intent > to implement" emails. > > There has been some discussion among various W3C/TAG etc. folks of > adding a security self-review to W3C specifications, based on this > strawman list of questions to answer (e.g. perhaps informatively in a > section in a spec) > > https://mikewest.github.io/spec-questionnaire/security-privacy/ > > Until specs start publishing their answers to these security/privacy > questions, should we consider doing so at least as part of "Intent to > implement"? > Yes! I found it quite useful to work on these questions. And those specs who don't answer them, might even take it as a pull request :) > Thoughts? > > Tantek > ___ > 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
IndexedDB transactions are no longer durable by default, and other changes
Hi folks,
Just a heads up that some big-ish changes to IndexedDB landed today on m-c.
1. The main change that affects users is bug 1112702, which switched IndexedDB
databases to be non-durable by default.
2. The the schema version for all databases has changed, so once you open a
database on trunk builds and it upgrades you will not be able to open that same
database in an aurora/beta/release build.
Details follow!
1. IndexedDB databases are now non-durable by default. This means that
"versionchange" and "readwrite" transactions will now fire "complete" events
after the transaction has committed but potentially before all data has been
written to disk. If a crash or power loss occurs at just the right moment then
the transaction will be lost/rolled back. It should still be impossible to ever
see database corruption though. This will mean faster delivery of "complete"
events, and more closely aligns with the performance vs. stability tradeoffs
other browser vendors have chosen.
The IndexedDB API does not currently have a way to say "no, really, I want to
make sure that this important data is saved to disk before I continue". Some
examples might be things like saving contacts, reservation confirmations,
one-time download tokens, etc. We will work with the spec authors to get
something in v2 of the IndexedDB specification for this.
In the meantime, if the "dom.indexedDB.experimental" pref is set (defaults to
|false| in Firefox and |true| in B2G, I think), you can specify the
"readwriteflush" transaction mode if you want to ensure that data is written to
disk before the "complete" event is delivered. E.g.:
var transaction1 = db.transaction("foo", "readwrite");
// Use transaction1...
transaction1.oncomplete = event => {
// Data may not yet be written to disk! A crash or power loss
// here could roll this transaction back.
};
// With "dom.indexedDB.experimental" set to |true|:
var transaction2 = db.transaction("foo", "readwriteflush");
// Use transaction2...
transaction2.oncomplete = event => {
// Data is guaranteed to be written to disk. A crash or power
// loss here will retain this transaction.
};
Waiting for data to be flushed to disk can take a long time, so unless the data
you're saving is critical/non-recoverable then you should probably be fine
continuing to use the "readwrite" transaction mode.
2. The database schema and journal mode have changed, and it should
dramatically decrease the size on disk of databases for desktop builds and
should increase performance of many operations due to decreased I/O. To do this
we have to rebuild the schema of the database on first load and that process
might take a little while, so be on the lookout for slowly opening databases.
Thankfully this is only required once, but thereafter these databases won't
work in an older build! Jumping back and forth between
nightly/aurora/beta/release builds will not work.
Please file any issues you see in Core:DOM::IndexedDB. Thanks!
-bent
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: DevTools and Intent to Implement process
On Tue, Mar 31, 2015 at 3:47 PM, Jet Villegas wrote: > We've started implementing the Web Animations API [1] with very early > collaboration with the Dev Tools team and have seen very promising results. > Is that a model we can continue to follow or modify to suit? While I was not directly involved in this work, I believe that model worked well overall from what I could tell. Getting involved early does mean things may be less stable or subject to change as Patrick mentions[1], but the benefits of early feedback for both platform and DevTools teams are still much more valuable overall. I am sure we can smooth out this process in the future, as I've only seen it happen a few times so far. So yes, I think it's a good model to work from. Let's do more of it! [1]: https://groups.google.com/d/msg/mozilla.dev.developer-tools/fZOxb3t0Npk/_LXhVKSgs6EJ - Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
On Wed, Apr 1, 2015, at 03:02 PM, ben turner (bent) wrote: > In the meantime, if the "dom.indexedDB.experimental" pref is set > (defaults to |false| in Firefox and |true| in B2G, I think) I don't think it's set to true for B2G right now. I don't see such a mapping in https://dxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js, or elsewhere with a search of https://dxr.mozilla.org/mozilla-central/search?q=dom.indexedDB.experimental&case=false. And there doesn't seem to be code in gaia/build that messes with the pref either. I also attached the WebIDE to my trunk Flame device and did "Runtime...Preferences" and searched for the pref, and I found it to have the value false there. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
On Wed, Apr 1, 2015, at 03:02 PM, ben turner (bent) wrote: > If a crash or power loss occurs at just > the right moment then the transaction will be lost/rolled back. It should > still be impossible to ever see database corruption though. This will > mean faster delivery of "complete" events, and more closely aligns with > the performance vs. stability tradeoffs other browser vendors have > chosen. Can you clarify the risk profile a little more? Specifically: - Crash-wise, are we talking about only the parent process crashing, or are we talking about the child process crashing too? - For power loss for B2G on mobile, battery-powered devices, the following sources of power loss seem to come to mind: 1. Device shutdown via the UI 2. User pulls the battery. (More likely, QA pull the battery :) 3. Hardware-shutdown via long-hold of the power button. (Because of apparent device lockup, user is QA, or accidental triggering due to pockets/device placement.) 4. Device runs out of power. It seems like we can probably avoid the problems during 1: normal device shutdown. Is it your/anyone's understanding that gecko and IndexedDB will get a chance to cleanly shutdown and an fsync will happen? I don't think we can do anything for 2: battery pulled (although if there's a back-cover-sensor...) For 3: long-power-button-hold it seems like depending on how extensively things are wedged, we could notice at say 6 seconds that we're headed for a shutdown and try to trigger an fsync and put a stop to new transactions. For 4: low-power, ideally there's just a point that the device decides it's not safe to operate and shuts itself down, and that's slightly before it would result in IndexedDB badness. My main question is what is a realistic risk model for power loss/crash and are there mitigations we can put in place to reduce the risk to users? The best example I have of this is when a QA tester was adding a contact to the contacts app and then pulling the battery on the device. This did find real bugs, but in terms of use-cases to engineer for, I don't think it's a valid use-case to add a contact and then immediately pull the battery. I do think it's a valid use-case to add a contact and then shutdown the device via the UI once the user has seen implied visual confirmation that the operation has completed. (I think in the case of that bug, the window of vulnerability was shockingly long.) On the flip side, desktop users on mains power are usually going to have a failure model that looks like 2: QA pulling the battery when the mains go out. But at the same time, it's understood that if your computer loses power, you very well may lose some work and a UPS may be advisable on unstable power. The issue there is how long the IndexedDB window of vulnerability is. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [meta] "Intent to implement" - captured some docs on wikimo
Should we add documentation for this to the Developer Guide on MDN? We cover a lot of the development process there, so it may be wise to include this information there, unless someone can think of a good reason not to. On Tue, Mar 31, 2015 at 9:08 PM, Jonas Sicking wrote: > Ah, sorry, I misunderstood the intent of the wiki page. I retract my concern. > > / Jonas > > On Wed, Apr 1, 2015 at 12:41 AM, Tantek Çelik wrote: >> Having pages go out of date can certainly be a challenge, hence why >> this wiki page is descriptive (citing historical examples and other >> external resources), rather than prescriptive. >> >> No additional risk of becoming out of date beyond that from already >> existing pages. It's a general good practice to write wiki-pages in >> such a future-defensive way. >> >> I'll also add a note about any questions about "intent to ..." should >> go to dev-platform to provide direction should anything actually go >> out of date and someone is potentially confused. >> >> Thanks, >> >> Tantek >> >> On Tue, Mar 31, 2015 at 3:10 PM, Jonas Sicking wrote: >>> Will someone be maintaining this page? I'm worried that having an >>> out-of-date page might create more confusion than information. >>> >>> / Jonas >>> >>> On Tue, Mar 31, 2015 at 3:58 AM, Tantek Çelik >>> wrote: Having followed the "Intent to implement" emails for a while, and noticing that there was already an email template for it on wikimo: https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement I went ahead and wrote up a page about this practice, along with links to Blink/MS equivalents: https://wiki.mozilla.org/Intent_to_implement Hopefully others find this useful. Feedback and as usual, direct edits/contribution to the page welcome and encouraged. Thanks, Tantek ___ 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 -- Eric Shepherd Senior Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: CSS Scroll Snapping on Desktop
FWIW documenting and providing examples for this is a candidate for a Q2 deliverable for the MDN content team. I do not make promises yet, however. ;) On Mon, Mar 30, 2015 at 9:37 PM, Tantek Çelik wrote: > From the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1138658 > > This will be on by default in 39 right? > > Do we have any nice example pages to show it off? > > Being able to use CSS Snap Points has also come up in recent > #indiewebcamp discussions, so FWIW, there are also independent web > developers who are ready and eager to implement this on their own > websites as well, in case you're looking for examples for your hacks > blog post. > > Thanks, > > Tantek > > On Mon, Mar 16, 2015 at 3:34 PM, Robert O'Callahan > wrote: >> On Tue, Mar 17, 2015 at 11:07 AM, Ehsan Akhgari >> wrote: >> >>> Is this feature worth having a hacks blog post about? (hint: I think so!) >> >> >> Yes! >> >> 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 -- Eric Shepherd Senior Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: nsMemory::Alloc, nsMemory::Free, nsMemory::Realloc are no more (Was: PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more)
And now, nsMemory::Alloc, nsMemory::Free and nsMemory::Realloc are gone as well. Mike On Tue, Mar 31, 2015 at 02:59:20PM +0900, Mike Hommey wrote: > Hi, > > In the next few weeks, there is going to be a reduction in the number of > our memory allocator wrappers/functions, for essentially the following > reasons: > - we have too many of them, > - developers rarely know which one to use, which results in: > - developers often make mistakes[1] > > This started today with the landing of bug 1138293, which effectively > removed moz_malloc, moz_realloc, moz_calloc and moz_free. > > They were replaced, respectively, with malloc, realloc, calloc and free, > because that works™. > > If you have pending patches that use moz_malloc, moz_realloc, > moz_calloc, moz_free, you can just remove the moz_ prefix. > > The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist, > and memory allocated with them can be freed with free. > > With that being said, please refrain from using any of the functions > mentioned above. Please prefer the C++y new and delete. new is > infallible by default (equivalent to moz_xmalloc). If you need an > equivalent to moz_malloc, use fallible new instead: > > new (fallible) Foo() > > Please note that this shouldn't make uplifting harder. Platform patches > using malloc/free/new/delete should apply and work just fine on beta, > aurora and esr (with a few exceptions ; if you uplift something from > mfbt/mozglue that uses the memory allocator, please check with me). > > Cheers, > > Mike > > > 1. if you look for it, you'll find cases of one family used for >allocation and another for deallocation, for possibly close to all >combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc, >new). > ___ > 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: IndexedDB transactions are no longer durable by default, and other changes
On Wed, Apr 1, 2015, at 05:12 PM, Andrew Sutherland wrote: > On Wed, Apr 1, 2015, at 03:02 PM, ben turner (bent) wrote: > > If a crash or power loss occurs at just > > the right moment then the transaction will be lost/rolled back. It should > > still be impossible to ever see database corruption though. This will > > mean faster delivery of "complete" events, and more closely aligns with > > the performance vs. stability tradeoffs other browser vendors have > > chosen. > > Can you clarify the risk profile a little more? Specifically: And I forgot one other thing: - Wake lock interaction. Could there be a problem if an application drops its wake-lock in the oncomplete notification for the transaction? (Or does IndexedDB hold a wake-lock to cover this and/or the kernel take care to flush dirty pages to disk before suspending/etc.?) Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
On Wednesday, April 1, 2015 at 1:40:07 PM UTC-7, somb...@gmail.com wrote: > I don't think it's set to true for B2G right now. Oops, you're right. It looks like it's false everywhere currently. -bent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com wrote: > - Crash-wise, are we talking about only the parent process crashing, or > are we talking about the child process crashing too? I was talking just about the parent process. If the child process crashes then whether or not the transaction is durable depends on whether or not the parent received the commit message and processed it (otherwise we automatically abort any outstanding transactions). That behavior is unchanged. > 1. Device shutdown via the UI This should be fine, we will flush to disk before actually powering down. > 2. User pulls the battery. > 3. Hardware-shutdown via long-hold of the power button. > 4. Device runs out of power. These three cases may fail to flush the data to disk, and if so when we restart the transaction will be rolled back. > For 3: long-power-button-hold it seems like > depending on how extensively things are wedged, we could notice at say 6 > seconds that we're headed for a shutdown and try to trigger an fsync and > put a stop to new transactions. That sounds reasonable, assuming we get that notification at the gecko layer? I am not sure what kind of info we get when long-presses happen. > For 4: low-power, ideally there's just > a point that the device decides it's not safe to operate and shuts > itself down, and that's slightly before it would result in IndexedDB > badness. I don't know, but if it goes through normal shutdown then we will be fine. > My main question is what is a realistic risk model for power loss/crash > and are there mitigations we can put in place to reduce the risk to > users? > ... > The issue there is how long the IndexedDB window of vulnerability is. Flushing happens automatically after the database is idle (i.e. no active transactions) for 2 seconds at present. If the database never goes idle for that long then we continue to journal until the WAL size exceeds 20MB on desktop or 10MB on mobile. > - Wake lock interaction. Good question. I don't know of any testing in this area. IndexedDB does not hold an explicit wake lock at present. -bent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
On Thu, Apr 2, 2015 at 3:00 AM, ben turner (bent) wrote: > On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com wrote: >> - Crash-wise, are we talking about only the parent process crashing, or >> are we talking about the child process crashing too? > > I was talking just about the parent process. If the child process crashes > then whether or not the transaction is durable depends on whether or not the > parent received the commit message and processed it (otherwise we > automatically abort any outstanding transactions). That behavior is unchanged. That doesn't sound entirely right. As soon as the child process received the last "success" event for a given request in a transaction, and we've sent the "go ahead and commit" message to the parent, then I would expect that it's ok for the child to crash at any point. This might match what you are saying. However the more important question that I believe Andrew is asking, is if we receive a "commit" event, what can then crash without there being a dataloss. My understanding is that at that point both the child and the parent can crash. As long as the kernel doesn't panic, or the battery runs out or is removed, the data will be written. I.e. once the "commit" event fires, the data has been transferred to the OS, and as long as the OS shuts down cleanly, or has time to flush, the data will be safe. >> 1. Device shutdown via the UI > > This should be fine, we will flush to disk before actually powering down. > >> 2. User pulls the battery. >> 3. Hardware-shutdown via long-hold of the power button. >> 4. Device runs out of power. > > These three cases may fail to flush the data to disk, and if so when we > restart the transaction will be rolled back. > >> For 3: long-power-button-hold it seems like >> depending on how extensively things are wedged, we could notice at say 6 >> seconds that we're headed for a shutdown and try to trigger an fsync and >> put a stop to new transactions. > > That sounds reasonable, assuming we get that notification at the gecko layer? > I am not sure what kind of info we get when long-presses happen. I would think that when long-press happens, the CPU simply receives a reset signal. So it's equivalent to pulling the battery and putting it back. But maybe the OS is sent a signal a few seconds prior to that which would encourage it to flush. I'm not sure. >> For 4: low-power, ideally there's just >> a point that the device decides it's not safe to operate and shuts >> itself down, and that's slightly before it would result in IndexedDB >> badness. > > I don't know, but if it goes through normal shutdown then we will be fine. I'm pretty sure this results in the OS getting shut down cleanly, and so will flush any data it still holds. I.e. the data should be safe given my answer at the top. >> My main question is what is a realistic risk model for power loss/crash >> and are there mitigations we can put in place to reduce the risk to >> users? >> ... >> The issue there is how long the IndexedDB window of vulnerability is. > > Flushing happens automatically after the database is idle (i.e. no active > transactions) for 2 seconds at present. If the database never goes idle for > that long then we continue to journal until the WAL size exceeds 20MB on > desktop or 10MB on mobile. But prior to that flushing the data has been write()ten, right? So the OS will take care of flushing it eventually as long as it's shut down cleanly. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
Please unsubscribe me On Wed, Apr 1, 2015 at 9:26 PM Jonas Sicking wrote: > On Thu, Apr 2, 2015 at 3:00 AM, ben turner (bent) > wrote: > > On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com > wrote: > >> - Crash-wise, are we talking about only the parent process crashing, or > >> are we talking about the child process crashing too? > > > > I was talking just about the parent process. If the child process > crashes then whether or not the transaction is durable depends on whether > or not the parent received the commit message and processed it (otherwise > we automatically abort any outstanding transactions). That behavior is > unchanged. > > That doesn't sound entirely right. > > As soon as the child process received the last "success" event for a > given request in a transaction, and we've sent the "go ahead and > commit" message to the parent, then I would expect that it's ok for > the child to crash at any point. This might match what you are saying. > > However the more important question that I believe Andrew is asking, > is if we receive a "commit" event, what can then crash without there > being a dataloss. My understanding is that at that point both the > child and the parent can crash. As long as the kernel doesn't panic, > or the battery runs out or is removed, the data will be written. > > I.e. once the "commit" event fires, the data has been transferred to > the OS, and as long as the OS shuts down cleanly, or has time to > flush, the data will be safe. > > >> 1. Device shutdown via the UI > > > > This should be fine, we will flush to disk before actually powering down. > > > >> 2. User pulls the battery. > >> 3. Hardware-shutdown via long-hold of the power button. > >> 4. Device runs out of power. > > > > These three cases may fail to flush the data to disk, and if so when we > restart the transaction will be rolled back. > > > >> For 3: long-power-button-hold it seems like > >> depending on how extensively things are wedged, we could notice at say 6 > >> seconds that we're headed for a shutdown and try to trigger an fsync and > >> put a stop to new transactions. > > > > That sounds reasonable, assuming we get that notification at the gecko > layer? I am not sure what kind of info we get when long-presses happen. > > I would think that when long-press happens, the CPU simply receives a > reset signal. So it's equivalent to pulling the battery and putting it > back. > > But maybe the OS is sent a signal a few seconds prior to that which > would encourage it to flush. I'm not sure. > > >> For 4: low-power, ideally there's just > >> a point that the device decides it's not safe to operate and shuts > >> itself down, and that's slightly before it would result in IndexedDB > >> badness. > > > > I don't know, but if it goes through normal shutdown then we will be > fine. > > I'm pretty sure this results in the OS getting shut down cleanly, and > so will flush any data it still holds. I.e. the data should be safe > given my answer at the top. > > >> My main question is what is a realistic risk model for power loss/crash > >> and are there mitigations we can put in place to reduce the risk to > >> users? > >> ... > >> The issue there is how long the IndexedDB window of vulnerability is. > > > > Flushing happens automatically after the database is idle (i.e. no > active transactions) for 2 seconds at present. If the database never goes > idle for that long then we continue to journal until the WAL size exceeds > 20MB on desktop or 10MB on mobile. > > But prior to that flushing the data has been write()ten, right? So the > OS will take care of flushing it eventually as long as it's shut down > cleanly. > > / Jonas > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: CSS Scroll Snapping on Desktop
Please unsubscribe me On Wed, Apr 1, 2015 at 7:22 PM Eric Shepherd (Sheppy) wrote: > FWIW documenting and providing examples for this is a candidate for a > Q2 deliverable for the MDN content team. I do not make promises yet, > however. ;) > > On Mon, Mar 30, 2015 at 9:37 PM, Tantek Çelik > wrote: > > From the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1138658 > > > > This will be on by default in 39 right? > > > > Do we have any nice example pages to show it off? > > > > Being able to use CSS Snap Points has also come up in recent > > #indiewebcamp discussions, so FWIW, there are also independent web > > developers who are ready and eager to implement this on their own > > websites as well, in case you're looking for examples for your hacks > > blog post. > > > > Thanks, > > > > Tantek > > > > On Mon, Mar 16, 2015 at 3:34 PM, Robert O'Callahan > wrote: > >> On Tue, Mar 17, 2015 at 11:07 AM, Ehsan Akhgari < > ehsan.akhg...@gmail.com> > >> wrote: > >> > >>> Is this feature worth having a hacks blog post about? (hint: I think > so!) > >> > >> > >> Yes! > >> > >> 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 > > > > -- > > Eric Shepherd > Senior Technical Writer > Mozilla > Blog: http://www.bitstampede.com/ > Twitter: http://twitter.com/sheppy > ___ > 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: PSA: nsMemory::Alloc, nsMemory::Free, nsMemory::Realloc are no more (Was: PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more)
Please unsubscribe me On Wed, Apr 1, 2015 at 7:32 PM Mike Hommey wrote: > And now, nsMemory::Alloc, nsMemory::Free and nsMemory::Realloc are gone > as well. > > Mike > > On Tue, Mar 31, 2015 at 02:59:20PM +0900, Mike Hommey wrote: > > Hi, > > > > In the next few weeks, there is going to be a reduction in the number of > > our memory allocator wrappers/functions, for essentially the following > > reasons: > > - we have too many of them, > > - developers rarely know which one to use, which results in: > > - developers often make mistakes[1] > > > > This started today with the landing of bug 1138293, which effectively > > removed moz_malloc, moz_realloc, moz_calloc and moz_free. > > > > They were replaced, respectively, with malloc, realloc, calloc and free, > > because that works™. > > > > If you have pending patches that use moz_malloc, moz_realloc, > > moz_calloc, moz_free, you can just remove the moz_ prefix. > > > > The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist, > > and memory allocated with them can be freed with free. > > > > With that being said, please refrain from using any of the functions > > mentioned above. Please prefer the C++y new and delete. new is > > infallible by default (equivalent to moz_xmalloc). If you need an > > equivalent to moz_malloc, use fallible new instead: > > > > new (fallible) Foo() > > > > Please note that this shouldn't make uplifting harder. Platform patches > > using malloc/free/new/delete should apply and work just fine on beta, > > aurora and esr (with a few exceptions ; if you uplift something from > > mfbt/mozglue that uses the memory allocator, please check with me). > > > > Cheers, > > > > Mike > > > > > > 1. if you look for it, you'll find cases of one family used for > >allocation and another for deallocation, for possibly close to all > >combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc, > >new). > > ___ > > 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 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
You've now sent 3 "please unsubscribe me" posts -- I don't think those have any effect, aside from spamming everyone else on the list. If you want to unsubscribe, you can do so via this link (which is included at the bottom of every email you receive from this list): https://lists.mozilla.org/listinfo/dev-platform Unsubscription instructions are available at the bottom of that page. ~Daniel On 04/01/2015 06:39 PM, Alex Webster wrote: > Please unsubscribe me > On Wed, Apr 1, 2015 at 9:26 PM Jonas Sicking wrote: > >> On Thu, Apr 2, 2015 at 3:00 AM, ben turner (bent) >> wrote: >>> On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com >> wrote: - Crash-wise, are we talking about only the parent process crashing, or are we talking about the child process crashing too? >>> >>> I was talking just about the parent process. If the child process >> crashes then whether or not the transaction is durable depends on whether >> or not the parent received the commit message and processed it (otherwise >> we automatically abort any outstanding transactions). That behavior is >> unchanged. >> >> That doesn't sound entirely right. >> >> As soon as the child process received the last "success" event for a >> given request in a transaction, and we've sent the "go ahead and >> commit" message to the parent, then I would expect that it's ok for >> the child to crash at any point. This might match what you are saying. >> >> However the more important question that I believe Andrew is asking, >> is if we receive a "commit" event, what can then crash without there >> being a dataloss. My understanding is that at that point both the >> child and the parent can crash. As long as the kernel doesn't panic, >> or the battery runs out or is removed, the data will be written. >> >> I.e. once the "commit" event fires, the data has been transferred to >> the OS, and as long as the OS shuts down cleanly, or has time to >> flush, the data will be safe. >> 1. Device shutdown via the UI >>> >>> This should be fine, we will flush to disk before actually powering down. >>> 2. User pulls the battery. 3. Hardware-shutdown via long-hold of the power button. 4. Device runs out of power. >>> >>> These three cases may fail to flush the data to disk, and if so when we >> restart the transaction will be rolled back. >>> For 3: long-power-button-hold it seems like depending on how extensively things are wedged, we could notice at say 6 seconds that we're headed for a shutdown and try to trigger an fsync and put a stop to new transactions. >>> >>> That sounds reasonable, assuming we get that notification at the gecko >> layer? I am not sure what kind of info we get when long-presses happen. >> >> I would think that when long-press happens, the CPU simply receives a >> reset signal. So it's equivalent to pulling the battery and putting it >> back. >> >> But maybe the OS is sent a signal a few seconds prior to that which >> would encourage it to flush. I'm not sure. >> For 4: low-power, ideally there's just a point that the device decides it's not safe to operate and shuts itself down, and that's slightly before it would result in IndexedDB badness. >>> >>> I don't know, but if it goes through normal shutdown then we will be >> fine. >> >> I'm pretty sure this results in the OS getting shut down cleanly, and >> so will flush any data it still holds. I.e. the data should be safe >> given my answer at the top. >> My main question is what is a realistic risk model for power loss/crash and are there mitigations we can put in place to reduce the risk to users? ... The issue there is how long the IndexedDB window of vulnerability is. >>> >>> Flushing happens automatically after the database is idle (i.e. no >> active transactions) for 2 seconds at present. If the database never goes >> idle for that long then we continue to journal until the WAL size exceeds >> 20MB on desktop or 10MB on mobile. >> >> But prior to that flushing the data has been write()ten, right? So the >> OS will take care of flushing it eventually as long as it's shut down >> cleanly. >> >> / Jonas >> ___ >> 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 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Asynchronous Plugin Initialization is enabled by default on Aurora 39
Asynchronous initialization of NPAPI plugins is enabled by default on desktop Aurora 39. It is controlled by the dom.ipc.plugins.asyncInit pref. Since this feature is not yet 100% e10s compatible, the Aurora channel is the first time that the feature is seeing widespread deployment. Because of this, there has already been some fallout that I am fixing in bug 1149358. If there are any other lingering issues, they are probably going to be observed during plugin instantiation. If you notice anything and need to file a bug, please cc me and file it blocking bug 1116806 (alias asyncplugininit). Aaron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
