Issue with other elements asking focus?

[danieledraganti]

Hello everyone,
I have found another very weird bug, present in 1.0.0-alpha.3, but not on 0.11.1.
I will explain my template first:

1. I have a series of link-to elements, within an {{each}} cycle, and each link-to contains a content-editable, with its value linked to myVariable. Clicking on any link-to will render a template inside of a {{partial}} in this template.
2. In a component of one of the child templates I load inside of the {{partial}}, I trigger a $.('input').focus() during didInsertElement, so that the input will gain immediate focus whenever that specific component is rendered. This input is also bound to the same myVariable.

This is where the weird stuff happens: the first click on ANYWHERE on the page triggers the observer for myVariable on the input element. It's as if the input swallows any first event triggered on the page, letting pass only the subsequent ones (which work perfectly fine).
My first thought was that this was a bug on how Chrome and Safari handle the focus on a DOM element, since the bug did not present in Firefox or IE, but the funny thing is... I rolled back to 0.11.1 due to another critical bug in 1.0.0-alpha.3, and this behavior disappeared.

Honestly, I can't wrap my head around this, but I'm just posting it here in case anyone finds what the cause could be.

[st-h]

@danidr could you please provide a simple app which reproduces this or a failing test, that shows the issue? I am having quite some problems to follow your description.
However, I am having two thoughts:

• the situation of multiple elements trying to acquire focus sound like it will inevitably cause race conditions depending on which call to focus() is run first
• 1.0.0 of this addon does no longer make use of jquery. Maybe the jquery implementation of focus() pre-1.0.0 was using plays well with that race condition and therefore it luckily does not show up within your app which also seems to rely on jquery?

On question though: which critical bug in 1.0.0-alpha.3 are you referring to? The one you closed today regarding placeholders and null values in Edge, or is there something else you found?

[danieledraganti]

I will set up a simple, example app as soon as I have time. I know, the description wasn't too clear... code is actually a bit complex on that page, and it has a a few copyrighted parts I cannot really share as they are, sorry.

Yes, it was that one about the null values in Edge; it was critical for my use case at least, since unfortunately, for the kind of project it is, a lot of users rely on Edge/IE11.

[st-h]

@danidr will have a look once you have something ready.
However, maybe I haven't stressed this enough: If it really is the case that you are actually trying to have multiple elements that request focus, I can only suggest to refactor and avoid this altogether. You are inevitably relying on ember internals (the order in which elements will be added and initialized) and even a patch release could break your app.

[danieledraganti]

Yes, I understand and I agree; I have actually tried to focus the element on the didRender step of the Ember cycle, thinking that probably the content-editable was getting focus on click (which makes a whole lot of sense), but nothing changed. I'll try and refactor the code, working around the cycle to avoid this bug.
Thank you in the meanwhile!

[st-h]

@danidr one other thing though: Does this issue disappear when you disable autofocus on the contenteditable?

[danieledraganti]

I have literally just tried this a few minutes ago. Unfortunately, no, on latest 1.0.0-alpha.4, the bug isn't resolved even if I set autofocus=false on the element.
Looks like a weird situation... I'll see if it resolves when I'll pass to ember-elsewhere instead of using the render helper for compatibility with 3.0.

[st-h]

Closing, as this does not seem to be related to this addon as the issue persists with autofocus=false and there is no intention for this addon to support multiple elements asking for autofocus as this inevitably will result in unpredictable behaviour. Please provide a simple app which reproduces this issue and we will further investigate in case you think this is a bug with this addon.