Opened 3 years ago

Last modified 3 years ago

#18954 reopened defect

Trac should not make request to next/related bug

Reported by: gk Owned by: qbi
Priority: Medium Milestone:
Component: Internal Services/Service - trac Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Suppose you are not logged into our Trac bugtracker and have your browser console open while loading #18915. At the very end you'll oddly see that the follow-up bug #18916 get requested, too. There is nothing special about this bug. This happens for any bug as far as I can see and Trac should not doing this because I only requested #18915.

It gets weirder as soon as I am logged in because then the second bug requested is not the one with the following bug number but one that seems related to my activity. Collecting this information seems already a bit overreaching to me but even if we do this for some reason this information should never go over the network (while I am using Trac).

Child Tickets

Change History (13)

comment:1 Changed 3 years ago by cypherpunks

Isn't this link prefetching? I found this ticket still open: #3010.

comment:2 Changed 3 years ago by gk

I think this might be true, good catch. But it does not make sense to me to have the link we prefetch being dependent on login status. Especially if it is not visible at all on the ticket just loaded. So, there is not even a slight chance that one can click on it.

comment:3 Changed 3 years ago by bugzilla

Component: Internal Services/Service - tracApplications/Tor Browser
Resolution: duplicate
Status: newclosed

For #10534 the #10536 is prefetched if you are not logged in (as there is no #10535).

Setting network.prefetch-next to false fully eliminates this behavior.

comment:4 Changed 3 years ago by gk

Resolution: duplicate
Status: closedreopened

I understand that this is prefetch related but that ticket is not something about flipping the related pref or not. Rather, about the behavior of our Trac instance, see comment:2

comment:5 Changed 3 years ago by gk

Priority: HighMedium
Severity: MajorNormal

Oh, and the prefetched resources aren't even cached in Tor Browser. So, basically, this only results in unnecessary overhead.

comment:6 Changed 3 years ago by gk

Component: Applications/Tor BrowserInternal Services/Service - trac

comment:7 in reply to:  4 ; Changed 3 years ago by bugzilla

Replying to gk:

I understand that this is prefetch related but that ticket is not something about flipping the related pref or not. Rather, about the behavior of our Trac instance, see comment:2

What do you want from Trac?

Last edited 3 years ago by bugzilla (previous) (diff)

comment:8 in reply to:  7 Changed 3 years ago by gk

Replying to bugzilla:

Replying to gk:

I understand that this is prefetch related but that ticket is not something about flipping the related pref or not. Rather, about the behavior of our Trac instance, see comment:2

What do you want from Trac?
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.

No. Take a fresh new Tor Browser and you'll see the same. Reading up on how link prefetching works would explain you why this is the case.

comment:9 in reply to:  7 ; Changed 3 years ago by cypherpunks

Replying to 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 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 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?

comment:10 in reply to:  9 ; Changed 3 years ago by bugzilla

Replying to cypherpunks:

Replying to 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.

This is how normal prefetcher should work (see e.g. CPU manuals), and it's not interesting that Mozilla was going to do it, but did only a "link rel next" reader. And what cookie are you talking about, dirty animal?

gk:
Next ticket becomes next in Custom Query or Report if you've opened a ticket from them. It's not login-related.

comment:11 in reply to:  10 ; Changed 3 years ago by cypherpunks

Replying to bugzilla:

This is how normal prefetcher should work (see e.g. CPU manuals), and it's not interesting that Mozilla was going to do it, but did only a "link rel next" reader.

Exactly: talking out of your ass.

And what cookie are you talking about

Read the source code, genius.

dirty animal?

Is that supposed to be an insult? Hilarious.

comment:12 Changed 3 years ago by nickm

bugzilla, cypherpunk: this is not how we communicate here.

comment:13 in reply to:  11 Changed 3 years ago by bugzilla

Replying to cypherpunks:
Restless punky animal, still can't stop thinking about the others' backs?

And what cookie are you talking about

Read the source code

The question was about its relevance to the topic. Or can't you find where it's written in the source code?

dirty animal?

Is that supposed to be an insult? Hilarious.

It's just what you shave everyday in the mirror.

...

Wow, nickm came into a discussion!

nickm:
It just tries to socialize. And how do you communicate with such an animal?

Note: See TracTickets for help on using tickets.