Overwriting launchExternalURL
G4TechTV
of the things I would love to do is overwrite
messenger.launchExternalURL() but it being an interface, I'm not sure
how too.
Can anyone help me out here?
Thanks!
MASA
Philip Chee
> I work on the ThunderBrowse Project (http://thunderbrowse.com) and one
> of the things I would love to do is overwrite
> messenger.launchExternalURL() but it being an interface, I'm not sure
> how too.
Basically it's just a thin C++ wrapper around the following code:
var uri =
Components.classes["@mozilla.org/network/io-service;1"]
.getService(Components.interfaces.nsIIOService)
.newURI(urlstring, null, null);
var protocolSvc =
Components.classes["@mozilla.org/uriloader/external-protocol-service;1"]
.getService(Components.interfaces.nsIExternalProtocolService);
protocolSvc.loadUrl(uri);
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.
[ ]There is a tiny plant here, murmuring "water, water".
* TagZilla 0.066.6
G4TechTV
> On Mon, 15 Jun 2009 22:25:32 -0700 (PDT), G4TechTV wrote:
> > I work on the ThunderBrowse Project (http://thunderbrowse.com) and one
> > of the things I would love to do is overwrite
> > messenger.launchExternalURL() but it being an interface, I'm not sure
> > how too.
>
> Basically it's just a thin C++ wrapper around the following code:
>
> var uri =
> Components.classes["@mozilla.org/network/io-service;1"]
> .getService(Components.interfaces.nsIIOService)
> .newURI(urlstring, null, null);
> var protocolSvc =
> Components.classes["@mozilla.org/uriloader/external-protocol-service;1"]
> .getService(Components.interfaces.nsIExternalProtocolService);
> protocolSvc.loadUrl(uri);
>
> Phil
>
> --
> 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.
> [ ]There is a tiny plant here, murmuring "water, water".
> * TagZilla 0.066.6
So can I write it in a fashion of:
var messenger = {
launchExternalURL: function(whatever)
{
//code
}
};
and it would work? I thought you can't do stuff like that if it's
based in core.
Philip Chee
> So can I write it in a fashion of:
>
> var messenger = {
> launchExternalURL: function(whatever)
> {
> //code
> }
> };
>
> and it would work? I thought you can't do stuff like that if it's
> based in core.
Well you are operating in javascript so what you have is a javascript
object that reflects some native code via XPCOM. Since this is just a js
object you can override any of its methods (including native code) with
your own js.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
G4TechTV
> On Wed, 17 Jun 2009 01:36:34 -0700 (PDT), G4TechTV wrote:
> > So can I write it in a fashion of:
>
> > var messenger = {
> > launchExternalURL: function(whatever)
> > {
> > //code
> > }
> > };
>
> > and it would work? I thought you can't do stuff like that if it's
> > based in core.
>
> Well you are operating in javascript so what you have is a javascript
> object that reflects some native code via XPCOM. Since this is just a js
> object you can override any of its methods (including native code) with
> your own js.
>
> Phil
>
> --
> 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.
Right, but if I recreate it as a component, I would have to recreate
all of nsIMessenger. Is there a way to just overwrite only that one
specific function or can I call everything from nsIMessenger and I'll
be fine?
G4TechTV
the component. I'm now rewriting the messenger variable.
messenger = {
launchExternalURL: function(whatever)
{
alert(whatever);
},
__noSuchMethod__: function __noSuchMethod__ (id, args)
{
//what's the best way to launch these?
},
};
Andrew Sutherland
__noSuchMethod__ will not handle attributes on the interface.
There is also the issue that there may be multiple messenger instances
per window; not just one.
Andrew
G4TechTV
Do you have any ideas for a better solution?
G4TechTV
There are three major reasons why I want to do this:
1) I want to fix a bug where certain attributes applied to html
elements will load in both Firefox and ThunderBrowse (no matter how
much I use event.preventDefault(), it still happens). An example of an
attribute is onSubmit();
2) Submitting a document more than once or clicking on a link while
another page is about to load will cause the page to load in both
Firefox and ThunderBrowse
3) Doing so will allow me to capture more url data and launch it all
within ThunderBrowse (also would make other Thunderbird extensions
that don't have support for ThunderBrowse to have their content loaded
within ThunderBrowse).
Mark Banner
> Apparently, it's best to say what the purpose is here.
Are we talking about Thunderbird 2 or Thunderbird 3 (or both even?)
> There are three major reasons why I want to do this:
Looking at
http://mxr.mozilla.org/comm-central/search?string=launchExternalURL and
http://mxr.mozilla.org/comm-central/search?string=openUILink I'm having
a hard time fitting your reasons into what we currently do.
Re-ordering your reasons:
> 3) Doing so will allow me to capture more url data and launch it all
> within ThunderBrowse (also would make other Thunderbird extensions
> that don't have support for ThunderBrowse to have their content loaded
> within ThunderBrowse).
I agree with this. I've two thoughts here. We could replace the
launchExternalURL calls with what the function actually does, or replace
with a call to a central function which is in js and does the work.
My concern here would be that if you override that call, and another
extension came along and wanted to do the same thing, then there would
be a conflict of interests. Maybe there is a better way we can provide a
call for extensions to hook into.
> 1) I want to fix a bug where certain attributes applied to html
> elements will load in both Firefox and ThunderBrowse (no matter how
> much I use event.preventDefault(), it still happens). An example of an
> attribute is onSubmit();
> 2) Submitting a document more than once or clicking on a link while
> another page is about to load will cause the page to load in both
> Firefox and ThunderBrowse
Looking at the links above, I can't see how launchExternalURL would
affect this. Maybe I've missed something.
My guess is that it is more likely to do with the fact we don't
"support" http/https loads*, and we're forcing them to be loading
externally. So when you come along with your onclick handler, even
though you call preventDefault() preventing the onclick load, some other
item is kicking in and trying to load the url as well (or maybe before
the onclick happens).
* don't "support" in the sense that we override the
network.protocol-handler.* prefs for Thunderbird:
http://mxr.mozilla.org/comm-central/source/mail/app/profile/all-thunderbird.js#282
Standard8
Dan Mosedale
>> 3) Doing so will allow me to capture more url data and launch it all
>> within ThunderBrowse (also would make other Thunderbird extensions
>> that don't have support for ThunderBrowse to have their content loaded
>> within ThunderBrowse).
the way the code happens to flow now. I think it's hard discuss how the
code _should_ flow without talking about use cases. What are some
specific use cases you want to support that you're currently finding
difficult?
> I've two thoughts here. We could replace the launchExternalURL calls
> with what the function actually does, or replace with a call to a
> central function which is in js and does the work.
wrapper for nsIExternalProtocolService.loadUrl. Given that there are
exactly four callers in the tree today, I'm not entirely convinced that
it needs to continue to exist. That said, specific use cases (as
requested above) could well change my mind.
> My concern here would be that if you override that call, and another
> extension came along and wanted to do the same thing, then there would
> be a conflict of interests. Maybe there is a better way we can provide
> a call for extensions to hook into.
might well be easier to implement if we put this method somewhere other
than on nsIMessenger.
>> 1) I want to fix a bug where certain attributes applied to html
>> elements will load in both Firefox and ThunderBrowse (no matter how
>> much I use event.preventDefault(), it still happens). An example of an
>> attribute is onSubmit();
>>
>> 2) Submitting a document more than once or clicking on a link while
>> another page is about to load will cause the page to load in both
>> Firefox and ThunderBrowse
>
> Looking at the links above, I can't see how launchExternalURL would
> affect this. Maybe I've missed something.
>
> My guess is that it is more likely to do with the fact we don't
> "support" http/https loads*, and we're forcing them to be loading
> externally. So when you come along with your onclick handler, even
> though you call preventDefault() preventing the onclick load, some
> other item is kicking in and trying to load the url as well (or maybe
> before the onclick happens).
>
>
> * don't "support" in the sense that we override the
> network.protocol-handler.* prefs for Thunderbird:
> http://mxr.mozilla.org/comm-central/source/mail/app/profile/all-thunderbird.js#282
>
offers control over what loads when. My suspicion is that flipping
those prefs
would fix problems 1 and 2. I got the impression from G4TechTV
yesterday that he didn't think that the prefs offered the right
granularity of control for that to make sense, though. G4, am I
remembering correctly, and, if so, can you elaborate on what the
problems there are?
Dan
G4TechTV
>
> Indeed, those prefs are currently the way the external protocol service
> offers control over what loads when. My suspicion is that flipping
> those prefs
> would fix problems 1 and 2. I got the impression from G4TechTV
> yesterday that he didn't think that the prefs offered the right
> granularity of control for that to make sense, though. G4, am I
> remembering correctly, and, if so, can you elaborate on what the
> problems there are?
>
> Dan
No, I don't want to just toggle the prefs as by doing so, the urls
won't do anything and will leave the user confused. I want to capture
the data as well.
Mark Banner
I'm confused. Are you saying you don't want to toggle the prefs because
doing so does nothing when you click on the link? Or maybe that if you
toggle the prefs onclick doesn't get called?
I think both cases are more to do with the general problem that we
aren't capable of handling links internally.
I'll see if I can take a look today and find out what is happening there
with those prefs.
Standard8
Mark Banner
I've just been thinking about this thread and what Thunderbird is doing
a bit more, and I think I've just realised what you are asking. So let
me restate a few things to be sure.
Your problem is that certain actions within web pages cause loads to
happen in Firefox (and maybe Thunderbrowse) even though you are trying
to capture via onclick.
You want to be able to have all form submits and other actions to load
within the same browser element, rather than getting thrown at a browser.
If that is the case, then I think the issue is Thunderbird. Part of the
main window code is effectively denying loading of events back into the
browser element it came from. It needs some work and some checking, but
I think we could fix this within Thunderbird so that you wouldn't have
to redirect those types of actions (or possibly even onclicks) back into
Thunderbird. You could still have onclick handlers to direct where a
link click should go etc, just like Firefox does for its open in
tab/window etc.
If you want I can get a test build via the try server with a potential
fix in for you to play around with, even if it may be a bit rough around
the edges, just to see if we're heading in the right direction.
Standard8
G4TechTV
wrote:
That's one thing I was saying. Thunderbird hits something it cannot
understand and force fires it to Firefox.
The problem is mainly javascript attributes on elements that would end
up changing the page. For example: onClick, onSubmit, form.submit(),
onSelect, etc etc.
But the other thing I want to do is intercept links launched by other
extensions and send them back to my extension.
Dan Mosedale
> But the other thing I want to do is intercept links launched by other
> extensions and send them back to my extension.
>
extension and code that's part of the core. Whenever a link is launched
from chrome, it will be treated the same way, unless the extension code
goes out of its way to cause that not to happen.
Dan