仅个人猜测，不喜勿喷
问题是这样的，我项目中的页面都是template 子页面的形式，以下简称webview,所有的webview都有设置preload属性；
如果我用webview打开一个第三方页面(如www.baidu.com)，然后按返回键，一切正常，因为template的backbutton事件被触发了，mui监听了该事件，并对webview进行了隐藏；
如果我再用这个webview打开一个我自己写的页面（包含mui.js）,然后按返回键，一切正常，因为子页面的backbutton事件被触发了，mui监听了该事件，并通过evalJS告诉了template，然后template中的mui对webview进行了隐藏；
接下来问题来了，我再用这个webview打开第三方页面,然后按返回键，nothing happen。。。。
之前有在论坛里提这个问题，但是得到想要的答复，所以就自己研究了一下
我猜大概是这样的
backbutton事件为系统级事件，只会被分发到一个webview，如果有多个webview通过plus.key对该事件进行了监听，按返回键时，也只有最顶层（猜测）的那一个webview能接收到事件；
所以当我第一次用webview打开www.baidu.com的时候，template为最顶层的那个webview(百度的界面没有监听backbutton事件)；
然后我再用这个webview打开自己的一个页面时，因为子页面加载了mui.js,所以子页面监听了backbutton事件，并成为了最顶层的那个webview，按返回键时，事件会被发到该子页面中；
最我再次加载www.baidu.com的时候，这个子页面依然是最顶层，依然监听了backbutton事件（该事件是通过plus,key绑定在webview上的，不会随之前的html销毁），所以按返回键时，事件依然被分发到了该子页面， 然而百度自然对这个事件不感兴趣，没加监听，所以什么都没发生
如果在加载新界面之前，把之前绑定的backbutton事件移除掉，就没问题了，但是要改mui的源码，因为绑定的那个事件是mui里的一个内部变量
官方看好不好从框架的层面上解决，好解决的话我就等一等，不好解决的话就改一改源码，locker.js也有兼容性问题，一直没修复好，每次更新后都要改几句代码，累啊！
- 发布：2015-07-31 00:06
- 更新：2016-11-18 09:58
- 阅读：2303
之前回复过你类似的问题，子webview的mui.init里边关闭掉backbutton的监听，不要让子webview监听backbutton
-
chender (作者)
亲，你说的意思我100%明白，我就是觉得你没太明白我的意思，才写了个详细点的帖子。。
我是同一个可复用的webview，要通过loadURL，打开各种各样的url，有些url里面是需要监听返回键的（比如要做一些逻辑后退），有些有些url是第三方url（比如google.com），然后就遇到了我所描述的问题2015-07-31 14:50
chender (作者) - 与人为善
我觉得官方应该在webview.clear()的时候，把通过plus.key绑定的事件从webview上完全清除掉，因为clear之后页面都没了，注册监听时的回调函数也早没了，那个监听还绑在webview上，不但占内存，还会导致我上面描述的那些问题；
回复 chender:
没看到你描述里有具体提到子页面需要监听back且处理逻辑
如果有这样的需求，在目前版本，有很多方案可以处理
1.还是之前的方案，子页面不监听，父页面监听，只不过在父页面的beforeback里，向子页面发送自定义事件，假设你的子页面监听了该事件，就说明有业务逻辑要处理。（该方案适用于业务逻辑不会阻止back，如果需要阻止back，那么不适用该方案）
2.第三方页面单独使用一个模板
3.子webview的mui.init时关闭backbutton，然后子webview.setJsFile(自己写个js文件监听back)，（仅setJsFile一次，多次loadURL都会生效）
-
chender (作者)
ok，thank you，我把第二种方案和第三种的思想方案结合了一下，因为区分模板的话管理起来会比较麻烦，然后去限制其他同事开发的子界面都关闭backbutton监听也不太好，所以就在webview loaded的时候通过evalJS注入一段代码，判断一下如果没有mui对象，就自己添加一个监听，监听backbutton事件
2015-07-31 22:38
chender (作者)
不是同一个问题
2015-07-31 09:33