Jump to content

Wikipedia talk:Tools/Navigation popups

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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.


Hint/tooltip glitches

[edit]

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)

IPv6 /64 ranges

[edit]

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.

References

  1. ^ As I understand it, IPv6 addresses are typically allocated in /64 blocks for each user by the provider. E.g., instead of your ISP allocating you a single IPv4 address of 189.201.223.245 (/32), and your router doing network address translation to your internal network of about 256 addresses in a block like 192.168.1.0/24 in a private use range, for IPv6 they will allocate 2A02:C7F:202:7500::0/64 to you and your internal network devices are assigned their addresses from that block (2A02:C7F:202:7500::0 through 2A02:C7F:202:7500:FFFF:FFFF:FFFF:FFFF).
[edit]

Since some weeks in german WP the visual diff view is active. But there the navigation popups dont work. They works only if I switch to the old wikitext mode. Is there a bug, or must I do some settings? Technical (I am web developer): It seems to me, there exists no event listeners for mouse movement.--Hlambert63 (talk) 17:42, 18 April 2023 (UTC)[reply]

It’s not implemented. Patches welcome —TheDJ (talkcontribs) 18:09, 18 April 2023 (UTC)[reply]
I think it should be implemented in visual diffs, not NavPopups, so I reported it at phab:T335199. —Tacsipacsi (talk) 16:28, 21 April 2023 (UTC)[reply]
@Tacsipacsi Yes, I would think so.
BTW: Today in 2 Diffs it worked, but at other didnt work. Dont know why.--Hlambert63 (talk) 14:13, 22 April 2023 (UTC)[reply]
It might be a race condition: if the visual diff loads first, by the time NavPopups loads, the diff is there and therefore the popups are added; however, if NavPopups loads first, it doesn’t find the visual diff on load, and later it doesn’t check it again (due to visual diffs not notifying it by firing the hook). —Tacsipacsi (talk) 00:43, 23 April 2023 (UTC)[reply]
@Tacsipacsi When the timing is the reason: Is it possible to load or re-ping / restart the NavPopups later in my Users common.js? (currently I activated it via a checkbox in my Settings)
At the console I saw, my common.js is called late, and if its too early, I'll find a way to defer a subfunction for a few seconds. Hlambert63 (talk) 18:16, 29 December 2023 (UTC)[reply]
@Tacsipacsi I meant, not I will find a way, but I could find a way for this, but I dont know, what function I must call to reload or restart NavPopups to re-establish the mouse-event-listeners.--Hlambert63 (talk) 13:19, 1 June 2024 (UTC)[reply]

I have found a 2nd bug: In Visual Diff the links to references leads to the article diff, I'd expect a link to the ref in ref-section (but it may be a collision with other popup-tools / -settings! – sorry *streichel* – I know a bulk of incoming bugs! ;-) )--Hlambert63 (talk) 18:04, 4 June 2023 (UTC)[reply]

Not working on Wikispecies

[edit]

