I am not able to reproduce using the given information.

When trying I get

APPLICATION ERROR #500
File upload failed. This is likely because the filesize was larger than is currently allowed by this PHP installation.

Certainly not the best possible error message, as you get it if the file size is greater than one of 3 settings.
$t_max_file_size = (int)min( ini_get_number( 'upload_max_filesize' ), ini_get_number( 'post_max_size' ), config_get( 'max_file_size' ) );

i have tried the same in 2 environment and there is no error in validation and the comment posted.

Steps To Reproduce:

1- this my default setting for PHP and MYSQL
2- try to comment without $g_max_file_size using RAR file with size 11M and the comments posed without the attachment or an error
3- try to comment using the $g_max_file_size = 5000000; with the same RAR file with size 11M and the comments posed without the attachment or an error

Setting.png (11,826 bytes)   

Setting.png (11,826 bytes)   

Do you store attachments in database or on disk?
Do you get any error or warnings when running admin/check/index.php ?
Are there any error or warnings in web server, database or PHP logs?
Have you any 3rd party plugins installed ?
Did you change any source of Mantis?
Did you change $g_display_errors setting?

Dropzone is configured with a max-files-size setting. When a file in its queue is bigger that that, the file is silently ignored and not uploaded.
Thus, there is no error, but no attachment either.

Additionally, that configuration is weak, see 0025463 and 0025464

i think the scenario reported here is believable.

The fact that atrol reproduces the server side error, also as i have experience usually, is probably:

• config_get( 'max_file_size' ) = 5M (as mantis default)
• ini_get_number( 'upload_max_filesize' ) = 2M (as php default)

files between 2M and 5M will be fine in dropzone, but gets an error at server side.
files >5M will be ignored by dropzone, and get no error nor attachment at server side.

Thanks @cproensa 0025452:0061473 probably explains it.

Do you store attachments in database or on disk?
==> databse
Do you get any error or warnings when running admin/check/index.php ?
==>attached
Are there any error or warnings in web server, database or PHP logs?
==>no
Have you any 3rd party plugins installed ?
==>no
Did you change any source of Mantis?
==>no
Did you change $g_display_errors setting?
==>no

i'm using WAMP server and i have updated it to the new version and forget to increase all values needed in MYSQL and PHP thats why the error happen accidentally .

i think its related to tickets 0025453 as well

check.JPG (81,430 bytes)   

check.JPG (81,430 bytes)   

@titovetch I expect that this issue is fixed as the related issues have been fixed.
Can you confirm? Maybe you could try latest nightly build https://www.mantisbt.org/builds.php

Thanks @artol,i have tested the last nightly version and i found that :
1- a warning pop messages appeared after dropping the file [good]
2- message appear when the mouse passes over the dropzone element which is good but the message hide the attachment information and it could be better if we put it after remove button
3-there is a different between the warning message size and dropzone element size
4- in case the attachment exceed the $g_max_file_size ,its accept to create comment/ticket without the attachment and i see its better if we prevent the process until the user upload relevant size

all scenarios have been done on commenting and creating ticket

IMG 1.PNG (7,118 bytes)   

IMG 1.PNG (7,118 bytes)   

1.PNG (7,809 bytes)   

1.PNG (7,809 bytes)   

2.PNG (7,613 bytes)   

2.PNG (7,613 bytes)   

@titovetch
I see strange, that a file that exceeds the allowed size, which triggers the new dialog, stays enqued in the dropzone area.
The triggering of the dialog ALSO removes the file from the dropzone.
Have you cleared cached files in browser, to load the new javascripts completely?

2- message appear when the mouse passes over the dropzone element which is good but the message hide the attachment information and it could be better if we put it after remove button

That is an overlayed message, i wouldn't pay much care to the exact layout, considering thet the file should not be ther in the first place (as said before)

3-there is a different between the warning message size and dropzone element size

Probably becasue: one says MiB = (1024*1024 bytes), and the preview shows MB (1000*1000 bytes). That's one inconsistency in dropzone, i saw it commented in their project issues too.

in case the attachment exceed the $g_max_file_size ,its accept to create comment/ticket without the attachment and i see its better if we prevent the process until the user upload relevant size

Yes, that may be revised, but it's part of the server side code.
I tried the client side because it can now easily prevent most, almost all, errors caused by the file sizes, for web ui users.

the screen explains my error on my server "File is to big"

I see strange, that a file that exceeds the allowed size, which triggers the new dialog, stays enqued in the dropzone area.
The triggering of the dialog ALSO removes the file from the dropzone.
Have you cleared cached files in browser, to load the new javascripts completely?

fixed after clearing the cash

Yes, that may be revised, but it's part of the server side code.
I tried the client side because it can now easily prevent most, almost all, errors caused by the file sizes, for web ui users.

unfortunately if file exceeds the allowed size during creating /commenting an misleading error message appear, do we need to create a new ticket to prevent any action if the size exceeds?

unfortunately if file exceeds the allowed size during creating /commenting an misleading error message appear, do we need to create a new ticket to prevent any action if the size exceeds?

Note that the image you attached is an unrelated error: "invalid form security token". Probably a token timeout, but still unrelated to attachment sizes.
If by any mean, the server side receives a request with a file that exceed the allowed size, an error is displayed, but the issue is created anyways (and the file silently dropped).
This is reported here: 0003759

@titovetch
Thanks for your feedback.
I'm going to set this issue as resolved, since all the points are either resolved, or previously reported, with the related issued

i hope you solved it :-)