TextEditingTool initial select query / change req

Hi - I am working on a notes-box pattern currently, using a custom text editor. All working well so far.

Problem: I notice that, at least in Chrome, when I click the textBlock to trigger editing, the entire string of existing text is highlighted in the textarea used as the editor - as if I had manually carried out a select-all action. This leads to multiple clicking as the user tries to figure out how to de-select and put the caret where they intended.

Research: Looking through the forums I found a case http://forum.nwoods.com/forum/forum_posts.asp?TID=6042 where this was mentioned obliquely - I just wanted to get your confirmation.

In that case, Walter says under the covers the editor is positioned then the following calls are made:

if (typeof input.focus === ‘function’) input.focus();
if (typeof input.select === ‘function’) input.select();

Therefore, if I want to stop my text being selected, I should do something like this:

var customText = document.getElementById(“id of html textarea”);

customText.select=function(e) { // eat the select() function for this element.
console.log(‘Select called’)

Is this what was meant at the end of the previous case ? It certainly works.

Question: Doesn’t overriding the default select() function in this way leave the textarea hobbled as far as any intended use of it’s select() function ? So we break the textarea as a workaround to the unwanted selection?

Change request: Please could you consider adding a parameter to the textEditing tool along the lines of textEditingTool.noStartupSelect which would have the effect of avoiding the call to input.select() at the start of an edit ? In this way the default behaviour of the textarea is retained.

Let me know if I got it wrong please.

I believe you are correct about the usage of the select function on the text editor. I do not know of any other callers of that function. If you are concerned, you could implement a flag to cause the call to be a no-op the first time.

Thanks for confirming.

Just before we get any further in to this, you may not know but default behaviour when a user selects a field in which text can be edited is NOT to select all the text. So gojs default behaviour is counter-intuitive, which I assume you would not have planned or encourage without a good reason.

Not sure what you mean by a no-op, can you expand a little or point to a sample ?

Did you mean I have to:

  • catch the start of the edit,
  • assign the customer select() function,
  • let the edit start,
  • de-assign the custom select() function
  • repeat per edit-enabled textBlock for now and evermore ?

Ok, I can do that, I’ll just develop a little library of such tricks…hang on that’s what I just paid you for ;-)

I disagree. If I recall correctly, the policy of automatically selecting all of the text when starting editing is called having a pending delete. It makes it easy for the user to delete everything and replace it with whatever they start typing. Or they can click the mouse or press any navigation key in order to remove the text selection and insert or delete individual characters.

When I click on the address box or search box in Firefox or Chrome or IE, that is exactly the behavior that I get.

Originally we did not have that pending delete behavior, but we added it due to demand.

Ok - happy to discuss and accept your perspective.

But I was curious based on your response. I built a small sample web form and 2 inputs here http://codepen.io/JEE42/pen/MYLGQQ which shows Chrome, IE, Safari and FF default is not ‘pending delete’.

The cited examples of browser address bars are not representative - they are special cases and as such exhibit targeted behaviour. We are talking about web forms inside the browser.

Some popular examples you might like to consider:

I think maybe the previous input was based on a specific use-case and did not consider the wider learned behaviour that web users hold.

That makes sense for entry fields, where there is normally no initial text.

But when there is already text that I want to modify, I much prefer having pending delete.

We’re considering adding an option for controlling that behavior.

Yeah - each to their own. I find that ‘pending delete’ behaviour a real pain in the browser address bars and don’t talk to me about the Spotify PC’s app search box!

That said, you have to look at what the users learned behaviour is and I believe on balance it is probably not pending delete.