Jump to content

Wikipedia talk:Tools/Navigation popups/Archive 12

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 10Archive 11Archive 12

Broken?

Has this broken? Hovering over a link only gives the target page with no preview for me. Eg, "violates any copyrights" only show Wikipedia: Copyright violations. Gaia Octavia Agrippa Talk 20:46, 27 July 2022 (UTC)

It's working again for me. Might have been a blip or an issue at my end. Gaia Octavia Agrippa Talk 21:12, 27 July 2022 (UTC)
I see that occasionally, especially if I have already hovered over that link previously. Selecting popups→reset from the popup menu sorts it out. Certes (talk) 21:44, 27 July 2022 (UTC)

collision with harv ref style

There's a collision with harf ref template, for example {{Harvard citation no brackets}}. Take Old Chinese as an example, when you put Computer mouse over the "115.^ Norman (1988), p. 95." on Old_Chinese#Citations's References/Citation section (1094133878), the popup will only show the Lead_section; However if popup is disabled, the popup frame will show the cited book (Norman, Jerry (1988), Chinese, Cambridge: Cambridge University Press, ISBN 978-0-521-29653-3.)

By the way, if you click the 115# reference, it will still take you to Old_Chinese#CITEREFNorman1988.

Environment: Windows 11, Firefox 102, Wikipedia Timeless skin. Kethyga (talk) 08:16, 30 July 2022 (UTC)

Here (MonoBook skin, also when temporarily using Timeless), popups over Harvard citation links always shows the beginning of the article itself. Tha happens in every article. -- Michael Bednarek (talk) 10:04, 30 July 2022 (UTC)
Kethyga My personal experience with Template:Harvard citation no brackets, ie {{harvnb}} is that it works, but harvnb is deprecated. Over the years, I have settled on a hard-coded reference name and date:
<ref name= CamelCaseName >AuthorName [URL (date) Title ] additional information here</ref>{{rp|page number}}
because I have come to rely on Navigation popups, in which I hover the cursor over the wikilink. The popup will faithfully display the relevant text, and not just the beginning of the article.
In particular, the hard-coded reference's name is best thought of as an editor's mnemonic: chooseYourMnemonicHere : a CamelCase single-word mnemonic conveys an entire phrase, which could convey a summary. The same holds for (date), which you can customize for the reference's needs. The reference Title can then be cut/pasted into the ref.
If I have to, I can then append {{rp|page number}} to the citation, but not always, on a case-by-case basis.
Camp Kosciuszko is a understandable example of this technique, which I have found can scale to hundreds of refs, as a live example of Popups working for the ref markup, and also for the efn template. Note how multiple named refs can be embedded in a named efn, which itself can summarize the refs.--Ancheta Wis   (talk | contribs) 12:24, 30 July 2022 (UTC) 23:35, 30 July 2022 (UTC)
{{Harvard citation no brackets}} is not deprecated; parenthetical citations are. Your observations about popups are correct, but for large articles with hundreds of references to a limited set of sources (e.g. Frédéric Chopin, {{sfn}} and its siblings have a place. -- Michael Bednarek (talk) 14:16, 30 July 2022 (UTC)
Thank you, so the correct slogan in editor language might instead be "harvnb works, but (citations, parenthetical; after 2020) are deprecated" ? --Ancheta Wis   (talk | contribs) 16:53, 30 July 2022 (UTC)
I have used refn, and know it can scale up with multiple named refs, but I have no experience with sfn. I know that multiple named refs can be used to source/summarize a sentence inside a named efn. Ancheta Wis   (talk | contribs) 23:35, 30 July 2022 (UTC)

Title attribute bug

The title attribute of a link is removed as soon as you move the mouse over the link, so you can disable all link titles just by moving the mouse fast.

At least re-add it on mouse out (if popup isn't shown)? Better yet, remove it just before the popup shows (unless the tooltip with title doesn't disappear after removing that attribute). MarMi wiki (talk) 20:46, 9 January 2023 (UTC)

conflicts with kartographer

the navigation popups for links to pages starting with a <mapframe> of kartographer only shows a single '[', see the link on de:Benutzer:Herzi Pinki/kartographer-popups. best --Herzi Pinki (talk) 08:25, 16 January 2023 (UTC)

Two wishlist proposals

I've proposed two wishlist entries related to NavPopups, for things that have been discussed a lot over the last 10+ years:

Please edit/improve the proposals directly or comment there, before 6 February. (Voting starts 10 Feb). Thanks! Quiddity (talk) 03:40, 29 January 2023 (UTC)

There have been multiple requests to expand the User menu to include a link to Special:CentralAuth. This is really important to editors who do cross-wiki work, such as global sysops and anti-spam folks. Could we please have this one link added? WhatamIdoing (talk) 19:09, 23 August 2022 (UTC)

+1. —MarcoAurelio (talk) 18:17, 8 February 2023 (UTC)

Issue with vector 2022

Due to the changed layout of vector, it seems that navpopups now show for the action tabs, as they are inside the content. This is determined in the function defaultPopupsContainer. The question now, is how to fix this.. There is no quick an dirty way that doesn't effect vector legacy.. The only thing i can think of is adding: document.querySelector('.skin-vector-2022 .vector-body') into the block before. I think that is safe, as browsers not supporting querySelector should no longer be supported as far as I can tell... diff. There are probably some other options, but this seems like the quickest fix. —TheDJ (talkcontribs) 22:30, 18 January 2023 (UTC)

@TheDJ this doesn't seem to have worked for me, did your test work? — xaosflux Talk 01:36, 19 January 2023 (UTC)
Caching, it seems to be working now. — xaosflux Talk 01:37, 19 January 2023 (UTC)
Fwiw, I thought this was a feature! I've really appreciated having direct access to the recent History via NavPopups, over the months I've been using/testing vector-2022. "Bug or Feature: Yes!" Quiddity (talk) 03:42, 29 January 2023 (UTC)
I also considered this a feature (although I knew it was technically a regression). By the way, Timeless is still “broken”, i.e. popups appear when I hover over the “tabs” (which are visually even less tabs than in Vector 2022). —Tacsipacsi (talk) 00:35, 30 January 2023 (UTC)
I did not realize that was a "bug", on Timeless I love being able to quickly see history so please put me in the "it's a feature" camp :) Legoktm (talk) 04:46, 9 February 2023 (UTC)
I’m pretty sure there is a config option to have pop-ups apply to the entire page! But that is not the default. —TheDJ (talkcontribs) 07:48, 10 February 2023 (UTC)
Aha, yes! window.popupOnlyArticleLinks=false; adds this back (and adds it to links in the personal-bar and site-sidebar). Thanks! (FYI @Legoktm, Certes, and Tacsipacsi:.) Quiddity (talk) 18:54, 10 February 2023 (UTC)
I love this feature. It saves me lots of time loading pages, and probably reduces server load too. Please, please don't "fix" it. Certes (talk) 12:40, 9 February 2023 (UTC)

