fix 5310 : show social links bar on non-scrollable item pages

[guillermo-escire]

References

Fixes #5310

Description

The Social Links bar was only visible on pages that required scrolling. This fix detects whether the page is scrollable and adjusts the AddToAny plugin behavior accordingly, so the bar appears on all pages including short Item pages.

Instructions for Reviewers

List of changes in this PR:

1. In social.component.ts: Added AfterViewInit lifecycle hook that detects whether the current page has a scrollbar by comparing document.body.scrollHeight vs window.innerHeight. Injected ChangeDetectorRef to force re-render after the check, since the component uses OnPush change detection.

2. In social.component.html: Made data-a2a-scroll-show attribute conditional. If the page is scrollable, the original 0,60 value is used. If the page has no scrollbar, the attribute is omitted so the AddToAny plugin displays the bar immediately without requiring a scroll event.

Include guidance for how to test or review your PR. This may include: steps to reproduce a bug, screenshots or description of a new feature, or reasons behind specific changes.

How to test:

1. Enable the Social Links feature in your config:
   addToAnyPlugin:
   socialNetworksEnabled: true
2. Browse to an Item page with minimal metadata (e.g. only title, author and date) that does not scroll.
3. Verify the Social Links bar appears at the bottom of the page without needing to scroll.
4. Browse to an Item page with enough metadata to require scrolling.
5. Verify the Social Links bar still appears correctly when scrolling, and does not block the footer.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[nwoodward]

Thanks for this PR @guillermo-escire. It works very well for items with little metadata that don't require scrolling.

One issue is that it changes the behavior on the homepage. On main when I scroll down to the footer the AddToAny links disappear and the COAR Notify logo and link are visible. But on this PR branch the AddToAny links stay at the bottom of the page and cover up COAR Notify. I think that is fine for items with little metadata, but is it possible to restore the original behavior on /home?

And this is only my personal opinion, but I don't think the AddToAny links are necessary on the homepage, because to me they are for sharing links to items/publications/etc.

[guillermo-escire]

Hi @nwoodward, thanks for the detailed feedback!

You're absolutely right — the issue on the homepage was caused by always applying the floating style, which made the social links overlap the footer.

I've updated the implementation so that the a2a_floating_style is only applied when the page is scrollable. This restores the original behavior on /home, while still ensuring the social links are visible on item pages that do not require scrolling.

Regarding your point about the homepage, I agree that social links may not be strictly necessary there. For now, I've focused on restoring the original behavior to avoid regressions, but I'm happy to adjust further if needed.

I'll push the update shortly.

[nwoodward]

Hi @guillermo-escire. Thank you for looking at this again. I think something went wrong with the most recent commit, because now the AddToAny buttons are permanently under the footer at the bottom of the page on all items and /home. I cleared browser cache and cookies.

[guillermo-escire]

Hi @nwoodward, thanks for testing this again!

You're right — the issue was caused by the AddToAny plugin not re-evaluating layout changes after the floating style was applied dynamically.

I've now updated the implementation to reinitialize the AddToAny plugin after detecting scrollability, so it correctly recalculates its position.

I'll push this fix shortly — please let me know if it works as expected after that.

[nwoodward]

Hi @guillermo-escire. Thank you for continuing to work on this. I'm sorry that it is taking so much effort. I redeployed locally, and the AddToAny links appear on small and large item pages, as well as /home. But they always cover up COAR Notify in the footer, because they never disappear. Do you see the same behavior? If you are able to test changes locally to see if they make the social links work correctly that may speed up this process.

[guillermo-escire]

Hi @nwoodward , thanks for testing and your patience!

I was able to reproduce the issue. It was caused by AddToAny not recalculating its position after the DOM update, so the bar never disappeared.

I've now fixed it by reinitializing AddToAny after detecting scrollability. This restores the floating behavior, and the bar no longer overlaps the footer.

I've pushed the update, could you please verify if it works correctly now?

[tdonohue]

