Opened 4 years ago

Closed 4 years ago

#12735 closed Bug (fixed)

Config.fillEmptyBlocks should only apply when outputting data

Reported by: Stan Owned by: Marek Lewandowski
Priority: Normal Milestone: CKEditor 4.4.7
Component: General Version: 4.0
Keywords: Cc:

Description (last modified by Piotrek Koszuliński)

Original TC:

In CK 4.4.5 everything is fine. After upgrade to 4.4.6 in chrome is problem cursor focus in empty content. Cursor is no-where, no blinking, nothing. I can write content and after that cursor is showing. Problem is in all last versions of Chrome: dev, beta, normal, Canary. Problem is not in FF,IE,O.

Real problem:

See comment:7.

Change History (14)

comment:1 Changed 4 years ago by Piotrek Koszuliński

Status: newpending

Could you describe the steps required to reproduce the problem? We changed fragments of code related to the behaviour described by you, but I can't reproduce the problem. When I focus an empty editor using tab key or by clicking, everything is fine.

comment:2 Changed 4 years ago by Jakub Ś

Version: 4.4.6

I have also tried it in Chrome on windows 7 but whether I was clicking or focusing editor with Tab key, the cursor was always blinking in content area.

comment:3 Changed 4 years ago by Stan

This is problem in config: config.fillEmptyBlocks = false;

comment:4 Changed 4 years ago by Piotrek Koszuliński

I don't underastand how it is realted. The fillEmptyBlocks option affect the data (the output of editor), not the HTML inside it.

comment:5 Changed 4 years ago by Stan

I dont understand too. Test it. I disabled this option in config and it works as before. I tested on clean source only with this config option. Thats all.

comment:6 Changed 4 years ago by bunny.hu

I have a same problem, and yes, remove the "fillEmptyBlocks" is solve this problem, but I need that option so please solve this problem! Anyway another problem (with fillEmptyBlocks=false) when you select the area and no cursor but you start to typing the editor add an unwanted empty line and paragraph like this ( I am typing only the "teszt" word:

<p>teszt</p>

<p></p>

comment:7 Changed 4 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.4.7
Status: pendingconfirmed
Version: 4.0 Beta

I'm shocked, but this bug exists since 4.0 (most likely pre-beta).

TC:

  • Set config.fillEmptyBlocks to false.
  • Load <p>x</p><p></p><p>y</p> into the editor.

Result:

  • Expected: The middle paragraph is visible (has a non-zero hight),
  • Actual: The middle paragraph is invisible (because it's totally empty).

This bug is more visible since 4.4.6, because now the empty block isn't filled with a bogus <br> by the fixBlock() function in editable.js. The assumption now is that empty blocks always contain bogus <br>s after data is loaded and that's how irt works when config.fillEmptyBlock is true.

I'm so surprised that I must double check this with someone else. But if I'm right, then we'll fix this is 4.4.7. The expected behaviour for me is that fillEmptyBlocks affects only output data (only getData() and not setData()). That's how it worked in CKEditor 3.x.

Last edited 4 years ago by Piotrek Koszuliński (previous) (diff)

comment:8 Changed 4 years ago by Jakub Ś

Version: 4.0 Beta4.0

Problem can be reproduced from CKEditor 4.0 (works fine in 4.0 beta and CKE 3.x ). I can't confirm that this issue is specific only to CHrome. With @Reinmar TC I was able to reproduce it in every browser.

comment:9 Changed 4 years ago by Piotrek Koszuliński

Description: modified (diff)
Summary: Content focus problem in ChromeConfig.fillEmptyBlocks should only apply when outputting data

comment:10 Changed 4 years ago by Piotrek Koszuliński

Description: modified (diff)

comment:11 Changed 4 years ago by Marek Lewandowski

Owner: set to Marek Lewandowski
Status: confirmedassigned

comment:12 Changed 4 years ago by Marek Lewandowski

Status: assignedreview

Pushed to t/12735 at dev.

comment:13 Changed 4 years ago by Piotrek Koszuliński

Status: reviewreview_passed

I moved the manual test from design tests to ticket tests. It makes more sense there, because it checks something that htmlDP wasn't designed to do.

comment:14 Changed 4 years ago by Piotrek Koszuliński

Resolution: fixed
Status: review_passedclosed

Fixed on master with git:3f0ab19.

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy