Closed Bug 91720 Opened 23 years ago Closed 23 years ago

In a stand-alone window, "Open Link in New Window" fails silently.

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: stephend, Assigned: sspitzer)

References

Details

(Keywords: regression, Whiteboard: PDT+)

Build ID: 2001-07-20 all OSs (Windows 2000, Mac OS 9.1 and RedHat Linux 7.1) BRANCH BUILDS of 0.9.2 Summary: In a stand-alone window, "Open Link in New Window" fails silently. Steps to Reproduce: 1. Compose an HTML formatted message that has a link in it. (or just read one ;-) 2. Double-click that message, so it open in a stand-alone window. 3. Context-click the link and select "Open Link in New Window". Expected Results: The link opens in a new browser window. Actual Results: Nothing happens. PLEASE NOTE: This may be related/DUP of things Bhuvan and Jag are working on (related to Steve Morse's checkin to the branch of late). I'm filing so that this case is known.
It may be different since this particular bug reported here doesn't even open / bring to front the browser window.
weird, this seems to be working in today's trunk builds. Open window from a stand alone imap message window opens up a new browser window and loads the url. As in 91719, I wonder if there are any JS errors getting dumped to the console.
Error: viewSourceElt has no properties Source File: chrome://communicator/content/nsContextMenu.js Line: 145 Error: gMessagePaneContextMenu has no properties Error: gMessagePaneContextMenu has no properties
this was caused by Blake's checkin to nsContextMenu.js on 7/18.
I think we should dup 91719 and this together since the same fix should fix both of them. The message pane context menu doesn't have a view source menu item and blake's addition to nsContextMenu.js assumes there is. we can just wrap the following lines in a try/catch clause: try { var viewSourceElt = document.getElementById("context-viewsource"); if (isPostData) viewSourceElt.setAttribute("disabled", "true"); else viewSourceElt.removeAttribute("disabled"); } catch(ex) {} and that will probably fix things.
*** Bug 91719 has been marked as a duplicate of this bug. ***
Thank you, Scott! I am going to email PDT on this one.
Keywords: regression
that try & catch may not be enough since a few lines above, there's code that assumes there's a dom element for context-viewsource: if (gBrowserElt == -1) gBrowserElt = document.getElementById("content"); if (gBrowserElt) isPostData = gBrowserElt.webNavigation.postData; this.showItem( "context-viewsource", !( this.inDirList || this.onImage) that may need to be wrapped in a try/catch clause too.
Oops, sorry all. I didn't realize mail used this, I thought they built their own. Adding the first try/catch you mentioned is fine. The second is unnecessary.
PDT+. Can lxr help us be sure we've covered every case now? Otherwise, maybe spamming seamonkey is in order.
Whiteboard: PDT+
It does not matter if we've tried every case or not. The try/catch fixes it at its heart, regardless of the clients.
Pls check in then. We'll continue our testing.
oops, you may need to get r and sr on this first, per the tree rules.
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: esther → stephend
I checked the context menus in both the 3 pane and the stand-alone window, and everything looks good so far (reply, edit in composer, open in new window, copy link location, etc.) Builds: Windows 2K - 2001-07-22-06-0.9.2 Mac OS 9.1 - 2001-07-22-03-0.9.2 Linux needs to be checked on the respin. (Monday)
*** Bug 91507 has been marked as a duplicate of this bug. ***
Verified FIXED using: RedHat Linux 7.1 - 2001-07-23-04-0.9.2
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.