Re: Announcing new test platform "Android 7.0 x86"
These tests run under normal GeckoView e10s mode, with one parent activity
process and one child service process. It should be very similar to desktop
e10s tests in terms of what tests run in which process.
Cheers,
Jim
On Sat, Nov 3, 2018, 4:01 AM Ehsan Akhgari wrote:
> Thanks a lot, this is great news!
>
> What's the process model configuration for this testing platform? Do these
> tests run in single process mode or are they running in some e10s like
> environment? Is there some documentation that explains what runs in which
> process?
>
> Thanks,
> Ehsan
>
> On Thu, Nov 1, 2018 at 5:44 PM Geoffrey Brown wrote:
>
> > This week some familiar tier 1 test suites began running on a new test
> > platform labelled "Android 7.0 x86" on treeherder. Only a few test suites
> > are running so far; more are planned.
> >
> > Like the existing "Android 4.2" and "Android 4.3" test platforms, these
> > tests run in an Android emulator running in a docker container (the same
> > Ubuntu-based image used for linux64 tests). The new platform runs an x86
> > emulator using kvm acceleration, enabling tests to run much, much faster
> > than on the older platforms. As a bonus, the new platform uses Android
> 7.0
> > ("Nougat", API 24) - more modern, more relevant.
> >
> > This test platform was added to support geckoview testing. Tests run in
> the
> > geckoview-based TestRunnerActivity (not Firefox for Android).
> >
> > To reproduce the main elements of this test environment locally:
> > - build for Android x86 (mozconfig with --target=i686-linux-android)
> > - 'mach android-emulator' or explicitly 'mach android-emulator --version
> > x86-7.0'
> > - install the geckoview androidTest apk
> > - run your test command using --app to specify the geckoview test app,
> > something like 'mach mochitest ... --app=org.mozilla.geckoview.test'
> >
> > Great thanks to the many people who have helped enable this test
> platform,
> > especially :wcosta for help with taskcluster and :jchen for investigating
> > test failures.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
>
> --
> Ehsan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
On Sat, Nov 3, 2018, 4:01 AM Ehsan Akhgari wrote:
> Thanks a lot, this is great news!
>
> What's the process model configuration for this testing platform? Do these
> tests run in single process mode or are they running in some e10s like
> environment? Is there some documentation that explains what runs in which
> process?
>
> Thanks,
> Ehsan
>
> On Thu, Nov 1, 2018 at 5:44 PM Geoffrey Brown wrote:
>
> > This week some familiar tier 1 test suites began running on a new test
> > platform labelled "Android 7.0 x86" on treeherder. Only a few test suites
> > are running so far; more are planned.
> >
> > Like the existing "Android 4.2" and "Android 4.3" test platforms, these
> > tests run in an Android emulator running in a docker container (the same
> > Ubuntu-based image used for linux64 tests). The new platform runs an x86
> > emulator using kvm acceleration, enabling tests to run much, much faster
> > than on the older platforms. As a bonus, the new platform uses Android
> 7.0
> > ("Nougat", API 24) - more modern, more relevant.
> >
> > This test platform was added to support geckoview testing. Tests run in
> the
> > geckoview-based TestRunnerActivity (not Firefox for Android).
> >
> > To reproduce the main elements of this test environment locally:
> > - build for Android x86 (mozconfig with --target=i686-linux-android)
> > - 'mach android-emulator' or explicitly 'mach android-emulator --version
> > x86-7.0'
> > - install the geckoview androidTest apk
> > - run your test command using --app to specify the geckoview test app,
> > something like 'mach mochitest ... --app=org.mozilla.geckoview.test'
> >
> > Great thanks to the many people who have helped enable this test
> platform,
> > especially :wcosta for help with taskcluster and :jchen for investigating
> > test failures.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
>
> --
> Ehsan
> ___
> 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
Use android-api-15 instead of android-api-11 on try
Hi all, Just a heads-up that, because of the recent API version bump, try runs should now use "android-api-15". Using "android-api-11" will not run any tests (though I wished the hg hook would tell you about it). I filed bug 1244463 to fix the trychooser. Cheers, Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and Servo training sessions at Whistler
Does the Servo session (which is earlier than the Rust session) require prior experience with Rust? Thanks, Jim On 6/8/15 3:44 PM, Lars Bergstrom wrote: The Research team will be holding a pair of 3 hour training sessions, with one on the new web rendering engine, Servo, and one on the new systems language it is implemented in, Rust. These sessions will have both presentation components and a large hands-on piece with exercises to do on your laptops. The Rust session will also have some content on building Rust code into Gecko. If you are interested in attending, please sign up on the Sched links below (you will have to log in and then click the “Add To My Sched” button). The numbers will help us figure out how many USB sticks to bring, how many people we need to have staffing the training, whether there is enough space in the booked room, whether we have enough stickers, etc. The Platform admins and managers have helped ensure that the Rust session will not conflict with any team’s meetings and that the Servo one will not conflict with meetings for teams that work on browser features, so you shouldn’t need to worry about something getting booked over them. Servo - Wednesday, 1–4 PM: http://sched.co/3ZQn http://sched.co/3ZQn Rust - Thursday, 1–4 PM: http://sched.co/3ZQp http://sched.co/3ZQp Please don’t hesitate to reach out if there are specific things you’d like to see us cover, as we’re making up the training materials right now. Thanks! - Lars ___ 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: Should we build a new in-process unwind library?
This is great! Thanks for working on it! Can the new library be used independently outside of SPS? For hang detection (bug 909974) we'd like to have the ability to unwind the hung thread's stack, and this library would be perfect for that. Cheers, Jim On 12/19/13 2:04 PM, Julian Seward wrote: Here's a status update. Recap: I proposed to create a new library to do fast in process CFI and EXIDX based stack unwinding, so as to be able to profile on tablets and phones with less overhead than using Breakpad. The library now exists. Tracking bug is 938157. It does CFI unwinding on x86_64-linux and arm-android, EXIDX on arm-android, and stack scanning (as a last resort) on both. Initial integration with SPS has been completed and it produces plausible profiles at least on x86_64-linux. Compared with the best Breakpad based schemes, this library gives easily a factor of 10 cost reduction for CFI unwinding. My best attempts with Breakpad achieved a cost of about 6600 insns/frame on x86_64-linux. The new library comes in at around 470 insns/frame, without much attempt at optimisation. It also facilitates implementation of the the kind of space-saving techniques documented in https://blog.mozilla.org/jseward/2013/09/03/how-compactly-can-cfiexidx-stack-unwinding-info-be-represented/ J ___ 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
Problem with scrollWidth and clientWidth for text inputs
Hello, I'm running into some problems working on bug 717878, which fixes scrollLeft/LeftMax/Top/TopMax/Width/Height for text inputs so that we can support panning the inputs in Fennec when they overflow. Currently, scrollLeft/LeftMax/Top/TopMax are all 0 and scrollWidth == clientWidth always for text inputs, because we don't return a scroll frame for text inputs [1]. However, once we do return a scroll frame, new problems come up. For our text input implementation, the element's padding is not part of the scroll frame (i.e. the padding does not scroll with the text [2] unlike a div). As a result, after the fix, the new scrollWidth doesn't include the padding, and because clientWidth is derived from the scroll frame, clientWidth doesn't include the padding either. This makes dom/tests/mochitest/general/test_offsets.html fail. Briefly reading the spec makes the impression that both scrollWidth and clientWidth should include the padding in this case, so at this point I'm not sure how to fix the scroll* properties while also having scroll/clientWidth include the padding [3]. Any ideas? Thanks, Jim [1] http://mxr.mozilla.org/mozilla-central/source/layout/forms/nsTextControlFrame.h?rev=1406ff031c19#42 [2] http://i.imgur.com/rsYaWH7.png [3] Textareas currrently have the same problem (http://jsfiddle.net/mj3Pz/1/), but we don't have a scroll/clientWidth test for it, so it doesn't appear to be broken. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Problem with scrollWidth and clientWidth for text inputs
Hm my bug shouldn't affect bug 157846, but a fix for bug 157846 might solve my problem as well. Thanks for the heads up! On 10/22/13 12:52 PM, Ehsan Akhgari wrote: Hmm, how does this work interact with bug 157846? On 2013-10-22 12:08 PM, Jim Chen wrote: Hello, I'm running into some problems working on bug 717878, which fixes scrollLeft/LeftMax/Top/TopMax/Width/Height for text inputs so that we can support panning the inputs in Fennec when they overflow. Currently, scrollLeft/LeftMax/Top/TopMax are all 0 and scrollWidth == clientWidth always for text inputs, because we don't return a scroll frame for text inputs [1]. However, once we do return a scroll frame, new problems come up. For our text input implementation, the element's padding is not part of the scroll frame (i.e. the padding does not scroll with the text [2] unlike a div). As a result, after the fix, the new scrollWidth doesn't include the padding, and because clientWidth is derived from the scroll frame, clientWidth doesn't include the padding either. This makes dom/tests/mochitest/general/test_offsets.html fail. Briefly reading the spec makes the impression that both scrollWidth and clientWidth should include the padding in this case, so at this point I'm not sure how to fix the scroll* properties while also having scroll/clientWidth include the padding [3]. Any ideas? Thanks, Jim [1] http://mxr.mozilla.org/mozilla-central/source/layout/forms/nsTextControlFrame.h?rev=1406ff031c19#42 [2] http://i.imgur.com/rsYaWH7.png [3] Textareas currrently have the same problem (http://jsfiddle.net/mj3Pz/1/), but we don't have a scroll/clientWidth test for it, so it doesn't appear to be broken. ___ 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
Hang monitoring for non-main threads
Hi all, I'm looking at implementing a hang monitoring mechanism for non-main threads. The initial motivation was that we've been noticing hangs on the compositor thread in Fennec. These hangs are not as easy to notice as main thread hangs, and we'd like more information about them like how frequently they occur. As we move more components off main thread, I think this kind of information could be useful to other areas as well. So far I looked at the main thread hang monitor [1], but it seems to make a lot of assumptions about the main thread. I think it would make sense to have a separate, generic hang monitor that can monitor multiple other threads. Each thread would register with the hang monitor and tell it how much time the thread must be blocked before it's considered a hang. The hang monitor would then relay counts/histogram of hangs to telemetry. It would be even better if we can get stacks. One thing I'm not sure about is we have a variety of threads (IPC threads, media threads, etc.), and I don't know how hard it would be to adapt them to use the hang monitor. Please share your comments and suggestions! Thanks, Jim [1] http://mxr.mozilla.org/mozilla-central/source/xpcom/threads/HangMonitor.cpp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tegra build backlog is too big!
Do we know why it's that much backed up? I started noticing it yesterday. Is it because of lots of inbound pushes? lots of try pushes? Lots of clobbering? Lots of tests? Jim On 9/11/13 5:31 PM, Kartikaya Gupta wrote: Earlier today the backlog on Android build jobs was on the order of 1300. It seems to be coming down a little now but for a while there I was worried it was going to grow unboundedly. Try jobs from over 10 hours ago still have pending jobs - as I'm sure you all know, having a 10-hour turnaround on try pushes is something of a productivity killer. I brought this up in #releng and one of the proposed solutions was to try to tweak the prioritization of jobs between Try and Inbound a little bit. I personally do like that Inbound jobs are prioritized above Try, but perhaps they don't need to be prioritized quite so much. However, changing this will affect a number of people, so it was suggested I bring the discussion here to get other people's comments. So, anybody have thoughts on a good way to solve this problem? Cheers, kats ___ 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: How to observe selection range within input element
Hi Xulei, I think you can use nsISelectionPrivate::addSelectionListener [1]. You can get nsISelectionPrivate through QueryInterface on nsISelection, which you can get from nsIEditor. Cheers, Jim [1] http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsISelectionPrivate.idl#52 On 8/28/13 5:24 AM, Yuan Xulei(袁徐磊) wrote: Hi all, I'm implementing b2g keyboard/IME api and encounter a problem with the selection range observing. We want to monitor the cursor position or selection range changes in current input element, which is a text input field or a content editable element receiving user's input. The cursor position or the selection range can be changed by 1) key events generated by virtual keyboard, 2) js code, 3) mouse events triggered by user. Currently we listen a pile of events(mousedown, mouseup, input...) to check if the selection range has been changed. It is inefficient and error prone. I wonder if there is a way to monitor the selection range changes from chrome js. Could anyone give me a clue? Thanks. ___ 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
