Jump to content

Wikipedia talk:Tools/Navigation popups/Archive 10

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

Wikidata ID

It would be really useful if the pop-up linked to the Wikidata equivalent of an article, displaying the Q value (e.g. Q144 for Dog) as the link text. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:27, 22 July 2014 (UTC)

I've provided a mockup, above. The Wikdiata ID could go between the article title and "actions" , if desired. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:32, 21 November 2014 (UTC)
Anyone? Having this feature would significantly increase my productivity, in certain regular tasks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:42, 20 February 2015 (UTC)
That looks overkill for something that few editors use, probably many aren't even aware of. Making it as prominent as, and so as important as, the article name is excessive. It doesn't display any useful information as the data IDs are on their own meaningless, and for editors unfamiliar with wikidata will be confusing. Better to put it in a menu, e.g. the 'actions' menu, and with a more descriptive title such as 'visit wikidata' or 'wikidata (Q144)'--JohnBlackburnewordsdeeds 10:18, 20 February 2015 (UTC)
The claim "doesn't display any useful information" is subjective; and easily refuted by the fact that I've asked for it because I regularly use such values. Specifically, I need to be able to right click and "copy link text", to capture the ID, so displaying the value as the (whole) link text, rather than text such as "visit wikidata", is imperative Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:35, 21 February 2015 (UTC)

@TheDJ, Amalthea, and Mr. Stradivarius: Are any of you able to help, please? If not, who else is involved in maintaining this tool? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:21, 3 March 2015 (UTC)

This tool is not under active development and basically in a 'keep alive' and 'bug fix only' mode. If you want a feature, you will have to find someone willing to program it. Amalthea has made a few functional changes over the last years, but also seems preoccupied with other things lately, same for me. So you will need to find a new developer for this piece of abandonware. —TheDJ (talkcontribs) 23:44, 3 March 2015 (UTC)

Request: Quality/class assessment indicator

I love this script. One of my favorites, and I only found it after disabling the beta hovercards. Idea: The top feature I'd want is something like User:Pyrospirit/metadata, or at the very least, the GA circle or FA star in the corner of the popup. It would really help me know how the page has been vetted. czar  22:46, 1 April 2015 (UTC)

Bug: Overflowing box

When hovering over an article history within a watchlist, if there is one of the new long-form IP addresses in the history, the edit summary column overflows the right-hand boundary of the box and is superimposed on the underlying watchlist, making the summaries hard or impossible to read. (Monobook skin, Firefox latest version, in case this is relevant) Could this be fixed?: Noyster (talk), 18:24, 7 April 2015 (UTC)

Same problem. Vector skin, also Firefox but alpha (development) build. I think something in User:George8211/vector.js might have broken it. No, commenting out all the JS options doesn't fix it. —George8211 / T 18:31, 7 April 2015 (UTC) Edit 18:33, 7 April 2015 (UTC)
 Confirmed. I, too, have observed this behaviour. I think it's always been thus and, given the inactive state of this tool's development, I put up with it. OTOH, I noticed that this behaviour sometimes changes when one hovers over a history without long usernames and then returns to the one which previously overflowed. -- Michael Bednarek (talk) 05:05, 8 April 2015 (UTC)

Hi there. Do you remember these two bugs? They're still not fixed. Could someone take care of it? --RezonansowyakaRezy (talk | contribs) 11:53, 4 February 2015 (UTC)

Maybe they won't be fixed. Red links not being red is frankly not a problem. --NE2 22:04, 10 February 2015 (UTC)
@Rezonansowy: Popups is maintained by volunteers, and none of them has decided to implement your requests. And why should they? You didn't even say the word "please" in your request; and you used not-so-polite language ("They're still not fixed"). If you don't want to learn enough JavaScript to implement your requests yourself, another option would to attach a monetary bounty to each request. If the requests are implemented, you can pay the bounties using PayPal or using a major credit card. Are you willing to attach such bounties? If so, how much are you willing to pay? Cheers, —Unforgettableid (talk) 03:32, 22 April 2015 (UTC)

Request: Show article maintenance templates

Idea: It would be a useful feature if popups could display tags on articles/pages. —George8211 / T 17:38, 17 February 2015 (UTC)

I would like such a feature too. Let me add:
Popups wouldn't actually have to show the entire text of an article's attached maintenance template.
It could show just the name of the template (e.g. {{news release}}).
Alternatively: It could show just the template's issue text ("This article reads like a news release, or is otherwise written in an overly promotional tone"). It could leave out the fix text ("Please help by either rewriting this article from a neutral point of view or by moving this article to Wikinews"). Cheers, —Unforgettableid (talk) 03:32, 22 April 2015 (UTC)

This is still happening. There is a new report on pt:Project talk:Software/Popups de navegação#Problemas no sumário de edição. Helder 19:12, 30 November 2014 (UTC)

Still seeing this problem. Ibadibam (talk) 22:15, 29 April 2015 (UTC)

View Redirect page?

When I get the popup for ΡΨ, it shows me the popup for that page and underneath it the one for Rho Psi as expected, but I don't see choice that would allow me to go to the unredirected page for ΡΨ, that is https://wiki.riteme.site/w/index.php?title=%CE%A1%CE%A8&redirect=no . Is that possible to add with an existing option?Naraht (talk) 14:58, 19 May 2015 (UTC)

AFAIK not directly. The obvious method is to click on the REDIRECT (ΡΨ) which takes you to Rho Psi and there click on (Redirected from ΡΨ) which will take you back to the REDIRECT. Alternatively, in the popups "actions" menu for ΡΨ, click on "most recent edit". -- Michael Bednarek (talk) 07:23, 20 May 2015 (UTC)

Unwatch oddity

Since the restoration of popups, I have noticed a new and odd behaviour when using actions - un|watch. Before the downage, clicking on the un produced a white box in the top right-hand corner of the screen to appear, with a message that the page, and its talk page, had been removed from my watchlist.

Now, as well as this box appearing, I am taken to a page which asks me if I want to unwatch, and asks me to click "OK". It also leaves me on the page I was unwatching, but with none of the content shewing, just a message telling me it has been removed from my watchlist. Previously I would not leave the page I was on, whether it be watchlist or anything else.

This change increases the clicks involved, and leaves editors on a page they do not wish to be on. DuncanHill (talk) 12:00, 7 August 2015 (UTC)

I think that behaviour has been happening for a long time, at least here. See Archive 8 from October 2011 to January 2012. -- Michael Bednarek (talk) 12:16, 7 August 2015 (UTC)
Well, it only started for me today. Yesterday it didn't happen, today it does. DuncanHill (talk) 12:24, 7 August 2015 (UTC)
Yeah, it's going to the fallback url, instead of executing the bound function. I notice that the script still depends on a lot of global variables, which won't work anymore. —TheDJ (talkcontribs) 16:18, 7 August 2015 (UTC)

Please deploy the following version of the code: source, diff. This exposes several of the variables to the global context, which was no longer exposed due to switching over to RL. —TheDJ (talkcontribs) 10:01, 8 August 2015 (UTC)

 Done. -- [[User:Edokter]] {{talk}} 10:14, 8 August 2015 (UTC)
Yay! That seems to work, many thanks. DuncanHill (talk) 12:12, 8 August 2015 (UTC)

Anyone else getting recent breakage?

At the moment, popups doesn't seem to be opening most of the time on my browser (FFox). The popup box will sporadically work on articles, but definitely tends to fail on watchlists and contribs pages. Perhaps a general script server wonkiness of the day? Maybe another scripted tool is breaking things (although some tests with disabling various other scripts in vector/monobook.js didn't fix anything yet). Maybe a leftover ancient config which needs updating? Anyone else getting recent popup grief? Dl2000 (talk) 00:48, 7 August 2015 (UTC)

