Last Comment Bug 671466 - If a page does not load, and the 'try again' button appears, it is disabled after a second page load failure.
: If a page does not load, and the 'try again' button appears, it is disabled a...
Status: RESOLVED FIXED
[status-firefox-6:fixed for SeaMonkey...
: regression
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla8
Assigned To: neil@parkwaycc.co.uk
:
Mentors:
: 678876 (view as bug list)
Depends on:
Blocks: 675316 364903
  Show dependency treegraph
 
Reported: 2011-07-13 18:40 PDT by Dave Young
Modified: 2011-09-22 16:07 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed


Attachments
Proposed patch (3.22 KB, patch)
2011-07-29 12:48 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Review
Proposed patch (1015 bytes, patch)
2011-07-29 12:59 PDT, neil@parkwaycc.co.uk
bzbarsky: review+
christian: approval‑mozilla‑aurora+
christian: approval‑mozilla‑beta-
Details | Diff | Review

Description Dave Young 2011-07-13 18:40:59 PDT
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 2011-07-16 09:18:24 PDT
Does this happen in safe mode?
Go Help->Restart with Add-ons Disabled.
Comment 2 Dave Young 2011-07-16 10:34:10 PDT
Yes, it does happen in safe mode.

Regards,

Dave.
Comment 3 Dave Young 2011-07-16 10:47:41 PDT
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] 2011-07-16 13:33:32 PDT
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 2011-07-16 15:27:06 PDT
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] 2011-07-16 15:50:06 PDT
(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 [:bz] (Out June 25-July 6) 2011-07-19 08:46:08 PDT
> 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 neil@parkwaycc.co.uk 2011-07-29 07:46:34 PDT
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 neil@parkwaycc.co.uk 2011-07-29 10:15:38 PDT
So, it appears that the button on the page isn't the one that was disabled...
Comment 10 neil@parkwaycc.co.uk 2011-07-29 10:27:40 PDT
Instead, in Firefox, the "Get Me Out Of Here..." button is getting disabled...
Comment 11 neil@parkwaycc.co.uk 2011-07-29 12:10:40 PDT
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 [:bz] (Out June 25-July 6) 2011-07-29 12:15:03 PDT
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 neil@parkwaycc.co.uk 2011-07-29 12:48:10 PDT
Created attachment 549442 [details] [diff] [review]
Proposed patch

Indeed, that totally fixes it :-)
Comment 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-07-29 12:55:32 PDT
Comment on attachment 549442 [details] [diff] [review]
Proposed patch

Why the notcached change?
Comment 15 neil@parkwaycc.co.uk 2011-07-29 12:59:28 PDT
Created attachment 549447 [details] [diff] [review]
Proposed patch

Without parts of bug 160144 this time... Sorry about that.
Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-07-29 13:11:51 PDT
Comment on attachment 549447 [details] [diff] [review]
Proposed patch

r=me
Comment 17 neil@parkwaycc.co.uk 2011-07-29 13:45:26 PDT
Pushed changeset c8a0de7179e0 to mozilla-central.
Comment 18 neil@parkwaycc.co.uk 2011-07-29 13:52:06 PDT
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 christian 2011-08-01 14:43:19 PDT
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) 2011-08-01 16:04:49 PDT
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 christian 2011-08-02 14:47:16 PDT
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) 2011-08-04 23:34:52 PDT
(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 23 Justin Wood (:Callek) 2011-08-14 17:45:34 PDT
*** Bug 678876 has been marked as a duplicate of this bug. ***
Comment 24 :Ehsan Akhgari (out sick) 2011-08-16 10:42:49 PDT
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 :Ehsan Akhgari (out sick) 2011-08-16 11:05:32 PDT
Nevermind, this _is_ in beta: http://hg.mozilla.org/releases/mozilla-beta/rev/bd419b4cdaea
Comment 26 Justin Wood (:Callek) 2011-08-16 11:07:48 PDT
(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] 2011-08-26 01:58:10 PDT
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 neil@parkwaycc.co.uk 2011-08-26 07:03:03 PDT
(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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-22 16:07:37 PDT
qa- based on comment 28

Note You need to log in before you can comment on or make changes to this bug.