-
Notifications
You must be signed in to change notification settings - Fork 6
Image resizer now cleans view after resize is committed/cancelled #122
Conversation
…gering options.onCommit.
…riginal view value.
Co-Authored-By: Aleksander Nowodzinski <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've found one UX issue - it flickers (dunno if related to this issue).
src/widgetresize/resizer.js
Outdated
this._cleanup(); | ||
this._options.onCommit( newValue ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we need to comment on this? Why it is better to commit after cleanup? It looks like it is better to cleanup the view before making changes to it from the model change. Is that it?
|
||
const editingView = this._options.editor.editing.view; | ||
|
||
editingView.change( writer => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this is the reason of:
Found on Firefox but also visible on Chrome: after ending resizing the image border of the original size flickers. It happens on every drag (not GIF drops some frames and is not always visible).
What I can think of is a single commit block (if doable) - i.e. wrapping clean-up and commit in a single view change block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is probably because things are done in two batches and the browser gets a chance to re-pain in between. I don't know how to address this unless I spend some serious time digging into the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doh 🤦 @jodator is right. I was a little overconfident with the change and did it only by writing unit test and making a fix. Without realizing there might be some rendering artifacts 😃 Fixed.
Co-Authored-By: Maciej <[email protected]>
Co-Authored-By: Maciej <[email protected]>
@ckeditor/qa-team Guys can I ask you to double check this little change whether there are no visible regressions vs |
Tests are passing locally for me, 100% CC. Don't know what's up with the CI. @jodator can you confirm? |
@mlewand I can confirm that the test don't work 😜. Merged with master to fix ;) Could you also add a test to ensure that this change is executed in one |
Tested in all browsers, looks good. |
This is a pretty simple test to write, AFAICT. You just need to listen to the As far as I can see from your discussion, this PR proposed an incomplete (buggy) fix, so we should definitely have a test for this scenario. If the mistake could have been done once it can easily be repeated. |
As requested in #122 (comment).
Added the test, I referenced the proper comment to give at least some clarity for a person that faces it in the future. |
I think that this should be a separate test as we're testing for the number of renders. Also, why 3? That's an odd number. I'll fix these issues. |
BTW, when I started digging into this, it turned out that this render count check passes before the issue that it was supposed to cover was fixed. When adding a test, you should verify that it's failing without the thing that you test (like in TDD, but to me it can also be done afterwards). |
I forgot to push the fixed test before merging this PR 🤦. I pushed it to master: edd37d8 |
Suggested merge commit message (convention)
Fix: Image resize now cleans up temporary view
width
style changes. Closes ckeditor/ckeditor5#6060.Additional information
Reverting should be handled in
_cleanup
method as it guarantees it to happen whether resize process was committed or cancelled.