Re: Ideas for making it easier and less error prone for Firefox OS partners to expose certified only APIs
On Fri, Jan 17, 2014 at 10:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Our Firefox OS partners occasionally need to expose new APIs to Firefox OS devices for things such as testing and diagnostics purposes. What's that more concretely? Testing and diagnostics sounds like an euphemism for Carrier IQ-like things, which would be privacy and brand-sensitive. In general, though, it seems to me that having partners patch Gecko is bad in the sense that it makes it harder to move to a future where the device vendor ships Gonk (analogous to Android) and Mozilla ships Gecko updates (analogous to Google Play Services). Have we given up on getting to a future where Mozilla ships Gecko updates and Firefox OS users get an up-to-date Gecko from Mozilla the way desktop and Android users do? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
using LLDB to debug Gecko
Hi, For those of you who are using LLDB -- either by choice, or against your will after upgrading to OS X 10.9 -- I've added some Gecko-specific LLDB functionality to an .lldbinit file in the tree. I've mainly started with porting across the commands from the in-tree .gdbinit that were still useful. You can read about it here: http://mcc.id.au/blog/2014/01/lldb-gecko Let me know if you have any ideas for further commands and type summaries we could add! Cameron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: using LLDB to debug Gecko
This is fantastic, thank you so much! a few months ago, I started looking into porting the pretty printers and niceties for various SpiderMonkey things that live in js/src/gdb, but the way much of this works is very different from gdb, so I didn't get too far back them. This makes me want to pick that project up again. On Tue, Jan 21, 2014 at 11:09 AM, Cameron McCormack c...@mcc.id.au wrote: Hi, For those of you who are using LLDB -- either by choice, or against your will after upgrading to OS X 10.9 -- I've added some Gecko-specific LLDB functionality to an .lldbinit file in the tree. I've mainly started with porting across the commands from the in-tree .gdbinit that were still useful. You can read about it here: http://mcc.id.au/blog/2014/01/lldb-gecko Let me know if you have any ideas for further commands and type summaries we could add! Cameron ___ 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: Terminating xulrunner?
Hi Gio, please read the previous messages in this thread: they contain answers to all these questions. In fact, they're pretty much all answered right in the first message[1]. [1]: https://groups.google.com/d/msg/mozilla.dev.platform/o99wQZBjIJw/4eBoWbjEzjAJ On Tue, Jan 21, 2014 at 7:02 AM, gio...@mozilla-hispano.org wrote: Hi, I have some questions, and would be nice if someone could answer. I will really appreciate. * Mozilla will not provide more Xulrunner builds (runtime)? * If not, developers will be able to compile Xulrunner builds from Mozilla code? * Will Mozilla continues the Xulrunner development? * What happens with Xulrunner based apps? *This is the more important to me* Maybe those questions are explained before, but could be great if someone could answer some of them. Regards, Gio ___ 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
Splitting of tests in the mochitest suite
It seems to me like the splitting algorithm for mochitests gives us different chunking results on different platforms, see this test failure for example: https://tbpl.mozilla.org/?tree=Mozilla-Inboundrev=746018b05d67. Is this expected? If not, is this easy to fix so that a given test always falls inside the same chunk if the number of chunks are equal on two different platforms? Thanks! -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Subpixel AA text rendering on OSX
On Jan 20, 2014, at 5:48 PM, Matt Woodrow m...@mozilla.com wrote: Hi, Currently in gecko we have code to determine if text being drawn into a transparent surface has opaque content underneath it. In the case where it doesn't we ask moz2d/cairo [1] to disable subpixel AA text rendering for this surface since it can have poor results depending on what the eventual background color is. However, this setting was only ever respected for the GDI font rendering backend with cairo, and the other backends ignored it (unless they do something internally?). Moz2D matched this until recently, until bug 941095 made the CoreGraphics backend start respecting the value as well. The two extreme examples of where this might matter are as follows: - A transparent surface with a very nearly opaque background color (the OSX content menus uses rgba(255,255,255,0.95) iirc). In this case it's probably ok to use subpixel AA since we're so close to opaque. The OSX context menu's used to get subpixel AA text in this case since the value was ignored, but no longer do (on nightly) since we respect the value. - A fully transparent surface containing only text. It should be fairly easy to get this to happen by 3d transforming a text element. I suspect we don't want subpixel AA here, since we have no idea what the final background color might be (and it could change every frame if the transform is animated). CG was previously still giving us subpixel AA in this case, but won't be any more. I suspect Safari will drop the sub pixel AA in this case and we should to. I doubt we want to ship the text quality regression for OSX context menus, so we need to find a solution to this. Preferably something that is consistent across backends :) Possible ideas: - Revert the change to the Moz2D CG backend. This takes us back to matching our previous behaviour, but not ideal to have Moz2D API functions that are ignored on some backends. I’d suggest we do this for now. OS X supports drawing subpixel-AA to partially transparent surfaces. I believe the amount of sub pixel AA depends on the alpha of the surface. (Imagine drawing sub-pixel aa text to a transparency group to get an idea of how this would work) On OS X we really only want to be disabling subpixel-AA when were drawing to surface that currently or will be not pixel aligned. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Splitting of tests in the mochitest suite
On 1/21/2014 12:05 PM, Ehsan Akhgari wrote: It seems to me like the splitting algorithm for mochitests gives us different chunking results on different platforms, see this test failure for example: https://tbpl.mozilla.org/?tree=Mozilla-Inboundrev=746018b05d67. Is this expected? If not, is this easy to fix so that a given test always falls inside the same chunk if the number of chunks are equal on two different platforms? Thanks! -- Ehsan http://ehsanakhgari.org/ We don't run the same never of tests on each platform, so I would say that it's expected, yes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Splitting of tests in the mochitest suite
On 1/21/2014, 12:54 PM, Gregory Szorc wrote: On 1/21/14, 9:05 AM, Ehsan Akhgari wrote: It seems to me like the splitting algorithm for mochitests gives us different chunking results on different platforms, see this test failure for example: https://tbpl.mozilla.org/?tree=Mozilla-Inboundrev=746018b05d67. Is this expected? If not, is this easy to fix so that a given test always falls inside the same chunk if the number of chunks are equal on two different platforms? It's a hard problem until all tests are in .ini manifests and automation is manifest driven. Currently, the tests archive only contains mochitests that are active in the current build configuration and the test runners look at the filesystem for test discovery. To have consistent bucketing, we'd need test archives to be the same on all configurations so the bucketing algorithm would operate consistently [by taking skipped tests into consideration]. Hmm, do you know what the current algorithm tries to do? I think that we should be able to apply the same bucketing rule to all platforms, and get buckets of potentially different sizes due to running different sets of tests on different platforms, but still have each test appear in the same test suite. Alternatively, we write the bucketing information into the test archive at archive generation time. Either way, we need bug 920185 to be finished. How close is that bug? There seems to be only two remaining blockers. Are there blockers which have not been filed yet? Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: using LLDB to debug Gecko
Yeah. In general there are still some pain points using lldb, since a lot of automation still assumes gdb (I'm looking at you, jit-tests). We're going to have to use lldb going forward, so I think we should make it a priority to improve the developer experience when using it. bholley On Tue, Jan 21, 2014 at 2:31 AM, Till Schneidereit t...@tillschneidereit.net wrote: This is fantastic, thank you so much! a few months ago, I started looking into porting the pretty printers and niceties for various SpiderMonkey things that live in js/src/gdb, but the way much of this works is very different from gdb, so I didn't get too far back them. This makes me want to pick that project up again. On Tue, Jan 21, 2014 at 11:09 AM, Cameron McCormack c...@mcc.id.au wrote: Hi, For those of you who are using LLDB -- either by choice, or against your will after upgrading to OS X 10.9 -- I've added some Gecko-specific LLDB functionality to an .lldbinit file in the tree. I've mainly started with porting across the commands from the in-tree .gdbinit that were still useful. You can read about it here: http://mcc.id.au/blog/2014/01/lldb-gecko Let me know if you have any ideas for further commands and type summaries we could add! Cameron ___ 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: Splitting of tests in the mochitest suite
On 1/21/14, 10:25 AM, Ehsan Akhgari wrote: On 1/21/2014, 12:54 PM, Gregory Szorc wrote: On 1/21/14, 9:05 AM, Ehsan Akhgari wrote: It seems to me like the splitting algorithm for mochitests gives us different chunking results on different platforms, see this test failure for example: https://tbpl.mozilla.org/?tree=Mozilla-Inboundrev=746018b05d67. Is this expected? If not, is this easy to fix so that a given test always falls inside the same chunk if the number of chunks are equal on two different platforms? It's a hard problem until all tests are in .ini manifests and automation is manifest driven. Currently, the tests archive only contains mochitests that are active in the current build configuration and the test runners look at the filesystem for test discovery. To have consistent bucketing, we'd need test archives to be the same on all configurations so the bucketing algorithm would operate consistently [by taking skipped tests into consideration]. Hmm, do you know what the current algorithm tries to do? I think that we should be able to apply the same bucketing rule to all platforms, and get buckets of potentially different sizes due to running different sets of tests on different platforms, but still have each test appear in the same test suite. See testing/mochitest/chunkifyTests.js. AFAICT it's a simple bucket grouping or a directory-based bucket grouping. Alternatively, we write the bucketing information into the test archive at archive generation time. Either way, we need bug 920185 to be finished. How close is that bug? There seems to be only two remaining blockers. Are there blockers which have not been filed yet? A very crude grep reveals 41 Makefile.in with MOCHITEST appearing in them. More bugs likely need to be filed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Today, 21 January 2014 at 2:00pm PST
The next MemShrink meeting will be brought to you by about:memory on B2G: https://bugzilla.mozilla.org/show_bug.cgi?id=948774 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 21 January, 2:00 PM PST * http://arewemeetingyet.com/Los%20Angeles/2014-01-21/14:00/MemShrink%20Meeting * Vidyo: Memshrink * MTV: Very Good Very Mighty, Mountain View office, 3rd floor * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Splitting of tests in the mochitest suite
On 1/21/2014, 2:19 PM, Gregory Szorc wrote: On 1/21/14, 10:25 AM, Ehsan Akhgari wrote: On 1/21/2014, 12:54 PM, Gregory Szorc wrote: On 1/21/14, 9:05 AM, Ehsan Akhgari wrote: It seems to me like the splitting algorithm for mochitests gives us different chunking results on different platforms, see this test failure for example: https://tbpl.mozilla.org/?tree=Mozilla-Inboundrev=746018b05d67. Is this expected? If not, is this easy to fix so that a given test always falls inside the same chunk if the number of chunks are equal on two different platforms? It's a hard problem until all tests are in .ini manifests and automation is manifest driven. Currently, the tests archive only contains mochitests that are active in the current build configuration and the test runners look at the filesystem for test discovery. To have consistent bucketing, we'd need test archives to be the same on all configurations so the bucketing algorithm would operate consistently [by taking skipped tests into consideration]. Hmm, do you know what the current algorithm tries to do? I think that we should be able to apply the same bucketing rule to all platforms, and get buckets of potentially different sizes due to running different sets of tests on different platforms, but still have each test appear in the same test suite. See testing/mochitest/chunkifyTests.js. AFAICT it's a simple bucket grouping or a directory-based bucket grouping. Right. OK, so the only way that the chunk would differ per platform would be if an entire test directory is omitted on a given platform. I guess it's possible to handle that would be to get a list of such directories and special case them, but that doesn't seem like something which I'm inclined to work on. So I guess we'll have to live with this sub-optimal behavior for now. :( Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ideas for making it easier and less error prone for Firefox OS partners to expose certified only APIs
On 1/21/2014, 4:27 AM, Henri Sivonen wrote: On Fri, Jan 17, 2014 at 10:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Our Firefox OS partners occasionally need to expose new APIs to Firefox OS devices for things such as testing and diagnostics purposes. What's that more concretely? Testing and diagnostics sounds like an euphemism for Carrier IQ-like things, which would be privacy and brand-sensitive. It could be anything really. Apparently it's common practice for vendors to include special hidden applications which directly talks to some hardware on the device, sending it various commands and reading various values out. These kinds of special purpose applications are used in certification and also for diagnosing problems when a customer brings the device in for repair. Note that the above may not be an exhaustive list of the cases where a partner may need to implement new APIs. I agree that such APIs can be privacy and brand-sensitive, but that is orthogonal to the purpose of my question here. I'm looking for ways to enable partners do this kind of thing more easily and more securely, to ensure that for example they don't end up exposing the API to non-certified contexts, etc. I'm not proposing implementing something which makes it impossible to make incorrect changes to Gecko here. In general, though, it seems to me that having partners patch Gecko is bad in the sense that it makes it harder to move to a future where the device vendor ships Gonk (analogous to Android) and Mozilla ships Gecko updates (analogous to Google Play Services). Have we given up on getting to a future where Mozilla ships Gecko updates and Firefox OS users get an up-to-date Gecko from Mozilla the way desktop and Android users do? I'm unaware of our plans for doing that, but indeed that sounds very hard if not impossible as long as Gecko modifications are permitted. Do you know who would be the right person to ask about the plans you're referring to? Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: using LLDB to debug Gecko
Really nice Cameron, thanks for doing this! Now if only I could get LLDB to work with GUD in emacs. If anyone has managed that, I'd love to hear about it. There was some elisp in the LLDB repo at one time but last I checked it had been removed and the last version that existed didn't work with the current version of emacs. - Seth On Jan 21, 2014, at 2:09 AM, Cameron McCormack c...@mcc.id.au wrote: Hi, For those of you who are using LLDB -- either by choice, or against your will after upgrading to OS X 10.9 -- I've added some Gecko-specific LLDB functionality to an .lldbinit file in the tree. I've mainly started with porting across the commands from the in-tree .gdbinit that were still useful. You can read about it here: http://mcc.id.au/blog/2014/01/lldb-gecko Let me know if you have any ideas for further commands and type summaries we could add! Cameron ___ 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
