On 8 May 2014, at 22:02, Irving Reid irv...@mozilla.com wrote:
I've recently fought my way through a bunch of intermittent test
failures in the Add-on Manager mochitest-browser suite, and there's a
common anti-pattern where tests receive a Window callback, usually
unload, and proceed to do
On 25/06/2014 15:16:04, Chris Mills wrote:
It looks like a good place to put this information would be as a subsection of
https://developer.mozilla.org/en/docs/Mochitest#Writing_tests
Can you add in a brief section covering this point, along with a brief code
snippet illustrating a good and a
Thanks for bringing this to dev-platform.
Dynamic analysis is something the security teams are particularly
interested in. Especially tainting user input is something we could make
use of across the project: Existing security efforts for Firefox OS,
Firefox Desktop, Firefox Mobile and our
Those are just the API root paths, for reference. For example, to view
a bug, they would be
https://bugzilla.mozilla.org/bzapi/bug/35
https://bugzilla.mozilla.org/rest/bug/35
Mark
On 2014-06-22, 4:42 AM, Josh Matthews wrote:
[5] https://bugzilla.mozilla.org/bzapi
[6]
Yes!!
On 6/25/14, 8:15 AM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
Yes! We'd absolutely love to show code
On 6/25/14, 8:15 AM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
As someone who develops JS for Firefox features,
On 6/25/14 5:15 PM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
I usually don't do this, but since the others have mentioned all the
good reasons and I am likewise totally excited about code
How does a gamepad differ from say a keyboard?
What is the purpose of the actor?
I just figured I'd ask these basic questions to help clarify some of the
details that might otherwise be missing.
I'm guessing that dealing with analog joysticks wouldn't be event based, but
would be more of a
Tainting could also be of use in a particular problem area for Content
Security Policy (CSP): allowing modifications to CSP-protected pages
caused by add-ons or bookmarklets. At the moment, such modifications
(e.g. an add-on injecting tags into a page) are indistinguishable from
malicious content
This is terrific!
The docs make mention of POST under bz_rest_options. Do you now (or will you at
some point) support bug creation via API? Would you do full CRUD at some point?
I'm excited to tinker with this. I'd guess REST support will eventually lead to
more creative interfaces on top of
On 6/25/2014 10:15 AM, Jason Orendorff wrote:
We're considering building a JavaScript API for dynamic analysis of JS
code.
Here's the sort of thing you could do with it:
- Gather code coverage information (useful for testing/release mgmt?)
I've begged this several times, and, as I
On 25 Jun 2014, at 20:04, Fitzgerald, Nick nfitzger...@mozilla.com wrote:
Record/replay is such a holy grail (eclipsed only by time traveling /
reverse and replay interactive (as opposed to a static recording) debugging
with live, on-stack code editing) that I hesitate to even get my hopes
On 06/25/2014 01:04 PM, Fitzgerald, Nick wrote:
Yes! We'd absolutely love to show code coverage in the debugger's
source editor! We've played with implementations based on
Debugger.prototype.onEnterFrame and hidden breakpoints, but it is
pretty slow and feels like a huge hack. Would this work
On 6/25/14, 1:06 PM, Jason Orendorff wrote:
An alternative involves letting you modify JS code just before it's
compiled (source-to-source transformation). This is more general (you
could modify the instrumented code arbitrarily, and react
synchronously as it executes) but maybe that's
On Thu, Jun 26, 2014 at 8:06 AM, Jason Orendorff jorendo...@mozilla.com
wrote:
An alternative involves letting you modify JS code just before it's
compiled (source-to-source transformation). This is more general (you could
modify the instrumented code arbitrarily, and react synchronously as it
Hi everyone,
Brian Hackett, Bobby Holley, and I have been working on some changes to the way
that add-ons run (bug 990729). These changes make possible a lot of awesome new
features for monitoring add-on performance and memory usage (which I'll talk
about below). However, there's the
Record/replay would be incredibly useful for game developers trying to
do automated testing or go back and analyze a rare failure case that
happens occasionally. I already do a bunch of this on my end by
recording API calls and results and such, having it at a lower JS
level would be incredibly
On Tue, Nov 19, 2013 at 11:02:52AM +0900, Mike Hommey wrote:
Hi,
I am going to land a long series of patches that changes how Gecko code
linkage is defined.
Currently, when you add new code (like, a new module) to Gecko, you:
- Add a new directory
- Edit the parent moz.build to add the
Hello all,
I'm one of the maintainers of the Jalangi dynamic analysis framework for
JavaScript:
https://github.com/SRA-SiliconValley/jalangi
Jalangi works via source-to-source transformation, and we already have an
implementation of many of the clients you listed (e.g., record/replay, taint
I agree with Rob that S2S would give the most flexibility. Something similar
to java.lang.instrumentation API would be immensely useful
(http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html).
I am a maintainer and developer of Jalangi
20 matches
Mail list logo
