Bugzilla – Full Text Bug Listing
| Summary: | Permission denied to access property '' | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Adam Dec <adam_dec> | ||||||||||
| Component: | SWT | Assignee: | Lakshmi P Shanmugam <lshanmug> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | CC: | adam_dec, adrianulbona, arunkumar.thondapu, c.sell, dstainhauser, gnosygnu, grant_gayed, lshanmug, matthew.painter, niraj.modi, peterwhitebugzilla, shippo | ||||||||||
| Version: | 4.4 | ||||||||||||
| Target Milestone: | 4.5 M6 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows 7 | ||||||||||||
| See Also: |
https://git.eclipse.org/r/35753 https://git.eclipse.org/r/43757 https://git.eclipse.org/r/43967 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b0e3448552a8fc9264fc89b242ed0031ee7cc2a4 https://git.eclipse.org/r/44067 https://git.eclipse.org/r/44068 https://git.eclipse.org/r/44069 https://bugs.eclipse.org/bugs/show_bug.cgi?id=465757 |
||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
I have seen the same with org.eclipse.swt.win32.win32.x86_3.103.0.v20140122-1932, XULRunner 24 32bit The code executed flawlessly against XULRunner 10 Please, any comments on that? Hi Adam, please attach some snippets of your code that can be used by us to reproduce the same problem at our end. Thanks! Everything is here: http://www.eclipse.org/forums/index.php/t/665690/ No magic. Thiss is my JavaScript that I want to evaluate using browser.evaluate() try { return window.document.getElementById("hplogo").title; } catch(e) { ExceptionHandler(e.toString()); } Permission denied comes randomly :( Other code is from jQuery" $('#ID').click(); or $('#formID').submit(); Do not get me wrong..I have no specific JavaScript code to share... Permission denied comes randomly when code is trying to access DOM... In my code I have used pure javascript and framework like jQuery...thats all... Created attachment 241635 [details]
Example java code to demonstrate permission denied error
I can reproduce the same on my Windows XP machine (as well as a Windows 7 64-bit one). I've attached a testcase above. Environment details: * SWT 4.4 M6: http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/S-4.4M6-201403061200/swt-4.4M6-win32-win32-x86.zip * XULRunner 24: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/24.0/runtimes/xulrunner-24.0.en-US.win32.zip * JRE: build 1.7.0_17-b02 Test case notes: * There are 2 links that will appear when running the test case ** Link 1 calls javascript for getRangeCount; it will fail and throw the following: org.eclipse.swt.SWTException: Permission denied for <file://> to get property Selection.rangeCount ** Link 2 calls the same javascript but wraps it in a setTimeout. The javascript no longer fails. * Both test cases work fine against XULRunner 10 Other notes: * Setting the prefs.js to bypass this issue does not work: ** security.fileuri.strict_origin_policy: http://kb.mozillazine.org/Security.fileuri.strict_origin_policy; http://stackoverflow.com/questions/7274538/firefox-and-local-files ** capability.policy.*: http://stackoverflow.com/questions/1289063/how-to-bypass-document-domain-limitations-when-opening-local-files *** Bug 431839 has been marked as a duplicate of this bug. *** I guess this is going to miss being fixed for the Luna release? Having the same problem with Luna and XULRunner
XULRunner 24, 32 bit
SWT: org.eclipse.swt.win32.win32.x86_3.103.0.v20140605-2012 32 bit
JDK: jdk1.7.0_25 32 bit
OS: Windows 7 64 bit
The permission denied exception only occurs when executing javascript functions on a Selection object, like toString() or getRange().
if (window.getSelection) {
// mozilla, safari
var selection = window.getSelection();
var text = selection.toString();
-> crash
When running with setTimeout it works, but this is not suitable for our purpose as we need the selected text in the return value of browser.evaluate.
If finally installed XULRunner 10.0.2 and it is working fine. This will suit as a temporary workaround but we hope the bug will soon be fixed as XULRunner 24 has better HTML 5 support.
Thanks for fixing it.
How come this bug is a P3? It renders a feature unusable, shouldn't it be at least a P2? Created attachment 248258 [details]
Fix
Neil, Can you please submit the patch via Gerrit? Please refer: http://www.vogella.com/tutorials/Gerrit/article.html for help if needed, Thanks! (In reply to Niraj Modi from comment #13) > Neil, Can you please submit the patch via Gerrit? Please refer: > http://www.vogella.com/tutorials/Gerrit/article.html for help if needed, > Thanks! I have created https://git.eclipse.org/r/#/c/35753/ is this correct? I've seen that the patch was applied on platform/eclipse.platform.swt's master. Shouldn't it be also applied to the 4.4 maintenance branch? Cool patch :)
Couple of tweaks I can see are necessary:
(1) The current eclipse code expects js of the form "return window.title"; a simple change like this perhaps?
nsEmbedString data = new nsEmbedString ("(function() { "+script+" })()");
execute.EvalInWindow (window, data, result);
(2) Currently (rightly or wrongly) you can access chrome code such as Components.classes within the execute/evaluate code. SWT need to be happy that this implementation as it stands will break this, which is fine IMHO because it is a security issue that can give js code access to the filesystem accidentally.
(3) Those people who have written their own wrappers to deal with (2) (like me) need an alternative method of executing chrome code. There is the code to deal with this in swt.js, but it needs to be made accessible from Java also. Testing this out it looks like the with(window) {} construct causes issues accessing e.g. Components as the security privilege changes. I would suggest that something like:
execute.prototype.evalInWindow = function(aWindow, aString) {
var window = XPCNativeWrapper.unwrap(aWindow);
try {
window.external.QueryInterface(Components.interfaces.External);
} catch (e) {
window.external = Components.classes["@eclipse.org/external;1"].createInstance();
}
return eval(aString);
};
... and then if you want access to "window" you have to use it qualified/explicitly. What do you think?
(In reply to Matt from comment #16) > (1) The current eclipse code expects js of the form "return window.title"; Thanks, I hadn't realised that this was the case. > (2) Currently (rightly or wrongly) you can access chrome code such as > Components.classes within the execute/evaluate code. Sorry, but I am unable to reproduce this; do you have an example snippet that works with SWT 4.4? > it looks like the with(window) {} construct causes > issues accessing e.g. Components as the security privilege changes. Ah yes, you're probably implicitly accessing window.Components here. I wasn't sure whether the explicit window access was acceptable, which is why I hadn't implemented it that way. As the patch stands, the workaround is to use (function(){return this.Components;}()) to access the privileged Components. (In reply to Neil Rashbrook from comment #17) > (In reply to Matt from comment #16) > > (1) The current eclipse code expects js of the form "return window.title"; > Thanks, I hadn't realised that this was the case. > > > (2) Currently (rightly or wrongly) you can access chrome code such as > > Components.classes within the execute/evaluate code. > Sorry, but I am unable to reproduce this; do you have an example snippet > that works with SWT 4.4? Sure, here you are: https://gist.github.com/mjgp2/1879dc0e1428b90c56ab > > > it looks like the with(window) {} construct causes > > issues accessing e.g. Components as the security privilege changes. > Ah yes, you're probably implicitly accessing window.Components here. I > wasn't sure whether the explicit window access was acceptable, which is why > I hadn't implemented it that way. As the patch stands, the workaround is to > use (function(){return this.Components;}()) to access the privileged > Components. As for (3) I would say that I would be pro having to explicitly reference window, and having a new pair of execute / evaluate methods for chrome level code. Created attachment 248966 [details] Exception (In reply to Matt from comment #18) > (In reply to Neil Rashbrook from comment #17) > > (In reply to Matt from comment #16) > > > (2) Currently (rightly or wrongly) you can access chrome code such as > > > Components.classes within the execute/evaluate code. > > Sorry, but I am unable to reproduce this; do you have an example snippet > > that works with SWT 4.4? > Sure, here you are: https://gist.github.com/mjgp2/1879dc0e1428b90c56ab Sorry, but that throws the attached exception when I try. (In reply to Neil Rashbrook from comment #20) > Created attachment 248966 [details] > Exception > > (In reply to Matt from comment #18) > > (In reply to Neil Rashbrook from comment #17) > > > (In reply to Matt from comment #16) > > > > (2) Currently (rightly or wrongly) you can access chrome code such as > > > > Components.classes within the execute/evaluate code. > > > Sorry, but I am unable to reproduce this; do you have an example snippet > > > that works with SWT 4.4? > > Sure, here you are: https://gist.github.com/mjgp2/1879dc0e1428b90c56ab > Sorry, but that throws the attached exception when I try. Curious. Running with the latest production swt-debug.jar on linux x64 with FF10 it works for me. Are you testing with FF24? (In reply to Matt from comment #21) > (In reply to Neil Rashbrook from comment #20) > > Created attachment 248966 [details] > > Exception > > > > (In reply to Matt from comment #18) > > > (In reply to Neil Rashbrook from comment #17) > > > > (In reply to Matt from comment #16) > > > > > (2) Currently (rightly or wrongly) you can access chrome code such as > > > > > Components.classes within the execute/evaluate code. > > > > Sorry, but I am unable to reproduce this; do you have an example snippet > > > > that works with SWT 4.4? > > > Sure, here you are: https://gist.github.com/mjgp2/1879dc0e1428b90c56ab > > Sorry, but that throws the attached exception when I try. > > Curious. Running with the latest production swt-debug.jar on linux x64 with > FF10 it works for me. Are you testing with FF24? Confirmed locally that it works with FF10 and throws said exception with FF24. (In reply to Matt from comment #21) > (In reply to Neil Rashbrook from comment #20) > > Created attachment 248966 [details] > > Exception > > > > (In reply to Matt from comment #18) > > > (In reply to Neil Rashbrook from comment #17) > > > > (In reply to Matt from comment #16) > > > > > (2) Currently (rightly or wrongly) you can access chrome code such as > > > > > Components.classes within the execute/evaluate code. > > > > Sorry, but I am unable to reproduce this; do you have an example snippet > > > > that works with SWT 4.4? > > > Sure, here you are: https://gist.github.com/mjgp2/1879dc0e1428b90c56ab > > Sorry, but that throws the attached exception when I try. > Curious. Running with the latest production swt-debug.jar on linux x64 with > FF10 it works for me. Are you testing with FF24? Yes I was testing using XR24 on Win32; SWT seems to crash my XR10 on shutdown which is why I was avoiding it (I don't have a debug build of XR10 handy). In this case the difference is probably explained by security being tightened between XR10 and XR24, rather than there being any problem with SWT. Agreed, there just needs to be an alternative (public) API for running chrome code in 24+ as it is possible in 10, that would surface the xul component chrome code in the patch. Where does SWT sit on adding in such an API to Browser? Or is there a better alternative? Can anyone from Eclipse/SWT comment on the API question? (In reply to Matt from comment #24) > Agreed, there just needs to be an alternative (public) API for running > chrome code in 24+ as it is possible in 10, that would surface the xul > component chrome code in the patch. > > Where does SWT sit on adding in such an API to Browser? Or is there a better > alternative? We cannot add an API in Browser class for something specific to Mozilla browser. But, we can add the required NS*.java classes to SWT and use their methods to perform Mozilla specific tasks. (for eg: see the Mozilla Browser snippets @ https://www.eclipse.org/swt/snippets/#browser) What is the API you are suggesting here? Is it possible to perform the same thing using the Mozilla NS* classes? (In reply to Lakshmi Shanmugam from comment #26) > browser. But, we can add the required NS*.java classes to SWT and use their > methods to perform Mozilla specific tasks. (for eg: see the Mozilla Browser > snippets @ https://www.eclipse.org/swt/snippets/#browser) If you're talking about the JAVAXPCOM classes that once were part of the Mozilla distro, forget it. They have long been dropped (ver. 10) and arent maintained any longer. (In reply to Christian Sell from comment #27) > (In reply to Lakshmi Shanmugam from comment #26) > > browser. But, we can add the required NS*.java classes to SWT and use their > > methods to perform Mozilla specific tasks. (for eg: see the Mozilla Browser > > snippets @ https://www.eclipse.org/swt/snippets/#browser) > > If you're talking about the JAVAXPCOM classes that once were part of the > Mozilla distro, forget it. They have long been dropped (ver. 10) and arent > maintained any longer. Some are still in org.eclipse.swt.internal.mozilla org.eclipse.swt.internal.mozilla.Execute was added in the submitted patch to add the functionality. I didn't think this was exported before, but now it seems to be, just flagged as internal. (In reply to Matt from comment #28) > (In reply to Christian Sell from comment #27) > > (In reply to Lakshmi Shanmugam from comment #26) > > > browser. But, we can add the required NS*.java classes to SWT and use their > > > methods to perform Mozilla specific tasks. (for eg: see the Mozilla Browser > > > snippets @ https://www.eclipse.org/swt/snippets/#browser) > > > > If you're talking about the JAVAXPCOM classes that once were part of the > > Mozilla distro, forget it. They have long been dropped (ver. 10) and arent > > maintained any longer. > > Some are still in org.eclipse.swt.internal.mozilla > > org.eclipse.swt.internal.mozilla.Execute was added in the submitted patch to > add the functionality. > > I didn't think this was exported before, but now it seems to be, just > flagged as internal. I have a working PoC that uses Neil's code to call Chrome methods :) Couple of small changes required, detailed below. swt.js: Make "window" available just in the scope, "with" causes security issues Execute.java: Add java call to mirror chrome method as defined in idl Mozilla.java: Return the SWT internal version of the nsiWebBrowser from getWebBrowser if JavaXPCom isn't available. I've attached a git diff against the current patch set, seems like as I don't own the gerrit submission this is the best way? Just wanted to thank Neil for the work here, good to see this component moving along again :) Created attachment 249588 [details]
git diff for Chrome code execution support
Hi Neil & Matt, The bug is blocked on couple of issues in the gerrit patch. The patch fixes the bug but the remaining issues have to be fixed before it can be merged to master. They need to be addressed this week for it to go into M6. Do you plan to do this for M6 or should we move the bug to M7? I'm trying to look at this today or tomorrow :) New Gerrit change created: https://git.eclipse.org/r/43757 (In reply to Lakshmi Shanmugam from comment #31) > Hi Neil & Matt, > The bug is blocked on couple of issues in the gerrit patch. The patch fixes > the bug but the remaining issues have to be fixed before it can be merged to > master. > They need to be addressed this week for it to go into M6. > Do you plan to do this for M6 or should we move the bug to M7? I have updated the gerrit change @ https://git.eclipse.org/r/#/c/35753 to address the two issues on the patch. Hopefully it should be good to merge tomorrow. If there are any questions I will be available to address them tomorrow. (PS Apologies for creating a gerrit change I immediately abandoned - it's my first foray into gerrit and I made an incorrect assumption!) Pushed the gerrit change to master --> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a84c4f3464a5f713e18d5891323717c2051b011d Thanks Matt & Neil for the patches! (In reply to Lakshmi Shanmugam from comment #35) > Pushed the gerrit change to master --> > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=a84c4f3464a5f713e18d5891323717c2051b011d > > Thanks Matt & Neil for the patches! Thanks for merging, however, you took out a key part that means that that there is now a regression in that you cannot execute chrome code as you can with XUL10. Comment was here: https://git.eclipse.org/r/#/c/35753/14/bundles/org.eclipse.swt/META-INF/MANIFEST.MF@25 I didn't have time to reply before you merged. I would have posted: Exporting internal packages marked as internal is already a pattern present in SWT. Access to this package is required in order to access the evalAsChrome method on the Execute class as discussed on this bug. "We cannot add an API in Browser class for something specific to Mozilla browser. But, we can add the required NS*.java classes to SWT and use their methods to perform Mozilla specific tasks. (for eg: see the Mozilla Browser snippets @ https://www.eclipse.org/swt/snippets/#browser) What is the API you are suggesting here? Is it possible to perform the same thing using the Mozilla NS* classes?" Without this it gives no upgrade path to those who depend on this functionality. (In reply to Matt Painter from comment #36) > (In reply to Lakshmi Shanmugam from comment #35) > > Pushed the gerrit change to master --> > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=a84c4f3464a5f713e18d5891323717c2051b011d > > > > Thanks Matt & Neil for the patches! > > Thanks for merging, however, you took out a key part that means that that > there is now a regression in that you cannot execute chrome code as you can > with XUL10. > > Comment was here: > https://git.eclipse.org/r/#/c/35753/14/bundles/org.eclipse.swt/META-INF/ > MANIFEST.MF@25 > > I didn't have time to reply before you merged. I would have posted: > Sorry, but I had to push the changes before the build started. The change to MANIFEST.MF was not in any of the earlier patches here or in gerrit. This change came in very late in the milestone to review and provide feedback. > Exporting internal packages marked as internal is already a pattern present > in SWT. The problem here is that all the classes in this internal package are public. So, exporting this package will expose all the internal classes. > > Access to this package is required in order to access the evalAsChrome > method on the Execute class as discussed on this bug. Can we instead have a public class in the org.eclipse.swt.browser package (Eclipse SWT Mozilla/common/org/eclipse/swt/browser) and have a public method through which we can call evalAsChrome. (similar to how evalInWindow is called in Mozilla.execute()). If we have to do it, it has to be done now, as this is milestone week and this milestone is also API freeze. New Gerrit change created: https://git.eclipse.org/r/43967 > > Access to this package is required in order to access the evalAsChrome
> > method on the Execute class as discussed on this bug.
> Can we instead have a public class in the org.eclipse.swt.browser package
> (Eclipse SWT Mozilla/common/org/eclipse/swt/browser) and have a public
> method through which we can call evalAsChrome. (similar to how evalInWindow
> is called in Mozilla.execute()).
>
> If we have to do it, it has to be done now, as this is milestone week and
> this milestone is also API freeze.
OK, here's a gerrit for the extra API.
Gerrit change https://git.eclipse.org/r/43967 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b0e3448552a8fc9264fc89b242ed0031ee7cc2a4 Matt, I've pushed the new API. Do you have a test snippet/script to test it? (In reply to Lakshmi Shanmugam from comment #41) > Matt, > I've pushed the new API. Do you have a test snippet/script to test it? As part of testing I tried running the Snippet from comment #18, doesn't work for me with the new API and XULR24. Can you try it out? A review comment from another committer, why not use evalAsChrome() in the existing browser.evaluate()? It would remove the need for another API. Also, the new API would have to be well documented for the client to find it. (In reply to Lakshmi Shanmugam from comment #42) > (In reply to Lakshmi Shanmugam from comment #41) > > Matt, > > I've pushed the new API. Do you have a test snippet/script to test it? > > As part of testing I tried running the Snippet from comment #18, doesn't > work for me with the new API and XULR24. Can you try it out? I've updated the gist with the new call, and it works for me. https://gist.github.com/mjgp2/1879dc0e1428b90c56ab > > A review comment from another committer, why not use evalAsChrome() in the > existing browser.evaluate()? It would remove the need for another API. Also, > the new API would have to be well documented for the client to find it. Couple of points: (1) no other browser integration (webkit/ie) has elevated security permissions (2) it's a security hole - the user's assumption would be that it runs in the normal page context, so is safe for javascript to be run in. However it's simple to read, delete and modify files from chrome javascript. (In reply to Matt Painter from comment #43) > (In reply to Lakshmi Shanmugam from comment #42) > > (In reply to Lakshmi Shanmugam from comment #41) > > > Matt, > > > I've pushed the new API. Do you have a test snippet/script to test it? > > > > As part of testing I tried running the Snippet from comment #18, doesn't > > work for me with the new API and XULR24. Can you try it out? > > I've updated the gist with the new call, and it works for me. > https://gist.github.com/mjgp2/1879dc0e1428b90c56ab I tested the snippet on Mac and the new API returns null. > > > > > A review comment from another committer, why not use evalAsChrome() in the > > existing browser.evaluate()? It would remove the need for another API. Also, > > the new API would have to be well documented for the client to find it. > > Couple of points: > > (1) no other browser integration (webkit/ie) has elevated security > permissions > (2) it's a security hole - the user's assumption would be that it runs in > the normal page context, so is safe for javascript to be run in. However > it's simple to read, delete and modify files from chrome javascript. The security hole still exists while using browser.evaluate() with XULR <=10? (In reply to Lakshmi Shanmugam from comment #44) > (In reply to Matt Painter from comment #43) > > (In reply to Lakshmi Shanmugam from comment #42) > > > (In reply to Lakshmi Shanmugam from comment #41) > > > > Matt, > > > > I've pushed the new API. Do you have a test snippet/script to test it? > > > > > > As part of testing I tried running the Snippet from comment #18, doesn't > > > work for me with the new API and XULR24. Can you try it out? > > > > I've updated the gist with the new call, and it works for me. > > https://gist.github.com/mjgp2/1879dc0e1428b90c56ab > I tested the snippet on Mac and the new API returns null. Works for me with XUL24: http://s28.postimg.org/4ezfaux31/Screen_Shot_2015_03_17_at_18_32_36.png > > > > > > > > A review comment from another committer, why not use evalAsChrome() in the > > > existing browser.evaluate()? It would remove the need for another API. Also, > > > the new API would have to be well documented for the client to find it. > > > > Couple of points: > > > > (1) no other browser integration (webkit/ie) has elevated security > > permissions > > (2) it's a security hole - the user's assumption would be that it runs in > > the normal page context, so is safe for javascript to be run in. However > > it's simple to read, delete and modify files from chrome javascript. > The security hole still exists while using browser.evaluate() with XULR <=10? Yes, but there's nothing you can do to close it without killing backwards compatibility. (In reply to Lakshmi Shanmugam from comment #41) > Matt, > I've pushed the new API. Do you have a test snippet/script to test it? Hi Lakshmi, Exposing this feature from a new Class, then it would be difficult for user to identify that such API exists, will suggest to expose this new API from the Browser class itself, may be something like below with appropriate JavaDocs to warn/restrict the use to Mozilla only: /** * This method will be honored only by Mozilla in order to run script by * ignoring the security(this is Mozilla only feature) * If called on other Browsers instance, it will delegate/default to Browser.evaluate (String script) method */ public static Object evaluateBypassingSecurity (String script) throws SWTException(); (In reply to Niraj Modi from comment #46) > (In reply to Lakshmi Shanmugam from comment #41) > > Matt, > > I've pushed the new API. Do you have a test snippet/script to test it? > > Hi Lakshmi, > Exposing this feature from a new Class, then it would be difficult for user > to identify that such API exists, will suggest to expose this new API from > the Browser class itself, may be something like below with appropriate > JavaDocs to warn/restrict the use to Mozilla only: > /** > * This method will be honored only by Mozilla in order to run script by > * ignoring the security(this is Mozilla only feature) > * If called on other Browsers instance, it will delegate/default to > Browser.evaluate (String script) method > */ > public static Object evaluateBypassingSecurity (String script) throws > SWTException(); I'm happy to do a gerrit for this. New Gerrit change created: https://git.eclipse.org/r/44067 New Gerrit change created: https://git.eclipse.org/r/44068 New Gerrit change created: https://git.eclipse.org/r/44069 (In reply to Eclipse Genie from comment #50) > New Gerrit change created: https://git.eclipse.org/r/44069 Apologies, the commit hooks somehow were lost on my system, and pushing two updates therefore created new gerrit reviews. I have reinstalled the commit hook. The previous two I have abandoned. (In reply to Matt Painter from comment #45) > (In reply to Lakshmi Shanmugam from comment #44) > > (In reply to Matt Painter from comment #43) > > > (In reply to Lakshmi Shanmugam from comment #42) > > > > (In reply to Lakshmi Shanmugam from comment #41) > > > > > Matt, > > > > > I've pushed the new API. Do you have a test snippet/script to test it? > > > > > > > > As part of testing I tried running the Snippet from comment #18, doesn't > > > > work for me with the new API and XULR24. Can you try it out? > > > > > > I've updated the gist with the new call, and it works for me. > > > https://gist.github.com/mjgp2/1879dc0e1428b90c56ab > > I tested the snippet on Mac and the new API returns null. > > Works for me with XUL24: > > http://s28.postimg.org/4ezfaux31/Screen_Shot_2015_03_17_at_18_32_36.png > I'm unable to open the link. Does it work for you on Mac? It works for me on Windows, but not on Mac.
> > http://s28.postimg.org/4ezfaux31/Screen_Shot_2015_03_17_at_18_32_36.png
> >
> I'm unable to open the link. Does it work for you on Mac? It works for me on
> Windows, but not on Mac.
Works for me XUL24, OS X 10.10. Linked image is just SWT + Mozilla with the "1.0" pop up from the snippet.
(In reply to Niraj Modi from comment #46) > (In reply to Lakshmi Shanmugam from comment #41) > > Matt, > > I've pushed the new API. Do you have a test snippet/script to test it? > > Hi Lakshmi, > Exposing this feature from a new Class, then it would be difficult for user > to identify that such API exists, will suggest to expose this new API from > the Browser class itself, may be something like below with appropriate > JavaDocs to warn/restrict the use to Mozilla only: > /** > * This method will be honored only by Mozilla in order to run script by > * ignoring the security(this is Mozilla only feature) > * If called on other Browsers instance, it will delegate/default to > Browser.evaluate (String script) method > */ > public static Object evaluateBypassingSecurity (String script) throws > SWTException(); Thanks for the feedback, Niraj. Initially, I didn't think it was right to add an API for something specific to Mozilla & XULR >=24. But, after trying out several things, having it in Browser seemed better for visibility. And the new API can be created as an extension of the existing evaluate API. The new API is designed on the lines of setText(String, boolean) -> public Object evaluate (String script, boolean trusted) It is in the latest I-build: I20150318-2000 Matt, can you please try it out? Thanks! (In reply to Lakshmi Shanmugam from comment #55) > It is in the latest I-build: I20150318-2000 > > Matt, can you please try it out? Thanks! Works for me on OS X :) Much prefer the API. One thing that I would suggest is that trusted in #evaluate(String) defaults to false (not true) so as to close the aforementioned security hole. Hi Matt, Looks like Browser.evaluate(script, true) is not working anymore. Please see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=465757. Can you try out I20150427-0800 or later and see if there is any problem with the new API? Thanks! The patch (In reply to Lakshmi Shanmugam from comment #57) > Hi Matt, > Looks like Browser.evaluate(script, true) is not working anymore. Please see > bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=465757. > Can you try out I20150427-0800 or later and see if there is any problem with > the new API? > Thanks! The fix for this bug caused BrowserFunction to not work for XULRunner versions < 24 (see Bug 465757). This is fixed now. |
SWT version: swt-I20140305-2000-win32-win32-x86_64 XULRunner version: 24 64b JDK: 7u51 (64b) i have encountered cases where the javascript I execute via Browser#execute randomly throws errors of the kind: "Permission denied when accessing property XXX". Solution was to enclose the javascript code in: setTimeout(function(){/* code here */}, 10); Forcing javascript execution onto the JS UI thread. After that, no more errors