View Issue Details

IDProjectCategoryView StatusLast Update
0026477mantisbtuipublic2020-02-04 11:18
Reporterpolzin Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Product Version2.22.2 
Summary0026477: Removing the caching of pages with validation gives returns the "empty form on back" bug #3728
Description

For v2.22, 0025969 the forced caching of certain pages (bug_change_status_page.php, bug_report_page.php, bug_update_page.php) was removed. This returns the "empty form on back" bug 0003728.

The best ui would be to have some javascript that does a check first when pressing the submit button.
If this is not possible, I would suggest to revert 0025969, as it breaks a common functionality for some rather uncommon feature.

In general, I have the feeling that "$g_allow_browser_cache" should not be an option in config_defaults_inc, because with this setting ON, a lot of weired things are happening. But for the mentioned pages it is valuable, as long as a pre-submit-javascript check is not possible.

Steps To Reproduce

What I have done:

  • Enter "Report issue" form (but did not fill in category)
  • Submit
  • System shows error message
  • I press browser "back"
    What I expect:
  • Form filled
    What I see:
  • Form empty
TagsNo tags attached.

Relationships

related to 0025969 closedcproensa bug_report_page is forced to be cached 

Activities

cproensa

cproensa

2019-12-17 18:05

developer   ~0063293

i think that the main problem of caching those pages is that it caused a greater bad than good.
I don't have the time right now but the summary of the issue was:

  • The caching headers was not being effectively applied since many years ago.
  • Once the caching headers were rewritten, and were effectively applied, bad thing happened, like: changing project, or going to report page after changing projects, would not refresh the correct report page (with coherent fields for the project, as the cached copy is presented)
  • that's why the caching of those form pages was disabled.

I'm not sure on what conditions, (previously to that point in time of those changes), the back navigation would have worked in presenting the previous form values. May be because of some combination of the headers, or some specific behaviour of browsers when presented with the incosistent headers?

FYI: currently, some browsers do effectively cache the form inputs. IIRC Chrome in my experience does this. Firefox in the other hand, don't. This is a internal behaviour of the browser, that is caching the form inputs, not the whole page.
Reverting to force the page cache is not viable, becasue of the prolems that were experimented.

The best ui would be to have some javascript that does a check first when pressing the submit button.
But for the mentioned pages it is valuable, as long as a pre-submit-javascript check is not possible.

What is the point in pre-submit processing regarding the back navigation and losing the input fields?

polzin

polzin

2019-12-17 20:46

reporter   ~0063299

@cproensa The reason for using "back" is that some form validation issued an error, e.g. mandatory field not set. This is something that happens frequently and should not make you loose all your input.

polzin

polzin

2020-02-04 11:18

reporter   ~0063575

Any suggestion how to proceed on that?

Issue History

Date Modified Username Field Change
2019-12-17 17:15 polzin New Issue
2019-12-17 18:05 cproensa Note Added: 0063293
2019-12-17 20:46 polzin Note Added: 0063299
2019-12-18 15:18 atrol Relationship added related to 0025969
2020-02-04 11:18 polzin Note Added: 0063575