Wikipedia talk:Tools/Navigation popups

This page is for discussing Navigation popups and reporting bugs you encounter with it. Please be aware that the original author of Popups (Lupin) is no longer active on Wikipedia. All issues are handled at the discretion of other experienced editors. Note that this project has an associated Phabricator project where implementation-related discussion happens.

Not sure how to explain your problem clearly? Read How to Report Bugs Effectively for some general pointers.

Some common questions are answered in the FAQ.

---

No '(cur)" links in history popups

Is there a reason as to why the navigation popups for history (like when hovering above "hist" on a Watchlist entry) doesn't include "(cur)" links? Would it make Watchlist page loading noticeably more sluggish, or is there a different reason? Stevie is the man! ^{Talk • Work} 18:01, 24 October 2016 (UTC)

Reading the code, I can't see any particular reason for it. This task is now being tracked at T149236. Enterprisey (talk!) 19:48, 26 October 2016 (UTC)

Thank you for responding. Stevie is the man! ^{Talk • Work} 22:29, 26 October 2016 (UTC)

Edit request filed at the gadget's talk page. Enterprisey (talk!) 04:01, 31 December 2016 (UTC)

Problem previewing diffs in Firefox

Several months ago, the "preview diff" feature of Navigation Popups stopped working for me. If I hover over a diff link, I see a popup with the page title, but no diff text.

I normally use Firefox with the Ublock Origin add-on. I tried disabling Ublock Origin for en.wikipedia.org, but this made no difference — I get popups, but only with the page title and no diff text.

If I look at Wikipedia pages in Google Chrome, everything works fine — if I hover over a diff link, the popup shows the diff text as expected.

If I hover over a regular article link, the popup includes everything I would expect — article title, initial text snippet, first image, etc.

The "preview diff" feature used to work, and I believe it stopped working for me sometime during the past year (2016), but I can't recall exactly when.

Any suggestions? — Richwales (no relation to Jimbo) 21:58, 27 December 2016 (UTC)

Specifically, this problem happens with Firefox 51.0b10 (64-bit) running on Ubuntu 16.04.1. If I use this same version of Firefox on Windows 7, the preview diff popups work OK. — Richwales (no relation to Jimbo) 22:07, 27 December 2016 (UTC)

I just started experiencing this issue today. The previews appear to be a diff off; hovering over a previous edit shows the diff of the one it follows, and the most recent one shows up blank. Interestingly, this only happens from my watchlist. This problem doesn't occur from the 'View History' tab on an article. Nothing on my side has changed, except the year. Clicking on the link also leads me to a blank diff: [1]. Again, from the 'View History' tab, this doesn't occur: [2] — ξ^xplicit 05:02, 2 January 2017 (UTC)

Width problem with history view

I am seeing an odd problem with histories, both when I hover over a 'hist' link in my watchlist, and when I navigate to a history from any popup instance. The leftmost column seems far too narrow, so the '(cur | last}' is split over three lines, making it hard to use and making every line wider by the same amount. I only just noticed this, so it probably started happening today. I am using the latest version of Safari on macOS, which has not been updated that recently. Clearing my cache did not help. Looking at the history this diff by Mr. Stradivarius and Enterprisey may be the reason, though my JS is too rusty to diagnose it myself.--JohnBlackburne^words_deeds 19:00, 1 January 2017 (UTC)

This started happening once the "cur" was added earlier today. The developer should have made sure "(cur | last)" didn't wrap. Stevie is the man! ^{Talk • Work} 19:07, 1 January 2017 (UTC)

I noticed this. Is there a way to revert to the previous version while waiting for them to fix it? Dustin (talk) 19:32, 1 January 2017 (UTC)

Those with the rights to do so might decide to roll it back, although I suspect the fix is so simple they would just post a quick fix. Or so I hope. Stevie is the man! ^{Talk • Work} 19:37, 1 January 2017 (UTC)

Looking at it now a couple of non-breaking spaces might be all that’s needed. It’s only a minor glitch so no need to roll back the change, IMHO. There‘s certainly no way to use the older version yourself.--JohnBlackburne^words_deeds 19:53, 1 January 2017 (UTC)

