671466 - If a page does not load, and the 'try again' button appears, it is disabled after a second page load failure.

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Dave Young]

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.

Comment 1

[Philip Chee]

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

Comment 2

[Dave Young]

Yes, it does happen in safe mode.

Regards,

Dave.

Comment 3

[Dave Young]

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.

Comment 4

[Tony Mechelynck [:tonymec]]

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.

Comment 5

[Dave Young]

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.

Comment 6

[Tony Mechelynck [:tonymec]]

(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)?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 8

[[e-mail]]

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.

Comment 9

[[e-mail]]

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

Comment 10

[[e-mail]]

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

Comment 11

[[e-mail]]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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?

Comment 13

[[e-mail]]

Attachment: Proposed patch

Indeed, that totally fixes it :-)

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 549442 [details] [diff] [review]
Proposed patch

Why the notcached change?

Comment 15

[[e-mail]]

Attachment: Proposed patch

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 549447 [details] [diff] [review]
Proposed patch

r=me

Comment 17

[[e-mail]]

Pushed changeset c8a0de7179e0 to mozilla-central.

Comment 18

[[e-mail]]

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 19

[LegNeato]

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 20

[Justin Wood (:Callek)]

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 21

[LegNeato]

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.

Comment 22

[Justin Wood (:Callek)]

(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

Comment 24

[(no longer active)]

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!

Comment 25

[(no longer active)]

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

Comment 26

[Justin Wood (:Callek)]

(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.

Comment 27

[Trif Andrei-Alin[:AlinT]]

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.

Comment 28

[[e-mail]]

(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.

Comment 29

[u279076]

qa- based on comment 28