Closed
Bug 112282
Opened 23 years ago
Closed 22 years ago
Navigate back/forward stops working in some cases
Categories
(SeaMonkey :: General, defect, P3)
SeaMonkey
General
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 :)
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Reporter | ||
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
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
Comment 5•23 years ago
|
||
*** Bug 113076 has been marked as a duplicate of this bug. ***
Comment 6•23 years ago
|
||
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
Comment 7•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
It looks like there could be a problem with the onLocationChange notification that triggers the sensitivity of the back forward buttons.
Assignee | ||
Comment 9•23 years ago
|
||
Steps to reproduce this would be great. I haven't seen this problem yet.
Comment 10•23 years ago
|
||
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.
Assignee | ||
Comment 11•23 years ago
|
||
Look at the javascript console (under Tasks -> Tools) when this happens. Are there warnings / errors there that seem related?
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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
Comment 14•23 years ago
|
||
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.
Assignee | ||
Comment 15•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
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.
Updated•23 years ago
|
Attachment #60668 -
Attachment description: Strange toggleable swuate below and left of back button → Strange toggleable square below and left of back button
Comment 17•23 years ago
|
||
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
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
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
Comment 20•23 years ago
|
||
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)
Reporter | ||
Comment 21•23 years ago
|
||
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)
Comment 22•23 years ago
|
||
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.
Assignee | ||
Comment 23•23 years ago
|
||
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 → ---
Comment 24•23 years ago
|
||
Reopening bug 113076 for the "history doesn't work when browser first opened from mail/news" issue and assigning to jaggernaut, as directed.
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
*** Bug 114172 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
*** Bug 114146 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
*** Bug 114704 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
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)
Comment 31•23 years ago
|
||
we gotta get this fixed for mozilla 0.9.7
Comment 32•23 years ago
|
||
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.
Comment 33•23 years ago
|
||
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
Comment 34•23 years ago
|
||
FWIW s/maxentries/max_entries/
Comment 35•23 years ago
|
||
I have no entry for browser.sessionhistory.maxentries in my prefs.js I still have this problem.
Comment 36•23 years ago
|
||
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).
Comment 37•23 years ago
|
||
Actually, that's why I reopened bug 113076. See comments 23 through 25.
Assignee | ||
Comment 38•23 years ago
|
||
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.
Comment 39•23 years ago
|
||
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.
Assignee | ||
Comment 40•23 years ago
|
||
See bug 113076. Please post follow-up comments for that patch there, since it won't fix this bug.
Comment 41•23 years ago
|
||
Are we nearing a patch for this bug? This bug can cause data loss!
Assignee | ||
Comment 42•23 years ago
|
||
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.
Comment 43•23 years ago
|
||
*** Bug 115378 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 44•23 years ago
|
||
Can anyone still see this bug now that the work-around for 113076 is in place?
Comment 45•23 years ago
|
||
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.
Comment 46•23 years ago
|
||
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.
Comment 47•23 years ago
|
||
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.
Assignee | ||
Comment 48•23 years ago
|
||
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?
Comment 49•23 years ago
|
||
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!
Comment 50•23 years ago
|
||
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.
Comment 51•23 years ago
|
||
also bclinger that text selection bug is also fixed in the 2:17pm build for 12-18.
Comment 52•23 years ago
|
||
I noted this morning that the select all/edit functions were back like they should be. Thanks for the fast repair, all. Ben
Assignee | ||
Comment 53•23 years ago
|
||
Until I get a reproducible testcase: -> future
Target Milestone: --- → Future
Comment 54•22 years ago
|
||
nsbeta1+ per Nav triage team., clearing future for retargetting.
Comment 55•22 years ago
|
||
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!
Comment 56•22 years ago
|
||
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.
Comment 57•22 years ago
|
||
Comment 58•22 years ago
|
||
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.
Comment 59•22 years ago
|
||
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
Comment 60•22 years ago
|
||
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).
Comment 61•22 years ago
|
||
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.
Comment 62•22 years ago
|
||
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.
Comment 64•22 years ago
|
||
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
Comment 65•22 years ago
|
||
Also, if you go back a few pages from that page and go forward, the forward button stops working.
Comment 66•22 years ago
|
||
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.
Updated•22 years ago
|
Whiteboard: [adt1]
Updated•22 years ago
|
Priority: -- → P3
Comment 68•22 years ago
|
||
Nav triage team needs info: Is anyone seeing this using current builds on top sites?
Whiteboard: [adt2] → [adt2] [need info]
Reporter | ||
Comment 69•22 years ago
|
||
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?
Reporter | ||
Comment 70•22 years ago
|
||
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...
Comment 72•22 years ago
|
||
nsbeta1- per Nav triage team
Comment 73•22 years ago
|
||
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"
Updated•22 years ago
|
Whiteboard: [adt2] → [adt2][Hixie-P0][Hixie-1.0][MB]
Comment 74•22 years ago
|
||
earthsound: can you still reproduce this?
Reporter | ||
Comment 75•22 years ago
|
||
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.
Comment 76•22 years ago
|
||
Claudius, can you reproduce this?
Comment 77•22 years ago
|
||
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.)
Comment 78•22 years ago
|
||
Evelyn says: we are seeing quite a bit of feedback citing this problem in Netscape 7.0 PR1 newsgroups.
Assignee | ||
Comment 79•22 years ago
|
||
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.
Comment 80•22 years ago
|
||
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.0 → mozilla1.0.1
Target Milestone: mozilla1.2alpha → ---
Comment 81•22 years ago
|
||
Is this the same as Bug 141290? That one has a ton of dups.
Comment 82•22 years ago
|
||
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.
Comment 83•22 years ago
|
||
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.
Comment 84•22 years ago
|
||
I still can't reproduce this. I'm still trying but no luck so far. Suggestions are welcome and encouraged
Comment 85•22 years ago
|
||
nsbeta1+/adt2 per Nav triage team. We need to resolve this, if only via some wallpaper/bulletproofing.
Comment 86•22 years ago
|
||
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.
Comment 87•22 years ago
|
||
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
Comment 89•22 years ago
|
||
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?
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•