Wikipedia talk:Tools/Navigation popups#Show changes after disambiguation

Archives

1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12

This page has archives. Sections older than 90 days may be auto-archived by Lowercase sigmabot III if there are more than 15.

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.

Good day,

The altering of the action object property in the getPrintFunction function, in these two cases (lines 5679 and 5688):

	case 'unwatch': case 'watch':
		this.print=magicWatchLink; this.action=this.id+'&autowatchlist=1&autoimpl=' + popupString('autoedit_version') + '&actoken='+autoClickToken(); break;

	case 'delete':
		this.print=wikiLink; this.action='delete';
		if (this.article.namespaceId()==pg.nsImageId) {
			var img=this.article.stripNamespace();
			this.action+='&image='+img;

and its use for retreiving the i18n tooltip in the wikiLink function (line 6174):

	var hint=popupString(l.action + 'Hint'); // revertHint etc etc etc

result in tooltips with url code between the action term and 'Hint', like: un|watch for any watch/unwatch, and delete for images (hover to see). I guess the altering of action needs to be moved to the switch statement in the wikiLink function (starting at line 6178).

Another one is email user – the i18n key 'EmailuserHint' (line 7049) needs a capital U.

With kind regards — Mar(c). 12:20, 7 January 2019 (UTC)

It would be useful if links for IPv6 addresses (in contributions and watchlists), when moused over, could have an option to produce a list of contributions for the /64 range to which the address belongs instead of just the specific /128 address.^[1]

One way to do this would be by splitting the link into two pieces, like this:

2A02:C7F:202:7500:14B3:9AA7:46A3:B9E0

When you mouse over the left side, you should get the contribs for the 2A02:C7F:202:7500::0/64 range (which currently doesn't work). When you mouse over the right side, you get the contribs for just the specific 2A02:C7F:202:7500:14B3:9AA7:46A3:B9E0/128 address.

On Wikidata, when a user hovers over the value of a property, it would be useful if the popup displayed the description of the linked item, in the user's preferred language, if present.

For example, on Black Sabbath (Q47670), the value of location of formation (P740) is Birmingham (Q2256), whose description in English is currently "city in West Midlands, England". the title is useful for disambiguating the target from others with the same name, such as the one in Alabama. A null description would alert the user that one is required, at Wikidata.

Similarly, here on Wikipedia (and other projects), for a link to Wikidata, like d:Q2256, the popup could display the title (and possibly also the description). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:03, 1 September 2024 (UTC)[reply]

Whenever I hover over an item that shows the name of somebody in their native language, your app or whatever zaps it, as if "I'm not interested in those funny foreign characters". Well, that is the whole point of me wanting to see the mouseover. For instance, hover over Kawahara Keiga. We see "Kawahara Keiga ( , also known as..." You see that "( ,"? That's where the silliness occured. Jidanni (talk) 21:38, 18 October 2024 (UTC)[reply]

It has nothing to do with “funny foreign characters”: simply all templates are removed, whether they contain Japanese text, English text or non-text content. This is a known limitation, and one that’s unfortunately not likely to go away in the near future. —Tacsipacsi (talk) 08:44, 19 October 2024 (UTC)[reply]

Example: monkfruit

• From page:
  <i><b>Siraitia grosvenorii</b></i>, also known as <b>monkfruit</b>, <i><b>luo han guo</b></i>, or <b>Swingle fruit</b> ...

• From popup:
  <strong><em>Siraitia grosvenorii</em></strong>, also known as <strong>monkfruit</strong>, <strong><em>luo han guo</em></strong>, or <strong>Swingle fruit</strong> ...

The problem is that <i> and <b> are formatting tags while <em> and <strong> are semantic tags. They're not interchangeable even though the result looks the same in most cases. Myself, I have a CSS rule for <em> so that I can tell it apart from regular italics.

— W.andrea (talk) 19:18, 22 February 2025 (UTC)[reply]

Copied comment to MediaWiki talk:Gadget-popups.js. I might have found the problem in the source code too. — W.andrea (talk) 19:46, 22 February 2025 (UTC)[reply]

Hello,

When I hover over a link to a page, then hover over "actions", "most recent edit", then finally "send thanks", it does not work. Clicking it brings me to https://en.wikipedia.org/w/index.php?title=Special:Thanks/cur. Myrealnamm (💬Let's talk · 📜My work) 14:20, 27 April 2025 (UTC)[reply]

@Myrealnamm. Unable to reproduce. Is the thanks button in the popup or somewhere else? Is this only on one page or on all pages? –Novem Linguae (talk) 17:52, 27 April 2025 (UTC)[reply]

@Novem Linguae

Yes, it is in popups, and it happens on all pages. If I hover, say, your username (which is linked), under actions --> most recent edit --> actions --> send thanks, it does not work, but brings me to the invalid page linked above. Myrealnamm (💬Let's talk · 📜My work) 19:44, 27 April 2025 (UTC)[reply]

Ah I see. I'm able to reproduce now. This gadget isn't really maintained. But now that this is easy to reproduce maybe it'll attract someone interested in writing a patch. –Novem Linguae (talk) 22:09, 27 April 2025 (UTC)[reply]

The latest Tech news includes:

Gadgets and user scripts that interact with Special:Block may need to be updated to work with the new manage blocks interface. Please review the developer guide for more information. If you need help or are unable to adapt your script to the new interface, please let the team know on the talk page. [1]

Is this gadget likely to be affected? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 20 May 2025 (UTC)[reply]

Good question. Just now I went to Pigsonthewing -> User -> Block to see what it did. It redirects to https://en.wikipedia.org/w/index.php?title=Special:Block&ip=Pigsonthewing. That form will be updated to support multiblocks around June 2. Since blocking just redirects to that form instead of having something built in, I think popups will be unaffected. Thank you for checking. –Novem Linguae (talk) 18:08, 20 May 2025 (UTC)[reply]

Hi! When using dark mode, I find the color for external links (#36b) pretty hard to read. Could the contrast be improved? Other link colors are fine. As far as I can see, it should be --color-progressive (#88a3e8) instead. Thanks, XanonymusX (talk) 19:42, 28 June 2025 (UTC)[reply]

I've never seen a popup with an external link. Can you give an example? -- Michael Bednarek (talk) 02:31, 29 June 2025 (UTC)[reply]

Pretty much all the popups that preview footnotes with a weblink. XanonymusX (talk) 17:21, 30 June 2025 (UTC)[reply]

Here, popups omit all footnotes, viz: a popup of Dutch East India Company shows, "The United East India Company ( ; VOC ), commonly known as the Dutch East India Company, was a chartered trading company and one of the first joint-stock companies in the world. Established on 20 March 1602 by the" ... "trade activities in Asia." Note that the 2 footnotes after "world", and single footnotes after "1602" and "Asia." are not shown, and consequently the external links in those footnotes aren't shown, either. -- Michael Bednarek (talk) 00:08, 1 July 2025 (UTC)[reply]

Here's a screenshot of what I see for a popup of a random citation: phab:F62753939 showing citation #4 at Leavenworth Riverfront Community Center (with both Page Previews and Navpopups, because I have both enabled as a frequent software-tester!). I believe that is what XanonymusX is describing. HTH. Quiddity (talk) 01:11, 1 July 2025 (UTC)[reply]

Thanks, the screenshot is very helpful, as page previews shows the expected color! XanonymusX (talk) 07:24, 1 July 2025 (UTC)[reply]

Probably has to be fixed somewhere here MediaWiki:Gadget-navpop.css#L-197 —TheDJ (talk • contribs) 07:14, 1 July 2025 (UTC)[reply]

I didn't get it that the complaint was about popups to citations within a page, which I almost never use. Apologies for my off-topic babbling. -- Michael Bednarek (talk) 07:27, 1 July 2025 (UTC)[reply]

Before we forget about this: indeed, after line 206 we should add the styles for dark mode. I would use

/* Dark mode fixes */
html.skin-theme-clientpref-night a.extiw,
html.skin-theme-clientpref-night a.extiw:active {
  color: var(--color-progressive, #88a3e8);
}
@media (prefers-color-scheme: dark) {
  html.skin-theme-clientpref-night a.extiw,
  html.skin-theme-clientpref-night a.extiw:active {
    color: var(--color-progressive, #88a3e8);
  }
}

Any concerns? If not, could somebody with editing rights please make the change? Much appreciated. XanonymusX (talk) 18:58, 21 July 2025 (UTC)[reply]

Do those tokens need to be wrapped in var()? Have you tested this code to make sure it works? You can add {{IAER}} when you have tested it, confirmed it works, and are ready to request an interface admin to make the change. –Novem Linguae (talk) 03:06, 22 July 2025 (UTC)[reply]

I no longer have popups when hovering on images, can't figure out why. - FlightTime (open channel) 17:37, 6 July 2025 (UTC)[reply]

@FlightTime: I still see them (just tried it out on a topic above). Could you be more specific?

• Do you experience this on enwiki or somewhere else?
• If on enwiki, can you confirm that the image in that above topic doesn’t work either?
• Do you see any JS errors?
• Did you enable any gadgets or user scripts lately? At least for the gadgets, can you try disabling them one by one to see if the issue persists? (You can do it with user scripts as well, but that leaves behind a lot of edits.)

Tacsipacsi (talk) 19:53, 6 July 2025 (UTC)[reply]

@Tacsipacsi: I'll have to research the steps you brought up, that will take awhile, but thanx for the reply. I can ping you here if I find anything, if you don't mind. Cheers, - FlightTime (open channel) 20:27, 6 July 2025 (UTC)[reply]

I went through and disabled all .js and .css pages and still not working. Will work on gadgets next. If it turns out to be a gadget interfering, then I shouldn't be the only one. - FlightTime (open channel) 22:56, 6 July 2025 (UTC)[reply]

Try WP:SAFEMODE first before you go to the trouble of bisecting all your gadgets. If the error remains in safemode, then it is not a gadget and is something else (browser plugins, etc.) –Novem Linguae (talk) 00:33, 7 July 2025 (UTC)[reply]

I also thought about this, but I didn’t suggest it because it doesn’t really work: NavPopups itself is also a gadget, so if one goes in safe mode, NavPopups will also be disabled, AFAIK without any possibility for getting it back other than issuing manual JavaScript commands (or disabling safe mode). —Tacsipacsi (talk) 20:59, 8 July 2025 (UTC)[reply]

Oops. Duh. Never mind :) –Novem Linguae (talk) 23:06, 8 July 2025 (UTC)[reply]

Navigation popups does not seem to handle multi-blocked accounts properly. For instance, if you hover over User talk:NishantXavier, it will not say they are blocked, despite the account being multiblocked. It should instead show a message like "Has multiple blocks" (with the partial block message being changed to "Partially blocked" to prevent confusion). OutsideNormality (talk) 04:45, 11 July 2025 (UTC)[reply]

I edit on a Personal Wiki. Using Gadget:Navigation Popup; I hover over a link while disconnected from internet access.

Under these conditions; I get a popup as expected. Additionally; the popup displays unwanted links to tool menu items like; What link here. The popup with unwanted links persist when I cease to hover.

If I refresh the page; the unwanted popup ends.

If I toggle on internet access and refresh the page and hover again; the popup displays and ends properly and the unwanted links do not appear.

Is there a way to eliminate the persistence of the popup and the unwanted links from the popup while browsing a wiki offline?

1. Environment: Windows 11 - XAMPP
2. Browser: Chrome
3. MediaWiki: 1.41.5
4. PHP: 8.2.12
5. MariaDB: 10.4.32

1. PageImages
2. Previews
3. TextExtracts

1. Semantic MediaWiki: 4.2.0
2. Semantic Result Formats: 4.2.1
3. Semantic Cite: 3.0.0

Thank you AKSHA (talk) 16:53, 25 August 2025 (UTC)[reply]

@AKSHA: Do you get any error messages? —Tacsipacsi (talk) 12:30, 25 October 2025 (UTC)[reply]

I have "sizetoggle" enabled, but on click, it just resizes the small image, it doesn't actually load a larger image, so the image looks pixelated and low-quality. — W.andrea (talk) 02:31, 31 August 2025 (UTC)[reply]

Is this the feature that creates the simple, right-floated popup box that appears when you try to link a string that is a disambig page? The poup starts out, 'Would you like to make this link more specific?' To view an example, edit or reply to this section, and start typing [[Mercury]], and watch what happens when you reach the second closing bracket. If not, do you know what tool does this popup? I am looking for more information about it. Mathglot (talk) 22:24, 2 September 2025 (UTC)[reply]

Nope, that isn't this one. Based on "disambiguator-review-link" being in the HTML for the popup, looks like you're talking about mw:Extension:Disambiguator#Features. –Novem Linguae (talk) 23:00, 2 September 2025 (UTC)[reply]

Much appreciated. I don’t want to admit how much time I spent looking around for that! Mathglot (talk) 00:10, 3 September 2025 (UTC)[reply]

Presently, Navigation popups support quickly checking on iterated/nesting mouseover inspection, everything from page "History" and "What links here", to user home & talk pages and contribution logs. The convenient mouseover iterative deepening exploration works for any page (linked to in rendered output) but excludes the present page loaded. Let's support Navigation popups mouseover of the title, or the edit button at pagetop (and on optionally enabled per-section edit boxes -- so it's always in easy reach.) How feasible would this change be? And concerns? Shall I draft a change? Mcint (talk) 03:38, 15 September 2025 (UTC)[reply]

I already did that on plwiki. It's quite easy - just allow users to hook into popups and add any number of extra things to view. Like the history button or read button/tab or whatever else you want. It works nice. Never had problems with it. You want a diff to merge? Nux (talk) 07:42, 15 September 2025 (UTC)[reply]

or the edit button at pagetop – doesn’t popupOnlyArticleLinks do exactly this? It doesn’t seem to work on section edit links, but it does work in the table of contents, so it’s always at reach if you use the default desktop skin. (Speaking of user pages and user talk pages, it even works on the user page, talk page and contribs links in the top right personal toolbar.) —Tacsipacsi (talk) 12:27, 25 October 2025 (UTC)[reply]

this seems like a useful tool but it doesn't exactly work the way i want by default. i would like the regular page previews to show up when i hover over a link to an article and the navigation popup to appear for basically everything else (notes, references, portals, projects, etc), or at least an easy way to switch between the two. is there a setting or plugin that does this? WikiLinuz asked a similar question in 2023 but got no answer. LARAUJO (talk) 23:47, 23 November 2025 (UTC)[reply]