Quantcast

Re: Bug #951769

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug #951769

ISHIKAWA,chiaki
(2014/04/28 19:08), ishikawa wrote:

> On (2014年04月28日 17:54), Neil wrote:
>> ishikawa wrote:
>>
>>> Is there some write up how to use this remote console/debugger?
>>> It happens that recent-enough TB seems to have it, too.
>>>  
>>>
>> Yes, I think you might be able to find more information here:
>> https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging
>>
>>> when I connected it, the console/debugger (meant for JavaScript) showed many files: in fact, so many it is difficult to scroll down to the desired file.
>>>  
>>>
>> There is a search facility so you can type some letters of the file and
>> then select it from an autocomplete list.
>>
>>> Also, there are files which are not loaded at the time of startup, and only when the execution reaches certain point, the file is loaded in. I am not entirely sure of how to set a breakpoint in such dynamically loaded (or lazy-loaded might be a better term.). And some buggy behavior I wanted to check only happen in such lazy-loaded files.
>>>  
>>>
>> As I recall, what worked for me was to open the window that used that
>> file, close it again, then set the breakpoint.
>>
>
> Thank you for all the tips.
> I will report what I will find.
>
> Yeah, I thought there ought to be a better method than
> inserting dump() in the source and rebuild :-)
> Especially for JS script file.
>
> TIA
>
>

Hi,
This is what I found out.

I could connect to TB under linux from FF under windows.

TB needs to set:
devtools.debugger.force-local    false (to allow non-local connection)
devtools.debugger.remote-enabled true (to allow remote debug connection
at all)

Now thanks to the tips, I could type in the file name
and move to it after TB started and wait for user interaction.
(Before, I was looking at the list files in the left column and
was at a loss to figure out where tree.xml is located!)

I was trying to debug an issue reported in
bugzilla Bug 1003240 - JS Engine reports FALSE-POSITIVE(?) "strict
warning" for "undefined property" under a certain condition.
https://bugzilla.mozilla.org/show_bug.cgi?id=1003240

so the file I was interested in was tree.xml.

(Note that it is .xml, and not .js file.)

Well, here lies the problem.
tree.xml defines some JavaScript code
that is invoked upon certain user interaction.
   onset="... JS snippet to assign a value to a variable or property of
a variable."
   onget="... JS snippet to return such a value."

   etc.

I think XBL framework (or some such) handles user interaction and
invokes these JS snippet to set/get variable/property values, do more
complicated stuff, etc.
(using eval()?)

Unfortunately, probably because of this dynamical binding nature or
simply  because tree.xml is not JS file, the JS debugger does not seem
to recognize the file as containing JS snippets.
Or more precisely, I can't seem to set breakpoints and have them honord
in the code as follows.:
(Well when I click "set breakpoint" from the context menu,
a mark is placed on that line of tree.xml, but
the breakpoint does not seem to be honored. I never had TB stop on that
line.)

   <implementation implements="nsIDOMXULTreeElement,
nsIDOMXULMultiSelectControlElement">

      <!-- ///////////////// nsIDOMXULTreeElement ///////////////// -->

      <property name="columns"
                onget="if (typeof (this.treeBoxObject.columns) === 'undefined')
dump('\n dump UNDEFINED\n');
                       if (! ('columns' in this.treeBoxObject) )
