Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#17051 closed defect (bug) (fixed)

Fix issue with status => reviewing in Firefox

Reported by: nacin Owned by:
Milestone: WordPress.org Priority: normal
Severity: normal Version:
Component: WordPress.org Site Keywords:
Focuses: Cc:


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.

Change History (12)

#1 @scribu
10 years ago

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.

#2 @nacin
10 years ago

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).

#3 @scribu
10 years ago

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".

#4 @scribu
10 years ago

Refreshing once also triggers it, as you said.

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

#5 @solarissmoke
10 years ago

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

#6 @nacin
10 years ago

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.

#7 @nacin
10 years ago

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.

#8 @nacin
10 years ago

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

#9 @nacin
10 years ago

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;

#10 @solarissmoke
10 years ago

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

#11 @nacin
10 years ago

  • Resolution set to fixed
  • Status changed from new to closed

#12 @scribu
10 years ago

Yay :)

Note: See TracTickets for help on using tickets.