How to inspect Js callstack from C++ callstack, I am using visual studio to debugging

[Yonggang Luo]

  mozjs.dll!js::jit::BaselineScript::icEntryFromPCOffset(unsigned int
pcOffset) Line 553 C++
  mozjs.dll!js::jit::DebugModeOSRVolatileStub::invalid() Line 56 C++
  mozjs.dll!js::jit::DoGetElemFallback(JSContext * cx,
js::jit::BaselineFrame * frame, js::jit::ICGetElem_Fallback * stub_,
JS::Handle lhs, JS::Handle rhs,
JS::MutableHandle res) Line 4048 C++
  [External Code]
  [Frames below may be incorrect and/or missing]
  mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData &
data) Line 126 C++
  mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState
& state) Line 155 C++
  mozjs.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 411 C++
  mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args,
js::MaybeConstruct construct) Line 497 C++
  mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const
JS::Value & fval, unsigned int argc, const JS::Value * argv,
JS::MutableHandle rval) Line 531 C++
  mozjs.dll!js::DirectProxyHandler::call(JSContext * cx,
JS::Handle proxy, const JS::CallArgs & args) Line 467 C++
  mozjs.dll!js::CrossCompartmentWrapper::call(JSContext * cx,
JS::Handle wrapper, const JS::CallArgs & args) Line 465
C++
  mozjs.dll!js::Proxy::call(JSContext * cx, JS::Handle
proxy, const JS::CallArgs & args) Line 2678 C++
  mozjs.dll!js::proxy_Call(JSContext * cx, unsigned int argc,
JS::Value * vp) Line 3082 C++
  mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args,
js::MaybeConstruct construct) Line 468 C++
  mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const
JS::Value & fval, unsigned int argc, const JS::Value * argv,
JS::MutableHandle rval) Line 531 C++
  mozjs.dll!js::jit::DoCallFallback(JSContext * cx,
js::jit::BaselineFrame * frame, js::jit::ICCall_Fallback * stub_,
unsigned int argc, JS::Value * vp, JS::MutableHandle res)
Line 8251 C++
  [External Code]
  mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData &
data) Line 126 C++
  mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState
& state) Line 155 C++
  mozjs.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 411 C++
  mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args,
js::MaybeConstruct construct) Line 497 C++
  mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const
JS::Value & fval, unsigned int argc, const JS::Value * argv,
JS::MutableHandle rval) Line 531 C++
  mozjs.dll!js::DirectProxyHandler::call(JSContext * cx,
JS::Handle proxy, const JS::CallArgs & args) Line 467 C++
  mozjs.dll!js::CrossCompartmentWrapper::call(JSContext * cx,
JS::Handle wrapper, const JS::CallArgs & args) Line 465
C++
  mozjs.dll!js::Proxy::call(JSContext * cx, JS::Handle
proxy, const JS::CallArgs & args) Line 2678 C++
  mozjs.dll!js::proxy_Call(JSContext * cx, unsigned int argc,
JS::Value * vp) Line 3082 C++
  mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args,
js::MaybeConstruct construct) Line 468 C++
  mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const
JS::Value & fval, unsigned int argc, const JS::Value * argv,
JS::MutableHandle rval) Line 531 C++
> mozjs.dll!js::jit::DoCallFallback(JSContext * cx, js::jit::BaselineFrame * 
> frame, js::jit::ICCall_Fallback * stub_, unsigned int argc, JS::Value * vp, 
> JS::MutableHandle res) Line 8251 C++
  [External Code]
  mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData &
data) Line 126 C++
  mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState
& state) Line 155 C++
  mozjs.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 411 C++
  mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args,
js::MaybeConstruct construct) Line 497 C++
  mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const
JS::Value & fval, unsigned int argc, const JS::Value * argv,
JS::MutableHandle rval) Line 531 C++
  mozjs.dll!js::DirectProxyHandler::call(JSContext * cx,
JS::Handle proxy, const JS::CallArgs & args) Line 467 C++
  mozjs.dll!js::CrossCompartmentWrapper::call(JSContext * cx,
JS::Handle wrapper, const JS::CallArgs & args) Line 465
C++
  mozjs.dll!js::Proxy::call(JSContext * cx, JS::Handle
proxy, const JS::CallArgs & args) Line 2678 C++
  mozjs.dll!js::proxy_Call(JSContext * cx, unsigned int argc,
JS::Value * vp) Line 3082 C++
  mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args,
