When turning the feature gating pref on and running tests, it revealed one oversight:
When test files are run and we reset telemetry, we don't properly unload the internal
state of CategorizationRecorder. Doing so means that we can keep the "threshold" variable
in a non-zero state despite reseting all telemetry, which can cause submit() to fire when
we don't expect it.
Differential Revision: https://phabricator.services.mozilla.com/D205507
Fundamentally, there shouldn't be any differences in functionality. I removed the
unit test since it was covered by the browser test and added a couple scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D203706
On top of making the conversion, instead of using raw values in the test which can be hard
to parse when making changes, I converted the raw values back to domains and then use a helper
to convert it before passing it to the Map. I also removed the external files and stored the
values inside either head.js or within the test.
Differential Revision: https://phabricator.services.mozilla.com/D203226
In rare cases, we may need to add event listeners in the content process which also trigger
a network event that would be parsed by the network observer. To avoid counting double
engagements, I propose we add a new array of regular expressions that when a URL matches, will
never be parsed by the SERP telemetry logic in the network observer. This would rely on the
content process events listeners to register the engagement event.
I think the regular expression should be specific enough that it shouldn't match something
in a search result lest we ignore a click on it.
Differential Revision: https://phabricator.services.mozilla.com/D202583
Largely non-functional changes:
- The pagehide callback can live in the top level pagehide event.
- Moving the submitted check into the callback will make it easier to refactor
the helper that adds event listeners.
- Changing the callbacks to use target as the name will make it easier to
remember that the target is potentially overwritable.
- waitForPageWithAction can be used in future tests.
Differential Revision: https://phabricator.services.mozilla.com/D202036
updateTrackingSinglePageApp() contains the core logic for when we observe same document loads.
Based on conditions, it may record telemetry (engagement/abandonment), and dispatch events
to the appropriate SearchSERPTelemetry actor.
SearchSERPTelemetryChild had to be modified to allow for manual dispatching of events, especially
unloading event listeners in the case where a user navigates to a non-default search page, like
Images or Shopping.
One complication in observing clicks is we're storing search pages based on the URL at the time
of load, and then looking them up again using the originURL, but it might be different from
the currentURL due to the way single page apps work. So this could cause confusion if multiple SERPs
are open and different from their originURL, hence the usage of recovering the correct state map by
first using the browser object and defaulting back to the originURL if the WeakMap doesn't
contain any of the browser objects.
I also created a mock SPA html file that when given a search query parameter, shows mock results.
The helper file head-spa.js contains a class that navigates the pages in tests.
The tests are broken out into the following:
- When a single search provider is opened in a single tab
- When a single search provider is has multiple tabs open
- When multiple providers are open at the same time
- Event listeners on in-content elements are unloaded properly when navigating away from the page
Differential Revision: https://phabricator.services.mozilla.com/D193320
updateTrackingSinglePageApp() contains the core logic for when we observe same document loads.
Based on conditions, it may record telemetry (engagement/abandonment), and dispatch events
to the appropriate SearchSERPTelemetry actor.
SearchSERPTelemetryChild had to be modified to allow for manual dispatching of events, especially
unloading event listeners in the case where a user navigates to a non-default search page, like
Images or Shopping.
One complication in observing clicks is we're storing search pages based on the URL at the time
of load, and then looking them up again using the originURL, but it might be different from
the currentURL due to the way single page apps work. So this could cause confusion if multiple SERPs
are open and different from their originURL, hence the usage of recovering the correct state map by
first using the browser object and defaulting back to the originURL if the WeakMap doesn't
contain any of the browser objects.
I also created a mock SPA html file that when given a search query parameter, shows mock results.
The helper file head-spa.js contains a class that navigates the pages in tests.
The tests are broken out into the following:
- When a single search provider is opened in a single tab
- When a single search provider is has multiple tabs open
- When multiple providers are open at the same time
- Event listeners on in-content elements are unloaded properly when navigating away from the page
Differential Revision: https://phabricator.services.mozilla.com/D193320
