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

Status: RESOLVED FIXED

(Calendar :: Preferences, defect)

Description

[Christoph Mueller]

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

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I don't have a such server available, setting qawanted.

Comment 2

[Nico Haase]

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.

Comment 3

[Christoph Mueller]

Attachment: calendar entry (VEVENT) to demonstrate the problem (standalone, does not require calendar server)

Comment 4

[Christoph Mueller]

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...).

Comment 5

[Christoph Mueller]

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?

Comment 6

[Mark Banner (:standard8)]

Check your "browser.chromeURL" preference, it should be set to "chrome://messenger/content/messengercompose/messengercompose.xul".

Comment 7

[Nico Haase]

(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 :(

Comment 8

[Christoph Mueller]

"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...

Comment 9

[Mark Banner (:standard8)]

(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.

Comment 10

[Christoph Mueller]

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.

Comment 11

[Christoph Mueller]

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 ;-)

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 16

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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?

Comment 17

[Mark Banner (:standard8)]

(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.

Comment 18

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 19

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v1

Fix using launchBrowser()

Comment 20

[Decathlon]

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.

Comment 21

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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>

Comment 22

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

releases/comm-aurora changeset 559cc6673f9c
releases/comm-beta changeset 913cc0cb37f9