On Thursday, November 2, 2017 at 1:08:21 AM UTC+1, Kris Maglione wrote:
> On Thu, Nov 02, 2017 at 01:06:09AM +0100, Jörg Knobloch wrote:
> > On 02/11/2017 00:41, Nicholas Nethercote wrote:
> >
> > 1) Remove the defaults/preferences directory support for extensions. This
> > is a feature that was
Looping in mkaply explicitly, if that has impact on organizational
deployments.
Axel
Am 02.11.17 um 00:41 schrieb Nicholas Nethercote:
Greetings,
In https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 I am planning to
remove a couple of things relating to preferences.
1) Remove the defaults
[ See formatted version here:
https://wiki.mozilla.org/SecurityEngineering/Newsletter ]
= Firefox Security Team Newsletter Q3 17 =
Firefox Quantum is almost here, and contains several important security
improvements. Improved sandboxing, web platform hardening, crypto performance
improvements
For anyone who clicked the link and was confused, NOW the wiki has the
latest newsletter. Apologies for that.
https://wiki.mozilla.org/SecurityEngineering/Newsletter
On Thu, Nov 2, 2017 at 9:26 PM, wrote:
> [ See formatted version here: https://wiki.mozilla.org/
> SecurityEngineering/Newsletter
When I first read this, I thought you meant the defaults/preferences
directory in Firefox.
Considering this only worked for true legacy extensions (not bootstrapped
extensions), this shouldn't be a problem for enterprise.
We double check to sure that no system add-ons need this.
Mike
On Wed, No
[Note: I'm a tab-hoarder - but that doesn't really cause this problem]
tl;dr: we should look at something (roughly) like the existing "page is
making your browser slow" dialog for website leaks.
Over the last several months (and maybe the last year), I've noticed an
increasing problem in website
Hi,
In bug 1374247, I intend to remove the XBL compatibility hack introduced
in bug 653881 [1] for which elements may be "transparent"
in selector-matching.
That means that a selector like .foo > .bar, would match a tree like:
The motivation is the following: This was no
Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
Team last week, *October 23 - October* *27* (week 43).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.o
about:performance can provide the tab/pid mapping, with some performance
indexes.
This might help solve your issue listed in the side note.
Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
On Thu, Nov 2, 2017 at 3:34 PM, Randell Jesup wrote:
> [Note: I'm a tab-hoarder - but that doesn't really ca
>about:performance can provide the tab/pid mapping, with some performance
>indexes.
>This might help solve your issue listed in the side note.
mconley told me in IRC that today's nightly has brought back the PID in
the tooltip (in Nightly only); it was accidentally removed.
about:performance can
This has been an issue forever, and there aren't really good tools on any
browser, as far as
I know, for web devs to debug their leaks.
Internally we do have useful data (CC and GC graphs and such), but would need
quite some ux skills to design some good
UI to deal with leaks. Also, the data to
What you're describing having seen is, I think, exactly what I've been
trying to reproduce in a now-blocking-57 bug (1398652).
By your description, the only thing that makes sense to me -- to account
for unknown/unknowable changes on the site -- is to track potential runaway
growth of the content
The W3C defined a generic sensor API for browsers which also allows to support
sensors like the Magnetometer. The spec can be found here:
https://www.w3.org/TR/generic-sensor/
Does Mozilla intend to support that API for Firefox? Is it maybe even already
under development?
note: Chrome 63 does
On 11/2/17 12:54 PM, hoehn6...@gmail.com wrote:
The W3C defined a generic sensor API for browsers which also allows to support
sensors like the Magnetometer. The spec can be found here:
https://www.w3.org/TR/generic-sensor/
This isn't a spec, nor did the W3C "define" it. This is a working dr
On 11/2/17 12:54 PM, hoehn6...@gmail.com wrote:
note: Chrome 63 does support it in it early version already
I should note that this is slightly misleading. According to
https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/blink-dev/2zPZt3watBk/M4qcI8wlBwAJ
>Many of the pages causing these leaks are major sites, like nytimes.com,
>washington post, cnn, arstechnica, Atlantic, New Yorker, etc.
...
>Perhaps we can also push to limit memory use (CPU use??) in embedded
>ads/restricted-iframes/etc, so sites can stop ads from destroying the
>website performa
Related: I've been thinking for a long time that we need better tools
for tracking what sites/usage patterns are responsible for the time we
spend in CC (and possibly GC, but I think that tends to be less of a
problem).
I've noticed, in particular, that having multiple Amazon tabs open, and
k
On Thu, Nov 02, 2017 at 05:37:30PM +0200, smaug wrote:
This has been an issue forever, and there aren't really good tools on any
browser, as far as
I know, for web devs to debug their leaks.
Internally we do have useful data (CC and GC graphs and such), but would need
quite some ux skills to de
On 11/02/2017 10:01 PM, Kris Maglione wrote:
On Thu, Nov 02, 2017 at 05:37:30PM +0200, smaug wrote:
This has been an issue forever, and there aren't really good tools on any
browser, as far as
I know, for web devs to debug their leaks.
Internally we do have useful data (CC and GC graphs and suc
>On Thu, Nov 02, 2017 at 05:37:30PM +0200, smaug wrote:
>>This has been an issue forever, and there aren't really good tools on any
>>browser, as far as
>>I know, for web devs to debug their leaks.
>>Internally we do have useful data (CC and GC graphs and such), but would need
>>quite some ux ski
On 11/02/2017 09:58 PM, Kris Maglione wrote:
Related: I've been thinking for a long time that we need better tools for
tracking what sites/usage patterns are responsible for the time we spend in
CC (and possibly GC, but I think that tends to be less of a problem).
I've noticed, in particular, t
Now that I'm writing a Web app for real, I realize just how easy it is to
accidentally leak :-(.
It would be useful, or at least cool, to be able to show users and
developers a graph of memory usage over time, one line per tab. You could
limit this to just show the top N memory-hungry tabs.
A UI
We have https://bugzilla.mozilla.org/show_bug.cgi?id=1243091 on file for
automatic leak detection in the DevTools' memory panel.
I'd have liked to try implementing
http://www.cs.utexas.edu/ftp/techreports/tr06-07.pdf because it can see
through frameworks/libraries (or claims to in a convincing way
For rr I have an i7 desktop with a base clock of 4.0 Ghz, and for
building I use icecc to distribute the load (or rather I will be again
when bug 1412240[0] is closed). The i9 series has lower base clocks
(2.8 Ghz, and 2.6Ghz for the top SKUs)[1], but high boost clocks of 4.2
Ghz. If I were t
On Thu, Nov 2, 2017 at 3:43 PM, Nico Grunbaum wrote:
> For rr I have an i7 desktop with a base clock of 4.0 Ghz, and for building
> I use icecc to distribute the load (or rather I will be again when bug
> 1412240[0] is closed). The i9 series has lower base clocks (2.8 Ghz, and
> 2.6Ghz for the t
25 matches
Mail list logo
