UnhandledWebDriverError: Permission denied for <http://www.facebook.com> to get property Window.frameElement - SEE COMMENTS 47, 55 AND 64 FOR WORKAROUND

[lukeis]

Originally reported on Google Code with ID 2863

I'm sending a message to select an iframe (http://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/frame)
to selenium via the facebook php bindings / RemoteWebDriver, but instead of selecting
the frame I'm getting an exception:

08:38:00.730 WARN - Exception thrown
org.openqa.selenium.WebDriverException: Permission denied for <http://www.facebook.com>
to get property Window.frameElement; duration or timeout: 15.04 seconds
Build info: version: '2.12.0', revision: '14666', time: '2011-11-10 18:35:23'
System info: os.name: 'Windows 7', os.arch: 'x86', os.version: '6.1', java.version:
'1.6.0_29'
Driver info: driver.version: RemoteWebDriver

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

    at java.lang.reflect.Constructor.newInstance(Unknown Source)

    at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:147)

    at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:113)

    at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:416)

    at org.openqa.selenium.remote.RemoteWebDriver$RemoteTargetLocator.frame(RemoteWebDriver.java:636)

    at org.openqa.selenium.support.events.EventFiringWebDriver$EventFiringTargetLocator.frame(EventFiringWebDriver.java:561)

    at org.openqa.selenium.remote.server.handler.SwitchToFrame.call(SwitchToFrame.java:52)

    at org.openqa.selenium.remote.server.handler.SwitchToFrame.call(SwitchToFrame.java:1)

    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

    at java.util.concurrent.FutureTask.run(Unknown Source)

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

    at java.lang.Thread.run(Unknown Source)

Caused by: org.openqa.selenium.remote.ErrorHandler$UnknownServerException: Permission
denied for <http://www.facebook.com> to get property Window.frameElement
Build info: version: '2.12.0', revision: '14666', time: '2011-11-10 18:35:23'
System info: os.name: 'Windows 7', os.arch: 'x86', os.version: '6.1', java.version:
'1.6.0_29'
Driver info: driver.version: unknown

I'm using Firefox 8.  I can't tell whether this is new behavior since changing from
FF8 or Selenium 2.11 or changing to the facebook php bindings.  Sorry I can't be more
specific but a lot is in flux at the moment.  It does happen 100% of the time though.

Here's the relevant line from the selenium log:

08:37:45.693 INFO - Executing: [switch to frame: app_runner_4ec53860c57652b93621183]
at URL: /session/1321547817083/frame)

Thanks for your help.

-DB

Reported by dbyron0 on 2011-11-17 16:46:41

[lukeis]

Issue 4048 has been merged into this issue.

Reported by luke.semerau on 2012-06-07 22:36:24

[lukeis]

I am having the same issue but with HTMLDocument.compatMode

I have added the follwing code to my firefox constructer: 

FirefoxProfile profilex = new FirefoxProfile();
                profilex.setPreference("capability.policy.default.Window.QueryInterface",
"allAccess");
                profilex.setPreference("capability.policy.default.Window.frameElement.get",
"allAccess");
                profilex.setPreference("capability.policy.default.Window.HTMLDocument.compatMode.get",
"allAccess");

                capabilities.setCapability(FirefoxDriver.PROFILE, profilex ) ;

However, this does not act as a work around and we still hit the issue, making our
test site untestable in firefox. 

Reported by foley85 on 2012-06-15 09:14:47

[lukeis]

I believe you want:
profilex.setPreference("capability.policy.default.HTMLDocument.compatMode.get", "allAccess");
or possibly
profilex.setPreference("capability.policy.default.Document.compatMode.get", "allAccess");

Reported by dawagner on 2012-06-15 13:43:46

[lukeis]

This happens even in Selenium 2.24.1 and Firefox 12.

The property I had to "allAccess" in my case was "Window.mozInnerScreenY".

I don't need an ETA, but do the devs have a "clue" of what's going on at least?
From the sound of it, if feels like it's Firefox security that is suddenly become "anal",
in a way that breaks WebDriver. Am I right?

Reported by detronizator on 2012-06-20 19:10:34

[lukeis]

Just to share some light, that's what we are currently using in our temporary profiles
to "avoid" those issues:

        // Loosening Cross-Domain security Checks in Firefox
        // Selenium Issue: http://code.google.com/p/selenium/issues/detail?id=2863
        setPreference("capability.policy.default.HTMLDocument.readyState","allAccess");
        setPreference("capability.policy.default.HTMLDocument.compatMode","allAccess");
        setPreference("capability.policy.default.Document.compatMode","allAccess");
        setPreference("capability.policy.default.Location.href","allAccess");
        setPreference("capability.policy.default.Window.pageXOffset","allAccess");
        setPreference("capability.policy.default.Window.pageYOffset","allAccess");
        setPreference("capability.policy.default.Window.frameElement","allAccess");
        setPreference("capability.policy.default.Window.frameElement.get","allAccess");
        setPreference("capability.policy.default.Window.QueryInterface","allAccess");
        setPreference("capability.policy.default.Window.mozInnerScreenY","allAccess");
        setPreference("capability.policy.default.Window.mozInnerScreenX","allAccess");

