Reimplement event handler for mobile sticky slot#2421
Merged
Conversation
|
Contributor
Contributor
|
Size Change: +213 B (+0.05%) Total Size: 388 kB
ℹ️ View Unchanged
|
cemms1
force-pushed
the
cemms1/reimplement-mobile-sticky-handler
branch
2 times, most recently
from
d5a3d9d to
0a5ebfc
Compare
dskamiotis
reviewed
Feb 19, 2026
| const handleBannerEvent = (event: Event) => { | ||
| log('commercial', '🪵 Handle Banner Event:', event.type); | ||
| const handleBannerEvent = (event: Event): void => { | ||
| log('commercial', `📲 Handling event ${event.type}`); |
Contributor
There was a problem hiding this comment.
Nice touch with the enhanced logging - great addition for debugging and monitoring, as well as coupled to the event
dskamiotis
approved these changes
Feb 19, 2026
| // We only try to load the mobile-sticky slot when one of the following events has been received | ||
| document.addEventListener('banner:close', handleBannerEvent); | ||
| document.addEventListener('banner:none', handleBannerEvent); | ||
| document.addEventListener('banner:sign-in-gate', handleBannerEvent); |
Contributor
There was a problem hiding this comment.
This addition makes sense and aligns with the banner:sign-in-gate event handling introduced in the DCR codebase.
cemms1
changed the title
cemms1
force-pushed
the
cemms1/reimplement-mobile-sticky-handler
branch
6 times, most recently
from
1154054 to
b506bae
Compare
Co-authored-by: Demetrios Skamiotis <[email protected]>
…f generating fake custom events
…ead of dispatching the custom event directly
This reverts commit b5de8df.
cemms1
force-pushed
the
cemms1/reimplement-mobile-sticky-handler
branch
from
b506bae to
291fa20
Compare
… queue flush implementation
cemms1
commented
Mar 9, 2026
| const bannerSelector = '[name="StickyBottomBanner"]'; | ||
| const mobileStickySelector = '#dfp-ad--mobile-sticky'; | ||
|
|
||
| /** TODO: Enable this when the event handling mobile-sticky logic goes live */ |
Contributor
Author
There was a problem hiding this comment.
Couldn't opt into AB tests in playwright with a query parameter as the GET requests are updated to POST requests for interaction with the DCR prod server (as this is what runs in the container)
Once we go live to 100%, we can fully enable this test
Jakeii
approved these changes
Mar 9, 2026
This was referenced Mar 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this change?
Re-introduces event handlers for launching the mobile-sticky ad slot from #2351.
This is being launched as an AB test while we understand the impact of the change.
The variant group of the AB test will implement the logic below. The control group will keep the existing logic in place.
We now listen to the following three events in order to determine whether we can render the mobile sticky slot:
banner:nonebanner:closebanner:sign-in-gatecmp:banner-closeThe page is not eligible for mobile-sticky until we receive one of these events on a given page view. We also still need to check the existing criteria before rendering the mobile-sticky ad slot but these event listeners now act as an additional check.
After receiving an event, we double check whether the CMP is still on the screen just in case the
cmp:banner-closeevent did not actually result in the dismissal of the CMP.This PR adds logging and event handling for these three scenarios as well as a Playwright test to monitor this moving forward.
Note
Companion PR in dotcom-rendering guardian/dotcom-rendering#15380
Why?
The mobile-sticky slot can sometimes launch at the same time as the CMP and supporter revenue banners. When this happens, the slot is present in the DOM but sits underneath these elements. We can't continue to allow this to happen as impressions are counted against the advert in the slot even though it can't be seen by the end user
We have decided to only allow the mobile-sticky to launch after certain events as well as the existing page conditions.
It is worth noting that we deliberately allow display of the mobile-sticky slot when the sign in gate is the chosen message from the
StickyBottomBannercomponent. The sign in gate currently appears most often obscuring the article body and does not look like a banner or a modal. Another version of the sign in gate appears as a modal and we may want to look into preventing ads running when this is present on the screen.Co-authored by: @dskamiotis
Document link for extra information