IB-536 update to latest2 #13
Conversation
Fix (ui): Users should be able to move the mouse cursor to a UI tooltip without closing it. Fix (ui): Users should be able to close UI tooltips using the Esc key.
…or#15981) Fix (watchdog): `EditorWatchdog` will no longer crash when the application is refreshed before completing the editor initialization or destruction. Closes ckeditor#15980.
…keditor#16103) Internal (ui): Force fully unpin tooltip before pin due to memory leak issues in tests.
Other (core): Clarified the description of keystrokes that execute various buttons (Space, Enter) in the accessibility help dialog.
Co-authored-by: Arkadiusz Filipczak <[email protected]>
Docs: info about editing external images. Closes cksource/ckeditor5-commercial#6092
…hould not obscure adjacent buttons. Closes ckeditor#16109.
Docs: adding multi-level docs.
…ist-command Internal (list): Introduced `customListNumbered` and `customListBulleted` commands for use in multi-level lists, with the ability to set additional attributes on command execution.
Other (html-support): GHS list integration will create proper model structure on upcast and not fire a redundant post-fixer during editor initialization. Closes ckeditor#16227.
Fix (engine): HTML Template elements are now properly handled in downcast and upcast conversion.
|
5000+ files? I think this is a record or something. |
| window.editor = editor; | ||
| } ) | ||
| .catch( error => { | ||
| console.error( 'There was a problem initializing the editor.', error ); |
There was a problem hiding this comment.
Can we make it like the one below, where there are no problems? :)
Please add some context to this error state. Why is it needed and why is this the best way to address it?
There was a problem hiding this comment.
It is a sample used for verifying that build has performed correctly. It was provided by CKEditor team or this logic was moved from old superbuild branch. It is not used anywhere in our app and do not influence the ckeditor build
| @@ -21,7 +21,7 @@ module.exports = { | |||
|
|
|||
| output: { | |||
| // The name under which the editor will be exported. | |||
| library: 'ClassicEditor', | |||
| library: 'CKEDITOR', | |||
There was a problem hiding this comment.
The package name is for the classic editor. Maybe ClassicCKEditor?
There was a problem hiding this comment.
This is how it was done in previous version (of our super build) and owr apps uses CKEDITOR name. I did it to maintain consistency. I agree that naming is not the most suitable. My suggestion is CKeditorInsperaBuild or InsperaCKEditor
| @@ -1,5 +1,5 @@ | |||
| { | |||
| "name": "@ckeditor/ckeditor5-build-classic", | |||
| "name": "ckeditor5-custom-build", | |||
There was a problem hiding this comment.
It is not me. It is done by whoever set up the ckeditor first. I just have to reintroduce this changes.
I am not happy this this approach either. How can reform CKEditor superbuild set up to the proper way? I mean forking CKEditor repo is overkill. The superbuild stuff should be done in another manner according CKEidtor docs - https://ckeditor.com/docs/ckeditor5/latest/installation/getting-started/quick-start-other.html#creating-custom-builds-with-online-builder
|
The error state needs some clearing up. |
|
This changes can lead to grading build fail. We need to resolve this first - https://assessment.slack.com/archives/CELTV2XBL/p1714639668496849 |
|
Only changes for upgrade ? |
|
Conflicts. |
resoved |
Too many changes are because latest master (CKEditor) is not merged to the ckeditor-super-build branch