In staff interface, when performing a simple search with a double quote (ie "histoire algerie"), the javascript is broken in results page because of : function GetZ3950Terms(){ var strQuery="&frameworkcode="; strQuery += "&" + "title" + "=" + ""histoire%20algerie""; Double quotes are not URI-escaped.
Created attachment 26997 [details] [review] Bug 12071 - javascript broken for a search with double quotes In staff interface, when performing a simple search with a double quote (ie "histoire algerie"), the javascript is broken in results page because of : function GetZ3950Terms(){ var strQuery="&frameworkcode="; strQuery += "&" + "title" + "=" + ""histoire%20algerie""; This patch moves URI escaping from perl to template with uri TT filter. Test plan : - In staff interface, perform a search with double quotes that will return no result, ie "aaa xxx" => Without patch, javascript is broken => With patch, javascript is not broken - Click on Z3950 button on results page => Without patch, the Title input is empty => With patch, the Title input contains the search terms
I can't reproduce this bug in master.
(In reply to Owen Leonard from comment #2) > I can't reproduce this bug in master. I found it occurs on a server with Debian Squeeze and not on my laptop with Ubuntu 13.10, maybe a difference in library URI::Escape. Still it must be corrected because most of libraries servers run Debian Squeeze. Also, escaping URL characters into TT is a better code, regarding to MVC layers.
Created attachment 27116 [details] Patch fixes encoding problem as well (e.g. äöü) I tryed to reproduce the problem and found an other one: If you do a search for someting like äöü and then hit Z39.50 button, the encoding in the Z39.50 search form is broken. With patch, the encoding is correct.
Created attachment 27117 [details] [review] [SIGNED-OFF] Bug 12071 - javascript broken for a search with double quotes In staff interface, when performing a simple search with a double quote (ie "histoire algerie"), the javascript is broken in results page because of : function GetZ3950Terms(){ var strQuery="&frameworkcode="; strQuery += "&" + "title" + "=" + ""histoire%20algerie""; This patch moves URI escaping from perl to template with uri TT filter. Test plan : - In staff interface, perform a search with double quotes that will return no result, ie "aaa xxx" => Without patch, javascript is broken => With patch, javascript is not broken - Click on Z3950 button on results page => Without patch, the Title input is empty => With patch, the Title input contains the search terms Additional test: Do a search with something like äöü and then click Z3950 button on results page. Without patch, encoding is broken in Z3950 form With patch, encoding is correct. Signed-off-by: Marc Véron <veron@veron.ch>
Created attachment 27272 [details] [review] [PASSED QA] Bug 12071 - Javascript broken for a search with double quotes In staff interface, when performing a simple search with a double quote (ie "histoire algerie"), the javascript is broken in results page because of : function GetZ3950Terms(){ var strQuery="&frameworkcode="; strQuery += "&" + "title" + "=" + ""histoire%20algerie""; This patch moves URI escaping from perl to template with uri TT filter. Test plan : - In staff interface, perform a search with double quotes that will return no result, ie "aaa xxx" => Without patch, javascript is broken => With patch, javascript is not broken - Click on Z3950 button on results page => Without patch, the Title input is empty => With patch, the Title input contains the search terms Additional test: Do a search with something like äöü and then click Z3950 button on results page. Without patch, encoding is broken in Z3950 form With patch, encoding is correct. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Fixed a few tabs. Passes tests and QA script. I can't reproduce the Javascript problem, but I can reproduce the Z39.50 encoding problem and can detect no regression.
Pushed to master, thanks Fridolin!
Pushed to 3.14.x, will be in 3.14.10
*** Bug 13038 has been marked as a duplicate of this bug. ***