Webstorm 6 - debug configurations
Hi all,
Not sure if I'm missing something here. I upgraded to Webstorm 6 last week and I seem to be missing an option when editting debug configurations. It says in the help system that there should be a checkbox "Single instance only" but it's not there any more. Is there a different way to stop WS from opening a new tab in Firefox every debug session?
Thanks
osc23
Please sign in to leave a comment.
Seems like you're looking at the default one. Please click "+" to create a new instance.
Hi Kirill,
Thanks for the quick reply. I don't understand your answer. I've used the + button to create two configurations in the attached screenshot and a third Unnamed one to follow your suggestion. None of them show the checkbox. What am I doing wrong? I followed the same steps I was using with WS 5.
Any suggestions?
Thanks again
osc23
Attachment(s):
run_debug.jpg
Hi,
I'm not sure if I get you right, but I think this is debug session is supposed to be runned once. Then it works with refreshing and all next debug triggers.
JS Debug configuration is singleto by default now. If new tab is opened on each run (ever if there is existong) — it is bug. Please specify path to open (I see empty value) and what do you see in browser address bar.
In WS:
K:\DEV\WEB\blah\web\index.html
In the browser:
file:///K:/DEV/WEB/blah/web/index.html
Windows 7
Firefox 19.0.2
JetBrains extension 0.5.20
Thanks
Please try to debug in Chrome. We will investigate this problem in Firefox.
I get the same thing in Chrome. Opens a new tab every time I debug.
JetBrains extension 0.5.7
Vladimir,
Is there any progress on this? It's quite frustrating.
Thanks
osc23
Please watch http://youtrack.jetbrains.com/issue/WEB-7167 It will be fixed in 6.0.1 or 6.0.2.
Having the same problem in 6.0.1, see my note below.
I'm running into the same issue in Chrome on Web Storm 6.0.1. While live edit is on, anytime I hit rerun and files have changed in the project the debugging session is opened in a new tab.
Even with live edit off, if I create a new file (say a brand new javascript file) and hit rerun then a new tab is opened.
I've found that using the "Reload in browser" feature I can refresh my app and it appears to be working as expected most of the time. However with new files if I try to hit "Reload in browser" it doesn't do anything unless I go to the root file (ie index.html) and reload from there. This was tested with live edit mode off, not sure if it does the same thing with live edit on.
Also reloading in the browser is only a workaround, because I assume things like "Before launch tasks" only work when you actually rerun. In my case I don't have any but others might...
I would expect rerun / reload in browser to always open in the same tab whether or not live edit mode is on or off. It's a big workflow killer. I have to remember to never hit rerun and for any new files to always hit refresh in browser from the root (index.html). Pretty confusing.
I'm actually in the evaluation period and am ready to purchase a license, because everything else is awesome! This is seemingly the only thing that's holding me back from purchasing. Netbeans 7.3 has a similar Chrome extension and rerunning works much better there and it seems to always open in the same tab with a fresh version of the app.
Is this still on the radar for being fixed for 6.0.2? I'm ready to purchase, but am hesistant until this issue is resolved. I don't mind providing a screencast of my problems if it would help.
Firefox — fixed (see http://youtrack.jetbrains.com/issue/WEB-7167)
Google Chrome — cannot reproduce, please try WebStorm 7 EAP and latest extension (https://chrome.google.com/webstore/detail/jetbrains-ide-support/hmhgeddbohgjknpmjagkdomcpobmllji?hl=en)
Rerunning the debug session (or stopping and restarting) still always opens in a new tab for me in Chrome. I'm running Webstorm 7 EAP and the latest Jetbrains Chrome extension (1.1) on Mac OSX 10.6. Haven't tried on my Windows box yet.
Attached a screencast showing the problem in action.
Attachment(s):
webstorm-chrome-tabs - Computer.m4v
Oh, I see, it is regression, will be fixed ASAP.
Version 1.3 was published, compatible with WebStorm 6.x-7.x
Awesome! This fixed the tab issue in Chrome! I did notice though that rerunning the debugger (or stopping and restarting the debugger) does not update the debug session with any new code changes. I'm still getting the old code unless I manually reload the browser. Seems like restarting the debugging session should bring in the latest code, no? Makes rerunning not so useful for me.
Made another screencast so you can see what I'm talking about.
Attachment(s):
webstorm-chrome-tabs#2 - Computer.m4v
Please watch&vote http://youtrack.jetbrains.com/issue/WEB-6109 Priority of this task will be increased.
Oh great, didn't realize it was already an open issue. Upvoted it. Webstorm is great editor and its only getting better. Thanks for addressing the Chrome tab issue so quickly!
Hi Vladimir
Great to see some movement on this. But I don't understand what to do next; I upgraded to 6.0.2 a week or two ago and I checked for updates on the Firefox addon yesterday. Is the fix going to be included in the next release? Also, can you confirm whether the Firefox extension is showing the same problems as the Chrome issues reported later please. We're approaching deadlines so I feel nervous about jumping to v7 if it's in nightly build status
Thanks
osc23
JS Debugger was greatly improved in WebStorm 7, but only for Google Chrome (just compare Variables view, blog post will be published soon). So, if you can, please use Google Chome (as you can see, Google Chome is default debug browser since WebStorm 6).
>> Firefox extension is showing the same problems as the Chrome issues reported later please
If you mean "Google Chrome does not refresh code automatically" — no (well, may be, investigation is not yet done). And this issue is not reproduced always (otherwise it would already have been fixed :)).
>> Is the fix going to be included in the next release?
Fix for firefox will not be included in WebStorm 6, only WebStorm 7.
>> jumping to v7 if it's in nightly build status
EAP status, first EAP is available http://blog.jetbrains.com/webstorm/2013/05/webstorm-7-eap/
Hello again.
I installed v7 yesterday and everything seemed to be fine. Love the new variables view.
However, I cannot get Chrome to work at all this morning. WB will not connect to the Chrome extension. Also it isn't just opening a new tab everytime I run the project it's opening a new browser window! I have reinstalled the extension, restarted WB. Nothing gets it to work. It continues to work with Firefox but it still opens a new tab for each session. So nothing seems to be fixed and it's actually worse than it was before.
Please let me know if I can give you any extra information to help resolve this
Thanks
It seems JB chrome extension is not connected to the IDE. Default port number 63342, see chrome extension options (chrome://extensions/, click Options) — "IDE connection". You can set up custom port to ensure that another instance of JetBrains IDE (e.g. IntelliJ IDEA) doesn't bound to the default port (in this case WebStorm will use 63343 (+1)) — IDE settings -> Debugger -> JavaScript -> built-in server port.
OK. That's fixed being able to actually connect to the extension. It still opens a new tab on each run. But the new variables and Structure view are amazing :)
>> It still opens a new tab on each run
Fixed, please update chrome extension — 1.5 (easy way — chrome://extensions/, check Developer Mode, click Update extensions now).
Yep, that works. Thanks very much. Is the custom port thing documented somewhere? I will be asking my team to update to 7 and it's a bit of a pain.
Thanks again
I am going to write blog post about it. You can get info in the issue description – http://youtrack.jetbrains.com/issue/WEB-6998
If you can wait one day — please wait, next EAP will be tomorrow (June 14, it is not critical update, just save your time to download/install new version). Also, I have discovered another bug related to "new tab instead of existing" (if you open several debug configurations — it is rare case, but will be fixed ASAP).
Great! Thanks for the warning :)