Closed Bug 36119 Opened 25 years ago Closed 25 years ago

Can't click on link in mail and load it in browser

Categories

(MailNews Core :: Backend, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: scottputterman, Assigned: mscott)

Details

Steps to reproduce: Open browser. Open mail Read a message with a web page link in it such as a bugzilla notification. Click on that link. I get the following assertion and the page doesn't load. NTDLL! 77f7629c() nsDebug::Assertion(const char * 0x05cf5b54, const char * 0x100a4db4, const char * 0x05cf5b18, int 1393) line 191 + 13 bytes nsDebug::Error(const char * 0x05cf5b54, const char * 0x05cf5b18, int 1393) line 308 + 22 bytes nsBrowserInstance::DoContent(nsBrowserInstance * const 0x047ccaf8, const char * 0x0012fb10, int 1, const char * 0x10085df0 gCommonEmptyBuffer, nsIChannel * 0x05a6dc70, nsIStreamListener * * 0x0012fb50, int * 0x0012faf4) line 1393 + 21 bytes nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x05a6dc70, nsISupports * 0x00000000) line 401 + 109 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x05a69b20, nsIChannel * 0x05a6dc70, nsISupports * 0x00000000) line 255 + 16 bytes nsHTTPChannel::AssureResponseOnStartFired() line 1496 nsHTTPChannel::FinishedResponseHeaders() line 1782 nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x05a6de30, nsIChannel * 0x05a6e864, nsISupports * 0x05a6dc70, nsIInputStream * 0x05a6e0fc, unsigned int 0, unsigned int 0) line 382 + 11 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x06c37f70) line 406 + 47 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x06c34e30) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x06c34e30) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x014309d0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00210636, unsigned int 49485, unsigned int 0, long 21170640) line 1030 + 9 bytes USER32! 77e71820()
This broke because travis removed the implementation of nsBrowserInstance::DoContent over the weekend! Shame on you. The browser instance needs to forward the request to it's content docshell like it did before. I'll fix this and get travis to review it.
Severity: normal → critical
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → M16
Okay I have a fix for this: Here's the new implementation of nsBrowserInstance::DoContent NS_IMETHODIMP nsBrowserInstance::DoContent(const char *aContentType, nsURILoadCommand aCommand, const char *aWindowTarget, nsIChannel *aChannel, nsIStreamListener **aContentHandler, PRBool *aAbortProcess) { // forward the DoContent call to our content area webshell nsCOMPtr<nsIURIContentListener> ctnListener = do_QueryInterface(mContentAreaWebShell); if (ctnListener) return ctnListener->DoContent(aContentType, aCommand, aWindowTarget, aChannel, aContentHandler, aAbortProcess); return NS_OK; }
i checked in thefix.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
OK using apr18 m16 commercial builds linux rh6.0, NT 4.0 and mac OS 9.0
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.