Page MenuHomePhabricator

jQuery.wikibase.***view widgets should not switch between edit modes on their own
Closed, ResolvedPublic

Description

he jQuery.wikibase.***view widgets (.e.g "valueview") should not be interpreting the "enter" key or "esc" keys being pressed as the user's wish to leave the edit mode. This logic should be implemented in the code instantiating the widgets.

This current behavior can be a problem when the widgets should be used on their own, e.g. on a special page where they shall remain in edit mode all of the time. It seems like we designed the widgets too smart while this should better be left to the respective controller depending on the use-case.

Changing this and introducing some sort of "focus management" in case of the entity view use-case would be the way to go.


Version: unspecified
Severity: normal
Whiteboard: u=dev c=frontend p=0

Details

Reference
bz54021

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:08 AM
bzimport set Reference to bz54021.
bzimport added a subscriber: Unknown Object (MLST).
Danwe created this task.Sep 11 2013, 4:54 PM
Danwe added a comment.Sep 11 2013, 4:56 PM

not "focus management" but management of "key management", confused this with the similar Bug 54019 for a second.

Danwe added a comment.Sep 11 2013, 5:01 PM

A fast hack for controllers who want to prevent the enter/esc keys from having an effect on the widget's edit mode can be to simply overwrite the "stopEditing" member of the widget via:

$widget.data( 'widgetname' ).stopEditing = function() {};

Change 92310 had a related patch set uploaded by Daniel Werner:
TODO for bug 54021, Snakview should not switch between edit modes on its own!

https://gerrit.wikimedia.org/r/92310

Change 92310 merged by jenkins-bot:
TODO for bug 54021, Snakview should not switch between edit modes on its own!

https://gerrit.wikimedia.org/r/92310

Danwe added a comment.Nov 5 2013, 3:38 PM

Above patch-set only adds an inline TODO.

https://gerrit.wikimedia.org/r/#/c/171258/

This seems to be the only (or last) place key handling was done in some *view widget. In previous refactorings, key handling logic has been moved to the toolbar definitions which is done in the change for the snakview as well. If the snakview is to be used on its own, a dedicated toolbar for it would need to be registered anyway. This toolbar would then be responsible for the key handling.