focus on <input> cursor position differs between server rendered and client rendered about universal HOT 13 CLOSED

I did some tests about the second point you mentioned (angular not saving the cursor position).
Removing the biding of [value] (I know this is not a solution), but doing so seems to fix this specific issue. However, the initial value of value is obviously not bound...

<input value="testing" autofocus value="value" (keyup)="value = $event.target.value">
                                 ^^^^^^^^^^^^

I will continue digging...

from universal.

this might be a browser thing

from universal.

We should change preboot.js to also store the caret position using input.selectionStart = input.selectionEnd = <caretPosition>.

from universal.

@jeffwhelpley what do you think?

from universal.

I was thinking of suggesting something like this:

// in event_manager.ts@addEventListeners()

// ...
state.eventListeners.push({
      node: node,
      name: eventName,
      handler: handler,
      selection: getCursorPosition(preboot, node)  //<--- capture the carret position
});
//...

May the state.eventListeners array is not the place where to store the caret information, but I thought that when replaying events of a certain Node, we could replay the selection record as well.

Here is a generic solution for getting the caret position, found on SO...

export function getCursorPosition(preboot: PrebootRef, node: Element) {
  var iCaretPos = 0;

  // IE Support
  if (preboot.dom.state.document.selection) {

    // Set focus on the element
    node.focus();

    // To get cursor position, get empty selection range
    var oSel = preboot.dom.state.document.selection.createRange ();

    // Move selection start to 0 position
    oSel.moveStart ('character', -node.value.length);

    // The caret position is selection length
    iCaretPos = oSel.text.length;
  }

  // Firefox support
  else if (node.selectionStart || node.selectionStart == '0')
    iCaretPos = +node.selectionStart;

  // Return results
  return (iCaretPos);
}

from universal.

Thanks, @manekinekko for the tip. I am trying out some changes now to preboot that will use a version of this code. I am putting the code for getting caret position and setting caret position in the dom wrapper since there is some browser specific hackery going on there. As a general rule, FYI, the dom wrapper should be used to abstract out any and all browser hackery (sort of like a mini-jQuery). I will try to have something checked in later tonight or tomorrow morning.

from universal.

Awesome! thanks @jeffwhelpley

from universal.

hi @jeffwhelpley I grabbed your PR and tested it locally. Here what I experienced...

My tests were:

• TEST1: I do a select all before preboot completes.
• TEST2: I move the cursor to a specific position.
• TEST3: I insert few letters at an arbitrary position.

FYI, I reloaded the page between each test and my network is set at 3G (in devtools)

(I joined a GIF to this comment, wait for it ==> 1Mo ^^)

from universal.

@manekinekko what browser are you using?

one thing I know has to change is that I am not changing the stored cursor position based on mouse movements. I can fix that, but I want to make sure I cover everything else. If you don't change the cursor with your mouse is there still an issue in whatever browser you are using?

from universal.

For the GIF above, I am using Chrome 44.0.2403.130 and Yes, I can tell you that when I move the cursor using the arrow keys, preboot remembers as expected the cursor position, in Chrome at least!

However, Safari and Firefox (nightly) have different behaviours...

Safari 8.0.8 (10600.8.7)

On page load, and before preboot completes, Safari selects all input content. Perhaps because of the focus event!

FireFox nightly 42.0a1 (2015-08-11):

Firefox (nightly) completely looses focus when preboot completes.

Sorry, I dont have a Windows machine in order to test IE.

from universal.

Interesting. OK, I will figure out what is going on with FireFox and Safari as well as the mouse events. We can worry about IE after that.

from universal.

I just updated my PR with changes that include selection of text. I have validated this works on modern Chrome, Safari and FireFox browsers. I wasn't quite sure how to test this on IE so I am hoping someone here has a Windows machine and can try this out.

from universal.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

from universal.