I've added two nbsp's, which works after cache-clearing. Removing the spaces altogether may be another option. -- zzuuzz ^(talk) 20:10, 1 January 2017 (UTC)

Could we actually swap the two places? Last is typically more useful in considering diffs than cur. Nikkimaria (talk) 20:18, 1 January 2017 (UTC)

I'm of the opinion that it's more intuitive to copy the order used by the MediaWiki software (cur | prev). Speaking of which it should probably use 'prev' instead of 'last'. -- zzuuzz ^(talk) 20:22, 1 January 2017 (UTC)

I agree with this, and funny enough I was just thinking the same thing about 'prev' vs. 'last'. Stevie is the man! ^{Talk • Work} 20:26, 1 January 2017 (UTC)

I guess I'll have to get used to hovering over over last instead of diff; at the current time, I keep hovering over cur which obviously isn't what I want to see most of the time. Thanks to zzuuzz for fixing the spacing issue regardless. Dustin (talk) 20:43, 1 January 2017 (UTC)

Thanks! Looks great! Stevie is the man! ^{Talk • Work} 20:27, 1 January 2017 (UTC)

So "last" should be changed to "prev", then? By the way, apologies for screwing up the layout in popups. Enterprisey (talk!) 00:24, 2 January 2017 (UTC)

I've gone ahead and changed "last" to "prev". — Mr. Stradivarius ^{♪ talk ♪} 01:58, 2 January 2017 (UTC)

Mr. Stradivarius, thanks for the change. I'm not sure whether 'prev' should also be added as an entry in the pg.string "database" for localization purposes, though. Enterprisey (talk!) 03:03, 2 January 2017 (UTC)

@Enterprisey: Good point - we don't want to break that message for anyone who's already localised it. I've changed the message key back to "last", and changed the default "last" message in pg.string instead. — Mr. Stradivarius ^{♪ talk ♪} 14:35, 2 January 2017 (UTC)

Enhancement: Show latest delete log entry for red internal links

This is just an enhancement request. It would be useful for when I hover over red links to see the latest delete log entry (if it exists) under it instead of having to go to the page to see it. Thanks for your consideration -- not a huge priority. Stevie is the man! ^{Talk • Work} 16:02, 5 January 2017 (UTC)

A use case for this would be when reviewing an article, I may want to hover over a particular red link, and if was deleted (rather than simply not created yet), that would tend to make me consider removing the link altogether, thus improving the article in that minor way. Stevie is the man! ^{Talk • Work} 16:34, 13 January 2017 (UTC)

Related to this, it would also be nice to see how many other articles link to that red link when I hover over it. This would also help me decide if the red link has merit. Of course, there are other aspects to that decision, but this bit of info helps. Stevie is the man! ^{Talk • Work} 16:38, 13 January 2017 (UTC)

New cur links faulty on user contribs lists

When using popups to look at user contributions, the new 'cur' link isn't working correctly. On the top line (most recent edit) it shows no change, as expected (as long as no-one else has edited the page since). But all the subsequent 'cur' links in the list show the diff to the top line's edit, even if the edit was to a different article. Result: crazy diffs like this. Inspection of the full url confirms the problem: &diff=nnnnnnnnn stays the same, while the &oldid=mmmmmmmmm changes. This is correct behaviour for page histories, but not for user contributions: it appears to be caching the top line's revision id when it shouldn't be. I've checked this on several different browsers and logged in as both this account and my other one - with the same effect.  —SMALLJIM  23:27, 5 January 2017 (UTC)

@Smalljim: I am unable to repeat this issue. I browsed through both my contributions and yours, looking at curs, and they all seemed correct. I assume you are talking about the cur links that appear when you hover over hist? Stevie is the man! ^{Talk • Work} 17:29, 6 January 2017 (UTC)

I see this too. Hover over any 'contribs' link, in a page history such as this one, and the 'cur' links are all broken. The first shows nothing as it does a diff between two identical revisions. Below that the diffs are with that revision and the top revision and so meaningless. 'cur' in page history compares that revision with the current one and so summarises all intervening edits. That makes no sense for a user’s contribution record as the edits are generally to different pages. It would be better to replace it with a 'hist', i.e. history of that page – as seen in any user’s contributions if you click through to them, such as Special:Contributions/JohnBlackburne.--JohnBlackburne^words_deeds 18:01, 6 January 2017 (UTC)

