Closed Bug 113076 Opened 22 years ago Closed 8 years ago

History is broken in browser windows opened from mail/news

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.2alpha

People

(Reporter: hyrosen, Assigned: jag+mozilla)

References

Details

(Keywords: regression, testcase, Whiteboard: [need info] checked in for 0.9.7)

Attachments

(1 file)

Put back code that works around / hides the bug
1.61 KB, patch
bryner
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review 
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
Keywords: regression
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
Keywords: testcase
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.
Keywords: mozilla0.9.7
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.
No longer blocks: 114455
*** Bug 114671 has been marked as a duplicate of this bug. ***
hmm, this is still opened, does this bug exist in moz0.9.8 ?
Keywords: mozilla0.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...
Keywords: mozilla0.9.7, mozilla0.9.7+, mozilla0.9.8 → nsbeta1
Whiteboard: checked in for 0.9.7 → [need info] checked in for 0.9.7
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.
nsbeta1- per ADT triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2
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.