Opened 10 years ago

Closed 5 years ago

#3110 closed Bug (wontfix)

ManyToMany filter_interface widget renders incorrectly in IE 6 when the field is in a fieldset with class collapse

Reported by: Adam Endicott <leftwing17@…> Owned by: xian
Component: contrib.admin Version: newforms-admin
Severity: Normal Keywords: nfa-someday
Cc: leftwing17@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: yes


When I put a ManyToManyField with filter_interface=True inside a fieldset with class "collapse", it renders the left (available) portion of the widget correctly, but the right (chosen) part renders as a normal select widget with all currently chosen values as options. This causes the problem that when the object is saved, only the first (currently selected) existing chosen option is saved as the value for that field.

Interestingly, if I add a new value to the chosen side (pick one on the left, then click the right arrow button), it seems to cause the right side of the widget to reevaluate itself and render correctly.

I'm only seeing this when the widget is within a collapsed fieldset.

I'm using the 0.95 release.

Attachments (1)

screenshot.png (54.1 KB) - added by Adam Endicott <leftwing17@…> 10 years ago.
screenshot example of the problem

Download all attachments as: .zip

Change History (16)

Changed 10 years ago by Adam Endicott <leftwing17@…>

screenshot example of the problem

comment:1 Changed 9 years ago by Simon G. <dev@…>

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

Can you confirm if this is still a problem on a current checkout?

comment:2 Changed 9 years ago by gwilson

  • Resolution invalid deleted
  • Status changed from closed to reopened

I don't think we should close tickets just because they haven't been confirmed.

comment:3 Changed 9 years ago by Adam Endicott <leftwing17@…>

Unfortunately this is pretty difficult for me to test on my current setup, I don't have a windows machine that can access anything I can set up for a quick test. I spent a few minutes trying to set something up testing on trunk, and didn't get it going.

I can confirm that in Django 0.96 it fails as described above in IE6, and works as it should in IE 7 (as well as Firefox).

Hopefully somebody with a windows setup can test it in trunk. This should be all the model needed to test it:

from django.db import models

class Foo(models.Model):
    name = models.CharField(maxlength=10)

class Thing(models.Model):
    name = models.CharField(maxlength=10)
    foos = models.ManyToManyField(Foo, filter_interface=True)
    class Admin:
        fields = ((None, {'fields': ('name',)}),
                  ('Foos', {'classes': 'collapse',
                            'fields': ('foos',)}),)

comment:4 Changed 9 years ago by Adam Endicott <leftwing17@…>

  • Cc leftwing17@… added

comment:5 Changed 9 years ago by ludo@…

I can confirm this bug is still present with a trunk checkout.

comment:6 Changed 9 years ago by ubernostrum

  • Owner changed from nobody to xian
  • Status changed from reopened to new
  • Triage Stage changed from Unreviewed to Accepted
  • Version changed from 0.95 to newforms-admin

Reassigning to xian since he's doing newforms-admin JS stuff.

comment:7 Changed 9 years ago by Karen Tracey <kmtracey@…>

  • Keywords nfa-someday added

Problem reported against old admin, should not block merge of newforms-admin.

comment:8 Changed 8 years ago by garcia_marc

This one looks like a duplicate of #1621.

Could somebody check if that is true, and close as duplicate one?

comment:9 Changed 8 years ago by Karen Tracey <kmtracey@…>

#1621 and #7278 are dups of this.

comment:10 Changed 8 years ago by Karen Tracey <kmtracey@…>

Also verified this is still a problem with IE6 (but not IE7) on newforms-admin r7737.

comment:11 Changed 8 years ago by Alex

Karen, dumb question, did you mean that it is confirmed working in IE7, or hasn't been checked?

comment:12 Changed 8 years ago by Karen Tracey <kmtracey@…>

Sorry, I see my comment could be interpreted either way. I did try IE7 and cannot recreate the problem there. It seems to affect only IE6.

comment:13 Changed 5 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from defect to Bug

comment:14 Changed 5 years ago by julien

  • UI/UX set

comment:15 Changed 5 years ago by oinopion

  • Easy pickings unset
  • Resolution set to wontfix
  • Status changed from new to closed

If it's IE6 only, then it's wontfix, as we don't support IE6 anymore in admin.

Note: See TracTickets for help on using tickets.
Back to Top