The only answer we can give is maybe or it depends.
You might ask: depends on what? and this is where it gets a bit complicated. Git itself does not have PRs. Pull requests themselves—and forks for that matter—have details that are specific to any one particular hosting provider.
What Git does have, and keep, and exchange, are commits. Commits are identified by raw hash IDs, which are always the same across every repository. GitHub, GitLab, Bitbucket, and so on are built atop Git, so they too keep and exchange commits, but they stack a lot of fancy interface on as well. With command-line Git, we have specific commands that do specific things with commits. With the web interfaces, we have clicky buttons that often run obscure, un-described commands—maybe many individual command-line commands—and it is hard to say what they do.
We can, however, say that there are at least three repositories involved here. There's the one you referred to as the upstream, probably hosted on some hosting server. There's another fork—another Git repository—on the same hosting provider, in which this PR B you're wondering about exists. There's your fork, a third repository, on this same hosting provider. There's probably at least one more Git repository on your own computer (e.g., laptop).
If you literally merge the commits from PR B, so that you add to your repository a commit whose parent is the tip commit of this PR B, then you've added this PR's actual commits, with their actual hash IDs, to your repository and your branches (perhaps on your laptop, perhaps on the hosting server). But if you use an operation that copies PR B's commits—such as git merge --squash or git cherry-pick or git rebase—then you'll end up with different commits. Some web hosting clicky "merge this" buttons make such copies, rather than using the originals.
Whoever owns the original repository has a similar choice: they could actually merge the tip commit of PR B. If they literally merge that and you literally merge that, Git will wind up doing the best thing it can, with as few problems as you can get. But if they use a process that copies the commits, they'll have a different set of commits than you have, whether or not you also copied the commits from this PR B.
And of course, whoever has presented PR B to the upstream could retract it and re-provide it with new commits, all on their own. (The exact mechanism for this might depend on the hosting server.)
All of this just brings it all back to the somewhat unsatisfactory answer: Maybe; it depends.
