Can confirm here, Mantis 1.1.1, Firefox 2.0.0.12.

I guess either the fix for 0007999 didn't work or this bug (0008501) is not a dupe.

Yes, I can second (third?) this formantis version 1.1.2

in core/print_api.php

line 1725 or near

change

$t_nbsp = chr(160);
$t_name = addslashes( str_repeat( $t_nbsp , $t_level ) . str_repeat( '»', $t_level ) . ' ' . project_get_field( $t_id, 'name' ) );

to

$t_nbsp = ' ';
$t_name = addslashes( str_repeat( $t_nbsp , $t_level ) . str_repeat('»', $t_level ) . ' ' . project_get_field( $t_id, 'name' ) );

edited to avoid mantis incorrectly displaying the wrong code

I've had the same problem in Mantis 1.1.2. The reason for this is that the characters in the extended dropdown go through Javascript before getting printed. This is why the progonal code (either using PHP's chr() or &\nbsp) don't work.

I've gotten it to work by replacing the characters with their unicode equivalents and removing the addslashes call, making the line as follows:

line 599 print_api.php

$t_name = str_repeat( '\ u00A0' , $t_level ) . str_repeat( '\ u00BB', $t_level ) . ' ' . project_get_field( $t_id, 'name' ) ;

Remove the spaces after the slashes.

This is present in 1.1.6...I have looked to apply 'michield'(0018163) fix but the closest I can find to his code reference in print_api.pjp is at line 597/598 and is

$t_nbsp = chr( 160 );
$t_name = addslashes( str_repeat( $t_nbsp , $t_level ) . str_repeat( '»', $t_level ) . ' ' . project_get_field( $t_id, 'name' ) );

which is subtly different to what he said i should expect.

On the other hand 'svenito'(0020660) fix appears to have worked...

Also seen on 1.1.8 under Firefox 3.6

Seen ??»[subproject] under drop down menu for all sub projects
(without the between &_raquo)

The fix from 'svenito'(0020660) works well

I am not able to reproduce this with latest stable release (1.2.19).

In upcoming 1.3.x, the extended browser option has been obsoleted.