Community
Participate
Working Groups
Here the steps to recreate this scenario: 1. Create a simple static web project, that contains the following: - A JS file with these LOCs var msg = "This is the alert message ! but also... "; var x = 20; function popup() { msgAlertDispatcher(msg); } function msgAlertDispatcher(msg) { var y = 40; console.log('Msg 1'); console.log('Msg 2'); console.log('Msg 3'); console.log('Msg 4'); console.log('Msg 5'); alert (msg + " sum = " + (x + y)); } - An HTML that contains a button with onClick event to call the JS function popoUp(). 2. Deploy your web project in any web container. 3. Open the URL for the html page in Firefox (Firebug up and running and Crossfire already listening) 4. In Eclipse create a new Remote JavaScript configuration as follow: - In Connect tab, select "Crossfire - Remote Attach" and leave all defaults - In the Source tab, delete the Default "Source Lookup Path" and add your sample project (or workspace) instead. 5. Start to "Debug" 6. Go to Firebug, and select the script tab and set a break in the first console message. console.log('Msg 1'); 7. Click in the button so then your JS breakpoint is reached. 8. Accept the Eclipse notification to go to debug mode (if not there already) 9. By the time the breakpoint is reached Eclipse paused threads focus appears in the opposite order as user set the breakpoints, having this scenario, user needs to change manually the focus to the paused tread at the bottom of the list to reach the breakpoint. Also, after every F6/Step over. Users will expect to get focus in the first breakpoint and continue e.g. in the same file by doing F6's. Firefox versions either 6 or 7 Firebug 1.8.3 Crossfire 0.3a8
Created attachment 205861 [details] example file Here is an example HTML file that demonstrates the problem. Notice in the packet frame count is correct, but that the frame entries are all in the wrong order. I would expect the stack ordering to be: 0. top_of_stack() 1. two() 2. three() 3. bottom_of_stack() 4. onclick() The packet from Crossfire confirms (edited for brevity): (java.lang.String) Content-Length:7649 { "type":"response", "command":"backtrace", "seq":20, "requestSeq":19, "body":{ "fromFrame":0, "toFrame":4, "totalFrames":5, "frames":[ { "functionName":"two", "url":"file:///C:/Users/mrennie/Desktop/frames.html", "locals":{}, "line":11, "scopes":[{"index":0,"frameIndex":0,"scope":{"type":"object","handle":132}}] }, { "functionName":"three", "locals":{}, "line":15, "scopes":[{"index":0,"frameIndex":1,"scope":{"type":"object","handle":132}}] }, { "functionName":"bottom_of_stack", "locals":{}, "line":19, "scopes":[{"index":0,"frameIndex":2,"scope":{"type":"object","handle":132}}] }, { "functionName":"onclick", "locals":{}, "line":1, "scopes":[{"index":0,"frameIndex":3,"scope":{"type":"object","handle":132}}] }, { "functionName":"top_of_stack", "url":"file:///C:/Users/mrennie/Desktop/frames.html", "locals":{}, "line":7, "scopes":[{"index":0,"frameIndex":4,"scope":{"type":"object","handle":132}}] } ]}, "status":{"running":true,"code":0}, "contextId":"xf0.3::9756832"}
The fix for this bug was entirely in the Firebug / Crossfire implementation. Closing this as NOT_ECLIPSE
