477643 - First search works, but when press back button to same form, and create a second search, the search button does not work.

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Michael]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)

On many, many webpages with a form entry, if I go to the page, enter information in the form (such as a search), then use the back button to go back to the original form entry page and try and enter in a new search, Firefox will allow me to enter my new information in the form fields, but it will not respond to my pressing Enter nor respond to my clicking on the search or submit or form entry button (whichever it is called on the particular site. The only viable work around I've seen is to reload the page, which is a senseless nuisance besides clearing my carefully-written second search. This reload also goes a long way to validating that it is not the webpages but Firefox's inner workings that are blocking these legitimate second-searches from happening.

Reproducible: Always

Steps to Reproduce:
1.Start at the webpage above (or find other ones that Firefox also treats this way).
2.Enter a legitimate search--like "Huckleberry Finn"
3.Once the results show up, press Firefox's Back button to return to the original search form.
4.Enter a new search--like "Mark Twain"
5.Notice how it will not comply.
(error checking to zero in on the problem:)
6.Reload the page
7.Enter the new search--I guess "Mark Twain"
8.Notice how everything putters away properly now, only seconds after an unexplained "hang up"
9.Try on other pages too...you will fairly commonly find others that do the same!
Actual Results:  
Firefox refuses to recognize when the user presses the form entry button a second time.

Expected Results:  
Firefox should pass the new search to the appropriate site.

This error occurs on many sites, and is unobtrusive enough not to be noticed as a Firefox error until one realizes that it occurs the same way over, and over, and over again. I suspect it may have to do with the way Firefox may try and prevent a second entry of form information (duplicate entry)--but this should NOT apply when the back button has been used to navigate back to the site. 

In all instances I've seen, this has only ever happened if the page itself has not been reloaded, merely gone back to by using the back button.

A legitimate use of the back button should clear whatever variable prevents duplicate entry, and this I think should solve the problem.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed on Windows XP. It is not a bfcache issue. Works fine with latest Opera, Google Chrome and IE7.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #1)
> It is not a bfcache issue.

Why?

> <form name="SearchForm" ...  nsubmit="showDiv('searchingmsg'); ...; return true;" id="SearchForm">
>(snip)
>            <input type="submit" name="searchButton" value="Search" class="SearchButton">
>(snip)
> </form>

> http://library.svu.edu/InfoCentre/assets/js/library.js
>(snip)
> function showDiv(layerName)
>   {
>(snip)
>      if(document.forms['SearchForm']){
>          document.forms[0].searchButton.disabled=true;
>       }
>    }  //end show div

I didn't check all JavaScript code. So I'm not sure that the  "document.forms[0].searchButton" in the script code always points to the submit button in the <form> coded in HTML source. But I think document.forms[0].searchButton.disabled=true; is the reason why submit button does do nothing after Back.
I believe main culprit is bfcache, because "Reload upon Back button"(it's normal expectation by Web developer) is never be executed due to bfcache. Needless to say, JavaScript code by site is an accomplice in a case.

Adding to bug list of meta Bug 415889.

Comment 3

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #2)
> (In reply to comment #1)
> > It is not a bfcache issue.
> 
> Why?

Because I tested it with browser.sessionhistory.max_total_viewers to 0 and still saw the issue.

Comment 4

[Ria Klaassen (not reading all bugmail)]

Regression range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-09-01+05%3A00&maxdate=2005-09-01+22%3A00
jst, could your bug Bug 304423 have caused this?

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> Because I tested it with browser.sessionhistory.max_total_viewers to 0 and still saw the issue.

FYI. Bug 314600 is report for same case.
(button is disabled by onSubmit script. See Bug 415889 Comment #2.)
> Bug 314600 Comment #4(on 2005-12-01) : max_total_viewers=0 was workaround. 
> Bug 314600 Comment #7(on 2007-08-22) : max_total_viewers=0 was not workaround.
>                                        (Mozilla v2.0.0.6, probably Fx 2.0.0.6)

Comment 6

[WADA:World Anti-bad-Duping Agency]

Symptom with bfcache=off(browser.sessionhistory.max_total_viewers=0) sounds for me same as Bug 425083(See Bug 425083 Comment #4 & Bug 425083 Comment #7).
Ria Klaassen, what do you think?

Comment 7

[Wayne Mery (:wsmwk)]

does this still fail?

Comment 8

[Ada [:adalucinet]]

Mozilla/5.0 (Windows NT 6.0; rv:25.0) Gecko/20100101 Firefox/25.0

WFM with latest Nightly (Build ID: 20130804030207): after navigating to the URL and click on Von Canon, the Search and Advanced Search works correctly after I press Back button.

Setting the Status of this bug to Resolved Worksforme; if anyone still encounters the issue or have more information to provide, please reopen.