0003729: When using the browser's back button, the form is cleared out.

(0005893)
lauploix (reporter)
2004-07-07 08:16

In some cases, when copying strings from another software (ie word), the bug cannot be submitted even if every field is filled.

When clicking back, the forms are blank.

(0005895)
vboctor (administrator)
2004-07-07 09:57

The reason why you get the error is that there is a documented bug in Internet Explorer. We have implemented a workaround for this bug in 0.19.0a1. The bug is triggered when you copy from Microsoft Word and paste into a web form. This is due to a problem in handling the unicode characters.

Can you please test this on 0.19.0a1? Note that the back button is a different issue.

(0005910)
lauploix (reporter)
2004-07-08 02:54

Ok. Next time I encounter the problem, I document it more clearly and test it against the new version of Mantis.

(0005929)
Chaotik (reporter)
2004-07-08 08:11

I will try with 0.19.0a1

This being said, I get the problem even when manually typing in the textareas, not just when copying and pasting. This makes it even more frustrating since you can just paste your text again. You have to retype the whole thing.

(0007847)
mfroman (reporter)
2004-09-30 10:36

This problem seems to be solved when using 0.19.0 (the official Mantis site bug tracker) entering normal text strings. That would also seem to mean that whatever fixed it in 0.19.0 could be patched into 0.18.x for users who can't upgrade to 0.19.0 yet (possibly reopening bug 0003626 which says that it couldn't be fixed).

(0007904)
TomR (reporter)
2004-10-05 07:18

In IE6.0 the problem still exists with me.

What exactly is the workaround implemented?

I only tested with a small example, report an issue, forget Description. When use Back Button the whole form is cleared. ( By the way, this is for us an shwostopper to use required custom fields ).

(0007914)
leftlink (reporter)
2004-10-05 12:18

This is the same issue as 0004520. It should be merged with that issue. I am noticing this behavior still, using IE6. Yes, it is not an issue with Firefox.

Does Mantis have a function to merge two bugs?

(0008109)
packeteer (reporter)
2004-10-19 23:18
edited on: 2004-10-20 02:47

Confirm issue exists using WindowsXP with IE 6.

Bug does not exist with Firefox 1.0PR

bug occurs with report issue page and not update issue page

edited on: 10-20-04 02:47

(0008120)
vboctor (administrator)
2004-10-20 08:28

I marked 0004520 as a duplicate of this one. However, when handling this issue, we should look at the notes of both issues. Also marked this as confirmed since it was confirmed by several users.

(0008336)
Sire (reporter)
2004-11-15 02:47

Issue 4699 also deals with the unicode problem. (Duplicate?)

(0008342)
leftlink (reporter)
2004-11-15 19:30

I just want to confirm that contrary to what "mfroman" said, the issue
still existed in 0.19.0, which is what we have installed. In our case we
added a custom field called "windows version". If you want to see the problem in action, go to organizenow.net/mantis and login as "test", "test" and then
enter an issue, leaving "windows version" blank. Try to submit it, then press the back button.

This has nothing to do with unicode or copying from microsoft word... this is a problem typing basic text in english.

(0008343)
Sire (reporter)
2004-11-16 01:19

Agreed. This is two bugs in one:

lauploix wrote:
"[bug 1: ] In some cases, when copying strings from another software (ie word), the bug cannot be submitted even if every field is filled.

[bug 2: ] When clicking back, the forms are blank. "

(0008344)
Sire (reporter)
2004-11-16 01:19

Agreed. This is two bugs in one:

lauploix wrote:
"[bug 1: ] In some cases, when copying strings from another software (ie word), the bug cannot be submitted even if every field is filled.

[bug 2: ] When clicking back, the forms are blank. "

(0008427)
gtomlin (reporter)
2004-11-25 09:22

Some observations based on my experiences/tests:

