西方人通常发现不了的一个IE的bug

这个问题我大概在一年多以前在某个用到VML的页面中（当时倒是记录了VML的一个严重问题）首次发现了这个Bug。经过一番狗狗之后，也未发现有同样的报告。后来我又逐渐在几种其他非VML的情形下重现了这个奇异的Bug。经过一番探究，我大致推断出了这个bug的原因。不过我一直没有公开发布过这个有趣的问题，只是跟少数同事提到过它。这个bug有个有趣的特点，就是西方人通常不会碰到这个bug。

最近，真懒同学（realazy）在《认识延迟时间为 0 的 setTimeout》一文中举例说明setTimeout的用途。代码大意如下：

$('myButton').onmousedown = function () {
  var input = document.createElement('input');
  input.type = 'text';
  $('myDiv').appendChild(input);
  input.focus();
}

在IE中，新创建的input没有如预期的获得焦点。

如果把input.focus()放在一个setTimeout中延时执行，则就可以获得焦点。

这个例子本身其实并不能证明realazy想要说明的观点，因为他不小心碰到了一个IE的微妙bug。在留言中，Lunatic Sun倒是敏锐的判断出这是IE的bug，只是这个bug的本质不是那么容易认识到，它其实并不是onmousedown本身的bug。

实际上，这是IE的focus机制的bug。

IE中的所有元素其实并不是被凭空绘制出来的，而是统统基于已有的Windows控件之上。除了典型的按钮、下拉菜单等，普通的div其实也是一个textbox控件。

所以IE的HTML focus等实际是被转换为windows控件的focus，于是在IE中存在两种不同层次的focus机制。理想上，HTML的focus应该被同步转换为windows控件的focus，然而IE可怜的代码导致这种转换存在许多bug。我们经常遇到的焦点虚线框丢失的问题其实就是一个例子。

实际上，在上面的例子中，表面上input没有得到焦点，但是其实调用focus()之后，HTML focus确实已经到了新生成的input中，这一点你可以通过document.activeElement来验证，你也可以按tab和shift-tab观察焦点的切换来证明这一点。然而，由于mousedown事件默认会获得控件焦点，所以windows控件focus就跑回了你的按钮上面了。这里出现了windows focus机制和html focus机制的脱节。显然IE在focus上的同步代码实在是太脆弱了。

事实上，IE对焦点的控制似乎本来就不和逻辑。所有的hasLayout元素都能获得焦点！结果一个页面上大部分区域在mousedown之后焦点就不知跑到哪个元素上了——这显然不是我们想要的行为——合乎HTML规范逻辑的行为应该是只有交互控件，如表单控件和A元素等，才能获得焦点。这导致一个典型的用户体验问题：在一个限制高度的可卷动区域中（例如一个长表单），拖动scrollbar，控件焦点就丢失——实际焦点跑到scrollbar所在的元素（例如form元素）上了。最严重的是，body元素一般总会有scrollbar！为了缓解这个问题，微软为body元素打了补丁，使得body上的scrollbar不会抢走焦点。然而IE这个patch打得实在是太烂了，在标准模式下，canvas从body变成了html元素，所以页面scrollbar就到了html元素上，结果bug又回来了！

撇开抢焦点问题，我们回到前面的话题。

既然html focus还是在input元素上，那么当时windows控件焦点到底跑哪里去了？实际上这个焦点跑到了mousedown所发生的对象上。比如如果是一个input按钮，焦点就会在该input按钮实际对应的windows的Button控件上。不过button元素的实现和一般的input不同，所以button元素上的mousedown之后，windows控件焦点实际上会跑到button元素外层的那个元素所对应的windows控件（通常是TextBox控件）中。

如何证明这一点？我过去用过一个调试工具可以显示出每个html控件实际的windows控件，也能查看实际的windows系统焦点。不过现在想不起来那个工具的名称了。搞笑的是，此处还会出现一个非常orz的症状——也就是本文标题所称的“西方人通常发现不了的一个IE的bug”——可以证明这一点。