dump('\n dump UNDEFINED 2\n');
                       if (typeof (this.treeBoxObject.xxyyz) === 'undefined') dump('\n
dump xxyyz UNDEFINED\n');
                       if ( ! ('xxyyz' in this.treeBoxObject) ) dump('\n dump xxyyz
UNDEFINED 2\n');
                       if (typeof (this.treeBoxObject.XxYyz) === 'undefined') dump('\n
dump XxYyz UNDEFINED \n');
                       for (let o = this.treeBoxObject; o; o = Object.getPrototypeOf(o)) {
                           dump('searching for columns: ' +
uneval(Object.getOwnPropertyDescriptor(o, 'columns')) + '\n');
                       }
                       dump('\n this.treeBoxObject.columns = ' +
JSON.stringify(this.treeBoxObject.columns) + '; \n' );
                       return this.treeBoxObject.columns;
                      "/>

I wanted to set breakpoint at the beginning of code in

onget="if ..." above.

But JS debugger did not seem to honor the breakpoint there.

Obviously, XBL or whatever framework and JS debugger ought to be taught
together how to handle such debug request in dynamically executed code (?)

I think XBL or whatever framework uses eval("JS code") to implement the
necessary binding of user interaction and the JS snipet.
So it is a little tricky to place a breakpoint in the eval'ed code.
But at least JS-Engine seems to know WHERE this "JS code" comes from. It
at least prints out the source code line when it issues strict warning
in debug build.

E.g.: excerpt from remote debugger console connected to remote TB

mutating the [[Prototype]] of an object will cause your code to run very
slowly; instead create the object with the correct initial [[Prototype]]
value using Object.create steelApplication.js:783
ReferenceError: reference to undefined property
this.treeBoxObject.columns tree.xml:50  <=== ******
ReferenceError: reference to undefined property aTabType.panelId
tabmail.xml:352
TypeError: anonymous function does not always return a value
osfile_shared_front.jsm:551

Note the warning
reference to undefined property this.treeBoxObject.columns tree.xml:50

tree.xml:50 is the

<property name="columns" <--- line 50!
                onget="..."

quoted above.

BTW, I copied the warning message and the code from the JS remote
debugger window inside FF. Thank you for the tips again.

Well, I wonder how I can set breakpoint in a JS snippet in tree.xml
using JS debugger and have it honored.

Thinking that the JS snippet executed by eval() seems to
hold the original file and line number intact, then
I have an idea.
This may slow down the operation a little bit, but
if we can teach JS debugger, JS engine, XBL framework or whatever, to
check if a string argument for eval() [I am assuming eval() is used for
the dynamic binding] has a debug flag aside from the property that tells
JS Engine to the file name and line number, and if it does,
stop and pass the execution to the (remote) debugger, then
this tricky situation of debugging of JS snippet in tree.xml can be
handled by the current debugger.
(It all depends on how the dynamic binding handles the JS code snipet,
JIT, etc. But I think it pays to have this breakpoint feature available
even if it means that the code runs a 1-3 % lower.)

Well, I think this ought to be discussed in another newsgroup.
I wonder what that would be.
I put mozilla.dev.apps.js-debugger as Newsgroup, but did not set
the followup-to: yet.


TIA

PS: Aha, I just realized if there is an explicit function to pass
the execution to the JS debugger in a co-routine style from within a JS
program, maybe I can explicitly tell a JS snippet in tree.xml to pass
the control to JS debugger by embedding such a function in the snippet.
It is not as handy as setting breakpoint, though, since I need to
recompile TB whenever I need a new breakpoint in tree.xml.
This negates the attractiveness of JS debugger by half or more :-(




_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug #951769

Neil-4
ISHIKAWA, Chiaki wrote:

>I wanted to set breakpoint at the beginning of code in
>
>onget="if ..." above.
>
>But JS debugger did not seem to honor the breakpoint there.
>
That sounds bad, I hope you filed a bug for that.

In the mean time as a potential workaround you could try editing the
file locally to use the <getter> child node instead of the onget attribute.

--
Warning: May contain traces of nuts.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug #951769

ISHIKAWA,chiaki
On (2014年05月04日 05:31), Neil wrote:

> ISHIKAWA, Chiaki wrote:
>
>> I wanted to set breakpoint at the beginning of code in
>>
>> onget="if ..." above.
>>
>> But JS debugger did not seem to honor the breakpoint there.
>>
> That sounds bad, I hope you filed a bug for that.
>
> In the mean time as a potential workaround you could try editing the
> file locally to use the <getter> child node instead of the onget attribute.
>

Sorry for delayed response. I am afraid that I missed this due to
a long holiday week in Japan.


After reading this, I realize that you are trying to say
that a breakpoint set in <getter> child node of the <onget> attribute will
be honored
by the JS debugger?!

That sounds encouraging.

I will try that (well, not sure how it will be effective for my case, but
that can wait.)

(Yes, it is possible that I may not be doing something correct for "onget="
part.
I will re-check it that debugger does not honor the breakpoint there,
and then file a bug for that if confirmed.)

Thank you again for all the helpful tips.

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug #951769

Neil-4
ishikawa wrote:

>you are trying to say that a breakpoint set in <getter> child node of the <onget> attribute will be honored by the JS debugger?!
>
I don't actually know, but it's worth trying.

--
Warning: May contain traces of nuts.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug #951769

Neil-4
In reply to this post by ISHIKAWA,chiaki
ishikawa wrote:

><getter> child node of the <onget> attribute
>
Actually that should be <getter> child node of the <property> element
(instead of the onget attribute).

--
Warning: May contain traces of nuts.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Loading...