Github Desktop: Rebase vs Merge Commit, to keep a fork up to date

My work flow to contribute to a repo, is

1. Create a fork of the upstream
2. Clone the fork to my local
3. Push changes to my fork
4. Create a PR to merge my change into upstream

Sometimes while I am working on my change, other devs might commit their changes into the upstream, so I want to do a rebase which will bring my fork up to date. But I have noticed that in the below scenario, Rebase and Merge Commit gave me different response,

The way I tested it is as follow:

1. I created a fork of the upstream
2. I cloned my fork to my local using GitHub Desktop, and set current branch to my fork branch
3. I then made a change in upstream/master branch and committed it
4. when I clicked "Rebase current branch", it tells me the current branch is up-to-date as below:
   
5. when I clicked "Merge into current branch", it detects a change in the upstream:
   
   upstream/master is the branch in the upstream, and muti/master is the branch in my fork.

My question is, why rebase doesn't detect any change, while the merge and commit does?

Note first that if you have access to the upstream repository, you don't have to fork it in order to push a fix branch and initiate a PR (Pull Request).

You can do all that directly in the upstream repository.

Second, the rebase would only work if the current branch has a divergent history from upstream/master.
If the current branch HEAD is an ancestor of upstream/master, the rebase (of the current branch on top of upstream/master) would be a no-op.
But a merge (of upstream/master into the current branch) would not, since from the point of view of the current branch, there is one commit (done in upstream/master) that it does not have.