http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13391 --- Comment #2 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to M. de Rooy from comment #1)

Hi Jacek, I am soon submitting code for report 10480. It will address these problems more generally, also allowing key and mouse events handling via jquery code.

Maybe I was reading too fast.. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13391 --- Comment #4 from Jacek Ablewicz <ablewicz@gmail.com> --- Created attachment 34138 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=34138&action=edit Bug 13391 - MARC 008 builder plugin not compatible with browser autocompletion In the koha-tmpl/intranet-tmpl/prog/en/js/xmlControlfield.js (currently used by 006 and 008 MARC21 plugins), in line 317 there are two JS events (onkeyup and onfocus) associated with <input> fields. But there is a slight problem with onkeyup event handler, apparently this event does not fire when: - user starts to enter some characters using the keyboard, - and then chooses something from the autocompletion list offered by browser. In such circumstances only the first character[s] entered in the given field are saved in 006 and/or 008 (only the part that was typed on the keyboard), and the remaining characters are effectively being ignored. This patch adds two additional event handlers to the <input> fields generated by the renderPositions() function in xmlControlfield.js: oninput (that should completely solve the problem for recent, HTML5-compliant browsers) and onblur (that, while not being quite satisfactory solution, should at least somehow improve things for old/lagacy WWW browsers as well). To test: - reproduce the aforementioned issue (try to enter some data into e.g. "country code" / 15-17 positions in the 008 MARC21 plugin: first using only the keyboard, and then by the means of the browser autocomplete) - observe that when the value is choosen from the autocompletion list, only the 1st part of it is being stored in the respective 008 field positions on the top - apply patch - clear browser cache - retest (preferably using some modern WWW browser first, and then something much older and inherently broken like IE7 or IE8 etc.) - make sure there are no aparent regresions of any kinds regarding 006 and 008 MARC21 plugins behaviour. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13391 --- Comment #5 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- (In reply to M. de Rooy from comment #3)

...

However, none of those methods are quite sufficient for older browsers. How far should we go?

Hopefully not too far ;). I did some googling, and it turns out that making it work 100% reliably for legacy browser wolud be pretty complicated. For example, there is an YUI module for that (event-valuechange), but it resorts to the timers / pooling methods, which is kind of ugly. So in the submitted patch I simply added two event handlers (oninput= and onblur=) - unless I'm very much mistaken, 1st should solve the problem for modern browsers, and the 2nd improve it a little bit for older ones. There is a little drawback though: in the modern browser, the same event handling code will now be executed (up to) 3 times when the user changes something in the given plugin <input> field. It doesn't seem to cause any noticeable issues performance-wise, but sill.. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13391 --- Comment #7 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- (In reply to Paola Rossi from comment #6)

On master 3.19.00.001 head 13645, using FireFox 36 I edited a journal,

Then I wrote n, waiting for an autocompletion drop down list of all the country codes beginning by 'n'. But no list appeared. Then I wrote ny, waiting for the value's autocompletion "nyu", but it didn't appear.

So I could not reproduce the bug.

I can't reproduce it any longer as well in Firefox 36.. Up-to-date Chrome also does not save any newly entered form data for autocompletion (but it displays drop down list with older values which were entered some months ago). In Firefox 34 and in Pale Moon 25.2.1 form data in plugin windows is still being saved and offered for autocompletion. Looks like there were some chages introduced in some browsers recently, which prevent entered form data from being stored (unless the form is actually submitted with POST or GET, I guess ?). Some of our librarians are (allegedly) using this autocompletion feature in their daily work, so after it ceased to function in recent browsers, I expect there will be probably some complains in 3.. 2.. 1.. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13391 Liz Rea <liz@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liz@catalyst.net.nz Resolution|--- |WORKSFORME Status|Needs Signoff |RESOLVED --- Comment #9 from Liz Rea <liz@catalyst.net.nz> --- I can't make this happen in Firefox 41, that's 3 Works for me's. -- You are receiving this mail because: You are watching all bug changes.