I am not able to reproduce the issue.
I get just the 805 error message, but not the 1200 message.
After that the system stops with message: "Please use the "Back" button ...."

Did you change sourcecode of MantisBT and/or installed any plugins?

No. Except for the phpmailer bugfix which I have reported before, I have tested it on the latest 1.2.4 which I have just installed into an empty directory only copying the config_inc.php from 1.2.3. No modifications or plugins or whatsoever.

Make a backup of file core/user_api.php and temporary add the following line after line 292 of file core/user_api.php
var_dump ( $p_username ); die();

I press the Signup button and it shows:

string(0) ""

Nothing else.

Did you change any error handling related settings?
For example: $g_display_errors

Yes:

$g_show_detailed_errors = ON;

    $g_display_errors = array(
            E_WARNING => 'inline',
            E_NOTICE => 'inline',
            E_USER_ERROR => 'inline',
            E_USER_WARNING => 'inline',
            E_USER_NOTICE => 'inline'
    );

Your settings are just for debugging purposes.
Have a look at the warnings in config_defaults_inc.php for the settings you made.

Please comment your settings in config_inc.php and check if this fixes your issue

O.K. That does it. I had those settings (or similar) for a long time. I have always thought they would only adjust how or where PHP errors are displayed, like the PHP display_errors ini option.

Maybe the labeling in MantisBT could be different from what you would know and expect if you knew display_errors in PHP.

Or I think at least a message "Ignoring error, continuing because E_USER_ERROR is set to 'inline'..." would help to understand better what's happening...

You wrote: "Maybe the labeling in MantisBT could be different from what you would know and expect if you knew display_errors in PHP."
If you know display_errors in PHP you can't think that this is similiar to g_display_errors of MantisBT. diplay_errors of PHP is just a string setting (boolean in earlier version) whereas g_display_errors of MantisBT is an array.
Changing E_USER_ERROR => 'halt' to E_USER_ERROR => 'inline' is something where you have to know what you do.

I agree the name is unnecessary confusion, but this name was introduced many years ago.

I think an enhanced message for E_USER_ERROR is a good idea.
Or even E_USER_ERROR should not be changeable.

I guess the "confusion" can't be changed anymore.

An enhanced message telling what happens would help to understand it.

The documentation in the default config could be more extensive on this point, too. In particular, because the "inline" setting probably could have security implications which noone really knows when the code continues at a place where it supposed to stop under normal circumstances.

Maybe even a warning message similar to the one warning about the existence of the admin/install directory would be a good idea. A normal mantis installation should not run with this setting. It should be really reserved for debugging purposes and if it is enabled it should be clearly visible.

E_USER_ERROR is always meant to be a fatal error. Using anything other than 'halt' is bad here because you're basically circumventing security errors (access denied), etc.

I think it may be best to update the new check script in MantisBT 1.3.x to check if the user has configured $g_display_errors in an undesirable way.

I have very similar problem: It's possible to signup to a mantisbt account without enter any username and e-mail address, i.e. leaving both fields empty, but the difference is that after pressing the "Signup" button any error messages don't appear on the next page only success message and I didn't change $g_display_errors settings so mentioned fix do not useful for me, could you advise something please?

Problem solved, errors didn't appear because of error_reporting settings set to 0

Assigned to David according 0012632:0027840

Thanks atrol.

Not-yet-concrete thoughts for the 1.3.x branch:

$g_display_errors won't exist in 1.3.x because every error is 'fatal' unless they are caught and handled by the code.

It should also be quite safe to override PHPs built-in error reporting sensitivity for MantisBT so that it triggers a fatal error for all unexpected errors. There is nothing to be gained by having this set as a user-adjustable setting.

Saying this - there could quite easily be new error options in 1.3.x if the need arises.

Removed assignment. dhx will not contribute to this issue in near future.

dhx's comments in 0012632:0027840 have been addressed in my local 13x branch, which I'll push to github shortly, by displaying a warning on the login page, as well as in the admin checks.

Same goes for vogt's 0012632:0027734 (regarding an additional warning when displaying E_USER_ERROR inline).