Closed Bug 113076 Opened 22 years ago Closed 8 years ago
History is broken in browser windows opened from mail/news
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.6+) Gecko/20011201 BuildID: 2001120108 I start the browser, type in a URL, let it load, then type in another one, and let that load. The "back" button remains inactive. Reproducible: Always Steps to Reproduce: 1. Start Mozilla. Mine has no home page defined. 2. Type 'nytimes.com' into the adrress bar an let it load. 3. Type 'cnn.com' into the address bar and let it load. Actual Results: The "back" button is inactive rather than being available to return to 'nytimes.com'. Expected Results: Made the "back" button active to return to the first site.
confirmed Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011201 Reassigning to History (Session) -- I hope this is the correct component. But it can't stay in Browser-General.
Assignee: asa → radha
Status: UNCONFIRMED → NEW
Component: Browser-General → History: Session
Ever confirmed: true
QA Contact: doronr → claudius
Note this is NOT 100% reproducible. For instance, as I started filing on this bug report, it started working again. Unknown why.
I am and have been experiencing the same problem for at least the last four builds. I am currently using build id 2001113003 and it's almost a given fact that it will happen in the first opened browser window. After the window is closed and reopened, the back button will work most of the time. It happens regardless of the URL/site.
Does this happen only/mostly when you have blank page as your starting page? Have you set session history prefs to hold more than 0 entries?
Negative -- for me it appears to be only the first browser instance I start. When I start a new window or tab, it begins working from the second page visited on the second tab. Going to the second page of the second tab also enables it for the first tab.
i think this might be a dup of bug 112282. *** This bug has been marked as a duplicate of 112282 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Reopening as a spinoff of bug 112282. From that bug, here is my testcase: 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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: "Back" button fails to activate. → History is broken in browser windows opened from mail/news
As per jag's request, I am reassigning this bug to him.
Assignee: radha → jaggernaut
Status: REOPENED → NEW
Here's my experience and observations. (Win98 current build 2001120703, existed in the last two days of builds as well.) Steps to reproduce: 1. Set preference to start ONLY mail window on startup and exit mozilla. (A. Optionally clear your history before stopping mozilla to make other observations easier.) (B. If set to start a Navigator window also the bug is produced) 2. Start Mozilla and wait for Mozilla (mail) to finish loading. 3. Press CTRL+N once or several times rapidly. All new navigator windows created BEFORE the first new one is drawn on screen will exhibit the bug. Any new windows (or tabs) created after a "bad" window has been created are normal. 4. Create a new tab, which will be 'good'. 5. Visit at least two links (in order to light up the back button), on or off same domains does not seem to matter. 6. Returning to the original 'bad' tab and you will see the Back and Forward buttons light up the same as the 'good' tab has them set. 7. If you have your history sidebar open you will see that the 'bad' windows are not entering information but 'good' windows will. Other attempts: 1. I'm using the Classic theme, but this happens with the modern theme as well. 2. If asked for your POP password (as I am because of my server settings) enter it to clear the dialog, if desired you can wait for the bottom "frame" to load the URL you defined in your prefs. These two settings do not seem to affect my re-production. 3. "Blank Page" or "Home Page" loaded on new windows setting does not matter. 4. I cannot reproduce this bug by clearing history, I MUST stop mozilla and generate NEW windows. I turned on the JS Console and caught two errors. The first is generated for every "bad" window that I create. The second occurs when I have a selectable back button (step 6 above) and right click to access the back list. 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 200" data: no] Source File: chrome://navigator/content/navigator.js Line: 200 Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://navigator/content/sessionHistoryUI.js :: FillHistoryMenu :: line 51" data: no] I hope this helps.
OS: Windows ME → All
Hardware: PC → All
Still seeing this on today's nightly: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/2001121 Bug 113751 may be a duplicate.
*** Bug 113751 has been marked as a duplicate of this bug. ***
I start with mailnews and browser and the first browser window never gets the back forward buttons enabled after surfing by typing in urls or clicking on links
Yup, yup, I can second comment #12. I start with mailnews only. Then I bring up a browser. That never gets a history. Once I create a new window, the second viewed page starts the history. Last working build where this definitely worked was 2001112703. 200112* is broken.
The problem here is that 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.
I'm putting back some code I removed Nov 29, and adding code to also set global history, both inside a test for this bug so we don't redundantly set it (the original reason I removed that code). I guess we should check this in on the trunk now, and not only on the 097 branch (once we branch), since it's a major nuisance.
Comment on attachment 61708 [details] [diff] [review] Put back code that works around / hides the bug r=bryner
Attachment #61708 - Flags: review+
Comment on attachment 61708 [details] [diff] [review] Put back code that works around / hides the bug sr=ben
Attachment #61708 - Flags: superreview+
I've checked this work-around in on the trunk-to-become-0.9.7, I'll take a look at why docshell isn't being created and come up with a real fix for 0.9.8.
Whiteboard: checked in for 0.9.7
*** Bug 113160 has been marked as a duplicate of this bug. ***
I'm not sure if this helps at all for the QA or record keeping but... Running 2001-12-17-15 of the 0.9.7 branch on Win98 I can confirm this bug does not appear.
As of build 2001121805 on MacOSX, I am able to use the forward/back buttons on an automatically created initial window.
*** Bug 114671 has been marked as a duplicate of this bug. ***
hmm, this is still opened, does this bug exist in moz0.9.8 ?
No, 0.9.8 will ship with the same work-around 0.9.7 shipped with. Fixing the root bug is hard.
has it been checked in?
Yes, see comment 19.
Nav triage team needs info: has this gone away? is the workaround sufficient for MachV? nominating for nsbeta1 in case...
I cannot reproduce in Windows 2000 (Win32 Nightly Build 2002021803) Open mozilla with -mail an created a new browser window from the both the quicklaunch (icon on lower left and from New->Browser menu) WFM
The work-around is sufficient. In navigator's onload handler we check to see if setting session history failed in <browser>'s constructor (triggered by the real bug) and if so we set it and global history from there, before the first URL is loaded.
jag, is there another bug for "the real bug"(jag, comment #30) or does it reside here? If this is to be the bug then let's get a clear statement of the problem and summary and what we know so far.(morph it a little) In this way we can avoid confusion and time-consuming requests for info in the future.
It resides in here, but I could move it to a new bug. The problem (as far as I can tell) is that a browser window created from mail/news doesn't have a valid docshell by the time the <browser> constructor is executed.
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
I can not reproduce this bug on Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 I will close this issue. If it still persists please reopen.
Status: NEW → RESOLVED
Closed: 22 years ago → 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.