focus问题 + 西方人通常发现不了。各位是否已经猜到了呢？大家不妨用realazy的那个页面中的第一个按钮来直接实验一把。

我会在下篇blog中继续聊这个话题。

评论

59 楼 tangshd 2008-10-24  

在以前开发的时候也遇到了同样的问题,
就是在一个弹窗页面中,用户回车后触发事件,但是获得的数据显示后,就像刷屏一样..立即消失了..
如果用户录入数据,然后用鼠标点击查询按钮是没有问题的..
最后把代码一步步的检查..就是没有发现问题.. 
最后无意中要对用户录入数据进行检查,数据不符合格式的,数据控件FOCUS后,上面的那个问题竟然解决了..
  
当时不知道原因,也就没有细究..看了楼主的深刻解答..才明白
:idea:  

58 楼 soni 2008-06-16  

这种bug我的做法就是放弃，随他去。

57 楼 梦醒了再睡 2008-06-16  

我试过了好像有这个问题，不过不受影响吧！以前没搞程序，哪里在乎那么多哦！

56 楼 class_syh 2008-05-26  

以前遇到过这个情况，一直以为是输入法的问题。

55 楼 achun 2008-05-24  

<p>我没有发现西方人通常发现不了的一个IE的bug,我做了一个屏幕视频,大家看看是我操作有问题么?</p>
<p> </p>

54 楼 rainchen 2008-05-24  

hax 写道

rainchen 写道

类似问题遇过了，在实现autocomplete时就发现在IE中正常，而在FF中，使用常用的中文输入（如sogou）不能很好的触发请求（因为会先在文本框中显示首字母）。

嗯，你说的这个问题我也碰到过。似乎除了定时读取外暂时想不出什么好办法。

后来观察过google.cn的autocomplete，他的可以在IE和FF中正常，忘了他是怎么做到的。

53 楼 oaklet 2008-05-21  

fins 写道

不知道为什么 西方人发现不了

我也想不太明白？

52 楼 bbiao 2008-05-20  

看标题以为是IE处理中文的问题

51 楼 hax 2008-05-20  

rainchen 写道

类似问题遇过了，在实现autocomplete时就发现在IE中正常，而在FF中，使用常用的中文输入（如sogou）不能很好的触发请求（因为会先在文本框中显示首字母）。

嗯，你说的这个问题我也碰到过。似乎除了定时读取外暂时想不出什么好办法。

50 楼 Realazy 2008-05-20  

netix1999 写道

realazy的例子中
我很好奇 google 的搜索框中
打开输入法，当输入拼音，还没形成汉字进入输入框时
它的可选搜索结果就出现在下拉框中了
这是怎么实现的？

这个是用计时器实现的，见：http://realazy.org/blog/2007/10/31/solution-of-keyup-failing-when-ime-is-on/

49 楼 rainchen 2008-05-19  

类似问题遇过了，在实现autocomplete时就发现在IE中正常，而在FF中，使用常用的中文输入（如sogou）不能很好的触发请求（因为会先在文本框中显示首字母）。

48 楼 hax 2008-05-18  

我认为javaeye的这个直接加到当前页面底端的处理确实存在问题，因为一般用户对此并没有预期。我相信可以做得更好。

47 楼 afcn0 2008-05-18  

"提高用户体验"有这么提高的吗,哪个大哥写的程序...........这叫提高体验吗

46 楼 tiyi 2008-05-17  

afcn0 写道

不知道,mousedown就是会影响focus,在ff下面也是一样,timeout是在事件结素后执行,当然focus上了,西方人发现不了,是因为输入法,焦点在输入法和ie之间大概会有问题的意思吧(本论坛有bug,在页面1提交回复,竟然直接更新到页面1底下了)

那你可以想想本论坛的发帖机制是什么。
那个只不过是对成功callback的一种处理。直接添加到当前页面的底部显示，用来提高用户体验。。。难道你真的以为改变了楼层吗……

