Closed Bug 804529 Opened 12 years ago Closed 12 years ago

Search doesn't work second time after going back in history

Categories

(support.mozilla.org :: Search, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
2012Q4

People

(Reporter: martijn.martijn, Assigned: rrosario)

References

()

Details

(Whiteboard: u=user c=general p=1 s=2012.20)

Steps to reproduce:
- Go to http://support.mozilla.org/nl/questions/929653
- Type something in the search bar (e.g. 'test'), press enter
- Wait for the resulting page
- Go back in history
- Type something in the search bar again, try to submit

Expected result:
- Should be able to submit the search input

Actual result:
- Not able to submit a search

This is happening because after going back in history, you get the bfcached page in Firefox. 
And apparently, after a search, the form gets class="disabled" on it, which prevents submitting the form another time (this is done by some js on the page).
But that means the bfcached page in Firefox also still has this class="disabled" on the form.

I guess a solution would be to turn the form back on after 1 second or so, using a timer. That would prevent double submits, but would still allow to search again on a page that was bfcached.
We can probably do something on page unload.
Assignee: nobody → rrosario
OS: Windows 7 → All
Hardware: x86 → All
Whiteboard: u=user c=general p=1 s=
Target Milestone: --- → 2012Q4
Why does it get class="disabled", anyway? A double-submit on a GET is fine, since the request is idempotent.
We just have generic code that disables all forms on submit. But yeah, it could ignore forms with method="get". I am pretty sure it's an easy fix by attaching to page unload event anyway.
I fixed this during 2012.20:
https://github.com/mozilla/kitsune/commit/dc02aebce853cc4793c146c9f9062d495049a3dc

I'll deploy shortly.
Whiteboard: u=user c=general p=1 s= → u=user c=general p=1 s=2012.20
Deployed to prod.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Ok, it seems to work now, thanks. The only gripe with using an unload event handler is that it breaks bfcache in Firefox. So going back a page isn't that quick anymore.
Status: RESOLVED → VERIFIED
Since this is generic, does this mean that we are submitting another GET request as people are clicking the back button to get to the search results page? And that we were not doing that before? Depending on how often people click back that might have an impact on our KPI.
Flags: needinfo?(rrosario)
(In reply to Kadir Topal [:atopal] from comment #8)
> Since this is generic, does this mean that we are submitting another GET
> request as people are clicking the back button to get to the search results
> page?

Yes, it will result in a new GET.
Flags: needinfo?(rrosario)
I am going to change the code so that it only affects submitting forms over POST. That way it doesn't affect search.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #10)
> I am going to change the code so that it only affects submitting forms over
> POST. That way it doesn't affect search.

landed: https://github.com/mozilla/kitsune/commit/472dfb2bf533fcc1a4c9dfaa307cef9e861e36c6

Will be deployed shortly.
perfect, thanks!
You need to log in before you can comment on or make changes to this bug.