Similar behaviour for me, IE11 on Win7. DuncanHill (talk) 01:13, 7 August 2015 (UTC)
completely broken on de:wp and en:wp for me, FF on win7 --Snotty (talk) 01:17, 7 August 2015 (UTC)
It's being explicitly blocked from loading with the console message "Gadget "Navigation_popups" was not loaded. Please migrate it to use ResourceLoader. See <https://wiki.riteme.site/wiki/Special:Gadgets>. ". The recent change blocks the script. Nakon 01:23, 7 August 2015 (UTC)
(edit conflict) Not working for me either on enWP, but seems fine on Commons (Safari v5, Mac).—Odysseus1479 01:26, 7 August 2015 (UTC)
Pop-ups still fine for me on enwp, Chrome, OS X, but the gadget that put my category box at the top just broke so perhaps something is up. – czar 02:29, 7 August 2015 (UTC)
Well, that's handy. How do we get them back? DuncanHill (talk) 01:27, 7 August 2015 (UTC)

Also discussed at Wikipedia:Village_pump_(technical)#Legacy_gadgets_are_disabled. --NeilN talk to me 02:31, 7 August 2015 (UTC)

(edit conflict) Would like to report on some findings: popups is broken (well, it loads erratically) on enwiki, and it doesn't work at all on simplewiki either. It works on Commons, Meta, and enwikt. It also seems to work just fine on Wikia. Using Chrome 44 on a Windows 7 computer. This issue also appeared for me on FF 39 (updating it as we speak) as well. --I am k6ka Talk to me! See what I have done 02:35, 7 August 2015 (UTC)
Crossed out some stuff, it's broken on Meta, enwikt, and Wikia now :/ --I am k6ka Talk to me! See what I have done 02:58, 7 August 2015 (UTC)
I don't know if this is a temporary godsend or not, but it's working for me on enwiki right now. It's still not working on Wikia, and it doesn't seem to be functioning on simplewiki either. Not sure if this is a cache/update issue I'm not aware of. --I am k6ka Talk to me! See what I have done 03:07, 7 August 2015 (UTC)
(update) seems to be working on Wikia now. Also seems to have returned on Meta. enwikt and simplewiki still aren't working, though. --I am k6ka Talk to me! See what I have done 03:36, 7 August 2015 (UTC)
(EC) They just came back for me too. Calidum T|C 03:09, 7 August 2015 (UTC)
Did some hard reloads, popups is now working much better from here, especially on the watches and contribs. Thanks everyone for the input and resulting repairs. Dl2000 (talk) 03:31, 7 August 2015 (UTC)

Changes merged

I've merged the changes from MediaWiki_talk:Gadget-popups.js#ResourceLoader which has fixed the issue for now. Nakon 03:13, 7 August 2015 (UTC)

thank you VERY much indeed --Snotty (talk) 03:29, 7 August 2015 (UTC)
@Nakon: Thanks! Popups had been in dire need of ResourceLoader updates for years. Glad to see this happen. Krinkle (talk) 05:28, 7 August 2015 (UTC)
+11111111.—Odysseus1479 05:29, 7 August 2015 (UTC)
Thank you @Nakon:, they seem to be working fine for me now, much appreciated. DuncanHill (talk) 11:31, 7 August 2015 (UTC)
Thank you very much; excellent work. -- Michael Bednarek (talk) 12:16, 7 August 2015 (UTC)

Some error

The gadget is not working for me anymore on enwiki (but strangely works fine on Commons). Popups worked fine just before the recent change, but now I can't see popups on my computer (OSX Yosemite 10.10.3 with Google Chrome). Epic Genius (talk) 03:20, 7 August 2015 (UTC)

Since the ResourceLoader issue was just repaired, you could try doing a hard refresh (or cache-clearing reload) e.g. Ctrl-Shift-R in FFox; see comparable commands for other browsers. These fixes may not be properly propagated with a regular refresh (or if you have not yet reloaded a page in question). Dl2000 (talk) 03:38, 7 August 2015 (UTC)
I removed the script from my common.js page and added it to my preferences section, so it works fine now. Epic Genius (talk) 15:42, 7 August 2015 (UTC)

Still down

  • I don't know if it's just me, but my pop-ups are down now. Tried different browsers, resetting cache, updating browser, uninstalling and reinstalling the gadget from preferences... – czar 09:17, 7 August 2015 (UTC)

Popups still broken for me - Chrome 44.0.2403.125 m or Firefox 39.0, Windows 7 Pro. In Chrome, I tried Ctrl-Shift-R, also F12 + right-click on reload button > Empty Cache and Hard Reload, still doesn't work. Any suggestions, please? --RobertGtalk 09:22, 7 August 2015 (UTC)

Please try removing the duplicate Lupin popups code from your vector.js file and try using the Gadget in the site preferences. Nakon 15:03, 7 August 2015 (UTC)
Please try removing the duplicate Lupin popups code from your common.js file and try using the Gadget in the site preferences. Nakon 15:01, 7 August 2015 (UTC)
Thank you, that did the trick. Not sure why it became a problem only yesterday. —SpacemanSpiff 15:11, 7 August 2015 (UTC)
Likewise, removed Lupin script from my vector.js, and it now works again for me too. Thank you. --RobertGtalk 16:06, 7 August 2015 (UTC)
Likewise that did the trick. Keith D (talk) 16:12, 7 August 2015 (UTC)
popups go down for me about every six months. This time, though adding ('http://wiki.riteme.site/w/index.php?action=raw&ctype=text/css&title=User:Lupin/navpopdev.css'); to css file did not work, nor clearing the cache, nor rebooting. I am using Firefox 39.0.3 with (gulp) XP Windows. Was working 2 days ago. Forced to hard boot (not related to this problem).
I don't understand references to .js. Mine have something else entirely there than doesn't relate: filling in citations. Student7 (talk) 18:00, 8 August 2015 (UTC)
Doesn't work in Windows Vista either so appears to be java/gadget dependent. Student7 (talk) 18:08, 8 August 2015 (UTC)

7 August 2015

I just lost the Navigation popups entirely, for the first time ever. I thought my own java machine might have caused it so I went to facebook to see if popups work. No problem. Poeticbent talk 16:58, 7 August 2015 (UTC)

Please remove the Lupin popups from your monobook.js and try using the Gadget instead. Nakon 17:17, 7 August 2015 (UTC)
  • Thank you. All is fine. I removed the Lupin popups from my monobook. The actual popups came back. But what "Gadget" did you have in mind User:Nakon? In my Preferences' section Gadgets I deselected Navigation popups as a gadget. Poeticbent talk 17:37, 7 August 2015 (UTC)
