自己做的邮件项目里面需要使用到富文本编辑器,邮件内容说白了就是HTML代码。前任使用的是wangEditor,部分定制化需求就是直接改的源码。
最近发现有的用户的邮件内容加进去的很多css信息,比如
为了做样式的隔离,所以我们查看邮件内容时使用了iframe,这样邮件内容的样式和我们邮件系统的样式不会发生相互影响。但是前任在新建、编辑邮件时没有使用iframe,当时就很纳闷,为什么没有使用呢?编辑邮件肯定也要进行样式隔离的啊,之前就有时会碰到个别邮件,在点击回复时,整个邮件系统的部分样式都受到了影响,我当时第一时间看了下wangEdtor的官网,没有发现这样的配置,可能需要修改源码,比较麻烦,再加上抽不出时间、出现频率极低,就扔在一边没有管了。最近有时间准备解决下这个问题,再次看了wangEdtor的官网,还是没有发现这样的配置项,估计是没有人有这样的需求,或者作者不知道有这样的需求吧,看来只能自己动手了改了。
由于之前有做翻译的经验,深知多了个iframe会有小麻烦,要处理好window、document,因为这个是分iframe的。
首先想到的就是直接将内容区域的节点从div改成iframe,再改动_initDom,在里面进行一些是否使用iframe的判断,
const textContainerDom = $(textSelector)[0];
const isIframe = Object.prototype.toString.call(textContainerDom) === '[object HTMLIFrameElement]';
if (isIframe) {
$textContainerElem = $(textContainerDom.contentDocument.body);
this.win = textContainerDom.contentWindow;
} else {
$textContainerElem = $(textSelector);
this.win = window;
}
上的this.win就是用来记录window的,如果使用了iframe的话,window自然应该是该iframe对应的contentWindow,相应的document的也需要变更。
于是我搜了下window和document,还是有点多了,这样即使做成功了,肯定觉得很low,并且维护性不好。
wangEditor源码改动
改动点一
为什么不直接改全局的window和document
先定义同名变量window和document分别等于默认的值,如果有iframe的话,直接使用contentWindow和contentDocument替换即可,想想都觉得很好,不是吗。
在最上面加入了一个方法fixContext。
(function (global, factory) {
typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
typeof define === 'function' && define.amd ? define(factory) :
(global.wangEditor = factory());
}(this, (function () { 'use strict';
let window = global;
let document = window.document;
function fixContext() {
if (global.$old) {
window = global.$old;
document = global.document;
} else {
global.$old = global
}
const iframe = document.querySelector('#editorIframe');
if (iframe) {
window = iframe.contentWindow;
document = iframe.contentDocument;
}
}
...
})));
改动点二
在_initDom的第一时间运行fixContext方法。
_initDom: function _initDom() {
var _this = this;
fixContext();
var toolbarSelector = this.toolbarSelector;
var $toolbarSelector = $(toolbarSelector);
...
}
自己感觉这样对源码的侵入性更小。
但是很快出现了这样的问题:
/> 1.Maximum call stack size exceeded。
2.TypeError: elem.appendChild is not a function
我很是纳闷,怎么可能呢,又没用写死循环。自己刚开始想难道是自己替换window和document的时机不对,或许个别地方的window和document不需要替换成iframe的呢。
决定自己一步一步打断点吧,发现问题出在initSelection
initSelection: function initSelection(newLine) {
var $textElem = this.$textElem;
var $children = $textElem.children();
if (!$children.length) {
// 如果编辑器区域无内容,添加一个空行,重新设置选区
$textElem.append($('
this.initSelection();
return;
}
var $last = $children.last();
if (newLine) {
// 新增一个空行
var html = $last.html().toLowerCase();
var nodeName = $last.getNodeName();
if (html !== '
' && html !== '
' || nodeName !== 'P') {
// 最后一个元素不是
$textElem.append($('
this.initSelection();
return;
}
}
this.selection.createRangeByElem($last, false, true);
this.selection.restoreSelection();
},
上面的!$children.length始终是null,导致了无限调用initSelection方法。
但是其实$children已经有新添加进去的子元素了,但是它的length却是空。经过打断点发现原来是源码的里面的querySelectorAll返回的“有误”导致。
function querySelectorAll(selector) {
var result = document.querySelectorAll(selector);
if (isDOMList(result)) {
return result;
} else {
return [result];
}
}
很显然,这里的document已经被我们替换iframe的contentDocument了,但是怎么还会有问题呢,其实返回的result没有问题,问题就出在isDOMList方法的判断上面。
function isDOMList(selector) {
if (!selector) {
return false;
}
if (selector instanceof HTMLCollection || selector instanceof NodeList) {
return true;
}
return false;
}
仔细排除发现,上面的document.querySelectorAll返回的明明是个NodeList,但是它并不是上面的NodeList的实例,所以上面的isDOMList还是会返回false。
就这样最终结果错误的返回了[result]而非result,也就是多了一层数组,而它并没有length,所以才引发了上面的死循环问题。
改动点三
可以简单粗暴的改成
if (selector instanceof HTMLCollection || selector instanceof NodeList || Object.prototype.toString.call(selector) === '[object HTMLCollection]' || Object.prototype.toString.call(selector) === '[object NodeList]') {
return true;
}
wangEditor的改动就此三处即可。
使用页面HTML结构变更
使用wangEdtior的页面建议进行如下改动
这样可以了。