[BUG]: not getting live link in button

[kpj2006]

Bug Description

after clicking share button we are not able to get live link

like in attach image we are on /#/about page but share button giving us / link to share.

Steps to Reproduce

No response

Logs and Screenshots

No response

Environment Details

No response

Impact

Low - Minor inconvenience

Code of Conduct

• I agree to follow the Code of Conduct
• I have joined the Discord server and will post updates there
• I have searched existing issues to avoid duplicates

[kpj2006]

@CodeRabbit give the reason behind this happening and what needed to fix(if any issue).

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 162 --repo AOSSIE-Org/SocialShareButton --comments

Length of output: 372

---

🏁 Script executed:

#!/bin/bash
gh issue view 162 --repo AOSSIE-Org/SocialShareButton --json title,body,comments,labels,state -q '.'

Length of output: 1662

---

🏁 Script executed:

#!/bin/bash
rg -n -i "share" --type=js --type=ts --type=tsx -l 2>/dev/null
rg -n "window.location" -g '*.{js,jsx,ts,tsx}'
fd -i "share"

Length of output: 444

---

🏁 Script executed:

#!/bin/bash
fd . -t f | head -100
echo "---"
rg -n "location" -g '*.js' -g '*.jsx' -g '*.ts' -g '*.tsx' .
echo "---share components---"
rg -ni "share" -g '*.js' -g '*.jsx' -g '*.ts' -g '*.tsx' -l .

Length of output: 2946

---

🏁 Script executed:

#!/bin/bash
sed -n '1,120p' src/social-share-button-react.jsx

Length of output: 3334

---

🏁 Script executed:

#!/bin/bash
sed -n '120,220p' src/social-share-button-react.jsx

Length of output: 825

---

🏁 Script executed:

#!/bin/bash
sed -n '1,40p' src/social-share-button.js

Length of output: 1688

---

🏁 Script executed:

#!/bin/bash
grep -n "options.url\|this.options.url\|getShareUrl\|buildShareUrl" src/social-share-button.js | head -50

Length of output: 675

---

G'day @kpj2006,

Had a squiz through the codebase, and reckon I've found the culprit, mate.

The reason

The share URL is captured once and then never refreshed when your app uses client-side (hash-based) routing:

• src/social-share-button.js (vanilla core, Line 13):

  url: options.url || (typeof window !== "undefined" ? window.location.href : ""),

  This runs only inside the constructor, so this.options.url gets frozen at whatever window.location.href was the moment the instance was created. It's then reused everywhere later on (Lines 125, 436, 453, 463, 503, 609, 749) without ever re-checking the browser's current location.

• src/social-share-button-react.jsx (Line 50), src/social-share-button-preact.jsx (Line 47), and src/social-share-button-qwik.tsx (Line 27) all do the same fallback: url || window.location.href.

For the wrapper components, this value is recomputed on every render, and is even in the useEffect dependency array that syncs it to the underlying vanilla instance. But that only helps if the component actually re-renders after navigation. When you're on a hash route like /#/about, moving between routes usually doesn't trigger a full reload or remount of the share button (especially if it's sitting in a shared layout/header outside your <Route> tree). No re-render → currentUrl never gets recalculated → the button keeps handing out the URL from the very first mount (often just /).

In short: nothing in the library listens for hashchange/popstate/history navigation events, so it has no way of knowing the route changed unless the host app explicitly re-renders it with a fresh url prop.

What needs fixing

There's a genuine bug here worth addressing. A couple of ways to do it:

Option 1 — Resolve the URL lazily at share time (most robust, fixes vanilla JS too):

// instead of caching this.options.url once and reusing it everywhere:
getCurrentUrl() {
  return this.options.url || (typeof window !== "undefined" ? window.location.href : "");
}

Then swap the direct this.options.url reads (share/copy actions) to call this.getCurrentUrl() instead — so it always reflects the live location unless the consumer explicitly passed a fixed url.

Option 2 — Actively watch for navigation changes:

window.addEventListener("hashchange", () => this.updateOptions({ url: window.location.href }));
window.addEventListener("popstate", () => this.updateOptions({ url: window.location.href }));

This is needed on top of Option 1 if you want SPA routers using pushState/replaceState (e.g., React Router's BrowserRouter) to also stay in sync, since those don't fire hashchange — you'd need to monkey-patch history.pushState/replaceState or expose a manual refreshUrl() method for consumers to call in a route-change handler.

I'd recommend Option 1 as the baseline fix across all four entry points (social-share-button.js, -react.jsx, -preact.jsx, -qwik.tsx), plus Option 2 for better SPA support out of the box.

Keen to help plan out the actual code change if you want — just say the word.

Cheers 🐰

---

✏️ Learnings added

Learnt from: kpj2006
URL: https://github.com/AOSSIE-Org/SocialShareButton/issues/162

Timestamp: 2026-07-03T20:42:10.298Z
Learning: In AOSSIE-Org/SocialShareButton, the share URL is resolved once via `url || window.location.href` at construction/render time in `src/social-share-button.js` (constructor, Line 13), `src/social-share-button-react.jsx` (Line 50), `src/social-share-button-preact.jsx` (Line 47), and `src/social-share-button-qwik.tsx` (Line 27). There is no listener for `hashchange`/`popstate` or patched History API, so on client-side/hash-based routed pages, the share button can emit a stale URL (e.g., `/` instead of `/#/about`) if the component doesn't re-render after route changes.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

[kpj2006]

@amankv1234

[amankv1234]

@kpj2006 , I Will do it .

[afzalansari12]

Hi @kpj2006, is this issue still available? I noticed there hasn't been any update for the past few weeks. If it's unclaimed, I'd be happy to work on it.

[amankv1234]

@afzalansari12 , It is already done

[afzalansari12]

@afzalansari12 , It is already done

Thanks for the update! I'll look for another issue to contribute to.