Summary: Stepping through code should point to the next thing that will execute. Test: 1. <script> 2. function foo(a, b) { return a + b; } 3. function a() { return 1; } 4. function b() { return 2; } 5. var x = 1; 6. foo( 7. a(), 8. b() 9. ); Steps to Reproduce: 1. Inspect test page 2. Set a breakpoint on line 5 3. Reload => Pause on breakpoint 4. Step through the code (step-over) => Can be confusing what is about to execute Notes: When stepping through code in different debugger environments we get different behavior: - WebKit: will stop at lines [5, 6] => "x = 1", "foo(...)" - Chrome: will stop at lines [5, 6] => "x = 1", "foo(...)" - Firefox: still stop at lines [5, 6, 7, 8, 6] => "x = 1", "foo(...)", "a()", "b()", "foo(...)" - lldb: would stop at lines [5, 7, 8, 6] => "x = 1", "a()", "b()", "foo(...)" I think the lldb approach makes the most sense. It is the smartest. In WebKit/Chrome you may not realize that you could step into "a()" or "b()". In lldb it is very clear that those will execute and you are given the opportunity to step over or into them. Firefox is close, but it is unclear what the first stop on line 6 mean given the stop at 7 and 8 happen before returning to and really executing line 6. Proposed stepping locations: - Proposed stop at lines [5, 7, 8, 6] => "x = 1", "a()", "b()", "foo(...)" Reasoning: - Stop at any location where the developer should be offered the choice to step over or into - this means function calls in execution order. foo(a(), b()) stops first at a(), then b(), then foo()
<rdar://problem/28181548>
Fixed by Bug 161658. *** This bug has been marked as a duplicate of bug 161658 ***