奇怪的 Firefox 输入错误
我对此感到有点惊讶，所以我想知道是否有任何 SOers 以前遇到过这种情况。
我有一个基本上平坦的页面，其中有许多 input=text 种子在标记中，默认值依次为 A、B、C、D、E。 标记在查看源代码中如下所示：
<td class="action invoice">
<a href="#foo">Toggle Invoice</a>
<div class="data">
<input type="text" class="formatted" value="A" />
<a href="#" class="notes" title="Add Note">Add Note</a>
</div>
</td>
针对 A->E 行数进行迭代。
该页面由 ASP.NET 2.0 应用程序创建。 版本 1 只是“user.aspx?id=1”，版本 2 是由类似 REST 的 HTTPModule 在内部从“user/1”映射到“user.aspx?id=1”的路径。
版本 1 很好。 版本 2 渲染后给我留下了重复按 E、A、B、D、E 顺序排列值的输入，但我看不出有什么特别的原因。
我可以查看源代码并且 value="X" 是正确的，并且在 firebug 中的 DOM 检查中，defaultValue 是正确的，但 value 不正确。
- 这不是 CSS 问题 - CSS 已从页面中删除。
- 这不是 JS 问题 - JS 已关闭。
- 这不是 HTML 问题 - 标记在所有情况下实际上都是相同的。
唯一的区别在于如何请求标记。 就好像 Firefox 以某种方式与服务器量子纠缠在一起。
有人听说过这样的事情吗？ 我惊呆了。
编辑：这也绝对是一个FF问题。 IE、Opera 和 Chrome 都可以正常使用该页面。
编辑2：我的字面意思是请求的路径。 一种版本是对 http://localhost/user.aspx?id=1，另一个（失败）版本是http://localhost/users/1< /a> 并且此版本由 HTTPModule 映射到第一个路径。 name= 不会有帮助，因为默认值不是人类输入的，它们位于所提供的源中。
I'm a bit flabbergasted at this, so I'm wondering if any SOers have encountered it before.
I have an essentially flat page with a number of input=text seeded in the markup with default values of say A,B,C,D,E in order. The markup looks like this in view source:
<td class="action invoice">
<a href="#foo">Toggle Invoice</a>
<div class="data">
<input type="text" class="formatted" value="A" />
<a href="#" class="notes" title="Add Note">Add Note</a>
</div>
</td>
Iterated for a number of rows A->E.
The page is created by an ASP.NET 2.0 app. Version 1 is merely "user.aspx?id=1" Version 2 is path mapped by a RESTlike HTTPModule from "users/1" to "user.aspx?id=1" internally.
Version 1 is fine. Version 2 after rendering leaves me with inputs with values in the order E, A, B, D, E repeatably, but I can see no reason for that order especially.
I can view source and the value="X" is correct, and on DOM inspection in firebug the defaultValue is correct, but the value is not.
- This is not a CSS issue - CSS is removed from the page.
- This is not a JS issue - JS is off.
- This is not an HTML issue - the markup is literally identical in all cases.
The only difference is how the markup is requested. It's like Firefox is quantumly entangled with the server somehow.
Has anyone ever heard of such a thing? I'm stunned.
Edit: this is also definitely a FF issue. IE, Opera and Chrome are all fine with the page.
Edit 2: I literally mean the path of the request. One version is a request to http://localhost/user.aspx?id=1, the other (failing) version is to http://localhost/users/1 and this version is mapped by an HTTPModule to the first path. name= won't help because the default values are not human entered, they're in the source as served.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我敢打赌，这与映射的 url 没有文件扩展名有关，因此 Firefox 无法正确推断内容类型。 尝试在 ASP 代码中将内容类型明确设置为“text/html”，看看是否可以解决问题。
I would wager that it's related to the mapped url not having a file extension and so the content type isn't being properly deduced by firefox. Try explicitly setting the content type to "text/html" in the ASP code and see if that fixes it.
你指的是C、A、B、D、E吗？ 我敢打赌，属性中未加引号或不匹配的 " 会扰乱 C 的 td 标记的解析。当表中有一个标记未正确包含在 tr/td/etc 中时，firefox 会将其移至较早的位置页。
Did you mean C,A,B,D,E? My bet is that an unquoted or mismatched " in an attribute is messing up the parsing of the td tag for C. When there's a tag in a table that's not properly contained in tr/td/etc, firefox moves it up to earlier in the page.
您说：“唯一的区别是如何请求标记。”
你能扩展一下吗？ 这是某种 DHTML 传递吗？
或者工作和非工作情况都是完整的 HTML 页面？
添加不同的 name="" 参数有帮助吗？ 火狐确实如此
在某些情况下，尝试保留以前输入的值
你回到上一页，我看到它变得混乱
以前发生名称冲突时。
编辑：你说名字没有帮助，但你尝试过吗？
You say: "The only difference is how the markup is requested."
Can you expand on that? Is this some kind of DHTML delivery,
or are both the working and non-working cases full HTML pages?
Does adding different name="" parameters help? Firefox does
in some cases try to preserve previously entered values when
you go back to a previous page, and I've seen it get confused
before when there were name collisions.
Edit: you say name won't help, but did you try it?
我还没有完全找到解决方案，它的可重复性似乎取决于我尚未确定的某些因素，但我有一些偶然的证据表明这似乎是 FF 中发生的某些事情的组合（可能是对另一个选项卡中内容的响应 - 推测）和相关页面没有严格的文档类型。
我会保留这个开放，以防其他人遇到并找到这个奇怪的小妖怪的原因。
I have not exactly found a solution to this and it's repeatability seems to be conditional on some factor I haven't determined, but I have some incidental evidence that this appears to be a combination of something happening in FF (possibly a response to content in another tab - speculative) and the page in question not having a strict doctype.
I'll leave this open in case anyone else ever encounters and finds a reason for this strange little gremlin.
Firefox 在刷新和后退/前进导航之间保存表单数据方面非常积极。
我想我会尝试在表单输入中添加一个
autocomplete="off"属性，看看是否有帮助。我认为 Firefox 可能会将当前 URI 与引用 URI 进行比较，以了解它应该如何处理保存的表单数据。 在你的第二个例子中，两者不匹配。
Firefox is pretty aggressive about saving form data between refreshes and back/forward navigation.
I think I would try adding an
autocomplete="off"attribute to the form inputs and seeing if that helped.I think firefox may compare the current URI with the referring URI to see how it should handle it's saved form data. In your second example, the two wouldn't match.
如果您可以创建一个重新创建此问题的案例，并向 Firefox 团队提交错误报告，以便他们可以努力修复它。
If you can create a case where this is recreated and submit it a bug report to the Firefox team so they can work on fixing it.
通过 HTML 验证器 运行您的代码，看看是否有任何缺失的语法片段导致其呈现奇怪的效果。
Run your code through an HTML Validator to see if there are any missing syntax pieces that are causing it to render weird.