Skip to content

Conversation

@hkhatana26
Copy link

@hkhatana26 hkhatana26 commented Nov 21, 2025

@hkhatana26 hkhatana26 requested a review from a team as a code owner November 21, 2025 12:05
@hkhatana26 hkhatana26 requested review from drashti1712, hkuraware, nkthakur48 and suhjainadobe and removed request for a team November 21, 2025 12:07
@github-actions
Copy link
Contributor

This pull request is not passing all required checks. Please see this discussion for information on how to get all checks passing. Inconsistent checks can be manually retried. If a test absolutely can not pass for a good reason, please add a comment with an explanation to the PR.

@spadmasa spadmasa self-assigned this Nov 22, 2025
@spadmasa
Copy link

Please provide after branch url to test , do not see with branch mwpw-181371-mweb-floatingcta--milo--hkhatana26 page loading

@spadmasa
Copy link

spadmasa commented Dec 1, 2025

Hi @hkhatana26 ,
As discussed current pr if it moves to production will impact the functionality of CTA visible
https://main--cc--adobecom.aem.page/products/photoshop?milolibs=mwpw-181371-mweb-floatingcta--milo--hkhatana26
and on authoring changes advised , please discuss with authors and get the updates to proceed with changes
cc : @nkthakur48 , @sigadamvenkata , @suhjainadobe , @drashti1712

@hkhatana26 hkhatana26 force-pushed the mwpw-181371-mweb-floatingcta branch from 844d5b5 to e7fea76 Compare December 3, 2025 13:22
@nkthakur48 nkthakur48 changed the title mweb floating cta changes fixes MWPW-181371: mweb floating cta changes fixes Dec 3, 2025
@github-actions
Copy link
Contributor

This PR has not been updated recently and will be closed in 7 days if no action is taken. Please ensure all checks are passing, https://github.com/orgs/adobecom/discussions/997 provides instructions. If the PR is ready to be merged, please mark it with the "Ready for Stage" label.

@github-actions github-actions bot added the Stale label Dec 16, 2025
@spadmasa spadmasa removed the Stale label Dec 16, 2025
|| entry.boundingClientRect.top < 0
|| stickySectionEl?.getBoundingClientRect().y > 0;
el.classList.toggle('hide-sticky-section', shouldHideSticky);
} else if (target.matches('merch-card')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: The nested if-else structure in the intersection observer is becoming difficult to follow
Could you see if extracting the merch-card handling into a separate function makes sense?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have extracted the merch card handling and moved the related condition into a separate function.

});
});
});
mutationObserver.observe(document.body, { childList: true, subtree: true });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Observing document.body with subtree: true monitors ALL DOM changes across the entire page. Could you check whether scoping the observer to a more specific container or using event delegation makes sense here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both observers are needed throughout the lifecycle of page .The IntersectionObserver must remain active to react to scroll-based visibility changes throughout the page lifecycle. The MutationObserver cannot be safely disconnected because merch cards load asynchronously and there is no reliable signal indicating when all cards have been rendered.

io.observe(stickySectionEl);
}

const mutationObserver = new MutationObserver((mutations) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The MutationObserver lacks cleanup, which can lead to potential memory leaks. Could you return the cleanup functions and call them appropriately

return () => {
  mutationObserver.disconnect();
  io.disconnect();
};

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am observing main tag because merch card will be loaded into that.

Copy link
Contributor

@zagi25 zagi25 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like that this solution only covers merch-cards, but based on the ticket description, any section should be able to trigger 'hide-action'.

});
});
});
mutationObserver.observe(main, { childList: true, subtree: true });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think observing main tag mutations is a good idea, this can get very expensive and it can lead to performance issues.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the MutationObserver on main.


if (target === document.querySelector('footer')) {
el.classList.toggle('fill-sticky-section', isIntersecting);
} else if (target === document.querySelector('.hide-at-intersection')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using Mutation Observer on main, is it possible to expand this functionality or to implement something similar to mark section for which notification should be hidden ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the MutationObserver on main and made this behavior more explicit. Sections that need to hide the notification are now marked using hide-at-intersection-start / hide-at-intersection-end and handled via IntersectionObserver.

This avoids expensive DOM observation and lets any section trigger the hide-action in a cleaner, more scalable way.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 3, 2026

This PR has not been updated recently and will be closed in 7 days if no action is taken. Please ensure all checks are passing, https://github.com/orgs/adobecom/discussions/997 provides instructions. If the PR is ready to be merged, please mark it with the "Ready for Stage" label.

@github-actions github-actions bot added the Stale label Jan 3, 2026
@spadmasa spadmasa removed the Stale label Jan 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants