As stated in summary.
Created attachment 8498208 [details] [diff] [review] Patch I must say that I'm shocked that NSBundle's pathForAuxiliaryExecutable ever worked, but this is due to the fact that OSX will treat any folder under Contents/MacOS as an application bundle. In this case, it was able to successfully retrieve the webapprt folder even though it's not actually an application bundle. Now that the webapprt folder is in it's correct place (Contents/Resources), NSBundle's pathForResource will do the right thing.
Attachment #8498208 - Flags: review?(myk)
Although the patch is seemingly doing the right thing, I'm seeing something odd between a run before any of the v2 signing stuff landed (local build compiled off of m-c cset 20c7e70e1b1a) and after the v2 signing changes with the patch here applied: We seem to crash pretty quickly in the build before the v2 signing stuff (see attachment 8498210 [details]). However, with the v2 signing stuff landed and the patch here applied, we no longer crash but end up with two test failures (browser_mozpay.js and browser_webperm.js). I would have expected the two runs to be virtually identical. Marco, does this seem right to you? Were there webapprt fixes that landed after the v2 signing patches?
(In reply to Stephen Pohl [:spohl] from comment #4) > However, with the v2 signing stuff landed and the patch here applied, we > no longer crash but end up with two test failures (browser_mozpay.js and > browser_webperm.js). ... see attachment 8498211 [details] for this run.
During the last few weeks, there have been three regressions (four, if you include the regression from the v2 signing changes). 1) All tests started to time out (this is what you're seeing now in attachment 8498210 [details], probably the harness caused the crash). 2) browser_mozpay.js started to (intermittently?) fail 3) browser_webperm.js started to consistently fail (bug 1073790) The patch that fixed (1), in bug 1072798, has probably landed at the same time as your patch for the v2 signing changes.
Great! Sounds like the patch in this bug is still the right one then. Thanks for the confirmation!
Comment on attachment 8498208 [details] [diff] [review] Patch Looks good, r=myk.
Attachment #8498208 - Flags: review?(myk) → review+
https://hg.mozilla.org/projects/oak/rev/2444de3042c1 Waiting for inbound and/or fx-team to reopen to land there.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Landed on aurora in the Mac V2 signing combined patch in bug 1047584
status-firefox34: --- → fixed
status-firefox35: --- → fixed
You need to log in before you can comment on or make changes to this bug.