This is a good idea.
On 08/04/15 21:30, Botond Ballo wrote:
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.
Have we considered issuing a warnin
On Wed, Apr 8, 2015 at 2:30 PM, Botond Ballo wrote:
> Have we considered issuing a warning saying that after upgrading the
> profile, it will not be compatible with older versions?
I would really like to have something like this. WebIDE makes use of
IndexedDB today, and it seems to trigger uncatc
> 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.
Have we considered issuing a warning saying that after upgrading the
profile, it will not be
On Saturday, April 4, 2015 at 9:02:32 AM UTC-7, Jonas Sicking wrote:
> > "crash" in that sentence means "kernel panic" not "Gecko crash", right?
>
> That's correct as far as I understand it. Ben should confirm.
Yep, should have said "system crash" or "OS crash" there.
-bent
_
On Sat, Apr 4, 2015 at 3:15 PM, Gian-Carlo Pascutto wrote:
> On 4/04/2015 12:22, Jonas Sicking wrote:
>
>> I tried to explain this, but I don't think it was particularly clear.
>>
>> Once the "complete" event has fired, the data has been completely
>> transferred to the OS. At that point, any geck
On 4/04/2015 12:22, Jonas Sicking wrote:
> I tried to explain this, but I don't think it was particularly clear.
>
> Once the "complete" event has fired, the data has been completely
> transferred to the OS. At that point, any gecko process crashing or
> getting killed will not be a problem.
The
On Fri, Apr 3, 2015 at 11:47 PM, Gian-Carlo Pascutto wrote:
>
>> 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".
>
> Do our internal APIs offer this?
>
> Android can kill Firefox at any time
> 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".
Do our internal APIs offer this?
Android can kill Firefox at any time it requires more memory. It seems
prudent to at least commit when we'r
On Thursday, April 2, 2015 at 5:01:12 PM UTC-7, Jonas Sicking wrote:
> We don't fire the "commit" event until after we've told SQLite to
> commit and it's come back to tell us that the commit was successful,
> do we?
You mean the "complete" event, but yes, that's correct.
-bent
__
On Thu, Apr 2, 2015 at 9:19 PM, ben turner (bent)
wrote:
> On Wednesday, April 1, 2015 at 6:26:04 PM UTC-7, Jonas Sicking wrote:
>> This might match what you are saying.
>
> Yep!
>
>> My understanding is that at that point both the
>> child and the parent can crash.
>
> Well, it's not enough to ju
On Wednesday, April 1, 2015 at 6:26:04 PM UTC-7, Jonas Sicking wrote:
> This might match what you are saying.
Yep!
> My understanding is that at that point both the
> child and the parent can crash.
Well, it's not enough to just receive the commit message from the child. We
then have to actuall
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/l
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
> >>
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 p
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
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.mozil
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 t
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 m
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/mozil
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 tr
20 matches
Mail list logo
