Bug 13391 - MARC 008 builder plugin not compatible with browser autocompletion
Summary: MARC 008 builder plugin not compatible with browser autocompletion
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Jacek Ablewicz
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-04 12:54 UTC by Jacek Ablewicz
Modified: 2016-06-21 21:36 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 13391 - MARC 008 builder plugin not compatible with browser autocompletion (4.68 KB, patch)
2014-12-05 11:29 UTC, Jacek Ablewicz
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jacek Ablewicz 2014-12-04 12:54:36 UTC
In the koha-tmpl/intranet-tmpl/prog/en/js/xmlControlfield.js (line 317) there are two JS events (onkeyup and onfocus) being handled for 008 MARC plugin <input ...> fields (for MARC21 008 plugin, <input> is used e.g. for dates, country codes and language codes). 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.

End result is that in such circumstances only the first character[s] entered in the given field are saved in 008 (only the part that was typed on the keyboard), and the remaining characters are effectively lost / being ignored by 008 plugin (unless the user "returns" to this field, i.e. gives it focus once again, before clicking "OK").

Replacing 'onkeyup' with 'oninput' in line 317 looks like the easiest solution for this issue; it works fine in recent (HTML5 compliant) browsers, but OnInput event handler is relatively new thing - it would not work in old, "legacy" WWW browsers. I guess we can also add autocomplete='off' to the <input> fields generated by renderPositions() function in xmlControlfield.js ;). I'm wondering what would happen if we try to put both oninput=.. and onkeyup= event handlers in those fields (probably both of them would fire when user enters something, but maybe that will be not necessarily such a bad thing ?).
However, none of those methods are quite sufficient for older browsers. Reparsing all fields on form submit may help a little bit - so changes in the entered values which may have been previously ignored by the plugin would have a chance to be saved in 008 after all - but that's only a partial solution, the 008 contents being displayed on top may still sometimes get "out of sync" with the individual values below..
Comment 1 Marcel de Rooy 2014-12-04 13:11:21 UTC
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.
Comment 2 Marcel de Rooy 2014-12-04 13:14:04 UTC
(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..
Comment 3 Marcel de Rooy 2014-12-04 13:53:39 UTC
(In reply to Jacek Ablewicz from comment #0)
> In the koha-tmpl/intranet-tmpl/prog/en/js/xmlControlfield.js (line 317)
The code is used in two templates for marc21 006 and 008. At first glance it looks like overcomplicated design.

> End result is that in such circumstances only the first character[s] entered
> in the given field are saved in 008 (only the part that was typed on the
> keyboard), and the remaining characters are effectively lost / being ignored
> by 008 plugin (unless the user "returns" to this field, i.e. gives it focus
> once again, before clicking "OK").
Could you automate that workaround?

> However, none of those methods are quite sufficient for older browsers.
How far should we go?
Comment 4 Jacek Ablewicz 2014-12-05 11:29:49 UTC
Created attachment 34138 [details] [review]
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.
Comment 5 Jacek Ablewicz 2014-12-05 11:54:05 UTC
(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..
Comment 6 Paola Rossi 2015-02-24 16:37:03 UTC
On master 3.19.00.001 head 13645, using FireFox 36 I edited a journal,
ACEEE ISSN 2158-754X.
Using "Tag editor", I edited the 008 MARC21 field of the journal.
A new window was opened, whose current URL was:
<http://......../cgi-bin/koha/cataloguing/plugin_launcher.pl?....>

On 15-17 field, first I emptied the field.
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 keep the status of this bug to "Needs Signoff" status.
Comment 7 Jacek Ablewicz 2015-02-26 08:15:37 UTC
(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..
Comment 8 Paola Rossi 2015-02-26 14:35:15 UTC
(In reply to Jacek Ablewicz from comment #7)
>[...] 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 [...]).

The same as Firefox 36 !

[And Explorer 11 too.]
Comment 9 Liz Rea 2015-11-06 01:35:28 UTC
I can't make this happen in Firefox 41, that's 3 Works for me's.