Incorrect bidderCode association with adm

[namanjainfbd]

Type of issue

Bug

Description

In the Prebid server adapter, we observed a discrepancy in the winning adm and seat associated with it.
Specifically, suppose there are two bids:

• Bid 1
  • seat s1
  • ad code adm1
• Bid 2
  • seat s2
  • ad code adm2

In auctionEnd event, we see the association of adm2 with s1 which shouldn't be the ideal case. To diagnose the problem further, we enabled pbjs_debug and reviewed the console events. Please check the screenshot below.

Here is the screenshot of the difference between chrome and safari.

As observed in the bidsReceived array, in Safari, all the bidderCode keys are having the value appnexus. While in Chrome it is as expected.

After extensive debugging, we pinpointed the issue here.

Prebid.js/libraries/ortbConverter/converter.js

Lines 119 to 121 in 2efc834

	function augmentContext(ctx, extraParams = {}) {
	return Object.assign(ctx, {ortbRequest: request}, extraParams, ctx);
	}

Seems like the issue is with the Object.assign which behaves differently on iOS 17 and later versions, affecting both Chrome and Safari. Additionally, it impacts Safari 17 and later on macOS.

Steps to reproduce

Request more than one bids from various bidders using the Prebid server for a given ad unit.
We will notice that the bidderCode is taken from the first bid of the response, while the adm corresponds to the winning bid.

Expected results

We expect that each bid in the auctionEnd event should have the correct bidderCode corresponding to its respective actual bid.

Actual results

We observed that each bid in the auctionEnd event has the same bidderCode value.

Platform details

• Prebid - 9.1.0

Device tested on

Environment	Expected Output
Browser - Safari 17.5, Os - MacOS, device - Desktop	❌
Browser - Chrome 126.0, Os - MacOS, device - Desktop	✔️
Browser - Chrome 92.0, Os - ios 17.0, device - Mobile	❌
Browser - Safari 17.1, Os - ios 17.0, device - Mobile	❌

Other information

We conducted further debugging since this behavior was observed on iOS 17 devices and Safari 17.
Our investigation revealed that Object.assign() behaves differently in Safari 17 compared to Chrome.
To illustrate this difference, we have attached a test snippet. Here is the snippet

const ctx = {
    "seatbid": {
        "bid": [
            {
                "w": 320,
                "h": 50
            }
        ],
        "seat": "rubicon",
        "group": 0
    }
};
const extraParams = {
    "seatbid": {
        "bid": [
            {
                "w": 300,
                "h": 250
            }
        ],
        "seat": "appnexus",
        "group": 0
    }
};
Object.assign(ctx, extraParams, ctx);
console.log(ctx);

// chrome shows seatbid.seat as appnexus
// safari shows seatbid.seat as rubicon

[namanjainfbd]

Hi @dgirardi,
Since you are the last committer of the line associated with this bug, perhaps you can help us further debug this issue.

[dgirardi]

@namanjainfbd could you post a PBS response body that triggers this - or link to a page with this issue?

[dgirardi]

Unfortunately I don't have a good way to test on Mac/Safari. Browserstack only goes up to Safari 17.3 (on desktop) where the snippet you provided does not behave as you describe (no difference with Chrome).

From your description I think #11848 should fix it, but I'm unable to verify - would you be able to test it?

[namanjainfbd]

Unfortunately I don't have a good way to test on Mac/Safari. Browserstack only goes up to Safari 17.3 (on desktop) where the snippet you provided does not behave as you describe (no difference with Chrome).

From your description I think #11848 should fix it, but I'm unable to verify - would you be able to test it?

Hey,
I have replicated the issue on BrowserStack. Please find the attached videos for reference.

Browser - Safari 17.3, OS - Mac Sonoma

Safari showing seatbid.seat as rubicon

safari.mp4

Browser - Chrome 126.0.0.0, OS - Mac Sonoma

Chrome showing seatbid.seat as appnexus

chrome.mp4

[dqureshiumar]

Unfortunately I don't have a good way to test on Mac/Safari. Browserstack only goes up to Safari 17.3 (on desktop) where the snippet you provided does not behave as you describe (no difference with Chrome).

From your description I think #11848 should fix it, but I'm unable to verify - would you be able to test it?

Hey @dgirardi,

We have tested the fix provided in #11848. The issue appears to be resolved. Please refer to the attached screenshot for verification.

Testing details:

• Chrome: Version 122.0.6261.128
• Safari: Version 17.4

[dgirardi]

Huh. Safari 17.3 / sonoma on browserstack does not do that for me. I wonder what's going on?

Regardless it's good to hear that the fix works - thank you!