The extractHrefs method is used to retrieve hrefs from components before passing it
SearchSERPTelemetry to store for future use when observer activity in the network process.
Javascript URLs are uncommon but can accidentally be extracted, especially if a topDown
search for elements is used. No test is added because the presence of the element in an
categorized component will break existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D203957
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
When enough users have transitioned to this version, we can update search-telemetry-v2 that
uses the new topDown features, and can delete the old interface.
Differential Revision: https://phabricator.services.mozilla.com/D202039
To allow the use of strings in Remote Settings to add conditions to the events, we pass expressions
that will be evaluated by the FilterExpression component. We pass the event details and some of
the params of the function that might be useful in the future.
Differential Revision: https://phabricator.services.mozilla.com/D202038
Previously, the only the way elements could add event listeners was using the related keyword.
This is too limiting, so this will allow parent and child elements to use the eventListeners
array to list events they want to listen for, the action that should be reported, and the target.
If no target is provided, the component type will be used. If no action is provided and the
event is click, the default action, clicked, will be used.
Differential Revision: https://phabricator.services.mozilla.com/D202037
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
Adds a flag that allows top down searches for elements to not report the number found back
to the ad_impression event. In later patches, this will allow us to add event listeners to
elements separately from other queries that might better answer the number of components
on the page. Additionally, we may want to add event listeners without reporting the
element in ad_impression, e.g. search boxes.
Differential Revision: https://phabricator.services.mozilla.com/D202035
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
Since we rely on the child process to parse this information, we need to
wait until the child has reported the presence of the shopping page
before sending the Impression event.
Differential Revision: https://phabricator.services.mozilla.com/D175576
