Project

General

Profile

Actions
Copy link

Defect #15125

closed

Task properties are reverted when doing a task update from firefox.

Added by Mehmet Soyturk about 11 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Wont fix
Affected version:
2.3.1

Description

We many unintended task property changes (the changes of one user is unintendedly reverted by another user).

To reproduce:
  • Open an issue from firefox.
  • Open the same issue in another tab / browser / computer.
  • From the second tab, update task properties that are selected from dropdown lists, such as "Status", "Priority", "Assignee" or "% Done".
  • Hit F5 from the first tab. You will see that the task properties were updated successfully.
  • Then, still in the second tab, click the "Update" link. You will see that still the old values are selected. Add some message and send the form, and the properties are now reverted.

It seems that Firefox, even after a page refresh, tries to remember the options selected by the user. To avoid this, a ctrl-F5 is needed. See also http://stackoverflow.com/questions/1479233/why-doesnt-firefox-show-the-correct-default-select-option

Files

_edit.html.erb.patch (517 Bytes) _edit.html.erb.patch Mehmet Soyturk, 2019-02-26 16:51

Related issues

Related to Redmine - Defect #14621: AJAX call on the issue form resets data entered during the requestClosedJean-Philippe Lang

Actions
Has duplicate Redmine - Defect #18011: Firefox: Value of a field not updated properly when hitting F5Closed

Actions
Actions
Copy link
 #1

Updated by Mehmet Soyturk about 11 years ago

We many unintended task property changes

We get many ...

Reproduced with Firefox 24.0.

Actions
Copy link
 #2

Updated by Toshi MARUYAMA about 11 years ago

  • Related to Defect #14621: AJAX call on the issue form resets data entered during the request added
Actions
Copy link
 #3

Updated by Toshi MARUYAMA about 11 years ago

Could you reproduce on trunk r12220?
I think #14621 fixed this issue.

Actions
Copy link
 #4

Updated by Mehmet Soyturk about 11 years ago

I don't know. I can reproduce it with our internal redmine install (for which I'm just a user and I don't know its version number), and from http://demo.redmine.org (see http://demo.redmine.org/issues/25923).

Actions
Copy link
 #5

Updated by Mehmet Soyturk about 11 years ago

But looking at the code, I don't think that #14621 fixes this issue. r12166 depends on the fact that updateIssueFrom is called when a select is modified. With this bug, select is not modified at all, and no updateIssueFrom is called.

Actions
Copy link
 #6

Updated by Jean-Philippe Lang about 11 years ago

  • Status changed from New to Closed
  • Resolution set to Wont fix

Firefox preserves the selected form elements when hitting F5 by design. So when you hit F5 from the first tab, the old values that were present on the issue form are preserved. Use Ctrl+F5 instead to reload the form without preserving selected values.

Actions
Copy link
 #7

Updated by Toshi MARUYAMA about 10 years ago

  • Has duplicate Defect #18011: Firefox: Value of a field not updated properly when hitting F5 added
Actions
Copy link
 #8

Updated by Mehmet Soyturk almost 6 years ago

Hi.

I was going to share our patch that fixes the issue, but couldn't because Redmine did not allow me to do so at that time (because the task was closed). Let me retry.

We have used the patch for 5 years without any issue. With a recent RedMine upgrade we have lost that change and the issue reappeared.

Kind regards.

Actions
Copy link

Also available in: Atom PDF