Using &diff=0 should fix the link for sure (i.e. when you click on it, you get the right page), but I hope it fixes the popup diffs too. --Tacsipacsi (talk) 18:44, 6 January 2017 (UTC)

I see it now, thanks to your explanation of the scenario. I think the problem is a little deeper, as in user contribution lists, the choices are supposed to be "(diff | hist) ", not "(cur | prev)". Stevie is the man! ^{Talk • Work} 19:10, 6 January 2017 (UTC)

Facepalm it appears to be caching the top line's revision id when it shouldn't be is exactly how I coded it. I don't think the cur links would be that useful on user contrib pages - should they just be removed? Enterprisey (talk!) 20:46, 6 January 2017 (UTC)

They could be changed to 'hist', so useful and matching normal contribution pages and the watchlist.--JohnBlackburne^words_deeds 20:49, 6 January 2017 (UTC)

Yes, that's nailed it: the real problem is that the user contributions lists in popups (as seen, for instance, when hovering over Special:Contributions/JohnBlackburne) should not show "cur | prev", but "diff | hist" – the same as the full page does.  —SMALLJIM  21:08, 6 January 2017 (UTC)

I'm currently neck-deep in the Popups source code, and there's this one piece of code that's used, as you might expect, by both the display-user-contributions code and the display-page-history code. It's possible to change the behavior of this one piece based on whether it's showing user contributions or a page history, so I'm writing some code for that now. Enterprisey (talk!) 21:14, 6 January 2017 (UTC)

Clarification: I forgot to mention what that one piece does. It takes the data about edits from the API and makes the actual links and text and whatever that gets shown to the user, and it's what I changed to make the "cur" links visible. Enterprisey (talk!) 21:15, 6 January 2017 (UTC)

Great work, Enterprisey: WP would be sooo tedious to use without Popups, so I'm really pleased that it's being supported again. If you ever find yourself with the inclination to enhance it further, perhaps you could consider Wikipedia talk:Tools/Navigation popups/Archive 9#Showing edit summaries :-)))  —SMALLJIM  22:04, 6 January 2017 (UTC)

Smalljim, alright, the finished product is in the sandbox, so if you (or anyone else reading this) wants to try it out during testing, you can install it just like a user script.

Regarding the edit summaries thing: it's being tracked in T138899 (and you can see everything that's being worked on on Phabricator as well). Enterprisey (talk!) 22:14, 6 January 2017 (UTC)

Wow, my request was already logged – that's impressive! I must remember to look at phab more often. Regarding testing the sandbox version, yes happy to try it. I've disabled the gadget and I assume that adding

mw.loader.load( 'SOMETHING&action=raw&ctype=text/javascript' ); to my vector.js will do it: if you could just tell me the SOMETHING that I need to add.  —SMALLJIM  22:31, 6 January 2017 (UTC)

I was trying to figure out how to set it up too, like other scripts in my common.js, but the results are very messy. I had to revert. Any instructions for testing are welcome. Stevie is the man! ^{Talk • Work} 22:39, 6 January 2017 (UTC)

Like this. Disable it in Special:Preferences#mw-prefsection-gadgets if you have it enabled there first. To Enterprisey, a brief check and it seems to be working perfectly.--JohnBlackburne^words_deeds 22:58, 6 January 2017 (UTC)

Thanks for testing! Wow, I didn't even know about importStylesheet(). I guess that's one good thing to come out of this, besides the writeup I did as I was writing the patch to keep myself from going crazy. Enterprisey (talk!) 23:04, 6 January 2017 (UTC)

@Enterprisey: The specified change for contribs shows (diff | hist) as expected and the links work. The only thing I'm seeing broken is the right paren missing for (cur | prev) on page histories. Stevie is the man! ^{Talk • Work} 23:27, 6 January 2017 (UTC)

Fixed, good catch! Enterprisey (talk!) 00:40, 7 January 2017 (UTC)

Working here too, thanks! JohnBlackburne, I thought that way of loading scripts was deprecated (I wrote myself a tetchy edit summary about it back in April.[3]) But it does still work.  —SMALLJIM  23:25, 6 January 2017 (UTC)

