Closed Bug 546857 (kill-remote-xul) Opened 14 years ago Closed 14 years ago

Drop support for XUL on web sites (remote XUL)

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b5
Tracking Status
blocking2.0 --- beta5+
fennec 2.0b1+ ---

People

(Reporter: jruderman, Assigned: sicking)

References

(Depends on 3 open bugs, )

Details

(Keywords: dev-doc-complete, sec-want, Whiteboard: See comment 198 regarding whitelist, See URL for why this bug was filed)

Attachments

(9 files, 5 obsolete files)

5.40 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
1.14 KB, patch
dwitte
: review+
Details | Diff | Splinter Review
24.72 KB, patch
jst
: review+
Details | Diff | Splinter Review
13.16 KB, patch
dao
: review+
Details | Diff | Splinter Review
4.25 KB, patch
ted
: review+
Details | Diff | Splinter Review
32.48 KB, patch
asaf
: review+
Details | Diff | Splinter Review
6.41 KB, patch
dao
: review+
Details | Diff | Splinter Review
1.04 KB, patch
sicking
: review+
Details | Diff | Splinter Review
4.55 KB, text/html
Details
As I mentioned on http://blog.mozilla.com/security/2010/02/10/fixing-security-holes-without-introducing-new-bugs/, XUL is a major source of security problems.

We're also scared to improve it because we worry that some "dark matter" intranet site might use it.
So what does this mean in practice?  Disallow the XUL content sink?  Disallow creation of nodes in the XUL namespace?  Disallow construction of special XUL frames?  Don't apply xul.css?  Something else?

As far as that goes, how are we defining "web site"?
I would say we would use generic XML elements for the XUL content sink, and use the nsXMLContentSink for the XUL mime type.

And do this for all documents that don't have a system principal.
> I would say we would use generic XML elements for the XUL content sink

I'm not sure I follow this.  Is this to make CreateElementNS do the right thing?

> And do this for all documents that don't have a system principal.

Wouldn't this break some of our stuff like error pages?
(In reply to comment #3)
> > I would say we would use generic XML elements for the XUL content sink
> 
> I'm not sure I follow this.  Is this to make CreateElementNS do the right
> thing?

Yes. We need to return *something* from createElementNS, and we need to insert *something* in the DOM if xul-namespaced elements appear in the DOM. If for no other reason because that's what DOM specs says.

But yeah, we probably need to not add xul.css as well, as to avoid styling these elements.

> > And do this for all documents that don't have a system principal.
> 
> Wouldn't this break some of our stuff like error pages?

Yeah, need to figure something out for these. Do these need to be XUL? Can web pages reach into the DOM of an error page?
Ok, so the answer to my questions from comment 1 sounds like "yes" to all except disallowing creation of nodes in the XUL namespace.  OK.

> Do these need to be XUL? 

I actually just double-checked and the error pages seem to be mostly HTML.  I would assume what little XUL they include (if any) can be replaced.  So we're clear there.

> Can web pages reach into the DOM of an error page?

No (modulo security bugs, of course).
does it mean we really couldn't create web application in XUL ? For example, if we use <menubar>, it won't act like a XUL menubar anymore, it will just be an xml node without the behavior of menubar ? does it mean you kill XUL on the web ?
Yes, that is indeed the very goal here.

Well.. the very goal is to remove the attack surface that comes with allowing XUL
Then you will broke several intranet app.

Couldn't we find a compromize ? in the parser, we generate XUL nodes for safed xul elements (menu, buttons, etc. they are safed, aren't they ?), and for other elements (browser ? tree ? ...) just xml nodes. And we could have a specific xul.css for remote xul.
killing XUL and/or XBL will break some of my apps.

i oppose this.
> Can web pages reach into the DOM of an error page?

DEFINITELY NO.
> does it mean we really couldn't create web application in XUL ?

It it's XUL it's not really a "web application" any more than an ActiveX control is a "web application".  It's a Gecko-based application delivered over the network.  It's not clear that we should be encouraging this.

> Then you will broke several intranet app.

Yes, that's understood.  So will our removal of enablePrivilege, removal of ability to link to XBL1 bindings from untrusted pages, etc.

You can still, of course, deploy such apps as extensions (if you really do want to lock other browsers out as the use of XUL implies) or using HTML.

> (menu, buttons, etc. they are safed, aren't they ?)

Menu is absolutely not, imo.  Button per se is ok, but the things people do with buttons that you can't do with an HTML button have absolutely been security issues historically.

I see no advantages of the proposed compromise over just using HTML for the app.  Am I just missing some?
>it's not really a "web application"

for me, a web application is an application accessible through HTTP and running in a browser

>I see no advantages of the proposed compromise over just using HTML for the
app.

Using XUL has some advantages, it is easier to create a UI:

- because of its flexible box model (for example, no need to play with the css float attribute to align some boxes),
- because of native behaviors of some XUL elements, so we don't need to write many lines of javacript code (ex: creating a menu popup in HTML needs to write some javascript codes whereas in xul, just use a menupopup element..),
- because of performance (displaying many data in a <tree> ..), 
- and because it is natively accessible (don't have to put aria attributes on all elements etc..)

Ok, XUL is implemented only in Gecko, but well, at this time, HTML is not really the better solution to create UI, IMHO. And this is why it's used in some intranet app. 

So that's a shame to drop XUL. Except if you announce that, when you will drop XUL for websites, interactive and forms elements of HTML 5 will be implemented, that the flexible box layout module http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/ will be a candidate recommandation, and that we will see the begining of the end of the implementation of XBL2 :-) (yes, yes, I know, everybody already works hard on many things in gecko :-))

An other reason why dropping xul is a bad thing: all XUL demos in online XUL tutorials won't work any more. It will be harder to convince developers that XUL is a powerful XML language, and is fantastic to develop extensions.
> and running in a browser

Define "browser"?  It sounds like any custom client that happens to speak HTTP fits your bill.  That's not what most people mean when they say "browser".

> - because of its flexible box model

You can use flexbox with HTML in Gecko if you want.  Webkit too, last I checked.

> - because of native behaviors of some XUL elements

Being worked on in the form of HTML5.

> - because of performance (displaying many data in a <tree> ..)

Tree in particular is a security bog.  Note that you suggest blacklisting it above.

> and because it is natively accessible

This is true.  I don't think it outweighs the costs.

> interactive and forms elements of HTML 5 will be implemented,

Dropping XUL on websites is a prerequisite for doing that, basically.

> will be a candidate recommandation

You can use it right now.  Why does it need to be in CR for that?  XUL's certainly not in CR.

> we will see the begining of the end of the implementation of XBL2

Dropping XUL on websites is a prerequisite for this.

Just so we're clear, fixing XUL-related security bugs that we don't have to worry about if XUL is not exposed to untrusted code is a huge percentage of my development time.  Same for roc, sicking, and others last I checked.  I sincerely doubt any progress on XBL2 and HTML5 forms will happen while this amount of effort has to be directed towards the XUL morass.
>Just so we're clear, fixing XUL-related security bugs that we don't have to
>worry about if XUL is not exposed to untrusted code is a huge percentage of my
>development time.

ok, if you kill XUL, most of your development time may be fixing other security bugs, what's the difference?

or you expect dropping xul to be a magic bullet ?
> or you expect dropping xul to be a magic bullet ?

I expect it to reduce the fraction of time I spend on security bugs by a factor of 3 or 4, personally.
>I sincerely doubt any progress on XBL2 and HTML5 forms will happen while this
amount of effort has to be directed towards the XUL morass.

ok, good point :-)

>Dropping XUL on websites is a prerequisite for this. (XBL2 and HTML5 stuffs)

How is it a prerequesite ?
You can currently get a lot of the xul box model via css even for HTML elements, correct?  Are we talking about removing that or is it just XUL + XBL?
> How is it a prerequesite ?

Because otherwise we do not have the developer time to work on XBL2 and HTML5.  First part of comment 17 seemed to me like you got that...

blizzard, we're not talking about removing the moz-box display type.
there might be a grain of sane reason in the original bug, but it is so anti-software-industry i fail to see it
i can live without XUL if management and legal decide so ;)
What is the timeframe for removing remote xul? I ask because I need to know how much time I will have to change my apps to html.
A timeframe for this is vital to know for anyone currently deploying XUL-based intranet apps who will need to update or replace them.

The (small) company I work for is about to launch a large remote-XUL app which we've been working on for 2 years. We picked XUL over HTML for the following reasons:

1) Box model
2) XBL
3) Overlays
4) Templates (despite the difficulty of working with them sometimes)
5) The implicit functionality in XUL widgets (e.g. column sorting, ordering, resising and hiding in trees)

It has always been our plan to migrate to HTML once we feel it's rich enough to support what we need. Primarily this means the CSS3 flexible box model and XBL2, so we're already close to a point where that migration work can begin - though reimplementing all that implicit XUL widget functionality will seriously add to our burden, and even reimplementing our XUL-based XBL widgets will take a while.


As an interim measure I would personally rather have a whitelist of sites allowed to serve XUL. There would be no UI for the whitelist - other than about:config - but it would allow intranets to carry on using their XUL apps for a little longer with just a small amount of effort. It would also bring the issue to the attention of any remote-XUL users who are not aware of this bug, but before it's too late for them to plan a migration strategy.
I don't want to say that this bug should not be fixed, because security for me is paramount.

But remote XUL is important.

It has not taken off due to bug 22942 (can't use remote DTD, i.e. XUL localization doesn't work).

Remote XUL was once proclaimed to be one of the cool features of
Mozilla, and would still be very useful for company-internal applications,
XULRunner apps loading remote content etc..

This has been one of the reasons why TomTom originally chose XULRunner, and the
fact that this is not practically possible has been a major bummer for TomTom,
who distributes a XULRunner app to about 10 million people.

Of course I'm aware that you can't and shouldn't do privileges JS from
remote XUL. The point of remote XUL would have been to tie in our web offers
naturally with the native application - both from the styling perspective (user
POV, native looks, identical to native app, so seamless integration) and the
coding perspective (same dev team can develop remote and local parts, with
identical technology). We needed a native, secure part which can manage the device, install stuff on the TomTom device, manage items stored away on the local computer etc., and a remote part which does the shop (buy map), community stuff (share your self-made Voices, Points of Interest, Routes etc. with others, forums, you name it), promotions and other things.

As is, you practically can't do that, you can't make a website look like a native app or XULRunner app, there's a huge, visible gap between the native app and the web offer.
> I see no advantages ... over just using HTML

- Platform native styling (important, see above)
- Localization without dynamic page generation (requires bug 22942)
- Some XUL widgets like <grid> (vs. <table>) are way faster than HTML,
  to my knowledge. Some XUL widgets don't exist at all in HTML, like
  <tree> or <menu> and can only be emulated (again, *much* slower).
- HTML tends to be messy, XUL can be concise and lends itself much more to
  proper coding, and is much better maintainable.
  (A typical HTML page is about 10 bigger than a typical XUL dialog, and
  with significantly more nesting. Similar differences for the CSS typically
  applied to them.)
  XUL is made for app development, while HTML was made to create text
  documents. It shows.

I am not opposing this bug. I just want to say that there is currently
no appropriate alternative to Remote XUL.
Alias: kill-remote-xul
Summary: Drop support for XUL on web sites → Drop support for XUL on web sites (remote XUL)
> - Platform native styling (important, see above)

-moz-appearance and system colors?

> - Localization without dynamic page generation (requires bug 22942)

So doesn't actually work.

> Some XUL widgets like <grid> (vs. <table>) are way faster than HTML, to my
> knowledge.

I'd like to see some data.  I rather doubt it, actually (for the grid case).

> A typical HTML page is about 10 bigger than a typical XUL dialog

That's mostly a function of XBL being available, actually.
HTML (HyperText Markup Language) A document markup language NOT application language!  AS more people want control of appliances/server/remote appliations a GOOD application language is needed.  XUL is a good application language, HTML5 is not. With out remote XUL, Mozilla will just make another browser.
If better security is needed, add Access Control List to capabilities.
Remote XUL is the way of the future for control of remote appliances/servers/...
XUL is not a W3C standard. You can only use it in Gecko. You're not meant to make web apps with it; you're meant to make real apps with it. And HTML5 is in fact made for web apps, no matter what you say, hence the interactive elements and new form features.
Yes XUL is not a W3C standard. But I must disagree with you, XUL was designed and coded to be a web application language before HTML5 was even dreamed of ( Mozilla REALLY messed up by not promoting it ).

If you look at the choices of languages out there for web applications. Java, .NET, Flash, HTML5, and XUL. 

Java is big and slow to run and load,
 
.NET is Microsoft with patents and other problems,

Flash has security issues and is proprietary,

HTML5 HTML is designed for document markup, presenting documents. The layout sucks, there is still a limited number of application elements, God knows when the all the features will be implemented.  The cool features are not even in HTML5 but  other specs(Web Sockets, Server sent events,...).
HTML5 will never give the user experience XUL, XBL can give. 

