Suddenly it's broken for me as well, as well as several other users. So now a significant number of users can't use mantis. It still seems to work from Mozilla for everybody, but I'd really like to figure out what's going on.

Versions of Internet Explorer that fail:
6.0.2800.1106.xpsp2.030422-1633
6.0.2800.1106

older (NT4) version of IE that works:
6.0.2600.0000

As more people log on, I'm finding that most IE users on Windows 2000 OR XP are unable to use the "view bugs" page under most projects. The few projects that do come up ok are defunct projects that only have less than 20 bugs entered. All large active projects (100+ bugs) hang when loading the page.

I created a brand new test user and reproduced the problem immediately, so it doesn't seem to be any weird junk left in the user tables from previous versions.

I found a really interesting quirk: when this bug happens, clicking on links (either the "View Bugs" link at the top or the numbered page links on the right side) always fails. But copying the URL, then pasting in into the address bar at top, always works.

Seems like this should point out exactly what the problem is, but I'm still clueless. Remember, it's only a problem with view_all_bug_page.php. All other mantis pages always display fine.

A big discovery: turning off HTTP 1.1 in IE seems to make the problem go away. (Tools->Internet Options->Advanced->HTTP 1.1 settings->Use HTTP 1.1)

I don't view this as a fix, because I don't want to have to tell every new user to fiddle with their settings just to access mantis.

So the best description of this bug I can come up with so far is:

IE using HTTP 1.1 hangs when clicking on links to view_all_bug_page.php

I've tried using the apache settings "nokeepalive force-response-1.0 downgrade-1.0" and these don't seem to help at all. Things are still broken for most IE users.

FYI, I'm running redhat 7.2, apache-1.3.27-2.7.2, php-4.1.2-7.2.6.

Just as a test, I tried copying my mantis installation over to a second machine running redhat 8.0, (apache) httpd-2.0.40-11.5, and php-4.2.2-8.0.8.

No difference. IE clients still hang, but only on view_all_bug_page.php, and only when clicking links (as opposed to pasting URLS), and not when HTTP/1.1 is disabled in the browser. Oh, and all of this stuff was running fine for the last year and a half until I upgraded to 0.18.0.

I'm just about running out of ideas.

Found the best workaround so far:

$g_compress_html = OFF;

seems to make the problem go away. So it's somehow related to the gzip encoded pages that 0.18.0 can generate (note that 0.17.5 didn't do this so that's why my setup broke with 0.18.0).

Is it a bug with IE? PHP? Mantis? no idea.

I watched some network traces and found out that what was really happening is that the entire http transaction was completed; all the data was sent to the browser (I think...it's a bug lump of compressed data). So it looks to me like the browser receives the whole page, then chokes on the compressed data. It spins the flag icon like it's still waiting for the page to load but that's misleading; the page has been delivered and the browser's simply choking on it.

I can see in new traces that it's delivering ASCII data now, and everything's fine.

As a final note, there are a few web pages referring to bugs in IE regarding gzip encoding, for example this one:

   http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496

However, the pages I've seen are all bugs fixed about two years ago, and in theory shouldn't be present in the patched-up-to-date versions of IE I'm seeing problems with. Is it this old bug, never actually fixed? Or something new? I have no idea.

As a tweak I set the default $g_default_limit_view to a smaller value that 50 (e.g. 20).

How I get this idea. I load view_all_bug_page.php on a project where it works and after that I switch to the trouble project.
When loading I press stop of the browser and edit the Show value to 20 in the filter table.
After Apply Filter everything works fine with the project.

I'm having similar issue with Internet Explorer users. My Mantis version is 0.18.3. And it fails with the 6.0.2800.1106 versions of internet explorer.

When switching betwen View All Bugs and Main Page, the browser remains blank, and the location does not change in the location bar.

I tried all you comented here: Disabling HTTP 1.1 on the browser, setting $g_default_limit_view = 20 or 25, and setting $g_compress_html = OFF

The problem remains in all cases.

When the user gets the blank page, if you hit the reload button, the page is displayed correctly, but the location bar remains with the old address.

With Mozilla, FireFox or other browsers run with no problems.

is anyone able to see if the latest CVS version still has this issue, and confirm that it is still an issue.

There's been no feedback on this issue. This issue could also be related to the following:
"
I'm pretty confident that this is due to mantis passing long url's about for filters.

This seems to cause issues with different browsers / Servers / Firewalls, as the length of the meta-refresh/location header or URL exceeds the limit that is expected.

As it's likely that to fix this issue reliably, we'll need to store the filter data in the database temporarily, this is being resolved as a duplicate of 0004609.
"