On Wednesday, July 11, 2018 at 3:01:04 PM UTC-7, Mike Hommey wrote:
> On Wed, Jul 11, 2018 at 09:48:23AM -0700, Thomas Daede wrote:
> > On 07/10/2018 01:29 PM, David Major wrote:
> > > Bug 1443590 is switching our official Windows builds to use clang-cl
> > > as the compiler.
> >
> > Another
On Thu, Jul 12, 2018 at 11:25 AM, Karl Tomlinson wrote:
> Would it be easier to answer the opposite question? What should
> not run in a shared process? JS is a given. Others?
>
Currently when an exploitable bug is found in content process code,
attackers use JS to weaponize it with an
Is there a guideline that should be used to evaluate what can
acceptably run in the same process for different sites?
I assume the primary goal is to prevent one site from reading
information that should only be available to another site?
There would also be defense-in-depth value from having
This was added in bug 1255843 [1]. I don't feel to strongly about keeping
it around, I believe mconley and mrbkap came up with the idea of adding it.
It's *much* more lightweight than about:memory and provides automatic
updates which is nice for monitoring without external tools.
What performance
On Wed, Jul 11, 2018 at 09:48:23AM -0700, Thomas Daede wrote:
> On 07/10/2018 01:29 PM, David Major wrote:
> > Bug 1443590 is switching our official Windows builds to use clang-cl
> > as the compiler.
>
> Another great effect of this change is that it finally fixes the issue
> of constantly
On Wed, Jul 11, 2018 at 11:42:01PM +0200, Jean-Yves Avenard wrote:
On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote:
It looks like it will be helpful, but unfortunately won't give us the 2MB
simple arithmetic would suggest. On Windows, at least, (and probably
elsewhere, but need to confirm)
On Wed, Jul 11, 2018 at 11:42:01PM +0200, Jean-Yves Avenard wrote:
> Hi
>
> > On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote:
> > Thanks. Boris added this as a blocker.
> >
> > It looks like it will be helpful, but unfortunately won't give us the 2MB
> > simple arithmetic would suggest. On
Hi
> On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote:
> Thanks. Boris added this as a blocker.
>
> It looks like it will be helpful, but unfortunately won't give us the 2MB
> simple arithmetic would suggest. On Windows, at least, (and probably
> elsewhere, but need to confirm) thread stacks
>Adding to what Tom said...
>
>1. "Web developers want the ability to observe the performance
>characteristics of their applications" - they want to do so, but
>*should* they be allowed to do so? The API would give access to deep
>performance data that could be used for all sorts of nefarious
On Wed, Jul 11, 2018 at 01:49:04PM +0200, Jean-Yves Avenard wrote:
There’s one place where we could gain heaps is in the media stack.
Currently, each content process allocate a thread-pool with at least 8
threads for use with the media decoders, each threads a default stack size of
256kB.
>On 7/11/18 5:42 AM, David Bruant wrote:
>> I've seen this information of 100 content processes in a couple places but
>> i haven't been able to find the rationale for it. How was the 100 number
>> picked?
>
>I believe this is based on telemetry for number of distinct sites involved
>in browsing
On Wed, Jul 11, 2018 at 02:42:11PM +0200, David Bruant wrote:
2018-07-10 20:19 GMT+02:00 Kris Maglione :
The problem is thus: In order for site isolation to work, we need to be
able to run *at least* 100 content processes in an average Firefox session
I've seen this information of 100
On Wed, Jul 11, 2018 at 5:42 AM, David Bruant wrote:
>
>
> * Andrew McCreight created a tool for tracking JS memory usage, and
>> figuring
>> out which scripts and objects are responsible for how much of it
>> (https://bugzil.la/1463569).
>>
> How often is this code run? Is there a place to
Context: we are currently redesigning about:performance to make it
more useful for users.
This section of the current about:performance page provides
information that isn't actionable for users, and collecting this
information causes performance issues, so I think it's time to remove
it.
I filed
On 7/11/18 5:42 AM, David Bruant wrote:
I've seen this information of 100 content processes in a couple places but
i haven't been able to find the rationale for it. How was the 100 number
picked?
I believe this is based on telemetry for number of distinct sites
involved in browsing sessions.
On 7/10/18 10:59 PM, L. David Baron wrote:
The changes relative to the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F07%2Fwebperf=https%3A%2F%2Fwww.w3.org%2F2018%2F07%2Fwebperf-charter
It looks like the new charter proposes to merge navigation
On 07/10/2018 01:29 PM, David Major wrote:
> Bug 1443590 is switching our official Windows builds to use clang-cl
> as the compiler.
Another great effect of this change is that it finally fixes the issue
of constantly running out of virtual address space when linking Win32
builds:
Adding to what Tom said...
1. "Web developers want the ability to observe the performance
characteristics of their applications" - they want to do so, but
*should* they be allowed to do so? The API would give access to deep
performance data that could be used for all sorts of nefarious purposes
I have a few concerns.
The Long Task Specification is essentially a way for a website to know if
you have other tabs open and if they are CPU intensive tasks. That seems in
pretty fundamental opposition to the Same Origin Policy.
Device Memory clearly has made an effort to make it 'less
Thanks Kris for all this information and the beginning of the first issue
of this newsletter!
2018-07-10 20:19 GMT+02:00 Kris Maglione :
> The problem is thus: In order for site isolation to work, we need to be
> able to run *at least* 100 content processes in an average Firefox session
I've
Le 11/07/2018 à 14:01, pedro.lar...@gmail.com a écrit :
> Is there a link to the required changes? I'm curious.
One of the meta bug is:
https://bugzilla.mozilla.org/show_bug.cgi?id=752004
Look at the list of "Depends on" to see what have been required!
(not mentioning other related work like
Is there a link to the required changes? I'm curious.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hi
That’s great info, thank you.
There’s one place where we could gain heaps is in the media stack.
Currently, each content process allocate a thread-pool with at least 8 threads
for use with the media decoders, each threads a default stack size of 256kB.
The W3C is proposing a revised charter for:
Web Performance Working Group
https://www.w3.org/2018/07/webperf-charter
https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0002.html
Mozilla has the opportunity to send comments or objections through
Friday, August 3.
The changes
24 matches
Mail list logo