45 楼 birdjavaeye 2008-05-14  

hax 写道

birdjavaeye 写道

hax 写道

实际上，这是IE的focus机制的bug。

是的，ie中input这样的控件在显示到页面之前设置focus是无效的，所以要setTimeout在控件显示之后设置focus

并非如此。你再看看我的主贴，其实和input是否显示出来是没有关系的。

嗯，结果即是如此，我说的现象，你说的原因，当然我没有去研究原因是什么
不过对于ie这种不得不用的垃圾，找到方案我就用了，实在没功夫去深究

我回复中提到的另外一些情况，你也研究研究吧，看看有没有更好的方案

44 楼 hax 2008-05-12  

fins 写道

按到底 是 down
抬起的一瞬间是 click
完全抬起时是 up

谁来告诉我一下 哪个系统是这么设计的了
swt ? j2me ? ...

你是不是跟dblclick混淆了？dblclick的行为是有不一致的。

43 楼 fins 2008-05-11  

你是怎么测试的??

================

我测试了一下 确实是我的错 呵呵  谢谢

我之前忘记了是被什么误导了 我一直以为

按到底 是 down
抬起的一瞬间是 click
完全抬起时是 up

谁来告诉我一下 哪个系统是这么设计的了
swt ? j2me ? ...

42 楼 netix1999 2008-05-11  

fins 写道

netix1999 写道

fins 写道

down click up 这是事件处理的顺序
在down里做一些事情确实危险

例如 alert一个东西 那么click事件 就不能被正确的触发了

事件顺序应该是 down up click 吧

你试验一下就知道了

对key 来说  keypress, keytype, keyrelease
对mouse来说 mousedown, mouseup, mouseclick

41 楼 sutra 2008-05-11  

楼主描述的问题好像不是bug吧，在keyup的时候聚焦或者取得文字就会如你所愿了：

--- settimeout_original.html	2008-05-11 23:41:23.000000000 +0900
+++ settimeout.html	2008-05-11 23:32:48.000000000 +0900
@@ -13,7 +13,7 @@
 		}
 		
 		window.onload = function(){
-			get('makeinput').onmousedown = function(){
+			get('makeinput').onmouseup = function(){
 				var input = document.createElement('input');
 				input.setAttribute('type', 'text');
 				input.setAttribute('value', 'test1');
@@ -31,7 +31,7 @@
 					input.select();
 				}, 0);
 			}
-			get('input').onkeypress = function(){
+			get('input').onkeyup = function(){
 				get('preview').innerHTML = this.value;
 			}
 		}

--- settimeout_original.html	2008-05-11 23:41:23.000000000 +0900
+++ settimeout.html	2008-05-11 23:47:48.000000000 +0900
@@ -12,14 +12,18 @@
 			return document.getElementById(id);
 		}
 		
+		var lastInput;
 		window.onload = function(){
 			get('makeinput').onmousedown = function(){
 				var input = document.createElement('input');
 				input.setAttribute('type', 'text');
 				input.setAttribute('value', 'test1');
 				get('inpwrapper').appendChild(input);
-				input.focus();
-				input.select();
+				lastInput = input;
+			}
+			get('makeinput').onmouseup = function() {
+				lastInput.focus();
+				lastInput.select();
 			}
 			get('makeinput2').onmousedown = function(){
 				var input = document.createElement('input');
@@ -31,7 +35,7 @@
 					input.select();
 				}, 0);
 			}
-			get('input').onkeypress = function(){
+			get('input').onkeyup = function(){
 				get('preview').innerHTML = this.value;
 			}
 		}

40 楼 fins 2008-05-11  

netix1999 写道

fins 写道

down click up 这是事件处理的顺序
在down里做一些事情确实危险

例如 alert一个东西 那么click事件 就不能被正确的触发了

事件顺序应该是 down up click 吧

你试验一下就知道了