Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shift+Enter inserts a <br> even though ShiftEnter plugin is disabled #1120

Closed
jodator opened this issue Jun 29, 2018 · 5 comments
Closed

Shift+Enter inserts a <br> even though ShiftEnter plugin is disabled #1120

jodator opened this issue Jun 29, 2018 · 5 comments
Assignees
Labels
package:enter type:bug This issue reports a buggy (incorrect) behavior.
Milestone

Comments

@jodator
Copy link
Contributor

jodator commented Jun 29, 2018

Is this a bug report or feature request? (choose one)

🐞 Bug report

💻 Version of CKEditor

latest master, Chrome

📋 Steps to reproduce

  1. I've only reproduced it on image plugin manual tests (caption namely)
  2. Go to the end of
    • paragraph
    • caption
  3. Press shift+enter.

✅ Expected result

Either nothing happens either <br> element is inserted.

❎ Actual result

There are two <br>s inserted. Consecutive shift+enter

📃 Other details that might be useful

You cannot place selection there, after typing the <br>s are removed.

screencast 2018-06-29 14_59_54

@Reinmar
Copy link
Member

Reinmar commented Jun 29, 2018

That's because all the manual tests in this package load only Enter without ShiftEnter.

However, it's strange that <br> isn't filtered out. If ShiftEnter is not loaded, it should be dropped completely. Shift+Enter should not change anything.

@Reinmar Reinmar changed the title Two <br>s are inserted at the end of paragraph/caption in some configuration. Shift+Enter inserts a <br> even though ShiftEnter plugin is disabled Jun 29, 2018
@Reinmar Reinmar added type:bug This issue reports a buggy (incorrect) behavior. status:confirmed labels Jun 29, 2018
@Reinmar Reinmar added this to the next milestone Jun 29, 2018
@Reinmar
Copy link
Member

Reinmar commented Jun 29, 2018

There seem to be at least two bugs.

Enter must always be handled

The native action Enter must always be prevented, even when just one of the plugins is loaded. However, now, both plugins abort their listeners if Shift is/isn't pressed. Instead, they should prevent the default action before aborting.

This is something I anticipated but ignored to not stale the initial implementation of ShiftEnter :D I hoped we won't see the bug report that soon.

And we wouldn't see it if for the second bug

Why isn't <br> removed from the DOM?

Browser may be doing a many DOM changes as it wants, but we are always re-rendering the DOM to match our view. In this case, the view is clean and contains text only. Then why does the DOM contain two <br>s?

My guess would be that we filter out mutations with bogus <br>s inside the MutationObserver because we treat them as insignificant. And this is true – they are insignificant (we do not represent bogus <br>s in the view). But we still have to re-render the modified element (in this case <figcaption>). It may be enough to call https://docs.ckeditor.com/ckeditor5/latest/api/module_engine_view_renderer-Renderer.html#function-markToSync.

@Reinmar
Copy link
Member

Reinmar commented Sep 4, 2018

Didn't we fix this?

@pomek
Copy link
Member

pomek commented Sep 4, 2018

PRs are still open :D

@Reinmar
Copy link
Member

Reinmar commented Sep 4, 2018

OMG... Sorry :D

Reinmar added a commit to ckeditor/ckeditor5-enter that referenced this issue Sep 4, 2018
Fix: Default action of `Enter` event should be always prevented. Closes ckeditor/ckeditor5#1120.
Reinmar added a commit to ckeditor/ckeditor5-image that referenced this issue Sep 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:enter type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

No branches or pull requests

3 participants