I filed an edit request. Enterprisey (talk!) 00:44, 7 January 2017 (UTC)

Footnotes and citations

By default, at least for me, Wikipedia already displays the contents of footnotes and citations when I mouse over them. However, the pop-ups extension interprets these as windows it must open as well, so the result is two of the same thing on the screen. Is there any way to make this stop? Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 07:14, 16 January 2017 (UTC)

The easier way is to disable Reference Tooltips in your preferences. The harder is to detect somehow in NavPopups if Reference Tooltips is active, and disable reference tooltips in that case. I’m not familiar with the code enough to know how difficult it is or if it’s possible at all. --Tacsipacsi (talk) 15:42, 16 January 2017 (UTC)

Indeed, Reference Tooltips aren't necessary if you're also using Popups, as Popups shows the same info. Stevie is the man! ^{Talk • Work} 15:55, 16 January 2017 (UTC)

That should work. Thank you. Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 05:42, 17 January 2017 (UTC)

Recognizable Article Level

Can there be a feature where popups can recognize articles that are GA, FA, and FL based on the level templates that are placed on the articles? -- 1989 (talk) 16:21, 19 January 2017 (UTC)

Sure, that's possible. I guess I could add a preference to turn it on, since not everybody might want to see it. Tracked at T155770. Enterprisey (talk!) 19:43, 19 January 2017 (UTC)

send thanks button

When I try to send thanks from popups, a new tab opens with this -- 1989 (talk) 14:07, 1 February 2017 (UTC)

Uh, that's weird. Confirmed and investigating. Enterprisey (talk!) 20:55, 1 February 2017 (UTC)

Unfortunately, this isn't one of those bugs that's gonna take only an hour to fix, since I have to change some stuff that's connected to everything. If I don't get some fix for this out in a few days, feel free to ping me here. Enterprisey (talk!) 21:21, 1 February 2017 (UTC)

@Enterprisey: --MCMLXXXIX 22:35, 12 February 2017 (UTC)

Section heading parsed wrongly

In the preview for the link to the section "Sprache" on this talk page, I’m getting Sprache= – wann du in welcher Vorlageneinbindung steckst, ist nach der Vereinheitlichung kaum noch auseinanderzuhalten. Nur werk= und url= unterscheiden dann noch von Sammelwerk= und Online as the section heading’s preview and no content preview. This appears to be an excerpt from another section, which is earlier than the section "Sprache" and contains = Sprache= in it’s text. Afaik = has to be the first character of a line to start a heading, which seems to not be checked in NavPopup’s parsing. (I’m using dewiki’s gadget, which imports the one from enwiki) --nenntmichruhigip (Diskussion) 09:09, 13 February 2017 (UTC)

Reverts/edits no longer autosaving

When I use popups to revert articles, the edits are no longer autosaving. The old version of the article is opened and the edit summary is populated but the edit isn't automatically saved; I have to manually click on the "Save changes" button. This has been happening for a few days now across multiple computers and different browsers. I have unchecked the popups tool option in my preferences, saved my preferences, and rechecked the option in an attempt to "reset" any potential changes I might have made or force an update if one is available.

Is this happening to anyone else? Does anyone have any ideas on how to fix this? ElKevbo (talk) 15:11, 16 March 2017 (UTC)

How about now ? removed old version —TheDJ (talk • contribs) 15:30, 16 March 2017 (UTC)

Nope; still happening. Thanks for trying to help! Any recommendations on how to proceed? ElKevbo (talk) 23:17, 16 March 2017 (UTC)

Forgive me if you've already tried this, but did you bypass your browser's cache after TheDJ's edit to your monobook.js? ​—DoRD (talk)​ 23:42, 16 March 2017 (UTC)

Yeah, no luck there either. Next idea? ElKevbo (talk) 01:28, 17 March 2017 (UTC)

Here's something odd: This works just fine if I click on the "revert" link for it to act in the same browser tab. But it fails when I right-click on the link and open it in a new tab. I typically use Firefox or Firefox-derivative browsers with the Tab Mix Plus addon so I'll begin testing in different browsers and with that addon disabled. ElKevbo (talk) 17:06, 19 March 2017 (UTC)

