282368 - Internet Explorer loses data when clicking the "Back" button

Status: RESOLVED WONTFIX

(Bugzilla :: Bugzilla-General, defect)

Description

[Shane H. W. Travis]

In what appears to be a recurrence of bug 83033, the Component, Version and 
Target Milestone fields are getting cleared when someone creates a search, 
views the resulting buglist, and then presses 'back' in their browser. Expected 
behaviour is that they should retain their previous values, as is done by every 
other field on the page.

I can verify that the query.cgi page behaves as expected in 2.16.7, so this is 
a regression in the javascript between then and now.

Comment 1

[Dave Miller [:justdave]]

Is it broken in 2.18?

Comment 2

[Shane H. W. Travis]

I *believe* that it is, based on memory alone; I recall seeing this incorrect 
behaviour on the SED system after upgrading to 2.18. My memory could be faulty, 
though, so someone should check to be sure.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

"If it's not a regression from 2.18 and it's not a critical problem with
something that's already landed, let's push it off." - Dave

Comment 4

[Shankar Unni]

This seems to be IE-specific. FF 1.0.4 retains all the values when "Back"ing up
to the query page after viewing a search result. But IE 6.0 SP2 (XP SP2) clears
the Component and Target Milestone (and probably the Version as well).

Comment 5

[Frédéric Buclin]

*** Bug 323070 has been marked as a duplicate of this bug. ***

Comment 6

[Frédéric Buclin]

I cannot reproduce using Fx, as described in comment 4. Moreover, only security and dataloss fixes will be accepted on the 2.20 branch. Retargetting to 2.22.

Comment 7

[Frédéric Buclin]

Morphing the bug summary to be more general. The problem seems to happen with Internet Explorer only, everytime you click the "Back" button. Data entered is lost. This bug doesn't happen with Firefox.

Comment 8

[Frédéric Buclin]

*** Bug 339820 has been marked as a duplicate of this bug. ***

Comment 9

[timeless]

i'd like to change the severity to major this bites me quite often and it's very unfriendly.

Comment 10

[exodus systems]

My bug 339820 has been marked as a duplicate of this bug.

However, bug 3398290 includes a more detailed description of the steps to reproduce this problem, explanation of how it does not happen EVERY time, and suggestions for the addition of a formal "back" button in the UI, rather than being dependent upon the browser.

Since bugs marked "duplicate" are pretty much ignored after that, I wanted to highlight that it is worth visiting Bug 339820 if evaluating or working on this bug.

I also agree with timeless that this bug should be at least raised to normal, not minor.

Comment 11

[Denis Roy]

We're seeing this as well:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=186846

Comment 12

[GavinS]

Is this IE specific, and so perhaps distinct from bug#36843, or is this really a dupe of that?

Comment 14

[Csaba]

(In reply to comment #13)
> *** Bug 544662 has been marked as a duplicate of this bug. ***

My bug544662 has been marked as a duplicate of this bug.

I can see this bug is almost 5 years old. Will be there any solution for it?

Thanks.

Comment 15

[Guy Pyrzak]

I think I know what the problem is and how to fix it. 

First i'll explain the suspected cause...

IE and Firefox/Webkit cache field values for multiselects and drop downs differently. This caching allows your browser to select the right values when you hit back (which is what is breaking). The fields, Component, Version and Target Milestone are all fields which are narrowed. 

Firefox/Webkit seem to store the values based on the option tag selected. IE seems to store the selected value as the index of the option tag in the select tag (i'm never sure if its the index before or after the narrowing).  

What I think happens is when you hit back IE selects the index that the user selected last (post narrowing) and Firefox/Webkit selects the option tag that you selected last. When the narrowing for product occurs the value that was incorrectly selected is removed from the list.

The solutions i can think of is using CSS to hide the options instead of removing them from the select (not sure if this works in IE thought). Or using a textfield to cache the select value from the drop down.

I can provide an example of this happening that is independent of the Search page if that's needed.

Comment 17

[emmanuel orvain]

As explained on this bz : Bug 956756
Chrome browser is also impacted by this issue.

And as explained in the same bz, it's easy to record a bad resolution of a bug.
As user thinks that back button refill the form, they don't have the intuition to check this specific field (resolution).

I think this is an important issue, because this let users to record wrong resolution in the database.

Comment 19

[Kohei Yoshino [:kohei]]

We are going to drop IE support with Bugzilla 6.0.