View Issue Details

IDProjectCategoryView StatusLast Update
0007104WYSIWYG Editor + Media Gallerymodule WYSIWYG Editor + Media Gallery - subpublic2020-09-02 12:21
Status acknowledgedResolutionreopened 
Product Version2.2.0 
Target VersionFixed in Version 
Summary0007104: WYSIWYG Editor steals focus when initialized
DescriptionWhen an admin page is loaded, the WYSIWYG Editor is initialized using summernote.js and then steals the focus from previously selected input fields.
Steps To Reproduce- use e.g. Chrome developer tools network tab, set throttling to Slow 3G and disable cache.
- navigate to article main section or any other section that consists of a WYSIWYG editor
- while page is loading, set focus on a filter input field in the upper 'list' frame and enter some characters
- when the WYSIWYG is initialized it steals the focus to the lower 'edit' frame and if you type further, characters are put into the WYSIWYG instead of the former form field in den upper frame
Additional InformationWhen using summernote.js isolated and in its current version (0.8.16) instead of the version 0.8.8 used by ddoe-wysiwyg-editor-module there's an option focus: false that would stop this behaviour.
TagsNo tags attached.



2020-03-03 09:28

reporter   ~0013141

I was able to narrow it down further, it relates to the following lines in backend.js

                            var editorContext = $ 'summernote' );

                            editorContext.invoke( 'codeview.activate' );
                            editorContext.invoke( 'codeview.deactivate' );

it seems that codeview.activate is the reason for focusing the editor pane.


2020-03-03 09:32

reporter   ~0013142

It is reproducible with summernote 0.8.16 as well. Feel free to fork my codepen at


2020-03-03 09:51

reporter   ~0013143

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.


2020-03-03 13:35

administrator   ~0013144

Last edited: 2020-03-03 13:36

View 3 revisions

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?



2020-03-03 13:44

reporter   ~0013145

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.



2020-03-03 13:56

administrator   ~0013146

Last edited: 2020-03-03 14:11

View 3 revisions

To acknowledge the bug I need to reproduce the bad effect too. So do you say it only exists on slow connections?


2020-03-04 17:11


screenrecorded.gif (439,825 bytes)


2020-03-04 17:11

reporter   ~0013147

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

2020-09-02 12:21

reporter   ~0013283

Last edited: 2020-09-02 12:21

View 2 revisions

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