Trac should not make request to next/related bug

added component::internal services/service - trac owner::qbi priority::medium severity::normal status::reopened type::defect labels

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

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.

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

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

Trac:
Status: new to closed
Resolution: N/A to duplicate
Component: Internal Services/Service - trac to Applications/Tor Browser

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

Trac:
Status: closed to reopened
Resolution: duplicate to N/A

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

Trac:
Priority: High to Medium
Severity: Major to Normal

Trac:
Component: Applications/Tor Browser to Internal Services/Service - trac

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?

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.

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?

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.

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.

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

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?

Trac should not make request to next/related bug

Child items 0

Activity