Closed Bug 668944 Opened 13 years ago Closed 7 years ago

URLs don't trigger the actions when clicked on

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Version:
10 Branch
Platform:
x86_64
FreeBSD
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: yuri, Unassigned)

References

Details

Attachments

(2 files)

/home/yuri/.thunderbird/qysr9gn2.default/mimeTypes.rdf
15.27 KB, application/octet-stream
Details
/home/yuri/.thunderbird/qysr9gn2.default/US/mimeTypes.rdf
2.56 KB, application/octet-stream
Details 
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110701024755

Steps to reproduce:

I have the e-mail with https:// link in it.
Preferences/Attachments specify that action for https is "Use firefox (default)"
But when I click on the link nothing happens.
OS: Other → FreeBSD
Hardware: All → x86_64
Version: unspecified → 5.0
Same behavior with http:// links.

Interesting that after I set an option for particular URL type to "Always Ask", dialog box "Launch Application" pops up when I click on the URL link. The first option is 'firefox'. But nothing happens when I select 'firefox' and click Ok. Dialog box just stays open.

So actions feature is broken. If application can't be launched for some reason, user should see the message explaining what ism the problem.

Setting importance to 'major' since this is a major usability issue and annoyance.
Severity: normal → major
What version of glibc is installed on your system ?
FreeBSD doesn't use glibc (GNU C library).
(In reply to comment #3)
> FreeBSD doesn't use glibc (GNU C library).

That's how we register what uri doe and what they launch.
Could you elaborate? How does TB register this through glibc?
Yuri:

Is it possible that Firefox is opening the link in the background, and just not focusing?

-Mike
No, this is not the case.
Yuri:

Can you open up the Error Console (Tools > Error Console), click the "CLEAR" button, try to click a link, and see if anything pops up in the dialog?

Let us know what happens - and if a message pops up, please right-click, copy, and paste into this bug.

Thanks,

-Mike
(In reply to comment #5)
> Could you elaborate? How does TB register this through glibc?

see bug 624341
Let me clarify: Ludovic probably meant `glib', not `glibc' (the two are very differnet libraries).
Actually the error console gets the error:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188"  data: no]
glib-2.26.1
Hm...this is sounding very similar to bug 668327.

Could it be that you too have a corrupted mimeTypes.rdf in your profile directory?

Very mysterious...

-Mike
There are two mimeTypes.rdf fils in my TB profile:
/home/yuri/.thunderbird/qysr9gn2.default/mimeTypes.rdf
/home/yuri/.thunderbird/qysr9gn2.default/US/mimeTypes.rdf
does it work if you remove them ?
Same thing after removing the mimeTypes.rdf
New file got created at /home/yuri/.thunderbird/qysr9gn2.default/mimeTypes.rdf after TB relaunch.
Hrm.  Frustrating.

Are you familiar with debugging Thunderbird?  If so, could you set a breakpoint at nsExternalHelperAppService::LoadUrl, step through, and see where exactly it's throwing the NS_ERROR_FAILURE?
Will try this.
I think this is also the case of poor error reporting.
Exception is thrown, caught and printed and yet it doesn't carry enough information about the cause.
Here is where an exception is thrown:

CallMethodHelper::Call (this=0x7fffffffad90) at xpcwrappednative.cpp:2407
2407        mCallContext.GetXPCContext()->SetLastResult(invokeResult);
(gdb) n
2409        if(NS_FAILED(invokeResult))
(gdb) n
2411            ThrowBadResult(invokeResult, mCallContext);
Hm - that's going a bit deep.  Are you able to get a backtrace from that point?
DEBUG version of thunderbird randomly crashes on FreeBSD by itself for some other reasons. Very hard to debug.
=en-US&version=5.0&os=FreeBSD&buildid=20110706135403]
--DOMWINDOW == 19 (0x8130e2d78) [serial = 11] [outer = 0x811e34100] [url = about:blank]
--DOMWINDOW == 18 (0x8131b8278) [serial = 14] [outer = 0x8111d9000] [url = about:blank]
--DOMWINDOW == 17 (0x81ca2cb78) [serial = 21] [outer = 0x8111d9000] [url = imap://yuri@imap.rawbw.com:143/fetch%3EUID%3E/INBOX%3E138342]
--DOMWINDOW == 16 (0x8142af878) [serial = 12] [outer = 0x8111da200] [url = about:blank]
###!!! ASSERTION: Not a UTF-8 string. This code should only be used for converting from known UTF-8 strings.: 'Error', file ../../../dist/include/nsUTF8Utils.h, line 453
###!!! ASSERTION: length mismatch: 'calculator.Length() == converter.Length()', file nsReadableUtils.cpp, line 402
Assertion failure: chars[length] == 0, at jsstrinlines.h:405
Abort trap: 6
===> crashes here <====
I think we're losing focus here - now we're debugging an assertion failure, which doesn't sound like the subject of this bug.  For the assertion failure, could you please file a new bug?

Were you able to get a backtrace for the point where LoadUrl fails for you?
I wasn't able to get the stack since debug version crashes before it reaches LoadUrl.
Build an optimized version but don't strip the binaries...
I have a similar issue, but I caution that I am running on a debug build with a few days old aurora, with my ExQuilla extension loaded, so I don't even know if my issue is valid. However the problem is appearing on IMAP trying to download the attachment of a spam message.

I'm getting a crash with the following stack:

 	mozjs.dll!JS_Assert(const char * s=0x5e5a21b4, const char * file=0x5e5a2200, int ln=171)  Line 79	C++
 	mozjs.dll!JSExternalString::new_(JSContext * cx=0x040ccbd0, const wchar_t * chars=0x05382a10, unsigned int length=101, int type=0, void * closure=0x00000000)  Line 171 + 0x24 bytes	C++
 	mozjs.dll!JS_NewExternalString(JSContext * cx=0x040ccbd0, const wchar_t * chars=0x05382a10, unsigned int length=101, int type=0)  Line 2719 + 0x17 bytes	C++
 	xul.dll!XPCConvert::NativeData2JS(XPCLazyCallContext & lccx={...}, jsval_layout * d=0x002bcccc, const void * s=0x002bcf98, const nsXPTType & type={...}, const nsID * iid=0x002bcd90, unsigned int * pErr=0x00000000)  Line 423 + 0x19 bytes	C++
 	xul.dll!XPCConvert::NativeData2JS(XPCCallContext & ccx={...}, jsval_layout * d=0x002bcccc, const void * s=0x002bcf98, const nsXPTType & type={...}, const nsID * iid=0x002bcd90, unsigned int * pErr=0x00000000)  Line 3173 + 0x20 bytes	C++
 	xul.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x09c99e78, unsigned short methodIndex=14, const XPTMethodDescriptor * info=0x03570528, nsXPTCMiniVariant * nativeParams=0x002bcf98)  Line 1551 + 0x2a bytes	C++
 	xul.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=14, const XPTMethodDescriptor * info=0x03570528, nsXPTCMiniVariant * params=0x002bcf98)  Line 586	C++
 	xul.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x0f1d52c0, unsigned int methodIndex=14, unsigned int * args=0x002bd058, unsigned int * stackBytesToPop=0x002bd048)  Line 114 + 0x21 bytes	C++
 	xul.dll!SharedStub()  Line 142	C++
