Created attachment 68175 [details]
Log file

This only happens when I turn "Enable client side debugging" on in the window that pops up when I start debugging. If 
I disable client side debugging, PHP debugger works fine.

Please evaluate, happens just if client side debugging is enabled according to agaace's comment. If problem in php
debugger please reassign back.

It looks like the problem is in the php debugger.  There is the following line:

DebugSession session = DebuggerManager.getDebuggerManager().getCurrentEngine().lookupFirst(null, DebugSession.class);

In the cases where multiple sessions are active (e.g. when client-side debugging is running alongside the php debugger),
the current debugger engine may not be the php debugger engine.  This code probably needs be replaced to iterate through
the currently running sessions to find the appropriate debugger engine.

Thanks for evaluation, hotfixed, somehow according quynguyen comment:
http://hg.netbeans.org/main/rev/6bce94f99463

Comment:
This my hotfix was needed because multiple sessions are running but the active one was the client side. My hotfix just
makes the php debugger to become the active one instead, which makes sense because client side debugging can't be
started until php processing on server is finished. 

Alone client/server side debugging both works now for me.
But if both debugging (client/server) are enabled, then client side debugging doesn't work for me - even if I manually
switch javascript debugger session as active (even closing php debugger session doesn't help). So, will be REASSIGNED
back to javascript debugger for next evaluation.

I tried both php/javascript debugging, and both sessions appeared to be working for me.  What exactly happens when it
doesn't work?

> What exactly happens when it doesn't work?
see picture

I would like to achieve the state when php debugging is finished and I can debug the javascript, which means have active
running javascript session, opened html generated by server in editor pane, stopped at first line, toolbars/actions like
continue, step over,.. are enabled, be able to see local variables and so on. 

Created attachment 68494 [details]
not stopped at firts line, actions like step over disabled

Integrated into 'main-golden', available in build *200808280201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/6bce94f99463
User: Radek Matous <rmatous@netbeans.org>
Log: #144937 AssertionError at org.netbeans.modules.php.dbgp.StartActionProviderImpl$ServerThread.run

Incomplete? Works for you ever? P2?

I haven't been able to reproduce this yet.  Do you have a reproducible test case?

To be clear, I ran the following scenario (on WinXP):

1) Create a PHP project and modify index.php to add a script tag in the body with some javascript code in it
2) Debug client-side and set the breakpoint in the page that comes up
3) Kill debugger session and close editor windows
4) Start debugger for both server and client
5) Debugger suspends on <?php> tag.  Hit continue.
6) Debugger suspends on <?php> tag again (why?).  Hit continue.

At this point, the javascript debugger hits the js breakpoint and suspends correctly.  Once the active session is
changed to the javascript debugger session (automatically or otherwise), the correct actions (step into/over, etc.) are
enabled.

From the screenshot, it looks like the javascript debugger is running correctly.  To verify that the breakpoint is set
correctly, look at the URL in the Breakpoints window and the URL in the Threads window.  They currently need to match
exactly (even with the query string) to work.

Once I've trapped it working according your steps from many many attempts. Steps 1-3 are probably necessary to place
breakpoints - very unintuitive I would say. Even just the client-side debugging (without php in 4/) to keep it as simple
as possible - doesn't work for me (again I have seen it working - but no clue when it works and why and when not). Now
it doesn't work for me. Even after restarting NB a few times. 

I will attach a very simple project for testing (naturally you must change the url properly on your computer) whereas
breakpoint should be placed in index.php:9.

Petr Pisl, someone from QA, please could you test, if it works for you.

While playing with it I got this exception:
http://statistics.netbeans.org/analytics/detail.do?id=57480

Created attachment 68583 [details]
project

To your question in 6) why it stops twice at the same line - I don't know, I've  seen it just once when I was lucky to
sucesfully follow your steps, never again, sorry, please evaluate if you can reproduce. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
FireBug 1.2.0
netbeans-firefox-extension 0.6

Steps 1-3 are necessary because the javascript code is executed while the page is loading (you could also refresh the
page in the browser to hit the breakpoint).  To determine if your breakpoint is set correctly, check the Breakpoints
window for the Resolved Location field.  Unless that field is populated with the correct URL, the breakpoint will not
get hit.

The reason why we can only hit breakpoints from the retrieved browser source is because there currently no way to map
line numbers from a .php file to the final source.  It is unintuitive, but we likely won't be able to resolve this issue
for NB 6.5.

1/ unintuitive in other words means that for many users it won't be easy to use it, which is a bad news - did you
consult it with someone from HIE or did you go through UI study process? 

2/  although I think I understand how I should use it - it doesn't work for me!  

1) The source problems only occur for .php/.rhtml/.jsp files; normal .html and .js files should work as expected.  FYI,
the javascript debugging feature did go through HIE and a usability study, although that is not relevant to this
discussion.  We do have plans to handle this better post-6.5, but I don't think there is even a proposed solution yet.

2) If the breakpoints aren't working, then it is a problem, but I need some way to reproduce the problem in order to
evaluate it.

