st-h / ember-content-editable Goto Github PK

The addon is always loading a contentEditable as a

When pasting some text in the component I get:

Uncaught IndexSizeError: Failed to execute 'setStart' on 'Range': The offset 299 is larger than or equal to the node's length (53).handlePaste  

is it possible to stop the action from bubbling up on click.

In my scenario i have the whole element also clickable for another action as i am using this component within another component

I've been trying to set up an Acceptance Test with content-editable but am having issues.

I'm sure this may be as easy as jQuery focus in, add text, focus out. But, just can't seem to get it working, so some example docs or tests would be great.

Thanks

After reaching the maxlength on firefox, the backspace button does not work

code is used as follows:

{{content-editable class="path-title-hover" value="test value" type="text" allowNewlines=false maxlength=100}}

check appropriate windows key

I think in the last version (v.3.x) there was unconsciously remove the event as argument for onEnter & onEscape.
In documentation there is still present (https://github.com/st-h/ember-content-editable#events)

In my application and also on the demo page, if you enter some text and then delete everything, the placeholder does not reappear, because the component contains a single br-tag, hence the :empty selector won't apply.

This is even the case if allowNewLines is set to false, which would make no difference in my case, cause i need new lines

Is there any possibility to change this? I would really appreciate such behaviour.

EDIT: This is a Firefox behaviour with contenteditable, but my point still remains: could we add something like a check if nothing else remains in the input except a br-tag, we remove this from the DOM?

Changing the @placeholder attribute during runtime empties the content-editable value, and the placeholder doesn't change.

When I was setting value="<p>Hello world!</p>", it doesn't show Hello world! in contenteditable, instead it shows <p>Hello world!</p>. I noticed it always render value with $.text() (refer to https://github.com/AddJam/ember-content-editable/blob/master/addon/components/content-editable.js#L79 )

Shouldn't it use $.html() to render when I set type=html?

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.

Hello,

In this pull request you added
-webkit-user-modify: read-write-plaintext-only;
to the [contenteditable] selector.

I think this is not correct because it may have a "false" value. We use TinyMCE which set's this property to false when you want the content to be read only and also on MDN there is a reference to the "false" option.
I think you should adjust the selector to only select elements that are truly editable.

When editing the value and pressing enter, you get a

As this addon is labeled unmaintained, are there any plans for the future? Were there any technical issues that lead to this decision? And lastly, is there any interest in transferring ownership? It's kind of sad to see this addon die.

Hi,

I've spotted another issue. Using this with attributes in my model, it works fine. However, my model has a hasMany relationship with some other data. Attempting to use it with that results in this error:

ember.debug.js:5523 DEPRECATION: A property of <ember-accounts@view:-outlet::ember499> was modified inside the didInsertElement hook. You should never change properties on components, services or models during didInsertElement because it causes significant performance degradation.
at _emberViewsViewsCore_view.default.extend.scheduleRevalidate (http://localhost:4200/assets/vendor.js:61168:34)

I've no idea why it should be handling this data differently? I've tried using {{input}} instead and that seems to work, so I'm assuming that the issue resides in this control, not in my code. I stand to be corrected though!

Hopefully, what I have is pretty easy to replicate... Here's my data ( I get this via a JSON API, but I'm assuming we'll have the same issue if it's done as a fixture):

{
"data": {
"id": 1,
"attributes": {
"created": "November, 01 2000 00:00:00",
"number": "A0011000001"
},
"type": "invoice",
"relationships": {
"details": {
"data": [
{
"id": 1,
"type": "invoice-detail"
}
]
},
"client": {
"data": {
"id": 14,
"type": "client"
}
},
"user": {
"data": {
"id": 2,
"type": "user"
}
}
}
},
"included": [
{
"id": 1,
"attributes": {
"amount": 3000,
"detail": "Stage 1 delivery of 3Com Reseller Locator to\r\nFoundation Network LTD",
"vat": 525
},
"type": "invoice-detail"
}
]
}

And here's some simplified code:

{{content-editable value=model.number isText=true}}

{{#each model.details as |detai|}}
{{content-editable value=detail.amount isText=true}}
{{/each}}

The first content-editable works fine. Its the one accessing the model.details (which is in the "included" part of the data) that results in the warning.

I'll take a look myself at some point and let you know if I spot something.

I am stuck with this error by just adding the component to the page:

raw-editor.js:1011 Uncaught TypeError: this.textInsert is not a function
    at Class.<anonymous> (raw-editor.js:1011)
    at Array.forEach (<anonymous>)
    at Class.<anonymous> (raw-editor.js:1007)
    at Generator.next (<anonymous>)
    at Class._resumeGenerator (-task-instance.js:536)
    at Class._handleResolvedContinueValue (-task-instance.js:692)
    at Class._proceed (-task-instance.js:656)
    at invoke (backburner.js:337)
    at Queue.flush (backburner.js:226)
    at DeferredActionQueues.flush (backburner.js:423)

The template is just:

<ContentEditable
  @value={{context}}
  @allowNewlines = false
  class="text-gray-600 text-sm break-all"
/>

I am on Chrome.

The placeholder color should not be modified as it is too hard to override in app.css.

Preferably it should be provided as a property that can be set with a default value of #cccccc.

[contenteditable=true]:empty:not(:focus):before {
  content: attr(placeholder);
  color: rgba(0,0,0,0.6);//remove this line or use attr(watermarkcolor)
}

By not specifying it, I can override it more easily in app.css

.ember-content-editable:empty {
  color: #cccccc;
}

Hello, it's me again, your nightmare.
So, I am implementing a page with the following code:
{{content-editable value=(get object key) focus-out=(action (mut (get object key)) value='value')}}
According to the latest standards for Ember helpers, setting value = (get object key) should be one-way, and the value should be passed back upon editing only if set with the mut helper (value=(mut (get object key))).
Instead, editing the content-editable content automatically updates also the variable on the parent component set through value, breaking the DDAU paradigm.
My workaround is wrapping the (get object key) in a concat helper which joins strings, effectively making it a computed variable and therefore not updatable upon editing; but it is quite an ugly hack.
Any reason why content-editable behaves this way?
Thanks,

Daniel

Continuously pasting the content till reach the limit , once we reached the limit "Undo" Ctr+Z it will exceed the limit. :(

i am trying to insert value with my custom tag but it doesnt work
{{content-editable value=message placeholder=(t 'placeholder.input.message') tagName="span" enter='doSend' type="html"}}

if I have something like
{{#each myArray as |element|}}
{{content-editable value=element}}
{{/each}}

It does not seem to be binding the value. Can anyone help?

When the bound model changes, it is not reflected in this component. It needs something like this to behave consistent with other components:

itemChanged: function() {
try {
this.$().html(this.get('value'));
} catch(err){}
}.observes('value'),

We should support as much of what {{input}} supports as is possible & reasonable - things that you'd expect when using the component.

• maxlength
• type="number" *
• disabled
• readonly
• autofocus
• tabindex
• spellcheck

Some of this might already be supported, some of it might not be feasible depending on how browsers behave. Needs to be tested.

• I don't think other types outside of number/text are applicable?

handlePaste is called to check against max length.
It would be handy to an action key-paste event triggered.

Same for the input event.

Atm ember-content-editable has as dependency "ember-source": "^4.0.0"

It would be greate to add ember-source v5, otherwise there is not possible to use this addon with ember v5

"peerDependencies": {
    "ember-source": "^4.0.0 || >= 5.0.0"
  },

If you need any help, just tell me, so i will add a PR

Hi,

How do you detect keypresses for escape and enter to end editing and either save or cancel the changes? I am new to Ember so I might just not know how to do it... If not possible, I would like to request it as a feature.

tried escape-press='alertUser' without success.

Thanks!

This is a great little control!

I have one request. Could you add a new function, much like stringInterpolator which filters what the user types in? eg. If I want a numeric value only, I can use stringInterpolator to strip out non-numeric characters, and only the numbers gets saved back to the model, but anything else I type in stays on the screen. This new function should update the visible content rather than what is sent to the model. I guess you'd then still execute the stringInterpolator function afterwards to further manipulate the input before saving back to the model...

Hello,
I have updated to Alpha 3 for a project I'm working on, but on Edge, instead of setting the placeholder in case the value is null, it will just show "null" as a content. Works fine on Safari and Chrome.
Will roll back to pre-1.0.0 since it I am on a release cycle.

Hello, I wonder if is possible to yield a content inside of the content editable, I want to use an element inside with the attribute "contenteditable="false", I would like to use like in this way:

<div class="a" contenteditable="true">
   <div class="b" contenteditable="false">
       <img src="url here">
   </div><br>
   text goes here
</div>

When editing an empty string value on FireFox (Mac), the height of the div collapses by about 70%. If you add text, it is normal size... then if you delete all the text, it is still fine. This issue was recreated with isText=true.

The css below fixes the issue. One day I will figure out how to do pull requests and start contributing that way, but for now, here is my fix. :)

.ember-content-editable:empty::after {
  content: "\0000a0";
}

Hello!

Thanks for making this! Really helps me to not have to write one of my own lol. Though I noticed that when setting disabled, the ember-content-editable class is still on the element and so the css class is still getting applied.

.ember-content-editable {
  cursor: text;
  -webkit-user-modify: read-write-plaintext-only;
}

Would possibly help to throw that into classNameBindings as contenteditable:ember-content-editable?

Update

I see that this relates to Issue #105 and PR #99 . Scoping the CSS would work better in this scenario! 👍

These styles will not works any more:

https://github.com/AddJam/ember-content-editable/blob/master/addon/styles/addon.css#L1-L4

Not sure why, but if you change [contenteditable=true] to .ember-content-editable or any other class name that user specified, placeholder will works again.

Steps to reproduce

1. Create a content-editable component styled with a non-default font (i.e. Georgia)
2. Type first half, press enter to make a line break, then type second half
3. Move the cursor to the beginning of second half and then press backspace so that first half second half is now on the same line.

Actual Result

4. first half is still using the Georgia font, but now second half is using the system default font.

If you inspect the markup, you can see what the browser does to the text. I won't explain it here.

Expected Result

4. first half and second half should both still be using the Georgia font.

Hi, so this issue was supposedly fixed in #109 but it seems that the input is still editable when @disabled={{true}}. What I think is happening is that the styles in ember-content-editable-modifier are still targeting .ember-content-editable instead of .ember-content-editable[contenteditable] so then -webkit-user-modify: read-write-plaintext-only; still gets applied.

Package version: 0.9.0
Summary:
I have a content-editable tag

{{content-editable value=article.domain
                       placeholder="Article Domain"
                       disabled=article.editableDisabled
                       enter='handleEnter'
                       escape-press='handleEsc'
                       type="text"
                       tagName="span"}}

When I am copying a paste with a website and putting this inside its coming with all the formatting as shown in the picture below {To show this issue, please look at topmost container. Rest of the content-editable tags are same}.

Though when I reload the page then this formatting is gone and its been displayed like a plain text in that field.

Just tried your add on, works great! I was wondering, would you consider to add editable as an alias for the contenteditable property?

I think this:

{{content-editable value=model.myValue editable=model.editMode}}

looks nicer than:

{{content-editable value=model.myValue contenteditable=model.editMode}}

On the bug I found, I was using a type='text' editable field and when I pasted data from an HTML (or doc with formatting) it was being persevered, instead of converting to text. Adding a maxlength=10000 fixed the conversion issue.

On the opposite issue though, if I have a type='html' and a maxlength the HTML is stripped in the editor field. Mostly putting this if someone else comes across it.

Was wondering if this project has been abandoned? I would like to modernize it and fix a few bugs, but was wondering if I did a PR if it would be accepted still? If not, I'd be happy to fork it.

When you press enter, the value does not match what is seen in the browser (value may not have the line feed where it is in the browser). Found this workaround to keep them in sync.

  updateValue: Ember.on('keyUp', function(event) {
    this.handleKeyUp(event);
    var v=this.stringInterpolator(this.$().text());
    this.set('value', v);
    this.$().html(v);
  }),

As already introduced in the readme, the 1.0.0 release will remove any currently deprecated apis. In addition to that I am considering removing the html support which is enabled by setting type to html. The reasons behind this are as following:

• according to the readme the main scope of this addon seems to be to provide a flexible alternative to an input field. (I am putting it this weird, as this has been what I expected from this addon when I started using it, and I just recently took over ownership over this addon)
• html support currently seems to contain several bugs that are not easily fixed
• it is not very clear what type html should actually be doing and what people expect and are actually using it for. By setting contenteditable on an element, there are quite a lot things that become possible to do. For instance it is possible to build a whole wysiwyg editor. I recently closed a few issues regarding html rendering because they either were too old and/or were not clear to me what the actual expectations were.
• personally I don't have a use case for the html feature nor do I currently have the time to support a feature which appears to be broken. Unless we can find somebody who is willing to put time and effort into fixing and probably help maintain that feature it looks like this feature will remain in a state where some things just unexpectedly fail or break, which will just cause frustration.

In the end, there are a lot of things that can be build by setting contenteditable on an element, which are rather hard to support by a very general addon. By putting a clear focus on being a flexible replacement for input and textarea elements I think we will be able to ship a much more stable addon, which works the way people are expecting it to work. I think anything that previously relied on the html type will find a much better place in dedicated addons than with one that tries to do it all.

Please raise your concerns, as I don't want to break this addon for a lot of people just because I wasn't able to think about that one use case that totally makes sense.

The component currently does not allow setting "dir" attribute, which would be useful for many rtl/ltr/bidi cases, especially since you can only set "auto" direction via this attribute.