IE 中 jQuery 设置的 iframe `name` 属性的奇怪行为 [英] Weird behaviour of iframe `name` attribute set by jQuery in IE

查看：22
本文介绍了IE 中 jQuery 设置的 iframe `name` 属性的奇怪行为的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在通过将文件以表单形式发布到 iframe 来执行 ajax 样式文件上传，并注意到 IE 中的一些奇怪行为(似乎在 6 和 8 中都会发生).基本上在 IE 中，表单没有正确target iframe，因此响应出现在新窗口中(而不是在 iframe 中).您可以使用以下最小的 HTML/JS 集重现该问题:

<头><script src="http://code.jquery.com/jquery-1.3.2.js"></script><脚本>$(document).ready(function(){var frameName = "myFrame";var $iframe = $("<iframe src="about:blank"/>").attr(名称"，框架名称).appendTo("body");var $uploadForm = $("<form action="http://www.google.com/search"/>").attr(目标"，框架名称).append("<input type="text" name="q"/>").append("<输入类型="提交"/>").appendTo("body");});<身体>

现在(在您发布答案之前)，我做了一些调查(使用 IE8 的开发人员工具)，看起来 .attr("name", frameName) 实际上是将属性添加为 submitName="myFrame" 而不是简单的 name="myFrame".基于此，我通过将 iframe 创建代码更改为稍微讨厌的方式解决了该问题:

var $iframe = $("<iframe src="about:blank" name="" + frameName + ""/>").appendTo("body");

进行此更改后，表单会根据需要发布到 iframe 中.

我的问题是:

  • 为什么 .attr("name", ...) 没有按预期工作?
  • 是 jQuery 中的错误还是 IE 中的错误(当然不是！?！)，还是我遗漏了一些明显的东西?
  • submitName 属性从何而来 &它的目的是什么?

解决方案

IE 中的一个错误(肯定不是！?！)

难以置信，我知道，但我们就是这样.

历史上(*)，在IE中设置name属性有很多问题.它往往只部分成立.例如，在表单字段名称上，它不会像它应该的那样影响 form.elements[name] 查找.这似乎是设置 name 属性不可靠的另一种情况.

虽然 jQuery 尝试解决这样的浏览器错误，但它并不能解决所有问题，并且没有已知的方法可以完全解决它.

(*:在 IE 中最多 7 个.如果您使用标准模式文档类型在本机文档模式下运行 IE8，并且在必要时使用 X-UA-Compatible 标头/元，则不会出现这两个错误.)

出现在开发工具中的 submitName 是一个有趣的 IE 错误幕后一瞥，因为它根本没有出现在公开可见的 DOM 中.如果您查看 元素或

其 name 属性在创建后已写入，它会执行相同的操作，

所以似乎正在发生的事情是 IE-up-to-7 将所有使用名为 name 的属性重定向到一个否则不可见的属性，内部称为 submitName，对于表单字段，它会更改该字段将作为表单提交的一部分生成的数据，但这不会更改用于 HTMLCollection 索引、无线电分组、getElementsByName 或在[i] 帧的情况，定位.

I'm doing an ajax style file upload by posting the file in a form to an iframe and noticed some weird behaviour in IE (seems to happen in both 6 & 8). Basically in IE the form doesn't target the iframe properly so the response appears in a new window (instead of in the iframe). You can reproduce the problem with the following minimal set of HTML/JS:

<html>
<head>
  <script src="http://code.jquery.com/jquery-1.3.2.js"></script>
  <script>
    $(document).ready(function(){
      var frameName = "myFrame";
      var $iframe = $("<iframe src="about:blank" />")
              .attr("name", frameName)
              .appendTo("body");
      var $uploadForm = $("<form action="http://www.google.com/search" />")
              .attr("target", frameName)
              .append("<input type="text" name="q" />")
              .append("<input type="submit" />")
              .appendTo("body");
    });
  </script>
</head>
<body>
</body>
</html>

Now (before you post an answer), I did some investigation (using IE8's developer tools) and it appears that the .attr("name", frameName) is actually adding the attribute as submitName="myFrame" instead of simply name="myFrame". Based on this, I solved the issue by changing the iframe creation code to the slightly nastier:

var $iframe = $("<iframe src="about:blank" name="" + frameName + "" />")
        .appendTo("body");

Making this change makes the form post into the iframe as desired.

My questions are:

  • Why doesn't .attr("name", ...) work as expected?
  • Is it a bug in jQuery, a bug in IE (surely not!?!), or am I missing something obvious?
  • Where does the submitName attribute come from & what's its purpose?

解决方案

a bug in IE (surely not!?!)

Hard to believe, I know, but there we are.

Historically(*), setting the name attribute has many problems in IE. It tends to only partially hold. For example on form field names, it doesn't affect the form.elements[name] lookup like it should. This appears to be another case where setting the name property is unreliable.

Whilst jQuery attempts to work around browser bugs like this, it doesn't catch everything, and there is no known way to solve it fully.

(*: in IE up to 7. If you run IE8 in native documentMode by using a standards mode doctype and if necessary an X-UA-Compatible header/meta, both these errors don't crop up.)

The submitName appearing in the dev tools is an interesting glimpse behind the scenes of an IE bug, since it doesn't appear in the publically-visible DOM at all. It does the same thing if you look at an <input> element or <form> whose name attribute has been written after creation, too.

So what appears to be happening is that IE-up-to-7 redirects all use of attributes called name to an otherwise-invisible property, internally called submitName, that for form fields changes the data the field will generate as part of a form submission, but which doesn't change the real name attribute used for HTMLCollection indexing, radio-grouping, getElementsByName, or, in the case of [i]frames, targeting.

这篇关于IE 中 jQuery 设置的 iframe `name` 属性的奇怪行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