Why so many? We don't control which test we run: our service leaves the customer free
to write it's own selenium/webdriver tests. Hence, we are hitting all sort of Permission
issues, not just the "few" we saw before.

I thought it was "good neighbourhood-hood" too share :)

Reported by detronizator on 2012-06-20 20:31:27

[lukeis]

I'm also seeing this in Firefox Selenium IDE 1.8.1
[error] isNewPageLoaded found an old pageLoadError: Error: Permission denied for <http://www.facebook.com>
to get property Location.href
[error] Permission denied for <http://www.facebook.com> to get property Location.href

This occurs when running the open page action where the page has the following declared
in the html element.

<!DOCTYPE HTML>
<html gecko="helper"  xmlns:og="http://opengraphprotocol.org/schema/"
      xmlns:fb="http://www.facebook.com/2008/fbml" >

Reported by bugtank on 2012-06-27 12:08:22

[lukeis]

@mihai.poplacenel

Mihai, thank you for reporting this issue but commenting the way you have is not constructive.
Since Selenium is a volunteer project we do what we can when the core team have time.
If you can help narrow down the regression, which needs to be done on Firefox and Selenium,
that would be really helpful and someone with your experience should find the task
rather trivial.

Reported by david.burns@theautomatedtester.co.uk on 2012-06-28 17:27:59

[lukeis]

@mihai: glad to help. Trust me: the firefox driver people are well aware of
what's happening. ButI guess the workaround is easy enough that they prefer
to focus on shipping the next firefox driver that shouldn't have those
issues.

Reported by detronizator on 2012-06-28 20:57:43

[lukeis]

Sorry for the non-constructive comment - I deleted it and I'm trying to start over in
a  constructive way. I meant to suggest that someone from the Selenium WebDriver team
summarizes what the workarounds are for the various environments and updates the forums.
It is difficult for someone to get around this, and it seems like a long-standing issue
and still present in latest-n-greatest (Firefox 13 with Selenium 2.24.1). I will try
to help you with a reproducible if I manage to get it out to the public domain.

Thanks to all the folks who helped with this issue, and to the Selenium WebDriver team
who put together a great and very useful product. 

Reported by mihai.poplacenel on 2012-06-28 20:58:59

[lukeis]

mihai,

This bug is inside Firefox, and we suspect due to a security model change inside Firefox.
 We have escalated to Engineers at Mozilla, who are working on tracking down exactly
what happened, and fixing it.

In comment 47, I gave a workaround for this problem, as well as the drawbacks you'll
suffer from doing so, and an explanation as to why we are not implementing the workaround
inside selenium.

In the comments following, others have expanded on the workaround, and I have tried
to help people with specific problems.

In comment 55, detronizator gave a fairly thorough workaround.

Unfortunately, there is no way for me to draw particular attention to these workarounds,
e.g. I can't edit the original bug report message.

I have changed the title of this bug report to point people at the workarounds.

I am going to close this bug to comments; we understand where the problem here lies,
it's not inside selenium, we're blocked on changes or debugging inside firefox by mozilla
to get it fixed, and a workaround has been published.  We do not need any reproduction
cases (I never thought I'd say that on a selenium bug!) If anyone has any particular
insights in to the problem which may help, please email selenium-developers@googlegroups.com,
but if you can't point at the firefox revision which caused the problem, you probably
don't have the right insight.

To reiterate, if you are seeing this problem, you can work around it by:
1) Looking at the exception you get, which should contain text like "Permission denied
... to get property Window.frameElement
2) Adding to your FirefoxProfile the preference:
capability.policy.default.Window.frameElement.get='allAccess', or something like it
depending on exactly what property/method/thing access is being denied to.
3) Iterating, adding more preferences as you encounter more problems.
Comment 55 has a fairly thorough set of preferences to set.

Note that by doing so, your tests will no longer detect bugs where the browser prevents
cross-origin frame access from javascript.

Reported by dawagner on 2012-06-28 22:27:57

• Labels added: Restrict-AddIssueComment-Commit

[lukeis]

Reported by dawagner on 2012-06-28 22:29:14

[lukeis]

Regression range has been found in http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a627b24e684e&tochange=cef1817c3b13
and have emailed the relevant people

Reported by david.burns@theautomatedtester.co.uk on 2012-06-29 15:18:13

[lukeis]

This is now working in the release branch of Firefox. The cause was never found but
obviously was a regression for something else. Closing this bug now.

Reported by david.burns@theautomatedtester.co.uk on 2012-08-29 09:49:23

• Status changed: Fixed

[lukeis]

Issue 4487 has been merged into this issue.

Reported by barancev on 2012-09-27 19:20:38