1. This is _not_ strictly an IE problem. I am having this problem with Mantis 0.19.0 and Firefox 1.0 on Win XP. I also recreated it on IE 6, Netscape 7.1 and Firebird 0.6.1. However it did not happen on Opera 6.04.

2. The problem occurs whether the data is missing from a standard field such as Summary or from a custom field that has been marked required.

3. On update, when a required field is cleared, after the back button is pressed the record is redisplayed with its pre-update values. The problem exists on both report and update.

Since different people are seeing/not seeing the problem with the same browsers, it might be browser options that are causing the problem.

(0008842)
leftlink (reporter)
2005-01-04 20:44

I just wanted to confirm that with 0.19.1, with the summary field not filled out, and the default settings for Firefox 1.0, this issue still exists.

It is really a pain. If there is no way to make the back button work, there needs to be another "back" button added to the user interface. That will go "forward" to the previous page.

We wanted to release our bug tracker to end users but with this still a problem we need to delay it. What would it take to fix this? maybe we could get some folks to donate $$.

(0008865)
malaussena (reporter)
2005-01-06 10:21

Confirmed with 0.19.2, IE6 on Windows XP

(0008948)
kasparloog (reporter)
2005-01-11 16:45

A suggestion. This can be related to the no-cache headers.

If you hit Back, then the browser reloads the page as it might have been changed.

Can anyone try modifying the meta-tags and remove the cache temporarily?

(0008966)
empty (reporter)
2005-01-12 00:57

I just added

$g_bypass_headers = ON;

in the config_inc.php

This solves the problem for us. I haven't noticed other problems with this configuration 'til now.

(0008967)
leftlink (reporter)
2005-01-12 08:36

I will try this workaround later... can others do the same and report what version of the browser it works with?

Also, the "severity" of this bug should not be "minor". This is at least a major bug IMHO.

(0009000)
kasparloog (reporter)
2005-01-13 09:39

I can confirm the bug with Firefox 1.0, Windows XP SP2.

$g_bypass_headers = ON; removes the problem. I think that this should be removed only on certain pages, where having the most recent database data is not needed. Like bug_report_page.php

(0010069)
BoGusman (reporter)
2005-05-10 14:42
edited on: 2005-05-10 14:44

Win XP/SP2, mantis 0.19.2, Firefox 1.0.3, $g_bypass_headers = ON; did not solve the problem for me.

(0010076)
Sire (reporter)
2005-05-11 03:25

This definitely has to do with all the no-cache tags and headers. They need to be removed for those (and only those) pages that:
- Often will be revisited with the back button because of missing or wrong entered information (like the bug report pages).
- Does not, or very seldom suffers from having cache.

Remember, very strange and annoying things can happen in a web app when using the default cache on pages, so the Mantis team has a good reason to force pages into not using it. However, the annoyance the users feel when having to write a huge bug report from scratch AGAIN just because they forgot some small required field invalidates any arguments of keeping the no-cache on these pages.

Suggestion for next version: hard-code some pages (just the bug report pages?) to use the default caching.

Suggestion for later versions: add an option on every page to use cache or not, or make a list in the config file.

Thanks!

(0010118)
lauploix (reporter)
2005-05-13 06:31

A simpler correction would be to add a "back" link in the error page, so that when you click on it, it goes (forward) back to the page you were filling, with values entered.

(0010119)
ryandesign (reporter)
2005-05-13 06:47

And a better solution would be to not show a separate error page at all, but rather to already land back on the form page again, with the previously-entered values filled in, with the error message shown at the top of the form, like every other modern web application does...

(0010120)
Sire (reporter)
2005-05-13 07:08

Ryandesign, agreed!

(0010167)
hgaland (reporter)
2005-05-18 13:36

I also have the problem with IE6 sp2 on WinXP, for both bug report and bug update pages.

I implemented the workaround in config_inc.php ($g_bypass_headers = ON;) and it is working.

Can anyone explain me the possible side effects of this workaround ?

