I just sent mail to the help list - before I saw this. I am also getting it repeatedly with 1.1.4, but not everytime.

FYI - update - 11/3/08: I saw some other comments about clearing the cache etc. That does usually work for me. I am running my application on Solaris 8, with apache 2.0.59, and using IE6 - in case a combination of the items matters. Also note that my Solaris 9 test system (also 2.0.59 apache, IE7) does not produce the error so far.

Same problem is happening to me on 1.1.4. But it seems to be more consistent at the moment (note that I first didn't have any problem).
When in project A I cannot report new bugs. However, when I go to project B, everything seems ok, until I want to submit a bug for project B. It seems that it jumps back to project A (with also the same #2800 problem).
If I select some other page again (view issues, my view, ...), it jumps back to project B.

So far I haven't been able to get it working again. Logging out & in doesn't seem to work either. (all in FF3)
When switching to IE7, I can submit a bug report as before.

Update: Now doesn't work for IE7 anymore as well

We have the same problem with IE6.

Can you try clearing your browser's cache, history, and cookies, and then see if it happens again after that?

After the application error occured, I have re-opened the browser, cleared the cache and tried again, but I got the same application error again.

Also make sure you are not setting $g_allow_browser_cache in your config_inc.php; it should always remain unset.

I've confirmed that IE6 is having this issue because, for unknown reasons, it's not properly pulling getting new pages from the server.

However, I cannot replicate the issue with any other browser, including Firefox 3, Opera, and IE7; hence my comment above to make sure that you do not have $g_allow_browser_cache set in your configuration.

It doesn't work, sorry. Still the same problem. If I rollback to version 1.1.1 everything works fine.

Hi,

Personnaly, I cannot reproduce the error. But some of my clients and some of my co-workers can :/

Seems that we cannot reproduce the issue under Linux or MacOS (with Firefox), but under windows it has been rapported for FF(3 at least, maybe 2)/IE6/IE7 on differents computers and network (some behind proxies, some not).

I've checked, the $g_allow_browser_cache directive is not set in the config.inc.php. I'll tell ones who gets the problem to clean their browsers data, but I cannot control that unfortunately.

We are behind a proxy.

Hi , I have the same problem in version 1.1.4 impossible to submit two bugs one after the other at the second one I have APPLICATION ERROR #2800 it makes using bugtracker very difficult

We have the same issue as noted above. Holding control down to do a full refresh of the page does allow a second bug to be submitted for our users. When requesting the bug submit page, a 302 not modified header is being sent back to the client which is why the same id is be passed back.

Thanks that workaround solved the problem. Is threre a patch to correct this problem ? it's stays boring to use

MIB - Most important bug

Some clients can't submit issues.

Any ideas as how to fix it before a patch?

/Frans

I did not find any solution actually, clients wants to report bugs, if our mantis does not work as excpeted, they send us emails :-/

I'm open to test solution mantis team should propose, but my users are not... If it works, it's cool, if it does not, they'll find another way, unfortunately.

Same happens in the 'lost password'-process: If you try to submit the form with the new password the same error (APPLICATION ERROR #2800) occurs.
Hope that info helps you to narrow down the problem.

Same error here, we checked with Firefox 2 and IE 7.

I have tried adding this line to the config file: (is it ok??)

$g_allow_browser_cache = "always";

Hope it works, I will post here a feedback as soon as I get news.

/Aurelio

found a workaround for this cahotic cache problem waiting for a better solution...

I modified string_get_bug_page function in core/string_api.php to force browser to reload the page.

function string_get_bug_page( $p_action, $p_user_id=null ) {
if ( null === $p_user_id ) {
if ( auth_is_user_authenticated() ) {
$p_user_id = auth_get_current_user_id();
}
}

    $g_show_action = config_get( 'show_' . $p_action );
    $t_string = sha1( time() . mt_rand() );
    switch ( $g_show_action ) {
            case BOTH:
                            if ( ( null !== $p_user_id ) &&
                                     ( ON == user_pref_get_pref( $p_user_id, 'advanced_' . $p_action ) ) ) {
                                    return 'bug_' . $p_action . '_advanced_page.php?id='.$t_string;
                            } else {
                                    return 'bug_' . $p_action . '_page.php?id='.$t_string;
                            }
            case SIMPLE_ONLY:
                            return 'bug_' . $p_action . '_page.php?id='.$t_string;
            case ADVANCED_ONLY:
                            return 'bug_' . $p_action . '_advanced_page.php?id='.$t_string;
    }

}

thanks that works nice very useful

Note : I can't read bugs anymore or correct them i go back without this change.
maybe another time

With this function I can see bugs and modify them

function string_get_bug_page( $p_action, $p_user_id=null ) {
if ( null === $p_user_id ) {
if ( auth_is_user_authenticated() ) {
$p_user_id = auth_get_current_user_id();
}
}
$g_show_action = configget( 'show' . $p_action );
if ( $p_action == "report" ) {
$t_string = "?jt=" . sha1( time() . mt_rand() );
}
switch ( $g_show_action ) {
case BOTH:
if ( ( null !== $p_user_id ) &&
( ON == user_pref_get_pref( $p_userid, 'advanced' . $paction ) ) ) {
return 'bug' . $p_action . '_advanced_page.php'.$tstring;
} else {
return 'bug' . $p_action . '_page.php'.$t_string;
}
case SIMPLEONLY:
return 'bug' . $p_action . '_page.php'.$t_string;
case ADVANCEDONLY:
return 'bug' . $p_action . '_advanced_page.php'.$t_string;
}
}

Thanks Mederic.

It seems it's working now, but I can not order by diferent concepts in "View Issues" screen. I mean it's not possible to order by clicking on the following columns: P, ID, Category, Severity and so on...

Edited: anyway if this change is stable then you can use "advanced search" for ordering results.

Hi, I had the same bug.
It's provoked when a user of an old version (in my case 1.0.6) uses the 1.1.4 version without having clean the internet cache. Once clean it, the bug did not appear any more.

may be it will be usefull for developers and users:
i've found that if you add bug when chosen project is "All projects", you can add it and error doesn't appears...

I am doing a POC with 1.1.4 in a virtual machine (VPC 2007), Windows 2000, IE 6 and SQL Server 2000.

Everythig was good, but suddenly I can't report an issue anymore. No error messages, I choose the project, the browser blinks and nothing happens. I commented out the line $g_allow_browse_cache = 1 in file bug_report_page.php and now it works again.

Hope it helps.

I am running on Mantis 1.1.4, and I can reproduce all the time. Using FF3 on both PC and MAC.

jreese if you like, I can pass you my server so you can see the behavior.

I just had it happen to me on this tracker, with FF2. I think the key was that I started submitting a bug, then got distracted, and finally submitted the form much later (maybe an hour after I loaded the form). I hit Back (got back the form with all the fields filled in), tried to submit again, and got the error again. Going back, copying the fields out, refreshing the form (clearing all the fields), pasting the fields in, and submitting worked. I think the delay between loading the form and submitting it is the key because it happened once in exactly the same way on my own tracker with 1.2.0a2 (trunk r5751).

Edit: obviously a different problem, 0009814 submitted.

I've had a user report this as well, but none of our staff has ever had it occur, and I cannot reproduce it.

For the time being, this has been resolved by preventing Internet Explorer from caching pages. This will fix the problem with being unable to report multiple issues in a row, but will unfortunately prevent IE from saving what was typed into the form if you make a mistake and need to use the back button (a partial regression of issue 0009323).

We've discussed this on the mailing list, and as there is no better solution except to rewrite a lot of pages to not rely on the browser in the case of errors, we feel it's the best option we can currently take.

The fix has been committed to both the 1.2.x and 1.1.5 development trees.

could you please give direct link to new distributive of 1.1.5 ?
Why this bug fix does not added to 1.1.4 distrib?

In note 0019750 you say that $g_allow_browser_cache shall not be set, however it is used in bug_report_page.php and bug_report_advanced_page.php - it is set to 1.
As many users reported getting this error (app.err. #2800) while trying to submit a bug, is it correct to have it set? What is the purpose?

I tried the proposed change for 1.1.5 and nothing changed (I have the same issue as many others already reported). Reading the changes I have the impression that the correction is not appropriate: too many lines commented out, than IE case handled with "default" case, meaning caching.

I am using the software for the first time v 1.14
Creating a new user
Once the link is clicked in the email http://www.xxxx.com/mantis/verify.php?id=4&confirm_hash=908e48cb27498dedbafad2e8135df5ed

The page loads with
SYSTEM WARNING: session_destroy() [function.session-destroy]: Trying to destroy uninitialized session

SYSTEM WARNING: Cannot modify header information - headers already sent by (output started at /home/xxxxx/public_html/mantis/core/error_api.php:166)

When I update the password I get the following when I submit the form.

APPLICATION ERROR #2800

Invalid form security token. Did you submit the form twice by accident?

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

##########################
I am also getting this APPLICATION ERROR #2800 for updating bugs in both simple report and advanced report.

This seems like a critical bug as one can not use the application. Is it possible to use the development release on an existing database as this version is useless as it is. The issue occurs on Firefox and IE the latest versions. Thanks.

I get the same situation as dplinnane.
It's really critical issue.
The issue occurs on Firefox 3 and IE 6.

ps. I try the way of dplinnane but no effect.

This error is not resolved. I applied the patch and the behavior still persists. The second bug-report after clearing the cache won't be accepted.