Confirmed users
596
edits
XUL:Remote XUL bugs: Difference between revisions
Jump to navigation
Jump to search
More list formatting
(Moving items around, depending on importance) |
(More list formatting) |
||
| Line 8: | Line 8: | ||
== RDF datasources == | == RDF datasources == | ||
[[User:BenB|Ben Bucksch]] Currently can't create and populate your own datasource from JS, only the remote-RDF-file-loader works. [http://www.xulplanet.com/tutorials/xultu/templates.html 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. | |||
== RDF local file async loading == | == RDF local file async 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. | |||
== Load external DTD == | == 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 [http://wiki.mozilla.org/GeckoDev?WishList GeckoDev:WishList], plus comment from myself, gonna remove the item here sometime soonish | |||
== Changing the height, width and title attributes of the <window> == | == Changing the height, width and title attributes of the <window> == | ||
Described in [https://bugzilla.mozilla.org/show_bug.cgi?id=248004 bug 248004] | |||
(NeilRashbrook) <window title="foo"> now works for remote XUL in 1.8 | |||
== More window dialog boxes than only alert(), confirm() and prompt() == | == 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. | * (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). | * (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). | ||
== File open and save dialog == | == File open and save dialog == | ||
This dialog would not only prompt the user for a file to read in, but would also read in the file and present it in a javascript string or array or input stream or something. I am not talking about direct access to the file objects, since remote scripts should not be able to read and write any file they want. What I want is a dialog (or just a tag, doesn't have to be a dialog) that prompts the user to select a file and then loads that file and returns it. It might also be nice to have a XMLFileOpen dialog, which would allow a DTD to be attached and would also return the data as a DOM tree. An example implementation is [[XUL:File_Input]]. | This dialog would not only prompt the user for a file to read in, but would also read in the file and present it in a javascript string or array or input stream or something. I am not talking about direct access to the file objects, since remote scripts should not be able to read and write any file they want. What I want is a dialog (or just a tag, doesn't have to be a dialog) that prompts the user to select a file and then loads that file and returns it. It might also be nice to have a XMLFileOpen dialog, which would allow a DTD to be attached and would also return the data as a DOM tree. An example implementation is [[XUL:File_Input]]. | ||
Rationale: This is already possible with a html input type="file" inside the XUL. That is, create a HTML input type=file, which would then post the file to the remote server. The file could then be retrieved from the server by using xmlhttprequest. This doesn't scale well, and the end result is the same. Using something like [http://www.quirksmode.org/dom/inputfile.html this] and some more CSS could probably even get the input to look exactly like it was just another XUL element. I also don't think it is a really big security issue, since the only file the remote script would be able to read would be the one the user selected. | |||
A file save dialog would be similar to the above, allowing a remote script to present a javascript string to be saved or an output stream or something. I am not as sure about this, since it might be possible to load the data into a hidden iframe and then call the document.execCommand('SaveAs',null,filename) command. Again, this seems possible already. | A file save dialog would be similar to the above, allowing a remote script to present a javascript string to be saved or an output stream or something. I am not as sure about this, since it might be possible to load the data into a hidden iframe and then call the document.execCommand('SaveAs',null,filename) command. Again, this seems possible already. | ||
== Copy and paste == | == Copy and paste == | ||
Enable to use the three XPCOM objects needed for copy and paste (nsISupportsString, nsITransferable, nsIClipboard) | |||
(BenBucksch) Note that XUL textfields do make use of user-triggered copy/paste just like HTML textfields do (XXX verify - at least they should) | |||
* (BenBucksch) Scriptable clipboard access is not possible, that would be a security bug. People have passwords in their clipboard. | * (BenBucksch) Scriptable clipboard access is not possible, that would be a security bug. People have passwords in their clipboard. | ||
* (BrianEcker) Why not write-only perms to clipboard? | * (BrianEcker) Why not write-only perms to clipboard? | ||
* (BenBucksch) What would you gain by being able to copy, but not paste? | * (BenBucksch) What would you gain by being able to copy, but not paste? | ||
== 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? | |||
== XML-RPC == | == XML-RPC == | ||
? | |||
* ([[XUL:Axel Hecht|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 [http://wiki.mozilla.org/GeckoDev?SecurityAndPriviledges GeckoDev's SecurityAndPriviledges] and should include the [http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html new soap security model]. | * ([[XUL:Axel Hecht|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 [http://wiki.mozilla.org/GeckoDev?SecurityAndPriviledges GeckoDev's SecurityAndPriviledges] and should include the [http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html new soap security model]. | ||
== Prefs UI for signed.applets.codebase_principal_support == | == Prefs UI for signed.applets.codebase_principal_support == | ||
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. | 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. | * (NeilDeakin) you should never be telling any user to change this preference. | ||
* Why not? My remote applications are mainly for intranet. | * Why not? My remote applications are mainly for intranet. | ||