Hmm, I'm not happy from this situation. What I read in this issue and also from my personal experience I have to say
that JavaScript debugger is something virtual for me, because I haven't seen it to work properly in php or ruby project yet.

Tomas, yo promised to look at it and play with it a little today. Please, could you express your experience or feeling
about it.

So, adding tomas mysik.

Well, let me summarize my experiences with JS debugger in PHP project (I just tried to debug one simple file):
1) I wasn't able to set a breakpoint - that was a big surprise for me (Radek had to tell me how to do it and it's... a 
bit tricky? a bit weird? not sure but definitely neither simple nor intuitive) - this completely differs from other NB 
debuggers (I understand that JS is client side, but still... maybe I just missed some help or wiki page).
2) Breakpoints don't move after code changes - I know that it's client side and maybe impossible but - it is the most 
common thing in any IDE to change sources...
3) I would like to ask - what are the advantages of NB JS debugger over just Firebug? I know Firebug quite well and I 
have to say that it works fine for me and I can hardly imagine that I would switch to NB JS debugger, I'm sorry (try 
to compare setting a breakpoint in Firebug and NB).
4) When I tried to use it together with PHP debugger, all the JS breakpoints were ignored (so no JS debugging at all).

My feeling is that we could/should improve user experience - e.g. we could stop at the first line of JS code as we do 
in PHP debugger, that would help a lot with problems 1) and 2).

Please, keep in mind that I have tried it for the first time and that I can miss something or can be wrong at all.
Thanks.

I have played with the js debugger for a few minutes. It's much better than it was a few weeks ago, but still there some
issues. 

1) The js debugger session is not active, when the breakpoint in js file is hit. 
2) Very often i was not able to finish the JS debugger session.
3) It stops to work at the moment, when I opened new tab in the started FF. 
4) When I finished the JS debugger session, it also close the FF with all opened tabs. So how it's covered usecase, that
I want to continue in the application without debugging.
5) It works for me only a while. Then I wasn't able to stop in a js file.
6) I put a breakpoing to the javascript, but then I wasn't able to remove it. The reason again is that the breakpoint is
in javascript but tha active session is the server side. 
7) When I hit a reload button in browser, then the execution is stopped on the server side, but not in the javascript. 
8) When you start to debug, then new window of FF is open, but it's not bought to the front. It's usually opened behind
the last opened window.
9) When I want to exit from the IDE, the IDE inform me that there is running php session, but don't talk about JS
session nothing
10) If I change the js script in my PHP file, then it's not reflected in the generated html sources. I had to stop and
start the JS session again. 
11) It allows me run many JS debugger sessions at once. This can be very danger.
......

I can continue in the list of problems. From my point of view this is not very tested area. 

Two more annoying things. I often got exception:
org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:253)
	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283)
	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:124)
	at org.netbeans.modules.web.client.tools.common.dbgp.Message.getNode(Message.java:334)
	at org.netbeans.modules.web.client.tools.common.dbgp.Message.create(Message.java:130)
[catch] at org.netbeans.modules.web.client.tools.common.dbgp.DebuggerProxy$MessageHandler.run(DebuggerProxy.java:388)

Next thing which is not good and IMHO has to be changed, is that in html the javascript has green background. This mean
that it's hard to recognized the line with breakpoint on LCDs. See the attached screenshot.

Created attachment 68638 [details]
The screenshot breakpoint in the javascript.

Thanks for the testing and comments.  Responses below to the major issues raised:

1) Breakpoints not getting hit when also debugging php - Likely this is due to the query string added by the php
debugger; we can definitely handle this situation better

2) Suspending on the first line of js code - This is not turned on by default, but that can be changed.

3) Changing active session to javascript when suspending on js code - I agree this should be done for now, but multiple
session management support needs to be better in the future.  I think the problem is similar to the multi-thread
problems in Java debugging that were improved in 6.5.

4) Browser issues - JS debugging is only enabled for the tab that it is launched in, so if you open a second tab, it
will not be active in that window.  The original window should still continue debugging.  Regarding the window closing
after the session is killed, I don't know why that was implemented.

5) Sources for R/O files from browser not up-to-date - Should be fixed, but not sure what it would entail.

6) Breakpoints not removed/exceptions/sessions not killed, etc. - General stability is still being looked at.

7) Green breakpoint on green background - True, will investigate what can be done about it.

Things that have been fixed (for some reason, the changesets didn't get auto-posted from qa@netbeans.org):
- js debugger session becomes active session when breakpoint is hit
- breakpoint setting/removing works when js debugger is not active session
- SAXException on message parsing, which would likely cause some of the issues with the debugger not working after a while

-have reproduced the not being able to kill session; produced thread dumps for Quy - bug to be filed tomorrow
-ConcurrentModificationException  #145748, has been fixed.
-as mentioned by Quy SAXexception #132805 has been fixed.

The initially reported problems with multiple sessions have been addressed.  Since the remaining problems have already
been filed as different issues, I will close this as FIXED if there are no objections.

Resolved as FIXED.