The Gadget "Navigation popups" is just the renamed version of Lupin's popups. That one should work properly going forward. Thanks, Nakon 17:40, 7 August 2015 (UTC)
Same thing happened to me. I lost popups today, but when I stripped it from my .js they...popped back up.--Jezebel's Ponyobons mots 19:32, 7 August 2015 (UTC)
I have the same problem on my laptop. When I removed it doesn't seem to work. I removed it from Javascript and somewhat it is not working. Could someone help me get them back. Have a look at my javascript and see what I should do --EurovisionNim (talk to me)(see my edits) 02:19, 8 August 2015 (UTC)
Same here, although I'm using my own (slightly modified) version of the tool (zh:User:Moonian/popups.js); dunno which part(s) of the code the RL is not happy about (feel free to modify it if you have the privileges to edit the page). — Preceding undated comment added 11:28, 8 August 2015 (UTC)
If you have your own version, you will have to do your own support ... —TheDJ (talkcontribs) 06:48, 10 August 2015 (UTC)
Just found the reason - it seems that the RL isn't happy about the getImageUrlStart(pg.wiki.hostname) call. Have to find a replacement of it, or the images from non-en wikip may not load... --Moonian (talk) 16:45, 10 August 2015 (UTC)
Problem is, that ths gadget is only on some wkis, but when I am using it on my global.js, I have no other option in many wikis... JAn Dudík (talk) 19:55, 9 August 2015 (UTC)
@JAn Dudík: Please read the installation instructions for "global.js" in the installation section. —TheDJ (talkcontribs) 06:48, 10 August 2015 (UTC)
Works, but not well. Popups does not disappear after moving cursor :-(. JAn Dudík (talk) 05:26, 11 August 2015 (UTC)

I also lost popups in other wikis when using it global.--Anatoliy (Talk) 20:10, 9 August 2015 (UTC)

rm Lupin works for me on monobook. Thanks! Student7 (talk) 21:53, 11 August 2015 (UTC)

9 August 2015

Pursuant to the above, I've lost the pop-ups too. I disabled and enabled the Gadget, but I'm still not seeing anything. I don't have a monobook.is, whatever that is. If someone could help me out, that'd be great. Braniff747SP (talk) 21:08, 9 August 2015 (UTC)

I have a similar problem. I don't have popups in my monobook.js. I do have my own version of WP:AVT. Now popups doesn't work from within that tool anymore. It used to, and something has changed. It would be kind of helpful if someone explained what has changed and why. I'm aware that the underlying Wiki software is in constant development, and that features get deprecated and deleted, but the development updates I've seen are, um, couched in opaque language that is only meaningful to the developers. Philip Trueman (talk) 03:25, 10 August 2015 (UTC)
@Philip Trueman: AVT is even less maintained than popups. —TheDJ (talkcontribs) 06:41, 10 August 2015 (UTC)
@TheDJ: Indeed, but as I said, I have my own version of AVT (see PILT), which I am prepared to make some effort to maintain. What's frustrating is not that I need to [do] so but that it's far from clear what I have to do to get things working again. Philip Trueman (talk) 08:36, 10 August 2015 (UTC)
An update: OK, I have one instance of sajax* that I need to replace with jQuery.post(). It'll have to wait. Philip Trueman (talk) 15:24, 10 August 2015 (UTC)
@Philip Trueman: You can simply replace that one with "new XMLHttpRequest();". The rest of the call doesn't use anything sajax specific. —TheDJ (talkcontribs) 15:27, 10 August 2015 (UTC)
@Braniff747SP: you do have a vector.js however and it includes Lupin's version of popups. Please remove it and enable popups through the gadgets. —TheDJ (talkcontribs) 06:41, 10 August 2015 (UTC)
@TheDJ: Worked. Many thanks, much appreciated. Braniff747SP (talk) 16:30, 10 August 2015 (UTC)

Nothing I have done seems to fix the tool. Dustin (talk) 18:29, 10 August 2015 (UTC)

Not having access to this tool significantly impairs my ability to check diffs and navigate. If anyone knows what my problem is, please help? Dustin (talk) 17:35, 12 August 2015 (UTC)
Could you provide the output of your browser's error console (only category Javascript errors)? In short: MediaWiki dropped support for some outdated libraries. If any script you're using is using on of them this results in an error, which makes the browser stop all js execution on that page. Find them and disable or update them. --nenntmichruhigip (Diskussion) 09:24, 14 August 2015 (UTC)

15 August 2015

I have removed the Lupin popups from my monobook.js and vector.js. Navigation popups was already enabled in my Preferences; but popups no longer works for me. I have purged the cache. What should I do now? RolandR (talk) 07:58, 15 August 2015 (UTC)

@RolandR: Look again at your vector.js. At the bottom. (You're loading Twinkle twice too).  —SMALLJIM  08:55, 15 August 2015 (UTC)
Thank you! RolandR (talk) 09:04, 15 August 2015 (UTC)
@Smalljim: I don't refer to Lupin.js in any of my subpages, but the gadget refuses to work. Why could I be having this problem? I don't meant to make you the go-to person, but since you might know... Dustin (talk) 22:58, 19 August 2015 (UTC)
@Dustin V. S.: I'm not an expert by any means! The only thing I can suggest is to try removing all content from your common.js in case it's another script that's causing the problem. If popups then works, adding the other scripts back one at a time would show which is the culprit. (don't forget to clear the cache for each change)  —SMALLJIM  23:07, 19 August 2015 (UTC)
@Dustin V. S.: ping. (Smalljim: adding a ping template like this won't work: it needs to be in a completely new comment.) — Mr. Stradivarius ♪ talk ♪ 10:58, 20 August 2015 (UTC)
Oops – thanks for the reminder!  —SMALLJIM  11:09, 20 August 2015 (UTC)
Thanks for the response. I'll try that out when I find the time! Dustin (talk) 11:15, 20 August 2015 (UTC)

Style enhancements similar to Hovercards

1 of 3 example screenshots

@TheDJ, Amalthea, and Mr. Stradivarius: I have been working on a Beta Feature called Hovercards. It has a setting to switch to Navigation Popups if its enabled (a few bugs there). So, I thought it might be nice if Navigation Popups and Hovercards had a similar style. I have made a few typographic and color changes — made the background white, moved to a gray color palette and reduced the font size of the meta data . Some of the changes like the drop shadow aren't in Hovercards yet but there are patches for it that are awaiting review.

You can check out the diff of the changes and some screenshots too. You can also copy my common.css to see the changes. Could you consider merging this change? I am willing to make technical and design changes wherever you find fit. —Prtksxna (talk) 00:01, 30 October 2014 (UTC)

Agree I've been increasing the excerpt's font-size for many months, and I like almost all the other changes proposed here. I hope we can do this, or something close.
I would suggest changing 2 things: Change the "popups" menu item into a cog-icon instead (to take up less space); and change the menu-links back to blue text (per standard link color). HTH. Quiddity (talk) 01:10, 31 October 2014 (UTC)

Let's do this. --MZMcBride (talk) 23:39, 26 January 2015 (UTC)

To be clear, this is a request to update MediaWiki:Gadget-navpop.css with the contents of User:Prtksxna/common.css. --MZMcBride (talk) 23:42, 26 January 2015 (UTC)

Done. I've also left a note at VPT. @MZMcBride, Prtksxna, and Quiddity: it would probably be a good idea to keep an eye on this page in case people disagree with the change or have any suggestions for how it could be improved. — Mr. Stradivarius ♪ talk ♪ 05:31, 27 January 2015 (UTC)

Yuck. How can I change this back? --NeilN talk to me 05:36, 27 January 2015 (UTC)

Ugh. Me too. Came here to post a bug, saw it's actually by design??? Please revert, or provide a switch so we can change it back.--JohnBlackburnewordsdeeds 05:38, 27 January 2015 (UTC)

I've reverted, seeing as the initial reactions here weren't positive. If we find a consensus about whether/how to tweak the new styling, then it can be applied again. — Mr. Stradivarius ♪ talk ♪ 05:42, 27 January 2015 (UTC)
@NeilN and JohnBlackburne: By the way, what parts of the new styling did you find objectionable? — Mr. Stradivarius ♪ talk ♪ 05:45, 27 January 2015 (UTC)
Thank you. My main beef was the fonts were too small, rendering some text ugly as hell and the mousing targets too small. --NeilN talk to me 05:48, 27 January 2015 (UTC)
For me it seemed suddenly way too large, both the font size and the borders (though it's possible that's just the font's natural borders), and the grey for menus was hard to distinguish from black. I could probably get used to the grey, as it's just the same three items usually, and the background colour though I prefer the slight colouration. But the much larger box made it immediately less usable.--JohnBlackburnewordsdeeds 05:56, 27 January 2015 (UTC)
I also saw the problem with the font size being too big. Interestingly, it didn't happen when I copied User:Prtksxna/common.css to my vector.css page to test the styling. I'm guessing that something must be being overridden in user CSS pages but not on the gadget CSS page (or vice versa). (This is in Firefox on Windows 7.) — Mr. Stradivarius ♪ talk ♪ 06:05, 27 January 2015 (UTC)
I'm using Firefox on Windows 8.1 with the Monobook skin. --NeilN talk to me 06:13, 27 January 2015 (UTC)
Safari and OS X 10.10, with the default Vector skin.--JohnBlackburnewordsdeeds 06:15, 27 January 2015 (UTC)
I hope the new styles can be restored once the font size issues can be resolved. While I'm sure the bright orange coloring appealed to Lupin's tastes, it was always a strange choice, and I also disliked the cramped format of the popups themselves (which seem to be a holdover from the bad old days of Monobook with its tiny UI elements, from when people still ran desktop computers on 15 inch CRT monitors). A design refresh of popups is long overdue. — This, that and the other (talk) 08:36, 27 January 2015 (UTC)
I like the idea, but there are some flaws. There is nothing wrong with a bit of color indicating this is still NavPopups, maybe just the top part. The header could use a little rearranging anyway, moving the menus to the next line. Finally, move the window down so that, just like Hovercards, it does not obscure the link being hovered over. -- [[User:Edokter]] {{talk}} 09:54, 27 January 2015 (UTC)


I have removed the font size changes for now, I need to test it with more screen types (lower DPI) before we can make that change. I also agree that the gray menu links don't seem like call to actions. People using the gadget already might know what to do, but new users would never hover over it if its that color. I've updated User:Prtksxna/common.css with these changes. Prtksxna (talk) 17:36, 27 January 2015 (UTC)

Cool. Thanks for the quick responses, all. :-) Maybe we can try re-applying the styling changes (minus the font size changes) in the next few days? It'd be great if some of the users who had issues could beta test first before updating the gadget for everyone. --MZMcBride (talk) 17:50, 27 January 2015 (UTC)
If you want me to test something, just ping me. --NeilN talk to me 21:57, 27 January 2015 (UTC)
Happy to give it a try; just point me to the relevant changes to make (I presume to my own .css).--JohnBlackburnewordsdeeds 22:06, 27 January 2015 (UTC)
@JohnBlackburne and NeilN: To test it, just copy the contents of User:Prtksxna/common.css to your skin.css page. — Mr. Stradivarius ♪ talk ♪ 23:21, 27 January 2015 (UTC)

Had it in my own style sheet for a couple of hours and it looks much better: the size seems the same as before, small, which was my main complaint. The grey menus still seems a bit odd; I noticed odd words in them which were blue and on experimenting it seems to be visited links are blue, non-visited links are grey which is very counterintuitive. Also looking for the lines which e.g. are above and below the 'un watch' line they are very faint, visible only if I look for them and move my head down, so invisible when looking at them normally, on what I think is a well-adjusted LCD display.--JohnBlackburnewordsdeeds 02:40, 28 January 2015 (UTC)

Thanks for testing this! I've made the color for the normal and visited links the same now and made the lines in the menu darker. Could you please test again?--Prtksxna (talk) 02:43, 9 February 2015 (UTC)
OK. It will take some time. I had the last version in place for a couple of weeks so also want to give this some time, and look at the original/current version again to remind me of it.--JohnBlackburnewordsdeeds 02:53, 9 February 2015 (UTC)

Attempt 2

@JohnBlackburne, MZMcBride, Prtksxna, NeilN, Mr. Stradivarius, Quiddity, and Edokter: It looks like this discussion died out. Would people object to doing another trial of the updated styles (since Prtksxna tweaked them further)? Are there still any major issues? Kaldari (talk) 18:12, 19 August 2015 (UTC)
I reverted to the standard appearance and then forgot about this. What would I need to do to test it again?--JohnBlackburnewordsdeeds 20:33, 19 August 2015 (UTC)
Copy the contents of User:Prtksxna/common.css (or just the Navigation Popups section) to your skin.css page. Kaldari (talk) 22:44, 19 August 2015 (UTC)
How about doing this in a safer method way ? Update and deployed the gadget and gadget definition on test.wikipedia.org. Build table of skins and browsers and let people sign off on wether or not it matches the screenshot as included above. —TheDJ (talkcontribs) 18:31, 20 August 2015 (UTC)
Now available at https://test.wikipedia.org by enabling the Gadget in your preferences.

I personally don't use navigation popups, but another attempt at updating the styling seems like a good idea to me. --MZMcBride (talk) 17:58, 20 August 2015 (UTC)

The popups over at test using monobook look fine to me. --NeilN talk to me 13:45, 22 August 2015 (UTC)
From a brief look they appear to respect my choice of fonts, so I’m happy. (Vector here.) I’ve become used to the pink background, but I don‘t think I‘d particularly miss it.—Odysseus1479 21:44, 22 August 2015 (UTC)
Any objections to switching it over to the new styles now? Kaldari (talk) 00:36, 26 August 2015 (UTC)
I haven't tested the version at https://test.wikipedia.org extensively, but it doesn't present any problems to me. -- Michael Bednarek (talk) 04:54, 26 August 2015 (UTC)
Has anyone tested IE versions ? Did all people who complained about the original change had a change to check out the test.wp version ? —TheDJ (talkcontribs) 07:53, 26 August 2015 (UTC)
Tested just now with IE 11/Win 7. Looks to be the same as my usual browser, FF 22.0 (deliberately retained), and Chrome 44.0. -- Michael Bednarek (talk) 10:10, 26 August 2015 (UTC)
Styles updated at MediaWiki:Gadget-navpop.css Kaldari (talk) 20:28, 8 September 2015 (UTC)

Report your Issues with the new style

  • checkY The menu dropdown is overlapping signifcantly. The old version also does this, but it seems more noticeable to me now.
  • checkY Little bit of overlap between some of the lines in the menu

@TheDJ: These should both be resolved now. Kaldari (talk) 20:02, 21 August 2015 (UTC)

This text.
This text.
The popup with the on-hover text for images is still yellow (see [[File:Question.png|right|This text.]] at right). That's probably a sitewide stylesheet, but I assume (ha!?) they have some design plan or basis for it. Might be good to have "the popup boxes on en.wp" all be consistent. DMacks (talk) 21:57, 8 September 2015 (UTC)
  • I don't understand why we're introducing a new style to an existing gadget to match a new feature. Hovercards and Navigation Popups are two different gadgets. One predominantly targets readers, the other tends to be more useful to editors. An opt in is available if users want to use the beta feature. Changing the background to white on such a small focal point just makes it more difficult to read. Please change it back. Fuebaey (talk) 22:57, 8 September 2015 (UTC)
    • I believe the reason was so that editors can switch from Hovercards to Navigation pop-ups without the interface changing dramatically. Kaldari (talk) 23:51, 8 September 2015 (UTC)
      • As an editor who doesn't use Hovercards, I don't think it's fair to expect existing Nav popup users to adapt to a new interface just to suit another gadget. Why not make this an optional skin if a user chooses to use Hovercards? Fuebaey (talk) 02:18, 9 September 2015 (UTC)
  • You area allowed to destroy wikimedia's best editor script in lupin's popups as WMF has a habit of enforcing stupid changes without the consent of editors but can you damn chance the colour back to yellow?..I have 40/40 vision and that colour change is hurting my eyes...atleast restore it to a lighter shade of yellow (not beige)--Stemoc 23:29, 8 September 2015 (UTC)
    • I'm fine with setting it to whatever color people want. The reason it was changed to white was to match Hovercards (so that people can change to Navigation pop-ups without the UI changing dramatically). There were many editors involved in the discussion and it lasted 11 months, so I don't think it's fair to say it was done without the consent of editors. If the consensus is to change it back to yellow (or whatever), I'm fine with that. Perhaps someone would like to start a formal discussion about it below. Kaldari (talk) 23:51, 8 September 2015 (UTC)
      • Personally, I much prefer the new style. For those that like the old style better, perhaps we could have an easy way to revert back on a per-user basis? I had a go at importing the old stylesheet via JavaScript, but that didn't work. I assume that copying and pasting Special:PermaLink/651663158 into Special:MyPage/common.css would do the trick, but is there an easier way? — Mr. Stradivarius ♪ talk ♪ 00:10, 9 September 2015 (UTC)
        • I think that's probably the only way to change it on a per-user basis. Kaldari (talk) 00:28, 9 September 2015 (UTC)
          • Some of us, who are wikiMedians are using this globally, its one of the few scripts which can be used across Wikimedia without effing up the individual settings of each wikis..how would you suggest changing that? again, its basically restoring the colour..No one likes Hovercards but its been forced upon us and we can't do anything about it so FGS stop messing up with things you should have no control over!....Can a sane admin just change the colour back please? the world does NOT revolve around the English wikipedia only..--Stemoc 05:19, 9 September 2015 (UTC)

There was proper en.wp consent here. It was not an arbitrary choice. Some folks might not like it, but that's what you get with 100000 users, there is always SOMEONE not happy. That's why people can use their own common.js and common.css to make changes to their hearts content. —TheDJ (talkcontribs) 08:52, 9 September 2015 (UTC)

Yep. Came here to share my praise, looks excellent! 👏 MusikAnimal talk 17:37, 9 September 2015 (UTC)
Me, too. In particular, I am happy to see the weird yellow color go away. Whether it should be white or extremely light gray is a decision for someone else, but please: no more yellow ever again. WhatamIdoing (talk) 18:38, 9 September 2015 (UTC)

No popups in history pages?

In the last couple of days, popups do not seem to work on history pages for me. No diff view, no user contributions, nothing. I am using Monobook on Safari, and none of the options I use seem to have anything to do with histories. Is there anything I can do? —Kusma (t·c) 09:04, 14 September 2015 (UTC)

@Kusma: Popups on history pages are working fine for me in both Firefox and Chrome, and on both Vector and Monobook. Do you still see the problem when you are on a different browser or a different computer? Also, have you enabled any gadgets recently? And finally, if you're feeling technical, the most useful thing that you can do is to open your browser console on a history page, refresh the page, and let us know if you see any error messages, either when you load the page or when you hover the mouse above a link. — Mr. Stradivarius ♪ talk ♪ 09:41, 14 September 2015 (UTC)
Thank you @Mr. Stradivarius: for the pointers. With Chrome on a Mac, I had no issues so far. I have now discovered that it sometimes (rarely) works in Safari, but most of the time the console tells me (on page load; popups no longer work after that)
TypeError: undefined is not a function (evaluating 'performance.mark('mwLoadEnd')')

and a bunch more errors in load.php. Does that point to an issue you know of? —Kusma (t·c) 09:59, 14 September 2015 (UTC)

If it's only in history pages it's likely due to resvision counter, revision jumper or similar gadgets. Those may be hard to tell from error console, so check if you're using one of them and try disabling them if there's nothing interesting on the error console mentioned by Stradivarius. --nenntmichruhigip (Diskussion) 09:56, 14 September 2015 (UTC)
It doesn't seem to be only history pages, but it does not seem to be completely reproducible. I turned off all gadgets expect popups and still get errors that disable popups, sometimes also on Contributions pages. —Kusma (t·c) 10:05, 14 September 2015 (UTC)
I have Safari and tried reproducing it, but popups worked everytime. I saw the above error twice, but popups kept working. Oddly the two times I saw the error were immediately after switching to Monobook and immediately after switching back to Vector.--JohnBlackburnewordsdeeds 10:33, 14 September 2015 (UTC)
The problem seems to be more general, and probably not connected to popups -- other javascript also sometimes (in a fairly erratic way) fails to load, so I will need to do some more research. Thank you, everybody, for your suggestions so far! —Kusma (t·c) 11:51, 14 September 2015 (UTC)
Yes I discovered this problem last friday, and it's really annoying for sure. It seems to only occur on Safari and it's not really clear yet why it is occurring. phab:T112287TheDJ (talkcontribs) 12:47, 14 September 2015 (UTC)
Glad I am not alone. Thank you for the link! —Kusma (t·c) 15:04, 14 September 2015 (UTC)

Maintenance

"This tool is no longer being developed. Guarantee to the door. If you find a problem, you should fix it...." Given that popups is one of the most useful and widely used tools on Wikipedia, perhaps an effort should be made to find volunteers who will officially (in the Wikipedia community sense) support/enhance the tool? --NeilN talk to me 18:18, 15 September 2015 (UTC)

Sudden shutdown?

Seems the popups have suddenly stopped working in the past several minutes. Anyone else finding their popups suddenly go nonfunctional? Dl2000 (talk) 23:34, 4 September 2015 (UTC)

Scratch that - popups seem to be working again after resetting a few things. Probably was a client-side JavaScript hiccup. Dl2000 (talk) 00:19, 5 September 2015 (UTC)

No matter what I do, popups will not work. Editing now takes me longer than it used to. I haven't been able to use the tool for a month now. Dustin (talk) 21:54, 10 September 2015 (UTC)

You've been asked to provide more details in another section on this page. --nenntmichruhigip (Diskussion) 12:17, 11 September 2015 (UTC)
@Nenntmichruhigip: Information: You are importing User:Lupin/popups.js into your common.js or <skin>.js! This script is unmaintained. Please remove this inclusion and enable the Navigation popups Gadget in the preferences of your account instead. Dustin (talk) 21:48, 11 September 2015 (UTC)
This message which TheDJ put there is causing a lot of confusion. You need to delete Lupin's version of the scirpt from your global.js file on Meta and read the instructions on how to install the new version. --V111P (talk) 06:02, 12 September 2015 (UTC)
I believe that the Notes section of Wikipedia:Tools/Navigation_popups#Installation should mention that editors who install the gadget by adding code to global.js should also make sure that they have disabled NavPopups in the gadget tab of the preferences, or it will never work for them. --Elitre (WMF) (talk) 16:53, 1 October 2015 (UTC)

Diffs in mainspace

Here (Windows 7, IE, Firefox, Chrome), Popups no longer work when viewing diffs of pages in mainspace/article space. E. g. for https://wiki.riteme.site/w/index.php?title=Bill_Gates&diff=682256714&oldid=681847565 no popups appear when hovering over "Revision as of 18:47, 19 September 2015" to allow various actions, nor when hovering over editor names etc. on that same diff. On similar diffs in other namespaces, e. g. https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Tools/Navigation_popups&diff=683649317&oldid=681240649 or https://wiki.riteme.site/w/index.php?title=Talk:Bill_Gates&diff=677791957&oldid=674595100 popups work. I haven't changed any preferences knowingly for at least 3 weeks and in any case I can't see how a personal configuration change could have such an effect. Does anybody else experience similar behaviour? -- Michael Bednarek (talk) 02:54, 2 October 2015 (UTC)

PS: The description of my problem can be simplified: in article space, Popups don't work at all. linkclassifier doesn't either. Baffled, Michael Bednarek (talk) 03:12, 2 October 2015 (UTC)
PPS: Consulting VPT at Unable to revert multiple revisions and Twinkle and Page Curation failing to load on certain pages explained and solved the problem (disable "Content Translation" at Special:Preferences#mw-prefsection-betafeatures). -- Michael Bednarek (talk) 03:10, 3 October 2015 (UTC)

How do I remove this?

I am being told to remove this 'plug in' but when I look at my common.js page I don't see anything there. Any clues, the tec=chnical side of Wiki' isn't my forte at all. Thanks. Stephenjh (talk) 08:50, 21 October 2015 (UTC)

You're using the monobook skin and are calling the ancestor(?) of this script from your monobook.js. Another option is checking here whether "Navigation popups" (currently sixth checkbox) is checked. Also it might be useful to know where you've been asked to do this, in case you'd prefer to keep using it's functionality. --nenntmichruhigip (Diskussion) 11:50, 21 October 2015 (UTC)

Does this even work with Microsoft's new browser for Windows 10? 50.135.190.43 (talk) 00:32, 1 February 2016 (UTC)

Disabling for Safari/Ipad

Popups gets in the way on an IPad. Touching a diff brings up the popup instead of the diff, and I can't seem to get rid of it. Is there an easy way to disable popups on a per-browser basis? ISTR doing this in the past. TIA Mr Stephen (talk) 17:36, 7 February 2016 (UTC)

Images in NAVPOPS

There is a discussion at Wikipedia talk:Non-free content/Archive 65#Hovercards that is ostensibly about Hovercards (a stripped-down version of NAVPOPS), but which could force the removal of many images from the WP:NAVPOPS gadget (or all images, if the gadget maintainers can't find a way to suppress solely non-free images). Whatever standard is applied to Hovercards will be applied to NAVPOPS. WhatamIdoing (talk) 23:06, 16 March 2016 (UTC)

Twinkle

The "Revert to revision" feature of Popups is similar to the "Restore this revision" feature of Twinkle. GeoffreyT2000 (talk) 16:58, 27 March 2016 (UTC)

Proposal on the gadget talk page to move script to GitHub

Please see Mediawiki talk:Gadget-popups.js#Proposal to host on GitHub. APerson (talk!) 16:29, 19 April 2016 (UTC)

Proposal to integrate gender preferences into Navpopups

Per this conversation at GGTF and this conversation at the village pump idea labs, could the function in this popupscript that shows gender preferences be integrated into Navpopups? Are there any objections to the idea? Brustopher (talk) 00:02, 27 August 2015 (UTC)

I've implemented this feature request with this requested edit. APerson (talk!) 02:19, 14 April 2016 (UTC)
The edit request has been answered, so this change is now live on the gadget. APerson (talk!) 03:58, 15 April 2016 (UTC)
Thanks APerson, this is a real convenience when participating in discussion threads: Noyster (talk), 16:33, 15 April 2016 (UTC)
@APerson: Is there any way to suppress the icon display? –xenotalk 02:04, 19 April 2016 (UTC)
xeno, I didn't implement a way of doing that. I suppose we could add an option for displaying that, like popupShowGender? APerson (talk!) 02:08, 19 April 2016 (UTC)
APerson Yes please, I would be thankful for the option. –xenotalk 02:13, 19 April 2016 (UTC)
xeno, edit request filed. APerson (talk!) 03:10, 19 April 2016 (UTC)
And the edit request was answered, so the preference is now live. APerson (talk!) 02:12, 20 April 2016 (UTC)

popupLastModified in Uzbek

Hi everyone! The function popupLastModified isn't working well on the Uzbek Wikipedia. We're getting popus that say something like "Last edited a few 4 days ago". Moreover, the first half of the sentence is rendered in Cyrillic, the second - in Latin. Here is a screenshot. I can't seem to find the corresponding entries on Translatewiki. Specifically, I can't seem to figure out where the Cyrillic phrases бир неча, кун олдин, ой олдин, йил один are coming from. Can anyone help us on this? Is it possible that the first half of the clause is rendered from Translatewiki and the second from, say, Meta? Nataev talk 06:44, 19 April 2016 (UTC)

NavPopup’s messages are stored in JavaScript files, but your screenshot seems to be Hovercards, which can be translated generally here. However, the time gap itself (e.g. “4 days ago”) is provided MediaWiki core—this is the reason for the two scripts. The Latin version is easy to find, it can be translated at the above location; the Cyrillic part might come from CLDR (is your interface version Cyrillic?). --Tacsipacsi (talk) 21:52, 19 April 2016 (UTC)
Thank you for your response! Our interface is in Latin. (We do have a Latin-to-Cyrillic converter for those who prefer to read in Cyrillic.) How can we change the Cyrillic entries on Phabricator to Latin? If I translate them all and have my work checked by other Uzbek wikimedians, can we request somebody to make the changes on Phabricator? One more thing. The annoying phrase бир неча is nowhere to be found. Somebody translated the English word "some" as "a few". It should've been translated as тахминан i.e. "approximately". Currently we're getting messages like "The page was last edited a few 4 days ago". If this mistake is fixed, we'll get something like "The page was last edited approximately 4 days ago" which is pretty decent. Or the phrase бир неча should be completely removed. "The page was last edited 4 days ago" sounds good. Nataev talk 03:27, 20 April 2016 (UTC)

Popups, anchors and hidden anchors

Hello!

I came across the following set of links (on the documentation page for {{Harvard citation}}) and they work funny (try hovering over the links):

Does anyone know if Navigation popups can (should) manage hidden anchors to produce the same result as actual section titles? Place Clichy (talk) 12:56, 3 May 2016 (UTC)

It does sound like that would be the expected behavior; I'll read over some of the code involved to see if making that happen is possible. APerson (talk!) 16:30, 3 May 2016 (UTC)
Feel free to ping me if I don't respond in the next few days. APerson (talk!) 16:34, 3 May 2016 (UTC)
Popups works with Wikitext and tries to find a wikitext section that matches the anchor that you hover. A hidden anchor is not a section, and can thus not be found. Same for the shortcuts links. —TheDJ (talkcontribs) 18:40, 3 May 2016 (UTC)

Show last edit

For users, I think it would be helpful if we showed the time since the user made their last edit, in the style of PleaseStand's userinfo script. This would help with, among other things, finding users that are still active in a list of many editors. Any objections? APerson (talk!) 16:12, 22 May 2016 (UTC)

Great idea. I often try to solve it using the contribs list, but it's much slower—if it appears at all, otherwise I have to load the full contribs page. —Tacsipacsi (talk) 19:01, 22 May 2016 (UTC)
Doesn't seem like the idea has encountered a lot of opposition; edit request filed. APerson (talk!) 02:46, 24 May 2016 (UTC)
Edit request answered; this is now live. APerson (talk!) 11:06, 24 May 2016 (UTC)
Oddly, after this was added, normal user contrib, account creation info etc is now failing to show on some random accounts on commons for me..--Stemoc 12:49, 24 May 2016 (UTC)
Stemoc, thanks for noticing that! Could you give me an example of a username that has this problem? APerson (talk!) 18:52, 24 May 2016 (UTC)
Very useful, thanks! DMacks (talk) 14:15, 24 May 2016 (UTC)

Locked and hidden admins?

For some reason, whenever I hover over a link to a user's userspace, the popup shows them as both globally locked and hidden, despite the fact that such users - some of which are administrators in good standing - can't possibly be either. —Jeremy v^_^v Bori! 22:26, 15 June 2016 (UTC)

My bad. A change I authored, which essentially was fixing style issues in the code, apparently changed the behavior of the code too. The fix was reverted later on. See this thread for the initial edit request and subsequent discussion. Enterprisey (talk!(formerly APerson) 02:34, 19 June 2016 (UTC)

Can we put bugs on Phabricator?

I think it would be a bit more useful to have bugs and feature requests also hosted on Phabricator under the (proposed) navigation popups project for a number of reasons:

  1. Talk page archives aren't a good way of storing bugs that are probably still valid and need work.
  2. Wikipedia threads don't support things like filtering, moving between boards, and assignment, not without doing it in natural language instead of software fields.
  3. Phabricator has excellent Mediawiki integration, so people won't have to make a whole new account.
  4. {{Tracked}} provides a link from Wikipedia discussions back to Phab, which is very helpful.

What do you think? Pinging everyone who commented on my last version-control-related proposal (KrenairXaosfluxMichael Bednarek). Enterprisey (talk!(formerly APerson) 02:15, 8 June 2016 (UTC)

For the most part, phabricator is for software and configurations used by all the mediawiki projects. That does not preclude using it for other types of things if it makes sense. My biggest concern about THIS is that the main page for NAVPOP basically tells everyone: this has not been maintained in 7 years, don't expect anything to be fixed or supported. Has "development" been taken over by someone else, or has this been forked? — xaosflux Talk 02:24, 8 June 2016 (UTC)
xaosflux, well, looking at the last 7 sections on Mediawiki talk:Gadget-popups.js, five are edit requests; out of those five, four were from me. Each one was to implement a feature request of some description. I guess you could call this "development".
Would it be true to say that you're concerned about Popups not being maintained in the context of this discussion because you're worried that it might give the false impression that Popups was being maintained, or were you thinking about something else? Enterprisey (talk!(formerly APerson) 02:59, 8 June 2016 (UTC)
I supposed I'm ready to remove the big banner "The developer of popups (Lupin) has not been active on Wikipedia since 2009." - assuming this is being "community maintained". That banner suggests that there is only 1 developer, and they are gone. — xaosflux Talk 03:04, 8 June 2016 (UTC)
Back to the phab question - there is no code to "merge" (e.g. this isn't using gerrit right?) - and as far as multi-project: has this been ported to other wiki's (are they maintaining their own forks?). — xaosflux Talk 03:06, 8 June 2016 (UTC)
Looking at a few localized versions, it looks like they all import our code (at least the ones I've seen do). Enterprisey (talk!(formerly APerson) 03:13, 8 June 2016 (UTC)
At least a couple don’t show the style update of a few months ago—Meta and Commons IME—but if the recently added pronoun-gender indicator is anything to go by, all the projects where I’ve used it are functionally in synch.—Odysseus1479 04:25, 8 June 2016 (UTC)
Alright, xaosflux, I opened a Phab task, since I don't think anyone's objected. @everyone: feel free to comment here or over there if you have an opinion on whether we should create this. Enterprisey (talk!(formerly APerson) 04:23, 11 June 2016 (UTC)
I'm all for adding this to Phab. It's a major gadget used across a ton of projects. Nakon 02:40, 19 June 2016 (UTC)
Re people won't have to make a whole new account: Not completly, but it's still less accessible as one has to provide a reachable mail adress, which isn't neccessary for a normal WMF-Wiki account. So if this will move to Phab, please make sure that it's still fine to post bug reports to talk pages and that they'll still be taken seriously. --nenntmichruhigip (Diskussion) 09:58, 27 June 2016 (UTC)
nenntmichruhigip, oh, of course. I don't intend to discourage anyone from posting to talk pages in any way - I just want Phab to be used to track the implementation of features and the fixing of bugs. Enterprisey (talk!(formerly APerson) 03:32, 10 July 2016 (UTC)
Then it's fine for me :-) It's just that I had issues with a similar transition (not Wikimedia-related) in the past, where the maintainer's oppinion on where users should post bugs suddenly changed a bit later, which excluded quite some users, and some bugs were even not resolved because they've been posted to the wrong place first… Maybe I'm a bit over-careful after this. --nenntmichruhigip (Diskussion) 10:03, 10 July 2016 (UTC)
Ah, no problem at all. Yeah, I've recently been going through the archives of this page and filing new tasks based on old, unresolved discussions, but I still expect people to primarily discuss the gadget right here. Enterprisey (talk!(formerly APerson) 19:05, 10 July 2016 (UTC)

Account not registered

In earlier versions of the tool, when a non-existent account's (e.g. Ex4mp1e (talk · contribs)) pages were moused over, Popups would note that the account was not registered. That feature no longer works, but it was very useful to some of us in the community when investigating sockpuppetry and other forms of abuse. If this could be sorted out, I'm sure that I'm not the only one who would be thankful. ​—DoRD (talk)​ 13:41, 14 July 2016 (UTC)

On a similar theme, I seem to also recall earlier versions handling accounts with no edits or only deleted edits differently. I recall it displaying some account information and maybe the deleted edit count. For example, I do a lot of spambot account blocking. Here is one account with only deleted edits Hewmhraex08n (talk · contribs) and one with no edits Tusar2184 (talk · contribs). Both of these accounts are now blocked and it would be helpful to see that they are blocked. -- Gogo Dodo (talk) 06:03, 15 July 2016 (UTC)

How can I hide the popup when hover some references link (created by <ref> code). Thank you 123.18.35.202 (talk) 17:56, 1 August 2016 (UTC)

popupQueriedRevertToPreviousSummary option not working

I am trying to use this option to change the edit summary, but popups still gives me the default edit summary when reverting edits. My Chemistry romantic (talk) 07:25, 21 August 2016 (UTC)

Disable popups for images?

Hi. Is anyone aware of a way to completely disable navpopups over images? I tried the js options, but none of them have the desired effect for me. Aasasd (talk) 04:35, 11 September 2016 (UTC)

Thanks function

I know there's no maintainer, but if someone's interested, I think it'd be nice to have easy access to the "thanks" function in the popup over a diff. czar 19:24, 11 December 2015 (UTC)

I second that motion, it would be really handy. ··gracefool 💬 07:52, 19 January 2016 (UTC)
I have an idea about how to implement this; will start working on it soon. APerson (talk!) 03:57, 14 April 2016 (UTC)
 Edit requested. APerson (talk!) 22:17, 14 April 2016 (UTC)
And the edit request was answered, so this should be on the live gadget now. APerson (talk!) 02:02, 19 April 2016 (UTC)
@APerson: Thank you! I just realized "send thanks" is an popup action now. This somewhat addresses phab:T90404, a feature request that I created in February 2015. Stevie is the man! TalkWork 22:57, 22 October 2016 (UTC)

Fixing redirects - does it work?

See Wikipedia talk:Tools/Navigation popups/About fixing redirects#Is this still a feature? and below.

I can't get it to work, though I have installed window.popupFixRedirs = true; in User:Wbm1058/vector.jswindow.popupFixDabs = true; works great for me.

There is code in MediaWiki:Gadget-popups.js relating to this that seems to do something. What does it do?

var warnRedir = redirLink(target, navpop.article);
	setPopupHTML(warnRedir, 'popupWarnRedir', navpop.idNumber);

function redirLink(redirMatch, article) {
	// NB redirMatch is in wikiText
	var ret='';

	if (getValueOf('popupAppendRedirNavLinks') && getValueOf('popupNavLinks')) {
		ret += '<hr />';
		if (getValueOf('popupFixRedirs') && typeof autoEdit != 'undefined' && autoEdit) {
			log('redirLink: newTarget=' + redirMatch);
			ret += addPopupShortcut(changeLinkTargetLink({
				newTarget: redirMatch,
				text: popupString('Redirects'),
				hint: popupString('Fix this redirect'),
				summary: simplePrintf(getValueOf('popupFixRedirsSummary'),[article.toString(), redirMatch]),
				oldTarget: article.toString(),
				clickButton: getValueOf('popupRedirAutoClick'),
				minor: true,
				watch: getValueOf('popupWatchRedirredPages')
			}), 'R');
			ret += popupString(' to ');
		}
		else ret += popupString('Redirects') + popupString(' to ');
		return ret;
	}

	else return '<br> ' + popupString('Redirects') + popupString(' to ') +
			 titledWikiLink({article: new Title().fromWikiText(redirMatch), action: 'view',  /* FIXME: newWin */
							  text: safeDecodeURI(redirMatch), title: popupString('Bypass redirect')});
}

If anyone uses this, can you post screenshots of it in action in Wikipedia:Popups/Structure examples? wbm1058 (talk) 22:30, 21 November 2016 (UTC)
Note the related proposal at m:2016 Community Wishlist Survey/Categories/Editing#Mark redirects that have typos. – wbm1058 (talk) 16:01, 28 November 2016 (UTC)

Wbm1058, what do you expect it to do? It works fine for me - the "Redirects" in "Redirects to" that appears whenever I hover over a redirect turns into a green link that opens an edit window and invokes autoedit. Enterprisey (talk!) 02:35, 29 November 2016 (UTC)
Enterprisey, dang! thanks, now I see how it works and what it does. I just uploaded a screenshot. I installed User:Anomie/linkclassifier and set that up to use the linked-misspellings class to highlight the linked misspellings in pink. Hover over one of those to start. Right, don't get distracted by or hover over the big bold links to the redirect and the redirect target, or the blue "actions" and "popups" pulldown menus. Hover over the little (green) Redirects to and the hint box Fix this redirect appears. When I click on that, one of two things happens, it's seemingly random which:
  1. I get the preloaded edit summary Redirect bypass from [[Dilma Rousseff]] to [[Dilma Rousseff]] using [[:en:Wikipedia:Tools/Navigation_popups|popups]]
    and (No difference)... it doesn't change anything
  2. I get lucky and the preload summary is Redirect bypass from [[Dilma Roussef]] to [[Dilma Rousseff]] using [[:en:Wikipedia:Tools/Navigation_popups|popups]]
    and each of the two pink-highlighted linked-misspellings is changed from [[Dilma Roussef]] to the piped [[Dilma Rousseff|Dilma Roussef]].
    This is kind of stupid as the objective is to fix both the linked and reader-visible misspellings. It should just change it to [[Dilma Rousseff]].
Can anyone fix this script to do that? wbm1058 (talk) 04:14, 29 November 2016 (UTC)
To editor Wbm1058: Might want to come up with a similar new script for that, since this one is luscious for bypassing redirects in Navbars so the links will turn to boldface type in their articles.  Paine Ellsworth  u/c 23:13, 16 December 2016 (UTC)

Reference the discussion above, #Fixing redirects - does it work? and the tool listed at Preferences → GadgetsAppearance that's titled "Display links to disambiguation pages in orange".

I use both tools in my .js file:

  • window.popupFixDabs=true;
  • window.popupFixRedirs=true;

Note that on the Preferences → Gadgets page we can make links that may need to be disambiguated appear in the color "orange". In the popup box for FixRedirs the "Redirect" link appears in the color "green". This is a great tool to fix redirects in navbars and sidebars; however, it can be tedious to have to hover over every single link in some large navbars. So I wonder if we can adapt the FixRedirs tool to change the color of redirect links on pages in the same manner that we can see links that need disambiguation in orange? Green would be a good color to use for this. Is this doable?  Paine Ellsworth  u/c 08:29, 18 December 2016 (UTC)

@Paine Ellsworth: It is doable. Wikipedia:Visualizing redirects has the solution. LittleWink (talk) 10:54, 18 December 2016 (UTC)
Yes, that is excellent! Thank you so very much, LittleWink! Too cool for words!  Paine Ellsworth  u/c 11:31, 18 December 2016 (UTC)

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! TalkWork 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! TalkWork 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 wiki.riteme.site, 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.--JohnBlackburnewordsdeeds 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! TalkWork 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! TalkWork 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.--JohnBlackburnewordsdeeds 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! TalkWork 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! TalkWork 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)

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! TalkWork 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.--JohnBlackburnewordsdeeds 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! TalkWork 19:10, 6 January 2017 (UTC)
Facepalm 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.--JohnBlackburnewordsdeeds 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! TalkWork 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.--JohnBlackburnewordsdeeds 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! TalkWork 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)

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! TalkWork 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! TalkWork 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! TalkWork 16:38, 13 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! TalkWork 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 versionTheDJ (talkcontribs) 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)

suggestions

make the hoverzoom boxes show more.

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

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? Reywas92Talk 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

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)

Hello, good afternoon. It would be great if through the popup i'd be able to view a review of the article in other languages the same way i view in the original language, or at least be able to jump to another language through the popup. can someone add a link to other languages inside the popup that would enable it? melo kol haaretz kevodi (talk) 20:09, 28 June 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)
Good idea! Edit request filed. Enterprisey (talk!) 19:32, 28 June 2017 (UTC)
And it's done, so the feature should be live. Enterprisey (talk!) 20:33, 28 June 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)
@Beeblebrox and Michael Bednarek: A long tap, after exiting the menu your phone opens, shows the popup. melo kol haaretz kevodi (talk) 21:10, 28 June 2017 (UTC)

JavaScript error

Hello. Intermittently (about 1 time in 6) popups fail to load for me on a Wikipedia page. It doesn't seem to be restricted to any namespace or any particular type of page, nor is it consistent on any individual page. The popups load if I do a Ctrl+F5. Happens on latest Chrome and on latest Firefox.

When popups have failed to load, the JavaScript console reports the following error.

ReferenceError: addPortletLink is not defined
    at eval (eval at <anonymous> (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:4), <anonymous>:1:228)
    at HTMLDocument.<anonymous> (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:179)
    at fire (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:45)
    at Object.add [as done] (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:45)
    at jQuery.fn.init.jQuery.fn.ready (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:49)
    at new jQuery.fn.init (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:41)
    at jQuery (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:1)
    at load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:179
    at eval (eval at <anonymous> (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:4), <anonymous>:1:203)
    at eval (<anonymous>)}}

Have I configured something incorrectly? Or have I found a problem? Grateful for any help anyone can offer. --RobertGtalk 09:08, 3 October 2017 (UTC)

@RobertG: Yes, this kind of behavior (random javascript initiated elements going missing) is usually due to errors in a script, which most of the time is your own script. I've corrected a script of yours which was of an outdated form. I think it will be better for you now. —TheDJ (talkcontribs) 20:36, 3 October 2017 (UTC)
@TheDJ: I think that has done the trick. Many thanks. --RobertGtalk 13:01, 4 October 2017 (UTC)

Error

Javascript was not loading properly for me, and when I tried to find out what it was, I saw this: Uncaught TypeError: Cannot read property 'getParamValue' of undefined and the link next to it was the Popups script.

   at autoEdit (/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:1097)
   at HTMLDocument.<anonymous> (/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:7837)
   at fire (load.php:45)
   at Object.fireWith [as resolveWith] (load.php:46)
   at Function.ready (load.php:49)
   at completed (load.php:49)

-- 1989 04:53, 28 September 2017 (UTC)

Note for later. "if (!setupPopups.completed) { setupPopups(); }" setupPopups is async, seems that autoEdit doesn't wait for it to be completed. —TheDJ (talkcontribs) 13:40, 28 September 2017 (UTC)
It is my hope that my latest change fixes this. —TheDJ (talkcontribs) 19:17, 6 October 2017 (UTC)

Revert edit summary no longer autopopulating

Beginning today, on multiple computers and multiple browsers, popups no longer autopopulates the edit summary when I use it to revert edits. Any ideas what may be going wrong and how I can fix it? ElKevbo (talk) 02:33, 6 October 2017 (UTC)

I noticed the same thing (Firefox and Chrome). -- Michael Bednarek (talk) 05:43, 6 October 2017 (UTC)
This seems like a very significant issue. I've had another issue - discussed above in " Reverts/edits no longer autosaving" - for about six months now. If this tool is no longer being maintained then we shouldn't include it as an option for all (logged in) editors to use. ElKevbo (talk) 15:41, 6 October 2017 (UTC)
If that was the bar, we wouldn't have any gadgets left. Most are unmaintained. —TheDJ (talkcontribs) 18:41, 6 October 2017 (UTC)
If they're still working as intended then it may not be an immediate problem. This tool is not working as intended so it is an immediate problem. ElKevbo (talk) 20:04, 6 October 2017 (UTC)
The problem is that if we remove it as an option, it's gone for all 47000 people who currently have it installed (plus probably as many users on wiki's that reuse directly include this specific version) and there is no undo button for that action. So while adding things is easy, removing them is much more difficult. I for one do not intend on pissing off potentially 47000+ users. —TheDJ (talkcontribs) 20:16, 6 October 2017 (UTC)