@guillermo-escire : I tested this today, and this doesn't appear to fix #5310.

With this PR in place, the behavior is similar to main:

1. The homepage behavior works well. The bar appears while scrolling, but when you get to the bottom of the page it disappears.
2. On the search page, the bar also works well. It appears while scrolling, but when you get to the bottom of the page it disappears.
3. On large Item pages (ones that are scrollable), the bar also works well. It appears while scrolling, but when you get to the bottom of the page it disappears.
4. On small Item pages (which have NO scrollbar), the bar does not appear. So the bug described in Social Links feature doesn't display on Item pages which do not scroll #5310 still exists.

We need to find a way for this social links bar to appear on a non-scrolling page without it hiding footer content. That likely means one of the following:

• Have the links bar appear (or stop scrolling) just above the footer. If we can stop the bar before it overlaps into the footer, then that might fix things.
• Or, add a button to the bar which allows you to somehow close/hide the bar.
• Or, add a "Share" link/button in the footer which can be pressed to make the social links options appear. This might be a way to remove the dependency on a scrollbar.
• Or potentially just embed the social links bar into the footer at all times (similar to how some sites on the web add icons to their footer to take you to their Facebook/X/YouTube/etc sites)

Overall, I'm not sure what is easiest. I'm just trying to brainstorm possible solutions.

[guillermo-escire]

Hi @tdonohue, thank you for the suggestions!

I went with the last option you mentioned: embedding the social links bar permanently inside the footer. This way the bar is always visible on all pages, including small item pages that do not scroll, without overlapping any footer content. I also centered the bar for a cleaner look that fits better with DSpace's footer style.

Could you please test and let me know if this works for you?

[tdonohue]

Thanks @guillermo-escire ! I've tested the new view and this is what I see:

I think this new view works, but I'd prefer if the buttons were on the right side of the footer (above the COAR Notify icon in this example).

As a sidenote, I just realized there's also another display that AddToAny recommends documented on this page: https://www.addtoany.com/buttons/customize/floating_share_buttons

Currently, in main we're using the floating horizontal share bar from that page. But, their other example is a floating vertical share bar. You can see it on that page in a fixed position to the left of the content.

Instead of putting these buttons in the header (where you need to potentially scroll down to see them), we could look at using the vertical share bar approach and dock it to the right side of the user's screen. So, it'd be the same display as on the AddToAny page above, except it would appear on the right side of any content. Something like this mockup:

If we go with the vertical bar, we'd just need to make sure it never overlaps with the header. So, it would need to float to the right of the content, near the top of the content.

Personally, I'd have a slight preference towards seeing if we can get the vertical bar to work (as it'd always appear on the page in the same place for both long pages and short pages). But, if that is problematic, embedding it in the footer is also OK with me.

@nwoodward : Do you have any strong preferences between these two screenshots?

[tdonohue]

As a sidenote, I've looked into the Codecov report for this PR and I think it's a false positive. For some reason, in this PR, CodeCov is saying the coverage is decreasing by 0.66%. But, if you visit the report on codecov.io for this PR, it says the PR's own coverage is at 100%.

So, I'm not sure how overall coverage can decrease in a PR with 100% code coverage. Therefore, I think we can safely ignore the failure in this PR from Codecov.

[guillermo-escire]

Hi @tdonohue ,

Thanks for the notes! I think the new view works well, and I prefer the vertical bar docked to the right. It stays visible on both long and short pages without overlapping the header, making it cleaner and more user-friendly than placing it in the footer.

Thanks!

[guillermo-escire]

Thanks for checking it out @tdonohue ! I agree: it looks like a false positive from Codecov. Since the pull request itself shows 100% coverage for the changes.

[tdonohue]

👍 Thanks @guillermo-escire ! I think this design looks great! I like having this social links bar floating on the right vertically. I've also verified that it looks good on all pages (including non-scrollable ones). So, I'm going to merge this immediately.

Thanks also for your many refactors to this PR as we figured out the best display. I think it was worth it in the end.