Checkin [c3b223b71d] largely breaks the "related" checkbox.

Using Fossil 2.10 (or any version through today), click on a branch name in the timeline, for example grep-hash-digits. The URL will contain an "r=TAG" query. This is interpreted the same as "t=TAG&rel", and the timeline graph is created accordingly.

The problem is the "related" checkbox and "tag filter" text entry do not get filled in. Because the URL does not contain the "t" and "rel" queries, the checkbox is unchecked and the text entry is left blank.

Prior to [c3b223b71d], the URL query string would be rewritten to replace "r=TAG" with "t=TAG&rel", but this is no longer being done. When style_footer() gets called, it eventually hits line 822 with zQPN set to rel:

if( PB(zQPN) ){
  @ checked \
}

PB(zQPN) returns false because rel wasn't set in the query string, so the checkbox is left unchecked. The same thing happens with t not being present in the query string resulting in the tag entry being left blank.

At this point, the timeline graph is correct, but "related" and "tag filter" are not set. Clicking on "related" now causes rel=on to be set in the query string, but t is left blank due to the tag filter not being set. In this situation, the blank t has priority over r since the following code gets skipped due to related having become true:

if( zBrName && !related ){
  zTagName = zBrName;
  related = 1;
  zType = "ci";
}

The blank t then in turn causes filtering to be disabled, and all checkins are shown, regardless of the value of r.

Dealing with this exact situation is why I originally committed 90057326f4. See the checkin comments on that same branch for more discussion.

Backing out [c3b223b71d] resolves the issue and restores expected operation of the "related" and "tag filter" widgets. However, I have to assume there was a reason for this checkin. It must have corrected some other issue elsewhere, so maybe a different solution is needed.

In my testing of this backout, I spotted another issue. Clicking on a branch name may set the "related" and "tag filter" widgets correctly, but it does not cause the X check-in(s) tagged with "Y" text to be shown until after making further changes to the filtering widgets. Here is the relevant code. zBrName is non-NULL because r was (originally) in the query string, but the branch name I happened to click didn't have any associated wiki, so wiki_render_associated() returns false, and desc gets ignored. I think the solution may be to repeat the else clause found in the non-zBrName code so that all cases emit desc. But I feel this is a secondary issue to the UI problems.

See branch andygoth-restore-related for my proposed corrections to all of the above. I'm keeping this on a branch because I don't know the reason why [c3b223b71d] was backed out and don't want to risk causing a regression elsewhere due to my having been out of the loop.