697162 - Back & Forward browser buttons require Reload to work

Status: RESOLVED INCOMPLETE

(SeaMonkey :: General, defect)

Description

[Paul Raveling]

User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
Build ID: 20110928161145

Steps to reproduce:

1. Install SeaMonkey 2.4.1, first installation to see if it's ready for use.
2. Open the browser
---  In at least 2 iterations:  Experiment with link behavior settings.
Current setting is to open new links in same tab, but in use so far the behavior has not depended on link settings.
3. Open any web page, follow any link. See the "What happened" description of my test scenario.


Actual results:

The Back and Forward buttons remain grayed out and unusable, even with links opened in same window, same tab.

Experimenting with what little could be done, I found that each button is enabled only after pressing Reload.  Here's a minimal scenario:

1.  Bring up the browser. Mine is set to use a home page of http://www.sierrafoot.org/users/praveling/index.html -- A private home page on my web site.

2. Hit a link. Example:  The Google button (top left corner of the button array), which goes to Google web search. Google comes up in the same page, same tab, but the Back button is grayed out.

3. Hit Reload. The Back button switches to show that it's active.

4. Hit Back The Forward Button remains grayed out. An additional issues is that the Back Button is NOT grayed out, even though this is the home page.

5. Hit Back. It does nothing.

6. Hit Reload. Now the Forward Button gets its green highlighting and the Back button is grayed out.

7. If desired, hit Forward to prove it works.



Expected results:

The Forward and Back buttons each should have become active when a page was available as the target for those functions.

Actual behavior is consistent with inappropriate dependence on an internal state, set separately for each of these two buttons, and with the state enabled only by the Reload function.

Here's what I think is the most likely internal behavior:

1. Link traversal should have set an internal state to show that a "Back" page exists and should have correspondingly updated the GUI object. It did not do so.

2. The Reload remedy works because it refreshes the chain of linked pages, correctly identifies Back and Forward pages, and sets the GUI state correctly.

Comment 1

[Paul Raveling]

I've just encountered a case of the web browser having lost one URI in a chain of links, with Back skipping over a previously visited page and with Reload not effecting a recovery. There may be more at issue in tracking visited pages.

Comment 2

[therube]

WFM.

Any extensions, plugins?

Does it happen if you restart in Safe Mode (Help | Restart with Add-ons Disabled).
> Note, Safe Mode does NOT disable plugins.

Does it happen if you disable your plugins (Tools | Add-ons Manager -> Plugins)?

Does it happen in a new, clean Profile?

Comment 3

[Philip Chee]

Try running SeaMonkey in safe-mode. Go:
Help->Restart with Add-ons Disabled.

Comment 4

[Paul Raveling]

I may have tested plugins disabled at a very early stage but don't recall for sure. If I did, the problem was present. The problem reproduces in extremely simple usage, where I'm fairly sure no plugins are actually being used, and it seems unlikely that plugin initialization would would have any functional coupling to link traversal. In general though, operating without plugins isn't viable for me as a user. Consequently, I'm not retesting with plugins disabled.

I'm not going to follow up on this bug or some others for 2.4 at this time, will wait to check out a production version of 2.5. 2.4.1 is the first version of SeaMonkey that I've tried out, and for now I need to switch my own use back to Firefox/Thunderbird/Kompozer due to some relatively minor problems that are showstoppers for my own use.

Otherwise, I prefer the user interface of SeaMonkey over FireFox, Thunderbird, and Kompozer. It looks as if SeaMonkey and fox/bird family are parallel evolutionary branches off of the last Netscape, and SeaMonkey is ALMOST where I need need it to be to use it regularly. Unfortunately my personal time isn't yet free enough to follow or contribute to SeaMonkey development.

I'll tune in again when 2.5 goes production.

Comment 5

[Philip Chee]

> Consequently, I'm not retesting with plugins disabled.
Closing as INCOMPLETE since the reporter declined to follow some basic troubleshooting instructions.

Comment 6

[Paul Raveling]

Folks, I have a couple comments. The least important one is that I retested with plugins disabled and it worked.

The next bigger comment is that anyone else can do the same test in about 30 seconds, just as I did.

Now the biggest one:
Although my history has been one of stepping forward to personally take responsibility, apparently this development community doesn't share that ethic. As one who retired from the Oracle Server Technologies Division, I'll comment that Oracle wouldn't put up with this bug disposition.

On strictly tech reasons, the bug probably is due to a mode sensitivity in SeaMonkey, not a misfiring plugin.

In my time at Oracle mode sensitivities were the dominant cause of bugs in the RDBMS, and almost all were sorted out by QA processes before a buggy change could be merged into the code base. The main parts of those processes were (1) developer diligence in doing a change; (2) code review as a prerequisite for merging changes; (3) testing by the developer with appropriate test suites that normally run in nightly regression tests. There were also requirements for review and approval by group managers and release managers, but frankly testing is the most important step.

What this bug illustrates is (1) lack of an experienced developer stepping up to take responsibility and (2) general lack of discipline to do even a simple test that takes lest time than writing about it.

Because of this environment and the other bugs that were low-level showstoppers for my ability to use SeaMonkey I'm reconsidering. Maybe it's time for me to get back to part of my system development roots and roll my own software.

Comment 7

[Philip Chee]

> The next bigger comment is that anyone else can do the same test in about 30 seconds,
> just as I did.

Yes anyone else can do the same test. However not anyone has access to your computer where the problem occurs. As therube points out it WFM (WORKSFORME) on his computer.

I am familiar with Oracle Metalink support as a customer previously. Also my cousin ran Oracle third-level support for Greater China for several years. I'm pretty sure Oracle Support will insist that you follow their troubleshooting steps before escalating a support incident.

> On strictly tech reasons, the bug probably is due to a mode sensitivity in SeaMonkey,
> not a misfiring plugin.
Since you say disabling all your plugins and addons allows SeaMonkey to work, the immediate inference is that the problem is a misbehaving addon/plugin. Further troubleshooting steps will help confirm if this is indeed the case.

> lack of an experienced developer
The SeaMonkey project is an all volunteer community project dedicated to continuing development of the abandoned Mozilla Suite. We operate under the umbrella of the Mozilla project. However we do not have any paid developers or in fact paid anything. We are all doing this in our spare time.

> Maybe it's time for me to get back to part of my system development roots and roll my own software.
You obviously have a lot of experience in software development. Why not volunteer to help us fix our "low-level showstoppers"? We are a very small team and are short-handed in almost all areas. Someone with your experience would be extremely valuable to an open source project like ourselves.