Thanks

(0010170)
thraxisp (manager)
2005-05-18 20:40

Setting $g_bypass_headers was intended to disable headers when running core/checkin.php from a command line. It disables some, but not all of the headers sent for each page.

We should consider the integrated error message for a future release.

Fix submitted to CVS to allow browser caching through the $g_allow_browser_cache variable.

bug_report_advanced_page.php -> 1.49
bug_report_page.php -> 1.52
config_defaults_inc.php -> 1.264
core.php -> 1.42
file_download.php -> 1.36
meta_inc.php -> 1.18

Notes
(0005893) lauploix (reporter) 2004-07-07 08:16	In some cases, when copying strings from another software (ie word), the bug cannot be submitted even if every field is filled. When clicking back, the forms are blank.

(0005895) vboctor (administrator) 2004-07-07 09:57	The reason why you get the error is that there is a documented bug in Internet Explorer. We have implemented a workaround for this bug in 0.19.0a1. The bug is triggered when you copy from Microsoft Word and paste into a web form. This is due to a problem in handling the unicode characters. Can you please test this on 0.19.0a1? Note that the back button is a different issue.

(0005910) lauploix (reporter) 2004-07-08 02:54	Ok. Next time I encounter the problem, I document it more clearly and test it against the new version of Mantis.

(0005929) Chaotik (reporter) 2004-07-08 08:11	I will try with 0.19.0a1 This being said, I get the problem even when manually typing in the textareas, not just when copying and pasting. This makes it even more frustrating since you can just paste your text again. You have to retype the whole thing.

(0007847) mfroman (reporter) 2004-09-30 10:36	This problem seems to be solved when using 0.19.0 (the official Mantis site bug tracker) entering normal text strings. That would also seem to mean that whatever fixed it in 0.19.0 could be patched into 0.18.x for users who can't upgrade to 0.19.0 yet (possibly reopening bug 0003626 which says that it couldn't be fixed).

(0007904) TomR (reporter) 2004-10-05 07:18	In IE6.0 the problem still exists with me. What exactly is the workaround implemented? I only tested with a small example, report an issue, forget Description. When use Back Button the whole form is cleared. ( By the way, this is for us an shwostopper to use required custom fields ).

(0007914) leftlink (reporter) 2004-10-05 12:18	This is the same issue as 0004520. It should be merged with that issue. I am noticing this behavior still, using IE6. Yes, it is not an issue with Firefox. Does Mantis have a function to merge two bugs?

(0008109) packeteer (reporter) 2004-10-19 23:18 edited on: 2004-10-20 02:47	Confirm issue exists using WindowsXP with IE 6. Bug does not exist with Firefox 1.0PR bug occurs with report issue page and not update issue page edited on: 10-20-04 02:47

(0008120) vboctor (administrator) 2004-10-20 08:28	I marked 0004520 as a duplicate of this one. However, when handling this issue, we should look at the notes of both issues. Also marked this as confirmed since it was confirmed by several users.

(0008336) Sire (reporter) 2004-11-15 02:47	Issue 4699 also deals with the unicode problem. (Duplicate?)

(0008342) leftlink (reporter) 2004-11-15 19:30	I just want to confirm that contrary to what "mfroman" said, the issue still existed in 0.19.0, which is what we have installed. In our case we added a custom field called "windows version". If you want to see the problem in action, go to organizenow.net/mantis and login as "test", "test" and then enter an issue, leaving "windows version" blank. Try to submit it, then press the back button. This has nothing to do with unicode or copying from microsoft word... this is a problem typing basic text in english.

(0008343) Sire (reporter) 2004-11-16 01:19	Agreed. This is two bugs in one: lauploix wrote: "[bug 1: ] In some cases, when copying strings from another software (ie word), the bug cannot be submitted even if every field is filled. [bug 2: ] When clicking back, the forms are blank. "