This template script recently stopped working, for me at least (I've asked, but have had no response from other users there), on Wikispecies. I cannot figure out why. Can anyone help, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:02, 23 December 2023 (UTC)[reply]

@Pigsonthewing You can load popups from enwiki directly. E.g. you can load like this. -- Nux (talk) 17:16, 23 December 2023 (UTC)[reply]
@Nux: Thank you. That's a useful work-around, but I'd still like to identify and fix the issue, for the benefit of others. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 23 December 2023 (UTC)[reply]

This is stil an issue. Can anyone assist, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 6 June 2024 (UTC)[reply]

@Pigsonthewing. I'm able to reproduce. I'm getting a WP:CONSOLEERROR which is surely the root cause. jQuery.Deferred exception: Cannot read properties of undefined (reading 'join') TypeError: Cannot read properties of undefined (reading 'join') at setTitleBase (https://species.wikimedia.org/w/load.php?lang=en&modules=ext.gadget.Navigation_popups&skin=vector&version=10j03:116:944).
Rather than trying to debug that, the easiest fix is probably to ask an English Wikispecies interface administrator to copy past the contents of the following enwiki pages to the corresponding English Wikispecies pages: MediaWiki:Gadget-popups.js, MediaWiki:Gadget-navpop.css. Hope that helps. –Novem Linguae (talk) 17:02, 6 June 2024 (UTC)[reply]
Thank you. Wikispecies, like Commons, is language-independent, but maybe User:Koavf will kindly oblige? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 6 June 2024 (UTC)[reply]
 Done Let me know if more is needed. ―Justin (koavf)TCM 21:23, 6 June 2024 (UTC)[reply]
It's working for me now. This is probably fixed :) –Novem Linguae (talk) 03:47, 7 June 2024 (UTC)[reply]
Resolved
Justin (koavf)TCM 03:56, 7 June 2024 (UTC)[reply]
[edit]

Talk page timestamp links have been deployed to multiple wikis (all except English Wikipedia at the moment, example) and this gadget tries to show a preview when you hover on them, however as the fragment does not correspond to a section, the preview is always just of the entire talk page, which isn't very useful. I would suggest that any link with the class ext-discussiontools-init-timestamplink be ignored. More generally you may also want to ignore any hash fragment starting #c- or #h- as these don't correspond to a page section. ESanders (WMF) (talk) 13:05, 30 January 2024 (UTC)[reply]

@ESanders (WMF): I don't use this gadget, how can I opt in to use this new cool feature here? Nardog (talk) 06:02, 31 January 2024 (UTC)[reply]
The feature isn't available on English Wikipedia yet as we are still back-filling the index table required to do the redirecting when a comment is archived. In the meantime you can enable clickable timestamp links using my commentlinks.js user script (example). ESanders (WMF) (talk) 07:44, 31 January 2024 (UTC)[reply]

Logo used in place of lead image in popup

[edit]

I noticed this hovering over a link for Eurofighter Typhoon - the article's infobox has both an SVG logo used in branding and an image of the plane. in the code, this is accomplished thus:

{|{{Infobox aircraft begin  
| name = Eurofighter Typhoon
| logo = File:Eurofighter logo.svg
| image = File:RAF Eurofighter EF-2000 Typhoon F2 Lofting-1.jpg

In this case, the popup displays the logo, which is less useful than showing the image. I guess it does need to be able to use either | logo or | image, but which is more appropriate is conditional - an example of an article with an infobox containing both an image and a logo where the logo is more appropriate would be Bayer. Improving this might be a pain - use the image by default, but the logo if the article is categorised using any of the categories within Category:Companies? One cookie (talk) 13:51, 6 February 2024 (UTC)[reply]

@One cookie: I wouldn't worry about it, as this tool is aimed at editors not readers. As the documentation says, the code just picks the first image it comes across in the wiki text. At User:John of Reading/X2 I've swapped the parameters over, and popups is displaying the plane rather than the logo. -- John of Reading (talk) 14:25, 6 February 2024 (UTC)[reply]
And on the page, the logo still leads the image. Looks like a solution to me. Thanks! One cookie (talk) 14:29, 6 February 2024 (UTC)[reply]

Feature request: popups at bottom of page should not be cut off by bottom of page

[edit]

When hovering over a link that is near the bottom of a page, it'd be awesome if the popup was displayed at the top of the link instead of going out of frame at the bottom, just like classic article previews. Thanks a lot! Cocobb8 (💬 talk • ✏️ contribs) 16:20, 22 February 2024 (UTC)[reply]

By “classic article previews”, you mean mw:Page Previews, which is about a decade younger than NavPopups, right? 🙂 There are some differences (apart from the time difference of a decade) because of which the always-bottom display makes more sense in case of NavPopups than it would in case of Page Previews:
  • Page Previews always shows a constrained-length popup, while NavPopups popups can get very long (e.g. if I hover over the “contribs” link in your signature, I get a popup that’s almost twice as tall as my entire screen), thus
    • it’s much more likely that the popup doesn’t fit in the screen either way, and it’s even possible that it doesn’t fit the document; if a popup overflows at the bottom (or right) of the screen, browsers usually extend the scrollbar so that even the very bottom/right of it is visible, but if it overflows at the top (or left), it’s clipped and the overflowing part is inaccessible;
    • if some part of the popup doesn’t fit the screen, it makes more sense for it to be the bottom, as the first sentence of the article (which defines what it’s about), the latest page history entries (which are usually the most relevant) etc. are on the top.
  • NavPopups features a lot of tools and links, which are all at the top; if the popup was displayed on the top, one would move the pointer more to reach them. Page Previews has a single tool (the settings), which is hardly ever needed, its only purpose is to show the preview of the article. (Notice the difference in the name: Navigation popups is for navigation, Page Previews is for previews.) —Tacsipacsi (talk) 15:27, 23 February 2024 (UTC)[reply]
Ah, that makes much more sense, thank you! Cocobb8 (💬 talk • ✏️ contribs) 16:05, 23 February 2024 (UTC)[reply]

Hovering over topicons doesn't display hover text

[edit]

Articles that are protected in some sort (such as the POPUPS page) have protection padlocks as topicons. They normally have hover text to indicate duration. However, navpops replaces that with a preview of the linked page, and doesn't display the hover text anywhere for some reason. Aaron Liu (talk) 11:41, 14 March 2024 (UTC)[reply]

Works for me; all redirects in Category:Wikipedia fully protected pages show the 1st paragraph of the target page. -- Michael Bednarek (talk) 12:43, 14 March 2024 (UTC)[reply]
I'm not saying it doesn't show the linked page; I'm saying that the hover text, like "Editing of this page is restricted to autoconfirmed users indefinitely", doesn't show. Aaron Liu (talk) 12:47, 14 March 2024 (UTC)[reply]

Feature request: Support for colored text

[edit]

Hello!

I've come up with a potential upgrade that could make NavPopups even better than they already are:

Having preview popups support colored text would be a win! This would not find any uses in the mainspace, but would be quite useful in showing an accurate preview of people's user pages that include specially formatted/colored text.

Any thoughts?

Cheers, Cocobb8 (💬 talk • ✏️ contribs) 20:11, 27 March 2024 (UTC)[reply]

Add edit summaries to reverts

[edit]

Currently, the "revert" function does not allow users to add an edit summary explaining the revert. Only the default edit summary (Revert to revision xxxxxxxxxx dated yyyy-mm-dd hh:mm:ss by User using popups) can be used.
My question is: Would it be possible to modify Navigation Popups to allow users to put more information in the edit summary, in addition to what already exist? Unexplained reverts are bad for Wikipedia, especially when a good faith edit is reverted without reason in the edit summary. InTheAstronomy32 (talk) 12:11, 25 April 2024 (UTC)[reply]

Wiki tags are always excluded

[edit]

Howdy, may I ask a hopefully simple question. At the moment, any text between any wiki tags is always excluded from the navigation popup. This applies to standard tags like <span> but also to self-defined tags used in a small private extension. <span> is a very common way to modify the appearance of text, e.g. <span style="color:#FF0000"> but of course we would like to see the spanned text within the popup. Is there a way, or will there be plans, to define a list of wiki tags/html tags that will simply be stripped off the article without also removing the embedded content text? 2003:C2:3F21:FD00:FD5B:946E:6956:E8CF (talk) 10:46, 3 May 2024 (UTC)[reply]

Too bad that there's no support. 2003:C2:3F3F:4A00:893D:E160:9A20:A609 (talk) 14:48, 23 May 2024 (UTC)[reply]

Make it bigger ?

[edit]

For the longest time, popups has been 350px wide as a maximum. Is it time to raise the width to 500px perhaps ? —TheDJ (talkcontribs) 11:16, 24 June 2024 (UTC)[reply]

No objections here. But it's more limiting and frustrating that a popup only seems to be shown below the link, even when it's on the bottom of the screen. -- Michael Bednarek (talk) 12:05, 24 June 2024 (UTC)[reply]
+1 to a box-size increase. (And perhaps the font-size, afterwards?) Quiddity (talk) 19:49, 24 June 2024 (UTC)[reply]
You can change font by overriding existing CSS:
div.navpopup { font-size: 14px;}
Perhaps width logic can be modified to allow something similar... Though I think there where some options that influence width (so it might be dynamic...). Not sure. Nux (talk) 21:12, 24 June 2024 (UTC)[reply]
Yeah, I already do it for myself (and similar at non-Wikimedia wikis), but perhaps others might appreciate it? As we grow older, things look smaller! Quiddity (talk) 21:23, 24 June 2024 (UTC)[reply]

Property values on Wikidata

[edit]

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]

CJK zapped by default is terrible policy

[edit]

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]

Bug: Popup uses HTML em and strong in place of i and b

[edit]

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]