see also bug 0006733, it's similar

The first hit on Google for "error 1072896658" is...

http://www.panoramio.com/blog/explorer-system-error-1072896658/

...which suggests it could be due to an incorrect (or missing?) charset parameter on the Content-Type header in the XmlHttpRequest response. I'll check that in Mantis.

In the mean time, you don't have to turn JavaScript off entirely; you can just turn off the fancy XmlHttpRequest code by putting...

$g_dhtml_filters = OFF;

...in your config file.

My initial reaction to this bug report was that NT4 is really old and that maybe its version of IE doesn't support XmlHttpRequest, or maybe supports it only badly. What version(s) of IE did you test on NT4?

The Mantis 1.0.1 source code does appear to properly send the Content-Type header with the right charset. So now I need to ask some more questions:

• Which menus are you clicking on that cause the problem in IE on NT4?
• What interface language are you using, and in what character encoding?
• When you view these menus in IE on XP, or in Firefox, do (or should) any entries contain any non-ASCII characters, especially any characters that cannot be represented in the above character encoding? What are the characters?
• What about trying a menu that doesn't contain any non-ASCII characters, like maybe Product Build or Product Version (depending of course on how you set up those fields)? Does that work in IE on NT4? If so, we know we're on the right track with the character encoding problem; but if that also fails to work, then we may need to look for a different culprit.

Hello, sorry for delay, TZ + sunday + experience.

Yes, it's a string problem.

NT4 + SP6 + IE 5.50.4522.1800 (sp1) --> bad
NT4 + SP6 + IE 6.0.2800.1106 (sp1) --> bad
XP + SP1 + IE 6.0.2900.xpxp.sp2.gdr.050301.1519 --> correct

• Which menus ?
  Any filters of view_all_set.php

• What interface language are you using, and in what character encoding?
  I set IE for fr, en, en-us. I have no choice for fr-fr

• When you view (I'm no sure to understand this sentence ..)
  Absolutly no pb with FF or XP+IE (Where are defined char encod ? IE or Apache2 ? If it's in IE, i don't know how to search char encod) The specific char are Latin Char like "é é, à à, ê ê ï ï"

• What about trying a menu
  like other menu !

experiences:
config_inc.php = auto or french or english prefs = english --> correct
config_inc.php = auto or french or english prefs = french or french_canadian -->bad

i edit english_strings.txt, and i rename it french_strings.txt
$g_default_language = 'auto';
and user prefs set to "french"
i modify $s_reporter (Reporter), $s_priority_enum_string, $s_severity by changing "e" by "é", or by "é or by "&é" and other strings found in filter's screen, and i cannot reproduce the problem !

I meant: what Mantis interface language are you using, and what is that Mantis interface language's charset? So you see the problem using French or French Canadian (which, if you look at the $s_charset variable at the top of the correspending file in the lang directory, use the iso-8859-15 charset) but not with English (which is set to windows-1252 but which actually uses no characters outside the ASCII charset.)

I'll see if I can find a machine with something like NT4 on it and see if I can reproduce the problem when using a French language file.

Hello all,

I also have this bug with XP sp2, ie 6.00.2900.2180.xpsp_sp2, on server side: CentOS 4.4, php 4.3.9-3.18 and mantis 1.0.5.
My charset is cp1252 (because it behaves differently from windows-1252 with hungarian accented characters, and iso-8859-15 also not working with all of them).

taking the latest dynamic_filters.js will do the trick

Hello All,

As far as i'm aware this issue has long been fixed.

If you can produce this in 1.0.8 or 1.1.0rc or greater, please submit a new bug or reopen, but I think this can be closed.

Paul