The default bug view has changed. See this FAQ.

Browser context is difficult to obtain from many XPCOM callbacks

NEW
Unassigned

Status

()

Firefox
Extension Compatibility
--
enhancement
9 years ago
6 years ago

People

(Reporter: Mike Perry, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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

9 years ago
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

9 years ago
(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?


(Reporter)

Comment 3

9 years ago
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

9 years ago
*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).
(Reporter)

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

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

Comment 6

9 years ago
(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

9 years ago
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

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

Comment 9

9 years ago
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

9 years ago
(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

9 years ago
Great!

Updated

7 years ago
Flags: blocking1.9.0.19?
Flags: blocking1.9.0.19?

Comment 12

7 years ago
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

6 years ago
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
You need to log in before you can comment on or make changes to this bug.