1252207 - [e10s] test_bug406541.html fails on OSX 10.10 (Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.createUnique] at chrome://specialpowers/content/specialpowersAPI.js)

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Maybe a sandboxing issue or something?

https://treeherder.mozilla.org/logviewer.html#?job_id=17298252&repo=try

 16:52:20     INFO -  135 INFO TEST-START | dom/plugins/test/mochitest/test_bug406541.html
 16:52:20     INFO -  TEST-INFO | started process screencapture
 16:52:20     INFO -  TEST-INFO | screencapture: exit 0
 16:52:20     INFO -  136 INFO TEST-UNEXPECTED-FAIL | dom/plugins/test/mochitest/test_bug406541.html | uncaught exception - NS_ERROR_FILE_ACCESS_DENIED: Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.createUnique] at chrome://specialpowers/content/specialpowersAPI.js:143
 16:52:20     INFO -      simpletestOnerror@SimpleTest/SimpleTest.js:1543:11
 16:52:20     INFO -      OnErrorEventHandlerNonNull*@SimpleTest/SimpleTest.js:1530:1
 16:52:20     INFO -  JavaScript error: chrome://specialpowers/content/specialpowersAPI.js, line 143: NS_ERROR_FILE_ACCESS_DENIED: Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.createUnique]
 16:52:20     INFO -  MEMORY STAT | vsize 3082MB | residentFast 127MB | heapAllocated 17MB
16:52:20 INFO - 137 INFO TEST-OK | dom/plugins/test/mochitest/test_bug406541.html | took 59ms

Comment 1

[Benjamin Smedberg]

Does this pass on windows?

The proximate cause here is in fact sandboxing. I don't know why the Windows sandbox doesn't prevent this file access, so I'm NI?bobowen. This test should be fixed by moving the filesystem writing bits to the chrome process. I don't know the best way to do that: felipe can you provide some mentoring/guidance on that?

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Yes, this passes on Windows and Linux.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

MattN is just adding a helper in his e10s-fication of passwd manager tests to let a mochitest-plain test run a snippet of code in the parent through SpecialPowers. It would probably be very useful here. Let me find some extra info.

Comment 4

[Bob Owen (:bobowen) PTO until 8th Oct]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Does this pass on windows?
> 
> The proximate cause here is in fact sandboxing. I don't know why the Windows
> sandbox doesn't prevent this file access, so I'm NI?bobowen. This test
> should be fixed by moving the filesystem writing bits to the chrome process.
> I don't know the best way to do that: felipe can you provide some
> mentoring/guidance on that?

If this is writing to TmpD then it passes on Windows because we change that to a per profile unique low integrity temp directory.

Haik has just landed something similar for Mac, i.e. a specially created temp dir to which we give write access.
Does it still fail on Mac with latest m-c?

Both of these are deleted on shutdown or start-up if that fails.

Comment 5

[Matthew N. [:MattN]]

See the mention of loadChromeScript at https://wiki.mozilla.org/Electrolysis/e10s_test_tips#Mochitest_.28plain.29 and the mentions of the two bug numbers. See an example at https://reviewboard.mozilla.org/r/36545/diff/3#3

Comment 6

[Ryan VanderMeulen [:RyanVM]]

(In reply to Bob Owen (:bobowen) from comment #4)
> Haik has just landed something similar for Mac, i.e. a specially created
> temp dir to which we give write access.
> Does it still fail on Mac with latest m-c?

It doesn't! \m/

Comment 7

[Firefox Bug Husbandry Bot]

Removing leave-open keyword from resolved bugs, per :sylvestre.