XUL:Remote XUL bugs

This page is a list of features, that require currently privileges to run, but that we need in web application and that in fact, wouldn't require privilege (because it seems that there isn't security reason).

So it could be nice if this following features become scriptable object that we can use in unprivilege script

• drag and drop

• datasources

(BenBucksch) Currently can't create and populate your own datasource from JS, only the remote-RDF-file-loader works. Documented (wording unclear), but severe restriction when working with trees etc.. I don't see any security reasons, as long as you're not allowed to change (or read or merge with) other internal data sources like bookmarks. If anybody knows a workaround, hints welcome.

• xml-rpc

(XUL:Axel Hecht) This is unclear. If you are referring to same-site restrictions, that is something that is likely to be discussed in the context of GeckoDev's SecurityAndPriviledges and should include the new soap security model.

• changing the height, width and title attributes of the <window> tag (described in bug 248004)

(NeilRashbrook) <window title="foo"> now works for remote XUL in 1.8

• We need more window dialog boxes than only alert(), confirm() and prompt(). Using privileged nsIPromptService we can use confirmEx() which also lets us customize the buttons that are displayed. It seems that there aren't any security reasons to prevent to use it. Other useful message boxes that comes with nsIPromptService interface are alertCheck() and confirmCheck(). http://xulplanet.com/references/xpcomref/ifaces/nsIPromptService.html

(BenjaminSmedberg) While it might be possible to add a few more default dialogs, it would be more generic to add the IE-compatible showModalDialog() DOM method, so apps can pop up whatever they wish. (BenBucksch) Do you think showModalDialog() is a good idea, considering phishing/UI-fakes and popup blockers? Also, predefined dialogs can be more easily made to fit to the platform (if ensuring that the user is aware that it's a dialog from the webpage, not Mozilla or another app).

• Load external DTD. This is really important for XUL remote application. For the time being the only way to load a DTD is using chrome. We need the ability to load DTD with a relative path. Otherwise remote xul developer can't localize their remote applications. Localizing remote XUL applications is a real improvement comparing to traditional web application. Actually, I don't know if this is a bug or a security restriction: http://bugzilla.mozilla.org/show_bug.cgi?id=22942 [Benjamin Smedberg] This is a bug, but it requires a decent amount of work to fix in the XML parser. The latest version of expat (1.95.8), which supports suspend/resume of the outer XML parsing to allow for non-blocking loads of the external DTD. This will probably make the mozilla 1.9 milestone, and is a top priority.

(XUL:Axel Hecht) copied this issue over to GeckoDev:WishList, plus comment from myself, gonna remove the item here sometime soonish

• Expose in the Options window the ability to change the value for signed.applets.codebase_principal_support. Currently we have to ask to the users to change the value from false to true using about:config and this is not a viable solution. I don't see any real security issue because, in any case, every time we ask for privileges a confirm box appear and the user have to accept it.

(NeilDeakin) you should never be telling any user to change this preference.

Why not? My remote applications are mainly for intranet.

(JesseRuderman) if the enablePrivilege dialog didn't suck so much, it would make sense for signed.applets.codebase_principal_support to be true by default. We allow XPIs, after all.

(BenBucksch) IMHO signed.applets.codebase_principal_support should be false by default and not be exposed in the UI. It's terribly insecure over the net and exposing it more will only lead people (developers and consequently users) to do the wrong thing. Either you are trusted and can be installed as extension with chrome rights or you shouldn't be running with these priviledges. In intranets where chrome is too expensive to distribute, you can set the default in your Mozilla distro or sign the app (good luck with signtool :( ). But ideally, intranet apps wouldn't need UniversalXPConnect or similar sledge hammers, only permission to open windows etc., that's what this page is about.

• Copy and paste. Enable to use the three XPCOM objects needed for copy and paste (nsISupportsString, nsITransferable, nsIClipboard)

(BenBucksch) Clipboard not possible, would be a security bug. People have passwords in their clipboard.

• Edit remote HTML - not talking about saving changes back here, but the ability to use the editor tag on remote sources

(NeilRashbrook) Doesn't Midas satisfy that requirement?

• RDF loading

(ConorDowling) Remote XUL pages often need to know when an RDF file has loaded. They can't listen to progress events and so can't neatly know when RDF loading ends. RDF should load asynchronously too - right now it seems to block the browser.