Closed Bug 7406 Opened 25 years ago Closed 25 years ago

Problem w/opening a blank browser window when reading msg

Categories

(SeaMonkey :: UI Design, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 14928

People

(Reporter: lchiang, Assigned: mscott)

References

Details

<This is pasted in from Bugsplat bug 61107 per suggestion of davidm. Assigning to XPApps. This issue was resurfaced in the mail-news mozilla.org newsgroup and was suggested to look at in 5.0> -- Begin pasted comments (I only pasted the relevant comments) -- About 10% of the time when I click on a new e-mail header, I'll get a completely blank Nav window. It does not contain the contents of the e-mail; it's definitely a Nav window and not an e-mail window. It's really odd. ------- Additional Comments From dmose 05/09/97 11:01 ------- I see this regularly on the XFE. I use IMAP. It _may_ coincide with viewing a message which contains an HTML attachment for the first time; I'm not entirely sure. ------- Additional Comments From phil 05/12/97 16:13 ------- Ok, after some investigation with lord, I think I have a reproducible case, and I think it's related to auto proxy config. 1. go to a web pane (I used home.netscape.com) 2. email the page to yourself 3. configure your prefs with - auto proxy config to w3proxy:8080 - start up with messenger mailbox - clear disk cache 4. exit and restart the app 5. when the app comes up, you get an empty browser window with the auto proxy config url in it. I tried this a couple of other ways, including manual proxy for http, and no proxy, and couldn't reproduct the problem. So it doesn't look like this is a mail problem to me, and montulli says that valeski would be the proxy guy these days. ------- Additional Comments From dmay 06/27/97 07:51 ------- 1. Set browser to blank page on startup or "about:" as to not hit proxy. 2. Set autoproxy to "europroxy.mcom.com:8080" or "w3proxy.mcom.com:8080" 3. Restart browser. 4. Read an email with attached HTML that references elements across the network that would cause proxy access. 5. The blank window will appear with the title = autoproxy setting in prefs. DM ------- Additional Comments From valeski 07/21/97 18:39 ------- This only happens once, and only if you haven't hit the network via the pac yet. The problem is that for those that fire up messenger first (or only use messenger), they will get this behavior all the time. Right now I have no clue why this is happening. Jud ------- Additional Comments From valeski 07/22/97 16:45 ------- From a message from blythe: The MSG_RequiresNewWindow(sp) function is an abomination. I think the call to it lies in CAbstractCX::GetUrl in cxabstra.cpp It undoubtedly returns TRUE when the http://autoconfig URL comes through, and for no other reason. ------- Additional Comments From lchiang May-28-1999 16:58 ------- Adding another scenario that John Friend wrote in mozilla.org's mail-news newsgroup: The problem today occurs when you're in a mail window (with no browser windows open) and you click on an http link that is going to have a content-type that can't be displayed by the browser. You first get a blank browser window (because that window was opened in order to download the http link), then you get the Save or Open dialog (when the browser window discovers it can't do anything else with the content-type). No matter which you pick, you're left with the blank browser window sitting there (and 4.6 has window activation problems that further mess up the user experience). I think the root of the problem is URLs where it's not possible to tell who should handle it based purely on the URL. Instead you won't really know until you start downloading the document and discover it's content-type. -- end of pasted comments -- From Davidm: Lets move it over to Bugzilla so we do the right thing in 5.0. Assign it to XPApps as I know Don has Radha scheduled to spent some time working on this issue.
Assignee: don → radha
Target Milestone: M8
Radha, this looks like a URL dispatching issue ...
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M8 → M10
No longer depends on: 8628
Target Milestone: M10 → M12
QA Contact: beppe → paulmac
Depends on: 12580, 14928
Target Milestone: M12 → M13
Assignee: radha → mscott
Status: ASSIGNED → NEW
Reassigning to mscott. This is probably resolved or a dup of something he has.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
This is a bug from the old codebase which doesn't apply to mozilla. Marking a dup of the generic URL dispatching bug. *** This bug has been marked as a duplicate of 14928 ***
Status: RESOLVED → VERIFIED
marking as verified
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.