Because we are talking about Gecko engine apps, Remote XUL a feature that Gecko can offer that other Browsers can't.  With out it, Firefox becomes just another “me too” browser.
In today's rich media and application based web, it's a suprise that XUL has not been promoted for client-side DHTML in an otherwise Flash/JS driven system. XUL makes some compromises to provide a better application experience. HTML5 must remain, at heart, a content language; not a programming language. Instead of choking one of our unique features, we should extend it to enhance HTTP features (add support for all the verbs) and improve the sandboxing protection. Browers always go their different ways, such as the encoding for HTML5 media. Market share is a dog-eat-dog world and if we don't carve a niche that makes us different, we could fall at the hands of leaner and meaner browsers like Chrome. XUL can become our little present to our users. If other browers adopt it, that will just give us more air. If they don't, then we can advance without them. In a world that is increasingly divided between web services and the mobile applications that serve them, XUL can be it's own API. The great majority of viewers will soon come from mobile devices, not whole desktops. Fennec and us need to prepare for that day, and XUL over HTTP is a good place to start.
(In reply to comment #1)
> So what does this mean in practice?  Disallow the XUL content sink?  Disallow
> creation of nodes in the XUL namespace?  Disallow construction of special XUL
> frames?  Don't apply xul.css?  Something else?
How about just turning off class info on box objects? Only just this week I reviewed a patch to an attack that depended on content access to a box object.

(In reply to comment #11)
> Menu is absolutely not, imo.  Button per se is ok, but the things people do
> with buttons that you can't do with an HTML button have absolutely been
> security issues historically.
Well, given you're excluding menubuttons by the first sentence in that comment, there's not much that I can think of that you can do with a XUL button that you can't do with an HTML button, except spoof third-party themes.

(In reply to comment #5)
> > Can web pages reach into the DOM of an error page?
> No (modulo security bugs, of course).
So does that mean that we don't have to blacklist XUL in error pages? Or, given that error pages can load chrome skin, does that mean that we can copy the xul.css button binding so that the XML element still has the correct look?
One major problem here is that we want to disable XBL1. Once that is done there is very little of XUL that still works.
(In reply to comment #31)
Wow. That's even worse. I don't care if I use <xul:toolbarbutton> or a <html5:button> with CSS as long as the XBL component model is preserved. But disabling XBL-1 is really a big thing.
How about only accepting digitally sign jar files to run remote XUL?. 

This would solve the some of the security problems, it still would allow XUL web apps, but prevent most XUL attacks. One of the issues is language, There would have to a jar file for every language, NOT good, loading remote DTD would have to be fixed. http://bugzilla.mozilla.org/show_bug.cgi?id=22942.  

XBL-2 has been "worked" now for a while.  Would that fix some of the issues?
> This would solve the some of the security problems

Not at all.  Anyone malicious who wants to can create signed jars.
That is why I said most/some.  But if the attacker uses a known signing cert they can be traced, if they create their own cert, the root CA has to be loaded into the browser, (ask if the want to!).  Because it is different than a normal web page the user can be notified and give a choice to run the app.  

Also would be better than most extensions now, they are not even signed.

I am trying to think of a way to save XUL apps, With out remote XUL, Firefox just becomes a Standards compliant bloated browser.  Already people are switching, http://tech.slashdot.org/article.pl?sid=10/06/17/2223241
(In reply to comment #34)
> Not at all.  Anyone malicious who wants to can create signed jars.

Interesting statement. This means that we can drop signed scripts at all?
We're planning to drop support for enablePrivilege, which is currently only enabled for signed scripts, if that's what you mean.  See bug 546848.
(In reply to comment #33)
> How about only accepting digitally sign jar files to run remote XUL?. 

One of the reasons we use remote XUL is that it allows us to do server-side content injection and dynamic code generation using ASP or PHP. I'm not aware of any easy way to do that with signed code, so making signed jars a requirement would be equivalent to completely disabling remote XUL for us anyway.
I have a C/Python framework that does dynamic code generation ( XUL ) by using JSON to transfer data to the app and let JavaScript render the XUL. I do have to have server-side content only for adding language ENTITY to the top of the XUL file. That is why the remote DTD bug is an issue, But having a signed jar for every language is stupid but it works.

Could you create the jar on the fly? Or write JavaScript to create the dynamic code generation?  Or create small signed jars each is like a module and dynamically load jars?
Please forget signed JARs already. Remote XUL support is not going to enabled for signed JARs only. As bz said, that's faulty logic from Netscape times.
Question:  will this mean XUL served from a file:// URL will be unsupported as well?  (I know it generally doesn't work all that well anyway.  I'm just curious.)
A workaround might be http://www.amplesdk.com/ (for standard-compliant, cross-browser, XUL) and http://code.google.com/p/xbl/ though these may not give complete coverage.

Maybe even the XUL documentation wiki could add a section or link to HTML-equivalent templates so XSL could be run on it. With such tools in place, it should also greatly help people make what I understand to be an anticipated eventual transition from XUL to HTML for extensions as well (once the features are there). (I also think the docs might benefit from defining a schema for XUL which could in turn be used for indicating expected children, etc. on the docs pages--which would still remain useful into the future for those who like the convenience of XUL markup.)
I use XUL/XForms for intranet applications because, 1) it can be used on Mac, Linux, and PC, 2) it is easy to set up forms for rich data 3) the logic makes sense the web designer who will need to update the system later 4) still flexible enough to make powerful apps.

I understand the desire to stop the XBL1 headache, but there is no real alternative yet for people who need quick, easy to develop web applications that can be maintained by others (unless you vendor-lock into...).

Can you:
a) leave the layout and widgets alone, so xul pages still render, and
b) provide some way to deliver extensions that "bind" those widgets to the interface delivered from the intranet...

In other words, make the XUL widgets available to intranet designers, while still requiring extensions to do bindings...

Since people who aren't comfortable developing extensions don't develop xbl, the "local only" requirement is not that much of an issue.  However, there are people that build XUL pages for the easy layout and rich widgets...
> I understand the desire to stop the XBL1 headache

That's a separate bug from this one.  There are XUL-specific headaches completely unrelated to XBL such that we need to stop allowing XUL from untrusted sources, period.

> a) leave the layout and widgets alone, so xul pages still render

Not safely.
Removing XUL, a rich and useful application format, seems a bit lazy to me. The answer is simply to provide security with sandboxing and permission gateways. Require users to approve really dangerous things like file access and just accept the utility of this unique Mozilla invention.
ipatrol, you seem to not understand.  The issues are not the permissions model; that works fine.  The issue is that the XUL code was not written with untrusted consumers in mind, and doesn't handle various combinations of tags that make no sense in actual XUL pages but could be used by an attacker.  While it would be possible to fix this, it would require more or less a complete rewrite of the XUL code, because the stupid assumptions are embedded deep in it.

Not doing said complete rewrite is not a matter of laziness, but of the fact that the work can be better spent on other things (which may even be more closely aligned with Mozilla's mission; use of remote XUL does NOT fit into the whole "choice" part of the mission, since it's just vendor lock-in into a particular layout engine no different than ActiveX).
"Mozilla's mission is to promote openness, innovation, and opportunity on the web."  
XUL is a great innovation!  XUL offers an opportunity to create remote applications better than any other browser can offer! The source code is open and any person can write XUL code. I think there is a ActiveX implementation of XUL. Not having XUL would reduce innovation and diminish opportunity for great web applications. Any other browser can implement XUL, they have the source to look at, 

I started writing web applications in 1994, I 1999 I found XUL. It was the answer. If Mozilla evangelize XUL then there would be no need for AJAX or HTML5.

XBL2 Should get more resources devoted to it,  The idea of visual subroutine for the web is a great innovation.  Able to create custom tags using existing tags reduces the need for bloat code. How long has Mozilla been working on XBL2?

Another project that I support is Python as the DOM scripting language, but that is an other story. As more functionality moves to the browser, code executed it the browser grows.
The ideal of writing a 100% and-nothing-more standards-based browser is foolhardy. Believe it or not, the browser wars have started again. The choice is still there as XUL is open source, free, and well documented. It's no different than chosing a predomanantly *nix tarball to hold the source code instead of the more widely supported zip archive.  If we don't show what special things we can do, other open source and more lightweight browsers will overtake us at the casual user and buisness market. If you're just a user, you might not care. But Mozilla's accountant's certainly do!
> XUL is a great innovation! 

But not great for openness.

> XBL2 Should get more resources devoted to it

Yes, exactly.  See comment 14.  You _did_ read this bug before commenting, right?

> Another project that I support is Python as the DOM scripting language

That's been dropped.  There are no consumers after many years of it being possible, and it was imposing unacceptable performance costs.  The relevant code is being removed.

> The ideal of writing a 100% and-nothing-more standards-based browser

You seem to be under the mistaken impression that Mozilla's goal is to write a browser.  It's not.  It's "To promote openness, innovation, and opportunity on the web."  Making things that depend on proprietary techology is NOT the way to do that.

> The choice is still there as XUL is open source, free, and well documented.

You had me there until "well documented".  It's not.  If you think it is, you haven't ever tried to figure out whether a particular XUL code change is ok or not in terms of breaking user layout expectations.  Almost everything really important about XUL is totally undocumented.

> If we don't show what special things we can do

Why do those special things have to be tied to a proprietary format?  We can do a number of special things with HTML, SVG, CSS, OpenType, etc that no other browser can do.  Focusing on those and on adding HTML and CSS features that allow the better parts of what XUL can do is a much better time investment than focusing on shoehorning XUL into a use case it was never designed for.

Note that even if we just stick to browsers, pushing remote XUL will just lead us to become what MSIE became in the early 2000s: the one browser that tries to push its own different thing and that everyone hates as a result.  After all, they were also just pushing neat technologies they had come up with.  Really, if you want to go there, feel free.  I don't, and I think I speak for all the module owners and peers relevant to XUL in any way when I say that.
I wonder how feasible it is to implement XUL on top of HTML and JS.
I think a lot of what XBL does can be implemented in straight JS, with a nice lib. It won't be 100% compatible, e.g. XBL will be gone and events will have somewhat different detail/timing behavior, so apps will have to be ported, but it should keep most of the app-dev (vs. web-dev) "feel" of XUL.
If we do that, we'll also see where HTML5 is still lacking compared to XUL, and fix that.
> I think a lot of what XBL does can be implemented in straight JS

Not its interaction with CSS, not its non-invasive modifications of the DOM.

But yes, the goal is to add more features to HTML/JS/CSS until they can do everything XUL can do now.  That's been happening for years.
XUL is *much* more appropriate for app development than the HTML, even if you could theoretically do the same. The differences are huge and painful, as I notice when I try to write web apps after writing XUL apps.

However, I hope we could bridge the gap between XUL syntax and HTML syntax and element APIs by a lib that implements XUL on top of HTML5. Yes, as I said, there would be differences in the details. Apps would have to be adapted, but less than a complete change to HTML. Even for new apps, I'd rather use such a "XUL 2" API than plain HTML5.

I think what we look for is mostly the XUL format and widget API, as well as *some* functionality to write your own tags, to factor out common, reusable functionality, e.g. custom complex widgets, e.g. your own wizard (let's call it JED).
I don't have an issue with Remote XUL going away - I understand the reasons and agree with them in principle. In practice, however, HTML5 is not (yet) a capable replacement, and reworking remote XUL as an extension isn't always a viable solution either. I would propose the following:

1) Make an official statement that it's being deprecated, and give a timescale. I think Fx4 is too soon to drop it, given the amount of rework needed for any existing remote XUL developer. Personally I would turn it off by default with Fx4, but allow it to be re-enabled via a preference, with an aim towards totally removing it for Fx5.

2) Invest more time and effort - together with the community - into XBL2/HTML replacements for the current set of XUL widgets. Make it easier for developers to replace their XUL trees (for example) without everyone having to write their own - with the advantage that you end up with a widget library that will run on other browsers as well.


The key thing, though, is an official statement and timeline. My boss won't allocate resources to a major rework of our code based on a "NEW" bug which isn't set as a blocker. Does that mean that remote XUL is going away in Fx4 as has been reported recently? That it might be? That it isn't? If you're going to remove a >10 year old technology then please give us the information we need to plan for that change on a reasonable timescale.
BZ, 
Sicking stated in #31 that XBL is the real problem. So do you plan do disable XBL so that XUL won't work anymore or disable XUL rendering at all?
I ask because I havbe to start working on a converter for my XUL pages and it's essential to know if I "only" would need to rewrite the XBL part or I also need to translate all XUL tags to HTML5.
Thanks.

> You had me there until "well documented". It's not.
https://developer.mozilla.org/En/XUL
As well as third-party documentation on XUL. Projects exist (http://enwp.org/XUL) which run exclusively on remote XUL.
> The issue is that the XUL code was not written with     >untrusted consumers in mind, and doesn't handle >various combinations of tags that make no
>sense in actual XUL pages but could be used by an >attacker.
I don't see where all this FUD comes from. If there's an issue, a security hole is a security hole and an issue for any XUL programs. Explain what the problem is!
> Sicking stated in #31 that XBL is the real problem.

bz also stated in comment 44 and 46 that the XUL implementation itself is a problem, even if XBL was no problem (and it is). You may believe bz :-) <http://hg.mozilla.org/mozilla-central/log?rev=Boris+Zbarsky>

As he said, he and others tried for a long time to fix all the holes, and they just couldn't, there are too many, too dense. When he says that fixing the holes would amount to a rewrite, you may trust his judgement. Please do not call him a FUD-spreader, that's offending.
Here's the first draft of our xul2html converter:
http://www.zooos.com/xulconverter/

In case someone is interested in using/improving this thing, please send me a mail.
(In reply to comment #53) 
> 1) Make an official statement that it's being deprecated, and give a timescale.
> I think Fx4 is too soon to drop it, given the amount of rework needed for any
> existing remote XUL developer. Personally I would turn it off by default with
> Fx4, but allow it to be re-enabled via a preference, with an aim towards
> totally removing it for Fx5.

