297741 - drop down menu selection changes after clicking a link then hitting back button

Status: REOPENED

(Core :: DOM: Navigation, defect)

Description

[Patrick Mellinger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614 Firefox/1.0+

The "Search in: " pulldown at the top of SHOP.COM changes from the default "All
Products" to a blank line after entering the shopping cart, then hitting the
back button. Occurred in Firefox 1.01, 1.02, the june 14th build of deer park 1,
and mozilla 1.7.8. 

Reproducible: Always

Steps to Reproduce:
1. go to http://www.shop.com/
2. click the link for "view cart" in the upper right.
3. click back

Actual Results:  
the drop down menu had changed from all products to a blank line.

Expected Results:  
when the browser returns back to the first page, it should have stayed on all
products.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Minimal-ish testcase needed...  Does this happen if you save the page to disk
(save page, complete) and work with the local copy?

Comment 2

[José Jeria]

Attachment: Testcase

1. Load testcase, noticed that "all products" is selected
2. Hit reload button, blank option is now selected

Both have the same name value

Comment 3

[Boris Zbarsky [:bzbarsky]]

So the problem is that when restoring we restore to the option with the right
value, since that would lead to the same form submit... And if there are
multiple options with the same value we can't get it right, in general.  :(

I think we have some existing bugs on this.

Comment 4

[u279076]

Removing qawanted since it appears to have been set when asking for a testcase. Since this bug has had this testcase qawanted is no longer needed. Please re-add if this is incorrect and indicate what is needed from QA on this bug.

On a side-note, this has been sitting in DUPEME for 6 years. The likelihood of finding a DUPE is pretty low at this point. Marking this bug as WONTFIX seems most appropriate in this case.

Feel free to reset the resolution to DUPLICATE if you can find one.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Do NOT resolve wontfix bugs in components you're not an owner or peer for.  It's not your call.

As for likelihood of finding a duplicate... did anyone even look?  Did you?

Comment 6

[u279076]

(In reply to Boris Zbarsky (:bz) from comment #5)
> Do NOT resolve wontfix bugs in components you're not an owner or peer for. 
> It's not your call.
> 
> As for likelihood of finding a duplicate... did anyone even look?  Did you?

I apologize. I did not realize resolving bugs was the sole right of component owners. Yes I did look and I couldn't find one. Nor has anyone been able to find one for over 3 years.

I apologize if I upset you, however your response seems a bit harsh. You are lucky I'm not a contributor because this sort of response comes off as being very anti-collaborative.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 7

[Boris Zbarsky [:bzbarsky]]

Anthony, resolving bugs _WONTFIX_ is specifically something that component owners/peers should do, since that's their call.  WONTFIX means that it's a real bug but we will never fix it for some reason, even if someone has a patch for it.  That's a pretty strong claim....

And I'm sorry about the tone of my response.  I did in fact know that you're not a volunteer, but that's not an excuse, of course....