For what it's worth, this change happened for me also, several months probably up to about a year ago. Chrome and Firefox with no extensions. Perhaps your cache has only just been refreshed. -- zzuuzz ^(talk) 17:20, 19 March 2017 (UTC)

Missing user info if no contributions

When hovering on a User: link for an account that has made any edits, the popup includes a footer line with a list of permissions bits, the edit-count, the date the account was created, and the date of the most recent edit. If the account has not made any edits, that footer is missing altogether. When tracking vandals (especially possible sleepers at SPI) it would be useful to see the account-creation date. And it would also be useful to see an explicit "0" for edit-count, to help distinguish this actual piece of data from the popup stalling before completely rendering itself. And it also is important to see tags like "blocked" and "locked" so I don't waste my time trying to clean up a mess that has already been cleaned up. DMacks (talk) 21:11, 8 April 2017 (UTC)

The account that prompted this is both suppressed and globally hidden, so I don't think that the Popups script can even see the account. Thankfully, this is a rare case, and I don't know if there's any graceful way for Popups to handle it. However, I agree that it would be useful if Popups could display complete information for other accounts without any edits, as that's an issue I frequently encounter as well. ​—DoRD (talk)​ 21:24, 8 April 2017 (UTC)

In Special:Block for that account, MediaWiki:Centralauth-block-already-locked ("...is already locked globally.") is noted. But other than that, it's true that the account does not have a block in its log and there is no pink box on its contributions page. DMacks (talk) 21:33, 8 April 2017 (UTC)

suggestions

make the hoverzoom boxes show more.

need more info! less file descrptiony stuff too. — Preceding unsigned comment added by Rhodechill (talk • contribs) 04:16, 28 April 2017 (UTC)

Will this work with mobile devices?

Not finding anything in the FAQ or talk archives on this, so might as well ask: does this only work if you are using a mouse/trackball/trackpad, or will it work for touchscreen users? Beeblebrox (talk) 18:21, 29 April 2017 (UTC)

I don't think anyone has figured out how to implement tooltips when hovering on clickable links on mobile (touch) devices. -- Michael Bednarek (talk) 01:54, 30 April 2017 (UTC)

Red links

Sometimes when a red link is shown, a page already exists with a differently spelled title. To discover this, an editor could search the wiki (in the same namespace) for the link text. Could someone add a search link to the menu for red links? --Bdijkstra (talk) 09:27, 17 May 2017 (UTC)

Popups only working on some pages

For some reason popups are not working for me on most pages but are on some. Right now they work on Special:Mycontributions and Special:Watchlist, but nowhere else including articles and WP pages. Anyone else have this problem or know how to fix it? Reywas92^Talk 18:12, 17 May 2017 (UTC)

Most probably it’s caused by one of your user scripts (vector.js or monobook.js, depending on your skin). The easiest fix is to wrap the whole script in a call beginning with mw.loader.using( 'mediawiki.legacy.wikibits', function () { and ending with } );, but it’s only a temporary fix, since wikibits.js will go away entirely after some time. If you would like to have a permanent fix, you might do it yourself (here are the replacements) or ask for assistance on the village pump. (These JavaScript subpages can be edited only by you and by admins.) --Tacsipacsi (talk) 18:44, 17 May 2017 (UTC)

If it doesn’t work, then there are other errors too (these files do have errors for sure) which produce error messages shown on the browser console. Those show exactly where the error occurred and help correcting them. (N.B. I can help you finding the errors, but I don’t have any rights to actually correct them; you need admins for that.) --Tacsipacsi (talk) 12:45, 18 May 2017 (UTC)

Seeing whether a page is on your watchlist from the navpop

Tracked in Phabricator
Task T169115

It would be helpful to be able to see whether an article was on your watchlist without having to click it. Would it be possible to add a similar star to the navpop of articles so that you can see if the article is on your watchlist (and maybe even add it to your watchlist)? Absolutelypuremilk (talk) 07:28, 14 June 2017 (UTC)

Sure, that sounds like a good feature to add an option for. Tracked on Phab. Enterprisey (talk!) 16:37, 28 June 2017 (UTC)