Wikimedia Bugzilla is closed!

Can you clarify the exact steps you followed to experience this bug?

Also, which browser version and operating system version did you use?

I am not able to reproduce this bug on Chrome, Firefox or Safari for Mac OSX.

I follow these steps:

1. Go to watchlist
http://en.wikipedia.org/wiki/Special:Watchlist

2. Click on 'Feedback from my watched pages »'

3. Go to Central feedback page, filtered for my watched pages:
http://en.wikipedia.org/w/index.php?title=Special%3AArticleFeedbackv5Watchlist&ref=watchlist

I get the same filtered list as if I had gone from the Central feedback page and clicked on the link at the top of that page ('Feedback from my watched pages'), except that the URL is a bit different:
http://en.wikipedia.org/wiki/Special:ArticleFeedbackv5Watchlist

Odd.

I tested and confirmed this bug at work on Windows 7/https/Firefox (no idea which version).

Now that I'm back at home, the bug is not happening on OS X/https/Chrome, but it is happening on OS X/http/Safari.

Strange.

I inspected the element in Safari. This is the relevant HTML:

---
<a id="articlefeedbackv5-watchlist-feedback-link" href="Special:ArticleFeedbackv5Watchlist?ref=watchlist">Feedback from my watched pages »</a>
---

The "href" attribute here is clearly wrong (it should be "/wiki/Special:ArticleFeedbackv5Watchlist?ref=watchlist").

Thanks. 

I am unable to reproduce this issue on Safari, which works fine for me.

But your point above is well taken.

I think that you have provided us enough info that Matthias can take a look at this in his morning, and determine whether there is an issue with his code.

Much appreciated.

I tried to debug this myself, but didn't get very far.

I started at <http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&*>.

I found ["ext.articleFeedbackv5.watchlist","1359341524",["jquery.articleFeedbackv5.track"]] in the code, so I headed to <http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.articleFeedbackv5.watchlist&only=scripts&skin=vector&*>.

I set ?debug=true (<http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=true&lang=en&modules=ext.articleFeedbackv5.watchlist&only=scripts&skin=vector&*>), but I get the following JS:

---
/**
 * Script for Article Feedback Extension: Talk pages
 */

/*** Main entry point ***/
jQuery( function( $ ) {

	// Check if the talk page link can be shown
	if ( mw.config.get( 'wgArticleFeedbackv5WatchlistLink' ) ) {

		// Check if we're not dealing with anon user
		if ( mw.user.anonymous() ) {
			return;
		}

		// Initialize clicktracking
		// NB: Using the talk page's namespace, title, and rev id, not
		// the article's as in the front end tracking
		$.aftTrack.init();

		// Build the url to the Special:ArticleFeedbackv5 page
		var params = { ref: 'watchlist' };
		var url = mw.config.get( 'wgScript' ) + '?title=' +
		          encodeURIComponent( mw.config.get( 'wgArticleFeedbackv5SpecialWatchlistUrl' ) ) +
		          '&' + $.param( params );

		// Add the link to the feedback-page next to the title
		var link = $( '<a id="articlefeedbackv5-watchlist-feedback-link"></a>' );
		link
			.text( mw.msg( 'articlefeedbackv5-watchlist-view-feedback' ) )
			.html( link.html() + ' &raquo;' )
			.attr( 'href', url )
			.click( { trackingId: 'watchlist_view_feedback-button_click' }, $.aftTrack.trackEvent );

		$( '#contentSub' ).append( link );

		// Track an impression
		$.aftTrack.track( 'watchlist_view_feedback-impression' );
	}

} );

;
mw.loader.state({"ext.articleFeedbackv5.watchlist":"ready"});
---

This JS looks fine to me off-hand. So I'm not sure what's going on here. Maybe something is cached?

I think that Matthias can make more rapid progress on this than either of us, since he's so familiar with the code and these types of issues.

But your hypothesis that this is related to a cached item could explain why we're getting different results for the same platforms.

Let's see what Matthias says tomorrow and we can pick it up from there ...

Thanks again for reporting this issue.

https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/ArticleFeedbackv5.git;a=commitdiff;h=495d5168874b211464e8939256f968277755b557

This seems like an issue where there's updated PHP code, but outdated JavaScript. I somehow missed this earlier.

I'm also unable to reproduce the issue. The culprit is indeed what MZMcBride points out in comment 7: this change has been deployed recently & the new value (through PHP) has been updated while the browser has not yet cleared JS cache. Which in turn results in the incorrect link.

Is there a way to force the JavaScript to update? In the past, we've usually done this with a version variable of some kind, changing <script src="foo.js?2"> into <script src="foo.js?3"> or similar. Is that possible here?

I'm not really sure how scripts loaded with Resourceloader can easily be forced to bust caches (don't think we can just add an arbitrary get param).
Here specifically, this is no longer an issue though.