Re: Standard C/C++ and Mozilla
Joshua Cranmer wrote:
On 7/31/2013 9:19 PM, Mike Hommey wrote:
Now think of all those NS_LITERAL_STRING() and other horrible
boilerplate we have.
... and my next target is s/PRUnichar/char16_t/, the last step of
which basically amounts to killing NS_LITERAL_STRING. :-)
Will that include this:
public:
templateint N
nsTSubstring_CharT(const char_type (str)[N])
: mData(str)
, mLength(N - 1)
, mFlags(F_TERMINATED) {}
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking separate Mercurial repositories
On 2013-07-31 8:57 PM, Mike Hommey wrote: Sadly, mercurial doesn't support having multiple working directories from a single clone, which would be useful to avoid wasting so much disk space on .hg. I'm 85% sure that Mercurial, on filesystems that support it, creates hardlinks instead of copies if you hg clone mozilla-central mozilla-central-2. joe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking separate Mercurial repositories
Sadly, mercurial doesn't support having multiple working directories from a single clone, which would be useful to avoid wasting so much disk space on .hg. I'm 85% sure that Mercurial, on filesystems that support it, creates hardlinks instead of copies if you hg clone mozilla-central mozilla-central-2. jlebar did a post on how to minimize wasted space in your Mercurial clones: http://www.jlebar.com/2011/5/20/Faster_and_smaller_clones_of_branches.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
talos mozharness status
Hi, * most of the ts test performance hit that we were expecting should have finished being reported * we had missed enabling talos mozharness for the PGO builders ** this means that the PGO branches will start reporting today and might take a day or two to clear up (like the other branches) * we want to enable it also for FF24 in preparation for ESR24 and not have to maintain two different code paths and kill one when ESR17 dies * there are some minor bugs that were discovered with major load which have been filed and we will tackle as soon as possible regards, Armen On 2013-07-30 10:17 AM, Armen Zambrano G. wrote: Talos mozharness is now live on all FF25 trees. Remember that we will see some ts regressions. More info in: http://armenzg.blogspot.ca/2013/07/enabling-talos-mozharness-for-ff25.html This will ride the trains. cheers, Jason Armen On 2013-07-29 1:04 PM, Armen Zambrano G. wrote: This will be going live tomorrow Tuesday 30th. On 2013-07-23 4:38 PM, Armen Zambrano G. wrote: I need these new changesets to spread across the FF25 trees before going ahead with this: https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4ab37e3f3e https://hg.mozilla.org/integration/mozilla-inbound/rev/496a7582cf9e I'm postponing this until Monday. Sorry for the noise. I want to make sure that it all goes as expected. cheers, Jason Armen On 2013-07-22 2:44 PM, Armen Zambrano G. wrote: Last week we enabled mozharness for talos on the try server and we have resolved all found issues since then. The issues were related to proper integration with tbpl and talos's try support. We will switch talos jobs to be driven by mozharness rather than through buildbot by Wednesday morning in the morning of EDT. I assume that changeset 3d1c2ca7efe8 is already on your local checkout after a week being in the tree but worth raising it up again. There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. regards, Jason Armen [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 On 2013-07-16 8:51 AM, Armen Zambrano G. wrote: Hi, We have recently been working hard to separate the buildbot logic that runs our talos jobs on tbpl to its own separate script (using mozharness). [1][2] This has the advantage of permitting anyone (specially the a-team) to adjust how our harnesses run talos inside of our infrastructure without having to set up buildbot (which is what currently runs our talos jobs). This also permits anyone to run the jobs locally in the same manner as Releng's infrastructure. This also allows for further development and flexibility on how we configure the jobs we run. Initially, we will enable it on the try server today to see production-like load. So far, it's been looking great on Cedar. [3] The only gotcha is that there will be a small performance hit for the ts tests that we are willing to take. [4] There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. Once we get a couple of days worth of load on the try server and see nothing new we will go ahead and enable it for every m-c based repository. If you have any questions/concerns please write a comment on bug 713055. Best regards, Jason Armen Release Engineering [1] https://bugzilla.mozilla.org/show_bug.cgi?id=713055 [2] https://developer.mozilla.org/en-US/docs/Mozharness_FAQ [3] https://tbpl.mozilla.org/?tree=Cedarjobname=talos [4] https://bugzilla.mozilla.org/show_bug.cgi?id=802801#c10 [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standard C/C++ and Mozilla
Neil wrote:
Joshua Cranmer wrote:
On 7/31/2013 9:19 PM, Mike Hommey wrote:
Now think of all those NS_LITERAL_STRING() and other horrible
boilerplate we have.
... and my next target is s/PRUnichar/char16_t/, the last step of
which basically amounts to killing NS_LITERAL_STRING. :-)
Will that include this:
public:
templateint N
nsTSubstring_CharT(const char_type (str)[N])
: mData(str)
, mLength(N - 1)
, mFlags(F_TERMINATED) {}
Actually it would be neat to have a second flag there F_LITERAL which
makes all assigments depend on the original string.
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On 07/31/2013 01:25 AM, Brian Smith wrote: Anyway, it would be easier to swallow the dependency on MFBT if it wasn't so large (over 100 files now), if it tried to be (just) a polyfill for missing standard library features, and if it could easily be used independently of the Gecko build system. But, none of those constraints is reasonable to place on MFBT, so that means MFBT isn't a good choice for most things that need to also be able to be built independently of Gecko. I disagree about independently-usable being an unreasonable constraint -- it seems totally reasonable for it to be a mini-embeddable thing, or something. But making it exactly that, without some of the hacks we have now for things like header-installation, etc., requires 1) time, 2) build-fu, and 3) understanding of the requirements of small little embeddable things, and I lack all these. On 07/31/2013 03:34 AM, Mike Hommey wrote: I am of the opinion that anything that is not a header file under MFBT should be moved into mozglue. The end result would be the same (MFBT is actually built into mozglue, except for js standalone builds, for which this would require some changes), but it would allow MFBT to just be used independently. Truly I don't care about the naming, but I've always envisioned mfbt as being headers and some compiled-into-objects files both, i.e. as the union of what you consider mfbt, and the compiled-in bits of it. Is there a good reason to have mozglue and what you consider mfbt to be two different things? Why not have both as a single thing, and make the whole thing more easily embeddable if necessary? Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mercurial extension to aid Gecko development
You can now file bugs against this extension at Other Applications :: mozext. I anticipate many awesome feature requests and embarrassing bugs. https://bugzilla.mozilla.org/enter_bug.cgi?product=Other%20Applicationscomponent=mozext On 7/26/13 11:07 AM, Gregory Szorc wrote: Since I announced this on Monday, I've implemented: * pushlog integration. Run |hg changesetpushes REV| to view when changesets landed on all the different trees. It even reports the version numbers of the beta and release versions when a changeset was first active. * Bug tracking. Run |hg buginfo BUG| to view information on changesets referencing bugs, including when those changesets landed on the different trees. You'll need to run |hg bugsync| first to populate the local database. * Automatic Python style checking. Run |hg critic| and get nagged about violations. You also get nagged automatically during qref and commit. * Pull from multiple repos with one command using aliases. e.g. |hg pull releases| pulls from esr, b2g, release, beta, aurora, and central. I concede the implementations of some things are rather half-baked at the moment. I'm mostly interested in experimenting to see if things are possible. If they are, I'll refine over time. Let me know if you run into any issues or have suggestions for improvements. Gregory On 7/22/13 11:03 AM, Gregory Szorc wrote: Do you use Mercurial to interact with mozilla-central and related repositories? I wrote an extension to make your life easier. * Easily manage unified Mercurial repositories (like the Git mirror) * hg tbpl (open TBPL for a changeset) * hg treestatus * hg pull fx-team * hg clone inbound * hg up elm/default * hg pushtree -r inbound/default central Source: https://hg.mozilla.org/users/gszorc_mozilla.com/hgext-gecko-dev/ clone and view the README for install instructions. More details: http://gregoryszorc.com/blog/2013/07/22/mercurial-extension-for-gecko-development/ Please let me know if you find any bugs or want to make enhancements. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Gavin Sharp schrieb: This has exposed some e10s crashes that previously weren't exposed on desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to track them - please hang any other such crashes off that bug. If you're working in a component that has e10s-related crashes, please fix them :) Note that all those crashes I have seen so far are actually crashes of the browser process, not just a content process, i.e. those crashes take down the whole browser! KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 2:19 PM, Mike Hommey m...@glandium.org wrote: On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote: On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote: I strongly oppose to any requirement that would make ESR+2 (ESR31) not build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not build on the old Debian stable (gcc 4.4). We're not going to change the requirements for the latter. And b2g still requires gcc 4.4 (with c++11) support anyways. Until they switch to the same toolchain as android, which is 4.7. Why are you so opposed? I feel like I can give a lot of good reasons why such constraints are a net loss for us, but I am not sure what is driving the imposition of such constraints on us. Because Mozilla is not the only entity that builds and distributes Gecko-derived products, including Firefox, and that we can't demand everyone to be using the latest shiny compiler. You are not answering the question. You are just making your assertion in a different way. First of all, when we created ESR, there was the understanding that ESR-related concerns would not hold back the mainline development. Any discussion about ESR in the context of what we use for *mozilla-central* is going against our original agreements for ESR. 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 even dropping GCC support completely in favor of clang, if it means that we can use more C++ language features and if it means we can avoid wasting time writing polyfills. Nobody saw installing a new version of GCC as part of the build environment as being a significant impediment. Everybody using Windows or Windows as their development environment has to download and install a multitude of programs and libraries in order to build Gecko. I've never heard of a justification for why Linux needs to be different. And, in fact, except for the compiler/linker/etc., Linux isn't different; that's why we have bootstrap.py that downloads and installs a bunch of stuff for Linux too. Why should only the compiler (including linker, etc.) only on Linux be treated specially? What justifies the reduced productivity that results from us wasting time writing unnecessary polyfills and/or writing worse code to avoid language features that aren't supported on some particular Linux distribution's version of GCC? How many developers working on Firefox are even using Debian as their development platform? What percentage of Firefox users are using Firefox on Debian? My position is that we should be doing everything we can to improve developer productivity, and that means using the best possible tools we have available to us. I have a hard time seeing how any Linux distributions' policies could possibly be more important than our productivity. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On Wed, Jul 31, 2013 at 8:09 PM, Joshua Cranmer pidgeo...@gmail.comwrote: More generally, nobody should be reasonably expected to write code that builds with any combination that isn't used on mozilla-central's TBPL. So, (clang, MSVC) is not really something to consider, for example. clang + MSVC is not a combination I expect us to support anytime soon. My main intent was to point out that library polyfilling is much harder than it is for compiler features. Look at the mess that is determining when we can use atomic. I agree with you. That is exactly why I suggested using the latest versions of every compiler whenever possible, and otherwise reducing the number of compiler+library combinations we need to deal with. functionality. The only time we should be requiring less than the latest version of any compiler on any platform is when that compiler is the compiler used for official builds on that platform and the latest version doesn't work well enough. I disagree. My baseline recommendation is that we should support the newest compiler present on a stable distribution (I assume Debian stable for a given ESR. This amounts to gcc 4.7 in practice on Linux at the moment. Windows and OS X compiler support is harder to gauge, but I think we should at least support the last two released versions of a compiler at any given time. Clang releases roughly every 6 months and MSVC is moving to a roughly yearly release schedule. This means that we should generally expect to support any compiler version released in the last two or three years. I am fine with you and Mike and others disagreeing with me. But, it is frustrating that you are saying that we should/must do these things, without providing any explanation of the reasoning behind your suggestions. Please explain why you are suggesting these things. I think we need a single polyfill for C++ standard library features. NSPR was that for C and POSIX, but as we get increasingly powerful things in standard C++, it makes less sense to be using it for base platform support (asynchronous I/O and sockets are planned for a networking TS). I've been assuming that this C++ polyfill is MFBT, but it may make sense to separate the C++ polyfill (+ arguably some stuff like Assertions.h/Attributes.h) from the assorted other ADT stuff (like BloomFilter, SplayTree). That sounds reasonable to me. But, I'd rather us upgrade compiler requirements than have us write any new polyfills for MFBT that would be unnecessary in the face of upgraded compiler requirements. Then the great developers that are often writing this code for MFBT could be writing great code to do something else. That isn't to say that we need to convert everything that currently uses MFBT things to use standard library things, if we think that the MFBT equivalent is substantially better than what the standard library offers. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
On Thu, Aug 01, 2013 at 04:13:23PM -0700, Gregory Szorc wrote: We have a number of references to OS/2 throughout the build system and source tree. According to Kyle Huey OS/2 has likely broken since we removed --disable-ipc (bug 638755) in March 2011. There have been OS/2-related changes landing way after that date, so I doubt it is actually broken. In fact, there's been an OS/2 specific landing a week ago (!). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
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 even dropping GCC support completely in favor of clang, if it means that we can use more C++ language features and if it means we can avoid wasting time writing polyfills. Nobody saw installing a new version of GCC as part of the build environment as being a significant impediment. And how many of them have actually tried to install new versions of gcc from scratch? As someone who works in compiler development, I can tell you firsthand that setting up working toolchains is an intricate dance of getting several tools to work together--the libc headers, the standard C++ library headers, debugger, linker, and compiler are all maintained by different projects, and a version mismatch between any two of these can foul up getting things to work that requires a lot of time and patience to fix even by people who know what they're doing. Look, for example, at some of the struggles we have had to go through to get Clang-on-Linux working on the buildbots. Also, the limiting factor in using new C++ features right now is b2g, which builds with g++-4.4. If we fixed that, the minimum version per this policy would be g++-4.7. the limiting factor would either be STLport (which is much slower to adopt C++11 functionality than other libraries tied primarily to one compiler) or MSVC, which has yet to implement several C++11 features. Instead of arguing right now about whether or not the minimum version policy suggested by glandium and I is too conservative, perhaps we should wait until someone proposes a feature whose need for polyfilling would depend on that policy comes up. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
CCing the last two persons who submitted patches for OS/2 On Thu, Aug 01, 2013 at 04:13:23PM -0700, Gregory Szorc wrote: We have a number of references to OS/2 throughout the build system and source tree. According to Kyle Huey OS/2 has likely broken since we removed --disable-ipc (bug 638755) in March 2011. While OS/2 is a tier-3 supported build configuration [1], we will shortly be rewriting a bunch of the build rules to handle non-recursive compilation. Since OS/2 is effectively dead as an operating system and since it apparently hasn't been able to build mozilla-central since 2011 without many people complaining AFAIK, I'm proposing that we remove traces of OS/2 from the build system. This likely plays out as not carrying OS/2 support forward as we change things. If the OS/2 community wishes to submit patches to re-add support, we can accept them, just like any tier-3 platform. Just to be clear, I don't believe other tier-3 operating systems may fall victim during refactors. OS/2 is special in that the OS is officially dead and sufficiently different from other supported platforms. It therefore is a non-trivial burden for us to attempt support as we perform large refactors to the build system. Are there any objections to this proposal? Gregory Szorc Build Config Module Owner [1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
On Thu, Aug 1, 2013 at 4:38 PM, Mike Hommey m...@glandium.org wrote: There have been OS/2-related changes landing way after that date, so I doubt it is actually broken. In fact, there's been an OS/2 specific landing a week ago (!). Bug 501496 and bug 712105 were pretty mechanical changes that just mirrored changes to other widget implementations. I imagine they were done blindly and without testing. They should not be confused with actual OS/2 maintenance work. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
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 oldstable until its actual EOL next year. Which is why i want ESR24 to remain compilable with gcc 4.4. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
On 2013-08-01, at 7:38 PM, Mike Hommey wrote: On Thu, Aug 01, 2013 at 04:13:23PM -0700, Gregory Szorc wrote: We have a number of references to OS/2 throughout the build system and source tree. According to Kyle Huey OS/2 has likely broken since we removed --disable-ipc (bug 638755) in March 2011. There have been OS/2-related changes landing way after that date, so I doubt it is actually broken. In fact, there's been an OS/2 specific landing a week ago (!). I removed the NSPR TimeStamp implementation on May 4 2012. We've only been supporting POSIX, Windows and MacOSX since then. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Could this be why I'm starting to see banner ads in some of my newtab-page snapshots, despite never seeing them in a tab? I don't appear to see this on an old nightly24 snapshot I have lying around. -Jeff - Original Message - From: Gavin Sharp ga...@gavinsharp.com To: dev-platform dev-platform@lists.mozilla.org Cc: firefox-dev firefox-...@mozilla.org Sent: Tuesday, July 30, 2013 4:10:34 PM Subject: reminder: content processes (e10s) are now used by desktop Firefox I've mentioned this at the engineering meeting, but thought it worth a note here just to ensure everyone is aware: Bug 870100 enabled use of the background thumbnail service in Firefox desktop, which uses a browser remote=true to do thumbnailing of pages in the background. That means that desktop Firefox now makes use of E10S content processes. They have a short life time (one page load) and are generally triggered by opening about:newtab when thumbnails are missing or out of date (2 days old). This has exposed some e10s crashes that previously weren't exposed on desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to track them - please hang any other such crashes off that bug. If you're working in a component that has e10s-related crashes, please fix them :) (Bug 891218 is also planning to make use of content processes for some Social-related functionality. Those remote processes will be longer-lived, typically having the same lifetime as the parent process.) Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Seems likely, I recall markh mentioning something similar - adblock probably doesn't work in the content process. Gavin On Thu, Aug 1, 2013 at 5:38 PM, Jeff Gilbert jgilb...@mozilla.com wrote: Could this be why I'm starting to see banner ads in some of my newtab-page snapshots, despite never seeing them in a tab? I don't appear to see this on an old nightly24 snapshot I have lying around. -Jeff - Original Message - From: Gavin Sharp ga...@gavinsharp.com To: dev-platform dev-platform@lists.mozilla.org Cc: firefox-dev firefox-...@mozilla.org Sent: Tuesday, July 30, 2013 4:10:34 PM Subject: reminder: content processes (e10s) are now used by desktop Firefox I've mentioned this at the engineering meeting, but thought it worth a note here just to ensure everyone is aware: Bug 870100 enabled use of the background thumbnail service in Firefox desktop, which uses a browser remote=true to do thumbnailing of pages in the background. That means that desktop Firefox now makes use of E10S content processes. They have a short life time (one page load) and are generally triggered by opening about:newtab when thumbnails are missing or out of date (2 days old). This has exposed some e10s crashes that previously weren't exposed on desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to track them - please hang any other such crashes off that bug. If you're working in a component that has e10s-related crashes, please fix them :) (Bug 891218 is also planning to make use of content processes for some Social-related functionality. Those remote processes will be longer-lived, typically having the same lifetime as the parent process.) Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On Thu, Aug 1, 2013 at 5:46 PM, Gavin Sharp ga...@gavinsharp.com wrote: Seems likely, I recall markh mentioning something similar - adblock probably doesn't work in the content process. That seems... less than ideal. I don't think creeping down the e10s path when all the e10s issues haven't yet been resolved is a good idea. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On Thu, Aug 1, 2013 at 6:24 PM, Nicholas Nethercote n.netherc...@gmail.comwrote: On Thu, Aug 1, 2013 at 5:46 PM, Gavin Sharp ga...@gavinsharp.com wrote: Seems likely, I recall markh mentioning something similar - adblock probably doesn't work in the content process. That seems... less than ideal. I don't think creeping down the e10s path when all the e10s issues haven't yet been resolved is a good idea. Do you have specific issues you're worried about, or are you just speaking about issues in general? In general, I don't see us resolving e10s issues until we have some incentive to do so, and get some sense of their relative severity. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
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 content processes being used for the background thumbnailing service that might not make the two cases directly comparable. It would be valuable for an adblockplus developer to investigate, certainly. Gavin On Thu, Aug 1, 2013 at 6:28 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Aug 2, 2013 at 1:24 PM, Nicholas Nethercote n.netherc...@gmail.comwrote: On Thu, Aug 1, 2013 at 5:46 PM, Gavin Sharp ga...@gavinsharp.com wrote: Seems likely, I recall markh mentioning something similar - adblock probably doesn't work in the content process. That seems... less than ideal. I don't think creeping down the e10s path when all the e10s issues haven't yet been resolved is a good idea. I thought AdBlock in particular we did have working with e10s. Maybe those changes haven't landed yet, or maybe it doesn't know about the hidden tabs where we load sites for thumbnailing. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
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 breakage with our #1 add-on makes me worry in general. In general, I don't see us resolving e10s issues until we have some incentive to do so, and get some sense of their relative severity. Huh? This sentence seems entirely antithetical to our standard operating procedure. I.e. backing out known regressions, etc. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On Thu, Aug 1, 2013 at 6:50 PM, Nicholas Nethercote n.netherc...@gmail.com 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 breakage with our #1 add-on makes me worry in general. To be clear, the issue is that thumbnails don't have ABP enabled, not that ABP falls over in general. In general, I don't see us resolving e10s issues until we have some incentive to do so, and get some sense of their relative severity. Huh? This sentence seems entirely antithetical to our standard operating procedure. I.e. backing out known regressions, etc. It's a trade-off, right? You can have thumbnails with ABP that jank the browser, or you can have thumbnails without ABP that don't. (AIUI the oop business also fixes the issue where thumbnails showed private data, like bank account info. There are probably other things it fixes too.) Showing banner ads in the screencaps doesn't seem like a big deal to me compared to what we get in return... I guess the biggest issue from my perspective might be that we're allowing advertisers to track us, by making HTTP requests we otherwise wouldn't. Hopefully we send the cookies to /dev/null, but even still they get our IP. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On Thu, Aug 1, 2013 at 6:50 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Huh? This sentence seems entirely antithetical to our standard operating procedure. I.e. backing out known regressions, etc. What known regression are you referring to here? Ads on thumbnails? That seems like a much less serious problem than the one that background thumbnailing solves (thumbnails missing entirely). Obviously the crashes and such will need to get fixed, and we won't ship the feature until we're happy with its overall quality. But the feedback we're getting from it being enabled on Nightly is invaluable. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On 08/01/2013 06:50 PM, 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 breakage with our #1 add-on makes me worry in general. Without special support, addons won't see content in the remote thumbnail processes since they don't have access to the DOM there. We have been working on making Adblock and other addons work in other processes, but the code isn't ready to ship. In general, I don't see us resolving e10s issues until we have some incentive to do so, and get some sense of their relative severity. Huh? This sentence seems entirely antithetical to our standard operating procedure. I.e. backing out known regressions, etc. As far as I know, the only strict backout policy we have is for performance regressions on certain commonly accepted benchmarks. It would be impractical to backout any change that causes a regression in anything. I think decisions about the thumbnail code should be made on the merits of that code alone. Personally I think that the benefits of generating the thumbnails off the main thread outweigh the loss of ad blocking in the thumbnails. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
