Item1966: State field gets rendered wrong in Firefox on page reload (after changing state)

Description

When changing the State field via the drop-down menu in Firefox and reloading the page, the contents of the State fields can get messed up, i.e. some of them don't get rendered correctly.

Initial state, before closing the first action (using the drop-down menu of the upper table)

After closing the first action and reloading the page; on reload the first action vanishes from the upper table, since we are looking for open actions. It looks like Firefox rememberes the order of the State fields of the two tables after closing the first action (Closed, Open, Open, Open) but the bgcolor of the fields is set correctly, for the real states (Open, Closed, Open)

How to reproduce

When ActionTrackerPlugin is installed, create a topic in Sandbox web with the following content and save it:

%ACTIONSEARCH{state="open" web="Sandbox"}%
---
%ACTION{ due="" notify="" state="open" who="Main.WikiGuest" }% set me to _closed_ and reload the page %ENDACTION%
%ACTION{ due="" notify="" state="open" who="Main.WikiGuest" }% then this displays _closed_ on an orange background,
indicating that it really is open (and late) %ENDACTION%

Then play around with the status drop-down menu as indicated in the actions and reload the page after each action. Try editing this in the upper and the lower table.

Analysis

It looks like Firefox is not updating the content of the table cells on reload of the page. It rather remembers the fields, even if now a row of the table is missing and therefore the subsequent rows move up.

We tested IE, Opera and Firefox (3.0 and 3.5). Only Firefox showed this behaviour. But still we guess this is not Firefox's fault; rather the HTML is messy...

I consider this as urgent since it's likely to confuse users and induce operating errors.

-- PhilippLeufke - 25 Aug 2009

Update by HolgerHain: Since we use an extra called summary wich is not a standard attribute I removed it from PhilippLeufke's example

The interesting thing is, that if you reload the page by using a link to this topic (i.e. the one directly under the page header) the page is displayed correctly

-- HolgerHain - 26 Aug 2009

This sounds more like a problem with caching in the browser, than anything else. I don't consider it to be a release blocker, though, so dropped priority to Normal. I don't have time to work on it right now, so it's going to have to wait.

-- CrawfordCurrie - 08 Dec 2009

Having played with this a bit, it's definitely an issues with the browser cache. If you look at the HTML sent to the browser for the page refresh, the field values are correct. I'm not aware of any way to disable the browser cache selectively for individual pages or fields. I'm going to leave this open; if anyone feels like tackling it, be my guest.

-- CrawfordCurrie - 28 Jan 2011

No-one seems interested, so closing this.

-- Main.CrawfordCurrie - 07 May 2017 - 10:12