Closed Bug 91531 Opened 24 years ago Closed 24 years ago

Blank browser window appears every other time a link is selected from Mail/IM

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: nbaca, Assigned: paulkchen)

References

Details

Attachments

(1 file)

Attach the WebMail welcome msg which including some non-working links
3.06 KB, text/plain
Details
Branch build 2001-07-19-05: WinMe, Whistler Overview: Selecting a link in a Mail (or IM) window results in a blank browser window every other time it is selected. Steps to reproduce: 1. Create a message with a link to a url (i.e. www.cnn.com) 2. Send and receive the message 3. From the 3pane, select the link from the message pane. It probably shows the cnn home page. 4. Close the Browser window 5. Select the link from the same message Actual Results: The browser window opens to a blank page. When this happens the url states "http://home.netscape.com/bookmark/6_1/homebutton.html". - Close the browser window and select the link again. Now it loads the cnn home page and the url states "http://www.cnn.com/" as expected. - Continue the same steps and notice that every other time the browser opens it displays a blank page.
Keywords: nsbeta1
Marking nsbeta1 because this should be fixed for RTM. Selecting a link in Mail should not result in a blank browser window. Especially every other time?
cc'ing mscott.
*** This bug has been marked as a duplicate of 85264 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Scott how can this be a dup of 85264 when the fix for 85264 was checked in on 7/17 and this is on the 7/19 build?
this bug is branch only. The fix for 85264 is a trunk fix. Ergo, the bug would still be present on the branch =).
that being said I didn't bother to read the bug report closely. It is different than 85264. However on the trunk we start to load homebutton.html then we load the correct url and it only happens when you don't have another browser window open.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
did this start happening after the fix for #83433 landed? that change landed on 7/17. (poor jst, any bug after the DOM landing gets blamed.)
similar to 91541.
*** Bug 91541 has been marked as a duplicate of this bug. ***
win98 also .. OS: all
OS: Windows ME → All
To answer Seth's question, I started noticing this problem with the 07-18-branch build. But I had the problem in bug 88267 (which has to do with the Home page opening) well before that. I have been seeing the blank window problem on Win98, not WinMe.
I started downloading past branchs, and in my case (win98) this problem really happens with today's branch. My branch from yesterday is fine.
my branch build from today exhibits this problem. Note: that if I have a browser window open already, then the URL loads fine. But if I don't have any browser windows open then a new blank browser window is created. We should fix this for rtm.
Keywords: nsBranch
Just reproduced on my powerbook with my branch build from this morning. It's very odd that it's every OTHER window that exhibits this behavior. Debug output to console is: Error loading URL http://www.mozilla.org/ : 2152398850 Error reading file Poeka:Documents:Mozilla:Profiles:Paul Chen:5d8hu0ba.slt:NewCache:B1039690d01 ###!!! ASSERTION: NS_ENSURE_TRUE(mCacheAccess & nsICache::ACCESS_WRITE) failed: 'mCacheAccess & nsICache::ACCESS_WRITE', file nsHttpChannel.cpp, line 947 Error loading URL http://www.cnn.com/ : 2147549183 Digging further. Marking nsbeta1+, p1, and mozilla0.9.3. I think we want this fixed. ;-)
Status: REOPENED → ASSIGNED
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
cc'ing gagan. I don't know if the cache errors in the output Paul added has anything to do with this bug. I saw that another cache bug is about to be backed out. Any possibility they are related?
nbaca: it would be helpful to know if this is a recent regression. Can you try with earlier branch builds (say 1 week and 3 days ago) to see if the problem existed previously also?
Has anyone looked at the file size of the link target as a factor in reproducing this problem? As Marcio and I investigated in Bug 91541, the URL which points to a small size file: http://elwood/mgalli2/t1.html (NS internal link) caused the problem every time but the link pointing to a larger size file never did: http://elwood/mgalli2/t2.html (NS internal link) (But make sure that no browser window is open.)
Having problems this morning with Bugzilla. In the meantime we tried the following. Maybe it may give a clue: 1. In a mail message I created url links to some news sites (abcnews.com and cbsnews.com) a. abcnews.com, file size 47kb - 7/18branch: loaded the page every time - 7/19branch: loaded this page every other time (appears to be only a 7/19 problem, interesting that when this page is saved to disk that it has a smaller file size than cbsnews.com) - 7/20branch: loaded the page every time b. cbsnews.com, file size 56kb - 7/19branch: loaded this page every time - 7/20branch: loaded this page every time 2. Esther loaded a bugscape bug in 7/19br and it exhibited the problem of displaying the image every other time (url pointing to the homebutton when it failed). Loading the same bug in 7/20br has a url pointing to the correct bug# but it doesn't display the bug report. Esther noticed the cursor at the end of the URL so she pressed Enter and then it displayed the bug report.
Branch build 2001-07-20-06: WinMe - Received an email notification for bugzilla bug# 91633 - Selected the link and it displays a blank page, the url displays the correct path to the bug and a flashing cursor appears at the end of the line - Press Enter and it displays the contents of the page. - It displays a blank page everytime the browser launches. It is a new bug so there is only one entry present in the bug.
kat's comment about file size is pretty interesting. ninoschka, does that match what you are seeing with those bugzilla links? I'm combing through the checkins to see what's suspect.
I'm currently pulling a new branch tree, hopefully I can reduce some cache noise with gagan's backout. Also, Jag thinks he's fixed all these open nav window problems in his patch to 65993, but he did this on the trunk. I've already applied the patch this morning, and the case where we would load the home page doesn't load the home page, but doesn't load the linked page either (get the same cache error). Also, in the case that did work, the homepage loads first. Ooops. Anyway, the adventure continues.
I just updated my branch tree, and this works now. Hmm, maybe it was the cache stuff after all. Can anyone reproduce this with today's builds?
I have had this happen once or twice today with the 07-20-branch build. It definitely happens less frequently now, but the problem is not completely eradicated.
Still happens every time with the smaller size file mentioned above. This is with 7/20/2001 Win32 branch build. Does not happen with the larger size file mentioned above.
Just tried linux 2001-07-20-04-0.9.2 mozilla bits with http://elwood/mgalli2/t1.html, and I see blank page with correct url in url bar. At least it's consistent now. ;-)
in my prefs, I've got it set to load my home page when a new nav window opens. i've set my home page url to: http://home.netscape.com/bookmark/6_1/homebutton.html when I launch -mail (no browser windows) and click on a link in a message (my test message link is http://bugzilla.mozilla.org/show_bug.cgi?id=91631) I get the blank page. when the browser window first comes up, http://home.netscape.com/bookmark/6_1/homebutton.html shows up in the url bar, and then the link I clicked on shows up. if I close that browser window, and click on the link again, it works. this is with a 0.9.2 branch mozilla build from ftp.mozilla.org, 7-20-03
...and, if I disable able my memory and disk cache (by setting the levels to 0), and do the same thing, it works. I still see the home page url come up first, but the link does load.
nbaca confirms that setting her cache settings to zero also makes this problem go away.
Seth, can you try jag's latest patch to 65993. That might fix the opening home page first problem. I just applied it but I don't think I saw that problem in the first place. It supposedly fixes all instances of opening the home page before loading the page it should load.
on my up to date linux branch build, with gagan backed out, I still see the problem. when I apply jag's patch for 65993, the problem goes away. I'll go double check that. note, my cache prefs are the default values. (they are *not* set to 0)
Ok, so I just reset my cache settings to default values. The link "http://elwood/mgalli2/t1.html" loads successfully the first time ONLY. On subsequent clicks on the link in mail (with no browser window), the browser window is empty. If I set both cache settings to 0, then this works every time. This is on my powerbook g3 500.
adding jag to cc-list
damn it, now I'm having problems reproducing the problem with out jag's fix. I'll keep trying.
FWIW setting the cache to zero would never help (this is a known bug in cache) which is fixed on the trunk but not on the branch. cc'ing gordon.
I saw the same problem on WebMail welcome msg. I will attach this welcome msg here, hope it help for fixing & debugging this problem....
pchen and I think dougt's last checkin to nsHttpTransaction.cpp (for bug #82720) fixes the problem. we're double checking that theory now.
I just backed out the fix for 82720 (reverted nsHttpTransaction.cpp back one revision on the branch) and the problem shows up again.
Maybe I should file separate bugs for these 2 problems, but I also have the following problems: 1. Clicking on a certain mail attachment goes to my mail start-up page instead of opening that HTML attachment. Looks like the size of the attached file has something to do with it. 2. Clicking on the Browse button on within an HTML Composer document sometimes goes to the browser home page. Bug 59497 and Bug 90925.
I'm seeing the same thing as pchen. dougt's fix for #82720 appears to have fixed this problem. without his fix, I can reproduce the problem. with it, I am unable to. before we mark this a dup, it would be great to hear dougt say: "ah, of course this is a dup! the reason is..."
Seth and I concur that this bug is done. With gagan's backout plus the fix for 82720, this bug is fixed. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
> 1. Clicking on a certain mail attachment goes to my mail start-up page > instead of opening that HTML attachment. Looks like the size of the > attached file has something to do with it. This problem did not go away with the fix in Bug 82720. Actually it opens the Navigator Home Page rather than the Mail start-up page. --> http://bugzilla.mozilla.org/show_bug.cgi?id=91793 > 2. Clicking on the Browse button on within an HTML Composer document > sometimes goes to the browser home page. Bug 59497 and Bug 90925. This problem still occurs with the 7/21/2001 Win32 Branch build. So I re-opened: --> http://bugzilla.mozilla.org/show_bug.cgi?id=90925
Unable to verify at this point, 'cause of http://bugscape/show_bug.cgi?id=7876, nothing happens when clicking on a link in Mac mail
Branch build 2001-07-24-06: WinMe Branch build 2001-07-24-03: Mac 9.04 So far, with the 7/24 build, this appears fixed. Bugscape # 7876 also appears to be working.
Verified fixed W2k branch build 2001-07-24-06 Linux branch build 2001-07-24-05 Mac branch build 2001-07-24-03 Thanks Ninoschka Baca! :-)
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: