Hi, Currently confirm navigations works well with ajax, if there is some unsubmitted form in the page. But I was thinking this confirm dialog should trigger for similar case if a user accidently press backspace, reloads or perform some operation that results in new page load. I have written the script but I couldn't get which is the perfect js file for adding this feature. Can anyone help me here?
Minhaz cistoner.org
On 4/21/14, Minhaz A V minhazav@gmail.com wrote:
Hi, Currently confirm navigations works well with ajax, if there is some unsubmitted form in the page. But I was thinking this confirm dialog should trigger for similar case if a user accidently press backspace, reloads or perform some operation that results in new page load. I have written the script but I couldn't get which is the perfect js file for adding this feature. Can anyone help me here?
I guess common.js or ajax.js may be appropriate for adding the relevant code, if that is what you were asking? Also, documentation contained at [0] and [1] may help.
[0] http://wiki.phpmyadmin.net/pma/Page_loader [1] http://wiki.phpmyadmin.net/pma/Microhistory
Hi
Dne Mon, 21 Apr 2014 19:22:58 +0530 Minhaz A V minhazav@gmail.com napsal(a):
Currently confirm navigations works well with ajax, if there is some unsubmitted form in the page.
No it does not work well - it asks for confirmation whenever there is something filled in in the form. What is true for many of our forms without user doing anything. Also it seems to ask for confirmation even when user is submitting form which he has just filled in (try something on table's Operations tab). I've just reverted commit causing these.
PS: All the Jenkins failures were also caused by this, is anybody paying attention to these mails or they are just being ignored?
Hi, I see the code is showing behavior other than expected behavior at certain sections. I was thinking this code could be modified to check if any input field was changed from the value it was loaded with if some user try to perform ajax operation or any operation that triggers onbeforeunload event.
AJAX code will go well in ajax.js while for onbeforeunload section, I'd add an event listener to it in common.js as mentioned by Atul.
If you guys feel this feature should not exist in pma, I'd stop here on this. Kindly let me know by night or I'll start writing :D, as I feel this feature should be there.
Also, is it possible to add a branch for this in pma, till this feature is working well or I should come up with a whole working one in my fork before I pull.
Minhaz cistoner.org
On Tue, Apr 22, 2014 at 5:04 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Mon, 21 Apr 2014 19:22:58 +0530 Minhaz A V minhazav@gmail.com napsal(a):
Currently confirm navigations works well with ajax, if there is some unsubmitted form in the page.
No it does not work well - it asks for confirmation whenever there is something filled in in the form. What is true for many of our forms without user doing anything. Also it seems to ask for confirmation even when user is submitting form which he has just filled in (try something on table's Operations tab). I've just reverted commit causing these.
PS: All the Jenkins failures were also caused by this, is anybody paying attention to these mails or they are just being ignored?
-- Michal Čihař | http://cihar.com | http://phpmyadmin.net
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Tue, Apr 22, 2014 at 5:16 PM, Minhaz A V minhazav@gmail.com wrote:
Hi, I see the code is showing behavior other than expected behavior at certain sections. I was thinking this code could be modified to check if any input field was changed from the value it was loaded with if some user try to perform ajax operation or any operation that triggers onbeforeunload event.
AJAX code will go well in ajax.js while for onbeforeunload section, I'd add an event listener to it in common.js as mentioned by Atul.
If you guys feel this feature should not exist in pma, I'd stop here on this. Kindly let me know by night or I'll start writing :D, as I feel this feature should be there.
Also, is it possible to add a branch for this in pma, till this feature is working well or I should come up with a whole working one in my fork before I pull.
About a separate branch, it is not meant to be created in main PMA
repository, instead you can create a new branch out of master in your local repo and push it to your github account for public review, then you can open a pull request from your branch to the main PMA repo's master branch when it's all done.
Atul, I get that, that is the normal workflow, but this is a new feature this must go to master branch when the pull is merged like it happened this time. Although I have a feeling that *matching the values of input fields against the values they were loaded with would be a good solution to this*, rather than checking if length of visible input.text fields, i think rather than merging this directly to master, in pma main repo if it is merged with some other branch and other members have confirmed no bugs exist, it can be merged to master.
Minhaz cistoner.org
On Tue, Apr 22, 2014 at 5:23 PM, Atul Pratap Singh < atulpratapsingh05@gmail.com> wrote:
On Tue, Apr 22, 2014 at 5:16 PM, Minhaz A V minhazav@gmail.com wrote:
Hi, I see the code is showing behavior other than expected behavior at certain sections. I was thinking this code could be modified to check if any input field was changed from the value it was loaded with if some user try to perform ajax operation or any operation that triggers onbeforeunload event.
AJAX code will go well in ajax.js while for onbeforeunload section, I'd add an event listener to it in common.js as mentioned by Atul.
If you guys feel this feature should not exist in pma, I'd stop here on this. Kindly let me know by night or I'll start writing :D, as I feel this feature should be there.
Also, is it possible to add a branch for this in pma, till this feature is working well or I should come up with a whole working one in my fork before I pull.
About a separate branch, it is not meant to be created in main PMA
repository, instead you can create a new branch out of master in your local repo and push it to your github account for public review, then you can open a pull request from your branch to the main PMA repo's master branch when it's all done.
-- Atul Pratap Singh http://blog.atulsisodia.in/
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Tue, Apr 22, 2014 at 5:30 PM, Minhaz A V minhazav@gmail.com wrote:
Atul, I get that, that is the normal workflow, but this is a new feature this must go to master branch when the pull is merged like it happened this time. Although I have a feeling that *matching the values of input fields against the values they were loaded with would be a good solution to this*, rather than checking if length of visible input.text fields, i think rather than merging this directly to master, in pma main repo if it is merged with some other branch and other members have confirmed no bugs exist, it can be merged to master.
Please understand that you have a public github account and phpMyAdmin repo forked on it, so if someone has to test your changes, one can easily pull from your github to one's local repo, test it and comment on your github, etc.
Hi
Dne Tue, 22 Apr 2014 17:16:35 +0530 Minhaz A V minhazav@gmail.com napsal(a):
I was thinking this code could be modified to check if any input field was changed from the value it was loaded with if some user try to perform ajax operation or any operation that triggers onbeforeunload event.
Looks like a better approach. On page/ajax load the initial value would be stored in some data attribute and the trigger would then check it for change. Though there might be some javascript generated values not covered by this...
AJAX code will go well in ajax.js while for onbeforeunload section, I'd add an event listener to it in common.js as mentioned by Atul.
If you guys feel this feature should not exist in pma, I'd stop here on this. Kindly let me know by night or I'll start writing :D, as I feel this feature should be there.
This is indeed useful feature, but it should not block normal usage as the first implementation did.
Also, is it possible to add a branch for this in pma, till this feature is working well or I should come up with a whole working one in my fork before I pull.
You can have branch in your fork, no need to add branch to upstream repository.
I have a better approach, We'll count the no of characters before an ajax load, and on event request count again and compare. But should this cause selenium test to fail? is there any test case which should trigger the dialog where it is expected to trigger?
Minhaz cistoner.org
On Wed, Apr 23, 2014 at 7:17 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 22 Apr 2014 17:16:35 +0530 Minhaz A V minhazav@gmail.com napsal(a):
I was thinking this code could be modified to check if any input field
was
changed from the value it was loaded with if some user try to perform
ajax
operation or any operation that triggers onbeforeunload event.
Looks like a better approach. On page/ajax load the initial value would be stored in some data attribute and the trigger would then check it for change. Though there might be some javascript generated values not covered by this...
AJAX code will go well in ajax.js while for onbeforeunload section, I'd
add
an event listener to it in common.js as mentioned by Atul.
If you guys feel this feature should not exist in pma, I'd stop here on this. Kindly let me know by night or I'll start writing :D, as I feel
this
feature should be there.
This is indeed useful feature, but it should not block normal usage as the first implementation did.
Also, is it possible to add a branch for this in pma, till this feature
is
working well or I should come up with a whole working one in my fork
before
I pull.
You can have branch in your fork, no need to add branch to upstream repository.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Wed, 23 Apr 2014 19:27:53 +0530 Minhaz A V minhazav@gmail.com napsal(a):
I have a better approach, We'll count the no of characters before an ajax load, and on event request count again and compare.
I don't think counting characters is a good idea, this way you can not detect many changes.
But should this cause selenium test to fail? is there any test case which should trigger the dialog where it is expected to trigger?
It should not be triggered anywhere in the Selenium tests - always when we fill in some value we also submit the form.
2014-04-22 13:34 GMT+02:00 Michal Čihař michal@cihar.com:
Hi
Dne Mon, 21 Apr 2014 19:22:58 +0530 Minhaz A V minhazav@gmail.com napsal(a):
Currently confirm navigations works well with ajax, if there is some unsubmitted form in the page.
No it does not work well - it asks for confirmation whenever there is something filled in in the form. What is true for many of our forms without user doing anything. Also it seems to ask for confirmation even when user is submitting form which he has just filled in (try something on table's Operations tab). I've just reverted commit causing these.
PS: All the Jenkins failures were also caused by this, is anybody paying attention to these mails or they are just being ignored?
-- Michal Čihař | http://cihar.com | http://phpmyadmin.net
Hi,
I don't think they are ignored. Yesterday, I wanted to ask about all these errors, because I don't see the origin. But the failed tests are linked to Selenium. Maybe people are not comfortable enough with this…
Hugues.
Michal Čihař a écrit :
Hi
Dne Mon, 21 Apr 2014 19:22:58 +0530 Minhaz A V minhazav@gmail.com napsal(a):
Currently confirm navigations works well with ajax, if there is some unsubmitted form in the page.
No it does not work well - it asks for confirmation whenever there is something filled in in the form. What is true for many of our forms without user doing anything. Also it seems to ask for confirmation even when user is submitting form which he has just filled in (try something on table's Operations tab). I've just reverted commit causing these.
PS: All the Jenkins failures were also caused by this, is anybody paying attention to these mails or they are just being ignored?
For me, it's difficult to see when these failures are real or not. For example, after your patch revert
https://ci.phpmyadmin.net/job/phpMyAdmin-continuous/6120/
there were a few Selenium failures. Are these real?
Hi
Dne Tue, 22 Apr 2014 08:17:07 -0400 Marc Delisle marc@infomarc.info napsal(a):
For me, it's difficult to see when these failures are real or not. For example, after your patch revert
https://ci.phpmyadmin.net/job/phpMyAdmin-continuous/6120/
there were a few Selenium failures. Are these real?
How you define real bugs? If you mean bugs in our code, then almost all bugs are real (basically all with exception of timeouts when talking with Selenium server), however some of these are bugs in our Selenium tests. Most of these are some timing issues like the Selenium driver is clicking on elements too early (eg. before Javascript initialization is completed).
These are less visible (happen less often) on Jenkins and more visible on Travis (due to higher latencies caused by local proxy used for testing).
I've already fixed many of such errors, but I somehow ran out of time I can spend on this, so any help is welcome here.
The ideal situation would be to fix these tests completely and do strict Selenium testing in Travis as well to have checked all pull requests with it...
Michal Čihař a écrit :
Hi
Dne Tue, 22 Apr 2014 08:17:07 -0400 Marc Delisle marc@infomarc.info napsal(a):
For me, it's difficult to see when these failures are real or not. For example, after your patch revert
https://ci.phpmyadmin.net/job/phpMyAdmin-continuous/6120/
there were a few Selenium failures. Are these real?
How you define real bugs? If you mean bugs in our code, then almost all bugs are real (basically all with exception of timeouts when talking with Selenium server), however some of these are bugs in our Selenium tests. Most of these are some timing issues like the Selenium driver is clicking on elements too early (eg. before Javascript initialization is completed).
Well, all of the Jenkins runs on phpMyAdmin-continuous have failed since almost 5 complete days. Are these all timing issues?
These are less visible (happen less often) on Jenkins and more visible on Travis (due to higher latencies caused by local proxy used for testing).
I've already fixed many of such errors, but I somehow ran out of time I can spend on this, so any help is welcome here.
The ideal situation would be to fix these tests completely and do strict Selenium testing in Travis as well to have checked all pull requests with it...
Hi
Dne Wed, 23 Apr 2014 09:51:48 -0400 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Hi
Dne Tue, 22 Apr 2014 08:17:07 -0400 Marc Delisle marc@infomarc.info napsal(a):
For me, it's difficult to see when these failures are real or not. For example, after your patch revert
https://ci.phpmyadmin.net/job/phpMyAdmin-continuous/6120/
there were a few Selenium failures. Are these real?
How you define real bugs? If you mean bugs in our code, then almost all bugs are real (basically all with exception of timeouts when talking with Selenium server), however some of these are bugs in our Selenium tests. Most of these are some timing issues like the Selenium driver is clicking on elements too early (eg. before Javascript initialization is completed).
Well, all of the Jenkins runs on phpMyAdmin-continuous have failed since almost 5 complete days. Are these all timing issues?
As the list of failing tests always differs it is a timing issue. Actually it looks like the navigation tree got slower and clicking on the table name immediately after expanding database no longer works. I've tried to workaround it in 8a0ab39, let's see if that helps.
-
Atul Pratap Singh -
Hugues Peccatte -
Marc Delisle -
Michal Čihař -
Minhaz A V