Closed Bug 112282 Opened 23 years ago Closed 22 years ago

Navigate back/forward stops working in some cases

Categories

(SeaMonkey :: General, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 126826

People

(Reporter: earthsound, Assigned: jag+mozilla)

References

Details

(Keywords: qawanted, regression, testcase, Whiteboard: [adt2][Hixie-P0][Hixie-1.0][MB])

Attachments

(5 files)

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

I noticed while I was waiting for bugzilla to print the page of email addresses,
after I submitted a bug comment, that the Back button was shaded. I figured it
would come back after the page was loaded. It didn't. Although it was shaded
(indicating there is no Back history) I could right click on the button and
access the Back history. The first screenshot is of the Back button menu
accessed via right clicking, although the button itself is shaded. 

Also, when I navigated back to one of the pages in the Back history, I noticed
the Forward button was shaded (indicating there was no Forward history) although
when I right clicked on the Forward button, the Forward history showed up...that
is what you'll see in the second screenshot. 

Additionally, I can't press Alt+<- (left arrow) to go back to previously viewed
pages, or Alt+-> (right arrow) to go forward in the history...I have to
right-click on the shaded buttons. 

And finally, the Go>Back & Go>Forward menu items are also shaded and
inaccessible, though both histories are there...

Reproducible: Didn't try
Steps to Reproduce:
I'm not sure how to repro...if I'm able to, I'll post it here.

See screenshots if this sounds confusing to you :)
Notice at the bottom of the expanded Go menu that there are pages to go to both
Back and Forward from the current page, but they're inaccessible via the Go
menu or the Alt+ shortcuts
over to claudius to test.

fwiw, the keybd shortcuts alt+left and alt+right WFM on winNT, 2001.11.28.06-comm.
QA Contact: sairuh → claudius
*** Bug 113076 has been marked as a duplicate of this bug. ***
okay, now i am seeing this...it's erratic and i'd like to get a better test case
to get into this state. in any case, it's very annoying, because it's occurring
about 50% of the time.

most notably, i'm encountering disabled Back and Forward buttons. moreover, the
shortcuts are also dead, and the Go menu no longer displays previously visited
items which should be listed.

-> session history, confirming. all platforms since i see it on linux and
claudius has noticed on mac.
Assignee: blakeross → radha
Severity: major → critical
Status: UNCONFIRMED → NEW
Component: XP Apps: GUI Features → History: Session
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
cc'ing xpapps folks. It looks like a regression in the UI of the back/forward
buttons and menus rather than a problem with session history.
It looks like there could be  a problem with the onLocationChange notification
that triggers the sensitivity of the back forward buttons. 
Steps to reproduce this would be great. I haven't seen this problem yet.
For the record, I might have a reproducible sequence.

This assumes Mozilla browser is not the first item to start, but Mail/News is. 
(As it is for me.)

(1) Start Mozilla.  Mail/News comes up.
(2) Open Mozilla browser after Mail/News is done.
(3) Visit a website.
(4) Visit a link on the website.

I only notice this bug on the first browser instance.  Second instances (like a
second tab) do not appear to have this bug.  See my comments in dupe bug 113076.
Look at the javascript console (under Tasks -> Tools) when this happens. Are
there warnings / errors there that seem related?
Yes, one error per webpage visited.  (I have strict JS warnings disabled for now.)

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIWebNavigation.canGoBack]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://navigator/content/navigator.js :: UpdateBackForwardButtons :: line 215"
 data: no]
Source File: chrome://navigator/content/navigator.js
Line: 215
I recently made some changes to nsDocShell:;CanGoBack()/CanGoForward(). These
changes were primarily to reduce footprint rather than change the functionality.
Shall check if I broke this behavior when I fixed it.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
In today's build, when I invoke mail first and later the browser, the browser 
window has no session history created for it.  This causes the assertion in 
nsIWebNav->GetCanGoback() and you can not go back/forward thro' any means. 
However, an instance of session history is created for the second and 
later browser windows. Where is session history created for the browser window? 

I do not see this problem on 11/27 build, but it is there in 12/3 build. 
It should be created in the browser's constructor in browser.xml:

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/browser.xml#252

