Skip to content

Conversation

lmarceau
Copy link
Contributor

@lmarceau lmarceau commented Sep 4, 2025

📜 Tickets

Jira ticket
Github issue

💡 Description

  • We got a request to migrate the fx-suggest to OHTTP through Glean. This can be done in the yaml file definition directly, since we now have the ohttp capability.
  • Created a FxSuggestTelemetry class that handles the Firefox suggest telemetry (so it's not passed into the TelemetryWrapper anymore).
  • We're also adding the country as part of that ping because we currently use the IP address to infer the geo on the backend, so when the IP address goes away (by routing the request over OHTTP) we need to pass the geo explicitly. I am using the same Locale code to get the regionCode 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.
  • Remove the feature flag .ohttpManagerGleanUploader as it won't be possible to have the ping sent through http or ohttp 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 from main
  • Adding a Locale extension to DRY the code as suggest here.
  • Removed [email protected] from the yaml files since that person is not at mozilla anymore

📝 Checklist

  • I filled in the ticket numbers and a description of my work
  • I updated the PR name to follow our PR naming guidelines
  • I ensured unit tests pass and wrote tests for new code
  • If working on UI, I checked and implemented accessibility (Dynamic Text and VoiceOver)
  • If adding telemetry, I read the data stewardship requirements and will request a data review
  • If needed, I updated documentation and added comments to complex code
  • If needed, I added a backport comment (example @Mergifyio backport release/v150.0)

@mobiletest-ci-bot
Copy link

mobiletest-ci-bot commented Sep 4, 2025

Messages
📖 Project coverage: 38.67%
📖 Edited 14 files
📖 Created 4 files

Client.app: Coverage: 36.92

File Coverage
BrowserViewController.swift 29.49% ⚠️
FeatureFlagsDebugViewController.swift 0.0% ⚠️
ASSearchEngineProvider.swift 0.0% ⚠️
NimbusFlaggableFeature.swift 95.38%
SponsoredTileTelemetry.swift 90.48%
FxSuggestTelemetry.swift 94.34%
NimbusFeatureFlagLayer.swift 82.13%
TelemetryWrapper.swift 68.44%
GleanWrapper.swift 73.53%
Locale+Extension.swift 63.64%

Generated by 🚫 Danger Swift against df70419

@lmarceau
Copy link
Contributor Author

lmarceau commented Sep 4, 2025

Started a TestFlight build #60974

Copy link
Collaborator

@ih-codes ih-codes left a 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
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member

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.

@lmarceau lmarceau force-pushed the lm/FXIOS-12358-#26928-fx-suggest-ping branch from b4194bc to 920c807 Compare September 10, 2025 01:35
@lmarceau lmarceau changed the title [WIP] Refactor FXIOS-12358 #26928 [Ohttp FxSuggest ping] fx suggest ping sent through ohttp Refactor FXIOS-12358 #26928 [Ohttp FxSuggest ping] fx suggest ping sent through ohttp Sep 10, 2025
@lmarceau lmarceau marked this pull request as ready for review September 10, 2025 13:56
@lmarceau lmarceau requested a review from a team as a code owner September 10, 2025 13:56
@lmarceau
Copy link
Contributor Author

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 👀

@lmarceau lmarceau requested a review from ih-codes September 10, 2025 13:57
Copy link
Collaborator

@ih-codes ih-codes left a 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:

Screenshot 2025-09-10 at 11 15 32 AM

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
Copy link
Collaborator

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. 👀

Screenshot 2025-09-10 at 9 55 19 AM

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. 😅

Copy link
Contributor Author

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?

Copy link
Collaborator

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)

Comment on lines 28 to 32
guard let contextIdString = TelemetryContextualIdentifier.contextId,
let contextId = UUID(uuidString: contextIdString) else {
return
}
Copy link
Collaborator

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.

Copy link
Contributor Author

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

Copy link
Collaborator

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.

@lmarceau
Copy link
Contributor Author

Question:

When testing, is it expected behaviour to record searchResultImpression with extra "wikipedia-suggestion" for tapping on a suggested tab? (Not a wikipedia result).

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

@lmarceau lmarceau requested a review from ih-codes September 10, 2025 19:59
@ih-codes
Copy link
Collaborator

Question:
When testing, is it expected behaviour to record searchResultImpression with extra "wikipedia-suggestion" for tapping on a suggested tab? (Not a wikipedia result).

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? 🤔

Copy link
Collaborator

@ih-codes ih-codes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@lmarceau lmarceau force-pushed the lm/FXIOS-12358-#26928-fx-suggest-ping branch from 36d3261 to df70419 Compare September 10, 2025 23:51
@lmarceau lmarceau merged commit 8dba04b into main Sep 11, 2025
11 checks passed
@lmarceau lmarceau deleted the lm/FXIOS-12358-#26928-fx-suggest-ping branch September 11, 2025 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants