š Bug Fix
- Lists /
enter: 'br'mode: converting a list type (ul ā ol, or applying a class/style that forces the REPLACE path) destroyed the list āunwrapListextracted thelicontent into aDocumentFragmentthat was dissolved on insertion, sowrapListreceived an empty detached node and the new<ol>/<ul>was never inserted into the document; the content was left as bare inline nodes. In the REPLACE path thelinow stays in the document and is re-wrapped directly. - commitStyle / attributes: a
number/booleanattribute value (e.g.commitStyle({ element: 'a', attributes: { tabindex: 2 } })) could never be toggled off ā theattr()getter returns a string, so the strict comparison against the raw value always failed and every re-apply took the CHANGE branch instead of UNSET. The value is normalized to a string before comparison now. - Selection:
cursorInTheEdge()(and itscursorOnTheLeft/cursorOnTheRightwrappers) threwIndexSizeErrorwhen the document had no selection ranges āgetRangeAt(0)was called without checkingrangeCount. It returnsnullnow, as documented. - Selection:
eachSelection()threwTypeErrorwhen the selection root was an empty editor (childNodes[-1]produced anundefinedstart node). - Dom.isFragment: fragments belonging to an inert document (
template.content,DOMParseroutput) were not recognized because of a staledefaultViewrequirement ā same class of problem already fixed forDom.isElementearlier. - Dom.between: when
endwas an ancestor ofstart, the ascent skipped over it and the callback kept firing for nodes far outside the intended range, up to the end of the tree. - Dom.replaceTemporaryFromString: the regular expression hardcoded the
data-jodit-tempattribute name instead of using theTEMP_ATTRconstant and did not match a temporary element whose marker attribute has no value (<span data-jodit-temp>). - LazyWalker: stopping a walk did not really cancel it ā
stop()calledcancelIdleCallbackwith an id that was never assigned (dead code left from the pre-scheduler.postTaskimplementation) and the scheduler'sAbortControllerwas never aborted. Also,setWork()called before the first chunk had started did not cancel the previously scheduled pass. RepeatedsetWork()calls (theclean-htmlplugin does this on every change) piled up concurrent loops pumping the same generator, defeating the chunked-walk throttling. The pending task is now aborted instop(). - LazyWalker: the
affectflag was not reset when a pass was interrupted viabreak(), so the next pass reportedend(affect = true)even if it had not changed anything (a falsesynchronizeValuestrigger forclean-html). It also processedtimeoutChunkSize + 1nodes per chunk instead of the configured size.
š Internal
- Dom: the
Dom.replace(elm, 'p')overload without acreateinstance is removed from the type surface ā it always failed at runtime on an assertion (Need create instance for new tag);createis now required whenever the replacement is defined by a tag name or an HTML string.Dom.isListis honestly typed asHTMLUListElement | HTMLOListElement,Dom.isCommentacceptsNullable<Node>,isSameAttributesno longer pretends to be a type predicate,CommitStyle.isAppliedreturns a real boolean. - Dom:
nextGenbuilds its sibling stack withpush+reverseinstead ofunshiftin a loop (was O(n²) on wide sibling lists);isTagcomputes the upper-case tag name lazily; the temporary-element regexp is compiled once at the module level. - Docs: fixed the misleading/inverted JSDoc for
Dom.between,Dom.up(root-check asymmetry),Dom.safeInsertNode,LazyWalkeroptions and events,cursorInTheEdgeOfString,isSuitElement(strictStyledescription was inverted), theLazyWalkerexample in the DOM module README (options object, not a number), and theDom.replaceexample (missingcreateargument). - Tests: new coverage for
Dom.between,Dom.isFragment(inert documents),Dom.replace,Dom.replaceTemporaryFromString, wide sibling traversal order inDom.find,LazyWalkerrestart/affect-flag reset,cursorInTheEdgewithout a selection,eachSelectionon an empty editor,ul ā olconversion inenter: 'br'mode, and toggling a numeric attribute viacommitStyle. - Tests / hermetic images: the resize, image-editor and image-properties karma tests that wait for a real image load no longer fetch
https://xdsoft.net/jodit/files/artio.jpg/th.jpgfrom the live server ā they use the byte-identicaltests/artio.jpgalready served by karma, so a slow or unreachable xdsoft.net can't time these tests out anymore (~17 tests were flaking on degraded networks). TheonLoadImagetest helper now also rejects with a clearfailed to load "<src>"message on an imageerrorevent instead of hanging until the mocha timeout.