How about this: http://blog.mozilla.com/addons/2010/07/21/compatibility-for-firefox-4-time-to-get-started/. I doubt the timescale is going to be changed, but you should take into account that Firefox 4 is still months away, and user migration is going to take some time after that. It may not be enough time to migrate very large applications, but clients could hold on to 3.6 while the migration occurs.
(In reply to comment #58)
> How about this:
> http://blog.mozilla.com/addons/2010/07/21/compatibility-for-firefox-4-time-to-get-started/.
> I doubt the timescale is going to be changed, but you should take into account
> that Firefox 4 is still months away, and user migration is going to take some
> time after that. It may not be enough time to migrate very large applications,
> but clients could hold on to 3.6 while the migration occurs.

Yes, I saw that, but it isn't clear to me how "official" that is: whether it represents an official policy decision, or just reflects the existence of this bug. If this is really going to happen in the Fx4 timescale, then changing this bug status from NEW or setting a blocking flag on it would seem to be a good step to take.

"Months away" isn't really good enough for those of us facing large migrations. I've got 40k lines of remote XUL code (of which about a quarter is XBL) to migrate to *something* else, but it's not at all clear what *something* should be. Migrating to HTML5 will take too long, but the whole application (actually a suite of about 50 individual applications) has been designed around being delivered from a web server, making the move to an add-on equally difficult in its own way.

Completely removing remote XUL without a transitional period of deprecation would be like Microsoft turning off ActiveX entirely with just a few months notice.
> I don't see where all this FUD comes from.

Code inspection while fixing _lots_ of XUL security bugs due to pervasive and systemic failure to do any input validation.  I'm obviously not going to post details about remaining security issues in a public bug, if that's what you were angling for, though.

Mark, I appreciate your position, but there have in fact been several announcements months to years old that we wanted to do this (without timeframes, agreed, since at the time it wasn't clear when we'd have the resources).  Perhaps they weren't "official" enough or user-facing enough...
Hish, XBL is a separate bug (don't have the bug number right now).  This bug is about disabling XUL in the sense that generic XML elements would be used instead of XULElement, that special XUL layout objects (like listbox) would not get instantiated, that the special XUL non-DOM-compliant parsing wouldn't happen.  That _might_ be the full list.
(In reply to comment #60)
>
> Mark, I appreciate your position, but there have in fact been several
> announcements months to years old that we wanted to do this (without
> timeframes, agreed, since at the time it wasn't clear when we'd have the
> resources).  Perhaps they weren't "official" enough or user-facing enough...

I've been aware of this since March (so a a few months, but certainly not years), so perhaps not user-facing enough. Given that many bugs ramble on for years with no resolution, it wasn't obvious whether to start panicking that the sky was falling or not at that stage.

There are bound to be developers - and worse still, users of "dark matter" remote XUL apps whose developers have moved on - who will not be aware of this change. The first they'll hear of it is when they upgrade to Fx4 and their vital intranet application breaks. 

That's why I think a period of deprecation is essential. If their apps stop working but can be re-enabled with a pref, they're more likely to discover this bug report and realise that they will _have_ to replace or rework their software before the next major release - but will at least have a workaround in the meantime.

Just turning it off with no workaround and no deprecation period leaves any users or developers who haven't yet heard about this change completely in the lurch, which strikes me as a pretty poor approach.
(In reply to comment #62)
> That's why I think a period of deprecation is essential. If their apps stop
> working but can be re-enabled with a pref, they're more likely to discover this
> bug report and realise that they will _have_ to replace or rework their
> software before the next major release - but will at least have a workaround in
> the meantime.
> 
> Just turning it off with no workaround and no deprecation period leaves any
> users or developers who haven't yet heard about this change completely in the
> lurch, which strikes me as a pretty poor approach.

FF4 is not out yet, FF3.6 supports remote XUL, and FF3.6 will continue to be maintained for some amount of time after 4.0 hits the wire, too. I rather suspect that means there will be some supported version of Firefox which supports remote XUL for at least 9-12 months.
blocking2.0: --- → ?
(In reply to comment #61)
> Hish, XBL is a separate bug (don't have the bug number right now).

Bug 546856. Prior to that, there was bug 379644 (resolved WONTFIX in 2008).
This is looking like a color of the bikeshed thing. I have not seen a convincing case for ending all uses of remote XUL without so much as an about:config option. And yet we're all arguing instead on exactly how to do this. Firefox is losing users to Chrome and yet all you can do is point to various standards whose resulting outputs are inconsequental to most users. So what if it can render that svg diagram or render that equasion faster and a bit more accurately. But when a prospective convert opens a webpage and is greeted by a rich, dynamic interface that stands in stark comparison to slow javascript, little-used html5, or buggy java, they think, "Whoa, that's cool!" Chrome is turning into an operating system, XUL can provide the ritch application experience they're used to in a sleek yet less powerfull netbook enviroment. Wake up! Mozilla is a buisness who's profit is based on the number of people who use its products. They only support standards because it makes it easier for others to transition to Mozilla. The fact that XUL is non-patented and open source allows us to keep this little feature without drawing any signifigant allegations of hypocricy from the standard bodies. A cleanup of the parser and a few scope restrictions would be good anyway to keep rogue addons from doing too much damage. The folks at Mozilla do not have the luxury of Stallman to crusade against capitalism while making their money on the lecture circut. There are employees to be paid and mouths to be fed, that's what real life is like.
ipatrol, you're done here. You may or may not intend this comment to be trolling, either way, it sure as hell isn't going to have its stated intent.

bikeshedding is when those who know, or think they know, about a topic decide to get in the way of people trying to do a thing, in order to tell them how it "should" be done. If that's happening here, I assure you it's not by Boris.

That you haven't seen a convincing case is, I'm sorry to say, largely beside the point. It's not Boris Zbarsky's job to convince you - his job is to understand, better than basically any person alive, the complex interplay of standards, code quality, and security that inform our decisions about platform feature support. He does it exceptionally well.

The lectures about operating a web business in the "real world" have no place in bugzilla, much less when they labour under significant misapprehensions about what Mozilla is (e.g. that we are profit-motivated). Advocacy in general is right out of place here; take it to the newsgroups if you must take it anywhere.

I *think* you believe yourself to be helping, to be a voice of reason trying to steer a project you care about. I hope that's true, because we always want passionate, thoughtful people in our community, even when we disagree. But if that's your intent, your choice of venue, method of expression, and patronizing tone undermine that effort rather fatally.

This change is happening. It keeps our users safer by reducing attack surface, aligns well with our mission, eases code maintenance burden, and frees up extremely valuable and limited talent to work on other, more important things. Indeed most of the reason I'm replying here at all is to save Boris and Jonas the effort.
Many people are very passionate about remote XUL. They have spent years developing software the uses XUL because it is the best web application language. Rewriting whole applications can destroy small companies.

Comments 53 & 52, are the best compromise.  Mozilla would also gain by supplying a library or extension that supports the major XUL elements, <listbox>,<tree>,box model,...
I think if a plan of action and time table for Mozilla to do this would reduce the stress and passion this issue creates.
(In reply to comment #63)
> FF4 is not out yet, FF3.6 supports remote XUL, and FF3.6 will continue to be
> maintained for some amount of time after 4.0 hits the wire, too. I rather
> suspect that means there will be some supported version of Firefox which
> supports remote XUL for at least 9-12 months.

I do understand that - heck, I'm relying on it - but I think a complete switch off, rather than a period of deprecation, leads to some problematic scenarios:

1) It's harder to sell a remote XUL product that requires an "old" version of Firefox. During the period that the software is being transitioned to an extension or HTML, companies still need to sell the existing product.

2) Upgrading Firefox is easy, downgrading is hard. Any remote XUL user who isn't aware of this change will likely upgrade when prompted, discover that their vital intranet app doesn't work anymore, and then be faced with having to downgrade again. Compare that with "set this pref to keep you running for the time being, but it really, really is going away in Fx5, so start your migration plans now".

3) You'll end up with the IE6 situation whereby some people _never_ upgrade due to essential internal apps. There will always be some who fall into that category, but for others the additional period of a deprecated release will give them the chance to plan a migration rather than just decide to stick with 3.6 forever.


Mozilla isn't really doing much to help us migrate existing apps. Where are the tutorials about converting from remote XUL to an extension? Where are the XBL2-driven drop-in replacements for XUL widgets (particularly complex widgets like trees) for those who choose to migrate to HTML instead? What do we do about overlays and templates? Is there a recommended alternative or sample JS/PHP/ASP code to acheive similar results? All these things take time to evaluate and implement: deprecating remote XUL for a release gives us more time to deal with these issues, and perhaps for the community to produce these aids if Mozilla doesn't step up.



Disclosure: I'm in scenario (1) - we're about to launch our remote XUL software (designed for intranet use) after 2+ years of development. In six months time it's going to become a very hard sell indeed if we have to tell people that it works in Firefox, but only an older version, not the one they'll be offered if they go to the Firefox website. I suspect that this scenario is a minority one, even amongst remote XUL devs: scenario (2) is more likely and a bigger concern precisely _because_ it affects people who don't know about this bug, and may not even know that they're running a remote XUL app until it suddenly stops working.
Mark C, Ample SDK might be of interest to you. It has some cross-browser XUL emulation features. http://www.amplesdk.com/examples/xul/
Thanks Henri. I have come across Ample SDK before, and will certainly look into it further now. If anything, however, it just reinforces the point that finding the best migration strategy takes time - Ample SDK is worth investigating, but it's just one of several options that all need to be considered and evaluated before a migration can begin in earnest.
bz et al: I think Mark C's comments are very reasonable and understandable.
As for his suggestion to release FF4 with remote XUL turned off by default, but that it can still be enabled via pref: Is this a workable suggestion? Are you just intending to cut off access to XUL from content, where you could just check a pref whether to deny or allow? Or are you intending to do a major code rework given the new freedom, and that rework makes sense to do now and not later?
Obviously, users who enable the pref would run with security holes, and we'd need to make sure they realize that (e.g. via docs or pref name or popup dialog).
A pref option for remote xul is good but it just delays the migration problem.  There still needs to a migration path.

Mozilla should create a web application library. It should use the standards that firefox is good at, A client web application framework.

At least there should be a document on what options there are, and code examples of how to translate xul into something else.
We've tried to avoid "exploit me now" prefs in the past, but we have no plans to do major code rework in anything XUL-related for 4.0 at this point.  So yes, this could probably be pref-controlled...  Note that the pref would allow _all_ remote XUL, including from random attack web pages, etc.

> but it just delays the migration problem. 

Well... that's the most common thing to do to make migrations easier, yes.

> Mozilla should create a web application library

That might be a good idea.  Can you please start a thread in .platform?  Though note that we'd really like to do all sorts of stuff; the problem is manpower...
(In reply to comment #73)
> We've tried to avoid "exploit me now" prefs in the past, but we have no plans
> to do major code rework in anything XUL-related for 4.0 at this point.  So yes,
> this could probably be pref-controlled...  Note that the pref would allow _all_
> remote XUL, including from random attack web pages, etc.


Stating the obvious, but such a pref should, of course, only be exposed via about:config.

To address the issue of random attack web pages, would it be feasible to make the pref a string which would take a comma-separated series of IP addresses (or better still, address/mask combinations) as a whitelist?

I'd wager that most intranet use of remote XUL is served from just one or two web servers within an organisation, so this approach would reduce the surface area for an internet-based attack even further.
> would it be feasible to make the pref a string which would take a
> comma-separated series of IP addresses

No.  It _might_ be possible to do hostnames, with a lot of work, but ip address information is simply not available on the DOM level (and isn't even well-defined; for example a single <video> might come from multiple IPs as it streams).
(In reply to comment #75)
> > would it be feasible to make the pref a string which would take a
> > comma-separated series of IP addresses
> 
> No.  It _might_ be possible to do hostnames, with a lot of work, but ip address
> information is simply not available on the DOM level (and isn't even
> well-defined; for example a single <video> might come from multiple IPs as it
> streams).

I'm not sure how applicable something like <video> is with respect to remote XUL - I doubt many intranet apps are using it, and those that are probably aren't streaming from multiple IPs. Even if it is applicable, allowing CIDR notation would allow the same behaviour as a boolean "enable for the whole internet" pref by setting it to 0.0.0./0 (not that I would recommend that generally). But if the IP isn't available at the right level in the code, it's a moot point anyway.


If there's no way to whitelist by IP, and no pratical way to do it by hostname, then I would still be in favour of a pref, even if it means the browser allows _all_ remote XUL - I was just hoping that there might be an easy(ish) way to minimise the attack surface while still allowing remote XUL to be enabled for intranet use during the Fx4 lifecycle.
<video> was just an example.  As I understand the HTTP spec, any given resource could come from multiple IPs in the right circumstances; it's just particularly easy for <video>.
(In reply to comment #77)
> <video> was just an example.  As I understand the HTTP spec, any given resource
> could come from multiple IPs in the right circumstances; it's just particularly
> easy for <video>.

I understand that, but I also suspect it's particularly unlikely that remote XUL will be served from many substantially different and unpredictable IPs. In most cases being able to specify just a few addresses would be sufficient, and for any really oddball deployments using 0.0.0.0/0 would be no worse than a boolean "true". But as I said, moot point anyway if the IP isn't available and using the domain would require a lot of work.
I think having a "remote-xul.trusted-uris" setting would be a good PERMANENT solution to the problem, at least from an IT perspective...

It should have the exact same format as the "network.negotiate-auth.trusted-uris" setting, since one must configure that setting for Intranets anyway.  Then, when you roll your msis and debs, it's just one more setting to pre-configure.
It's been brought to my attention that this isn't assigned to me.
Assignee: nobody → jonas
Marking blocking2.0 beta4+.
blocking2.0: ? → beta4+
Ok, so I've come to the conclusion that there is no point using XUL for my networked applications and best use HTML instead seeing as XUL is going to completely die some day in the near future.

But I need to continue development now rather than waiting to see what Mozilla decides to do with the various Mozilla technologies. So I have some questions about the whole Mozilla platform.

- Will the Mozilla runtime (currently xulrunner) continue to exist even after XUL has died, or do I need to abandon the Mozilla runtime altogether (choosing instead to embed Gecko into my own C/C++ application)?
- When XUL has died is the Mozilla runtime going to use a HTML page instead of a XUL page for it's default window on startup?
- What's going to happen to XPCOM and Javascript modules, technologies which are often used in XUL applications, are they always going to be available?
- What is the best way forward, should I create a XUL window for my application but fill it with an interface written entirely in HTML in order to minimise future changes when XUL finally dies?

Another point which is not important but I am curious about: I take it that the browser's interface is going to be ported from XUL to HTML at some point then?
(In reply to comment #82)
> Ok, so I've come to the conclusion that there is no point using XUL for my
> networked applications and best use HTML instead seeing as XUL is going to
> completely die some day in the near future.

This bug is purely about stopping XUL from working for untrusted content like webpages. There are no plans to kill XUL altogether. Applications based on XULRunner and extensions will still be able to use XUL. The rest of your questions are basically irrelevant once you understand that.
nsDOMParser currently requires that the principal is passed in. There is no way to pick up the calling principal other than if you use the constructor on Windows (new DOMParser). However that constructor is not available in xpcshell.

Additionally things are a bit extra complicated by the fact that we really expect to be able to get a uri out of the used principal when initalizing. However this obviously doesn't work if the principal is the system principal.

In a fortunate turn of events, if we're using the system principal, we'll eventually end up using a null principal as the principal for the final document. So in that case we can use the document uri of the null principal.

This is essentially what already happens as we initialize with a null principal once you start parsing, if we haven't been initialized yet. However for some changes happening later in this bug, that implicit init won't work as we really need mOriginalPrincipal to be the system principal.
Attachment #464747 - Flags: review?(bzbarsky)
This is sort of a temporary hack to allow permissions to be set for all documents loaded from file://. There is no way in UI to actually set these permissions. This is intentional for now as that will require all sorts of security reviews and probably UI changes.

So for now this just lets mochitest or addons to set permissions for file:// by manually poking values into the database.
Attachment #464750 - Flags: review?
We currently use <xul:button>s for all buttons in error pages. I've been told that this is to get them styled as UI buttons in case the rendering differs (don't remember specifics, maybe setting style through userContent.css?)

Ideally we need to find a different fix here, but I think this is good enough for beta. I'll file a followup to try to find a better solution here.
Attached patch Part 4: Fix feed reader (obsolete) — Splinter Review
Put the feed reader UI into a binding as to allow it to still use XUL.
Make unit test profiles contain a default permissions.sqlite file which enables xul/xbl on all domains where we run tests (including file:// for reftest/crashtest)
Attachment #464760 - Flags: review?(ted.mielczarek)
Attachment #464750 - Attachment is patch: true
Attachment #464750 - Attachment mime type: application/octet-stream → text/plain
Attachment #464750 - Flags: review? → review?(dwitte)
Comment on attachment 464750 [details] [diff] [review]
Part 2: Allow permissions to be set on files.

>+  // no host doesn't mean an error. just return the default. Unless this is
>+  // a file uri. In that case use a magic host.

Can you recapitalize the existing comment?

Would be nice to put a comment outside ::GetHostEntry() saying that it can also accept a <foo>-style host and will perform an exact lookup since it doesn't contain a dot.

r=dwitte
Attachment #464750 - Flags: review?(dwitte) → review+
Comment on attachment 464755 [details] [diff] [review]
Part 3: Don't use XUL for buttons in error pages

>diff --git a/browser/base/content/aboutRobots.xhtml b/browser/base/content/aboutRobots.xhtml
>--- a/browser/base/content/aboutRobots.xhtml
>+++ b/browser/base/content/aboutRobots.xhtml
>@@ -71,17 +71,17 @@
>       var buttonClicked = false;
>       function robotButton()
>       {
>         var button = document.getElementById('errorTryAgain');
>         if (buttonClicked) {
>           button.style.visibility = "hidden";
>         } else {
>           var newLabel = button.getAttribute("label2");
>-          button.setAttribute("label", newLabel);
>+          button.textContent = newLabel;
>           buttonClicked = true;
>         }
>       }
>     ]]></script>
> 
>     <style type="text/css"><![CDATA[
>       #errorPageContainer {
>         background: url('chrome://browser/content/aboutRobots-icon.png') left 0 no-repeat -moz-Field;
>@@ -134,21 +134,20 @@
>         <!-- Short Description -->
>         <div id="errorTrailerDesc">
>           <p id="errorTrailerDescText">&robots.errorTrailerDescText;</p>
>         </div>
> 
>       </div>
> 
>       <!-- Button -->
>-      <xul:button xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>-                  id="errorTryAgain"
>-                  label="&retry.label;"
>-                  label2="&robots.dontpress;"
>-                  oncommand="robotButton();" />
>+      <button id="errorTryAgain"
>+              label=""
>+              label2="&robots.dontpress;"
>+              onclick="robotButton();">&retry.label;</button>
> 
>       <img src="chrome://browser/content/aboutRobots-widget-left.png"
>            style="position: absolute; bottom: -12px; left: -10px;"/>
>       <img src="chrome://browser/content/aboutRobots-widget-right.png"
>            style="position: absolute; bottom: -12px; right: -10px;"/>
>     </div>
> 
>   </body>
>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js

>   // Attach a listener to watch for "command" events bubbling up from error
>   // pages.  This lets us fix bugs like 401575 which require error page UI to
>   // do privileged things, without letting error pages have any privilege
>   // themselves.
>-  gBrowser.addEventListener("command", BrowserOnCommand, false);
>+  gBrowser.addEventListener("click", BrowserOnCommand, false);

It looks like we really don't want to run this handler for each and every click on content.
Dão: I was a bit concerned about this too. However it seems unlikely that this is actually a problem. We'd waste at the most a few milliseconds on each click, which usually doesn't happen more than once every few seconds.

Even in extreme cases when the user is hammering a mouse button, it seems like unlikely that this is noticeable to a user.
Comment on attachment 464757 [details] [diff] [review]
Part 4: Fix feed reader

Mano: Would you be able to look at this. Would love to get this into beta 4.
Attachment #464757 - Flags: review?(mano)
Only attach a listener while on error pages
Attachment #464755 - Attachment is obsolete: true
Attachment #465072 - Flags: review?
Attachment #465072 - Flags: review? → review?(dao)
> Only attach a listener while on error pages

Great, thanks!

+      if (/^about:/.test(aBrowser.contentWindow.document.documentURI)) {

Don't you have an nsIURI here, e.g. from aBrowser or from aRequest (see a few lines up)? You could do:
  if (aRequest.URI.scheme == "about")

Note sure if that's a problem, but I'd only removeEventListener() when there's actually a listener. (That's a very common case, for every normal page load.)

NIT: I'd rename BrowserOnCommand() to reflect that it's only about error pages e.g. ErrorPageOnButtonPressed() or similar.
Comment on attachment 464747 [details] [diff] [review]
Part 1: Fix nsDOMParser to make it useful from xpcshell tests

> +    // If we have the system principal, then we'll just use the null principals

"principal's"

r=me
Attachment #464747 - Flags: review?(bzbarsky) → review+
(In reply to comment #96)

> +      if (/^about:/.test(aBrowser.contentWindow.document.documentURI)) {
> 
> Don't you have an nsIURI here, e.g. from aBrowser or from aRequest (see a few
> lines up)? 

aBrowser.contentWindow.document.documentURIObject?
(In reply to comment #96)
> Note sure if that's a problem, but I'd only removeEventListener() when there's
> actually a listener. (That's a very common case, for every normal page load.)

Removing the listener when there is none isn't a problem. I guess we could keep track of when a listener was registered and when it wasn't, but that seems like introducing needless complexity in the code.

> NIT: I'd rename BrowserOnCommand() to reflect that it's only about error pages
> e.g. ErrorPageOnButtonPressed() or similar.

Can do.

> > +      if (/^about:/.test(aBrowser.contentWindow.document.documentURI)) {
> > 
> > Don't you have an nsIURI here, e.g. from aBrowser or from aRequest (see a
> > few lines up)? 
> 
> aBrowser.contentWindow.document.documentURIObject?

I could use this, but I wanted to keep the test similar to the tests in BrowserOnCommand.
Comment on attachment 465072 [details] [diff] [review]
Part 3: Don't use XUL for buttons in error pages

>--- a/browser/base/content/aboutRobots.xhtml
>+++ b/browser/base/content/aboutRobots.xhtml

>-      <xul:button xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>-                  id="errorTryAgain"
>-                  label="&retry.label;"
>-                  label2="&robots.dontpress;"
>-                  oncommand="robotButton();" />
>+      <button id="errorTryAgain"
>+              label=""
>+              label2="&robots.dontpress;"
>+              onclick="robotButton();">&retry.label;</button>

drop label=""?

>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js

>+    // Attach a listener to watch for "click" events bubbling up from error
>+    // pages.  This lets us fix bugs like 401575 which require error page UI to
>+    // do privileged things, without letting error pages have any privilege
>+    // themselves.
>+    // We can't look for this during onLocationChange since at that point the
>+    // document URI is not yet the about:-uri of the error page.
>+    if (aStateFlags & Ci.nsIWebProgressListener.STATE_STOP) {
>+      if (/^about:/.test(aBrowser.contentWindow.document.documentURI)) {
>+        aBrowser.addEventListener("click", BrowserOnCommand, false);
>+      }
>+      else {
>+        aBrowser.removeEventListener("click", BrowserOnCommand, false);
>+      }
>+    }

This is going to wrongly be inside of #ifdef MOZ_CRASHREPORTER on mozilla-central tip. (Looks like your tree is outdated.)

As far as not needlessly calling removeEventListener for every load is concerned, maybe this will work for you:

if (aStateFlags & Ci.nsIWebProgressListener.STATE_STOP &&
    /^about:/.test(aBrowser.contentWindow.document.documentURI)) {
  aBrowser.addEventListener("click", BrowserOnCommand, false);
  aBrowser.addEventListener("pagehide", function () {
    aBrowser.removeEventListener("click", BrowserOnCommand, false);
    aBrowser.removeEventListener("pagehide", arguments.callee, true);
  }, true);
}

I agree that that we should rename BrowserOnCommand. Maybe also make it return early there if the target isn't a button.

>--- a/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml
>+++ b/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml

>-          <button xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>-                  id="startPrivateBrowsing" label="&privatebrowsingpage.startPrivateBrowsing.label;"
>-                  accesskey="&privatebrowsingpage.startPrivateBrowsing.accesskey;"/>
>+          <button id="startPrivateBrowsing"
>+                  accesskey="&privatebrowsingpage.startPrivateBrowsing.accesskey;">&privatebrowsingpage.startPrivateBrowsing.label;</button>

This causes the accesskey to not be underlined anymore, although it still works.

Is this change necessary at all? about:privatebrowsing should be privileged.

>--- a/browser/locales/en-US/chrome/overrides/netError.dtd
>+++ b/browser/locales/en-US/chrome/overrides/netError.dtd
>@@ -173,11 +173,11 @@ be temporary, and you can try again late
> <!-- LOCALIZATION NOTE (securityOverride.warningText) - Do not translate the
> contents of the <xul:button> tags.  The only language content is the label= field,
> which uses strings already defined above. The button is included here (instead of
> netError.xhtml) because it exposes functionality specific to firefox. -->
> 
> <!ENTITY securityOverride.warningText "
> <p>You should not add an exception if you are using an internet connection that you do not trust completely or if you are not used to seeing a warning for this server.</p>
> 
>-<xul:button xmlns:xul='http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul' id='getMeOutOfHereButton' label='&securityOverride.getMeOutOfHereButton;'/>
>-<xul:button xmlns:xul='http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul' id='exceptionDialogButton' label='&securityOverride.exceptionButtonLabel;'/>
>+<button id='getMeOutOfHereButton'>&securityOverride.getMeOutOfHereButton;</button>
>+<button id='exceptionDialogButton'>&securityOverride.exceptionButtonLabel;</button>
> ">

Needs new entity name and an updated localization note.
Attachment #465072 - Flags: review?(dao) → review+
Given that this is somewhat risky, and still lacking reviews, I'm going to push this to beta5.
blocking2.0: beta4+ → beta5+
Comment on attachment 464764 [details] [diff] [review]
Part 6: Disable XUL for pages, unless user specifically opts in for domain.

- In NS_NewXULElement():

+    nsIDocument* doc = aNodeInfo->GetDocument();
+    if (!(!doc || doc->AllowXULXBL())) {
+        printf("blocking XUL\n");
+    }

Remove the printf.

- In MayUseXULXBL():

+  PRBool allow = nsContentUtils::IsSitePermAllow(uri, "allowXULXBL");
+  if (!allow) {
+    nsCOMPtr<nsIURI> curi;
+    aChannel->GetURI(getter_AddRefs(curi));
+    nsCString spec;
+    if (curi) {
+      curi->GetSpec(spec);
+    }
+    printf("blocking xulxbl in dlf\n");

Remove the printf.

r=jst with that!
Attachment #464764 - Flags: review?(jst) → review+
one suggestion for folks concerned about their intranet apps not working in future releases of FF(4) is to roll out Mozilla Prism as the client instead. the standalone version of Prism uses xulrunner instead of FF. The plugin version of Prism uses FF by default but it is very simple to point it to the xulrunner runtime instead. With all the web apps I have built I avoided using FF for this same reason(concern that changes in FF would break my apps). It may not be feasible in cases where you need the user to have the full browser experience but in most cases Prism/Xulrunner should work fine.
I have been trying to convert a XUL listbox to HTML5, what a F nightmare!!!!

I have been using http://stackoverflow.com/questions/130564/i-need-my-html-tables-body-to-scroll-and-its-head-to-stay-put as my reference. Some you have to add JavaScript, some are over 200 lines of just css. No wonder the "web applications" on the internet user experience sucks.

All of them do not include resizeable columns, or any list item management code!
BLOAT

Maybe I am looking in the wrong places( any help ?)

Your's
Very frustrated and **** off!
Comment on attachment 464760 [details] [diff] [review]
Part 5: Add a default permissions.sqlite to unit test profiles

I'm not opposed to this in principle, but I have two big problems with it:
1) You need to provide steps (or preferably a Python script or something) to regenerate this database, since we'll inevitably need to make changes to it.
2) If someone adds a new domain to server-locations.txt, then it won't be in this database, so XUL tests there will fail. (Also, presumably we'll want to be able to write a test that shows that a domain that's not allowed to load XUL cannot do so, so it'd be nice to have a testing domain that's reserved for that.)

Perhaps you could solve both of these by generating the file on the fly in the harness? I'd guess the reftest one is simpler because it only loads from file:// or one specific HTTP server. (Although when we run tests on mobile devices, that could be something other than localhost.)
Attachment #464760 - Flags: review?(ted.mielczarek) → review-
No longer blocks: 550959
Depends on: 550959
Attached patch Part 4: Fix feed reader (obsolete) — Splinter Review
The previous 'part 4' patch was the wrong patch. This is the correct one.
Attachment #467450 - Flags: review?(mano)
Comment on attachment 467175 [details] [diff] [review]
Part 5: Add a default permissions.sqlite to unit test profiles

Looks good, just one comment.

>diff --git a/build/automation.py.in b/build/automation.py.in
>--- a/build/automation.py.in
>+++ b/build/automation.py.in
 
>+  def setupPermissionsDatabase(self, profileDir, permissions):
>+    # Open database and create table
>+    permDB = sqlite3.connect(os.path.join(profileDir, "permissions.sqlite"))
>+    cursor = permDB.cursor();
>+    cursor.execute("""CREATE TABLE moz_hosts (
>+       id INTEGER PRIMARY KEY,
>+       host TEXT,
>+       type TEXT,
>+       permission INTEGER,
>+       expireType INTEGER,
>+       expireTime INTEGER)""")

Presumably this same schema is defined somewhere in the codebase? Could you add a comment indicating where that lives? (And for bonus points, a comment in the source indicating that if that changes, this should be changed as well.)

r=me with that change.
Attachment #467175 - Flags: review?(ted.mielczarek) → review+
Attached patch Part 4: Fix feed reader (obsolete) — Splinter Review
Fix some problems that mano found during review.
Attachment #467450 - Attachment is obsolete: true
Attachment #467538 - Flags: review?(mano)
Attachment #467450 - Flags: review?(mano)
Attachment #464757 - Attachment is obsolete: true
Attachment #464757 - Flags: review?(mano)
Fix more review comments
Attachment #467538 - Attachment is obsolete: true
Attachment #467560 - Flags: review?(mano)
Attachment #467538 - Flags: review?(mano)
Comment on attachment 467560 [details] [diff] [review]
Part 4: Fix feed reader

>--- /dev/null
>+++ b/browser/themes/*/browser/feeds/subscribe-ui.css

>+.handlersMenuList > menupopup > menuitem {

1. These rules could be simplified to select on .handlersMenuPopup.

>diff --git a/browser/components/feeds/content/subscribe.xml b/browser/components/feeds/content/subscribe.xml
>new file mode 100644
>--- /dev/null
>+++ b/browser/components/feeds/content/subscribe.xml
>@@ -0,0 +1,39 @@
>+<?xml version="1.0" encoding="utf-8"?>
>+<!DOCTYPE bindings [
>+  <!ENTITY % globalDTD
>+    SYSTEM "chrome://global/locale/global.dtd">
>+  %globalDTD;

2. This dtd isn't used.

3. Please add license blocks to all new files.

r=mano otherwise.
Attachment #467560 - Flags: review?(mano) → review+
Ugh, -moz-locale-dir("rtl") should be :-moz-locale-dir(rtl).
I'm not really sure how many localizers will catch this change of content without change of keyname :-\
http://hg.mozilla.org/mozilla-central/diff/61fd19a4587f/browser/locales/en-US/chrome/overrides/netError.dtd
(In reply to comment #114)
> I'm not really sure how many localizers will catch this change of content
> without change of keyname :-\
> http://hg.mozilla.org/mozilla-central/diff/61fd19a4587f/browser/locales/en-US/chrome/overrides/netError.dtd

The entity needs a new name, as noted in comment 101.
Ah, this landed already. Jonas, the r+ was conditional on the comments being addressed...
 Sorry, meant to ask about that. Why do localizers need to care? The entities have the same meaning and value as they did before. It's still button labels.
Comment on attachment 465072 [details] [diff] [review]
Part 3: Don't use XUL for buttons in error pages

<...>
>diff --git a/browser/locales/en-US/chrome/overrides/netError.dtd b/browser/locales/en-US/chrome/overrides/netError.dtd
>--- a/browser/locales/en-US/chrome/overrides/netError.dtd
>+++ b/browser/locales/en-US/chrome/overrides/netError.dtd
>@@ -173,11 +173,11 @@ be temporary, and you can try again late
> <!-- LOCALIZATION NOTE (securityOverride.warningText) - Do not translate the
> contents of the <xul:button> tags.  The only language content is the label= field,
> which uses strings already defined above. The button is included here (instead of
> netError.xhtml) because it exposes functionality specific to firefox. -->
> 
> <!ENTITY securityOverride.warningText "
> <p>You should not add an exception if you are using an internet connection that you do not trust completely or if you are not used to seeing a warning for this server.</p>
> 
>-<xul:button xmlns:xul='http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul' id='getMeOutOfHereButton' label='&securityOverride.getMeOutOfHereButton;'/>
>-<xul:button xmlns:xul='http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul' id='exceptionDialogButton' label='&securityOverride.exceptionButtonLabel;'/>
>+<button id='getMeOutOfHereButton'>&securityOverride.getMeOutOfHereButton;</button>
>+<button id='exceptionDialogButton'>&securityOverride.exceptionButtonLabel;</button>
> ">

This change needs to be called out to the localizers, otherwise they'll all continue to use xul buttons, which won't work anymore?
(In reply to comment #117)
>  Sorry, meant to ask about that. Why do localizers need to care? The entities
> have the same meaning and value as they did before. It's still button labels.

Because not all localization tools are able to catch a change in the en-US content, while they always catch a new key (also compare-locales fails, because there's an untranslated string, giving an additional warning), which means they'll keep using xul buttons (and that explains Axel's question in comment #118)
Doesn't the localization just put the button *label* in the DTD? The button is already in the markup.
Pike explained things to me. I'll write a followup patch.
So, remind me again, why are error pages so unsafe that they can't use XUL?
also:

> >--- a/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml
> >+++ b/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml
> 
> >-          <button xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
> >-                  id="startPrivateBrowsing" label="&privatebrowsingpage.startPrivateBrowsing.label;"
> >-                  accesskey="&privatebrowsingpage.startPrivateBrowsing.accesskey;"/>
> >+          <button id="startPrivateBrowsing"
> >+                  accesskey="&privatebrowsingpage.startPrivateBrowsing.accesskey;">&privatebrowsingpage.startPrivateBrowsing.label;</button>
> 
> This causes the accesskey to not be underlined anymore, although it still
> works.
> 
> Is this change necessary at all? about:privatebrowsing should be privileged.
(In reply to comment #122)
> So, remind me again, why are error pages so unsafe that they can't use XUL?

Because they are same-origin with content pages, which means that a content page can reach in to the error page and get to the XUL element. This would expose a lot of the attack surface we're trying to remove.

(In reply to comment #123)
> also:
> 
> > >--- a/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml
> > >+++ b/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml
> > 
> > >-          <button xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
> > >-                  id="startPrivateBrowsing" label="&privatebrowsingpage.startPrivateBrowsing.label;"
> > >-                  accesskey="&privatebrowsingpage.startPrivateBrowsing.accesskey;"/>
> > >+          <button id="startPrivateBrowsing"
> > >+                  accesskey="&privatebrowsingpage.startPrivateBrowsing.accesskey;">&privatebrowsingpage.startPrivateBrowsing.label;</button>
> > 
> > This causes the accesskey to not be underlined anymore, although it still
> > works.
> > 
> > Is this change necessary at all? about:privatebrowsing should be privileged.

I can revert this page, but that means listening to both click and command events from browser.js. Is that preferred?
aboutPrivateBrowsing.xhtml already accesses the chrome window, so browser.js shouldn't have to listen for the command or click event in the first place...
Attachment #467825 - Flags: review? → review?(dao)
Comment on attachment 467825 [details] [diff] [review]
Part 4b: Fixes for part 4

> <!-- LOCALIZATION NOTE (securityOverride.warningText) - Do not translate the

s/warningText/warningContent/
Attachment #467825 - Flags: review?(dao) → review+
(In reply to comment #124)
> (In reply to comment #122)
> > So, remind me again, why are error pages so unsafe that they can't use XUL?
> Because they are same-origin with content pages, which means that a content
> page can reach in to the error page and get to the XUL element.
So comment #5 is wrong?
Hrm, the changed error pages look really ugly in non-system themes, as suddenly there's a system-native button in the middle of a custom-themed UI. :(
http://forums.mozillazine.org/viewtopic.php?p=9787499#p9787499
is caused by this bug ?
if so, regression or intended ?
Depends on: 589543
Comment on attachment 465072 [details] [diff] [review]
Part 3: Don't use XUL for buttons in error pages

In addition to comment #132, note that XUL buttons default to inheriting the message-box font while HTML buttons default to something called a -moz-button.
So do you guy to kill the Bugzilla Sidebar? That's awesome.
https://bugzilla.mozilla.org/sidebar.cgi
Killing remote XUL will hurt (real, non-Intranet) sites which (ab-)use the <xul:description> element to mimic the behavior of the text-overflow: ellipsis CSS property which is not currently supported by Gecko (bug 312156). 

xul:description is widely (e.g. http://tinyurl.com/3xx3jrz) suggested as a workaround.
(In reply to comment #136)
> So do you guy to kill the Bugzilla Sidebar? That's awesome.
> https://bugzilla.mozilla.org/sidebar.cgi

I filed bug 589860 in order to port sidebar.cgi to HTML.
Once this lands http://ted.mielczarek.org/code/mozilla/xuledit/xuledit.xul won't work anymore will it?
There's a copy of that crappy tool in the Extension Developer's Extension if you really want it.
Comment on attachment 469130 [details] [diff] [review]
Part 7: Fix XHR to allow loading XUL content when initialized with system principal

This patch fixes Fennec's opening of prompt dialogs
tracking-fennec: --- → 2.0b1+
Comment on attachment 469130 [details] [diff] [review]
Part 7: Fix XHR to allow loading XUL content when initialized with system principal

Got r=jst over irl
Attachment #469130 - Flags: review+
Part 6 landed last night, and part 7 landed today:

http://hg.mozilla.org/mozilla-central/rev/cec16a1741fb
http://hg.mozilla.org/mozilla-central/rev/5070ab3714fe

So marking this FIXED!!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b5
Blocks: 590725
So, using a build with all the latest patches:

* Attempting to load a remote XUL document asserts and fails to load anything (in particular <iframe src="remote.xul"> results in a frame that doesn't even properly load a blank document).
ASSERTION: DoContent returned no listener?: 'abort || m_targetStreamListener', file uriloader/base/nsURILoader.cpp, line 776
ASSERTION: OnDataAvailable implementation consumed no data: 'Error', file netwerk/base/src/nsInputStreamPump.cpp, line 531

* Attempting to load a remote XHTML document with XUL elements asserts and generates an XML parsing error.
ASSERTION: Wrong element being closed: 'content->NodeInfo()->Equals(debugTagAtom, debugNameSpaceID)', file content/xml/document/src/nsXMLContentSink.cpp, line 1130

Is this intentional?
It's unfortunate that we assert of course. Could you file a separate bug and I'll look into it.

I did want to cut things off very strictly though. I didn't want to allow creating elements in the XUL namespace, even if we didn't instantiate nsXULElements. I'm concerned that CSS and frontend javascript code only looks at the namespace (we do that quite a bit in the DOM code).
Do/should the changes in this bug also affect loading XUL documents from file:///?
They do and IMO should. Due to the ease of saving web pages we have a policy of not trusting documents loaded from file:// any more than those loaded from http://
The DoContent thing may be a docshell bug due to failing to propagate error nsresults....  Please do file a bug on that?  And the XHTML thing definitely needs to be fixed.
Depends on: 590812
Depends on: 590842
What's the recommended way for getting XUL documents from bugzilla.mozilla.org and developer.mozilla.org displayed?
Why are there any on the latter?

For the former you could add it to your whitelist...
(In reply to comment #153)
> Why are there any on the latter?

https://developer.mozilla.org/en/XUL_Tutorial, e.g. https://developer.mozilla.org/samples/xultu/examples/ex_menuscroll_1.xul

> For the former you could add it to your whitelist...

How? Writing an extension to do so?
> How? Writing an extension to do so?

Hmm...  Whatever it takes to get stuff into the permission manager?  Not sure what's involved in that.
(In reply to comment #155)
> > How? Writing an extension to do so?
> 
> Hmm...  Whatever it takes to get stuff into the permission manager?  Not sure
> what's involved in that.

I think sayrer has a SpecialPowers add-on for replaing enablePrivilege.

/be
(In reply to comment #148)
> I did want to cut things off very strictly though. I didn't want to allow
> creating elements in the XUL namespace, even if we didn't instantiate
> nsXULElements. I'm concerned that CSS
Oh, so now CSS is unsafe too?

> and frontend javascript code only looks at the namespace
File a bug on switching to instanceof XULElement?

> (we do that quite a bit in the DOM code).
Why not switch IsInNamespace(kNameSpaceID_XUL) to IsNodeOfType(eXUL)?
Blocks: 590870
xul.css is full of -moz-binding, which web pages aren't allowed to use.  For example:

button {
  -moz-binding: url("chrome://global/content/bindings/button.xml#button");
}

Preventing web pages from creating elements in the XUL namespace seems like an insane way to prevent that rule (or at least the binding part) from applying.
(In reply to comment #158)
> Preventing web pages from creating elements in the XUL namespace seems like an
> insane way to prevent that rule (or at least the binding part) from applying.

Yeah, the behavior arising from this way of disabling XUL is really weird. I'd expect attempts to load application/vnd.mozilla.xul+xml into a browsing context to show a message page similar to the "Server not found", etc., messages saying that remote XUL from random servers is no longer supported. I'd expect attempts to create elements in the XUL namespace (via parser or via DOM) to behave like such attempts would behave in a browser that doesn't treat the XUL namespace as special (like Safari or Opera).
No longer blocks: 590870
Depends on: 590870
> Why not switch IsInNamespace(kNameSpaceID_XUL) to IsNodeOfType(eXUL)?

Because the latter is much slower?
Depends on: 590990
We could allow elements in the XUL namespace to be instantiated, re-introduce IsNodeOfType(eXUL), add hacks to the style system to prevent adding bindings to xul-namespaced-non-xul-elements, do a global search'n'replace for anyone using kNameSpaceID_XUL or "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" and embark on a never-ending hunt for people using the wrong way to check for XUL elements.

But why? What is the advantage to users and web developers?

The whole point of this bug is to get rid of the whack-a-mole'ing.
In our local XULRunner application I wanted to load a local XUL file using the file protocol. After this patch landed this is no longer possible which is more than irritating and I don't understand why a local XUL file in my local application could be harmfull. I filed bug 590990 where bz pointed me to this bug.

Actually this is a really big change for *A LOT* of applications which either use XULRunner or simply Firefox as a basis for their applications. And it's really frustrating as it breaks a lot of work. So this needs to be documented and communicated very soon and it should be documented how to use the whitelist and workaround this restriction.

Using prism as suggested in comment 104 doesn't seem to be a solution as XULRunner is using the same code basis. I would be happy to be able to completely disable this for a specific XULRunner application without the need to hack the code and create my own build.

Anyway - just for "defrustrating" - please provide some information how to use the whitelist and add files to it by code.

eg:
if (notInWhitelist(file))
  addFileToWhitelist(file)
loadFile(file)

And it would be much easier to simply say "enable file:// protocoll".
Daniel,
If you trust your local (file:) XUL files, why not put them in chrome://, i.e. register a chrome: or resource: URL for the local directory?
If you do not trust the XUL files, they shouldn't be loaded anymore, not even as exception, because we'll have security holes that allows these files to get system access and we can't fix them (that's the reason for this change).
(In reply to comment #161)
> But why? What is the advantage to users and web developers?

The YSoD claiming an XML parse error without any explanation is bad UX compared to a message saying that XUL is no longer supported.

As for being able to have unprivileged DOMs with XUL-namespace nodes, a potential use case would be someone with legacy XUL creating an emulation layer that loads existing XUL files via XHR and then renders them using HTML/CSS/DOM. (I don't know how realistic this use case is. Maybe it's not worth supporting.)
Why not do what Firefox does for most (all?) files that it doesn't support rendering: offer to download the file?

The current behaviour is very odd and looks like the browser is broken.
(In reply to comment #164)
> As for being able to have unprivileged DOMs with XUL-namespace nodes, a
> potential use case would be someone with legacy XUL creating an emulation layer
> that loads existing XUL files via XHR and then renders them using HTML/CSS/DOM.
> (I don't know how realistic this use case is. Maybe it's not worth supporting.)

I'm not sure about realistic but that's one of the approaches we were planning to try, at least for the initial stages of our migration away from remote XUL.
(In reply to comment #163)
> If you trust your local (file:) XUL files, why not put them in chrome://, i.e.
> register a chrome: or resource: URL for the local directory?

I trust them as my application generated them. The files are created as part of each project created with our application. So each project contains several generated XUL files. They are not part of any chrome or resource but are simply where the user saved them to. (Can I register such local files dynamically without using a manifest and use it right away?)

The bug here is about remote XUL but finally local XUL is now prevented too.

The really irritating thing is, that it works again in my case if I simply rename the extension from .xul to .xml. The content is still XUL. I don't understand this behaviour and it looks like a new bug to me.

(See the original bug 590990 for more details)
> The bug here is about remote XUL but finally local XUL is now prevented too.

We treat them the same. See comment 150.
See also comment 73.

I don't think your customer would be happy if loading one of your files from a CD would result in takeover of the machine, would they?

> it works again in my case if I simply rename the extension from .xul to .xml.
> The content is still XUL.

Urgs, that sounds like a bug. sicking, bz?
(In reply to comment #168)
> I don't think your customer would be happy if loading one of your files from a
> CD would result in takeover of the machine, would they?

I'm talking about applications based on XULRunner which are also affected by this change. With a local XULRunner application the situation is completely different. I as a vendor are responsible for problems - including and especially security related problems. However I am now (and nearly every day) forced to spend a lot of time fixing bugs resulting of changes for a browser specific problem which has nothing to do with my application. It's getting more and more difficult to use the really cool platform as a basis for applications because of all that security stuff that is relevant to the browser but not to me.

It might be a good idea to have these features for XULRunner as well as there might be projects who need to care about that. But I really wish for a "switch security stuff off" pref or manifest directive. Not for the browser, but for XULRunner. This would save me A LOT of work and nerves.

Sorry to spam the bug here. Maybe we should discuss that in a newsgroup.
> Urgs, that sounds like a bug. sicking, bz?

The content in question is not XUL.  It's some XML that loads a chrome stylesheet via an xml-stylesheet PI and has all its nodes in the "http://www.birgin.de/ida/there.is.only.ida" namespace.  See bug 590990 comment 4 for the full content involved.

A newsgroup discussion on XULRunner apps using local XUL files and how to make this relatively painless, if it's safe, seems like a good idea.  And we definitely need to document how the whitelist can be edited.
I opened a discussion "XULRunner app using local XUL file and handling security issues in general" in the mozilla.dev.tech.xul group.

msg id: AYudnQWFWclnbOrRnZ2dnUVZ_gidnZ2d@mozilla.org
Depends on: 591401
Depends on: 591198
(In reply to comment #155)
> > How? Writing an extension to do so?
> 
> Hmm...  Whatever it takes to get stuff into the permission manager?  Not sure
> what's involved in that.

So there is currently no way to get xul/xbl working again for certain sites?
Depends on: 592693
Depends on: 592829
This test script adds <file> in the permissions.sqlite database, when clicking on the first button. I had to add a notifyObservers hack to get Firefox to notice the added pref, instantly. However, I didn't manage to get it noticed instantly when removing the pref. Only restarting helps here.

But adding this <file> pref should be possible with the permissionmanager, which it currently not is. See bug 204285.
Depends on: 592952
> We could allow elements in the XUL namespace to be instantiated, re-introduce
> IsNodeOfType(eXUL)

Fwiw, that's the SVG situation: not all SVG-namespace elements are nsSVGElement.

The style system issue is the biggest problem with this approach...

> But why? What is the advantage to users and web developers?

Ability to keep parsing random XML that may happen to have XUL-namespaced things in it.
(In reply to comment #174)
> > But why? What is the advantage to users and web developers?
> 
> Ability to keep parsing random XML that may happen to have XUL-namespaced
> things in it.

I think we should consider this -- it could be important. It would give users a cheaper way forward than rewriting if they could use JS to make something happen with the XUL-namespaced stuff. This is the way of the web.

/be
Note that allowing elements in the XUL namespace to be instantiated is a *significant* amount of work. We would have to change the code at all these locations:

http://mxr.mozilla.org/mozilla-central/search?string=kNameSpaceID_XUL

as well as most of these:
http://mxr.mozilla.org/mozilla-central/search?string=there.is.only&find=\.js

We'd also have to add some sort of CSS syntax to only apply XUL bindings to "real" xul elements, and not all elements in the XUL namespace.

And I'm fairly sure I'm missing other changes that needs to be made.

We'd also have to continuously monitor the code to make sure that no other places like the above sneak back in after the initial change. Static analysis of javascript would help a lot.

We can certainly do this. But I only think we should do it if it brings significant advantage to authors as it will be a significant cost to us.
The fact is, XUL and XBL are used on the web. They probably never should have been, but they are. Often the use case for XUL on the web is to work around missing features in Gecko's CSS or HTML support.

Two examples:

* bug 312156 (text-overflow: ellipsis) has been worked around for *years* with xul:description (directly in HTML, applied through JS, or using -moz-binding), now the work around makes things worse - missing content (like in Mike Shaver's bug 592693). Google Search for "xul description text-overflow ellipsis": <http://omf.gd/czp>

* lack of word-wrap: break-word (now supported since 3.5) used to be worked around with another XBL hack, as described in this blog post: <http://omf.gd/czo>. While we now support word-wrap, if the web developer applies this hack in Fx4, the content will be gone.

Personal story (TL;DR?): a few days ago I limited the ellipsis workaround in my employer's webmail app (used by a few millions of users, half of which use Firefox 3.x) to Gecko <2.0. Had I not been a Mozilla volunteer using nightlies every single day, I would probably learn about the issue the hard way, probably by being called by my boss the evening Firefox 4 is released and end users start en masse to check their email to see blank space instead of <xul:description>s with their e-mail subjects... 

So what I think should be done is:
1. identify all the use cases for XUL & XBL on the web (I guess there's more than the two I described above)
2. provide alternative means to reach (at least the most common of) these cases - by fixing the issues that are being worked around with XUL
3. be Really Loud about XUL being dropped, what it breaks and what (hopefully standards-based) alternatives are available
(In reply to comment #177)
> * bug 312156 (text-overflow: ellipsis) has been worked around for *years* with
> xul:description (directly in HTML, applied through JS, or using -moz-binding),
> now the work around makes things worse - missing content (like in Mike Shaver's
> bug 592693). Google Search for "xul description text-overflow ellipsis":
> <http://omf.gd/czp>

Perhaps that bug should be retriaged for 2.0 then, though I fear at this point it may be too late to implement anyways.
Note that the disappearing content is bug 591198, and it will get fixed in next beta. We're definitely not going to ship without that fixed.
As this deletion of a well-known feature ( http://books.google.co.nz/books?id=ryEKOKnHFa8C&lpg=PA392&ots=k3AKxyj8QL&dq=xul%20chrome%20programming%20firefox&pg=PA100#v=onepage&q&f=false ) destroys a "dark matter" intranet app that is the main tool of 900+ clients and will take more than 18 months to adapt to another technology (be it ActiveX or HTML if feasible) we'd be thankful for some official document that explains if there is a migration path to Prism or whatever. Right now the note "Support for remote XUL has long been a potential security concern; support for it was removed in Gecko 2.0." is not helpful enough.

Thanks in advance.
Francisco, does the ability to whitelist a particular hostname to allow XUL from it (which still needs to be documented) not solve your issue?  If not, why not?
It does (rather should since we're still migrating the components to the latest mercurial code), that's not the issue.

What we'd like to (officially) know, is if remote XUL will still be accessible for app development through some dedicated app based on firefox code, or this whitelist feature will be kept in the future.

When we finish this iteration of our tech platform (optimistically around year's end), we'll have to decide whether we continue development with our custom firefox-based setup or we switch technologies, which will require some careful planning and coordination of a couple dozens of employees just for the main development.

The platform has been extensively used for 5 years now and we have more than 2000 screens deployed. We're utmost interested on whether remote XUL will still be somehow supported or we should start prototyping in HTML5/ActiveX/whatever to avoid stagnation.

Thanks for your answer.
OK, just to be sure, as of FF4beta5, local XUL files will no longer load unless they are in chrome. Right?  

You guys should have posted this intention in big letters on developer.mozilla.org a while back and not left it accessible only in a bug report.  First mention anywhere (other than bugzilla) seems to be here: http://blog.mozilla.com/addons/tag/firefox-4/ as of July, 2010.

Why the griping?  Because had I known in January when I rewrote an entire application to use XUL (50,000+ lines of code, 1000+ man hours), I wouldn't have bothered.  It's going to cost me countless hours to port over to an extension which is time I don't have until next summer (if then).  I'm sorry to be so heated here, but I've been a FF user from the beginning and I'm feeling a bit burnt at the moment.
Well, all the pages on remote XUL have already been updated to note that it's no longer supported, and the fact that it's no longer supported is also documented on the "Firefox 4 for developers" page. From a documentation perspective, this has been done for a while, other than the requests that someone create a migration guide of some sort.

However, I'm not currently in a position to do it (I have no clue how to do it myself yet). If someone can contribute one, or at least notes on the topic, that would be helpful.
I'm actually moving things over now, although there is much that is broken.  I may just document the process as I go since it seems that many others are having issues and I've got to put just about everything else on hold until this is done.  In a short month, I have users who will have my head if this app won't work once they upgrade to FF4.  

In so far as documentation is concerned, when I first read "remote XUL" I thought "Ah.. XUL that is loaded remotely, not from my own file system.  This doesn't affect me or my app."  Also, as recently as July 8, 2010, your XUL tutorial front page "https://developer.mozilla.org/en/XUL_Tutorial/Introduction" implies that full XUL support will continue.  I do appreciate your efforts today to insert the note on Gecko 2.0 at the top of many pages.  Thanks.

Generally I have dealt with security issues by writing an installer (bash or batch) that creates a new profile "opentrack" and then modifies the prefs.js file to allow for the use of XPCOM components and access to UniversalBrowserRead/Write/XPCom methods and privileges.  Considering what I had to do to make this work across platforms and the number of times users were queried to give approval before the install was finalized, it seemed to me the local file system was already fairly secure (or else I'm a terrible bad-guy).  I'm sorry to see this technology get locked down so tight.  I'm afraid that many users will revert to IE and ActiveX or move to Qt or WebKit based solutions instead.
> What we'd like to (officially) know, is if remote XUL will still be accessible
> for app development through some dedicated app based on firefox code, or this
> whitelist feature will be kept in the future.

I don't think this has been decided yet.

> or we should start prototyping in HTML5/ActiveX/whatever

Prototyping in HTML5 seems like a good idea to me, for what it's worth.  It avoids you being locked into a particular browser, and early feedback on what you need that HTML5 is missing would be enormously useful.  That would make it easier to make sure those missing pieces are added.

> local XUL files will no longer load unless they are in chrome. Right?  

I believe so.  In particular, I would expect that the whitelisting thing doesn't work for local files (but worth double-checking with Jonas).

> You guys should have posted this intention in big letters

There have in fact been several announcements of this intention in the mailing lists/newsgroups over the last two years.  You're right that updating devmo with that infomation would have been a good idea too...
HTML5 layout is horrible!! HTML5 follow SGML NOT XML. This means that the XML parent child relationship for layout means nothing! you can put a child <div> anywhere out side the parent. And there is noway to to put maintain a XML child parent relationship without breaking "inline flow".

I have started to port my XUL apps to HTML5. The development time has tripled because HML5 layout is so bad.  There is no box model in layout! Now I know why today's browsers  are so bloated and soo full of bugs, HTML layout is not orthogonal!

To describe Visual Formating of CSS 2.1 takes 2 chapters, 45 pages, 1386 paragraphs, and 18295 words. http://www.w3.org/TR/CSS21/ chapters 9 & 10.

Instead of using DTD's for international web application in XUL, every language now requires a new page or have some server side search and replacement.  

Conclusion:  Start coding to HTML5 and lose so much, but it is the only thing that will be supported.

"HTML5/CSS is like Latin, it does not matter the order, just to words need to be correct"  
"HTML5 est amo latin. is does non res ordo , iustus ut lacuna postulo futurus rectus"
(In reply to comment #186)
> > What we'd like to (officially) know, is if remote XUL will still be accessible
> > for app development through some dedicated app based on firefox code, or this
> > whitelist feature will be kept in the future.
> 
> I don't think this has been decided yet.
> 
> > or we should start prototyping in HTML5/ActiveX/whatever
> 
> Prototyping in HTML5 seems like a good idea to me, for what it's worth.  It
> avoids you being locked into a particular browser, and early feedback on what
> you need that HTML5 is missing would be enormously useful.  That would make it
> easier to make sure those missing pieces are added.
> 
> > local XUL files will no longer load unless they are in chrome. Right?  
> 
> I believe so.  In particular, I would expect that the whitelisting thing
> doesn't work for local files (but worth double-checking with Jonas).

It does work for local files, that is what the https://bug546857.bugzilla.mozilla.org/attachment.cgi?id=464750 patch was about.
And that's what I added in the https://bugzilla.mozilla.org/attachment.cgi?id=471268 testcase, to show that it is possible (but because of bug 204285 unnecessarily difficult).
OK...security is important and I wouldn't just to say like "Stop breaking our product!" thing, and we'd consider to stay away from this good old technology.

Lotus iNotes utilizes XUL elements embedded in HTML page from Mozilla 1.0 era to accomplish richer UI (eg. Explorer-like list view for attachments) without creating external component like plugins.

Staying away from XUL and developing in alternative way cannot be done soon, and for our customers using current version of iNotes all of a sudden it stop working when Firefox is updated to 4.0 (possibly it would be suggested to install with a dialog, right?)

So the whitelist should be very, VERY important. Haven't there be any actual plan to implement it? Hopefully it is done through a warning dialog (or a bar at the top of the page) and add an exception for the site when user allows. It is painful for customers to let their hundreds of end users to add the site manually...

Given you are going to drop enablePrivilege as well, the similar thing would occur for signed script which we use in conjunction with XUL to implement file select/save dialog.
I don't believe there are plans to implement in-browser UI for the whitelist at this point.
(In reply to comment #190)

Thanks...so what kind of implementation is planned now...or where to know it?
(In reply to comment #188)
> (In reply to comment #186)
> > > What we'd like to (officially) know, is if remote XUL will still be accessible
> > > for app development through some dedicated app based on firefox code, or this
> > > whitelist feature will be kept in the future.
> > 
> > I don't think this has been decided yet.

Well, thankfully we build a custom version of firefox so we aren't affected on unplanned changes coming from the Mozilla project. Still, we already started adapting to FF 4's codebase, so we'll keep on that using the whitelist.

The thing is, this remote XUL change leaves in the gutter the planning of our platform for years to come, from UI design tools to server infrastructure.

We'd REALLY appreciate some longer-term planning on this issue, even if it's total annihilation of XUL. At least to have something to say when the MS/Oracle/random corp. drones come visit our CEOs to sell them on some inferior and pricy technology.

> > or we should start prototyping in HTML5/ActiveX/whatever
> 
> Prototyping in HTML5 seems like a good idea to me, for what it's worth.  It
> avoids you being locked into a particular browser, and early feedback on what
> you need that HTML5 is missing would be enormously useful.  That would make it
> easier to make sure those missing pieces are added.

Migration to HTML5 means maintaining our next FF4 codebase in production for a long time while new systems are used to test the change. Just the allocation of resources for that can't be done on a whim, it will slow the pace of development on many projects for a long while around here.

Hence why we'd like to know what's the plan for remote XUL before getting into a mess that will start with heated meetings with CTOs that don't like their delivering being delayed by other departments.
(In reply to comment #192)
> We'd REALLY appreciate some longer-term planning on this issue, even if it's
> total annihilation of XUL. At least to have something to say when the
> MS/Oracle/random corp. drones come visit our CEOs to sell them on some inferior
> and pricy technology.

Of the XUL alternatives mentioned in the comments of this bug, HTML5 is the only one that isn't a single-sourced platform and that is coupled with strong incentives for vendors to support existing content, so moving to HTML5 makes the most sense if you want to avoid disruptions arising from the priorities of the platform vendor changing.

(In reply to comment #187)
> HTML5 layout is horrible!! 

Other than having to unsink your current sunk cost in XUL development, the main current drawback of HTML5 is that the so far standardized parts of CSS are document-oriented rather than app UI-oriented. However, this is being fixed:
http://www.w3.org/TR/css3-flexbox/

It'll be a while before CSS3 Flexbox is available in browsers without vendor prefixes, tough. Gecko supports an earlier formulation of Flexbox with -moz- prefixes. However, vendor-prefixed CSS properties and values are subject to change or go away, so if you want stability, it doesn't really make sense to rely on vendor-prefixed CSS.

> HTML5 follow SGML NOT XML.

That's not true. The HTML5 text/html syntax is neither SGML nor XML though it looks similar to both.

> This means that the XML
> parent child relationship for layout means nothing! you can put a child <div>
> anywhere out side the parent.

You can't put a <div> inside a <p>, but you can nest most non-<p> elements (including <div>) just like you'd nest XML elements.

> Instead of using DTD's for international web application in XUL, every language
> now requires a new page or have some server side search and replacement.  

The easiest way to do DTD-based localization with HTML5 is to author your markup as XHTML5 and use entity references to localized strings in the XHTML5 markup. Then when a browser request a document, parse the XHTML5 markup on the server side with an XML parser that resolves the entities on the server-side, feed the output of the XML parser to an HTML5 serializer and send the serializer output as HTML5 to the browser. This is quite doable in a Java servlet, for example. If you are using Java, you can get an HTML5 serializer that you can connect to an XML parser as part of the Validator.nu HTML Parser package: http://about.validator.nu/htmlparser/

Also, client-side DTD-based localization hasn't worked for *remote* XUL in previous versions of Firefox anyway.

(I would advise against betting on Gecko introducing support for DTD-based localization for *remote* XML content in the future. We'll likely move parsing of remote XML content off the main thread and due to architectural limitations in the XML parser Gecko uses and the networking library Gecko uses, supporting external DTDs off-the-main-thread would be very inconvenient.)
> Thanks...so what kind of implementation is planned now...or where to know it?

There is already an implementation landed.  It queries the permission manager; adding whitelist entries means adding permissions to the permission manager.  This can be done either via its API (using an extension) or via directly editing the sqlite database it uses using command-line sqlite tools.  We're going to document both approaches once we're sure we're giving out the right information on the latter.

For the rest, can we please take the "html5 sucks or doesn't" debate elsewhere?  This is the wrong venue for it.
For what it's worth, I've added a note to Firefox 4 for developers noting the existence of a whitelist and that docs are forthcoming. I'm coordinating with the coders behind this stuff to ensure that when we're ready to document something, docs get written promptly.
Blocks: 595260
As bz notes, we have two possibilities:

1) An extension to add permission manager entries for specific sites.
2) A commandline tool (i.e. direct use of 'sqlite3') to add an exception to the database.

What would people prefer here? One or both? The use case for the latter could be a more automated method of deployment, though presumably people could get the appropriate exception into permissions.sqlite via any number of means, and then simply deploy that file as part of the default profile. (Having a commandline tool is also somewhat fragile, since database schemas are subject to change.)

Filed bug 595260 on writing an extension. It's simple to do; if anyone would like to volunteer, that would certainly help things move along!
I think the best answer is to have both a command line tool and an extension. There are valid use cases for both. Certainly devs are going to want an extension for testing purposes, but a command line tool will be needed for installers.
Ok, so there's apparently been some confusion as to the whitelist feature.

First off, the whitelist allows you to enable XUL/XBL on a site by site basis. You can do this using the nsIPermissionManager interface using the "allowXULXBL" type and setting the permission to ALLOW_ACTION.

See
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIPermissionManager.idl

The situation is a bit trickier for file:// urls, i.e. for local files. XUL and XBL is allowed for local files if you opt in for the "allowXULXBL" type for the special domain "<file>". However this can currently not be done using the nsIPermissionManager interface, but has to be done by adding an entry to the permissions.sqlite database directly.

If this is not good enough, we can come up with some alternative solution. Possibly we could make it such that you can use nsIPermissionManager and pass in a file:// nsIURI, however I have to talk over the consequences of this with more people.


As for the long term plans for the whitelist. I don't think it will go away until we have a credible alternative. Such as a better XUL implementation which we can enable everywhere. Or support for remote chrome:// in some fashion.
Whiteboard: See comment 198 regarding whitelist
We already have an "xbl" permission type -- http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIContentPolicy.idl#107

This is a bit confusing. What's the difference between the two?
(In reply to comment #198)
> The situation is a bit trickier for file:// urls, i.e. for local files. XUL and
> XBL is allowed for local files if you opt in for the "allowXULXBL" type for the
> special domain "<file>". However this can currently not be done using the
> nsIPermissionManager interface, but has to be done by adding an entry to the
> permissions.sqlite database directly.

I attached a patch in bug 204285 that would fix this.
(In reply to comment #193)
> (In reply to comment #192)
> > We'd REALLY appreciate some longer-term planning on this issue, even if it's
> > total annihilation of XUL. At least to have something to say when the
> > MS/Oracle/random corp. drones come visit our CEOs to sell them on some inferior
> > and pricy technology.

Francisco: your point about longer-term planning is good, and this bug shows a lack of communication about our plans, if not deficiencies (being addressed now) in those plans.

We know there's a lot of "XUL Dark Matter". We use XUL in all our apps and add-ons and it's not going away. Therefore a whitelist and other relatively simple means to the end of support XUL Dark Matter should be done. They will be done.

> Of the XUL alternatives mentioned in the comments of this bug, HTML5 is the
> only one that isn't a single-sourced platform and that is coupled with strong
> incentives for vendors to support existing content, so moving to HTML5 makes
> the most sense if you want to avoid disruptions arising from the priorities of
> the platform vendor changing.

Sorry, HTML5 (even with flexbox in CSS) is no replacement for XUL in full (XBL1 and all). Rewriting XUL dark matter apps such as Le Monde's daily production system is a huge cost.

We should not sell something that isn't a replacement, as if it were, and also ignoring the switching cost.

We have good reason to disable remote-for-any-site XUL and XBL, we never should have enabled them (it was a long time ago; it seemed like a good idea; AOL had some interest, maybe, or at least some then at Netscape thought so).

But this doesn't mean we're going to break all the XUL dark matter apps without any possibility of them whitelisting their sites and continuing to use the same code our apps and add-ons use via chrome: URLs. Breaking users like that is just bad platform stewardship.

Any XUL users who can go local via chrome: installables, please do. But that too is potentially too costly. Hence the whitelist. Good to see sicking comment on this point.

/be
(In reply to comment #199)
> We already have an "xbl" permission type --
> http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIContentPolicy.idl#107
> 
> This is a bit confusing. What's the difference between the two?

I'm not sure I understand the question. Content policy load types are a totally different thing that permissions manager permission types. We never pass one to the other. One is an number and the other is string.
(In reply to comment #202)
> I'm not sure I understand the question. Content policy load types are a totally
> different thing that permissions manager permission types. We never pass one to
> the other. One is an number and the other is string.

Sure we do.
http://mxr.mozilla.org/mozilla-central/source/extensions/permissions/nsContentBlocker.cpp#64
http://mxr.mozilla.org/mozilla-central/source/extensions/permissions/nsContentBlocker.cpp#274
(In reply to comment #198)
> has to be done by adding an entry to the
> permissions.sqlite database directly.

So does that mean it could be done using SQLite Manager (if it were updated to work with current nightlies)?

https://addons.mozilla.org/en-US/firefox/addon/5817/
Yes, it could. That's probably the best short-term solution. See also bug 595260 -- https://addons.mozilla.org/en-US/firefox/addon/7385/ is another extension that is a little more user-friendly.
(In reply to comment #203)
> (In reply to comment #202)
> > I'm not sure I understand the question. Content policy load types are a totally
> > different thing that permissions manager permission types. We never pass one to
> > the other. One is an number and the other is string.
> 
> Sure we do.
> http://mxr.mozilla.org/mozilla-central/source/extensions/permissions/nsContentBlocker.cpp#64
> http://mxr.mozilla.org/mozilla-central/source/extensions/permissions/nsContentBlocker.cpp#274

Hmm.. wow. Yes, this is definitely a bit confusing.

The two types work totally opposite, with "xbl" defaulting to "allow" and "allowXULXBL" defaulting to "deny". I'm not really sure there is a use for the "xbl" type any more, and I'm not sure if there's a way to disable it. What would happen if we change the string in that file from "xbl" to "allowXBLXUL"?
(In reply to comment #206)
> The two types work totally opposite, with "xbl" defaulting to "allow" and
> "allowXULXBL" defaulting to "deny". I'm not really sure there is a use for the
> "xbl" type any more, and I'm not sure if there's a way to disable it. What
> would happen if we change the string in that file from "xbl" to "allowXBLXUL"?

I'm a bit confused as to the difference between the two. Your XUL/XBL stuff is obviously implemented in a different place to the XBL bit there. For XBL, at least, are they covering the same situation and achieving the same end, or are they slightly different?

If they're the same, then I have another question. Does it make sense to block XBL without blocking XUL, and vice versa? And if it does, do we care about supporting that case?

If we want them to mean the same thing, then we can change the string and add a TYPE_XUL to nsIContentPolicy that translates to the same string. We could possibly also migrate "xbl" permissions to the new type.
For the XBL part, they mostly block things the same way right now I think, at least for http urls. The new XBL blocking code intentionally allows through non-system-principal-chrome-urls which I saw for some reason.

Though I would expect us to add checks at a few more points in the future.

As for the XUL blocking, that can not be done with a content policy.

It does not make sense to allow XUL while blocking XBL. XUL relies heavily on XBL. The other way around could make sense (allowing XBL while blocking) on a technical level, but I don't see why anyone would want to do that.
OK. We should probably leave the "xbl" string alone then, since people might be using it -- and extensions like https://addons.mozilla.org/en-US/firefox/addon/7385/ allow editing it.
... and document what the difference is. :)
Blocks: 595397
> For the rest, can we please take the "html5 sucks or doesn't" debate elsewhere?
>  This is the wrong venue for it.

I am sorry but that was not my intention. I want to say there is not now or in the near future a replacement technology for XUL.
> The new XBL blocking code intentionally allows through
> non-system-principal-chrome-urls which I saw for some reason.

sicking, why's that? If XUL has security holes that won't be fixed, then allowing XUL is basically the same as system principal.
You wouldn't have XPCOM APIs, but need an exploit, but when lowering access rights, that's exactly the point: to prevent attacks from this origin. The code written by the author is never the problem anyway.
So, given that the purpose of this exercise is to plug security holes in XUL, then all XUL from untrusted sources must be blocked.

XUL devs: Without wanting to stir up emotions, just stating facts (to my understanding): That means that anything in the above mentioned whitelist also has full system access to all clients. Anybody adding things to the whitelist should be aware of that. Never add http sites, as they can be intercepted trivially, even without sitting between server and client, e.g. via DNS poisoning. And even if you add https sites, these servers will be able to remotely control all clients - are you sure that your server will never get hacked? When whitelisting file: and allowing to load XUL from files that users pass around, be aware that they have the same status as EXE files, not normal file like images. All of this (servers having full system access to clients, data files having full access) must be stated to your users, so that they can be aware of the security consequences and take care.
Depends on: 596224
Depends on: 596354
Blocks: 594459
No longer blocks: 594459
Depends on: 594459
Depends on: 600819
Depends on: 597259
Depends on: 605048
Depends on: 605087
The changes made may have introduced bug 606697 - DOMParser chokes on parsing content with XML containing XUL namespace. Please consider.
Depends on: 606697
Depends on: 610167
Depends on: 613478
You should be supporting and improving Remote XUl, not dropping it. I use Remote XUL in my web apps and came on, if I want to use Remote XUL, even knowing its securety problems, well, this decision should be mine as a developer, not from the plataform. There is no better solution for UI building than XUL. If exists, please, let me know. I have been using HTML for years for building wep apps, till I found XUL. HTML sucks for that purpose. Please, do not drop support for Remote XUl.
Please see here for why:

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/3279e68d8966da36
Whiteboard: See comment 198 regarding whitelist → See comment 198 regarding whitelist, See URL for why this bug was filed
(In reply to comment #214)
> if I want to use Remote XUL, even knowing its securety problems, well,
> this decision should be mine as a developer, not from the plataform.

But you, the developer, don't pay the costs of the security problems. Browser users who wouldn't recognize XUL if Gozer himself hand-delivered it are the ones potentially at risk, the vast majority of whom will never, ever, visit your site but instead are perfectly happy with all the popular commercial sites written in HTML and which work in every modern browser.

> I have been using HTML for years for building wep apps, till I found
> XUL. HTML sucks for that purpose.

Does it suck so much you're willing to throw away 70% of your potential audience? Or do you have the luxury of being able to mandate the use of Firefox?
Dear Daniel, 

I realize Mozilla Project pays for the costs of security problems, and for that reason I think it as a plataform maker should find ways to avoid security problems, but simply dropping direct support for remote xul should not be a option. There should exist another option.

About my audience, well, nice you touch that question. In my case, audience is closed, and yes, I am able to mandate the use of firefox, as I already do. You may wonder how, but that's the point I guess you are missing. I own three subscribed web applications running as a service, and for accessing it my clients must use firefox. The point you are missing is about that, some applications ran on intranets or extranets, where users should adopt the choosen plataform. In cases like that, the use of xul is great because its short time to setup the UI and frontend programming.

I think Mozilla Project should be enforcing the use of remote xul on web applications, since there is no better UI framework as XUL. All javascript libraries which has UI support are slow and much more time spending to program. 
XUL has a set of UI widgets and a box layout subsystem that, in my vision, is perfect for entreprise remote application. Creating a pre-configuration in order to users have access to remote xul makes no sense to me. If other browsers does not support xul, than that's a problem of them. I use Open Source, I use Firefox and XUL as a software development plataform, so I would appreciate if XUL could remain remotely accessed without any pre-configuration done by the users. I think the mainpoint here is the use of XUL for web application purposes and not for "presentation sites". By the way, if Firefox itself is made from XUL, why then should XUL be used freely inside Firefox anymore? Give up because "security problems" as they could not ever be fixed, well, this makes me less hopeful about Mozilla Project as I always was.
> There should exist another option.

There is, sure.  Everyone on the content and layout and content teams could drop every single other thing we're doing (video, html5, css improvements, everything) and spend a year trying (without guarantees of success) to make XUL safe to use on the public web.  We considered this option, and decided it wasn't tenable.  Dropping remote XUL support was in fact the least bad option here.

> why then should XUL be used freely inside Firefox anymore?

Because unlike websites, we have some control over what goes into the Firefox UI.
Guess decision is already done by Mozilla Project to drop direct access remote xul. What garantee do developers has even if remote "user pre-configuration" xul support will continue over the decade? Guess none. The fact is: There is no UI framework as xul offer. You are talking about open web, I am talking about closed web applications. Xul has lacks and missings that possibly were the cause for its low usage indeed. However, even with those lacks and missings it is great for web application programming. Well, my intention was only to try to advocate for xul. I use, I like it, my costumers like it, and I feel sad about "dark matter" label.
Miguel,

> In my case, audience is closed, and yes, I am able to mandate the use of firefox

I think in your case, the best option would be to move to a XULRunner application. Your users only need a firefox and start your app with "firefox.exe -app C:/path/to/your/app/application.ini". The xul files are local, but you can use the updater. Advantage is that it's much faster, because the files don't have to be downloaded.

You can also integrate better with the computer, but OTOH you need to be very careful about security, because simply loading a URL (coming from the network or an untrusted source) in the wrong context can cause a security hole, so be sure to read a XUL/Mozilla chrome security introduction.

For all you XUL programmers, I think that's the best option forward for now.

Or the pref to enable remote XUL, as mentioned, preferably in separate Firefox profile, started with "firefox.exe -no-remote -P <profilename>".

Everybody realizes you are in pain, and we're truely sorry for it.
strike "in the wrong context" (chrome XUL is a sharp knife!)
Thanks Ben, for your advises. However, using XULRunner is not an option in my case. My users should download the app code, unzip it into some folder, configure firefox execution path, guess is to much for dummies. Transforming my apps into an add-on is not an option too, since I use other tecnologies in my web apps other than XUL. Hence the effort to transform everything into XUL is insane. As I pointed, XUL is cool because its great UI control and simplicity, and also because you can have your XUL related code in a remote server, with better control over it, and tampered proof. Well, thanks anyway. My fear now is if Mozilla Project will maintain remote XUL even as a manually activated feature. I am really in doubt if I continue with XUL in my web apps. May in Firefox 10 you decide to drop even that manually configuration for XUL. :-(
> My users should download the app code, unzip it into some folder,
> configure firefox execution path, guess is to much for dummies.

Then make an installer with NSIS.
As said, you can update xulrunner apps, IIRC.

> Transforming my apps into an add-on is not an option too, since I
> use other tecnologies in my web apps other than XUL. Hence

I don't understand why it's possible to make it as web app, but not as add-on. An addon can do everything that a webpage can.

Anyway, even if it doesn't work for you, maybe it helps others here.

> My fear now is if Mozilla Project will maintain remote XUL even as a
> manually activated feature.

I would indeed not count on that, given that it is very insecure and leaves users at risk. It's a transitional feature only. Addons and xulrunner will probably be a better bet.
We beg you to *please* consider adding a domain to the whitelist easier than "you have to install the XUL whitelist manager" or edit the database with a command line tool (are you seriously expecting normal people to use that?).

With Firefox 4-beta a user trying to access our application is greeted with a blank page - no errors or warnings, just a blank page. The whole point is being able to access it from any computer with a Firefox browser, we can't rewrite it as an add-on or force users to install a whitelist manager every time they access it from a new computer (and believe me if we could rewrite it in plain HTML we would have done so a long time ago). 

Instead of forcing the developers to notify their users that they need to download an add-on when Firefox 4 hits [which they won't do, the average user doesn't even know what an add-on is], what's the reasoning behind not having a simple "This domain wants to run Mozilla specific UI code, click OK to allow this or Cancel to abort" dialog? It's like saying "yes" to downloading the extension and manually adding the domain to the whitelist, but done easy and in a way that will actually work for everyone?
We _could_ have a message like that.  However, what it would have say is "This domain wants to take over your computer."  In fact, it would pretty much look like the "attack page" error page.  I doubt that's what you want.
Actually, I think a message along the lines of "This page was designed for older versions of Firefox and is using technology which could be used to compromise your computer" could be much much better than "<blank page that makes users confused>".

Even if it does say "attack site", at least it gives information.  A blank page tends to lead people to think there's a server or network problem, rather than a technology one.

Otherwise, it's like just showing a blank page instead of an "attack site" message, or showing a blank page instead of "SSL connection is untrusted", etc.  It's just strange.

That said, probably wouldn't be entirely trivial to implement such a page, and not sure if the small number of XUL sites out there warrant it.

-[Unknown]
(In reply to comment #225)
> We _could_ have a message like that.  However, what it would have say is "This
> domain wants to take over your computer."  In fact, it would pretty much look
> like the "attack page" error page.  I doubt that's what you want.

bz, actually, yes, compared to a blank page leaving users and customers to at the very best email support for exact instructions on how to enable and configure a whitelist manager add-on to get their stuff working, then it's definitely a step in the right direction!

While I do appreciate your focus on security here, I can't see how being able to add the current domain to a whitelist directly from within the browser without any external add-ons would hurt anyone.

Unless it's changed in 4; with a harsh warning that someone might be trying to impersonte the server Firefox will let you "Add an exception" for invalid SSL certificates without having to bother with a "SSL certificate whitelist add-on" (arguably more severe than allowing remote XUL from a trusted domain anyway). Having something similar to allow for our customers and users to continue using our XUL based products in future versions of Firefox would ease the mind of all developers who's complained in this bug while still by default deny permission to evil XUL, if there is such a thing, hidden in iframes from suspicious domains or what have you.

Please give it some thought at least.
Well, using SSL even without knowing the third-party at least nets you encryption.  It's better than HTTP.  That argument is gaining weight lately.

Giving users a "too easy" way to whitelist a site may be a Bad Thing (TM).  But, at least providing them with an error message they can report/search for gives them options and visibility into what the problem at hand is.

Otherwise, developers/IT admins will just be confused, and probably hold back users to 3.6 saying "must be a bug in the 4.0 release, we'll wait for an update."  I'm sure this is worse for security.  We want developers/IT admins to at least know what's going on, right?  Not everyone reads newsgroups/bugzilla.

I actually think adding the UI to easily whitelist into 4.0 is both too late and too risky at this point, IMHO.  Can always be done in 4.1 or w/e.  But no visibility is just bad.  Just my half-pence.

-[Unknown]
I totally agree that just showing a blank page with no information is a no go.

There should be at least any kind of hint why the original XUL document cannot be shown and maybe a hint to some documentation or to ask the admin.

A page similar to the "untrusted certificate" page which lets me add an exception for this page/domain sounds like a good and easy solution and would be *very* helpfull.
We don't actually *want* it to be as easy to add an exception for XUL as for adding invalid certificates.

We should assume that XUL is an insecure technology and enabling it for a website gives the website the ability to hack your computer. The warning for doing that needs to be as extensive as the warning for installing addons and other software.

The current solution of requiring users to install an addon isn't great, but it accomplishes that objective.


I agree that the lack of error messages is bad. However how would we fix it? Should we show the error message as soon as a page tries to create a XUL element? That would make it impossible for pages to try to detect if XUL is supported as as soon as the page tries to detect XUL support the error message would be displayed.

Ideas welcome, though I can't promise to implement any particular solution given time constraints.
XUL is as insecure as any other web resource. Anyone can fake any web resource and force it to be downloaded by the user. This argument is weak. I am in favor of, at least, remote XUL be accessed though HTTPS. 

The truth is: You decided to discontinue remote XUL. This decision is already made. I do not know the true reason, and probably never will.
> XUL is as insecure as any other web resource.

Wrong. Obviously, you have not understood what thigs bug is about. Please read all the existing comments before making new comments. We're going in circles.
Hi Mozillian (especially BZ and Sicking),
maybe you can't understand that there are lots of XUL apps out there which will be broken in a few weeks. 
I understand that there must be a really big security issue with XBL/XUL and chrome access but you still should try to understand that for some people here, it's a big investment to change from XUL to HTML5, if it's possible at all. 
Still there are some XUL features which don't have a repaplacement in HTML5. Not to talk about XBL at all. 
So, adding a whitelist with HUGE BIG WARNINGS would be ok. But this addon thing makes things difficult without any need.
Btw: In times when everybody talks about cloud apps, removing a feature which is designed for exactly this purpose doesn't sound very smart.
Hey Hish,

You are right, howver they seem do not figure out this. I quit to show them this, indeed.
We are well aware that there are people out there using XUL and that this is a huge problem for them. Please follow the link in the url field for why we have made this decision anyway.
Following the link gives a this first paragraph: "We are, by default, disabling the ability for websites to use XUL and XBL1. We are however allowing this to be overridden on a site-by-site basis since we know there are a few websites out there that are relying on these technologies."

Then, please add an UI which allows these settings to be overwritten and do not point to an addon. How do you think deployment should work in enterprises? Asking every user to please add install the addon which can be found at http://addons.mozilla.com?

I can understand that you want to remove XUL/XBL. Doing this is not my opinion but I can understand it. But just removing a feature without offering alternatives is weak. As far as I can see we are currently missing:
- a whitelist support
- overlays 
- XBL objects
- Native OS widgets

So, I think that asking for at least a clean way how to add domains to a whitelist is not asking for too much. Of course in the long run we'll end up using HTML5 but the transformation is a very long and expensive project.

Also, you should remove this: https://developer.mozilla.org/en/using_remote_xul
We're not going to remove the "Using Remote XUL" article because it still applies to other versions of Gecko, including not only that used in the shipping version of Firefox but in other Gecko-based software. In addition, historically, we don't delete articles but mark them as obsolete once they're no longer relevant.

The "Using Remote XUL" article does however have a large note at the top saying summarizing the gist of this bug, explaining that you need to whitelist sites that you want to allow XUL from, complete with a link to the extension that adds UI for configuring this.
(In reply to comment #236)
> Then, please add an UI which allows these settings to be overwritten and do not
> point to an addon. How do you think deployment should work in enterprises?
> Asking every user to please add install the addon which can be found at
> http://addons.mozilla.com?
How do you deploy Firefox currently?  Do you ask your users to install it on their machine?  If so, I don't see how asking them to also install an add-on is much more difficult.  If not, it doesn't seem to difficult to also install the add-on when you install Firefox pre-deployment.
(In reply to comment #238)
> If not, it doesn't seem to difficult to also install the
> add-on when you install Firefox pre-deployment.
And how do I get my own domain on the whitelist of all PCs?
(In reply to comment #230)
> Ideas welcome, though I can't promise to implement any particular solution
> given time constraints.

You're right.  But, if the root node of the loaded document is in the XUL namespace, it seems like a pretty sure-fire way to detect an issue.

My suggestion would be that if a page uses a non-XUL root node, most likely it won't be entirely blank/broken when viewed, leading to some ability to diagnose the issue.

Another option would be to at least log a warning for XUL/XBL/etc. in the Web Console.

-[Unknown]
(In reply to comment #239)
> And how do I get my own domain on the whitelist of all PCs?
It shouldn't be difficult to write an add-on that does this.  You can probably even modify the existing add-on.
(In reply to comment #241)
> It shouldn't be difficult to write an add-on that does this.  You can probably
> even modify the existing add-on.
In other words: No solution exists.
Hey Hish, forget, anything you mention here they will tell you something else to impede the remote XUL support. They already decided to drop remote XUL. It is easer to drop remote XUL than find a elegant solution to a "problem". I am very disapointed to Mozilla Project about that. If even they can not figure out the coolness of remote XUL, nor you or me will show them instead. It is a shame.
(In reply to comment #230)
> We don't actually *want* it to be as easy to add an exception for XUL as for
> adding invalid certificates.

This is something I don't understand. It's not like someone will enable remote XUL support for a domain by accident just because it would be easy to do so if you want it to. I don't really see it protecting gullible users either, they would enable it on the request by a malicious host just as much as they'd accept that ActiveX control, Java applet, or whatever other technology they need to give extra permissions. 

For what it's worth, the whitelist add-on currently doesn't even want to install on the latest beta for me due to version mismatch. If Firefox 4 was to be released tomorrow we would be screwed and forced to tell our users to downgrade to 3 again, and in the future wait until the add-on is done playing catch-up with new versions of Firefox. I hope you can see how this really doesn't work out very well for us.
(In reply to comment #239)
> (In reply to comment #238)
> > If not, it doesn't seem to difficult to also install the
> > add-on when you install Firefox pre-deployment.
> And how do I get my own domain on the whitelist of all PCs?

Hi Hish, been a while. Do you really mean all PCs running Firefox 4, where ever they may be?

(In reply to comment #244)
> (In reply to comment #230)
> > We don't actually *want* it to be as easy to add an exception for XUL as for
> > adding invalid certificates.
> 
> This is something I don't understand. It's not like someone will enable remote
> XUL support for a domain by accident just because it would be easy to do so if
> you want it to.

Hish wants his domain whitelisted on all PCs. No matter how easy, this will be too hard if users individually have to do it. Therefore he wants some kind of default whitelist in Firefox. We won't do that (we don't have the time or even necessarily the ability to vet his remote XUL) so the fall-back is for him to bundle an add-on with his domain in the add-on's default whitelist.

> I don't really see it protecting gullible users either, they
> would enable it on the request by a malicious host just as much as they'd
> accept that ActiveX control, Java applet, or whatever other technology they
> need to give extra permissions.

Too right. Don't ask the user or you'll get "yes" due to over 20 years of OS and app UI security confirmation false-positives. See http://www.cs.auckland.ac.nz/~pgut001/ and search for all uses of the word "user".

> For what it's worth, the whitelist add-on currently doesn't even want to
> install on the latest beta for me due to version mismatch. If Firefox 4 was to
> be released tomorrow we would be screwed and forced to tell our users to
> downgrade to 3 again, and in the future wait until the add-on is done playing
> catch-up with new versions of Firefox. I hope you can see how this really
> doesn't work out very well for us.

I see the problem (and we are not shipping tomorrow), but would updating the add-on to work with Firefox 4 be enough?

/be
(In reply to comment #245)
> (In reply to comment #239)
> > (In reply to comment #238)
> > > If not, it doesn't seem to difficult to also install the
> > > add-on when you install Firefox pre-deployment.
> > And how do I get my own domain on the whitelist of all PCs?
> 
> Hi Hish, been a while. Do you really mean all PCs running Firefox 4, where ever
> they may be?> Hish wants his domain whitelisted on all PCs.> he wants some kind of default whitelist in Firefox

I don't think that's what he wants, actually.  He wants to be able to invoke some way to allow an exception to be added to stock Firefox installations.

Hish, what you desire can practically be achieved using add-ons, though.  (Could it be achieved with restartless add-ons, even?)

It seems you want the following experience:
1. The user visits your site.
2. Firefox notifies the user that the site is trying to use remote XUL and prompts the user to add an exception.
3. The user clicks a button and adds an exception.

How does this prohibitively differ from the approach using an add-on?
1. The user visits your site.
2. Firefox gives the stock "This site is trying to install software".
3. The user clicks "Allow".
4. The user clicks "Install".
Exactly.

> 1. The user visits your site.

1b. Your site detects (using UA string) an MSIE, Chromium etc, Gecko < 2.0 or Gecko >= 2.0. In the latter case, your site delivers a page that allows the user to either install the addon or to click on a link and go to the "low-fi" page that you use for Chromium. (If you do not have such a fallback mode, that option drops and only the addon install remains.)

> 2. Firefox gives the stock "This site is trying to install software".
Everyone, please note that discussing this here in this bug is not the right format, this should be done either in a newsgroup / mailing list thread or at least in a bug about providing some kind of notification when encountering remote XUL. The topic this bug was about has been discussed in the right (non-Bugzilla) places and implemented here. Any further discussion should take place in a real discussion area, not an issue tracker.

Also, one additional very motivating factor for this (next to the security issues that are the immediate reason) is that XUL is not a general standard done n the open by some committee but a not even internally standardized proprietary implementation without any specification (one has been tried but never followed). As Mozilla's mission is to make the web open and vendor-independent by following open, commonly agreed-to standards, allowing the web to use this proprietary technology is against what Mozilla is all about and therefore a bad idea.
I (and I think all of Mozilla) agree that HTML5/CSS3 is not yet up to doing UI as well as XUL is right now, but esp. Mozilla's representatives in the various standards committees are trying hard to incorporate a lot of features into those standards to improve the usability of the official web standards for real UI in web apps. Adding the XUL-like flexible box model into CSS3 is one example of that happening in practice.
(In reply to comment #247)
> Exactly.
> 
> > 1. The user visits your site.
> > 1b. You point your user to an add-on

1c. The add-on won't install because their browser is too new and the add-on hasn't been updated to support it yet. They're not at their own computer and can't install add-ons just like that. They don't even know what an add-on is. They install the add-on, and then what? Now they have to configure it to whitelist the domain, how? They just wanted to access their XUL based corporate webmail like they've always done, not this! There's so much that can and will go wrong this way.

What's really irking us is the fact that the whitelisting of domains is done hard not because of technical reasons but because you simply don't want it to be easy :(

By denying permission from everywhere by default you've already secured the browser, but this relying on add-ons thing isn't saving anyone while making it a complete mess for us developers and users alike.
You can point the user to an addon you wrote that whitelists your site specifically (at install, without additional interaction), and that is compatible with the latest version of the browser. Yes, that's a bigger hurdle than what currently exists, but it's already been explained here (and in the newsgroup thread linked to from here) why that trade-off was made.
(In reply to comment #245)
Hi Brendan,
long time not seen :-)
Well, the problem is pretty easy to describe: What do I do in a corporation with >10,000 PCs where all apps are deployed by a central server. I can add some addons but I don't see a way how to automatically add the intranet domain to the whitelist. I don't know what would be the workaround. Asking them to keep 3.6 wouldn't work I guess. Asking everyone to do some steps to add this domain to a FF4 whitelist would cause trouble. 99% even don't know what a XUL whitelist is.
As mentioned already, an addon could be written that adds a site to the whitelist on installation, without any further user interaction. It's not hard.
I'm the developer of the Remote XUL Manager add-on. I've updated its compatibility info and it should now work for all future versions of Firefox 4. Sorry for the delay.

I'm also planning to implement a way to generate add-ons that you can deploy with specific whitelists, install without requiring a restart, perform the configuration and then remove themselves.

You should all be aware that this is probably as good as it will get, at least in the 4.0 timeline. For any feature requests, please use the contact information on the add-on page, not this bug: https://addons.mozilla.org/en-US/firefox/addon/235281/

Sorry for the bugspam :P
Our use of remote XUL is in a product that we sell to our customers for them to deploy on their intranets. Therefore we can't simply provide an add-on to whitelist _our_ domain, as that's not the domain the users will be pointing at. Many of our customers also use Prism rather than Firefox, in order to give users the impression of a desktop application, but with the centralised updates and management of a web site. With that in mind, I have a few questions and comments:

1) Presenting a blank page is disastrous, as it gives no indication at all as to what the cause of the problem is. The text from comment #226 seems reasonable: "This page was designed for older versions of Firefox and is using 
technology which could be used to compromise your computer"

2) I think that the only pages affected by this completely blank response are "XUL pages" rather than "HTML pages with some XUL/XBL content". Would it be possible to present a useful error page when the root node is in the XUL namespace (per comment #240) or when the page is served with the XUL mimetype? 

3) Is there any way for the _server_ to detect whether or not remote XUL is enabled for the domain? That would allow the server to present a different page to users with Fx4 but no whitelist instructing them what to do. Perhaps the whitelist extension could add an http header when the page is being requested from a whitelisted domain? That would allow a combination of UA sniffing and header parsing to present the right page to each user.

4) Will this bug also affect Prism? If so, are there any plans for a similar whitelist extension, or for a checkbox on Prism's main "add a site" page to allow remote XUL to be enabled for the domain at the same time as adding the site?

5) Please could we have some documentation about other ways to add a domain to the whitelist. In particular how to do so from the command line, as this may be a more suitable solution for intranets where our installer could create a batch file to run on the users' machines.
If anyone have any ideas for what text (in english) we should put in the error message we display when the user navigates to a XUL page, please put your suggestions over in bug 623482.
Depends on: 640536
Depends on: 633113
Depends on: 623482
Depends on: 677474
Depends on: 771767
Keywords: sec-want
You need to log in before you can comment on or make changes to this bug.