Bugfix 4415,4453,4452,4451; RFE-1518 (Navigate away) improvements

[chirayuchiripal]

-> Reverted old partial fix for bug-4415
-> Complete Fix for Bug-4415 + "Filter Rows:" prompt fix
-> It now considers only input/textarea which are inside form elements. (This fixes unnecessary prompts on "Filter rows:" of browse tab).

[coveralls]

Coverage remained the same when pulling a5fe8ea on D-storm:bug-4415 into a6d379c on phpmyadmin:master.

[chirayuchiripal]

-> Now, listens only on forms with "lock-page" class.
-> Added lock-page class to SQL tab, Search tab (table level), Insert Tab, create table interface.

[coveralls]

Coverage decreased (-0.01%) when pulling 7385c28 on D-storm:bug-4415 into a7bc3a7 on phpmyadmin:master.

[chirayuchiripal]

-> Displays lock icon at top right corner (just before "goto pagetop") in menubar when form gets edited.

[coveralls]

Coverage decreased (-0.0%) when pulling d9a4e54 on D-storm:bug-4415 into d909aa6 on phpmyadmin:master.

[chirayuchiripal]

-> Complete makeover
-> bugfix 4453/52/51

[coveralls]

Coverage decreased (-0.0%) when pulling b80a41a on D-storm:bug-4415 into d909aa6 on phpmyadmin:master.

[coveralls]

Changes Unknown when pulling de0f7bc on D-storm:bug-4415 into * on phpmyadmin:master*.

[coveralls]

Coverage increased (+0.01%) when pulling de0f7bc on D-storm:bug-4415 into fe93f9e on phpmyadmin:master.

[chirayuchiripal]

Thanks for the github example, maybe now I can explain it in a better way.

CASE 1 (No changes, no prompt on cancel):
1] Click "Edit Comment" link on PR.
2] Dont change anything and click "cancel".
3] No prompt.

CASE 2 (Unsaved changes, prompt on cancel):
1] Click "Edit Comment" link on PR.
2] Change some content and click "cancel".
3] Prompts "Are you sure you want to cancel? You have unsaved changes that will be reverted".

CASE 3 (Revert changes, no prompt on cancel): [Bug-4452]
1] Click "Edit Comment" link on PR.
2] Change some content and revert them.
3] click "cancel".
4] No prompt.

CASE 4 (Truncating existing data, prompt on cancel): [Bug-4453]
1] Click "Edit Comment" link on PR.
2] truncate the field and click "cancel".
3] Prompts "Are you sure you want to cancel? You have unsaved changes that will be reverted".

CASE 5 (cut/pasting using mouse, prompt on cancel): [Bug-4451]
1] Click "Edit Comment" link on PR.
2] right-click and paste some content and click "cancel".
3] Prompts "Are you sure you want to cancel? You have unsaved changes that will be reverted".

[chirayuchiripal]

I think we should also use similar prompt message. How about this one: "Are you sure you want to leave this page? You have unsaved changes that will be reverted." or any other suggestion would be appreciated.

[lem9]

I suggest "You have unsaved changes; are you sure you want to leave this page?".

[chirayuchiripal]

That is also a good one.

[mebjas]

Well, I was considering case of editing any file in github, they do not take care if the values have been reverted, the prompt is triggered for any change. Although its a good feature to have if saving the values of each fields in not an overhead!

But considering the one, when we truncate the values. If we look at the scenario for PMA, If I have empty fields, I do not have any data to loose.. in this case, I think maximum probability is user intentionally want to navigate away and thus should not get a prompt. Even if false negative occurs, the user has no data to loose!

[chirayuchiripal]

@mebjas, after reverting the changes whether we save or not does not make the difference so there is no need to prompt and as far as saving values of each field is considered then it is not an overhead because I am not saving the values of each field, here I am hashing the old value and saving that hash inside data-attribute of form element which is fixed small size data no matter how big your data is.

And considering the data loss only is not good, we should consider changes because deletions are equally important to additions. It may be possible that user wants to empty the field and accidentally navigates away and his/her changes will not get saved. Suppose a user is editing a row (insert/edit tab) having 100 columns all full of data and you want to empty the 90 columns of it. After doing this, (s)he accidentally clicked a link then it would get navigated away without saving it. Yes, if the field initially was empty then it will not prompt the user.

[mebjas]

Well I think this condition will arise in mostly in editing tab only. So we can keep it.

[chirayuchiripal]

Exactly.

[scrutinizer-notifier]

The inspection completed: No new issues

[lem9]

I have started testing and so far, I like this patch. Can you confirm that grid editing with the following case does not lock the page?

$cfg['SaveCellsAtOnce'] = true;

[chirayuchiripal]

Currently, I have not added lock-page class to grid editing form. So, it will not work now. If it is needed to add there, I can add it.

[coveralls]

Coverage decreased (-0.0%) when pulling b527dc7 on D-storm:bug-4415 into 239f4c0 on phpmyadmin:master.

[lem9]

Well it can wait; I'll merge this pull request first, after my tests.

[lem9]

Nice work. I'm not sure we need to lock the table Search page (at least, leaving this page would not cause much harm) but I'm happy to leave it locked for now.