>	xul.dll!mimeEmitterStartAttachment(MimeDisplayOptions * opt=0x091b1730, const char * name=0x09b595f8, const char * contentType=0x0c627660, const char * url=0x09b596b0, int aIsExternalAttachment=0)  Line 1867 + 0x27 bytes	C++
 	xul.dll!NotifyEmittersOfAttachmentList(MimeDisplayOptions * opt=0x091b1730, nsMsgAttachmentData * data=0x042a9ba0)  Line 684 + 0x2a bytes	C++
 	xul.dll!mime_display_stream_complete(_nsMIMESession * stream=0x0c64c948)  Line 1040 + 0x10 bytes	C++
 	xul.dll!nsStreamConverter::OnStopRequest(nsIRequest * request=0x0bc2fbd0, nsISupports * ctxt=0x0428d648, unsigned int status=0)  Line 1090 + 0xf bytes	C++
 	xul.dll!nsImapCacheStreamListener::OnStopRequest(nsIRequest * request=0x0bfee208, nsISupports * aCtxt=0x0428d648, unsigned int aStatus=0)  Line 8652 + 0x30 bytes	C++
 	xul.dll!nsInputStreamPump::OnStateStop()  Line 579	C++
 	xul.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x09b01a40)  Line 403 + 0xb bytes	C++
 	xul.dll!nsInputStreamReadyEvent::Run()  Line 115	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=0, int * result=0x002bd340)  Line 617 + 0x19 bytes	C++

In mimeEmitterStartAttachment the url is:

"imap://kent%40caspia%2Ecom@mail.caspia.com:143/fetch%3EUID%3E.INBOX.spam%3E62525?header=filter&emitter=js&part=1.2"
See my bug 677360 for additional details.
(In reply to Kent James (:rkent) from comment #30)
> See my bug 677360 for additional details.

dependent?  dupeu?
(In reply to Wayne Mery (:wsmwk) from comment #31)
> (In reply to Kent James (:rkent) from comment #30)
> > See my bug 677360 for additional details.
> 
> dependent?  dupeu?

I think that Jonathan Protzenko [:protz] might be better able to address that. I was mainly posting because I had a lot of detail, since I was running debug builds when I saw the issue.

What I am not sure of is whether a core bug exists, as Jonathan and I said in bug 677360, or whether mailnews is simply misusing a core function.
Still here
Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120229 Thunderbird/10.0.2

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188"  data: no]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 5.0 → 10
Blocks: 444808
Is this still present in latest Thunderbird version? Don't have FreeBSD installation with GUI on hardware to retest
Flags: needinfo?(yuri)
Whiteboard: [closeme 2017-05-15]
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(yuri)
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2017-05-15]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: