Getting rid of enablePrivilege
Boris Zbarsky
poor UX (popups asking a user to grant incomprehensible permissions), it
has weird function-level scoping, and it has opaque privilege strings
that make no sense to anyone. It also complicates security code a fair
amount.
At the same time, it seems to be used a fair bit for intranet apps.
Earlier today there was a brainstorming session about use cases for
enablePrivilege, and we came up with the following:
1) Working around same-origin restrictions
2) Working around DOM security/privacy restrictions (things like
getting the full path from a file input, or setting the value
of a file input).
3) Enabling programmatic copy/paste in Midas
4) Cross-site XHR (a variant of #1)
5) Mochitests
First of all, are there other major classes of use cases we're missing?
If not, here's a possible course of action:
A) Do something with mochitests (move the relevant one to chrome
tests, expose an object that allows running privileged code,
whatever).
B) Announce that we plan to remove this API in the release after Gecko
1.9.1. Possibly add a warning when it's used in 1.9.1.
C) Do something about the other 4 use cases. The "something" should
have only two levels of permissions: "normal sandbox website" and
the equivalent of UniversalXPConnect. The intermediate privilege
levels are more confusing than they're worth.
D) Remove enablePrivilege after 1.9.1 is done, as well as removing
signed jar code (which is really only used for enablePrivilege).
After a good bit of discussion, for item (C) we're thinking the answer
is an extension. One concern is that making the extension (which must
take input from untrusted content, obviously) secure is nontrivial. So
what would be ideal is for us to expose a communications channel that
such extensions could use and a way to have prefs specifying which sites
can use the communications channel for a given extension. Alternately,
the prefs could specify hostnames that are allowed to pass a chunk of
script with privileges (something like evalOutsideSandbox()). Or
something along those lines. The assumption is that intranet
deployments can set preferences as needed, of course.
The open question are what form this communication channel or
evalOutsideSandbox() functionality should take place. What's really
needed, I think, is feedback on use cases and some discussion (and then
a decision!) about how to make this work.
Ideally the solution we come up with should be simple enough to
implement that we can do it for 1.9.1, to allow sites to start migrating
to the new setup.
Thoughts?
Boris
P.S. Please respect the reply-to and followup-to and keep this on
m.d.platform.
John J. Barton
...
>
> First of all, are there other major classes of use cases we're missing?
I'm not clear on whether the proposed change only applies to calls to
enablePrivilege in extensions or only in web pages, but Firebug calls it
so it can use the MD5 hash function to compute a message digest for
eval() buffers.
>
...
> After a good bit of discussion, for item (C) we're thinking the answer
> is an extension. One concern is that making the extension (which must
> take input from untrusted content, obviously) secure is nontrivial. So
> what would be ideal is for us to expose a communications channel that
> such extensions could use and a way to have prefs specifying which sites
> can use the communications channel for a given extension. Alternately,
> the prefs could specify hostnames that are allowed to pass a chunk of
> script with privileges (something like evalOutsideSandbox()). Or
> something along those lines. The assumption is that intranet
> deployments can set preferences as needed, of course.
>
> The open question are what form this communication channel or
> evalOutsideSandbox() functionality should take place. What's really
> needed, I think, is feedback on use cases and some discussion (and then
> a decision!) about how to make this work.
Again I'm not clear on exactly what you need here, but Firebug 1.2 had
to implement a complex scheme to allow web pages to write into the
Firebug console without compromising the browser. A DOM element is
written from the extension into the page, code is injected via a mixture
of evalInSandbox() and script tags; then both sides set event handlers
on the element to marshal the restricted subset method calls and
arguments.
Conceptually the channel is fine and it works in practice (eventually).
But the setup code has a jizillion failure modes, especially since we
don't want to inject the channel in every page only when the user needs
it (like your prefs I suppose).
Wouldn't you need something similar? If so, it would cool if we had a
better way to achieve it.
jjb
Boris Zbarsky
> I'm not clear on whether the proposed change only applies to calls to
> enablePrivilege in extensions or only in web pages
Extensions shouldn't need to call it at all, so this all only applies to
code running in web pages.
> Conceptually the channel is fine and it works in practice (eventually).
> But the setup code has a jizillion failure modes, especially since we
> don't want to inject the channel in every page only when the user needs
> it (like your prefs I suppose).
>
> Wouldn't you need something similar? If so, it would cool if we had a
> better way to achieve it.
Yeah, your use case was mentioned in this context. I agree that it
would be good to have a better solution for it, and it's worth having a
separate thread about your requirements...
-Boris
Dave Townsend
> D) Remove enablePrivilege after 1.9.1 is done, as well as removing
> signed jar code (which is really only used for enablePrivilege).
I trust you don't mean completely remove the signed jar checking
functions we have which are used to verify signed extensions as well.
Boris Zbarsky
> I trust you don't mean completely remove the signed jar checking
> functions we have which are used to verify signed extensions as well.
Probably not, no. ;) I was more talking about removing certificate
stuff from nsPrincipal, and so forth.
-Boris
Dan Mosedale
> 2) Working around DOM security/privacy restrictions (things like
> getting the full path from a file input, or setting the value
> of a file input).
> 3) Enabling programmatic copy/paste in Midas
> 4) Cross-site XHR (a variant of #1)
> 5) Mochitests
>
>
> C) Do something about the other 4 use cases. The "something" should
> have only two levels of permissions: "normal sandbox website" and
> the equivalent of UniversalXPConnect. The intermediate privilege
> levels are more confusing than they're worth.
>
> is an extension.
I'd be curious to understand why that stuff doesn't belong in the core,
given that it seems like there were be a large set of users for that
group of things...
Dan
Jonas Sicking
> to implement a complex scheme to allow web pages to write into the
> Firebug console without compromising the browser. A DOM element is
> written from the extension into the page, code is injected via a mixture
> of evalInSandbox() and script tags; then both sides set event handlers
> on the element to marshal the restricted subset method calls and arguments.
>
> Conceptually the channel is fine and it works in practice (eventually).
> But the setup code has a jizillion failure modes, especially since we
> don't want to inject the channel in every page only when the user needs
> it (like your prefs I suppose).
>
> Wouldn't you need something similar? If so, it would cool if we had a
> better way to achieve it.
Absolutely. What firebug is doing is exactly what I had in mind when we
discussed this.
Basically we should have a way for an extension to install some API into
a page, and do it such that it is:
* Simple!
Should be as close to just providing a object or function from the
extension that will be accessible by the webpage as possible. Security
is the main limiting factor here.
All the hoops that firebug currently has to jump through is not
acceptable.
* Secure
Firefox should take care of most of the security stuff so that the
extension can focus on functionality.
Should be easy to get the functionality installed only on a limited
set of sites, such as all intranet sites, or just a single site.
* Reliable
Should install the API early enough that it's always accessible from
page script. We should reduce those 'jizillion' failure modes to
something more manageable :)
/ Jonas
Dave Townsend
Well we use
http://mxr.mozilla.org/mozilla-central/source/caps/idl/nsISignatureVerifier.idl
to find the signature which gives us an nsIPrincipal so I guess there is
some relationship there. Obviously that can change and we can use whatever.
John J. Barton
...
> Basically we should have a way for an extension to install some API into
> a page, and do it such that it is:
Possibly related: webkit has a 'console' object intended to be
compatible with Firebug's console. So in addition to "some API" we could
consider "a particular API" (if for example the general case proves
difficult). There is much distance between these really, since you can
only do one thing safely with web-page objects in an extension: walk the
property names down to primitives (getter controls needed). The only
other operation you need is the ability to call a web page function in
the web page (using the name you get from the property walk).
> * Simple!
> Should be as close to just providing a object or function from the
> extension that will be accessible by the webpage as possible. Security
> is the main limiting factor here.
A global object/function would solve many problems. I didn't realize
until recently that components can implement global objects. What I
don't know is whether an extension could control the global object
availability. We need the global to either exist whether or not Firebug
(or another particular extension) was installed or we need the global
existence to be controllable by the extension. Otherwise web pages can
test the existence of the global to learn if the user has Firebug
(or...) installed, but its none of their business. (I'm not enthusiastic
about another round of Firebug console implementation, but this global
object avenue seems promising).
> All the hoops that firebug currently has to jump through is not
> acceptable.
> * Secure
> Firefox should take care of most of the security stuff so that the
> extension can focus on functionality.
> Should be easy to get the functionality installed only on a limited
> set of sites, such as all intranet sites, or just a single site.
> * Reliable
> Should install the API early enough that it's always accessible from
> page script. We should reduce those 'jizillion' failure modes to
> something more manageable :)
These last two bits are the two cases I mentioned above: "always
available" or "under control of extension". The case we don't want is
"available whenever the extension is installed".
>
> / Jonas
Boris Zbarsky
>> After a good bit of discussion, for item (C) we're thinking the answer
>> is an extension.
>
> I'd be curious to understand why that stuff doesn't belong in the core,
> given that it seems like there were be a large set of users for that
> group of things...
A key point here is that the user experience for enabling expanded
privileges for a site needs to clearly indicate that they are installing
software on their computer and that this software can then do whatever
it wants.
We already have such UI in the form of the extension manager, so we want
to leverage that. What the extension does is still an open question.
One possibility is that it just sets some prefs that core code then
reads. Intranet deployment could set those prefs directly during
install of the browser, of course.
That still raises the question of how the site gets its chosen script
communicated to whatever can run things with privileges. I don't think
we ever want to be running privileged code on the untrusted JSContext,
so one way or another the code to be run needs to migrate elsewhere.
Whether the code is put into the extension itself, or passed as a string
to some sort of evalOutsideSandbox() method or something else is also
still open.
-Boris
Boris Zbarsky
> Well we use
> http://mxr.mozilla.org/mozilla-central/source/caps/idl/nsISignatureVerifier.idl
> to find the signature which gives us an nsIPrincipal so I guess there is
> some relationship there. Obviously that can change and we can use whatever.
Sure. Or we can keep an nsIPrincipal that represents a signed cert, but
assert in various places about such certs being used in security checks.
I'd love to know (offline, if you want) what you use this principal for,
other than the prettyName.
-Boris
John J. Barton
...
> That still raises the question of how the site gets its chosen script
> communicated to whatever can run things with privileges. I don't think
> we ever want to be running privileged code on the untrusted JSContext,
> so one way or another the code to be run needs to migrate elsewhere.
> Whether the code is put into the extension itself, or passed as a string
> to some sort of evalOutsideSandbox() method or something else is also
> still open.
>
> -Boris
I've made my opinion of evalInSandbox() known, so I'd vote for
"extension itself" with evalOutsideSandbox() as an option that the
extension may choose. (BTW some example code would make these issues
clearer....)
jjb
Boris Zbarsky
> I've made my opinion of evalInSandbox() known, so I'd vote for
> "extension itself" with evalOutsideSandbox() as an option that the
> extension may choose.
The problem with the "extension itself" approach is that it increases
complexity of the extension, as well as increasing the complexity of the
safe channel we need to expose, since the page needs to be able to
indicate to the extension which code to run.
> (BTW some example code would make these issues clearer....)
Mochitest is a good source of examples. Grep it for EventUtils.js or
enablePrivilege calls, and ask yourself how you'd do that sort of thing
with an extension and how you'd go about securing that extension.
-Boris
John J. Barton
> John J. Barton wrote:
>> I've made my opinion of evalInSandbox() known, so I'd vote for
>> "extension itself" with evalOutsideSandbox() as an option that the
>> extension may choose.
>
> The problem with the "extension itself" approach is that it increases
> complexity of the extension, as well as increasing the complexity of the
> safe channel we need to expose, since the page needs to be able to
> indicate to the extension which code to run.
Ok, you could just say you already decided on the other solution ;-)
>
>> (BTW some example code would make these issues clearer....)
>
> Mochitest is a good source of examples. Grep it for EventUtils.js or
> enablePrivilege calls, and ask yourself how you'd do that sort of thing
> with an extension and how you'd go about securing that extension.
>
> -Boris
By design of the safe channel the only operation the page will allowed
is some possibly elaborate version of "print()" right? The web page
can't run any methods outside its context; the extension can't run any
methods of the page from outside. So the extension is going to fill the
sandbox with some methods that ultimately yield strings. It has to take
care that these methods do not expose data to the page, eg other pages
state, users settings? The web page, over joyed to see these methods,
will call them with data from the page. When the extension gets control
again it can take strings out of the box. It still has to take care to
not to eg write the strings to disk or another page etc.
Safe but not very powerful, works for Firebug console, but I don't get
how you can allow the other cases and still be safe.
jjb
Boris Zbarsky
> Ok, you could just say you already decided on the other solution ;-)
Nothing's been firmly decided on that front. I'm just explaining what
the tradeoffs are.
> By design of the safe channel the only operation the page will allowed
> is some possibly elaborate version of "print()" right?
That depends...
> The web page can't run any methods outside its context; the extension can't run any
> methods of the page from outside.
The latter is false, and the former may be false depending on the
approach we take here.
> So the extension is going to fill the
> sandbox with some methods that ultimately yield strings.
That's one approach to the situation, yes.
> It has to take
> care that these methods do not expose data to the page, eg other pages
> state, users settings?
Not necessarily, since the fundamental assumption is that this setup
should allow selected pages to do things they normally can't do.
> Safe but not very powerful, works for Firebug console, but I don't get
> how you can allow the other cases and still be safe.
"safe" means that you don't allow sites other than the ones the user
trusts to cause code to be executed with privileges (either directly or
on their behalf).
-Boris
Dave Townsend
Currently yes we just get the prettyName off the principal (with some
comment from you that maybe that isn't the best option) and it is
displayed in the add-on install confirmation dialog. Then after download
of course we verify that the contents of the xpi haven't changed since
being signed.
There are bugs around requesting improvements here, such as bug 278629
which wants to include access to the full signing certificate from the
install dialog.
Dave
Boris Zbarsky
> There are bugs around requesting improvements here, such as bug 278629
> which wants to include access to the full signing certificate from the
> install dialog.
Right. So in all cases, you'd be OK with just an nsIX509Cert or an
nsISupports that you can QI to that interface.
In any case, removing code here is a lower priority than switching to a
new setup for expanded privileges, so I'd sort of like to refocus
discussion on use cases for expanded privileges and suggestions for how
they should work.
-Boris
fsta...@gmail.com
are making a fairly intensive use of enablePrivilege (~ 300-400
occurences in our code base). That's the reason why, after Boris
pointed out this discussion, I take the opportunity to give some
feedback on the subject.
I speak on behalf of all the developers involved. First a little
overview of what we're doing :-)
The application's entire interface is implemented in XUL. Of course,
it requires the user to be authentified. A signed jar containing the
main window is generated upon login and it references stylesheets (not
included in the jar as of today) that map the apprioriate tags to our
50-100 custom bindings we implemented. Those bindings are fetched from
the server one by one "on demand" (by using the -moz-binding CSS
property, which contains the URL of a php script). They are always
processed server-side, using php, as they depend on the user
connected (lang, permissions, ...). The processing often only consists
in using our i18n translation mechanisms, but sometimes we complete
the implementation section of the bindings (adding methods, fields,
properties...).
The reason we interact with XUL this way won't be discussed here -
choices made more than three years ago, we use this technology since
2005 and have several hundreds of customers for the product.
To come back to the subject, among the first 4 use cases of
enablePrivilege mentionned in the first post, we are directly
concerned by 1,2,3 (our Richtext Editor is based on Midas and the
same origin issue often arises through the use we make of iframes). We
don't do cross site XmlHttpRequest as far as the core of our product
is concerned, but customer specific developement might use this
feature.
We also access some XPCOM interfaces here and there:
- for file uploads (nsIMultiplexInputStream, nsIFileInputStream,
nsIBufferedInputStream, ...)
- for writing/accessing local files (nsILocalFile, directory service)
- all drag and drop operations in general inside the interface
(nsIDragService).This is a crucial point for us.
- inIDOMUtils to perform operation on content of iframes displaying
html content generated by the CMS, and fetch the result of the
transformations.
- ...
90% of the time we ask for UniversalXPConnect and a few
UniversalBrowserWrite here and there. I suppose you get the idea :-)
Our overall feeling is that the existing privilege API is confusing
and agree that it's scoping policy is a bit strange. Also, since
firefox 1.5 and the clear(and legitimate) concern that you guys showed
in improving FF security, the number of places where we had to use
enablePrivilege increased, while we have the feeling that given the
nature of our application our clients aren't directly concerned by
most of the exploits.
We are developing and deploying a very specific application: we host
it, configure client machines to access, have full control on the code
(server-side and client-side). It is our responsibility to handle its
security and protect it against exploits. Of course, FF should be as
secured as possible - but ideally it should not prevent us from doing
accessing some functionalities, for that specific application, hosted
on a specific domain.
If my interpretation of Boris' first post is correct, going towards
the possibility to set preferences "somewhere" to handle privileges
would be nice as long as people doing remote XUL rather than
extensions don't get left over.
This post might be a bit vague, but, well - the application is not
open source and there are a certain number of points that can't be
discussed on a public list. There are probably very few projects using
XUL the way we do :-)
Franck
Boris Zbarsky
fsta...@gmail.com wrote:
> To come back to the subject, among the first 4 use cases of
> enablePrivilege mentionned in the first post, we are directly
> concerned by 1,2,3 (our Richtext Editor is based on Midas and the
> same origin issue often arises through the use we make of iframes)
OK.
> We also access some XPCOM interfaces here and there:
This is something we'd like to avoid exposing to web content, basically.
Looking at your use-case, would using chrome over https basically work
for you instead of using signed jars over https? Sine you control both
client and server, this might be an acceptable option. That said, see
below.
> - for file uploads (nsIMultiplexInputStream, nsIFileInputStream,
> nsIBufferedInputStream, ...)
Would the new HTML5 APIs for getting file data once the user selects a
file in an <input type="file">, combined with XMLHttpRequest fill this need?
> - for writing/accessing local files (nsILocalFile, directory service)
Do you need this to just save information your app uses, or to create
arbitrary files? Could you use DOM storage for the former?
> - all drag and drop operations in general inside the interface
> (nsIDragService).This is a crucial point for us.
Would the HTML5 drag/drop API (which I believe will be implemented in
Firefox 3.1) fill this need? If not, what are the shortcomings it has?
> - inIDOMUtils to perform operation on content of iframes displaying
> html content generated by the CMS, and fetch the result of the
> transformations.
I'd be curious to find out more about the use cases here.
> We are developing and deploying a very specific application: we host
> it, configure client machines to access, have full control on the code
> (server-side and client-side).
Does this application have to run inside the browser, or could it run as
a Prism app, say?
> If my interpretation of Boris' first post is correct, going towards
> the possibility to set preferences "somewhere" to handle privileges
> would be nice as long as people doing remote XUL rather than
> extensions don't get left over.
I have to be honest... Given that you control both sides of the table,
why can't your code be an extension? It could even behave the same from
the user's point of view as far as looking like a tab in Firefox, if
that's desired. I realize the code is already written; I'm wondering
whether there are technical reasons it couldn't work.
> There are probably very few projects using XUL the way we do :-)
We've heard of quite a number sorta anecdotally (nor precisely as you
do, with on-the-fly jar generation, but similar after that point)...
We've just had a hard time getting hold of the people involved.
Again, I really appreciate the feedback; knowing what people are doing
and in what ways existing (or upcoming) web specifications don't address
their needs is very helpful in this context.
-Boris
Bryan White
> First of all, are there other major classes of use cases we're missing?
I just stumbled on this thread. I realize it is a couple of months old
but here are my thoughts.
I manage a set of about 30 signed xul/jar intranet apps.
In all cases, when needed I use UnivercalXPConnect, mostly because that
works and documentation is (or at least was at the time) sparse on what
priv to ask for.
I have been developing the code since 2004 and there may be changes in
the interim that I am not aware of.
Here is a list of how I use enablePrivilege:
1) Assigning a custom view to a <tree>. This is critical functionality.
Without custom tree views I would not be using XUL. I long for the
day when something similar makes its way into HTML but I am not holding
my breath.
2) Creating 'atoms' for use in a custom tree view (getCellProperties and
getRowProperties). I have never understood why styling should need
protection.
3) Opening windows to other XUL or HTML applications. This code really
bothers me:
var blocked = PB.getBoolPref("dom.disable_open_during_load");
if(blocked)
PB.setBoolPref("dom.disable_open_during_load",false);
win = window.open(url,name,features);
if(win) win.focus();
if(blocked)
PB.setBoolPref("dom.disable_open_during_load",true);
Manipulating browser preferences in this instance is scary.
4) Copy a string to the clipboard. Usually transferring a grid of data
as a string in a form that a spreadsheet will understand.
5) Logging a message to the error console, Only needed for debugging.
The js debugger is flaky and to my knowledge firebug does not work in
jar files.
6) Populating the HTML content of an iframe. I had problems with this
last Spring. I think those problems were fixed in FF3.0 and I need to
review this to see if the privs are still required.
7) Printing the content of an iframe. iframe.contentWindow.print().
8) JSON encode/decode. My understanding is FF3.1 will have an alternate
API and will not require privs.
9) iframe.contentWindow.scrollTo(0,pos);
10) drag and drop
11) Some mechanism for file upload. My current hack is to embed an
iframe with an HTML file upload form.
One of my pet peaves is the dialog that pops up the first time the user
runs an app. If they decline permission, the will never be able to use
any of the apps. There is no Options GUI for revisiting this decision.
Short of creating a new profile, I am not even certain how do to this
now.
Bryan White
Smaug
Couldn't you use <input type="file"> and then grab the data using
input.files.item(0).getAsDataURL() and send that data using XMLHttpRequest?
Boris Zbarsky
> 1) Assigning a custom view to a <tree>. This is critical functionality.
> Without custom tree views I would not be using XUL. I long for the
> day when something similar makes its way into HTML but I am not holding
> my breath.
OK. That doesn't need dynamic per-JS-stackframe permissions, though, right?
> 2) Creating 'atoms' for use in a custom tree view (getCellProperties and
> getRowProperties). I have never understood why styling should need
> protection.
Because the API is moronic. We should just fix this.
> 3) Opening windows to other XUL or HTML applications. This code really
> bothers me:
> var blocked = PB.getBoolPref("dom.disable_open_during_load");
> if(blocked)
> PB.setBoolPref("dom.disable_open_during_load",false);
> win = window.open(url,name,features);
> if(win) win.focus();
> if(blocked)
> PB.setBoolPref("dom.disable_open_during_load",true);
> Manipulating browser preferences in this instance is scary.
This looks like you're trying to bypass the popup blocker, no? Why do
you need to do that, exactly?
> 4) Copy a string to the clipboard. Usually transferring a grid of data
> as a string in a form that a spreadsheet will understand.
Yeah, this is a problem; untrusted content shouldn't be able to get at
the clipb oard. OK.
> 6) Populating the HTML content of an iframe. I had problems with this
> last Spring. I think those problems were fixed in FF3.0 and I need to
> review this to see if the privs are still required.
Yeah, that's odd. This is quite doable without privileges, in general
> 7) Printing the content of an iframe. iframe.contentWindow.print().
An iframe you don't control, right?
> 8) JSON encode/decode. My understanding is FF3.1 will have an alternate
> API and will not require privs.
Indeed.
> 9) iframe.contentWindow.scrollTo(0,pos);
Again, if the subframe is something you don't control, correct?
> 10) drag and drop
Firefox 3.1 is shipping an implementation of the HTML5 d&d API. Does
that address your use cases?
> One of my pet peaves is the dialog that pops up the first time the user
> runs an app.
How would you like the setup to look here, in terms of the user
basically allowing you to do whatever you want with their computer?
-Boris
Jonas Sicking
alternative if you don't have extra privileges. And that will always be
the case.
I think that part of our plan here was to create better APIs to enable
extensions to inject APIs into pages of their choice. The pages could
then call into these APIs to perform the operations they need.
So for example an extension could add an API to a set of pages that
exposes the ability to access the clipboard.
/ Jonas
Dan Mosedale
> There are definitely things below for which there is no current
> alternative if you don't have extra privileges. And that will always be
> the case.
>
> I think that part of our plan here was to create better APIs to enable
> extensions to inject APIs into pages of their choice. The pages could
> then call into these APIs to perform the operations they need.
>
> So for example an extension could add an API to a set of pages that
> exposes the ability to access the clipboard.
I like this direction a lot, in part because while I'm wearing my
messaging hat, I can imagine various ways to enhance people's messaging
experiences on the web using this approach.
Dan
Bryan White
> Bryan White wrote:
>> 1) Assigning a custom view to a <tree>. This is critical
>> functionality. Without custom tree views I would not be using XUL.
>> I long for the day when something similar makes its way into HTML but
>> I am not holding my breath.
>
> OK. That doesn't need dynamic per-JS-stackframe permissions, though,
> right?
If I don't do it get:
[Exception... "Security error" code: "1000" nsresult: "0x805303e8
(NS_ERROR_DOM_SECURITY_ERR)" location:
"chrome://global/content/bindings/tree.xml Line: 0"]
My recollection is this was not always the case but I do not know when
it changed.
>> 3) Opening windows to other XUL or HTML applications. This code
>> really bothers me:
>> var blocked = PB.getBoolPref("dom.disable_open_during_load");
>> if(blocked)
>> PB.setBoolPref("dom.disable_open_during_load",false);
>> win = window.open(url,name,features);
>> if(win) win.focus();
>> if(blocked)
>> PB.setBoolPref("dom.disable_open_during_load",true);
>> Manipulating browser preferences in this instance is scary.
>
> This looks like you're trying to bypass the popup blocker, no? Why do
> you need to do that, exactly?
It is possible this is not needed. I remember having problems at one
time with windows not opening. I quick test shows it is not now needed.
I need to do a more through test.
>> 7) Printing the content of an iframe. iframe.contentWindow.print().
>
> An iframe you don't control, right?
>
>> 9) iframe.contentWindow.scrollTo(0,pos);
>
> Again, if the subframe is something you don't control, correct?
I just tried both the above without the privs and it seems to work.
Perhaps it did not at some point in the past.
>> 10) drag and drop
>
> Firefox 3.1 is shipping an implementation of the HTML5 d&d API. Does
> that address your use cases?
I have not looked at HTML5 d&d yet. I hope to soon.
>> One of my pet peaves is the dialog that pops up the first time the
>> user runs an app.
>
> How would you like the setup to look here, in terms of the user
> basically allowing you to do whatever you want with their computer?
It is not how it looks. The problem is if the user does not grant the
access it does not ask again and there is no good way to get it to ask
again. The remembered decision does not show up anywhere in the Options
stuff (at least that I can find).
Bryan
Boris Zbarsky
>>> 1) Assigning a custom view to a <tree>. This is critical
>>> functionality. Without custom tree views I would not be using XUL.
>>> I long for the day when something similar makes its way into HTML but
>>> I am not holding my breath.
>>
>> OK. That doesn't need dynamic per-JS-stackframe permissions, though,
>> right?
>
> If I don't do it get:
Yes, I know you need to enablePrivilege now. But allowing custom views
seems like something that should be set by the user on a per-site basis,
not on a per-JS-function basis as now.
> My recollection is this was not always the case but I do not know when
> it changed.
When we realized that a misbehaving custom view can crash the browser
exploitably? ;)
>>> 7) Printing the content of an iframe. iframe.contentWindow.print().
>>
>> An iframe you don't control, right?
>>
>>> 9) iframe.contentWindow.scrollTo(0,pos);
>>
>> Again, if the subframe is something you don't control, correct?
>
> I just tried both the above without the privs and it seems to work.
> Perhaps it did not at some point in the past.
It should work any time your code and the iframe's window are same-origin.
>> How would you like the setup to look here, in terms of the user
>> basically allowing you to do whatever you want with their computer?
>
> It is not how it looks. The problem is if the user does not grant the
> access it does not ask again and there is no good way to get it to ask
> again. The remembered decision does not show up anywhere in the Options
> stuff (at least that I can find).
OK, gotcha.
-Boris
Jonas Sicking
> 2) Creating 'atoms' for use in a custom tree view (getCellProperties and
> getRowProperties). I have never understood why styling should need
> protection.
For what it's worth I don't think you need to do this any more. If you
in JS pass a string to a XPCOM function that wants an nsIAtom, we'll
magically convert it for you.
Though I guess it might be more performant to create an atom once and
then call the function multiple times reusing the same atom.
/ Jonas
Jonas Sicking
> 2) Creating 'atoms' for use in a custom tree view (getCellProperties and
> getRowProperties). I have never understood why styling should need
> protection.
For what it's worth I don't think you need to do this any more. If you
Neil
> Bryan White wrote:
>
>> 2) Creating 'atoms' for use in a custom tree view (getCellProperties
>> and getRowProperties). I have never understood why styling should
>> need protection.
>
> For what it's worth I don't think you need to do this any more. If you
> in JS pass a string to a XPCOM function that wants an nsIAtom, we'll
> magically convert it for you.
It doesn't explicitly want an atom though, because it's an array, so it
will take anything it can convert to an nsISupports.
--
Warning: May contain traces of nuts.
Bryan White
>> var blocked = PB.getBoolPref("dom.disable_open_during_load");
>> if(blocked)
>> PB.setBoolPref("dom.disable_open_during_load",false);
>> win = window.open(url,name,features);
>> if(win) win.focus();
>> if(blocked)
>> PB.setBoolPref("dom.disable_open_during_load",true);
>> Manipulating browser preferences in this instance is scary.
>
> This looks like you're trying to bypass the popup blocker, no? Why do
> you need to do that, exactly?
I did some looking into this one. It usually but not always works. One
particular scenario that fails is like this:
The page opens. In onload does async XHR to get a bunch of data from
the server. This may take two or three seconds to respond. When the
XHR request finishes, opens another XUL window. The popup blocker kicks
in at that time. If it make a difference, these are the window features
requested: 'chrome,close,width=750,height=450,resizable,dialog'. Also
the window URL is to a file in the opener's JAR file.
Bryan
Boris Zbarsky
> The page opens. In onload does async XHR to get a bunch of data from
> the server. This may take two or three seconds to respond. When the
> XHR request finishes, opens another XUL window. The popup blocker kicks
> in at that time. If it make a difference, these are the window features
> requested: 'chrome,close,width=750,height=450,resizable,dialog'. Also
> the window URL is to a file in the opener's JAR file.
Yeah, this is definitely something the popup blocker would, and should,
block...
OK.
-Boris