This works just fine for me. Can you try the latest version with SVN, and if it doesn't work provide the engine and xdebug sections (only) of phpinfo() output?

I'll try it later today.

Maybe the problem with POST requests is that it was originally a GET request and TamperData just added the POST parameter (or maybe not, I'm not sure if it's allowed by the HTTP RFCs to add POST data to a GET request - and what Apache and PHP do in such a case). Unfortunately my C knowledge is by far not deep enough to understand the source of XDebug at that point. Neither is my knowledge of debugging such problems, so I could not track it down myself.

Ah. I'm sorry - I've found the error. I use the Firefox extension CookiePie for developing on my TYPO3 websites, so I can have multiple tabs with the same site, but with different logins. The problem is that CookiePie does not send the XDEBUG_PROFILE cookie, though Easy XDebug showed profiling as enabled in the bottom right corner...

The other problem I mentioned (HTTP POST data not read with GET requests) still persists, but I bet that it gets lost somewhere in Apache or PHP, so there might be nothing XDebug can do about that.

All in all, I think this bug can be closed - I'm sorry for the inconvenience caused. Just another thing: XDebug's tests in trunk threw some errors, which I have posted to qa.php.net - if you want to do something about that and need a tester, don't hesitate to contact me. And keep up the good work with XDebug! :)

One final note: Maybe it would be worth adding a note to the docs that people should be careful with any browser extensions that fiddle around with cookies and request data. Maybe a short PHP test script that displays all data it got and whether XDebug was enabled for that request or not would be a great help in such situations.

Alright, closing then. I know there are some test failures, and will be looking at them.