Related Link (in Edit Task and Edit Event Window) is NOT clickable

RESOLVED FIXED in 1.0

Status

RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: christoph.mueller, Assigned: Fallen)

Tracking

Trunk
x86
Windows XP
Bug Flags:
blocking-calendar1.0 +

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Lightning 1.0b2pre (nightly build 21-Jan-2010 11:57)

While I understand the reasoning given in Bug 502162 for not making this field editable the field should definitely be clickable (i.e. open a browser window) if it contains an URL. As it is, the field is neither clickable nor is it possible to extract the contents with copy.

Note that this bug seems to affect Lightning only as with Sunbird the field is clickable.

Reproducible: Always

Steps to Reproduce:
1. load a (remote) calendar (I tested with the openCRX CalDAV server that populates the field related link with an URL providing an alternative view of events/tasks
2. open any event/task (--> Edit Window)
3. click on the URL shown in the field "Related Link"
4. nothing happens...
Actual Results:  
while hovering the mouse over the field the cursor changes to a pointer, but clicking does not do anything; furthermore, the content of the field is not selectable (and hence can't be copied) and right-clicking does not bring up a context menu (and hence there is no way to copy the contents...)

Expected Results:  
if the field 'Related Link' contains an URL the field should be clickable; clicking should open a browser
(Reporter)

Updated

9 years ago
Version: unspecified → Lightning 1.0b1
I don't have a such server available, setting qawanted.
Keywords: qawanted

Comment 2

8 years ago
This is still happening with

Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Mnenhy/0.8.3 Thunderbird/3.1

To reproduce this, you can add the calendar http://dev.nicohaase.de/lightningTest.ics and disable writing access. If you double click the event in tie calendar now, a popup opens where the link seems to be clickable.
(Reporter)

Comment 3

8 years ago
Created attachment 487560 [details]
calendar entry (VEVENT) to demonstrate the problem (standalone, does not require calendar server)
(Reporter)

Comment 4

8 years ago
This is still happening with 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b3pre Thunderbird/3.1.6

As the problem does not exist with Sunbird, but only with Lightning, I suspect that the real cause of the problem might be Thunderbird (there are other Thunderbird add-ons with non-clickable URLs). 

If somebody knowledgeable about how to resolve issues with Lightning that might be related/caused with/by Thunderbird could please look into this and maybe raise the issue with the Thunderbird team? Even though this is probably a minor issue it hinders the workflow in a major way and it makes using the combo Thundbird/Lightning difficult (there is no easy way to navigate to the respective event on a calendar server because the URL can't be copied either...).
(Reporter)

Updated

8 years ago
Version: Lightning 1.0b1 → Lightning 1.0b2
(Reporter)

Comment 5

8 years ago
maybe another bit of information that could help: upon clicking on such a link the following is shown in the Thunderbird error console:

No chrome package registered for chrome://navigator/content/navigator.xul

it seems that neither current Thunderbird builds (3.1.6) nor current Lightning builds contain navigator.xul, i.e. it seems plausible that clicking external links doesn't do much 

Anybody know how to fix this?
Check your "browser.chromeURL" preference, it should be set to "chrome://messenger/content/messengercompose/messengercompose.xul".

Comment 7

8 years ago
(In reply to comment #6)
> Check your "browser.chromeURL" preference, it should be set to
> "chrome://messenger/content/messengercompose/messengercompose.xul".

I cannot find this preference using about:config at Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Mnenhy/0.8.3 Thunderbird/3.1.6 :(
(Reporter)

Comment 8

8 years ago
"browser.chromeURL" preference seems the right preference, but the value
"chrome://messenger/content/messengercompose/messengercompose.xul" opens a "new mail" window whereas we need a browser window...
(In reply to comment #8)
> "browser.chromeURL" preference seems the right preference, but the value
> "chrome://messenger/content/messengercompose/messengercompose.xul" opens a "new
> mail" window whereas we need a browser window...

Thunderbird does not contain a browser window. If you're changing that pref, then that's the wrong thing to do.

The core issue is bug 263433. You could probably work around it for now by providing an onclick handler for the relevant links:

onclick="if (event.button == 0) { openURL(this.getAttribute('url')); }"

You'll need to include contentAreaUtils.js into the references.
(Reporter)

Comment 10

8 years ago
Here are instructions for a patch if anybody is interested (thanks to Werner Froidevaux at CRIXP Corp. for looking into the issue and providing/testing the patch):

The following patch makes the 'Related Link' field clickable (the field corresponds to the ICal URL field):

* Locate calendar.jar in the Lightning distribution
* Expand the jar
* Locate the file calendar-event-dialog.js in directory ./content/calendar.
* Add the following function:

/**
 * According to
 * https://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/3a1376a79ae38377?hl=de
 */
function openURL(url) 
{ 
   let ios = Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService); 
   let iuri = ios.newURI(url, null, null); 
   let eps = Components.classes["@mozilla.org/uriloader/external-protocol-service;1"].getService(Components.interfaces.nsIExternalProtocolService); 
   eps.loadURI(iuri, null); 
} 

* Locate the file calendar-event-dialog.xul
* Locate the label with id="url-link".
* Add an onclick handler as follows:

OLD:
<label id="url-link"
  class="text-link"
  crop="end"/>

NEW:
<label id="url-link"
  class="text-link"
  crop="end"
  onclick="openURL(this.href);"/>

Recreate the jar with jar -cf0 calendar.jar * (the option 0 is important. Do not compress. Execute in expanded calendar dir)

I tested the above patch with the nightly build of Lightning dated 30-NOV-2010 and it worked just fine. Using the external protocol service should be portable between different versions of TB.

This may not be a perfect patch, but it does what it's supposed to do.
(Reporter)

Comment 11

8 years ago
additionally, if you want to make the 'Related Link' of read-only events/tasks clickable, you can apply the above patch to the files
* calendar-summary-dialog.js
* calendar-summary-dialog.xul

Now we just need somebody actually working on Lightning to take this and inject it into the source ;-)
While onclick is a start, it doesn't catch all cases. The text-link binding watches for left click, VK_RETURN and VK_ENTER. To fix this bug, I'd rather like to see someone debug into

http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/widgets/text.xml#297

and find out which part of it is failing. If we can't use that, we could possibly use the mail window's browserDOMWindow.openURI(), or add a function to calUtils.jsm or calendar-ui-utils.js.

I'd appreciate if someone could do the debugging and put together a patch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

8 years ago
Duplicate of this bug: 638442
(Assignee)

Updated

8 years ago
Duplicate of this bug: 560680
It seems that setting:

network.protocol-handler.expose.http = false;
network.protocol-handler.expose.https = false;

causes links to be opened correctly. I don't know why Thunderbird has these set to true, since it doesn't process http links itself. Whats happening now btw is that the external link is opened in a compose dialog.

Deferring to Product Thunderbird to get some advice. Please move back if we should do it differently.
Assignee: nobody → philipp
Component: Lightning Only → Preferences
Product: Calendar → Thunderbird
QA Contact: lightning → preferences
Version: Lightning 1.0b2 → Trunk
I just learned this is because of bug 516776. Very annoying. I guess we can not use the toolkit binding and roll our own, or does anyone see alternatives?
(In reply to Philipp Kewisch [:Fallen] from comment #16)
> I just learned this is because of bug 516776. Very annoying. I guess we can
> not use the toolkit binding and roll our own, or does anyone see
> alternatives?

No, it isn't about bindings, its about the fundamentals of how gecko protocol handling works.

We generally override openURL where we need to, although this would be somewhat easier if bug 263433 was fixed.
Could you give me an example on how this overriding is happening? I've tried using the openURL method as in <http://mxr.mozilla.org/comm-central/source/mail/base/content/aboutDialog.xul#119>, but when called from the main window, it still opens a compose window.

Alternatively, I could use calendar's launchBrowser() method, which seems to work fine.
(Assignee)

Updated

7 years ago
Assignee: philipp → nobody
Component: Preferences → Preferences
Product: Thunderbird → Calendar
QA Contact: preferences → preferences
Created attachment 569169 [details] [diff] [review]
Fix - v1

Fix using launchBrowser()
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #569169 - Flags: review?(bv1578)
(Assignee)

Updated

7 years ago
Keywords: qawanted
(Assignee)

Updated

7 years ago
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]

Comment 20

7 years ago
Comment on attachment 569169 [details] [diff] [review]
Fix - v1

The patch opens the registered web browser at the specified url but obviously the error mentioned in comment 5 is still present in the console because the click event calls the "open" method in the text-link binding:

message
No chrome package registered for chrome://navigator/content/navigator.xul

error
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/text.xml :: open :: line 357"  data: no]

The same error doesn't happen for the url related to the tasks' attachments (they are text-link and use launchBrowser() as well: http://mxr.mozilla.org/comm-central/source/calendar/base/content/calendar-task-view.js#174) because this.href inside method "open" is null so the code returns immediately from the method.

If we want to avoid the error in the console, we could add an event.preventDefault() after launchBrowser().

Maybe, also a    if (event.button == 0)
wouldn't be a bad idea, at least until the "open" method doesn't work as it should.
Attachment #569169 - Flags: review?(bv1578) → review+
Thanks for the comments. I've solved this by adding a second, optional, parameter to launchBrowser that takes care of watching for left click and stops propagation.

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/922bba081c7b>
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
You need to log in before you can comment on or make changes to this bug.