js::MaybeConstruct construct) Line 468 C++
  mozjs.dll!Interpret(JSContext * cx, js::RunState & state) Line 2620 C++
  mozjs.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 422 C++
  mozjs.dll!SendToGenerator(JSContext * cx, JSGeneratorOp op,
JS::Handle obj, JSGenerator * gen, JS::Handle
arg, js::GeneratorKind generatorKind, JS::MutableHandle
rval) Line 1781 C++
  
mozjs.dll!NativeMethod(JSContext
* cx, unsigned int argc, JS::Value * vp) Line 1943 C++
  mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args,
js::MaybeConstruct construct) Line 475 C++
  mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const
JS::Value & fval, unsigned int argc, const JS::Value *

Re: How to inspect Js callstack from C++ callstack, I am using visual studio to debugging

[Philipp Kewisch]

Not sure how this works in Visual Studio, but check out:

http://www-archive.mozilla.org/scriptable/javascript-stack-dumper.html

In gdb you can do "call DumpJSStack()"

Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: mochitest- mach commands

[Andrew Halberstadt]

This has now been merged to central. I've update the docs at:
https://developer.mozilla.org/en-US/docs/Mochitest
https://developer.mozilla.org/en-US/Firefox_OS/Automated_testing/Mochitests

In most cases just running |mach mochitest path/to/test/or/dir| will do
what you want. But if for some reason you need to restrict tests to a
specific flavor or subsuite, you can use --flavor (-f) or --subsuite
respectively.

E.g:
|mach mochitest-plain| becomes |mach mochitest -f plain|

Bug 1122590 is also fixed, so running |mach mochitest browser/devtools|
should now work. To exactly mimic the old |mach mochitest-devtools|
command, you'd use:
|mach mochitest -f browser --subsuite devtools|

Trying to run one of the old removed commands will print out a helpful
error message that provides examples using the new syntax.

If you have questions or things aren't quite working as expected, please
let me know.

-Andrew

On 13/05/15 03:54 PM, Andrew Halberstadt wrote:

As mentioned previously in another post, work is under way to remove
the flavor specific mochitest commands (e.g mach mochitest-plain,
mach mochitest-browser etc.). This is being tracked in bug 1164597
[1]. Bug description pasted below:


As part of an effort to make running tests as easy and intuitive
as possible, I'd like to consolidate all of the mochitest-
mach commands into the single |mach mochitest| command.

Currently |mach mochitest| will automatically detect the flavor of
mochitests you wish to run. If you specify a directory that
contains multiple flavors, each flavor will be run in sequence. For
example:

./mach mochitest dom/indexedDB

runs all the mochitest-chrome, mochitest-browser-chrome and
mochitest-plain tests in that directory. The flavor can be limited
by passing in -f (--flavor). So to only run the chrome tests in
that directory you'd use:

./mach mochitest -f chrome dom/indexedDB

Commands of the form |mach mochitest-| will be removed:

./mach mochitest-plain -> ./mach mochitest -f plain ./mach
mochitest-browser -> ./mach mochitest -f browser etc..

I believe this will make running tests easier and more intuitive.
The fact that different flavors of mochitest exist will become a
background implementation detail. Instead, an emphasis will be
placed on running directories of tests, or tests related to
certain features. The knowledge of which test belongs to which
flavor will no longer be required, but of course the ability to run
specific flavors will still be there for those who need it.

The described behaviour for |mach mochitest| above, already exists
today. This bug is about making it the defacto way to run
mochitests (maybe aside from |mach test|). This bug will also add
b2g and android support to |mach mochitest|.

Exceptions to this will be robocop, webapprt-chrome and
webapprt-content which for technical reasons will not be rolled
into |mach mochitest| (for now).



Please let me know if you have any questions or concerns, -Andrew

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1164597


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to inspect Js callstack from C++ callstack, I am using visual studio to debugging

[R Kent James]

On 6/1/2015 2:53 AM, Philipp Kewisch wrote:

Not sure how this works in Visual Studio, but check out:

http://www-archive.mozilla.org/scriptable/javascript-stack-dumper.html

In gdb you can do "call DumpJSStack()"

Philipp



Here's what I do.

After your C++ breakpoint is hit, in Visual Studio do:

1)  In the callstack, make sure that the selected line is in xul.dll

2)  Open Debug/Quickwatch

3)  For the Expression, enter "DumpJSStack()" (without quotes)

4)  You should see in the Console output results that look like this:

0 GenericSendMessage(msgType = 0) 
["chrome://messenger/content/messengercompose/MsgComposeCommands.js":2691]

this = [object ChromeWindow]
1 SendMessage() 
["chrome://messenger/content/messengercompose/MsgComposeCommands.js":2772]

this = [object ChromeWindow]
2 defaultController.commands.cmd_sendButton.doCommand() 
["chrome://messenger/content/messengercompose/MsgComposeCommands

.js":569]
this = [object Object]
3 defaultController.doCommand(aCommand = "cmd_sendButton") 
["chrome://messenger/content/messengercompose/MsgComposeComma

nds.js":726]
this = [object Object]
4 goDoCommand(aCommand = "cmd_sendButton") 
["chrome://global/content/globalOverlay.js":96]

this = [object ChromeWindow]
5 oncommand(event = [object XULCommandEvent]) 
["chrome://messenger/content/messengercompose/messengercompose.xul":1]

this = [object XULElement]

I always run with a console output (start Thunderbird as thunderbird.exe 
-console)


:rkent
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: status-firefox41: affected

[Philip Chee]

On 01/06/2015 12:18, glob wrote:
> this started happening via 
> https://bugzilla.mozilla.org/show_bug.cgi?id=972040
> 
> please file a bug and we'll apply per-product filtering -- currently 
> it'll be set on any product that has that flag.

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1170179

> (i'm not sure why seamonkey has that flag visible on its bugs)
And Thunderbird, Mail News Core.


Phil
-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Misplaced xpcomglue.lib

[Meenakshi Shankar]

On Thursday, 28 May 2015 08:09:55 UTC+5:30, Mike Hommey  wrote:
> On Wed, May 27, 2015 at 11:38:30AM -0700, Meenakshi Shankar wrote:
> > Hi,
> > 
> > We are using Firefox SDKS for our FF extension. The libs generated
> > after compiling Firefox 39 beta 1 source (using start-shell-msvc2013)
> > did not contain few libs (xpcomglue.lib,xpcomglue_s.lib,...) in the
> > "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\dist\lib" folder,
> > instead it was found at
> > "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\xpcom\glue\standalone". 
> > 
> > Can anyone kindly let us know,
> > 
> > 1) If there is any change in FF 39 sdk build binaries
> 
> Yes and no. There were changes that make libraries not installed to
> dist/lib anymore, but those never were the sdk libraries. The sdk
> libraries are in dist/sdk/lib.
> 
> Mike

Thanks Mike. 
After linking the xpcomglue_s.lib from the sdk path, below linker errors are 
seen

2>xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2001: unresolved 
external symbol __imp__moz_free
2>xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2001: unresolved 
external symbol __imp__moz_free
2>xpcomglue_s.lib(Unified_cpp_xpcom_glue2.obj) : error LNK2001: unresolved 
external symbol __imp__moz_free


Kindly let us know if any other lib which contains __imp__moz_free has to be 
included in the linker-input or does it need any preprocessor to be defined?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Misplaced xpcomglue.lib

[Mike Hommey]

On Mon, Jun 01, 2015 at 12:51:23PM -0700, Meenakshi Shankar wrote:
> On Thursday, 28 May 2015 08:09:55 UTC+5:30, Mike Hommey  wrote:
> > On Wed, May 27, 2015 at 11:38:30AM -0700, Meenakshi Shankar wrote:
> > > Hi,
> > > 
> > > We are using Firefox SDKS for our FF extension. The libs generated
> > > after compiling Firefox 39 beta 1 source (using start-shell-msvc2013)
> > > did not contain few libs (xpcomglue.lib,xpcomglue_s.lib,...) in the
> > > "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\dist\lib" folder,
> > > instead it was found at
> > > "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\xpcom\glue\standalone". 
> > > 
> > > Can anyone kindly let us know,
> > > 
> > > 1) If there is any change in FF 39 sdk build binaries
> > 
> > Yes and no. There were changes that make libraries not installed to
> > dist/lib anymore, but those never were the sdk libraries. The sdk
> > libraries are in dist/sdk/lib.
> > 
> > Mike
> 
> Thanks Mike. 
> After linking the xpcomglue_s.lib from the sdk path, below linker errors are 
> seen
> 
> 2>xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2001: unresolved 
> external symbol __imp__moz_free
> 2>xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2001: unresolved 
> external symbol __imp__moz_free
> 2>xpcomglue_s.lib(Unified_cpp_xpcom_glue2.obj) : error LNK2001: unresolved 
> external symbol __imp__moz_free

See bug 1168291.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Goodbye PR_LOG, hello MOZ_LOG

[Eric Rahm]

tl;dr - PR_LOG* are deprecated. Use MOZ_LOG* instead.

As part of the effort to improving logging in gecko we've started a transition 
to using a MOZ prefix and a new set of log levels [1]. I've just landed these 
changes on mozilla-inbound, if they stick this means you should no longer use 
PR_LOG and friends (and in most cases it won't work as we explicitly undef them 
in mozilla/Logging.h).

A quick transition guide:
  - #include "prlog.h" => #include "mozilla/Logging.h"
  - PR_LOG => MOZ_LOG
  - PR_LOG_TEST => MOZ_LOG_TEST

Additionally we have moved to using an enum class to specify log levels. This 
means that using integer constants to represent log levels in code no longer 
works, nor can you create pseudo log levels (such as, lets say, PR_LOG_DEBUG + 
2).

After some rather thorough discussion [2] we have settled on an enum class that 
provides a pretty decent mapping to the previous PR_LOG levels:

enum class LogLevel {
  Disabled = 0,
  Error,
  Warning,
  Info,
  Debug,
  Verbose,
};

Of note:
  - PR_LOG_ALWAYS was removed, usage was mostly transitioned to the new Info 
log level. 
  - Verbose was added and instances of PR_LOG_DEBUG + 1 were replaced with it
  - PR_LOG_ERROR mapped to level 2, Error maps to level 1
  - PR_LOG_WARNING mapped to level 3, Warning maps to level 2

Additionally, please note, there is now an Info level. This should probably be 
the default output level for most messages, but, of course, which log level to 
use is left to the discretion of the developer.

Also as previously noted [3]: please stop using |#ifdef PR_LOGGING|, PR_LOGGING 
is always enabled. Such usage has no effect and is misleading.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1165515
[2] https://groups.google.com/forum/#!topic/mozilla.dev.platform/t9cDvC8LHsM
[3] https://groups.google.com/forum/#!topic/mozilla.dev.platform/JNN0T07y_ww
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linked Data and a new Browser API event

[Anne van Kesteren]

On Sun, May 31, 2015 at 5:09 AM, Jonas Sicking  wrote:
> We should use whatever formats people are using to mark up pages. If that is
> microdata we should use that. If it's RDF we should use that. If its JSONLD
> we should use that.
>
> The API that is used to extract the data is irrelevant. That will be an
> internal API anyway. Effectively we should think of the browser api as an
> internal api. There is no way it will be standardized in any relevant
> timeframe.

Sure, but if our project has any success any competitor would have to
reverse engineer this mess. Which seems sad.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linked Data and a new Browser API event

[Karl Dubost]

Benjamin,

Le 30 mai 2015 à 21:35, Benjamin Francis  a écrit :
> But Microdata is only one of the formats widely used on the web today. I'd
> like to see some evidence-based discussion on which format(s) we should
> support to get the most possible value out of what already exists on the
> web. The examples we used in our prototype all use Open Graph, which seems
> quite widely used (mainly due to Facebook and Twitter) and is based on RDFa.

if not done yet, you might want to talk with Dan Brickley. He is working at 
Google on everything related to schema.org. danbri -AT- google.com

He might have access on how popular for each of those markup. 
It might be possible to have a conversion tables in between the different 
markups so making it easier to start with one markup and build up little by 
little.

Whatever you adopt as an internal API. I would recommend you publish along on 
how to write down these meta in Web pages, so it encourages authors to add 
those if not done yet. It will help enter into a virtuous circle with a very 
quick feedback loop ala:

1. You see you put data like this in the page
2. This is the result for the pinned page.



-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[dgraham]

We enabled native copy-to-clipboard on github.com today for Firefox Nightly 
visitors. The copy buttons no longer use a Flash widget in Nightly or Chrome!

Thanks so much for working on this, Ehsan.

David


On Wednesday, May 6, 2015 at 7:42:23 PM UTC-6, Ehsan Akhgari wrote:
> On 2015-05-06 2:51 PM, Mike Taylor wrote:
> > Hey David,
> >
> > On 5/6/15 13:09, dgra...@github.com wrote:
> >> Although IE 11 supports this API as well, we have not enabled it yet.
> >> The browser displays a popup dialog asking the user for permission to
> >> copy to the clipboard. Hopefully this popup is removed in Edge so we
> >> can start using JS there too. I just haven't had a chance to test with
> >> it yet.
> >
> > Thanks for mentioning this--I suspect other sites would also fall back
> > to Flash if our UX is similarly annoying.
> 
> Thanks David, this is really helpful.  I also agree that showing UI for 
> this feature decreases the usability to a degree that the Flash 
> alternative may be preferred.
> 
> >> Right now, there isn't a reliable way to feature detect for this API
> >> in JS. We use user agent detection instead, just for this feature. Any
> >> suggestions here would be much appreciated.
> >
> > You can use the document.queryCommandSupported()[1] or
> > document.queryCommandEnabled()[2] APIs to check for support.
> 
> So technically queryCommandSupported is the right way to feature detect 
> this.  Note that currently our implementation of queryCommandSupported 
> is buggy and it returns true for all of the command names that we know 
> of, including "cut", "copy" and "paste".  Over in 
> , we'll fix our 
> implementation so that we return true for "cut" and "copy" and false for 
> "paste".  So in Firefox, you'd be able to feature detect like this:
> 
> function isSupported() {
>return document.queryCommandSupported("copy") &&
>   !document.queryCommandSupported("paste");
> }
> 
> Chrome's implementation of this function is affected by 
> , but it 
> seems like it is getting fixed.  I have not tested IE's implementation 
> of queryCommandSuported yet.
> 
> Cheers,
> Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linked Data and a new Browser API event

[Jonas Sicking]

On Mon, Jun 1, 2015 at 4:31 PM, Anne van Kesteren  wrote:
> On Sun, May 31, 2015 at 5:09 AM, Jonas Sicking  wrote:
>> We should use whatever formats people are using to mark up pages. If that is
>> microdata we should use that. If it's RDF we should use that. If its JSONLD
>> we should use that.
>>
>> The API that is used to extract the data is irrelevant. That will be an
>> internal API anyway. Effectively we should think of the browser api as an
>> internal api. There is no way it will be standardized in any relevant
>> timeframe.
>
> Sure, but if our project has any success any competitor would have to
> reverse engineer this mess. Which seems sad.

I think we're already talking about reverse-engineering what search
engines and twitter/facebook/etc do.

But I'm still all for proper standardization. Including driving
towards good technical solutions.

But given how small marketshare browsers in general have as metadata
consumers, I think any standardization efforts would have to be driven
by the current matadata consumers, like search engines and social
networks.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linked Data and a new Browser API event

[Gordon Brander]

On June 1, 2015 at 17:34:48 , Jonas Sicking (jo...@sicking.cc) wrote:
> I think we're already talking about reverse-engineering what search
> engines and twitter/facebook/etc do.
> 
> But I'm still all for proper standardization. Including driving
> towards good technical solutions.

Yup. We’re really talking about 2 things in parallel:

1. Defining a standards-based approach to marking these things up (using 
pre-existing patterns where it makes sense). Encouraging authors to use it.

2. Creating internal APIs that will leverage this metadata, and in cases where 
the standards-based metadata does not exist, scraping reasonable results from 
other common metadata or markup patterns.

---
Gordon Brander
Sr Design Strategist  
Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform