|
|
I was able to narrow it down further, it relates to the following lines in backend.js var editorContext = $editor.data( 'summernote' ); editorContext.invoke( 'codeview.activate' ); editorContext.invoke( 'codeview.deactivate' ); it seems that codeview.activate is the reason for focusing the editor pane. |
|
|
It is reproducible with summernote 0.8.16 as well. Feel free to fork my codepen at https://codepen.io/matths/pen/jOPwJxq |
|
|
History doesn't help much. I guess, we can't do without the line as it relates to fixing image urls as stated by the commit message. https://github.com/OXID-eSales/ddoe-wysiwyg-editor-module/commit/e0661ef4e689ee4e5062a00fa2311c4a15800953 https://github.com/OXID-eSales/ddoe-wysiwyg-editor-module/commit/c71d555c4be849cd4bca9f1ce89155e8949f295d Bildschirmfoto 2020-03-03 um 09.47.54.JPG (187,680 bytes) |
|
|
I have reproduced that. But I could never be fast enough (in normal usage) to write in the form before summernote is loaded. How could that be a problem? -MF |
|
|
Are you serious about closing the issue, even when you were able to reproduce? IMHO I think "works on my machine" or "works on my network condition" can't be an argument. The problem was reported by our customer, who hits this quite often in his usual workflow when working with articles in the OXID admin panel. I would appreciate some support here. -MD |
|
|
To acknowledge the bug I need to reproduce the bad effect too. So do you say it only exists on slow connections? |
|
|
No, it happens on regular connections. And it happens for my customer. And the bad effect is, that when he wants to quickly find and change an article, his text input is put into the long description WYSIWYG editor instead of the article search input field. I reproduced it with the OXID demoshop and I switched connection speed to "Fast 3G" (which is something quite usual in terms of network speed) so I could reproduce and record what I described earlier. AFAIK the reason are these two lines of code, which were added to "Fix full image url in text widget": editorContext.invoke( 'codeview.activate' ); editorContext.invoke( 'codeview.deactivate' ); I think, a real fix would be to put the correct image urls in the widget in the first place and not to have unnecessary Javascript calls do that for you. Both commands to activate or deactivate the codeview are setting the focus away from where it is. So I could fix it by manipulating backend.js and/or summernote.js by myself. But that would not be update safe. I think a real fix would consider to remove the two lines, mentioned above. Br, Matthias |
|
|
I think, we have a simple workarround only for the backend article page. Just test it on your own risk. Place: ddoe\wysiwyg\out\src\js\backend.min.js http://downloads.foxido.de/backend.min.zip |
- Anonymous
