On 02.08.2013 03:35, Gavin Sharp wrote:
The experiment you're referring to was Adblock running in Firefox with
remote tabs enabled, I think. I'm not up to date with how that
experiment was progressing, but I think there are some fundamental
differences between that scenario and the background
On 02/08/2013 03:50, Nicholas Nethercote wrote:
On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp ga...@gavinsharp.com wrote:
Do you have specific issues you're worried about, or are you just speaking
about issues in general?
This AdBlock issue worries me specifically. And the fact that there's
We are working on ways to make add-ons like adblock work with e10s on
desktop without major changes to the add-on. That mechanism might work
for the thumbnail case. Gavin can reach out to trev and discuss whether
this is something we should try to make work. I do agree this isn't
super high
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey m...@glandium.org wrote:
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
Debian doesn't keep Iceweasel up to date in oldstable anyway.
Actually, I'm providing backports for oldstable. 24 is as far as I'm
ready to go to support
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote:
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey m...@glandium.org wrote:
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
Debian doesn't keep Iceweasel up to date in oldstable anyway.
Actually, I'm providing
On 02/08/2013 16:57, t...@adblockplus.org wrote:
The code in question was explicitly running in Firefox Mobile only.
It used messageManager.loadFrameScript() API to inject code into the
content process of new tabs - I doubt that it will work the same
here, Adblock Plus would probably need to
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey m...@glandium.org wrote:
Upgrading minimum compiler requirements doesn't imply backporting those
requirements to Aurora where ESR24 is right now. Are you opposed to
updating our minimum supported gcc to 4.7 on trunk when Firefox OS is
ready
to
On Fri, Aug 2, 2013 at 1:36 AM, Joshua Cranmer pidgeo...@gmail.comwrote:
On 8/1/2013 5:46 PM, Brian Smith wrote:
FWIW, I talked about this issue with a group of ~10 Mozillians here in
Berlin and all of them (AFAICT) were in favor of requiring that the latest
versions of GCC be used, or
It's certainly worrying given the number of security- and privacy-related
addons people rely on working. Seeing ads in thumbnails is relatively harmless
(if disconcerting), but if someone is relying on an addon for important
security or privacy reasons, and we auto-updated them and bypassed
(Cross posting. Please reply to dev.builds.)
I've noticed an increase in the number of complaints about the build
system recently. I'm not surprised. Building mozilla-central has gotten
noticeably slower. More on that below. But first, a request.
Many of the complaints I've heard have been
On Wed, Jul 31, 2013 at 7:41 PM, Joshua Cranmer pidgeo...@gmail.comwrote:
implementation, libc++, libstdc++, and stlport. Since most nice charts of
C++11 compatibility focus on what the compiler needs to do, I've put
together a high-level overview of the major additions to the standard
It is very useful for building a logging interface that is safer and more
convenient than NSPR's printf-style logging. Note that, again, Eric
Rescorla already built an (partial) iostream-based wrapper around NSPR for
WebRTC. I would say that, if there is no additional overhead, then we
should
I agree that iostream-based logging would be safer. If we had it I
wouldn't have had to work on this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=855335
I can't access that bug, but maybe you mean
https://bugzilla.mozilla.org/show_bug.cgi?id=onelogger ?
I feel like the goals there are
Sorry I should've noticed that 855335 is a sec-bug. It's title is Audit
SIPCC printf-style format strings which means we went through every
logging call and repaired a few which had incorrect printf-style args.
-EH
On Fri, Aug 2, 2013 at 2:44 PM, Justin Lebar justin.le...@gmail.com wrote:
On 8/2/2013 1:52 PM, Jeff Gilbert wrote:
It's certainly worrying given the number of security- and privacy-related
addons people rely on working. Seeing ads in thumbnails is relatively harmless
(if disconcerting), but if someone is relying on an addon for important
security or privacy
First of all, I'd like to thank you and the rest of the build peers for
your tireless efforts!
On 2013-08-02 5:13 PM, Gregory Szorc wrote:
(Cross posting. Please reply to dev.builds.)
Sorry, but cross-posting to both lists. I don't think most of the
people interested in this conversation
On 2013-08-02 5:21 PM, Brian Smith wrote:
3. How should we handle bridge support for standardized features not yet
universally-implemented?
Generally, I would much rather we implement std::whatever ourselves than
implement mozilla::Whatever, all other things being equal.
Yes, but it's still
On 2013-08-02 4:49 PM, Brian Smith wrote:
That sounds reasonable to me. So, based on that then, let's get back to my
original question that motivated the discussion of the policy: If we add
std::move, std::forward, and std::unique_ptr to STLPort for Android and
B2G, can we start using std::move,
On 2013-08-02 4:39 PM, Brian Smith wrote:
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey m...@glandium.org
mailto:m...@glandium.org wrote:
Upgrading minimum compiler requirements doesn't imply backporting
those
requirements to Aurora where ESR24 is right now. Are you opposed to
On Fri, Aug 2, 2013 at 3:38 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
# Building faster
One of our Q3 goals is to replace the export tier with something more
efficient. More on tiers at [1]. This should make builds faster,
especially on pymake. Just earlier this week we made WebIDL and
Brian Smith wrote:
We have mozilla-build for Windows. From what you say, it sounds like we should
have mozilla-build for Linux too that would include a pre-built GCC or Clang or
whatever we choose as *the* toolchain for desktop Linux.
mozilla-build doesn't include a compiler or SDK. At one
It was brought to my attention that it's unclear what I'm looking for in
this conversation, so let me try to summarize. I am not convinced that
there is something wrong with the way that things currently work (polyfill
where the feature is not available everywhere, else use it if
appropriate).
On Sat, Aug 3, 2013 at 9:13 AM, Gregory Szorc g...@mozilla.com wrote:
Many of the complaints I've heard have been from overhearing hallway
conversations, noticing non-directed complaints on IRC, having 3rd parties
report anecdotes, etc. *Please, please, please voice your complaints
directly
On 8/2/13 3:38 PM, Ehsan Akhgari wrote:
Hmm. I'm not sure if the number of source files is directly correlated
to build times, but yeah there's clearly a trend here!
I concede a lines of code count would be a better indicator. I'm lazy.
# Header dependency hell
I have been playing with an
On 8/2/13 4:43 PM, Robert O'Callahan wrote:
Nathan has just made an excellent post on this topic:
https://blog.mozilla.org/nfroyd/2013/08/02/i-got-99-problems-and-compilation-time-is-one-of-them/
It would be interesting to measure the number of non-blank precompiled
lines in each build, over
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
This adds too much risk of security patches failing to backport from
mozilla-central to ESR 24. Remember that one of the design goals of ESR
is to minimize the amount of effort we put into it so that ESR doesn't
On 8/2/13 8:14 PM, Brian Smith wrote:
The risk that any developer would need to
waste time on ESR just to support a product that isn't even Firefox on a
platform that virtually nobody uses, and the risk that comes with making
any changes to the security fix that you are trying to backport.
I
On Sat, Aug 3, 2013 at 1:32 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 3, 2013 at 9:13 AM, Gregory Szorc g...@mozilla.com wrote:
Many of the complaints I've heard have been from overhearing hallway
conversations, noticing non-directed complaints on IRC, having 3rd
parties
On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-08-02 4:49 PM, Brian Smith wrote:
That sounds reasonable to me. So, based on that then, let's get back to my
original question that motivated the discussion of the policy: If we add
std::move, std::forward,
On Fri, Aug 02, 2013 at 06:47:08PM -0400, Ehsan Akhgari wrote:
On 2013-08-02 5:21 PM, Brian Smith wrote:
3. How should we handle bridge support for standardized features not yet
universally-implemented?
Generally, I would much rather we implement std::whatever ourselves than
implement
On Fri, Aug 02, 2013 at 02:44:57PM -0700, Justin Lebar wrote:
I agree that iostream-based logging would be safer. If we had it I
wouldn't have had to work on this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=855335
I can't access that bug, but maybe you mean
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote:
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
This adds too much risk of security patches failing to backport from
mozilla-central to ESR 24. Remember that one of the design goals of ESR
is to
On Sat, Aug 3, 2013 at 12:47 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-08-02 5:21 PM, Brian Smith wrote:
3. How should we handle bridge support for standardized features not yet
universally-implemented?
Generally, I would much rather we implement std::whatever ourselves than
On 8/2/2013 10:09 PM, Brian Smith wrote:
2. It is reasonable to expect that std::whatever works as the C++
standard says it should. It isn't reasonable to expect
mozilla::Whatever to work exactly like std::whatever. And, often,
mozilla::Whatever isn't actually the same as std::whatever
Building mozilla-central has gotten noticeably slower.
Yep. A bit over two years ago I started doing frequent browser builds
for the first time; previously I'd mostly just worked with the JS
shell. I was horrified by the ~25 minutes it took for a clobber
build. I got a new Linux64 box and
On Saturday 2013-08-03 13:36 +1000, Nicholas Nethercote wrote:
# Header dependency hell
I've recently done a bunch of work on improving the header situation
in SpiderMonkey. I can break it down to two main areas.
== MINIMIZING #include STATEMENTS ==
There's a clang tool called
On Fri, Aug 2, 2013 at 8:59 PM, L. David Baron dba...@dbaron.org wrote:
khuey was also recently working on something to reduce some pretty
bad #include fanout related to the new DOM bindings generation.
(I'm not sure if it's landed.)
That was bug 887553. I'll land it on Monday.
- Kyle
On Fri, Aug 2, 2013 at 9:12 PM, Kyle Huey m...@kylehuey.com wrote:
On Fri, Aug 2, 2013 at 8:59 PM, L. David Baron dba...@dbaron.org wrote:
khuey was also recently working on something to reduce some pretty
bad #include fanout related to the new DOM bindings generation.
(I'm not sure if it's
The weekly Engineering meeting will be broadcast on Air Mozilla starting this
coming week (Aug 6, 2013). The reasons for broadcasting this meeting on Air
Mozilla are to:
1. provide a recording of the meeting for those who unable to attend at the
scheduled time
2. make it easier for people to
39 matches
Mail list logo
