417869 - Browser context is difficult to obtain from many XPCOM callbacks

Status: RESOLVED WONTFIX

(Firefox :: Extension Compatibility, enhancement)

Description

[Mike Perry]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Firefox/2.0.0.12 XPCOMViewer/1.0a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Firefox/2.0.0.12

It is very difficult to determine which tabbrowser many XPCOM callbacks originate from, and in some cases absolutely no context information is provided at all. This makes writing extensions that would like to do per-tab settings and content filters difficult to impossible.

So far, I've noticed the following callbacks have these deficiencies:
nsIProtocolProxyFilter::applyFilter (http://www.xulplanet.com/references/xpcomref/ifaces/nsIProtocolProxyFilter.html)

This callback provides no context, not even a content node, for the extension to decide the appropriate proxy policy for this URL. This makes writing secure versions of extensions like FoxyProxy (that determine proxy settings based on url filters) impossible to write.

nsIContentPolicy::shouldLoad (http://www.xulplanet.com/references/xpcomref/ifaces/nsIContentPolicy.html)
This interface does provide the DOMnode responsible for loading the url. However, it is difficult to map this back to a tabbrowser without enumerating every single window and tab. There is no back link from a content window to its parent tabbrowser element.

nsIWebProgressListener::on* http://www.xulplanet.com/references/xpcomref/ifaces/nsIWebProgressListener.html Again, it is possible to extract a contentWindow from the aRequest parameter, but it is an O(tabs) operation to find the corresponding tab.

The common suggestion in the mozilla developer documentation is also ambiguous. It is not possible to simply call nsIWindowMediator::getMostRecentWindow, as this only gives the FOCUSED window, and not the window receiving the events. 


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
The APIs lack context.

Comment 1

[timeless]

a number of these interfaces are fairly frozen. the apis suck, but you get to live with them. this especially should apply to contentpolicy and webprogresslistener.

note that tab browsers are really an implementation detail. it sounds like you want tabbrowser to provide a service that will tell you which tab owns a docshell. that's a perfectly reasonable request (but amusingly it's really not that hard to write in js), certainly a c++ implementation that used a hashtable would be much faster.

Comment 2

[friend]

(In reply to comment #1)
>but amusingly it's really not that hard to write in js
What would it take to get you to implement & post a JS class which does this?

Comment 3

[Mike Perry]

friend: I actually wrote one myself. Feel free to use it as you see fit. It actually does caching as well (though be sure to call expireOldCache() periodically):
https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/window-mapper.js

timeless: I guess it probably is too much to ask to change the content policy and webprogress interfaces, since all the calls to them would have to be updated.. But in the case of the nsIProtocolProxyFilter, what about an nsIProtocolProxyFiler2 then? Or perhaps add an nsIProxyInfo member setter to tabbrowser to set the proxy for that tab? The proxy filtering is the most egregious case, since there is no context whatsoever. I'm not sure is not even possible to write a truly secure version of the FoxyProxy extension without that context (hence Eric Jung's quick uptake of this bug). See my comments at http://archives.seul.org/or/talk/Dec-2007/msg00131.html.

Comment 4

[timeless]

*shrug*, i don't own any of the interfaces. in the old days (before Netscape 7) there was a team responsible for API freezing, and in theory you could probably have asked them for help. Today, you'll probably have to file bugs w/ well conceived patches for each component for each interface you want improved. Before doing that, I'd suggest you track down the module owners and ask them for their opinions.

fwiw, I've actually been in this position, we needed some of this information, and I was generally relatively OK (I think for content policies I may have even filed a bug asking for this, in which case, I'd appreciate it if you found and used that bug instead of filing a new one).

Comment 5

[timeless]

fwiw, I don't like the idea of confirming a meta bug like this, it's really not helpful.

Comment 6

[Eric Jung [:ericjung]]

(In reply to comment #0)

> It is very difficult to determine which tabbrowser many XPCOM callbacks
> originate from, and in some cases absolutely no context information is provided
> at all. This makes writing extensions that would like to do per-tab settings
> and content filters difficult to impossible.
> 
> So far, I've noticed the following callbacks have these deficiencies:
> nsIProtocolProxyFilter::applyFilter
> (http://www.xulplanet.com/references/xpcomref/ifaces/nsIProtocolProxyFilter.html)
> 
> This callback provides no context, not even a content node, for the extension
> to decide the appropriate proxy policy for this URL. This makes writing secure
> versions of extensions like FoxyProxy (that determine proxy settings based on
> url filters) impossible to write.

Timeless, do you have any ideas on how to get docshell/window/browser/tab/tabbrowser from within nsIProtocolProxyFilter::applyFilter() callbacks?

Comment 7

[Jesper Hansen]

Not sure if this is related, but i managed to get the panel/tab id for tabs that ex. working out of the user focus (working tabs that aint selected by the user but is still requesting+other ex. meta refresh (hope everyone understands this)) with help from ideas of many. 


function getDOMWindow ( /* in nsIChannel */ aChannel ) {
	try {
		var requestor = aChannel.notificationCallbacks;
		var win = requestor.getInterface(Components.interfaces.nsIDOMWindow);
		var tabid = gBrowser.getBrowserForDocument(win.document).parentNode.id;
		return tabid;
	} catch (e) {
		return null;
	}
}

== Usage ==
var httpChannel = aSubject.QueryInterface(Components.interfaces.nsIHttpChannel);
getDOMWindow(httpChannel);

== Full cut code ==
http://pastebin.mozilla.org/446711

Comment 8

[Jesper Hansen]

Should be noted that the above doesn't work well with 3xx redirection it seems.

Comment 9

[Jakob Ericsson]

This is not a solution to the problem in nsIProtocolProxyFilter.applyFilter.
nsIProtocolProxyFilter.applyFilter doesn't give you anything decent to work with.

nsIProxyInfo applyFilter ( nsIProtocolProxyService proxyService , nsIURI URI , nsIProxyInfo proxy )

proxyService is used as a factory for creating new nsIProxyInfo.
URI is the actual URI to test to see if it should be proxied or not.
proxy is a nsIProxyInfo set by another object higher up in the call hierarchy, i.e. Network preferences in your firefox instance.

Comment 10

[Eric Jung [:ericjung]]

(In reply to comment #9)
> This is not a solution to the problem in nsIProtocolProxyFilter.applyFilter.
> nsIProtocolProxyFilter.applyFilter doesn't give you anything decent to work
> with.

See bug 436344. I have a patch for it that I'll be submitting shortly.

Comment 11

[Jakob Ericsson]

Great!

Comment 12

[obsolete.fax]

If 3.6.4 is about fixing Out Of Process Plugins - OOPP, shouldn't the Importance of this bug be changed from Enhancement ==> Normal.

Comment 13

[shawn.sumin]

The Tor Project / Electronic Frontier Foundation is paying to have this bug fixed.

"If you know C++ and/or Firefox internals, we should be able to pay you for your time to address these issues and shepherd the relevant patches through Mozilla's review process."

Source: https://blog.torproject.org/blog/web-developers-and-firefox-hackers-help-us-firefox-4

Comment 14

[Andy McKay]

This is no longer relevant for Firefox since all extensions are now WebExtensions. If this is relevant to other parts of Firefox that use XPCOM, let's reopen and move to a non Extension Compat component.