Archives

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

Sections older than 90 days may be automatically archived by MiszaBot II.

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.

v t e Navigation popups
Info	Navigation popups (talk) /FAQ (talk) /Translation (talk)
misc.	/About fixing redirects (talk) /Pages with buggy previews /Structure examples /Technical details
Code	MediaWiki:Gadget-popups.js talk sandbox diff MediaWiki:Gadget-navpop.css MediaWiki:Gadgets-definition

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.

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[reply]

It’s not implemented. Patches welcome —TheDJ (talk • contribs) 18:09, 18 April 2023 (UTC)Reply[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[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[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[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[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[reply]

There appears to be a bug with the Redirect bypass feature from the Popup window if the link is piped. The available options are "Fix target or target & label", yet both of them perform the same function (for piped links). My expectation was that if I use Fix target, then the target link would be fixed, yet the piping of the link would remain unchanged. On the other hand, if I use Fix target & label, then the piping would simply be eliminated, and the new link would be an unpiped link directly to the new target.

Note that the behavior is as expected on redirects where there is no piped link involved. I have used the Draft sandbox with the Redirect example from Wikipedia:Tools/Navigation popups/About fixing redirects to illustrate this:

• This is the result of Fix target
  • Y The piped link remains piped, as I would expect.
  • Y The unpiped link becomes piped in order to retain the original text, as I would expect if only changing the target.
• This is the result of Fix target & label
  • N The piped link remains piped, and only the target is changed when I would expect the target AND label to change (effectively eliminating the piped link).
    • This is the buggy use case.
  • Y The unpiped link remains unpiped, and displays the new label, as I would expect if changing the target and label.

Now, in the example I'm using, having a disambiguated/anchored link display in normal text is a bit unruly for prose, but I would expect that the user should be using "Fix target" only option if they are trying to preserve the prose text and correct the target link.

I am coming across this since this Popups feature is pretty nice when performing WP:POSTMOVE cleanup. Sometimes a page is moved from a title with a parenthetical or WP:QUALIFIER dab to one with a WP:NATURAL dab that might be entirely different when subjects are renamed. I recognize that these redirects are WP:NOTBROKEN, but there are some cases where the new title can provide more appropriate context to the reader, and some should be selectively updated. -2pou (talk) 18:01, 5 May 2023 (UTC)Reply[reply]

Let’s assume Morphosyntax was redirected to Morphological syntax instead of Morphology (linguistics)#Paradigms and morphosyntax. (Probably no such term exists, but that’s irrelevant in this example.) Let’s assume you want to fix the redirect in the first sentence of Nafsan language#Indirect/general possession, which currently sounds Indirect possession is morphosyntactically represented through […]. If not only the target, but also the label was changed, it sounded Indirect possession is morphological syntax represented through […], which is grammatically incorrect. This is why non-default labels shouldn’t be replaced automatically (and even default labels should be preserved, i.e. the Fix target mode should be used, if the redirect is a different part of speech than the target). —Tacsipacsi (talk) 11:29, 6 May 2023 (UTC)Reply[reply]

That's a good example of when "fix target" should be used, and it works correctly. "Fix target & label" wouldn't do what we want here, with or without bugs. It's for other cases. Suppose I write [[David Williams|Williams]] when I meant [[David Walliams|Walliams]]. Then, we'd want to change both misspellings. However, the old label will almost always differ from the old target, and the new label should probably differ from the new target in a similar way. In this case, it's by omitting the given name, but in general it's by no means obvious what it should be changed to and not the script's job to guess. Certes (talk) 12:05, 6 May 2023 (UTC)Reply[reply]

Forgot all about this... I see your point for not making an assumption. What I'm struggling with now is when anyone should be using Fix target & label. It seems like the two behave the same. Maybe I misinterpreted the intention, but I was always reading "label" as the displayed text of a piped link. Is that incorrect? So when would we need to Fix target & label? If I did understand correctly, then the "fix" would have to become more complex as Certes points out, where the UI would have to prompt the editor to input a new label that should be used. -2pou (talk) 15:41, 16 May 2023 (UTC)Reply[reply]

"Fix target & label" is useful as-is for unpiped links. It's for when we want to change [[David Williams]] to [[David Walliams]], changing the displayed text in the same way as the link target (by default, because there's no pipe). For it to become useful for piped links, we'd have to work out the new displayed text, either by letting the editor type it in or by calculating it implementing a vague specification such as "obtain the new display by modifying the new target in the same way that the old target was modified to obtain the old display". The problem is that seeing one piece of text modified into another provides an example rather than a general algorithm. Certes (talk) 10:17, 18 May 2023 (UTC)Reply[reply]

When attempting to display the contents of an article that contain the percent sign "%" (e.g. 1% rule), it fails with a message The requested page title contains invalid characters: "%25" (inside JSON).

An example of a full message displayed: {"batchcomplete":true,"query":{"pages":[{"title":"1%25_rule","invalidreason":"The requested page title contains invalid characters: \"%25\".","invalid":true}]},"limits":{"images":500,"categories":500)) Naruyoko (talk) 22:51, 28 May 2023 (UTC)Reply[reply]

I see now* that previews, of sections(!), are available from the ToC, gated by an option. However, linking to a section of another page does not show previews of that section, just the linked page's overview preamble. This seems feasible to improve. Mcint (talk) 05:36, 2 June 2023 (UTC)Reply[reply]

When previewing popups, it's convenient recurse into popups of embedded pages, or via the actions menu. However, when mousing-over onto other pages, ending mouse-over of the original popup's (obscured) area causes the original to close. I would like have the path to root visible. It looks like there's not a setting for this. Anyone else also interested? I would put in some time to use this on other wikis in the future. Mcint (talk) 06:25, 2 June 2023 (UTC)Reply[reply]

Hi! Kind regards. I wanted to ask if the gadget allows to preview specific section in articles. Pinging @Tesugi:, who had the original question. NoonIcarus (talk) 07:50, 27 July 2023 (UTC)Reply[reply]

I'm delighted with what appears when I hover over a link. However, when I hover over the same link again later, I sometimes see just the article title and no content. It happens mainly (perhaps exclusively) when I hover over a redirect then slide the pointer onto the target to see the start of the target article. Do other users also see this? If so, would it be easy to change the behaviour so the start of the article text appears again? Certes (talk) 19:35, 2 August 2023 (UTC)Reply[reply]

I can reproduce that bug. For example: The WP:POPFAQ link initially shows the redirect-target's content, but the 2nd mouseover doesn't. Quiddity (talk) 22:09, 2 August 2023 (UTC)Reply[reply]

I found that using the "popups / reset" function will restore the initial behaviour. -- Michael Bednarek (talk) 01:15, 3 August 2023 (UTC)Reply[reply]

Thanks for the tip. I've done that successfully, so this is not urgent missing functionality, purely a convenience issue of not having to click Reset. Certes (talk) 07:58, 3 August 2023 (UTC)Reply[reply]

https://phabricator.wikimedia.org/T348606 Jidanni (talk) 09:30, 14 October 2023 (UTC)Reply[reply]

as of 2023-08-17, and already a couple of weeks before that, the usability of "Navigation popup" has regressed (at least to my observation) on mobile browsers (tested with Firefox Android and Chrome Android... maybe the issue always existed, but I didn't notice it before):

When using mobile / touch devices, the popup appears when long-touching a link. Long-touching a link is the typical interaction to open a context menu with the intention to open that link in an additional tab/window.

on mobile devices with their small screen, an unintended popup appearance obscures a significant share of the current viewport content.

While technically long-touching results in mouseenter/mouseover/mousemove/focus events firing (therefore causing "Popup Navigation" to notice), there are means to better disambiguate a user's actual intentions on mobile phones.

See:

• https://developer.mozilla.org/en-US/docs/Web/API/Touch_events/Using_Touch_Events
• https://patrickhlauke.github.io/touch/
• https://patrickhlauke.github.io/touch/tests/event-listener.html

Abdull (talk) 22:16, 17 August 2023 (UTC)Reply[reply]

There are articles such as Lebanon and Economy of Lebanon for which the opening text doesn't appear under the metadata in the popup as it does for most articles. Is it some template placed in front of the lead that's causing this? Largoplazo (talk) 03:30, 24 September 2023 (UTC)Reply[reply]

I suspect that happens when articles have an extraordinary long infobox, and popups doesn't get to the beginning of the prose. Same thing happens at United States. -- Michael Bednarek (talk) 04:34, 24 September 2023 (UTC)Reply[reply]

Infoboxes generally have a table class parameter matching infobox.*; could the parser see that and skip the table? Orange Suede Sofa (talk) 05:50, 24 September 2023 (UTC)Reply[reply]

No. Popups has it's own preview system based on full wikitext of the article. It doesn't actually render any of the wikitext. The extract/abstract have to be within the first 10k characters. And in this case the infobox is... well... quite long ;). The text ends with "ethnic_groups" parameter at the moment. Nux (talk) 21:34, 24 September 2023 (UTC)Reply[reply]

Infoboxes, including long ones, being a reality, I wonder whether the popup code could be modified to skip it rather than counting on there to be plain text within the first 10K characters. Largoplazo (talk) 21:53, 24 September 2023 (UTC)Reply[reply]

I think the easiest fix would be to modify an option for yourself(s): `window.popupMaxPreviewCharacters = 8000;`. Popups takes double that to generate a preview.

I guess that the preview could be optimized by doing a quick search for multiline templates on top and removing them before doing anything else... Would not be easy though. Would require testing on slow PC to see if using a simple template parser would be fast enough. I mean I have something like that, but not sure if that would be faster then the killer function in Popups (probably more accurate, but might not be faster). Nux (talk) 21:55, 24 September 2023 (UTC)Reply[reply]

A modern version of Popups that augments the software's built-in preview function (which is able to deal with Economy of Lebanon) by all of the nice links we use and love it for would be really nice. —Kusma (talk) 22:05, 24 September 2023 (UTC)Reply[reply]

@Kusma the new core preview function has it's own problems. Doesn't even try to handle anything outside the main namespace... And sometimes doesn't even handle main namespace (phab:T346686, phab:T272394). Nux (talk) 22:12, 24 September 2023 (UTC)Reply[reply]

Do you know what “doesn't even try to handle anything outside the main namespace” means? Does the backend it uses provide no information on non-mainspace pages, or does just the frontend not query that information? If the latter, that wouldn’t affect NavPopups. For the mainspace bugs, the current preview could be kept as a backup, especially as the new “core” preview function is actually not MediaWiki core, but an extension, so third-party users of NavPopups may not have it. —Tacsipacsi (talk) 07:26, 25 September 2023 (UTC)Reply[reply]

@Tacsipacsi it's by design. I did some tests recently (due to some bugs in the pagepreviews) and when you move an article from the main namespace to the user namespace the API will no longer generate an abstract. Apparently this is be design, but seems like a bit weird choice (if for nothing else, it makes testing hard). There are other weird design choices -- e.g. it removes born/died info from a bio (which I find important). As for the placement in code -- you are right, the API comes from mw:Extension:Popups too (didn't notice that before). A longer description is on mw:Page Previews and subpages. Nux (talk) 12:05, 25 September 2023 (UTC)Reply[reply]

That doesn't happen here. For me, popups in the User space look no different, i.e. any page in Special:AllPages/User: or Special:AllPages/User_talk:. It even shows the broom in User:Nux/Code Cleanup. -- Michael Bednarek (talk) 13:25, 25 September 2023 (UTC)Reply[reply]

I don't know why they used the name "Popups" for the extension. Maybe Lupin should've trademarked that ;). The popups extension is something different then the actual Popups (gadget). The extension uses this API: api/rest_v1/page/summary/User:Nux%2FCode_Cleanup (notice empty extract on the bottom of JSON). Nux (talk) 13:35, 25 September 2023 (UTC)Reply[reply]

Hence why Nux said "the new core preview function has its own problems", because it doesn't match what the Navigation Popups renders (which you likely use). New also being relative btw. as it's already 9+ years old now. A significant number of the readers will not even have been born when Navigation Popups was written (2005). The first iPhone is 4 years younger than this gadget, the Wikimedia foundation had just started and had not hired its first employee yet. websites were mostly still text only, as images were 'expensive'. —TheDJ (talk • contribs) 15:13, 25 September 2023 (UTC)Reply[reply]

My mistake. I was talking about the subject of this talk page, "Navigation popups" and didn't read Nux closely enough to notice that he was talking about "Page Previews". -- Michael Bednarek (talk) 16:31, 25 September 2023 (UTC)Reply[reply]

((geodis)) is a redirect to ((Place name disambiguation)). However, if I use the latter on a disambigution page, popups will not display any dab links. Popups will only show the links if ((geodis)) is used. Is this a bug or intentional? RedWolf (talk) 03:22, 26 October 2023 (UTC)Reply[reply]

I can't duplicate that behaviour. Here, hovering over Central Coast (which uses ((place name disambiguation))) or Clark County (which uses ((geodis))) both yield pop ups with their content. The difference I notice is that the pop ups for the former don't offer "Click to disambiguate this link to:", which is annoying and might be worth fixing. -- Michael Bednarek (talk) 05:16, 26 October 2023 (UTC)Reply[reply]

Yes, when I said it will not display dab links, I meant the "Click to disambiguate..." followed by each of the links. I just changed Mount Reynolds back to using ((place name disambiguation)) and it currently illustrates the issue. I wonder if the number of redlinks it currently has is what is causing the issue. In the case of Central Coast I wonder if the headings are causing the issue. RedWolf (talk) 19:08, 26 October 2023 (UTC)Reply[reply]

Looking at some of pages that use pnd that also show the issue: Elbow Lake, Minnesota, Highland, Indiana, Dickinson, New York, Buckingham Township, Pennsylvania. Those are all pages with just 2-4 links and no headings. RedWolf (talk) 19:19, 26 October 2023 (UTC)Reply[reply]

Indeed it depends on the template name. This is again an ancient feature that doesn’t make use of features introduced to MediaWiki in the past decade or so. It matches the page wikitext against the regexp

/\{\{\s*(d(ab|isamb(ig(uation)?)?)|(((geo|hn|road?|school|number)dis)|[234][lc][acw]|(road|ship)index))\s*(\|[^}]*)?\}\}|is a .*disambiguation.*page/im

instead of relying on the presence of the __DISAMBIG__ magic word. —Tacsipacsi (talk) 21:05, 26 October 2023 (UTC)Reply[reply]

Apparently, ((Place name disambiguation)), and others, call ((dmbox|type=disambig)) which then emits that magic word. Could Popups use that? Which text is interrogated by that regex? The wikitext an editor sees, or an expanded version that gets displayed? Can Popups see categories applied by templates, or only those specified in the wikitext? -- Michael Bednarek (talk) 14:27, 27 October 2023 (UTC)Reply[reply]

It matches against the wikitext an editor sees. It could be modified to match against the expanded version, but I think it would be easier and more performant (no need to download the whole expanded wikitext), and in any case would work more reliably across wikis (no need to create a local list of disambiguation templates specifically for NavPopups) to look for __DISAMBIG__ or its translated version by querying page properties: https://en.wikipedia.org/w/api.php?action=query&prop=pageprops&titles=Main%20Page%7CCentral%20Coast%7CClark%20County&ppprop=disambiguation – Main Page doesn’t have "pageprops": {"disambiguation": ""}, while both Central Coast and Clark County have. —Tacsipacsi (talk) 10:25, 28 October 2023 (UTC)Reply[reply]

I've been reading up on this at mw:Extension:Disambiguator and came to the same conclusion. I guess such an API query could then replace the regex? Who can implement that? -- Michael Bednarek (talk) 12:19, 28 October 2023 (UTC)Reply[reply]

I think so. Anyone who understands the code can make an edit request. (I may give it a try, but not now, and I can’t promise anything.) —Tacsipacsi (talk) 23:18, 28 October 2023 (UTC)Reply[reply]

I went the easier route, modifying my popups configuration:

popupDabRegexp='(\\{\\{\\s*disambig(?!uation needed)|disambig\\s*\\}\\}|disamb\\s*\\}\\}|disambiguation\\}\\}​|dab\\s*\\}\\})|\\{\\{\\s*(((geo|hn|road?|school|number)dis)|[234][lc][acw]|(road|ship)index)(\\s*[|][^}]*)?\\s*[}][}]|is a .*disambiguation.*page';

by adding |disambiguation\\}\\} capturing "disambiguation))", and it works. -- Michael Bednarek (talk) 01:23, 29 October 2023 (UTC)Reply[reply]

