User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2421.0 Safari/537.36 Steps to reproduce: Tried to walk the stack using devtools debugger and investigate values stored in variables Actual results: "Optimized away" - enough said, I think. Expected results: While devtools is open, do NOT allow IonMonkey to remove valuable information pertaining to the process (scripts) being debugged. At the very least, FF Developer Edition (Aurora) and Nightly should override/force javascript.options.ion:false

By way of background info, this is a thread from devtools mailing list: > The problem is not necessary coming from the DevTools, it might be caused by the optimizing compiler. Sounds likely. I will test again in a while and report back. > If this is caused by the optimizing compiler (IonMonkey), then you can disable it in "about:config", by turning off the option "javascript.options.ion" off. THANK YOU > Do not forget to turn it back on, for your navigation, or when measuring performances. Actually, for Dev Ed. and Nightly, I'll keep it OFF - it's a real PITA. > Can you describe how you are using the devtools, such that we can get a better understanding of what might be wrong? Well, in this particular instance, I'm using the debugger to trap a particularly awkward bug deep in a nested structure (where recursion is also likely happening, hard to say) and, having identified the exception and the point it occurred, then tried to step back on the call stack to investigate what put my code into that state. You know, normal everyday debugging in the debugger ;) Apart from "this" and a couple other window/global namespaced items, all vars were listed as "Optimized away" in the variables pane. The command line in the console issues "Error: Optimized out" when trying the same vars down there. This obviously rendered devtools utterly useless - what's the point of having the stack navigable if when using it it can't provide any info? (rhetorical). IMO, really, ion should be optimized for development practices when devtools is open, not force devs to switch to another dev platform. I'd file a bug report but at this stage, it's more a complaint.

Jen, this is a nasty gotcha for debugging particular types of code. I think we should try to make this better, admittedly most of the process will be advocating to the js team to make changes in Spidermonkey.

There's a careful balance of deoptimizing code when the debugger is connected. There are two ideals: one is that there are no noticeable perf regressions when the debugger is connect, since soon we are going to connect the debugger whenever the devtools are opened (not just when the debugger is clicked). The other is that you get a full view into what's happening in the system in the debugger. These ideals are in conflict. Ideally it's configurable, and I think the default for this should be on. But we shouldn't have to make users go into about:config to turn it off. In fact, could we just flip that pref ourselves in the debugger with an option? (we'll need some good UX to make sifting through many options feel nice)

(In reply to James Long (:jlongster) from comment #3) > ... since soon we are going to connect > the debugger whenever the devtools are opened (not just when the debugger is > clicked). Shame - I like the fact that the debugger is not activated until its tab is opened. > Ideally it's configurable, and I think the default for this should be on. Uh... not following you. I think the default for optimization should be OFF when devtools is open. Agreed? > But we shouldn't have to make users go into about:config to turn it off. In > fact, could we just flip that pref ourselves in the debugger with an option? > (we'll need some good UX to make sifting through many options feel nice) Possibly. But why ship a tool that can't be used "out of the box"? The best solution is to reconfigure settings auto-magically for developers when the devtools are open. That won't be possible for all settings in all circumstances, I agree, but again, why would you want a debugger that can't view variables? Seems like a no-brainer to me.

(In reply to Jeff Griffiths (:canuckistani) from comment #2) > Jen, this is a nasty gotcha for debugging particular types of code. I think > we should try to make this better, admittedly most of the process will be > advocating to the js team to make changes in Spidermonkey. Noted - as discussed on IRC, we'll talk to Jim et al and see what we can do.

Check out bug 1193046. We also want to make it possible to even be able to *use* a page when the tools are open (notably games). Disabling all optimizations when our tools are open significantly degrades performance. Heck, why not switch everything to interpreted mode, where everything is clearly debuggable? You wouldn't even be able to use most pages then, however. It's a balance.