Display block reason

Hello. Can you add the display of block reason if a user is blocked?
Previous is below
User:Partha Chakraborty ⋅ actions ⋅ user ⋅ popups
BLOCKED, 19 edits since: 2023-02-18, last edit on 2023-02-19

Now it could be:
User:Partha Chakraborty ⋅ actions ⋅ user ⋅ popups
BLOCKED:Undisclosed paid editing in violation ..... , 19 edits since: 2023-02-18, last edit on 2023-02-19 Lemonaka (talk) 19:55, 19 February 2023 (UTC)

This script has no activ3 maintainer, but if you write the patch, someone might be willing to deploy it. —TheDJ (talkcontribs) 18:24, 27 February 2023 (UTC)

Hello. The "edit counter" link uses https://tools.wmflabs.org/supercount/index.php?user=$user_name&project=$project_domain which redirects to https://xtools.wmflabs.org/ec/$project_domain/$user_name. Could you please update it at MediaWiki:Gadget-popups.js#L-8695 (although there are other lines that mention "supercount"). Thank you. —MarcoAurelio (talk) 18:26, 8 February 2023 (UTC)

@MarcoAurelio See: MediaWiki_talk:Gadget-popups.js#rvslots_and_edit_counter_fixesTheDJ (talkcontribs) 11:39, 12 April 2023 (UTC)

The tool is almost useless for links to content model CSS, flow-board, Scribunto, json, javascript - pretty much everything that isn't wikitext. Rather than showing true content, the following appears:

{"batchcomplete":true,"warnings":{"main":{"warnings":"Subscribe to the mediawiki-api-announce mailing list at for notice of API deprecations and breaking changes. Use Special:ApiFeatureUsage to see usage of deprecated features by your application."},"revisions":{"warnings":"Because \"rvslots\" was not specified, a legacy format has been used for the output.

It seems that one parameter has to be added to the API query for it to be happy. Can it be fixed, please? Thanks! אוהב חכמה (talk) 12:16, 13 March 2023 (UTC)

Yeah those aren't really supported. However the deprecation warning makes it worse, as it replaces whatever it would have otherwise displayed. I'm fixing the deprecations with MediaWiki_talk:Gadget-popups.js#rvslots_and_edit_counter_fixesTheDJ (talkcontribs) 11:41, 12 April 2023 (UTC)

Disabling popups for references/citations

I just started using this tool (really useful!) but I noticed it also opens popups for citations/references in a page. Example, if I visit a page and hover over one of the citations, example "[32]", it uses a popup. How do I disable it? I only want to use this tool for Wikilinks inside an article and not for citations/references/notes. Here's my current settings User:WikiLinuz/vector.js (I even explicitly set popupOnlyArticleLinks to true), I see popupOnlyArticleLinks is by default set to true so I'm not sure why it's still showing popups for citations. Am I missing something? --WikiLinuz {talk} 01:11, 18 May 2023 (UTC)

Bug with redirect fixes

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
    • Green tickY The piped link remains piped, as I would expect.
    • Green tickY 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
    • Red XN 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.
    • Green tickY 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)

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)
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)
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)
"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)

Error when the article title contains the percent sign

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)

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)

Persisting parent popups in a chain?

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)

Section preview

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)

mobile/responsive/touch/Android usability issue with touch versus mouse

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:

Abdull (talk) 22:16, 17 August 2023 (UTC)

Opening text not appearing in popups for some articles

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)

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)
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)
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)
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)
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)
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)
@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)
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)
@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)
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)
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)
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 (talkcontribs) 15:13, 25 September 2023 (UTC)
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)

Revisit a popup

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)

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)
I found that using the "popups / reset" function will restore the initial behaviour. -- Michael Bednarek (talk) 01:15, 3 August 2023 (UTC)
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)
https://phabricator.wikimedia.org/T348606 Jidanni (talk) 09:30, 14 October 2023 (UTC)