Wysiwyg-editor: IE11 - Dropdown Selection Scrolls to top of Page

[JaxonWright]

Expected behavior.

No page scrolling is done and the selection is applied.

Actual behavior.

The page scrolls to the top unexpectedly.

Steps to reproduce the problem.

This is reproducible on the demo website for Froala

1. Scroll down the page so you are not at the very top
2. Make a toolbar selection that involves a drop-down (i.e Font Family)
3. Watch the page jump to the tippy top

Editor version.

v3.1.0

OS.

Windows 10

Browser.

Internet Explorer 11

[JaxonWright]

This appears to be related to the focus parameter of the dropdown. When I modified a custom dropdown to have focus: false, the problem goes away.

[JaxonWright]

I dug into the minified code and found where the focus event function is. It is named c in the code. I was able to fix the issue by returning !1 (AKA false) when I.browser.msie is true. See the context below with my added code.

javascript function c(e) { if (void 0 === e && (e = !0), !l.$wp) return !1; if (l.browser.msie) return !1; // THIS FIXES THE BUG if (l.helpers.isIOS() && l.$win.get(0).focus(), l.core.hasFocus()) return !1; if (!l.core.hasFocus() && e) { var t = l.$win.scrollTop(); if (l.browser.msie && l.$box && l.$box.css("position", "fixed"), l.browser.msie && l.$wp && l.$wp.css("overflow", "visible"), l.browser.msie && l.$sc && l.$sc.css("position", "fixed"), p(), l.el.focus(), l.events.trigger("focus"), f(), l.browser.msie && l.$sc && l.$sc.css("position", ""), l.browser.msie && l.$box && l.$box.css("position", ""), l.browser.msie && l.$wp && l.$wp.css("overflow", "auto"), t !== l.$win.scrollTop() && l.$win.scrollTop(t), !l.selection.info(l.el).atStart) return !1 } if (!l.core.hasFocus() || 0 < l.$el.find(".fr-marker").length) return !1; if (l.selection.info(l.el).atStart && l.selection.isCollapsed() && null !== l.html.defaultTag()) { var n = l.markers.insert(); if (n && !l.node.blockParent(n)) { i(n).remove(); var r = l.$el.find(l.html.blockTagsQuery()).get(0); r && (i(r).prepend(V.MARKERS), l.selection.restore()) } else n && i(n).remove() } }

Any thoughts @stefanneculai? I would make a PR, but you guys commit purely minified files which makes versioning and reviewing difficult.

[pashachek]

I dug into the minified code and found where the focus event function is. It is named c in the code. I was able to fix the issue by returning !1 (AKA false) when I.browser.msie is true. See the context below with my added code.

 function c(e) {
            if (void 0 === e && (e = !0), !l.$wp) return !1;
            if (l.browser.msie) return !1; // THIS FIXES THE BUG
            if (l.helpers.isIOS() && l.$win.get(0).focus(), l.core.hasFocus()) return !1;
            if (!l.core.hasFocus() && e) {
                var t = l.$win.scrollTop();
                if (l.browser.msie && l.$box && l.$box.css("position", "fixed"), l.browser.msie && l.$wp && l.$wp.css("overflow", "visible"), l.browser.msie && l.$sc && l.$sc.css("position", "fixed"), p(), l.el.focus(), l.events.trigger("focus"), f(), l.browser.msie && l.$sc && l.$sc.css("position", ""), l.browser.msie && l.$box && l.$box.css("position", ""), l.browser.msie && l.$wp && l.$wp.css("overflow", "auto"), t !== l.$win.scrollTop() && l.$win.scrollTop(t), !l.selection.info(l.el).atStart) return !1
            }
            if (!l.core.hasFocus() || 0 < l.$el.find(".fr-marker").length) return !1;
            if (l.selection.info(l.el).atStart && l.selection.isCollapsed() && null !== l.html.defaultTag()) {
                var n = l.markers.insert();
                if (n && !l.node.blockParent(n)) {
                    i(n).remove();
                    var r = l.$el.find(l.html.blockTagsQuery()).get(0);
                    r && (i(r).prepend(V.MARKERS), l.selection.restore())
                } else n && i(n).remove()
            }
        }

Any thoughts @stefanneculai? I would make a PR, but you guys commit purely minified files which makes versioning and reviewing difficult.

Thanks a lot!

[d3v1]

Hi @stefanneculai, are you making progress on a fix for this?

We're in the same boat as @JaxonWright, we've got several customers who are either exclusively on IE11 or mostly on IE11. Jumping to the top of the page on a very long form is not going to make customers very happy

Thanks for all your efforts on this product so far 😃

[dejanmartinovic]

@d3v1 @pashachek @JaxonWright The fix will be available in version 3.2.2 (should be released by the end of August)

[d3v1]

I ended up writing a workaround that saves the scroll position when various Froala events fire and then restores the scroll position after the browser scrolls to the top of the page.

Firstly, you need to save the scroll position when the below Froala events happen, they indicate interactions with the interface:

• focus (without an event being passed)
• blur
• command.before
• click

The second part is to force restore the scroll position. This has to be done when a Froala focus event fires that has an event passed to the focus event. It's a little confusing to say so check out the pseudo code below:

'focus': function(event) {

    if (this.$browserIsIE11()) {

        // an event being passed means that the user has clicked the interface or used the keyboard to interact with it
        if (typeof event !== 'undefined') {

             // below calls a function (you have to write) that saves the scroll position ready to restore it
             vueComponent.saveScrollPosition();

        } else { 
             // no event means this focus event is triggered by Froala when it has closed a drop down or similar
             // this is what triggers the bug in the Froala code that sends IE11 to the top of the page

             // below calls a function (you have to write) to restore the scroll position on the next tick
             // you must make sure you restore on the next tick to give Froala time to scroll to the top first
             vueComponent.restoreScrollPosition(); 

        }
    }

}

The restoreScrollPosition and saveScrollPosition methods need logic relating to your own projects. I haven't included the code for that reason.

Hopefully that might help someone if they need to implement a workaround

[JaxonWright]

This appears to be fixed in v3.2.2!