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.

quite agree with comment #12

> 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.

> - 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.

(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.

Marking 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.

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.

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.

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)

This is where the magic happens.

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

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.

Only attach a listener while on error pages

> 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.

Or: if (aBrowser.currentURI.scheme == "about") <https://developer.mozilla.org/En/XUL/Method/AddTabsProgressListener> <https://developer.mozilla.org/en/XUL/browser#p-currentURI>

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

(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.

Given that this is somewhat risky, and still lacking reviews, I'm going to push this to 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!

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.)

The previous 'part 4' patch was the wrong patch. This is the correct one.

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.

Fix some problems that mano found during review.

Fix more review comments

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.

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...

Comment on attachment 467825 [details] [diff] [review] Part 4b: Fixes for part 4 > <!-- LOCALIZATION NOTE (securityOverride.warningText) - Do not translate the s/warningText/warningContent/

(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?

Landed parts 1-5: http://hg.mozilla.org/mozilla-central/rev/3c43a7339d02 http://hg.mozilla.org/mozilla-central/rev/1493938c90c8 http://hg.mozilla.org/mozilla-central/rev/61fd19a4587f http://hg.mozilla.org/mozilla-central/rev/7072d5e4753f http://hg.mozilla.org/mozilla-central/rev/dee01181500d and part 4b: http://hg.mozilla.org/mozilla-central/rev/baff7b7b32bc Part 6 is currently blocked on bug 589194 which will be fixed on next releng restart.

Backed out part 4b: http://hg.mozilla.org/mozilla-central/rev/ee6fb954cbc3

I've fixed the non-python comment and pushed the patches back: http://hg.mozilla.org/mozilla-central/rev/71712924bba9 http://hg.mozilla.org/mozilla-central/rev/1fb7b57d3026

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://hg.mozilla.org/mozilla-central/diff/7072d5e4753f/browser/components/feeds/content/subscribe.xml from http://hg.mozilla.org/mozilla-central/rev/7072d5e4753f is an illegal XML (comment before <?xml ...> tag), which prevents feed subscriptions.

http://forums.mozillazine.org/viewtopic.php?p=9787499#p9787499 is caused by this bug ? if so, regression or intended ?

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?

No, it will not.

There's a copy of that crappy tool in the Extension Developer's Extension if you really want it.

This push: http://hg.mozilla.org/mozilla-central/rev/cec16a1741fb Broke loading prompts in Fennec (bug 590477). The code that loads the prompts is here: http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#2153

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

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

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!!

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.

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)?

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).

> Why not switch IsInNamespace(kNameSpaceID_XUL) to IsNodeOfType(eXUL)? Because the latter is much slower?

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

(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?

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.

> 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.

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.

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. :)

> 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.

The changes made may have introduced bug 606697 - DOMParser chokes on parsing content with XML containing XUL namespace. Please consider.