I think I have found a small bug on KeyboardWidget

120 views
Skip to first unread message

CL

unread,
Jan 8, 2017, 6:04:46 AM1/8/17
to TiddlyWiki
Minial test code:
\define macro()
<$action-setfield $tiddler="Tiddler" text={{$:/state/tiddler}}/>
<$action-setfield $tiddler="$:/state/tiddler" text=""/>
\end

<$keyboard actions=<<macro>> key="enter">
<$edit-text tiddler="$:/state/tiddler" tag="input"/>
</$keyboard>

I wanted edit-text field to be cleared after I trigger action with KeyboardWidget.
Text field of the state tiddler does get cleared,
but the edit-text field remains same.
I guess this is a bug.

Best wishes,
CL

Tobias Beer

unread,
Jan 8, 2017, 9:31:56 AM1/8/17
to tiddl...@googlegroups.com
Hi CL,

As for a simple input element, the problem is that it does not listen to the enter key, since it only binds the input event, which imho is a problem.

This fiddle illustrates how the input in TiddlyWiki doesn't receive any event.and thus doesn't update / refresh.

https://jsfiddle.net/tobibeer/593zpemu/

Try typing some, and then hit enter only to see that there's no input event firing.

I would argue there needs to be a keyup handler as well that only, explicitly listens to the enter key.

Best wishes,

Tobias.

Tobias Beer

unread,
Jan 8, 2017, 9:38:55 AM1/8/17
to tiddl...@googlegroups.com
Hi again CL & @Jeremy

Try typing some, and then hit enter only to see that there's no input event firing.

What's also not clear at all is how the edit-text widget manages refreshing.
This appears to be implemented different from other widgets.
So the question is. Why does the edit-text widget not realize
that its tiddler is gone or the text of it deleted and thus not refresh accordingly?

All in all, I think this should be reported as a bug at the github repo.

Best wishes,

Tobias.

Tobias Beer

unread,
Jan 8, 2017, 9:48:22 AM1/8/17
to TiddlyWiki
Hi again,
 
So the question is. Why does the edit-text widget not realize
that its tiddler is gone or the text of it deleted and thus not refresh accordingly?

I believe this is owed to a shortcomming in refresh handling:

The edit-text widget refreshes first. At that point, the keyboard widget hasn't changed anything about its value.

Now the keyboard widget fires and does it's thing. However, the refresh cycle is oddly done in a way that the edit-text widget does not check again if it needs refreshing and so it just sits there, waiting for the next input.

So, the question is: how to modify the refresh handling, so that affected elements know they need to double check, since one of the things they were watching changed before the refresh cycle changed.

I am a bit astonished, that this problem of "sequence of events" wouldn't be handled by the core already so that another refresh cycle would kick-in, since the last one modified the store... or some such.

Best wishes,

Tobias.

Jeremy Ruston

unread,
Jan 8, 2017, 1:13:23 PM1/8/17
to tiddl...@googlegroups.com
Hi Tobias

This is actually related to the conditional in the edit widget that we discussed a few weeks ago.

The issue is that when the button is clicked the text edit has the focus, thus the conditional kicks in and prevents the update.

You’ll recall that the purpose of the conditional was to prevent the cursor/selection position being lost when the value for the text input is updated. So the fix would be to manually preserve the selection position across the update.

Best wishes

Jeremy


--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ac977126-7033-44af-b724-03bab9c34605%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tobias Beer

unread,
Jan 9, 2017, 5:32:57 AM1/9/17
to tiddl...@googlegroups.com
Hi Jeremy,
 
This is actually related to the conditional in the edit widget that we discussed a few weeks ago.

I knew it rang a bell but that last step didn't make it all the way to my focus.

The issue is that when the button is clicked the text edit has the focus, thus the conditional kicks in and prevents the update.

Indeed. Now that you've pointed that out and with a little reflection on that conditional, the solution turns out all the more simple, yay :-)

refresh simple editor when empty text, e.g. hitting ENTER

You’ll recall that the purpose of the conditional was to prevent the cursor/selection position being lost when the value for the text input is updated. So the fix would be to manually preserve the selection position across the update.

Gladly, such complexities doen't appear to be needed, at least not for now and not for the one usecase we've been trying to solve, i.e. to clear the input on "commit" as captured by the KeyboardWidget for the ENTER key, or any other.

@Jeremy: There's one thing I don't quite understand though: Assume CL does his thing as in the OP, enters some text, hits enter, Tiddler gets created. Shouldn't some event like switching some tabs, open or close a tiddler, etc..., trigger a refresh on that input, now that it no longer has focus? That doesn't appear to be the case, though.

Anyway, happy to see this resolved, after all, even before the next release.

Best wishes,

Tobias.

Jeremy Ruston

unread,
Jan 9, 2017, 5:38:33 AM1/9/17
to tiddl...@googlegroups.com
Hi Tobias

