Re: href in XUL label - linking borked in TB3?

[Philip Chee]

On Mon, 21 Dec 2009 09:32:43 +0000, Axel Grude wrote:

> Labels in an options dialog that contain a href to a web site do not
> open the link in the configured browser anymore.
>
> Instead they throw this error:
>
> No chrome package registered for chrome://navigator/content/navigator.xul
> ----------
>
>
> Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
> [nsIDOMJSWindow.open]
> Source file: chrome://global/content/bindings/text.xml
> Line: 353
>
> the line that fails is:
> if (uri)
> win.open(uri.spec);

In Thunderbird < 3.0, http:// was an external protocol so the external
protocol handler was called to hand off the url to your systems default
browser.

In 3.0 http became an exposed protocol so Thunderbird tries to handle
this internally. I'm still not sure why this problem occurs since you
are not on a Mac.

In:
http://mxr.mozilla.org/comm-1.9.1/source/mail/base/content/utilityOverlay.js#51
There is:

function getBrowserURL() {

try {
var prefs = Components.classes["@mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
var url = prefs.getCharPref("browser.chromeURL");
if (url)
return url;
} catch(e) {
}
return "chrome://navigator/content/navigator.xul";
}

But I'm not sure how this is invoked.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Leni]

Philip Chee wrote:
> On Mon, 21 Dec 2009 09:32:43 +0000, Axel Grude wrote:
>> Labels in an options dialog that contain a href to a web site do not
>> open the link in the configured browser anymore.
>> Instead they throw this error:
>> No chrome package registered for chrome://navigator/content/navigator.xul

I scratched my head over this for a while.

I changed the code to:
<a target="_blank"
onlick="openURL('http://example.com')"
href="http://example.com">example</a>

and

function openURL(url)
{
let ios = Cc["@mozilla.org/network/io-service;1"].
getService(Ci.nsIIOService);
let iuri = ioservice.newURI(url, null, null);
let eps = Cc["@mozilla.org/uriloader/external-protocol-service;1"].
getService(Ci.nsIExternalProtocolService);

eps.loadURI(iuri, null);
}

which seems to work well both in tb2 and tb3.

Leni.

[Axel Grude]

Philip Chee wrote:
> On Mon, 21 Dec 2009 09:32:43 +0000, Axel Grude wrote:
>
>> Labels in an options dialog that contain a href to a web site do not
>> open the link in the configured browser anymore.
>>
>> Instead they throw this error:
>>
>> No chrome package registered for chrome://navigator/content/navigator.xul
>> ----------
>>
>>
>> Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
>> [nsIDOMJSWindow.open]
>> Source file: chrome://global/content/bindings/text.xml
>> Line: 353
>>
>> the line that fails is:
>> if (uri)
>> win.open(uri.spec);

Hi Phil, maybe it helps if I give you more of the Javascript log detail
- I have just installed Venkman to debug the call as well.

Error Console Output:

No chrome package registered for

chrome://browser/content/contentAreaUtils.js
----------
Error: [Exception... "Component returned failure code: 0x80040154
(NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDocShellHistory.useGlobalHistory]"
nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)" location: "JS
frame :: chrome://global/content/bindings/browser.xml :: :: line 643"
data: no]
Source file: chrome://global/content/bindings/browser.xml
Line: 647
----------
Warning: Error in parsing value for 'white-space'. Declaration dropped.
Source file: chrome://venkman/content/venkman-output-base.css
Line: 58
----------
QuickFolders:Exception in initDelayed: TypeError:
document.getElementById("QuickFolders-Toolbar") is null
----------

No chrome package registered for chrome://navigator/content/navigator.xul
----------
Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIDOMJSWindow.open]
Source file: chrome://global/content/bindings/text.xml
Line: 353

----------

No chrome package registered for

chrome://browser/skin/extensions/icons/console2-css.png

> In 3.0 http became an exposed protocol so Thunderbird tries to handle
> this internally. I'm still not sure why this problem occurs since you
> are not on a Mac.

is it possible to set a breakpont in text.xml ? Some way to display the
URI generated by ioService?

ALso, if the same version is part of SeaMonkey 2.0 is it possible to
compare here - guess it depends on whether I can debug text.xml...
- I also wonder whether win.open(href) would have worked...

code in (my) text.xml:

var href = this.href;
if (!href || this.disabled || aEvent.getPreventDefault())
return;