PS: I just noticed that I took the code for popupDabRegexp from the overleaf documentation as my starting point, not from mw:Gadget-popups.js; they are slightly different. The decentralised discussions and documentation are irritating. -- Michael Bednarek (talk) 01:48, 29 October 2023 (UTC)Reply[reply]

I now took the regex at mw:Gadget-popups.js as my starting point and came up with:

popupDabRegexp='disambiguation\\}\\}|\\{\\{\\s*(d(ab|isamb(ig(uation)?)?)|disambiguation\\}\\}|(((geo|hn|road?|school|number)dis)|[234][lc][acw]|(road|ship)index))\\s*(\\|[^}]*)?\\}\\}|is a .*disambiguation.*page';

YMMV. -- Michael Bednarek (talk) 02:28, 29 October 2023 (UTC)Reply[reply]

This template 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[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[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[reply]

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[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[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[reply]

When I have Navigation Popups or Reference Tooltips on, I get barraged with the following: Javascript Error https://en.wikipedia.org/w/load.php?lang=en&modules=ext.popups.main&skin=monobook&version=1ul2s at line 35: Uncaught SyntaxError: Failed to execute 'closest' on 'Element': The provided selector is empty. czar 14:45, 30 January 2024 (UTC)Reply[reply]

I think this is fixed now. Some other problem caused the problem with popups. See Wikipedia:Village_pump_(technical)#Empty_element_error?. You may need to do a hard reload, to clear out cached pages. --Salix alba (talk): 17:47, 30 January 2024 (UTC)Reply[reply]