[tor-bugs] #18954 [Internal Services/Service - trac]: Trac should not make request to next/related bug

[Tor Bug Tracker & Wiki]

#18954: Trac should not make request to next/related bug
----------------------------------------------+--------------------------
 Reporter:  gk                                |          Owner:  qbi
     Type:  defect                            |         Status:  reopened
 Priority:  Medium                            |      Milestone:
Component:  Internal Services/Service - trac  |        Version:
 Severity:  Normal                            |     Resolution:
 Keywords:                                    |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
----------------------------------------------+--------------------------

Comment (by cypherpunks):

 Replying to [comment:7 bugzilla]:
 > It's the behavior of internal FF's prefetcher that tries to predict the
 "next" your move based on its prediction algorithm which is based on
 history of your navigation.
 You're talking out of your ass. Stop it. Kthx.

 gk, qbi:
 What you are seeing here is default Trac behaviour (at least in branch
 1.0, the one I looked at), not particular to this instance.

 Trac is setting a few `<link>` elements with a `rel` type related to
 'sequential navigation' (or something). Looking
 [https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types here] you'll
 find: 'index', 'up', 'first', 'last', 'prev', and 'next'. (Plus non-
 standard synonyms.) According to that page, all except 'prev' and 'next'
 have been obsoleted.

 Except for 'index' I've seen Trac set all of these. According to the
 source, they are used in various components, not just tickets. (Actually,
 it seems there's a little bug in Trac: it uses both 'first' and 'start',
 an incorrect synonymous for 'first', with different targets. I looked at
 trunk and it's still there.)

 When Firefox sees 'next' (or 'prefetch') `<link>`s, prefetching kicks in,
 if not disabled. Is not clear to me if the Trac developers had prefetching
 in mind when coding this.

 The 'sequence' Trac thinks of, in the case of tickets, is the global list
 of tickets (all in the db) or those produced by the 'context query', if
 Trac can find one. This 'context query' appears to be some query
 associated with the value of a cookie (maybe the session cookie itself?).

 So, if Trac can't associate the ticket view request with a context query,
 'next' ends up being the next ticket number available in the database.
 Otherwise, 'next' is the next ticket among the results of said query.

 Some of the mentioned links are in fact clickable. If you look right below
 the main navigation bar, in a ticket view, you'll see the 'Context
 navigation' (disable CSS and it willl be obvious): `prev | up (*) | next`.
 (*) 'up' might be missing. It will be present if there's a context query:
 e.g. 'Back to Query'.

 For the implementation see (search for functions `add_link` and
 `add_ticket_link`):
 * trac/web/chrome.py
 * trac/ticket/web_ui.py
 For the HTML see (search for `chrome.links`):
 * trac/templates/layout.html (`<link>`)
 * trac/templates/macros.html (`<li><a>`)

 Replying to [comment:5 gk]:
 > Oh, and the prefetched resources aren't even cached in Tor Browser. So,
 basically, this only results in unnecessary overhead.

 This seems like a good argument for disabling prefetching in Tor Browser,
 no?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18954#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online