User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 OS: Windows XP Pro SP3 If a web page does not load, and the try again button appears, clicking the try again button attempts to load the web page a second time. If it still fails to load, the try again button is disabled, so it has no effect. This happens in SeaMonkey 2.1 and 2.2. Reproducible: Always with, currently, www.tunetribe.co.uk. Steps to reproduce: 1. Have page not load 2. Click try again 3. If the page again fails to load, the try again button is disabled. Expected Result: After the second page load failure, the try again button should be enabled, as is the case with SeaMonkey 1.1.19.

Does this happen in safe mode? Go Help->Restart with Add-ons Disabled.

Yes, it does happen in safe mode. Regards, Dave.

I posted a message ([url=http://forums.mozillazine.org/viewtopic.php?f=40&t=2249819]'Try Again' after 'Network Timeout' problem[/url] about this on the MozillaZine forum. Andy Boze replied that he: "Didn't know whether it was a bug or a feature." Regards, Dave.

Possible workaround: What I do in such a case is click the Go button (or click at the end of the URL bar then hit Enter); and if the browser doesn't seem to react (the throbber doesn't start throbbing) click "Reload" then.

Yes, I'm aware of the workarounds, but something has changed between SeaMonkey 1.x.x and SeaMonkey 2.1/2.2. I would have thought it ought to be possible to fix it? Regards, Dave.

(In reply to comment #5) > Yes, I'm aware of the workarounds, but something has changed between > SeaMonkey 1.x.x and SeaMonkey 2.1/2.2. I would have thought it ought to be > possible to fix it? > > Regards, > > Dave. Sure, it "ought" to be possible, but will it and when? That is not my province. Does anyone know if the same behaviour happens also on Firefox (Fx4 and later)?

> Does anyone know if the same behaviour happens also on Firefox (Fx4 and later)? It does not. But there was a bug about it at some point that got fixed. May be worth looking into.

So, it looks as if HTML button elements deliberately save their disabled state across reloads. But, try as I might, I can't find out where to break to find out how Firefox's button gets re-enabled.

So, it appears that the button on the page isn't the one that was disabled...

Instead, in Firefox, the "Get Me Out Of Here..." button is getting disabled...

So, what happens is that before the custom certificate error page was created, Firefox added two buttons to its error page via the DTD. It is one of these buttons that gets disabled when the page reloads.

Oh, so Firefox is just relying on a bug in the form state restoration behavior? Nice. If the real issue here is form state restoration, does adding autocomplete="off" to the button help?

Indeed, that totally fixes it :-)

Comment on attachment 549442 [details] [diff] [review] Proposed patch Why the notcached change?

Without parts of bug 160144 this time... Sorry about that.

Comment on attachment 549447 [details] [diff] [review] Proposed patch r=me

Pushed changeset c8a0de7179e0 to mozilla-central.

Comment on attachment 549447 [details] [diff] [review] Proposed patch This fix enforces behaviour that Firefox was previously achieving by luck; SeaMonkey wasn't so lucky.

Comment on attachment 549447 [details] [diff] [review] Proposed patch Denied for mozilla-beta. If the SM team wants this they can land it on their own relbranch or if they really need it on default please feel free to lobby us harder and renominate.

Comment on attachment 549447 [details] [diff] [review] Proposed patch > or if they really need it on default please feel free to lobby us harder and renominate. This is a very very simple change, doesn't break/change any API. No change of behavior for Firefox. The affect of patch is that "Retry" for a network error can actually retry more than once. Due to a "lucky" hit of a different bug Firefox was avoiding this particular issue, but if that other-bug was fixed would need this fix as well. I'm renominating because relying on a relbranch for these landings complicates our release process a lot, where its much easier to go on a Firefox Tag.

Comment on attachment 549447 [details] [diff] [review] Proposed patch Denied for beta again. We don't want to take this in our last beta. We're approving it for releases/mozilla-aurora, even though it doesn't really meet the aurora criteria...mainly because the potential downsides look trivial and it's always good to help out dependent projects.

(In reply to Christian Legnitto [:LegNeato] from comment #21) > Denied for beta again. We don't want to take this in our last beta. We're > approving it for releases/mozilla-aurora, even though it doesn't really meet > the aurora criteria...mainly because the potential downsides look trivial > and it's always good to help out dependent projects. Since I pushed to m-beta as well (on a SeaMonkey relbranch) I'm marking status-firefox-6:fixed, and adding notes for that in whiteboard as well. Also just pushed to aurora. http://hg.mozilla.org/releases/mozilla-beta/rev/f327eb465d32 http://hg.mozilla.org/releases/mozilla-aurora/rev/bd419b4cdaea

We're not taking this bug for the beta migration, but if you guys wanna take this for your own relbranch again on beta, please do so!

Nevermind, this _is_ in beta: http://hg.mozilla.org/releases/mozilla-beta/rev/bd419b4cdaea

(In reply to Ehsan Akhgari [:ehsan] from comment #24) > We're not taking this bug for the beta migration, but if you guys wanna take > this for your own relbranch again on beta, please do so! This actually was referring to our relbranch-only landing of this bug. It did infact properly migrate from Aurora [7] to Beta [7]. So will be in our next release without a need for a manual relbranch.

Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0 I followed the steps in reproduceing this issue, but Firefox works as expected. Is there another way to test this issue or are the steps in the description enough? Thanks.

(In reply to Trif Andrei-Alin from comment #27) > I followed the steps in reproduceing this issue, but Firefox works as expected. As per comment #12, Firefox doesn't exhibit this bug because of another bug.

qa- based on comment 28