@Jeremy: There's one thing I don't quite understand though: Assume CL does his thing as in the OP, enters some text, hits enter, Tiddler gets created. Shouldn't switching some event like switching some tabs, etc...  trigger a refresh on that input, now that it no longer has focus? That doesn't appear to be the case, though.

Although switching tabs will trigger a refresh, the list of changed tiddlers will not include the state tiddler to which the edit widget is bound, and so the widget won’t refresh. Modifying $:/state/tiddler itself will trigger a refresh as expected.

Best wishes

Jeremy



Anyway, happy to see this resolved, after all, even before the next release.

Best wishes,

Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

Tobias Beer

unread,
Jan 9, 2017, 7:24:22 AM1/9/17
to tiddl...@googlegroups.com
@Jeremy,
 
Although switching tabs will trigger a refresh, the list of changed tiddlers will not include the state tiddler to which the edit widget is bound, and so the widget won’t refresh. Modifying $:/state/tiddler itself will trigger a refresh as expected.

Perhaps the edit-text widget as it is preventing a potential refresh to not lose the caret position could store the state title back to the "queue of touched tiddlers" so that once the preventing conditions are gone, i.e. the edit-text widget no longer has focus, the widget updates accordingly on the next refresh cycle, while repeatedly putting the title back to the queue under preventative conditions. A bit like a "deferred refresh".

Best wishes,

Tobias.

Jeremy Ruston

unread,
Jan 9, 2017, 7:27:05 AM1/9/17
to tiddl...@googlegroups.com
Hi Tobias
Perhaps the edit-text widget as it is preventing a potential refresh to not lose the caret position could store the state title back to the "queue of touched tiddlers" so that once the preventing conditions are gone, i.e. the edit-text widget no longer has focus, the widget updates accordingly on the next refresh cycle, while repeatedly putting the title back to the queue under preventative conditions.

I think that that may be more complex than just preserving the selection/cursor position.

Best wishes

Jeremy



Best wishes,

Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

Tobias Beer

unread,
Jan 9, 2017, 8:35:11 AM1/9/17
to TiddlyWiki
Hi Jeremy,
 
I think that that may be more complex than just preserving the selection/cursor position.

Not sure what you may be referring to.

Asked differently: Is it possible to push the state title back into the "touched tiddlers" without that immediately triggering another refresh cycle as a result of it?

Only for the simple editor, if focus is what preserves selection/cursor over a refresh cycle, then a loss of focus could / should be what gives it away ...for potential refreshing.

Best wishes,

Tobias. 

Jeremy Ruston

unread,
Jan 9, 2017, 10:04:12 AM1/9/17
to tiddl...@googlegroups.com
Hi Tobias

Asked differently: Is it possible to push the state title back into the "touched tiddlers" without that immediately triggering another refresh cycle as a result of it?

Yes; modifying a tiddler adds the tiddler title to an accumulated list of changes, but the change event (and hence the refresh cycle) is asynchronous, triggered by window.setTimeout() or process.nextTick()

I think that that may be more complex than just preserving the selection/cursor position.
Not sure what you may be referring to.

The original problem here can be fixed by updating SimpleEngine.prototype.setText() (and variants) to preserve the selection position during the update. That’s a fairly simple, Google-able problem.

That approach fixes all the problems we’ve discussed without needing to do anything tricksy with the refresh mechanism.

Best wishes

Jeremy.




Best wishes,

Tobias. 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

Tobias Beer

unread,
Jan 9, 2017, 1:35:40 PM1/9/17
to TiddlyWiki
Hi Jeremy,
 
The original problem here can be fixed by updating SimpleEngine.prototype.setText() (and variants) to preserve the selection position during the update. That’s a fairly simple, Google-able problem.

That approach fixes all the problems we’ve discussed without needing to do anything tricksy with the refresh mechanism.


Not sure if / when we'll ever need a more sophisticated handling like that for the simple editor. So, I'd probably wait for someone calling for it.

Best wishes,

Tobias.

Jeremy Ruston

unread,
Jan 9, 2017, 2:04:32 PM1/9/17
to tiddl...@googlegroups.com
The original problem here can be fixed by updating SimpleEngine.prototype.setText() (and variants) to preserve the selection position during the update. That’s a fairly simple, Google-able problem.

That approach fixes all the problems we’ve discussed without needing to do anything tricksy with the refresh mechanism.


Not sure if / when we'll ever need a more sophisticated handling like that for the simple editor. So, I'd probably wait for someone calling for it.

It’s a general problem with the combination of the keyboard widget triggering changes to a tiddler field bound to a text editor widget while it has the focus. I’d be very happy to see it fixed; you’ll recall your initial befuddlement when you encountered the code, and it would be nice to spare future generations of developers that experience :)

Best wishes

Jeremy


Best wishes,

Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
Reply all
Reply to author
Forward
0 new messages