Open Bug 1525076 Opened 10 months ago Updated 9 months ago

The nsIMacAttributionService not returning the referrerURL

Categories

(Firefox :: General, defect, P2)

defect

Tracking

()

Tracking Status
firefox66 - fix-optional
firefox67 --- affected

People

(Reporter: pdehaan, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Ref: https://bugzilla.mozilla.org/show_bug.cgi?id=1511071

Trying to do a complete end-to-end flow using https://gist.github.com/piatra/f0a2b9f9f700cbe19afd2ebf1561e6ee but I'm always getting an empty attributed object when I get to the following line in the steps:

AttributionCode.getAttrDataAsync().then(console.log) // something with content `{EF522540-89F5-46b9-B6FE-1829E2B572C6}`

Testing on macOS Mojave (latest) and High Sierra (latest-1). I asked Benny from my team to also test and he was getting the same results as me.

I was speaking w/ @mixedpuppy this morning and he was suggesting it may be due to a dialog prompting me when I try and run the app from my ~/Downloads/ folder, so I'm trying to verify that, but @ddurst asked me to file an issue.

Flags: needinfo?(ddurst)

Odd, I tested this in Nightly v67 (copying the config from Release v65), and I got the following error in the Browser Scratchpad:

ChromeUtils.import("resource:///modules/AttributionCode.jsm");
ChromeUtils.import("resource://gre/modules/addons/AddonRepository.jsm");

AttributionCode.getAttrDataAsync().then(console.log)

/*
Exception: ReferenceError: AttributionCode is not defined
@Scratchpad/1:4:1
getEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:134:18
exports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:105:18
evaluateJS@resource://devtools/server/actors/webconsole.js:1005:22
evaluateJSAsync@resource://devtools/server/actors/webconsole.js:910:22
onPacket@resource://devtools/server/main.js:1279:15
send/<@resource://devtools/shared/transport/local-transport.js:64:11
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:14
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:14
*/

Here's a simple script to set the attribution on a downloaded app. https://pastebin.com/kWZ3DhdZ

Starting from a shell[1] everything works, starting from Finder (or using "open Firefox.app" in shell) it doesn't.

[1] path/to/Firefox.app/Contents/MacOS/firefox-bin -P profile

just want to confirm - that the failure on OSX is a graceful one. So if source attribution isn't returning information on OSX, the user just sees the default onboarding experience. That would be a silent failure - nothing user visible.

(In reply to :shell escalante from comment #3)

just want to confirm - that the failure on OSX is a graceful one. So if source attribution isn't returning information on OSX, the user just sees the default onboarding experience. That would be a silent failure - nothing user visible.

A very graceful fiery ball is flung through the screen at the user. It's basically silent, things will continue working as there is nothing to see.

OK, I think I got a bit closer... I downloaded Firefox 65 and ran the new script (and verified the attributes were copied from the new script):

$ ./showattrs.sh feb-03/Firefox65.app
$ ./showattrs_old.sh feb-03/Firefox65.app
054B329B-8F38-473A-8DD9-7AEFFA5DD2E8|570995305.0|org.mozilla.nightly|Nightly|http://dummy.com/file.zip|||0||https://www.mozilla.org/en-US/firefox/download/thanks/?utm_campaign=non-fx-button&utm_content=%7BEF522540-89F5-46b9-B6FE-1829E2B572C6%7D&utm_medium=referral&utm_source=addons.mozilla.org|

Running the following in the Scratchpad (Browser context) gives me some output:

ChromeUtils.import("resource:///modules/AttributionCode.jsm");
ChromeUtils.import("resource://gre/modules/addons/AddonRepository.jsm");

AttributionCode.getAttrDataAsync().then(console.log)

/*
Object {
  source: "addons.mozilla.org",
  medium: "referral",
  campaign: "non-fx-button",
  content: "{EF522540-89F5-46b9-B6FE-1829E2B572C6}"
}
*/

I'm still not seeing any add-ons preinstalled in about:addons.

I'll test in Firefox 66 and see if I get the same results.

(In reply to Peter deHaan [:pdehaan] from comment #5)

Running the following in the Scratchpad (Browser context) gives me some output:

Ok, you're getting the attribution data there.

How are you starting firefox when you get data?

I'm still not seeing any add-ons preinstalled in about:addons.

That would be a different problem than this bug.

Same results w/ FF66 (DevEdition). See attached screenshot.

I'm running the FF65 and FF66 via the CLI, like you suggested:

$ ./feb-03/Firefox66.app/Contents/MacOS/firefox-bin -P profile66

Where that seems to display the profile manager at launch, then I create a new profile and then check about:addons.

(In reply to Peter deHaan [:pdehaan] from comment #8)

I'm running the FF65 and FF66 via the CLI, like you suggested:

Ok. That is expected to work at this point. This bug is basically that it doesn't work if you start normally as a user would.

I've been trying to reproduce this with a local build, but I keep getting "Exception: ReferenceError: AttributionCode is not defined" no matter how I start Firefox. Is there anything I'm missing to get this working with a local build? I would assume that AttributionCode would always be defined, even if no attributes are present.

Flags: needinfo?(mixedpuppy)
Blocks: 1468680

(In reply to Stephen A Pohl [:spohl] from comment #10)

I've been trying to reproduce this with a local build, but I keep getting "Exception: ReferenceError: AttributionCode is not defined" no matter how I start Firefox. Is there anything I'm missing to get this working with a local build? I would assume that AttributionCode would always be defined, even if no attributes are present.

I've no idea on this. Are you testing a scratchpad script? Is it in browser environment?

Flags: needinfo?(mixedpuppy)

(In reply to Shane Caraveo (:mixedpuppy) from comment #11)

(In reply to Stephen A Pohl [:spohl] from comment #10)

I've been trying to reproduce this with a local build, but I keep getting "Exception: ReferenceError: AttributionCode is not defined" no matter how I start Firefox. Is there anything I'm missing to get this working with a local build? I would assume that AttributionCode would always be defined, even if no attributes are present.

I've no idea on this. Are you testing a scratchpad script? Is it in browser environment?

Yes (scratchpad script from comment 5) and yes (browser context). I was going to look into this to figure out what might be going on here, but at this point I can't even get to the point outlined in comment 5.

From David's comments in Trello it sounds to me like this may not block the feature rollout (even to Mac users). So, the Return to AMO feature may not work for Mac users but will not do anything negative, either, is that correct?

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #13)

From David's comments in Trello it sounds to me like this may not block the feature rollout (even to Mac users). So, the Return to AMO feature may not work for Mac users but will not do anything negative, either, is that correct?

correct.

I have a WIP E2E test plan at https://github.com/pdehaan/return-to-amo-e2e-test which covers downloading Firefox Nightly (v67) and using mixedpuppy's https://pastebin.com/kWZ3DhdZ script to copy attributes and then launch Firefox Nightly. I'm not seeing the about:welcome page open in the new profile, but if I open about:welcome in a new tab it will prompt me to install the SearchPreview add-on. :+1:

No need for me to track this if it isn't blocking the feature release and has no negative effect on users.

Flags: needinfo?(ddurst)
See Also: → 1511071

QA notes that this issue still blocks some of their end-to-end testing.

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #17)

QA notes that this issue still blocks some of their end-to-end testing.

Why are they testing OSX at this point?

Flags: needinfo?(lhenry)

Ah, maybe this one isn't relevant and they were referring to bug 1511071, which is about testing Windows.

Flags: needinfo?(lhenry)
Component: Activity Streams: Newtab → Installer

Bug 1344771 landed in ::General, so moving there ?

Component: Installer → General
Depends on: 1344771

Can somebody assign a priority to this bug please?

David and Shane, there still seems to be confusion here. If this isn't relevant, should we close the bug, give it a P5 or something, or can you explain further to QA that they don't need to test on MacOS? That was my understanding.

Flags: needinfo?(ddurst)
Priority: -- → P2

This is not a blocker for RTAMO and there is no plan to fix it for 66/67. We do want to fix it if possible.

Flags: needinfo?(ddurst)
You need to log in before you can comment on or make changes to this bug.