1842866 - Clicking on an ad link records an error in the browser console search logs

Status: NEW

(Firefox :: Search, defect, P3)

Description

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Notes

• Intermittent to a degree; error does not necessarily appear on a first try.
• Does not reproduce with Google set as the default search engine.

Found in

• 116.0b3;

Affected versions

• 117.0a1;
• 116.0b3;

Tested platforms

• macOS 12;
• Windows 10;
• Ubuntu 22;

Affected platforms

• macOS 12;
• Windows 10;
• Ubuntu 22;

Unaffected platforms

• N/A;

Preconditions

• browser.search.log = true
• browser.search.serpEventTelemetry.enabled = true
• Have BING as the default search engine.

Steps to reproduce

1. Launch Firefox with the profile from preconditions.
2. Open the browser console.
3. Focus the address bar and perform a search that generates ads (e.g. buy shoes, buy phone).
4. Once the SERP is loaded, click on an ad link.
5. Check the browser console.

Expected result

• “Click” event is recorded, no errors are shown in the browser console.

Actual result

• ‘Click’ event is recorded, but the following error is displayed along with the rest of the pings:

TypeError: telemetryState is undefined SearchSERPTelemetry.sys.mjs:1148:9
_reportPageWithAds resource:///modules/SearchSERPTelemetry.sys.mjs:1148
reportPageWithAds resource:///modules/SearchSERPTelemetry.sys.mjs:323
receiveMessage resource:///actors/SearchSERPTelemetryParent.sys.mjs:17

Regression range

• Will look for one as soon as possible.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:oardelean, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[Oana Botisan, Desktop QA]

I tried to find the regression for this issue using several methods. It seems that is intermittent. I could only find irelevent regressors. My quess is that the issue is reproducing since the browser.search.serpEventTelemetry.enabled pref was introduced because the bug is reproducing on Nightly from 2023-03-02.

Comment 3

[James Teow [:jteow]]

Hi Ardelean, I have a couple questions related to when the error is encountered just to help me re-create the issue on my machine:

• Does clicking the ad link open the ad in a new tab or does it change the location of the current tab?
• In the logging for the SERP, did it record a page impression?
• In the logging for the SERP did it record any logs for counting ads for the SERP, e.g. Counting ad: Object { type: "shopping_tab", adsLoaded: 1, adsVisible: 1, adsHidden: 0 }? Or was that error message the only thing you saw related to counting ads on the page.
• What kind of ad was clicked (e.g. carousel? text ad? ad on the right sidebar)?
• Which locale/region was used for the searches?

Comment 4

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hy James, sorry for the late reply!

Does clicking the ad link open the ad in a new tab or does it change the location of the current tab?

Reproducible when the ad link is opened in a new tab. I could not reproduce the error if I set Bing to open search results in the same tab.

In the logging for the SERP, did it record a page impression?

Yes.

In the logging for the SERP did it record any logs for counting ads for the SERP, e.g. Counting ad: Object { type: “shopping_tab”, adsLoaded: 1, adsVisible: 1, adsHidden: 0 }? Or was that error message the only thing you saw related to counting ads on the page.

Logs were recorded for all impression/engagement events that were done.

What kind of ad was clicked (e.g. carousel? text ad? ad on the right sidebar)?

Reproducible with carousel, link, sitelink.

Which locale/region was used for the searches?

US.

Please let me know if there’s anything else I can do to help, thank you.

Comment 5

[James Teow [:jteow]]

Interesting. Is it possible to see either a recording of it or the full logs?

Comment 6

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Attachment: console-export-2023-8-1_15-44-0.txt

Comment 7

[James Teow [:jteow]]

Bing has origin-when-cross-origin on its SERP.

When you click on an ad link that opens a new tab, it loads a page containing Javascript. The Javascript code checks if there is a referrer.

If there is, it'll attempt to use history.replaceState and set the page URL to the referrer.

If it fails (e.g. the referrer is not of the same origin) or there was no referrer, it'll use window.location.replace() to set the location of the page to the target URL and avoid allowing the user to go easily go back to this interstitial page.

However, if the referrer was the SERP, it'll be the full URL (due to origin-when-cross-origin) which include the query params. You'll see the page URL change from the ad link to the SERP URL. It'll then set window.location.href to the target URL, and allow this page to be navigable with the back button, so that from the context from the target URL, the user could go back to the SERP.

Additionally, the markup of the page includes a hidden anchor to the ad URL itself as a fallback for the user in case the Javascript fails. It is only visible if a timeout elapses.

---

When we click on an ad, the browser is stored in SearchSERPTelemetry if the URL found during the onLocationChange event looks like a SERP. Since the original page load was an ad and not a SERP, it won't store the browser. If onLocationChange is called again and the location is the same document, SearchSERPTelemetry won't be updated, hence why we're not tracking the browser even though the URL now looks like a SERP.

The child however looks at all pages with the https scheme and assesses whether or not to find ads based on the page URL. It does so at load, pageshow, and DOMContentLoaded.

After the page loads and we wait 1 second, the location of the page has changed to the SERP URL. The child process thinks its a SERP with ads are on the page (the hidden link) and sends its findings back to SearchSERPTelemetry, which didn't store the browser state because the original URL was an ad link.

I wonder, in SearchSERPTelemetryChild, if the DOMContentLoad/pageshow event decided this wasn't a SERP, we should record that so the load event doesn't do unnecessary work and it keeps in sync with the logic of SearchSERPTelemetry.

Comment 8

[James Teow [:jteow]]

Upon thinking on this further, I was thinking a better solution would be to work on Bug 1827536. That could restrict the actor from being created lest it matched a specific expression. It would also avoid having to add state to the child process.

However, changing the location post-load could end up creating another actor and getting us into the same issue as we listen to load events and allow actors to be created on that event type.

Comment 9

[Daniel Bodea [:danibodea]]

I can also confirm that this issue is intermittent, making regression investigation quite impossible.
This being considered, we can definitely say that the issue has occurred at least since Nightly v114.0a1 from 2023-04-10.

The mozregression result is most probably NOT the correct regressor, but these are the results:
Bug 1826962 - Fix panel-list menuitems' image placement when placed in a XUL document r=mconley
Also fix the vertical alignment of the browser icon displayed on the
selector.
Differential Revision: https://phabricator.services.mozilla.com/D174959

Removing the regressionwindow-wanted tag considering a more detailed regressor range can not be provided with the steps provided.