(0008344) Sire (reporter) 2004-11-16 01:19	Agreed. This is two bugs in one: lauploix wrote: "[bug 1: ] In some cases, when copying strings from another software (ie word), the bug cannot be submitted even if every field is filled. [bug 2: ] When clicking back, the forms are blank. "

(0008427) gtomlin (reporter) 2004-11-25 09:22	Some observations based on my experiences/tests: 1. This is _not_ strictly an IE problem. I am having this problem with Mantis 0.19.0 and Firefox 1.0 on Win XP. I also recreated it on IE 6, Netscape 7.1 and Firebird 0.6.1. However it did not happen on Opera 6.04. 2. The problem occurs whether the data is missing from a standard field such as Summary or from a custom field that has been marked required. 3. On update, when a required field is cleared, after the back button is pressed the record is redisplayed with its pre-update values. The problem exists on both report and update. Since different people are seeing/not seeing the problem with the same browsers, it might be browser options that are causing the problem.

(0008842) leftlink (reporter) 2005-01-04 20:44	I just wanted to confirm that with 0.19.1, with the summary field not filled out, and the default settings for Firefox 1.0, this issue still exists. It is really a pain. If there is no way to make the back button work, there needs to be another "back" button added to the user interface. That will go "forward" to the previous page. We wanted to release our bug tracker to end users but with this still a problem we need to delay it. What would it take to fix this? maybe we could get some folks to donate $$.

(0008865) malaussena (reporter) 2005-01-06 10:21	Confirmed with 0.19.2, IE6 on Windows XP

(0008948) kasparloog (reporter) 2005-01-11 16:45	A suggestion. This can be related to the no-cache headers. If you hit Back, then the browser reloads the page as it might have been changed. Can anyone try modifying the meta-tags and remove the cache temporarily?

(0008966) empty (reporter) 2005-01-12 00:57	I just added $g_bypass_headers = ON; in the config_inc.php This solves the problem for us. I haven't noticed other problems with this configuration 'til now.

(0008967) leftlink (reporter) 2005-01-12 08:36	I will try this workaround later... can others do the same and report what version of the browser it works with? Also, the "severity" of this bug should not be "minor". This is at least a major bug IMHO.

(0009000) kasparloog (reporter) 2005-01-13 09:39	I can confirm the bug with Firefox 1.0, Windows XP SP2. $g_bypass_headers = ON; removes the problem. I think that this should be removed only on certain pages, where having the most recent database data is not needed. Like bug_report_page.php

(0010069) BoGusman (reporter) 2005-05-10 14:42 edited on: 2005-05-10 14:44	Win XP/SP2, mantis 0.19.2, Firefox 1.0.3, $g_bypass_headers = ON; did not solve the problem for me.

(0010076) Sire (reporter) 2005-05-11 03:25	This definitely has to do with all the no-cache tags and headers. They need to be removed for those (and only those) pages that: - Often will be revisited with the back button because of missing or wrong entered information (like the bug report pages). - Does not, or very seldom suffers from having cache. Remember, very strange and annoying things can happen in a web app when using the default cache on pages, so the Mantis team has a good reason to force pages into not using it. However, the annoyance the users feel when having to write a huge bug report from scratch AGAIN just because they forgot some small required field invalidates any arguments of keeping the no-cache on these pages. Suggestion for next version: hard-code some pages (just the bug report pages?) to use the default caching. Suggestion for later versions: add an option on every page to use cache or not, or make a list in the config file. Thanks!

(0010118) lauploix (reporter) 2005-05-13 06:31	A simpler correction would be to add a "back" link in the error page, so that when you click on it, it goes (forward) back to the page you were filling, with values entered.

(0010119) ryandesign (reporter) 2005-05-13 06:47	And a better solution would be to not show a separate error page at all, but rather to already land back on the form page again, with the previously-entered values filled in, with the error message shown at the top of the form, like every other modern web application does...

