Closed
Bug 541310
Opened 14 years ago
Closed 13 years ago
Related Link (in Edit Task and Edit Event Window) is NOT clickable
Categories
(Calendar :: Preferences, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.0
People
(Reporter: christoph.mueller, Assigned: Fallen)
References
Details
(Whiteboard: [needed beta][no l10n impact])
Attachments
(2 files)
1.92 KB,
text/plain
|
Details | |
1.38 KB,
patch
|
bv1578
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
Version: unspecified → Lightning 1.0b1
Assignee | ||
Comment 1•14 years ago
|
||
I don't have a such server available, setting qawanted.
Keywords: qawanted
Comment 2•14 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•14 years ago
|
||
Reporter | ||
Comment 4•14 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•14 years ago
|
Version: Lightning 1.0b1 → Lightning 1.0b2
Reporter | ||
Comment 5•14 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?
Comment 6•14 years ago
|
||
Check your "browser.chromeURL" preference, it should be set to "chrome://messenger/content/messengercompose/messengercompose.xul".
Comment 7•14 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•14 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...
Comment 9•14 years ago
|
||
(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•14 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•14 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 ;-)
Assignee | ||
Comment 12•14 years ago
|
||
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 | ||
Comment 15•13 years ago
|
||
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
Assignee | ||
Comment 16•13 years ago
|
||
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•13 years ago
|
||
(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.
Assignee | ||
Comment 18•13 years ago
|
||
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•13 years ago
|
Assignee: philipp → nobody
Product: Thunderbird → Calendar
QA Contact: preferences → preferences
Assignee | ||
Comment 19•13 years ago
|
||
Fix using launchBrowser()
Assignee | ||
Updated•13 years ago
|
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]
Comment 20•13 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+
Assignee | ||
Comment 21•13 years ago
|
||
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
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Assignee | ||
Comment 22•13 years ago
|
||
releases/comm-aurora changeset 559cc6673f9c releases/comm-beta changeset 913cc0cb37f9
Target Milestone: Trunk → 1.0b8
You need to log in
before you can comment on or make changes to this bug.
Description
•