Fix issue with status => reviewing in Firefox

[nacin]

In Trac using Firefox, if you return to a ticket using the back button, the radio will kick to reviewing.

scribu isn't going crazy after all, I guess? :)

On subsequent test, I can no longer reproduce. If someone can isolate what's going on here, we can try to fix.

[scribu]

It seems it's not limited to 'reviewing'. It will jump to the second radio button, whatever it is.

I almost accidentally closed (or re-opened) tickets due to this bug.

[nacin]

Further investigation:

Scroll to the radio buttons. Note that new is checked. Refresh the page, again and again, and watch it switch back and forth.

Yet when this occurs, note that the input for new keeps the checked attribute.

It's one of three things: A bug in the keywords code, a bug in Trac, or a bug in Firefox (or some combination).

[scribu]

I can reproduce consistently now:

1. Go to ​http://core.trac.wordpress.org/timeline
2. Go to any ticket page.
3. Press "Back".
4. Press "Forward".

[scribu]

Refreshing once also triggers it, as you said.

I'm guessing a simple document.getElementById('propertyform').reset() would fix it.

[solarissmoke]

The issue is with keywords.js - I just tried disabling that and then it works fine.

[nacin]

Indeed, I've tracked it down to (I think) wpKeywords.template, but there's nothing in there that's suspicious. My watch statement isn't showing any change -- it's either always checked, or never checked, regardless of where it is checked.

[nacin]

I 've been banging my head against the wall (and I'm pretty sure I drove koopersmith mad) for almost two hours now. The issue is when we add a <select/> to the dom, in that function.

Moving a pre-rendered select element in place does not fix the issue. In fact, the only thing that does fix the issue, is if I take the actions (#action) and append it to the end of the form (#propertyform). Yet bafflingly, if I then proceed to take the buttons (#propertyform .buttons) and append them to the end of the form, and thus after the actions (and thus no visual change), the bug returns.

I'm pretty sure we've stumbled upon a bug in Firefox. I just don't know what.

I've been trying to come up with a workaround via JS (some described above), but I'm nearly out of ideas, so tomorrow I'm going to try to generate more of this template on the server side, which should fix it.

[nacin]

I'm also going to try to replicate this bug in a simple HTML document. Wish me luck with that one.

[nacin]

Alright. So it's a bug in Firefox's autocomplete implementation. This helps to explain why the ordering of the buttons was affecting whether the bug could be reproduced.

It's described here, in a post sadly written in 2008: ​http://www.ryancramer.com/journal/entries/radio_buttons_firefox/.

Dynamically generated form inputs that are added before radio buttons end up screwing with the radio buttons when autocomplete kicks in.

I'll be getting this code pushed today:

$.browser.mozilla && $('#action input:radio').each( function() {
	this.checked = this.defaultChecked;
});

[solarissmoke]

I think we should all go and vote for the bug: ​https://bugzilla.mozilla.org/show_bug.cgi?id=394782

[scribu]

Yay :)