var uri = null;
try {
const nsISSM = Components.interfaces.nsIScriptSecurityManager;
const secMan =

Components.classes["@mozilla.org/scriptsecuritymanager;1"]
.getService(nsISSM);

const ioService =
Components.classes["@mozilla.org/network/io-service;1"]

.getService(Components.interfaces.nsIIOService);

uri = ioService.newURI(href, null, null);

var nullPrincipal =
Components.classes["@mozilla.org/nullprincipal;1"]
.createInstance(Components.interfaces.nsIPrincipal);
try {
secMan.checkLoadURIWithPrincipal(nullPrincipal, uri,

nsISSM.DISALLOW_INHERIT_PRINCIPAL)
}
catch (ex) {
var msg = "Error: Cannot open a " + uri.scheme + ": link
using \
the text-link binding.";
Components.utils.reportError(msg);
return;
}

const cID =
"@mozilla.org/uriloader/external-protocol-service;1";
const nsIEPS = Components.interfaces.nsIExternalProtocolService;
var protocolSvc = Components.classes[cID].getService(nsIEPS);

// if the scheme is not an exposed protocol, then opening
this link
// should be deferred to the system's external protocol handler
if (!protocolSvc.isExposedProtocol(uri.scheme)) {
protocolSvc.loadUrl(uri);
aEvent.preventDefault()
return;
}

}
catch (ex) {
Components.utils.reportError(ex);
}

// otherwise, fall back to opening the anchor directly
var win = window;
if (window instanceof Components.interfaces.nsIDOMChromeWindow) {
while (win.opener && !win.opener.closed)
win = win.opener;
}

if (uri)
win.open(uri.spec);
else
win.open(href);

aEvent.preventDefault();

[Axel Grude]

Thanks Leni - coding it by hand is certainly a workaround; although I
still believe its a Mozilla bug, so I wouldn't like to bloat my code too
much to implement this.

Just per interest, how would you fix the broken link in the about dialog
of the Add-Ons Manager? Is it possible to inject JS code like that into
the install.rdf as well?

thx
Axel

[Leni]

Axel Grude wrote:
> Just per interest, how would you fix the broken link in the about dialog
> of the Add-Ons Manager?

Not sure I follow. Which link is broken? Tools/Add-ons/something?

Leni.

[Neil]

Philip Chee wrote:

>In 3.0 http became an exposed protocol so Thunderbird tries to handle this internally. I'm still not sure why this problem occurs since you are not on a Mac.
>
>

Because the <label> tries to use window.open and Thunderbird probably
doesn't support that, although I haven't tried.

--
Warning: May contain traces of nuts.

[Mark Banner]

On 22/12/2009 08:07, Axel Grude wrote:
> Thanks Leni - coding it by hand is certainly a workaround; although I
> still believe its a Mozilla bug, so I wouldn't like to bloat my code too
> much to implement this.

The core mozilla bug is basically
https://bugzilla.mozilla.org/show_bug.cgi?id=263433

It comes down to the fact that text.xml assumes everything is a browser
and doesn't give non-browser apps the opportunity to do anything else.

> Just per interest, how would you fix the broken link in the about dialog
> of the Add-Ons Manager? Is it possible to inject JS code like that into
> the install.rdf as well?

I need to debug the add-ons manager homepage issue as I don't think it
is as clear cut as just adding in some javascript. As mentioned in
https://bugzilla.mozilla.org/show_bug.cgi?id=529215 it works in some
cases and not others which is really quite weird.

I've flagged that bug as needed for the 3.0.x releases, so I'm more
likely to remember to look at it now ;-)

Standard8

[axel....@gmaii.com]

In tools / addons, when you scroll to the extension, then right-click
and select "about", you are presented with an automatically generated
message that contains build information from install.rdf, such as
Version / Author / Developers / Translators etc.

My install.rdf is fairly complex as it needs to support TB, SeaMonkey
and Postbox.

[axel....@gmaii.com]

Thanks Mark,

that's great I was too lazy to search for these bugs in great detail;
now I can close some of my bugs by linking to these :-)

Do you need any more test case files? I can put some up on the Mozdev
page later (if my ISP at home plays nice again). Or just mail me off
list by fixing my (slightly) obfuscated Email address, or via

http://quickfolders.mozdev.org/members.html (click on Axel, not Alex)

thanks again
Axel

[Axel Grude]

Neil wrote:
> Philip Chee wrote:
>
>> In 3.0 http became an exposed protocol so Thunderbird tries to handle
>> this internally. I'm still not sure why this problem occurs since you
>> are not on a Mac.
>>
>>
> Because the <label> tries to use window.open and Thunderbird probably
> doesn't support that, although I haven't tried.
>

Well it used to, in TB2 and older TB3 versions. Whether this is
semantically correct, I wouldn't know.