On Sat, 28 Jun 2014, Dale Harvey wrote:
>
> Application developers have the ability to specify additional menuitems for
> contextmenus via
> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
> however they are currently shown in addition to the defa
Application developers have the ability to specify additional menuitems for
contextmenus via
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
however they are currently shown in addition to the default items, we are
looking to implement an optional
On 25/06/2014 08:15, Jason Orendorff wrote:
> We're considering building a JavaScript API for dynamic analysis of JS
> code.
> Here's the sort of thing you could do with it:
>
> - Gather code coverage information (useful for testing/release mgmt?)
Yes, I confirm that we would be happy to get a cl
I don't follow what you have in mind. Assuming that you suggest we move
to sqlite, you seem to be suggesting that we should considerably
increase the amount of I/O. Or do I misunderstand what you say?
Also, readability of sqlite being better than that of json is quite
debatable.
Best regards,
Da
Am Samstag, 28. Juni 2014 16:45:39 UTC+2 schrieb Tobias Besemer:
> Am Samstag, 28. Juni 2014 14:42:40 UTC+2 schrieb David Rajchenbach-Teller:
>
> > See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
>
> > on the proposed Journaled Storage mechanism. This should bring down the
Am Samstag, 28. Juni 2014 14:42:40 UTC+2 schrieb David Rajchenbach-Teller:
> See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
> on the proposed Journaled Storage mechanism. This should bring down the
> number of writes by an order of magnitude.
I had a look at this bug ... i
Am Samstag, 28. Juni 2014 14:45:38 UTC+2 schrieb David Rajchenbach-Teller:
> Tobas, if you have an opportunity to perform a comparison, this would be
> an interesting piece of data.
Sorry, not yet ... :-/
___
dev-platform mailing list
dev-platform@lists.
Am Samstag, 28. Juni 2014 14:44:53 UTC+2 schrieb Tim Taubert:
> Tobias Besemer wrote:
> > It is not just a question of battery!
> > Too much writing accesses also harms the life-time of HDs or SSDs!
> Yup, that's why we're working on it. Clearing data on quit won't get us
> there as data accumulate
Am Samstag, 28. Juni 2014 14:45:38 UTC+2 schrieb David Rajchenbach-Teller:
> While we should and will reduce the total amount of I/O due to Session
> Restore, I must add that we have not attempted to compare it to the
> total amount of I/O due to cache access for instance. I would not be
> surprise
Am Samstag, 28. Juni 2014 14:42:40 UTC+2 schrieb David Rajchenbach-Teller:
> See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
> on the proposed Journaled Storage mechanism. This should bring down the
> number of writes by an order of magnitude.
Thx! I will try to study it ..
Tobias Besemer wrote:
> Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim Taubert:
>> Tobias Besemer wrote:
>>
>>> The amount of I/O is always a problem! E.g. for Notebooks in battery use.
>> Yes, of course. That is a known problem and we're working on it by
>> increasing the write interval when
While we should and will reduce the total amount of I/O due to Session
Restore, I must add that we have not attempted to compare it to the
total amount of I/O due to cache access for instance. I would not be
surprised if the cache caused several orders of magnitude more I/O than
Session Restore, in
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
on the proposed Journaled Storage mechanism. This should bring down the
number of writes by an order of magnitude.
Cheers,
David
On 28/06/14 14:32, Tobias Besemer wrote:
> Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim
Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim Taubert:
> Tobias Besemer wrote:
>
> > The amount of I/O is always a problem! E.g. for Notebooks in battery use.
> Yes, of course. That is a known problem and we're working on it by
> increasing the write interval when running on battery and wor
Am Samstag, 28. Juni 2014 14:23:32 UTC+2 schrieb Tim Taubert:
> Tobias Besemer wrote:
>
> > The ss is necessary, when e.g. a user editing a large text in a wiki,
> > haven't saved that text yet, and closes this page as a mistake. So he can
> > go back / undo close and still have his un-saved tex
Tobias Besemer wrote:
> The amount of I/O is always a problem! E.g. for Notebooks in battery use.
Yes, of course. That is a known problem and we're working on it by
increasing the write interval when running on battery and working
towards a journaled storage.
As I said before, cleaning sessionsto
Am Samstag, 28. Juni 2014 14:03:38 UTC+2 schrieb David Rajchenbach-Teller:
> I am currently running benchmarks to find the influence of each part of
> Session Restore data on startup duration.
Thank you!
> The work is ongoing, but for
> the moment, I can confirm that closed tabs and closed windo
Tobias Besemer wrote:
> The ss is necessary, when e.g. a user editing a large text in a wiki, haven't
> saved that text yet, and closes this page as a mistake. So he can go back /
> undo close and still have his un-saved text ...
Yes, this was the reason why sessionstore was introduced years ago
Am Samstag, 28. Juni 2014 14:00:12 UTC+2 schrieb Tim Taubert:
> Why is the amount of I/O a problem for you exactly?
The amount of I/O is always a problem! E.g. for Notebooks in battery use.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
htt
OK, maybe we should first talk about what the ss is for, what he should do,
when it is used & so ...
The ss is necessary, when e.g. a user editing a large text in a wiki, haven't
saved that text yet, and closes this page as a mistake. So he can go back /
undo close and still have his un-saved t
I am currently running benchmarks to find the influence of each part of
Session Restore data on startup duration. The work is ongoing, but for
the moment, I can confirm that closed tabs and closed windows have
strictly no measurable influence on startup duration. The ongoing work
towards differenti
Tobias Besemer wrote:
>> What problems are you currently hitting that you think will be fixed by
>> downsizing sessionstore.js?
> I have ~4-8 GB I/O because of ss on a 8h day. Please look at the bugs you
> have commented before.
I looked at those bugs and they don't have better problem descriptio
Am Samstag, 28. Juni 2014 08:04:43 UTC+2 schrieb Tim Taubert:
> To properly set the stage for this discussion, why exactly do you want
> this? Where do you see the problem with a "big" sessionstore.js file?
Bug 669034 - (sessionRestoreJank) [meta] Re-architect session restore to avoid
periodic fr
Am Samstag, 28. Juni 2014 07:28:22 UTC+2 schrieb Katelyn Gadd:
> If this behavior were changed I'd change it back locally with a pref
> or addon or something.
This should be the solution for those who want this behavior.
> There are lots of reasons to exit (powering off to install
> windows upda
> I often restart FF because of memory use bloat - a restart cleans up that
> memory use somewhat. When I do that I expect all my history for each tab to
> be retained, and to be able to undo closed tabs.
History would be retained, old form data would be cleared, closed tabs would be
forgotten
25 matches
Mail list logo
