Not a bug Pasting tabs into WYSIWYG editor

[digitalpoint]

Affected version

2.2.12

I feel like I can't possibly be the only one that runs into this, but I couldn't find an existing bug report...

Pasting code snippets (and more specifically tabs) is screwy when in WYSIWYG editor mode...

In BBCode mode (not WYSIWYG), it works as expected:

    /**
     * @param \DigitalPoint\Marketplace\Entity\Item $content
     */
    public function getBreadcrumbs(Entity $content)
    {
        /** @var \XF\Mvc\Router $router */
        $router = \XF::app()->container('router');

        $breadcrumbs = $content->Marketplace->getBreadcrumbs();
        $breadcrumbs[] = [
            'value' => $content->title,
            'href' => $router->buildLink('items', $content)
        ];
        return $breadcrumbs;
    }

The same editor box, but in WYSIWYG mode and it's this:

/**
 * @param \DigitalPoint\Marketplace\Entity\Item $content
 */
public function getBreadcrumbs(Entity $content)
{
/** @var \XF\Mvc\Router $router */
    $router = \XF::app()->container('router');

$breadcrumbs = $content->Marketplace->getBreadcrumbs();
 $breadcrumbs[] = [
'value' => $content->title,
'href' => $router->buildLink('items', $content)
    ];
return $breadcrumbs;
}

Froala always removes tabs and no option to disable that (not sure why, it's stupid if you ask me):



I dug a little further, and Froala requires the use of the paste.beforeCleanup event to convert tabs to spaces (Froala always removes tabs). XenForo is using it to convert tabs to spaces, but it seems like it has issues with the logic of when to do it.

in editor.js (comments are my own):

            ed.events.on('paste.before', function(e)
            {
                isPlainPaste = false;

                if (e && e.clipboardData && e.clipboardData.getData)
                {
                    var types = '',
                        clipboard_types = e.clipboardData.types;
// at this point, clipboard_types = ["text/plain", "text/html", "text/rtf"]
                    if (ed.helpers.isArray(clipboard_types))
                    {
                        for (var i = 0 ; i < clipboard_types.length; i++)
                        {
                            types += clipboard_types[i] + ';';
                        }
                    }
                    else
                    {
                        types = clipboard_types;
                    }

                    if (
                        /text\/plain/.test(types) && !ed.browser.mozilla
                        && !/text\/html/.test(types)
                        && (!/text\/rtf/.test(types) || !ed.browser.safari)
                    )
                    {
                        isPlainPaste = true;
                    }
// now isPlainPaste = false;
                }
            });

			ed.events.on('paste.beforeCleanup', function(content)
			{
// not going to do it because isPlainPaste = false;
				if (isPlainPaste)
				{
					content = content
						.replace(/\t/g, '    ')
						.replace(/  /g, '&nbsp; ')
						.replace(/  /g, '&nbsp; ')
						.replace(/> /g, '>&nbsp;');
				}
// .......
			}

This was with Chrome/Mac. Wouldn't it make sense to always convert tab to spaces since Froala always removes tabs rather than only when it thinks it's plain text and no other types are available?

 

[digitalpoint]

Actually... cancel all this. lol After wondering how Froala's sample editor took on the exact styling from PhpStorm, I realized PhpStorm was giving an html version to the clipboard that has no tabs. My life just got so much better when I disabled that in PhpStorm settings.

 

[Chris D]

Wait, so I noticed this for the first time today and I was pretending to ignore it because I didn't want to deal with it.

Has this changed recently because of this PhpStorm setting? Or has Froala changed something that has affected this?

I know pasting from PhpStorm used to work fine, anyway.

 

[Chris D]

Well, it was like this with XenForo 2.2.12 based on the demo I just spun up:

test

Paste from PhpStorm with Rich-text enabled: public function preDispatch($action, ParameterBag $params) { $this->checkCsrfIfNeeded($action, $params); $this->preDispatchType($action, $params); $this->app->fire('controller_pre_dispatch', [$this, $action, $params], $this->rootClass); }

de79d25aebaf84e8.demo-xenforo.com

This was running Froala v4.0.14. We're now running Froala v4.0.18.

Which leads me to believe it was probably not a Froala issue and it may be a new thing in PhpStorm 2023?

Good to know, I'll keep that switched off then...

 

[digitalpoint]

Wait, so I noticed this for the first time today and I was pretending to ignore it because I didn't want to deal with it.

Has this changed recently because of this PhpStorm setting? Or has Froala changed something that has affected this?

I know pasting from PhpStorm used to work fine, anyway.

I don't think it's new in new version of Froala. It's always been a pain in my ass... and when I was testing it, it was on my own XF site with the older version of Froala and it's the same there). I just never bothered to go digging that much until today when I realized PhpStorm was giving an html version which is what Froala is dealing with. So maybe it's new in PhpStorm? I dunno... but it's been broken for a long time (at least a couple years) for me. Wish I found that PhpStorm option a long time ago...