Bizarre Firefox Input Bug

Question

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.

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

Run your code through an HTML Validator to see if there are any missing syntax pieces that are causing it to render weird.