[PATCH] View ticket details has misaligned fields when using custom fields

[sid@…]

Our site is using 0.9.4 and custom ticket fields. When I create a new ticket, everything is aligned nicely. When I go back to view a ticket, the fields do not line up correctly. Here is the custom ticket section of my trac.ini file:

[ticket-custom]
crb_approved = checkbox
crb_approved.label = Approved by CRB
inventory_disposition.label = Inventory Disposition
cause_and_plan.cols = 68
completed_by_date = text
cause_and_plan.label = Cause and Plan
cause_and_plan = textarea
inventory_disposition = select
field_disposition = select
field_disposition.label = Field Disposition
completed_by_date.value = mm/dd/yyyy
doc_number.label = Doc / Drawing #
doc_number = text
field_disposition.options = |Replace immediately|Replace at next maintenance cycle|Replacement not required
field_disposition.value = 0
crb_approved.value = 0
inventory_disposition.options = |Purge existing inventory|New production only|Use up existing inventory
cause_and_plan.value = ROOT CAUSE is ....  ACTION PLAN is ...
cause_and_plan.rows = 10
inventory_disposition.value = 0
completed_by_date.label = Complete By

I normally use Opera (9.00 beta) on Mac OS X, but the misaligned rendering also happens with Firefox.

[sid]

screenshot of the misaligned ticket fields when viewing a ticket

[sid]

Another data point: tickets on the edgewall website show up as normal when I view them using the same browsers.

[anonymous]

I've got a similar problem. Two custom textarea. The "New ticket" view looks fine. When I view an existing ticket, the second textarea is misaligned. (It hasn't got closing-opening TR tag?) - Sorry for my english.

[sid]

Fix for 0.10 release for the misaligned fields.

[sid]

Attached a fix for 0.10 that fixes this bug in both the new ticket and view tickets pages. This is tested and works on my setup.

The problem is that the idx variable was being incremented when a <textarea> tag was encountered, but the num_fields was held constant. So idx would grow larger than num_fields, and you would see some strange field alignments.

[sid]

#3440 was marked as a duplicate of this.

[sid]

Better patch for 0.10 that doesn't require incrementing num_fields

[sid]

New patch. This one is better because the previous patch relied on some strange logic to increment num_fields to stay in sync with idx (which is incremented with some special cases and is difficult to debug).

This patch leaves num_fields alone, and now has a count to track how many form fields have been already listed. The meaning of idx has changed.. now it just flips between 0 and 1, indicating whether to print as class="col1" or class="col2".

[sid]

#3602 was marked as a duplicate of this ticket.

The alignment problems in that ticket happened when using multiple textarea custom fields.

[sid]

#3406 was marked as duplicate. In that ticket, he mentions that one workaround might be to tweak the custom field ordering to avoid the bug.

[sid]

I tested this on 0.11dev and it is working correctly. The patch I created is only valid for 0.10 (due to the change to using Genshi instead of Clearsilver templates), so I'm going to close this as a worksforme.

[Geoff Reedy <gereedy@…>]

I'm reopening this ticket and retargeting to 0.10.4 so that the patch might be included in 0.10.4 when/if it is released.

[Christian Boos]

Replying to Geoff Reedy <gereedy@sandia.gov>:

I'm reopening this ticket and retargeting to 0.10.4 so that the patch might be included in 0.10.4 when/if it is released.

You can increase the chances that this will happen if you test the patch and tell us if it worked for you.

[anonymous]

Replying to cboos:

Replying to Geoff Reedy <gereedy@sandia.gov>:

I'm reopening this ticket and retargeting to 0.10.4 so that the patch might be included in 0.10.4 when/if it is released.

You can increase the chances that this will happen if you test the patch and tell us if it worked for you.

Tested the patch on 0.10.2 project template folder and it works a treat!

[alexandre.franke@…]

Tested against 0.10.3 and as I upgraded to 0.10.4, tested against it as well. Now I really think this should be commited so that next security upgrade won't break things once more.

[sid]

With pending 0.11 release, and also since this is fixed in 0.11, I'm going to reclose this. It will not likely be merged to 0.10-stable, and if it bothers people, please use the patch I attached to the ticket to get it working on your installation.

[osimons]

#6814 closed as duplicate.