./mach webapprt-test-chrome no longer works on OSX due to v2 signature changes

RESOLVED FIXED in Firefox 34

Status

Testing
General
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: spohl, Assigned: spohl)

Tracking

unspecified
mozilla35
All
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox34 fixed, firefox35 fixed)

Details

Attachments

(3 attachments)

(Assignee)

Description

3 years ago
As stated in summary.
(Assignee)

Comment 1

3 years ago
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)
(Assignee)

Comment 2

3 years ago
Created attachment 8498210 [details]
Output before any v2 signing changes.
(Assignee)

Comment 3

3 years ago
Created attachment 8498211 [details]
Output after v2 signing changes and this patch applied.
(Assignee)

Comment 4

3 years ago
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?
Flags: needinfo?(mar.castelluccio)
(Assignee)

Comment 5

3 years ago
(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.
Blocks: 899707
Flags: needinfo?(mar.castelluccio)
(Assignee)

Comment 7

3 years ago
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+
(Assignee)

Comment 9

3 years ago
https://hg.mozilla.org/projects/oak/rev/2444de3042c1

Waiting for inbound and/or fx-team to reopen to land there.
https://hg.mozilla.org/mozilla-central/rev/c772f124fed2
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.