(0010120) Sire (reporter) 2005-05-13 07:08	Ryandesign, agreed!

(0010167) hgaland (reporter) 2005-05-18 13:36	I also have the problem with IE6 sp2 on WinXP, for both bug report and bug update pages. I implemented the workaround in config_inc.php ($g_bypass_headers = ON;) and it is working. Can anyone explain me the possible side effects of this workaround ? Thanks

(0010170) thraxisp (manager) 2005-05-18 20:40	Setting $g_bypass_headers was intended to disable headers when running core/checkin.php from a command line. It disables some, but not all of the headers sent for each page. We should consider the integrated error message for a future release. Fix submitted to CVS to allow browser caching through the $g_allow_browser_cache variable. bug_report_advanced_page.php -> 1.49 bug_report_page.php -> 1.52 config_defaults_inc.php -> 1.264 core.php -> 1.42 file_download.php -> 1.36 meta_inc.php -> 1.18

Issue History
Date Modified	Username	Field	Change
2004-04-08 10:24	Chaotik	New Issue
2004-07-07 08:16	lauploix	Note Added: 0005893
2004-07-07 09:57	vboctor	Note Added: 0005895
2004-07-08 02:54	lauploix	Note Added: 0005910
2004-07-08 08:11	Chaotik	Note Added: 0005929
2004-09-30 10:36	mfroman	Note Added: 0007847
2004-10-05 07:18	TomR	Note Added: 0007904
2004-10-05 12:18	leftlink	Note Added: 0007914
2004-10-19 23:18	packeteer	Note Added: 0008109
2004-10-20 02:47	packeteer	Note Edited: 0008109
2004-10-20 08:27	vboctor	Relationship added	has duplicate 0004520
2004-10-20 08:28	vboctor	Note Added: 0008120
2004-10-20 08:28	vboctor	Status	new => confirmed
2004-11-15 02:47	Sire	Note Added: 0008336
2004-11-15 19:30	leftlink	Note Added: 0008342
2004-11-16 01:19	Sire	Note Added: 0008343
2004-11-16 01:19	Sire	Note Added: 0008344
2004-11-25 09:22	gtomlin	Note Added: 0008427
2005-01-04 20:44	leftlink	Note Added: 0008842
2005-01-06 10:21	malaussena	Note Added: 0008865
2005-01-11 16:45	kasparloog	Note Added: 0008948
2005-01-12 00:57	empty	Note Added: 0008966
2005-01-12 08:36	leftlink	Note Added: 0008967
2005-01-13 09:39	kasparloog	Note Added: 0009000
2005-05-10 14:42	BoGusman	Note Added: 0010069
2005-05-10 14:44	BoGusman	Note Edited: 0010069
2005-05-11 03:25	Sire	Note Added: 0010076
2005-05-11 03:25	Sire	Note Added: 0010077
2005-05-11 03:26	Sire	Note Deleted: 0010077
2005-05-13 06:31	lauploix	Note Added: 0010118
2005-05-13 06:47	ryandesign	Note Added: 0010119
2005-05-13 07:08	Sire	Note Added: 0010120
2005-05-13 07:08	Sire	Note Added: 0010121
2005-05-13 07:09	Sire	Note Deleted: 0010121
2005-05-18 13:36	hgaland	Note Added: 0010167
2005-05-18 14:25	thraxisp	Relationship added	has duplicate 0005415
2005-05-18 20:40	thraxisp	Status	confirmed => resolved
2005-05-18 20:40	thraxisp	Fixed in Version	=> 1.0.0a3
2005-05-18 20:40	thraxisp	Resolution	open => fixed
2005-05-18 20:40	thraxisp	Assigned To	=> thraxisp
2005-05-18 20:40	thraxisp	Note Added: 0010170
2005-05-31 11:27	vboctor	Status	resolved => closed
2009-10-27 23:36	vboctor	Relationship added	has duplicate 0009273