There was a redundant setter for session history in navigator.js that I recently
removed, since session history was already being set from the constructor in
browser.xml. This was probably hiding the bug we're seeing now. Adding that code
back to navigator.js is not the right thing to do, so let's figure out why
session history isn't getting set correctly from the browser's constructor.
This may be related.  About the same time I noticed this bug, I started
noticing a smallish square appearing from time to time near the back button.

It toggles visible and invisible when I:
* click or right click the down arrow for multiple back, or
* right click the back button.

Its position is highly unusual, occurring right over the horizontal line
separating the personal toolbar from the navigation toolbar.
Attachment #60668 - Attachment description: Strange toggleable swuate below and left of back button → Strange toggleable square below and left of back button
History is totally broken!

Testcase:
Start Mozilla to Mail/news.
Clear History (Edit, Preferences, Navigator, History, Clear History)
Visit two sites in sequence.  They must be totally different domains.
Open History.

Note History shows NO entries to date.

Open a tab.
Visit the same two sites in sequence.

Note History now shows two entries to date.
Keywords: testcase
Summary: The Back/Forward buttons are shaded (and Alt+<- & Alt+-> don't work) & the Go>Back & Go>Forward menu items are shaded, although there is a Back & Forward history (that is viewable by right clicking on the buttons) → History is broken in browser windows opened from mail/news
FWIW, when I run the testcase, starting Composer first instead of Mail/News,
Mozilla handles the history correctly.

And if I was paying attention to what people were saying, I wouldn't have
flooded people's boxes with the three spam above.  Sorry.
I think global history is not being created (just like session history)in the
browser's  constructor. I'm handing over this bug to the xpapps team, as the
problem is in browser code. 
Assignee: radha → jaggernaut
Status: ASSIGNED → NEW
Component: History: Session → Browser-General
modifying summary so that my queries will find this more easily.
Summary: History is broken in browser windows opened from mail/news → History is broken in browser windows opened from mail/news (Back, Fwd buttons disabled, Go menu not updated)
Changing summary back to original, as I had no mail/news opened when I noticed &
reported this bug. Also, notice that in attachment 59426 [details]
(http://bugzilla.mozilla.org/attachment.cgi?id=59426) the Go menu *was* updated,
but the Back & Forward menu items were not accessible. FWIW, I cannot reproduce
this bug when following the steps in comment #10. When I ran across this bug, it
came up while I was waiting for the confirmation page to load after I commented
on bug 59108. Before that, the history appeared normal, that's why I even
noticed it, and initially thought it would go back to normal. Also, I think the
lack of a
history, per comment #17, is an unrelated bug and should be opened separately. 
Summary: History is broken in browser windows opened from mail/news (Back, Fwd buttons disabled, Go menu not updated) → The Back/Forward buttons are shaded (and Alt+<- & Alt+-> don't work) & the Go>Back & Go>Forward menu items are shaded, although there is a Back & Forward history (that is viewable by right clicking on the buttons)
jaggernaut -- as the bug's owner, would you please pick an official summary for
this bug, and post the reporter's summary as a comment so we don't lose it?

A summary that long is extremely annoying, with no disrespect to the reporter or
anyone else.
Hmmm... I'm guessing the "history doesn't work when browser first opened from
mail/news" is a different one than this bug. Also, I didn't remove the session
history stuff from navigator.js until the 29th, and this bug was reported the
27th, so it can't be related to this bug, though it may still be related to the
"launched from mail/news" one, which I can't reproduce on my machine btw. Alex
Vincent, could you file a new bug for that, assigned to me for now?

I don't know what's going on with the original case, though it sounds like
something in session history code going wrong, e.g. canGoBack returning false
when it should return true, which causes the back button and alt+left to be
disabled. For further investigation, I'll need a reproduceable testcase.

Resetting target milestone, reducing severity to "major".
Severity: critical → major
Summary: The Back/Forward buttons are shaded (and Alt+<- & Alt+-> don't work) & the Go>Back & Go>Forward menu items are shaded, although there is a Back & Forward history (that is viewable by right clicking on the buttons) → Navigate back/forward stops working in some cases
Target Milestone: mozilla0.9.7 → ---
Reopening bug 113076 for the "history doesn't work when browser first opened from
mail/news" issue and assigning to jaggernaut, as directed.
I see that this bug was reported on 11/27, but jag didn't change navigator.js
until 11/29. Based on the original comments in this bug, it looks like, the
original problem was not  easily  reproducible until comment #10 showed up on
12/4.  The original problem is a sign of onLocationChange() not firing properly.
That's why the buttons didn't get updated, even though there was history
available. But the situation got further degraded when navigator.js was changed.
I think bug 113076 should be addressed first and then this one.
*** Bug 114172 has been marked as a duplicate of this bug. ***
*** Bug 114146 has been marked as a duplicate of this bug. ***
This bug is still occuring with the latest release, which has been deleted from
the machine due to its instability. Anyway, I noted that it ALWAYS occurs with
the initial browser window when both the BROWSER and MAIL options are set to
automagically start when the program starts. Close the initial browser window
and reopen it makes the thing work just fine. It is 100% of the time and happens
on occasion with Netscale 6.2.1 - not with 6.2.
*** Bug 114704 has been marked as a duplicate of this bug. ***
FWIW I have a 100% reproducible case. And this has nothing to do with Mail/News.
An interesting thing I noted was that if I create a new profile then everything
works ok. (I basically moved my .mozilla away for a while and things worked just
fine with a new one created and when I moved it back-- this bug reappeared)
we gotta get this fixed for mozilla 0.9.7
Radha helped me point out that the browser.sessionhistory.maxentries in my
prefs.js was somehow set to 0 and when I reset it back to 50 everything works
fine. The big question now is why is that pref being set to 0. 
true , if i move my prefs.js out of the way and build new one from scratch it
works for a __WHILE__, probably until i set mail to come up first, then buttons
arebroken again, see bug 114671 ( a duplicate of this one, apparently) 
-Sobert Somerville
FWIW s/maxentries/max_entries/
I have no entry for 
browser.sessionhistory.maxentries 
in my prefs.js

I still have this problem.
This bug has nothing to do with any pref settings. If someone is running into
that then can you please file another bug so we can track it separately. 

This bug is for the case were creating a browser window from mail causes it to
not have session history. Someone also reported that the first stand alone
browser may also have this problem. I suspect this should be considered a 097
stopper since there is a data loss issue (I and others have had scenarios were
we read a bug message, click on the link, modify the bug, hit post just to get a
bugzilla collision and no way to go back and resubmit).
Actually, that's why I reopened bug 113076.  See comments 23 through 25.
mscott, there appear to be two distinct bugs (three if you count gagan's, but
more on that in a bit).

The first one is the one descibed in here, where Session History works for a
while in a browser window, and then stops. I don't know yet what's causing this.

The second one is where session history doesn't work in the first browser window
opened from mail/news, or when it's opened together with mail/news from startup.
This is a known bug where the docshell is somehow not created at the time the
browser's xbl constructor fires, so we can't initialize its session and global
history objects. We don't know yet why the doscshell wasn't created by that
time, we're looking into that.

gagan's problem seems to be the result of the preferences bug this weekend that
erased fields in panels you've viewed, so in his case the default of 50 would've
been set to 0.
do we know what set of changes brought this on or brought greater exposure to
the problem?

if we do, backing out these changes would be the right thing for the milestone
until we have more time to investigate why we see these side effects.
Blocks: 114455
See bug 113076. Please post follow-up comments for that patch there, since it
won't fix this bug.
Are we nearing a patch for this bug?  This bug can cause data loss!
No patch for this particular bug yet, since it rarely shows up and we have no
set of steps to reproduce it. There is a patch for bug 113076 though.
*** Bug 115378 has been marked as a duplicate of this bug. ***
Can anyone still see this bug now that the work-around for 113076 is in place?
seems to be working in the 12/18 build on win98 in my case where I start
mail/news and browser at startup, and that first browser window had no back/forward.
Yes, it is still there as of this writing with one change. The problem I was
having 100% of the time was that it required closing of the first window and
reopening to get it working. Now at my.yahoo.com, I find that I have to still
close the first window and reopen twice in order to keep from backing out to the
sign-on screen from the site. For instance, once inside my.yahoo.com, in the
initial window click on a news link to read an article, click on the
back/forward, returns you to the sign-in screen. After exiting the windows 2
times, clicking on the back/forward window from an article returns you to the
regular my.yahoo.com main menu screen. So yes, it is still a problem.
In regards to comment #45 and #46 (chofmann and blcinger) are you sure you are
talking about bug 112282 which deals with loss of history in a working browser?
It sounds very much like you are talking about bug 113076 which is specifically
for the frist browser window created after a FRESH start of Mozilla (mail). Jag
already has a fix for bug 113076 on the trunk and on the 0.9.7 branch. If you
can recreate bug 112282 (look at the original post and comment #6 MOST of the
other posts on this bug are actually for 113076) please post steps to reproduce.
bclinger: I suspect that is a different bug, since this one is about having no
session history at all, or put differently, you won't be able to go back at all.

chofmann: I suspect then that you were seeing bug 113076, but please correct me
if I'm wrong and you actually saw the bug as described in the initial report or
in comment 6.

se: can you tell us what the steps are you refer to in comment 6? 
Well, I posted this as a reply due to being in a hurry and now I find that I
cannot copy the information from the mailer to the clip board for inclusion
here, so I gotta retype it. <G>. Anyway - after re-reading the note and what I
typed, you are absolutely correct to point out that I was confused. Not the same
bugs, however, just as annoying. Now with this build, 2001121803, we have a new
bug that prevents me from selecting text from a displayed message in the mail
function. Bugs!
fwiw: FYI.

perfs problems.. was hosed and changed values of "true" & "false" where not
being read/written to correctly.. from 12-4+ builds.. see bug 113482, bug
114299, and bug 114630 for that if interested.


bclinger: I noticed the context menus' in message pane is not the same as
before.. either disabled for now, as all the context menu items do not work as
intended or are partially implemented.. or some other code caused the context
menu to not sure all the items listed.  Its been this way for several builds now.
also bclinger that text selection bug is also fixed in the 2:17pm build for 12-18.
I noted this morning that the select all/edit functions were back like they
should be. Thanks for the fast repair, all. Ben
No longer blocks: 114455
Until I get a reproducible testcase: -> future
Target Milestone: --- → Future
nsbeta1+ per Nav triage team., clearing future for retargetting.
Keywords: nsbeta1nsbeta1+
Target Milestone: Future → ---
as discussed w/jag over email, this bug doesn't really deserve a nsbeta1+
nomination *until* we have a clear, reproducible case. the time i've encounter
this was in bug 113076, which has a workaround.

clearing nomination --yeah, i know i had put in the nsbeta1 originally. again,
the workaround in bug 113076 seems to suffice for me nowadays. renominate if a
more reliable testcase crops up --in other words: is this still happening
reliably for anyone else, with a recent trunk build? thx!
Keywords: nsbeta1+qawanted
The number of 6.2 users who sent in feedback about their back and forward
buttons being inappropriately disabled is astounding.   We seem to keep pushing
the back/forward bugs around from release to release because we can't reproduce
it, but it's pretty clear that users can.  I think there needs to be some
nsbeta1+ bug open to fully investigate this issue and what might cause it.
Keywords: nsbeta1
This patch ensures that we default to 50 if we can't get the pref for any reason
(e.g. if it doesn't exist).  There is, of course, more to this bug.  attachment
59425 is intriguing, showing that it is indeed a problem with either
onLocationChange firing or canGoBack/Forward returning the wrong result.
Blake, there is no proof in this bug or any of the other bugs  referred here
that there was/is a serious problem with the prefs settings. Your changes
provide a safety situation if something goes wrong with prefs. I  provide a
r=radha  just for that. This bug should be marked fixed after this patch is
checked in.  

Someone mentioned about a problem with my.yahoo.com. That is being addressed in
a separate bug assigned to me for 0.9.9
I know; it's just a safety patch I happened to notice while investigating.  I
just checked this patch in, but I don't think this bug should be closed yet. 
attachment
59425 [details] clearly shows that there's some sort of problem with enabling the buttons
at the proper times.  The 6.x user comments indicate that it's not limited to a
small subset of pages (e.g. my.yahoo.com).
FWIW, for bugs that first usage happens, then works the second time:

I have noticed that over several months here.. there are many bugs that occur on
first usage, but work fine the second+ time it gets used, many are related to a
the first browser window or first Mail/News window startup itself: Mail/News has
a ton of them, browser has a ton, sidebar, and menus/widgets, and Menu tasks
<any task or function here> I can name alot of them off the top of my head. 
Many have been fixed up over that time.  

Not to start a discussion and change the bug or anything:

but, in regards to this, I'd say Mozilla's got some problem with first
initiation of an instance out of a first browser or mail/news window that has
been causing bugs like this.  
nsbeta1+ per Nav triage team.  Lack of reproducible case is not sufficient
reason to push this out, it has affected too many people.  We can't ship with
this problem again, so we need to ensure that we apply whatever bullet-proofing
we can, and be very sure that it goes away.
-> 1.0 then.
Target Milestone: --- → mozilla1.0
I just created a testcase for this. Visit site.
http://bugzilla.mozilla.org/attachment.cgi?id=53852&action=view. Click on
checkbox called "Show Image Section". Now try to go back.
Keywords: mozilla1.0
Also, if you go back a few pages from that page and go forward, the forward
button stops working.
Yes, this testcase is 100% reproducible. Note that you have to navigate to this
link in current window to have some other pages in history.

I don't know why should the javascript mess up with the history. It seems to do
only some display="none"/"block" switching in inline stylesheet.
Whiteboard: [adt1]
Changing to ADT2 per ADt triage.
Whiteboard: [adt1] → [adt2]
Priority: -- → P3
Nav triage team needs info: Is anyone seeing this using current builds on top sites?
Whiteboard: [adt2] → [adt2] [need info]
2 things I noticed about the test case from comment 64:

It doesn't cause the Back/Forward buttons or the Back & Forward options under
the Go menu to be shaded, as per the original manifestation of this bug,
although functionality (or lack thereof) is similar.

The javascript adds items to my Back/Forward history list although only two
pages have been visited (this bug page and the test case). Is this normal?
Another shortfall of the testcase in comment 64 is that functionality returns
quite easily in the same browser session, though in the original bug
manifestation I had to close Mozilla and relaunch it to get my Back/Forward
buttons (and their functionality) back. It seems as though the javascript test
case is triggering only a partial manifestation of this bug...
removing plus for re-triage
Keywords: nsbeta1+nsbeta1
nsbeta1- per Nav triage team
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha
Early PR feedback shows that this is still a problem.  I'm convinced it's some
type of profile corruption.  We have to do something to remedy it, but I have no
idea what.  A new development in the PR feedback is that the Stop button also
does not work, but Reload does.  Perhaps we should contact some of these users
for the contents of certain files (contact me for the e-mail addresses):

"I am unablt to use the back arrow or GO > BACK
functions... They are always grayed out and do not
work.  This was a problem in v 6.0 as well.  It is
a very frustrating problem and I would LOVE a
resolution to this.  Thanks!"

"THe back and forward buttons are greyed out and
inactive on this version/os combiniation. As well,
when right clicking on the page, those two choices
are greyed out."

"When I first used Netscape 6.2.2. I was not able
to use the back and forward buttons in the
navigations toolbar when I viewed other web pages.
Today I download 6.2.3 and had the same problem.
When I tried out the prerelease of 7.0 the same
problems occured."

"I have tried netscape 6.1 6.2 and so on and now
7.......and the back and forward buttons don't
work.  I get so frustrated that I go back to the
microsoft program.  My computer can't be the only
on that these programs fail on."

"Unable to use either the back or forward buttons
on Netscape 7PR1"

"I just bought the N6.2 CD & owners book. It worked
fine, N7 has buttons... be nice if they worked.  I
uninsatlled N7 & what ever is causeing the Back &
Forward button not to work gets picked up by some
sort of an artifact left behind after uninsatl. 
This is is aperfect example of why uninstal should
be exactly that UNINSTAL.  Now I have to try and
find all the dam artifacts left in the registry &
get them out , before reloading N7.  Maybe next
year, when I have some time.
I'd be happy to work with anyone to try & get a fix."

"Back/Foward button on tool bar will not respond to command"

"back button doesn't work on toolbar or from "Go"
drop down screen"

"both back and forward buttons are unuseable 
(greyed) and will not activate.  I have no way to 
going between visited web pages.  I cannot find 
another way of activating the buttons."

"hen I am browsing the web I can not use the back
or forward buttons. You can push them all you want
and it does nothing. The stop button also doesn't
work but the reload button does work."

"The foward/back arrows do not work.  Only the
refresh button does.  This has happened to me
recently in Netscape 6.1 browsers also.  This has
just started recently, and has never happened before."

"When using the browser I can not use the buttons
for forward. back or even stop when browsing,
happens all the time."

"The Back button on Netscape 7 isn't working"
Keywords: nsbeta1-nsbeta1
Whiteboard: [adt2] [need info] → [adt2]
Whiteboard: [adt2] → [adt2][Hixie-P0][Hixie-1.0][MB]
earthsound: can you still reproduce this?
Ian, 
  I have not reproduced this since 1.0RC2, but I haven't used RC3 nearly as much
yet. Also, I have not identified what triggers it. 

  Something else I've noticed with the test case in comment #64 is that the js
only disables the Back/Forward buttons while viewing the pages that contain that
js trigger, and even on those pages, it is only disable when trying to go
forward from the first page containing the js to the 2nd and vice versa.

  I.e.: if you visit several pages before checking out the testcase @
http://bugzilla.mozilla.org/attachment.cgi?id=53852&action=view, you can use the
down-facing back arrow button to go to a page visited before the pages titled
"Navigator/Messenger context menus". From there, the Back/Forward buttons and Go
menu have full functionality, until you try to use them on one of the
"Navigator/Messenger context menus" titled pages as described in the last ¶. 

  Wish I had a better test case...although I think the one above may touch on
part of the problem. 
Claudius, can you reproduce this?
If anyone can reproducing this, it would be most helpful if they could
immediately create a tarball or zip file of their entire profile directory, then
say so in this bug so that we can get a copy of the profile. (Don't attach the
profile to the bug as it can contain sensitive personal information.)
Evelyn says: we are seeing quite a bit of feedback citing this problem in
Netscape 7.0 PR1 newsgroups.
Can we make it so that you can't have 0 for "Number of pages session history"?

Have a minimum value of 1 or 5 or so.
1.0.1 drivers say: We need to get a handle on this bug for 1.0.1, even if it's
wallpaper.  Clearing target, nominating for 1.0.1
Severity: major → critical
Keywords: mozilla1.0mozilla1.0.1
Target Milestone: mozilla1.2alpha → ---
Is this the same as Bug 141290?  That one has a ton of dups.
141290 is the same problem as this one. However there is a comment there that
says that the problem disappeared after doing a reinstall.  All the dupes in
that bug are essentially  the same problem, assigned to different people in the
browser team
and me. Also look at bug 126826, which could also be a dupe of thsi one. 
The problem described in comment #64 is probably the same as bug 129590. I don't
believe it is related to the original problem described here, which is back and
forward completely disabled in a fresh installation (probably) due to corruption
 in prefs or profile.  Please discuss issues related to div.innerHTML and
div.display in bug 129590.
I still can't reproduce this. I'm still trying but no luck so far. Suggestions
are welcome and encouraged
nsbeta1+/adt2 per Nav triage team.  We need to resolve this, if only via some
wallpaper/bulletproofing.
Keywords: nsbeta1nsbeta1+
I think we should try to set up a test environment similar to a end user's
environment probably with a previously installed Mozilla or netscape
installation and/or shared profile. We should probably ask one of the
commentators in this bug to give us their profile or prefs.js file and spend
some real QA time in trying to reproduce it.  This bug has bounced around quite
a bit with "Can't reproduce" type of response from our end. Obviously users are
seeing something that we don't. We should put some serious effort in trying to
reproduce this.  I can help with debugging,and/or provide debugged dlls, but I
would like the QA to get a test environment going. 
No point in having two nsbeta1+ bugs about the same problem, is there?  Duping
this against bug 126826 since this seems to have a lot of noise in it.

*** This bug has been marked as a duplicate of 126826 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Can anyone who sees this problem -- of the back and forward buttons *never*
enabling -- please e-mail to me their problematic profile's prefs.js and
localstore.rdf?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: