-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Refactor FXIOS-12358 #26928 [Ohttp FxSuggest ping] fx suggest ping sent through ohttp #29166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Client.app: Coverage: 36.92
Generated by 🚫 Danger Swift against df70419 |
Started a TestFlight build #60974 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I quickly scanned the telemetry portion, I'm happy to see it pulled into its own type (yay!). Looks good to me at first glance. You mentioned you wanted to look at unit testing for this, so let's chat at our 1:1 next week. 👍
@@ -50,13 +50,15 @@ fx-suggest: | |||
Distinguishable by its `ping_type`. | |||
Does not contain a `client_id`, preferring a `context_id` instead. | |||
include_client_id: false | |||
uploader_capabilities: | |||
- ohttp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this ping contains client info data as it does NOT have metadata.include_info_sections: false
.
That potentially allows it to be connected back to regular telemetry.
If we can't have that we will need a new ping name, as switching a ping to include_info_sections: false
will not work in the pipeline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @badboy is correct, removing the info sections as required for ohttp pings would fail schema validation on ingestion if we keep the same name, and removing fingerprintable data like the info sections is an important part of anonymizing the data we collect over OHTTP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@badboy this ping has include_client_id: false
so IIUC SDK won't submit client_id
?
This is similar to https://github.com/mozilla-firefox/firefox/blob/4a1256a814d330833bb9ff484f069ec65f070969/mobile/android/fenix/app/pings.yaml#L116-L123 which does not have client_id
populated in BQ.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the point was that with the info-sections the possibility of fingerprinting is fairly high, yet. But if this has been okayed with the info sections attached, then we will not block this landing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. If it's ok that the rest of client_info is included then this is fine.
If it's not we have to rename the ping.
b4194bc
to
920c807
Compare
I tested with the Debug Ping Viewer and all looks good to me. Here's the link. I declare this PR to be ready for review 👀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some thoughts for you, nothing jumped out at me overall! Great work! 😁
Looks like the telemetry eng folks had some good feedback for your consideration as well (passing client IDs).
Question:
When testing, is it expected behaviour to record searchResultImpression
with extra "wikipedia-suggestion"
for tapping on a suggested tab? (Not a wikipedia result). For example, switching to this standardebooks.org tab:

This also fires the fxSuggest ping as well for Wikipedia... 🤔
Anyway I tested in the sim with the Glean debugger and otherwise I think things look good. (I haven't been able to force a sponsored suggestion though to test the .amp
cases yet though.)
P.S. For QA it might also be useful to note that the fx suggest ping should maintain exactly the same behaviour as before (besides the differences you've already noted on the ticket). Just so they can test before/after too. Maybe that's obvious from the context but I like to be explicit. 😆 Also, just FYI the ping examples you added for them will just live for about 30 days IIRC.
@@ -0,0 +1,15 @@ | |||
// This Source Code Form is subject to the terms of the Mozilla Public |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI I found that we already have this other localeRegionCode
implemented on a separate Locale
extension. 👀

Looks like it was added last December by @OrlaM for the DMA work. The one you grabbed from @mattreaganmozilla's SEC code seems to have more sophisticated logic for iOS version. I would like to suggest removing one but I also don't know why there's nuance here and don't want to break anything. 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I grabbed the one from SEC since it made sense to have the same region code in the different area of the app, particularly if it relates to search engine, and telemetry is in the search bar it just made sense to me to have the same region code. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep I think that makes sense! 👍
I would like to remove the other method vs. having 2 methods that are supposed to do the same thing, but I don't have enough context around the DMA work to feel confident suggesting a change. (Feel free to ignore me as this is outside the scope of your PR haha)
guard let contextIdString = TelemetryContextualIdentifier.contextId, | ||
let contextId = UUID(uuidString: contextIdString) else { | ||
return | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure the likelihood of error here, is this something we should log a warning for, or add an assertion? 🤔 Might be good to put an assertionFailure for these because the setupContextId code might get moved out of the TelemetryWrapper later...
Side note, TelemetryContextualIdentifier.setupContextId()
is called in the TelemetryWrapper init, as well as one place under certain conditions in AppLaunchUtil. 🤔 I wonder if there's a more reliable place we can ensure this is set properly? (If we're relying on the TelemetryWrapper init specifically)
Unrelated: it's a bit sketchy to me because of the order of those 2 setupContextId()
calls. Even if you pass false
to setupContextId()
later, GleanMetrics.TopSites.contextId
is never unset.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can put an assertion in case. As for the rest, there is some work for the context id that was started by Carson here but it got stale. This area needs improvement. The TelemetryContextualIdentifier.setupContextId()
under AppLaunchUtil
was added as a patch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh interesting. 👀 Thanks for the info! I hope the FXIOS-12301 ticket for this work can clean this up a bit.
firefox-ios/firefox-ios-tests/Tests/ClientTests/Telemetry/FxSuggestTelemetryTests.swift
Show resolved
Hide resolved
I am using the same code as it was before, so this seems fine to the extent of my knowledge 😆 As long as I didn't make a copy paste error/mismatch I assume the previous code for those events makes sense and is triggered properly |
Seems reasonable, I kinda figured this was the same code. I wonder if we need to file a bug ticket for this, as it seems a bit weird........ Any idea who we can ask about expected behaviour here? 🤔 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
…mebar.searchResultImpression are recorded
36d3261
to
df70419
Compare
📜 Tickets
Jira ticket
Github issue
💡 Description
fx-suggest
toOHTTP
through Glean. This can be done in theyaml
file definition directly, since we now have the ohttp capability.FxSuggestTelemetry
class that handles the Firefox suggest telemetry (so it's not passed into theTelemetryWrapper
anymore).Locale
code to get theregionCode
as used in the new search engine provider code (added in Add FXIOS-11351 [SEC] [WIP] Initial groundwork for Consolidated Search #25335). Created an extension to DRY the code as suggested in here..ohttpManagerGleanUploader
as it won't be possible to have the ping sent throughhttp
orohttp
with a code toggle. Feature flag is still useful as it's merged in main and won't affect any release that is cut-off frommain
Locale
extension to DRY the code as suggest here.[email protected]
from theyaml
files since that person is not at mozilla anymore📝 Checklist
@Mergifyio backport release/v150.0
)