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

RESOLVED FIXED in Firefox 6

Status

()

Core
Document Navigation
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Dave Young, Assigned: neil@parkwaycc.co.uk)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla8
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox6 fixed, firefox7 fixed)

Details

(Whiteboard: [status-firefox-6:fixed for SeaMonkey 2.3 only][qa-])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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

6 years ago
Does this happen in safe mode?
Go Help->Restart with Add-ons Disabled.
(Reporter)

Comment 2

6 years ago
Yes, it does happen in safe mode.

Regards,

Dave.
(Reporter)

Comment 3

6 years ago
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.
(Reporter)

Comment 5

6 years ago
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.
(Assignee)

Comment 8

6 years ago
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.
(Assignee)

Comment 9

6 years ago
So, it appears that the button on the page isn't the one that was disabled...
(Assignee)

Comment 10

6 years ago
Instead, in Firefox, the "Get Me Out Of Here..." button is getting disabled...
(Assignee)

Comment 11

6 years ago
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?
(Assignee)

Comment 13

6 years ago
Created attachment 549442 [details] [diff] [review]
Proposed patch

Indeed, that totally fixes it :-)
Assignee: nobody → neil
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #549442 - Flags: review?(bzbarsky)
Comment on attachment 549442 [details] [diff] [review]
Proposed patch

Why the notcached change?
(Assignee)

Comment 15

6 years ago
Created attachment 549447 [details] [diff] [review]
Proposed patch

Without parts of bug 160144 this time... Sorry about that.
Attachment #549442 - Attachment is obsolete: true
Attachment #549447 - Flags: review?(bzbarsky)
Attachment #549442 - Flags: review?(bzbarsky)
Comment on attachment 549447 [details] [diff] [review]
Proposed patch

r=me
Attachment #549447 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 17

6 years ago
Pushed changeset c8a0de7179e0 to mozilla-central.
Blocks: 364903
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Component: General → Document Navigation
Keywords: regression
OS: Windows XP → All
Product: SeaMonkey → Core
QA Contact: general → docshell
Hardware: x86 → All
Resolution: --- → FIXED
Version: SeaMonkey 2.1 Branch → Trunk
(Assignee)

Comment 18

6 years ago
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.
Attachment #549447 - Flags: approval-mozilla-beta?
Attachment #549447 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

6 years ago
Blocks: 675316

Comment 19

6 years ago
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.
Attachment #549447 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
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.
Attachment #549447 - Flags: approval-mozilla-beta- → approval-mozilla-beta?

Comment 21

6 years ago
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.
Attachment #549447 - Flags: approval-mozilla-beta?
Attachment #549447 - Flags: approval-mozilla-beta-
Attachment #549447 - Flags: approval-mozilla-aurora?
Attachment #549447 - Flags: approval-mozilla-aurora+
(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
status-firefox6: --- → fixed
status-firefox7: --- → fixed
Whiteboard: [status-firefox-6:fixed for SeaMonkey 2.3 only]
Target Milestone: --- → mozilla8

Updated

6 years ago
Duplicate of this bug: 678876
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.
(Assignee)

Comment 28

6 years ago
(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
Whiteboard: [status-firefox-6:fixed for SeaMonkey 2.3 only] → [status-firefox-6:fixed for SeaMonkey 2.3 only][qa-]
You need to log in before you can comment on or make changes to this bug.