Opened 6 years ago

#1723 new defect

[patch] No-change edit to single-field creator forces two-field mode on next edit

Reported by: fbennett Owned by: dstillman
Priority: minor Milestone:
Component: interface Version: 2.0
Keywords: Cc:

Description

When a creator field is set to single-field mode, and is then opened for editing, and closed without making any change, the next edit of the field will save it in two-field mode, but without reparsing the content. That is, the field content is set like this:

lastName: 'John Doe'
firstName:

The cause seems to run as follows. The fieldMode is carried on the textbox, which is destroyed when hideEditor() is run. When the field has not changed, an elem element is minted, but the fieldMode value is not set on it. The elem element must be provided in some way, because it is substituted in at the end of the function, and creators are just one of several field types served by the terminal substitution.

The missing attribute on the element doesn't affect the appearance of the UI until the next showEditor/hideEditor cycle, which is where the behavior comes from.

The story of why things don't break when the field is edited is actually a little more complicated. When the field has changed, hideEditor() calls modifyCreator(), which moves the textbox attribute across to a freshly minted label element, and subs the latter into place. This leaves the textbox (the argument to hideEditor()) as an orphan to the DOM, so although the elem substitution is performed on it at the end of the function, it either breaks without raising an error, or the substitution happens out in nano-space someplace where it can't be seen.

Anyway, the patch seems to work. :)

Attachments (1)

field-mode-bug.patch (603 bytes) - added by fbennett 6 years ago.

Download all attachments as: .zip

Change History (1)

Changed 6 years ago by fbennett

Note: See TracTickets for help on using tickets.