Here is a test: http://jsfiddle.net/zalun/VkCyH/ (for some reason installation on device is working only from http://jsfiddle.net/zalun/VkCyH/embedded/result) This code passes on Firefox installed on the computer, but throws Security Error on Firefox OS either it is Simulator or device.

I can't get the attached test case working - I'm not seeing alerts fire. Can you attach a direct HTML test case here?

I have just installed it in simulator and only the "pre" alert worked.

You may provide this webapp URL instead of clicking Install - http://jsfiddle.net/zalun/VkCyH/manifest.webapp

Here's what I see when I connect to that app via Simulator 4.0. Accessing the navigator keys throws a security error.

CCing Lucas et al, who may be able to shed light on this. Thanks in advance!

Also raising severity here: This is blocking PhoneGap/Cordova integration.

Jonas, do you know why we might restrict access to window.navigator in B2G? I don't recall any such restrictions being discussed.

So I'm seeing the error: 07-17 11:37:52.011: E/GeckoConsole(815): [JavaScript Error: "SecurityError: The operation is insecure." {file: "http://jsfiddle.net/zalun/VkCyH/app.html" line: 33}] We need a reduced test case to identify what is failing in the navigator.

So the reduced test case here doesn't end up hitting any errors in progress on inspecting the navigator's properties.

Is this a recent regression? Currently we throw if we don't have the settings permission but we want to access navigator.mozSettings. This landed yesterday and Reuben will land a fix asap.

Bug 894964 has a patch, duping.

This was caused by bug 889503, in which we started throwing during initialization of the navigator property when the page does not have the necessary permissions.

Are you sure bug 894335 is a dupe of this bug? bug 894335 reproduces on b2g18, which the associated regressing bug has not landed on b2g18.

(In reply to Jason Smith [:jsmith] from comment #17) > Are you sure bug 894335 is a dupe of this bug? bug 894335 reproduces on > b2g18, which the associated regressing bug has not landed on b2g18. Meant to say are you sure this is a dupe of bug 894964.

(In reply to Jason Smith [:jsmith] from comment #17) > Are you sure bug 894335 is a dupe of this bug? bug 894335 reproduces on > b2g18, which the associated regressing bug has not landed on b2g18. I know for sure that bug 894964 will cause this test case to fail, but mozSettings might be the only property doing funny things here. If this reproduces in b2g18, it's not just bug 894964.

Narrowed this down a bit - this won't reproduce if you do a navigator dump in the browser, but it does reproduce in a hosted app. Here's a slightly reduced test case on my github: 1. Install Hosted App Test Case 1 on http://jds2501.github.io/webapi-permissions-tests/ 2. Launch app 3. Select navigator dump link

Just installed example from jsfiddle on keon with nightly b2g build and it shows both alerts. I also installed above "Hosted App Test Case 1" and it worked fine without throwing SecurityError. I consider this fixed. Please reopen if there is still an issue

Works for me if a patch isn't present.

Bug 838146 probably fixed a few problems here. However that bug hasn't, and likely won't, land on the b2g18 branch. Has anyone tested how we behave in v1.1 builds? And no, I don't think there is any intentional throwing happening here. Simply the fact that iterating all properties will mean trying to read them, which we probably made throw some places. Instead we should simply return null or undefined or some such for simplicity. In v1.2 the properties won't be there at all if you can't access them.

leo? from email - this blocks partner work. I'll follow up and leo+ if appropriate. Also reopening. I know this isn't perfect engineering procedure, but Resolved bugs don't ever get attention. Who wants this bug?

(In reply to Alex Keybl [:akeybl] from comment #24) > leo? from email - this blocks partner work. I'll follow up and leo+ if > appropriate. > > Also reopening. I know this isn't perfect engineering procedure, but > Resolved bugs don't ever get attention. > > Who wants this bug? Already opened up a new bug here to avoid confusion on this.