Wikipedia talk:Tools/Navigation popups/Archive 6

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 4

→

Bug: Username with colon

Resolved

Pointing on the contributions of BabyyB(: (talk · contribs) shows the contributions of Null (talk · contribs) in the popup div. --Amalthea 19:34, 17 February 2009 (UTC)

... and the popup of that user name itself hasn't got the "User" menu. Probably related.--ospalh (talk) 13:12, 30 April 2009 (UTC)

Usermenu issue fixed. Still shows the incorrect contributions however. —TheDJ (talk • contribs) 13:24, 3 May 2009 (UTC)

Both cases fixed now. —TheDJ (talk • contribs) 14:12, 3 May 2009 (UTC)

Breaks secure wikimedia

Resolved

– Smallman12q (talk) 21:45, 22 April 2009 (UTC)

When using popups with Secure Wikipedia, popups breaks that security and sends things unencrypted resulting in "partial encryption". Perhaps popups should be modified to detect a secure wikipedia connection and send info encrypted to avoid breaking the encryption. To recreate this bug, simply go to the secure wikipedia link and have popups active. You will notice that the encryption is broken(in IE and firefox, it will show a broken lock). Now try going to secure wikipedia without popups and you will notice the encryption is not broken.Smallman12q (talk) 20:15, 19 February 2009 (UTC)

patches are welcome (remember that popups is not under active development). --TheDJ (talk • contribs) 21:09, 19 February 2009 (UTC)

I tried to check today what is broken, but as far as I can see the only thing breaking might be the images, and I can't do much about that. --TheDJ (talk • contribs) 18:40, 17 April 2009 (UTC)

Smallman, try switching from Lupin/popups.js to the gadget version, enabled in your preferences. Lupin/popups.js is used by external sites and has to use an absolute URL, with a hardcoded scheme. --Amalthea 20:46, 17 April 2009 (UTC)

Err, of course that could check where it's being called from, and use the https url instead. :) --Amalthea 20:49, 17 April 2009 (UTC)

Hmm...didn't think of that, I will try that and see what happens. ThanksSmallman12q (talk) 21:53, 17 April 2009 (UTC)

That fixed the problem. You should make a note about that somewhere. I've also found that wikied even in gadget form breaks the encryption...so still have a partially encrypted connection=(. Anyone know how to fix that?Smallman12q (talk) 22:06, 17 April 2009 (UTC)

Ask it's author User:Cacycle. --TheDJ (talk • contribs) 23:18, 17 April 2009 (UTC)

Will do. Thanks again.Smallman12q (talk) 21:45, 22 April 2009 (UTC)

Doesn't retrieve api.php properly on a shortened url wiki besides Wikipedia.org

Resolved

Yes, I'm using this gadget on another wiki in addition to wikipedia.org. I was looking through the code, and I wasn't sure how rigorous the code is with regards to "non-wikipedia" wikis when using this gadget. I have the popups and everything, but when I look at the URL, it appears to be using the wiki/index.php instead of the w/index.php. I'm pretty good with Javascript and could probably fix this myself, but I wanted to know if anyone else has gotten this to work on non-wikipedia wikis with short urls, first of all, thanks. -Verifex- (talk) 10:29, 1 March 2009 (UTC)

Yes, I have. IIRC you need to define the functions siteArticlePath and siteBotInterfacePath:

function siteArticlePath(){ return 'wiki'; }
function siteBotInterfacePath(){ return 'w'; }

Amalthea 11:32, 1 March 2009 (UTC)

There is an extension, svn:trunk/extensions/NavigationPopups which can load the popups and define those functions. -Steve Sanbeg (talk) 21:59, 3 March 2009 (UTC)

Better question is, why does it need that at all. Are there realistically still mediawiki websites deployed that don't have the JS globals like wgScript and wgUsername disabled ? --TheDJ (talk • contribs) 19:48, 17 April 2009 (UTC)

Which it now does. —TheDJ (talk • contribs) 01:09, 22 January 2010 (UTC)

Show changes after disambiguation

Resolved

I posted at Wikipedia:Village pump (technical)#Disambiguation_using_popups about how the "show changes" button suddenly stopped being automatically pressed when disambiguating using popups. No reply there, so I wonder if anyone watching this page can shed any light on this? --BrownHairedGirl (talk) • (contribs) 14:13, 11 March 2009 (UTC)

I did a disambiuguation link, and I did get the "show changes" page. עוד מישהו Od Mishehu 14:50, 11 March 2009 (UTC)

Yep, works for me too, with a copy of your monobook.js and popups enabled in the gadgets. Do you notice any errors in your javascript error console? Any changes to your MediaWiki skin or browser lately? Is popups still replacing the links? Is it writing the "The Show changes button has been automatically clicked. Please wait for the next page to load" into the page? --Amalthea 15:43, 11 March 2009 (UTC)

No changes at all. I tried turning off the gadgets version of popups and reinstalling Lupin's verion, then forece-reloading, but that made no difference.

So I shut down all tabs, cleared my cache, reloaded Firefox, purge-reloaded the main page, and it started working again. All very odd, but at least I got it back again ... and sorry for being silly and not doing all that before posting here. --BrownHairedGirl (talk) • (contribs) 16:15, 11 March 2009 (UTC)

One version

Resolved

If nobody minds, I'd like to change this script to import the gadget version of the script, so that only one needs to be maintained. See User:Amalthea/popups.js for the javascript. --Amalthea 13:59, 26 March 2009 (UTC)

You would need popups_importScript as well. Because this version (unlike the gadget) is used from outside Wikipedia. --TheDJ (talk • contribs) 15:43, 26 March 2009 (UTC)

Eh, thanks for that! I've changed it accordingly, and am going to test it on a remote wiki, too. --Amalthea 16:22, 26 March 2009 (UTC)

OK, I've made the switch now. Cheers, Amalthea 11:36, 9 April 2009 (UTC)

Only popup on right-click

Would it be possible to have an option where a popup would only be displayed when I right-click a link? — Blue-Haired Lawyer 10:33, 2 April 2009 (UTC)

Maybe even make it only pop up on right click (no option)? The drawbacks are that it would be less discoverable and would override the normal context menu. In any case, we have to solve the usability problem that this proposed solution is trying to solve: the pop up is so big that it obscures the content it refers to or the context around it. -Pgan002 (talk) 06:50, 27 August 2009 (UTC)

Should be protected

Resolved

I'm concerned that this page is not protected against malicious editing - this might be an easy way for attackers to effectively hijack accounts of admins and other users who use Popups. Are there measures in place to guard against this? Dcoetzee 02:35, 4 April 2009 (UTC)

The real scripts are in userspace User:Lupin/popups.js and in Mediawiki space MediaWiki:Gadget-popups.js, both only editable by admins --TheDJ (talk • contribs) 09:10, 4 April 2009 (UTC)

feature suggestion: user group lookup

Resolved

It would be nice if there was a feature for looking up which groups a user belongs to. Thanks! --Ixfd64 (talk) 03:23, 7 April 2009 (UTC)

I agree, that would fit in nicely. FWIW, you can use User:Voice of All/History/monobook.js which adds a "$" tab to user (talk) pages that displays the user groups (along with edit count, registration date, and (if applicable) block reason). --Amalthea 15:09, 9 April 2009 (UTC)

It looks like someone has added this feature. Thanks! --Ixfd64 (talk) 08:07, 20 April 2009 (UTC)

No problem. It was a personal favourite of mine as well. I did not intend on implementing any features, but this was just to simple and compelling :) --TheDJ (talk • contribs) 08:26, 20 April 2009 (UTC)

localization

I noticed that in popups appear user group names (as "editor, sysop, ..."). But this look not localizable. Is it ? Thanks --Arno Lagrange ✉ 15:56, 2 August 2009 (UTC)

Disambig detection

Popups currently are not correctly detecting all types of disambiguation pages listed at MediaWiki:Disambiguationspage. To correct this, I am using the following line in my personal options:

popupDabRegexp = '(([{][{]\\s*(airport disambig|callsigndis|disambig|disambig-chinese-char-title|disambig-cleanup|fish-dab|geodis|hndis|hndis-cleanup|hospitaldis|letter disambig|mathdab|na broadcast list|numberdis|powdis|roaddis|schooldis|dab|disamb|disamb-cleanup|biodab|hndisambig)\\s*[}][}])|(is a .*disambiguation.*page))';

Perhaps this should be incorporated into the standard script. --R'n'B (call me Russ) 13:48, 8 April 2009 (UTC)

I'd rather not change turn it into an explicit list, judging by how this script is kept up to date. How about the following:

'((\\{\\{\\s*(disambig))|((disambig|disamb|dab)(-cleanup)?\\s*}})|\\{\\{\\s*(((geo|hn|road?|school|number|callsign|hospital|letter |pow)dis(ambig|-cleanup)?)|na broadcast list)(\\s*\\|[^}]*)?\\s*}}|is a .*disambiguation.*page)'

It should recognize all currently on MediaWiki:Disambiguationspage. I've thrown out {{[234][lc][acw]}}; {{3CC}} and others are apparently all long deleted (didn't check all of them though). I've also removed {{shipindex}} which marks a WP:SETINDEX page.
Anyone sees a problem with it? Amalthea 14:16, 9 April 2009 (UTC)

See, the one you just added is already caught. :) --Amalthea 15:30, 9 April 2009 (UTC)

Thanks, I was just working on how to simplify this (as you suspected). (One thing I found, unfortunately, is that there are templates that match both '*dis}}' and '*dab}}' that are not disambiguation templates, so we can't safely take that shortcut.) I suggest we both test this out a little before finally endorsing it; subtle regexp errors are hard to detect. --R'n'B (call me Russ) 15:35, 9 April 2009 (UTC)

The one from above is more or less the current regex, which accepts ".*dab\s*}}", but is more restrictive with "dis" where it requires a prefix "(geo|hn|road?|school|number|callsign|hospital|letter |pow)". I mostly only simplified it, and tried to be rather restrictive with additions. Did you check how many false positives ".*dab\s*}}" gives?
Amalthea 15:46, 9 April 2009 (UTC)

Try this version:

'(([{][{]\\s*(([-\\w\\s]*disamb[-\\w\\s]*)|(bio|fish-|geo|math)?dab|(callsign|(geo-?)|hn|hospital|number|pow|(road?)|school)dis|hndis-cleanup|na broadcast list)(\\s*\\|[^}]*)?\\s*[}][}])|(is a .*disambiguation.*page))'

(or you can look at User:R'n'B/monobook.js where I have it formatted more nicely). I found four false positives with '*dab' already, and I've only gotten about halfway through the namespace! --R'n'B (call me Russ) 16:02, 9 April 2009 (UTC)

Time

Resolved

Is there a way to have popups use my time, instead of UTC time? CTJF83Talk 04:03, 9 April 2009 (UTC)

How can this be resolved with no response? (removed {{resolved}}) CTJF83Talk 23:55, 17 April 2009 (UTC)

Resolved in the batch of updates that i'm preparing for deployment. --TheDJ (talk • contribs) 00:03, 18 April 2009 (UTC)

Exploit?

Isn't is a possible security risk that it parses HTML/JS in edit summaries? As an example, if you hover over this, you'll see a button which triggers an alert(). I'm thinking someone could possbily make it automatically (or through onMouseOver or something) open custom links to things like Special:Block automatically blocking someone should an admin do it? --aktsu ^(t / c) 17:16, 9 April 2009 (UTC)

Looks like it is, yes. I'm surprised that no one noticed that before! I only have superficial knowledge of this script, but I'll try to patch it. --Amalthea 19:17, 9 April 2009 (UTC)

OK, fixed that, but I had to rewrite the parsing of the edit summaries. Man, that script is ... complex. If you can, please be on the lookout for links in edit summaries that aren't working as expected anymore. I'm thinking that some probably won't be recognized by popups anymore (they all should still work though).
Parsing should now be much closer to what MediaWiki does. --Amalthea 23:37, 9 April 2009 (UTC)

HTML injection on Lupin's popups (as a gadget), revision as of Apr 9

moved here from WP:VPT. Amalthea 21:46, 10 April 2009 (UTC) If you've got Navigation Popups on, hover over this link (I swear, it's clean!): [1]. You should see a giant Google logo, which is rendered using pure HTML...for real trouble, this link should create an alert box, which should show that this is a security hole. Unfortunately, with ~280KB of code, I haven't a clue how to go about fixing this particular hole, so I'm hoping someone does. nneonneo ^talk 21:07, 10 April 2009 (UTC)

woopsie

--NE2 21:23, 10 April 2009 (UTC)

Fantastic. I've spent a couple hours yesterday fixing a similar issue in edit summaries (see WT:Tools/Navigation popups#Exploit?). I'll try and have a look.
FWIW, posting this here is a bit WP:BEANSy, I'd rather you have posted this at the tool's talk page to keep it quiet, until its fixed. --Amalthea 21:44, 10 April 2009 (UTC)

Sorry about that, I wasn't entirely sure where to post it, here or at WP:VPT, and I thought I'd post at the latter as it had a higher chance of being noticed quickly -- I'll keep this in mind in the future. nneonneo ^talk 22:09, 10 April 2009 (UTC)

As a quick fix, I've disabled the special handling of template previews which has opened this particular hole. This means that template previews won't be as useful as they have been; if anyone is interested to fix this properly then they are welcome to do so, I don't think that I will in the near future.
Usually, all html tags are killed so it appears that popups is secure, but I haven't really understood the parser code so far: there could very well be more holes in it.
Amalthea 11:40, 14 April 2009 (UTC)

Reading through the docs, I think a better quick-fix would be to force popupPreviewRawTemplates, which should use raw template markup in place of prettified markup. nneonneo ^talk 13:49, 14 April 2009 (UTC)

Hmpf. Looking into it a bit longer, I've just made sure that all HTML tags are also removed from the source when previewing templates. I don't really like the template preview code though, and not only because it looks very bad on documentation subpages and the like. From what I can tell it's safe now though. --Amalthea 15:22, 14 April 2009 (UTC)

Removing everything non-api.php

I was thinking that enough time might have passed now for us to fully remove the Query.php and screen scraping routines from popups.js. Personally, I don't really care about 3rd parties that don't update their mediawiki installations or don't have api.php enabled. I can fairly easily do this, since i wrote all the api.php parts, and i still have a pretty good idea about what is old and what is new... --TheDJ (talk • contribs) 11:52, 14 April 2009 (UTC)

Almost any suggestion to reduces the file size of the js file will get my support. :) Amalthea 13:37, 14 April 2009 (UTC)

I'll prepare that sometime tonight then. --TheDJ (talk • contribs) 14:21, 14 April 2009 (UTC)

User:TheDJ/slimpopups.js all scraping and Query fallbacks have been removed. It also fixes an important issue with autoedit that I stumbled upon. --TheDJ (talk • contribs) 21:09, 14 April 2009 (UTC)

Next on my list will likely be to see if i can do something about the issue with File vs. Image --TheDJ (talk • contribs) 21:09, 14 April 2009 (UTC)

The timezone fix. This broke because the format in which this is stored changed internally in MediaWiki. --TheDJ (talk • contribs) 22:27, 14 April 2009 (UTC)

Ok great! I've only skimmed over the diff, but I noticed a ":File:Image" in a regex somewhere that seems wrong. I haven't looked into what it's supposed to be doing, I'm guessing you can fix it far easier than me. :)
Cheers, Amalthea 10:05, 15 April 2009 (UTC)

Personally, i'd like to delay the File Image changes for a little while later. They are very preliminary, and I could use some other folks testing that first. But good catch thx. The other changes however are a lot more reliable and shouldn't break popups any further than it was already broken. :D --TheDJ (talk • contribs) 10:29, 15 April 2009 (UTC)

Just remembered that I should add a check for api.php presences.... will do that in a few minutes. --TheDJ (talk • contribs) 10:37, 15 April 2009 (UTC)

I have now repaired the support for commons images and imageusage backlinks. Still need to add an api.php check, and then after some testing by people with Firefox, it should be good to go. --TheDJ (talk • contribs) 14:55, 15 April 2009 (UTC)

OK, I have done enough on this for now. This version is proposed for deployment. It is even tested on an external server and with API disabled. The changelog for this update:

removes all fallback (query/scrap) methods for elements that can api.php.
presents an alert if api is not enabled on your mediawiki installation
fixes an issue with autoedits not autosaving/previewing.
now supports images from Commons again
now supports descriptions from Commons again
"hacks" to support both the Image and File namespace
switches from custom to firebug/safari error/debug logging
fixes an issue with timezone corrections that had been broken for a while now.
adds support for several new interwiki prefixes
fixes an issue with listing image usages.
contributions tree removed due to brokenness.
always shows template code when looking at a template or an image link.
switched to soxred editcounter
preview user's info. blocked/groups/editcount. Thx to Splarka
removes editpage selection preview.
fixes "latest edits" and "diff my edit"

Please include a diff of this post in the edit-summary when applied, so the changes can easily be found. If any regressions are found, I'll fix them. --TheDJ (talk • contribs) 20:14, 17 April 2009 (UTC)

That version would loose the it.wiki namespace fix I applied to it ;) Current version is 284486788.
Do you want to do that right away, or rather give it the weekend? I'm going to be offline most of the weekend, so I couldn't react if something were to break.
BTW, I really hate "always shows template code when looking at a template or an image link", that was the first thing I configured back the way it was. Why did you change it?
Cheers, Amalthea 20:43, 17 April 2009 (UTC)

The primary reason i did it for images, was to be able to determine information at all. Most image information is in a template. :( For templates it's kinda the same. There is no useful information for most templates, unless you have this option. Bigger previews, but at least you see "something". --TheDJ (talk • contribs) 23:20, 17 April 2009 (UTC)

Just realized that it might be handy to have a full diff of the proposed changes. These include Amalthea's latest edit for the Italian namespaces. --TheDJ (talk • contribs) 21:58, 18 April 2009 (UTC)

Done, thanks. Let me know if something breaks.
And from the looks of it you'll be putting the next one live yourself. Good luck with that, and I'm glad I won't have to do your editprotected requests that I keep encountering. :)
Cheers, Amalthea 17:05, 19 April 2009 (UTC)

editpage selection preview is back, per below↓. --Amalthea 10:51, 20 April 2009 (UTC)

Whoa...feature removed?

Resolved

It used to be that you could select a wikilink in the edit box and click in the middle, and it would bring up popups for that link. I found this very useful. Has this been disabled? --NE2 23:21, 19 April 2009 (UTC)

It isn't working for me, either, and I often use that (although I only hovered over the link, I didn't click it)! I hope it can be restored. --Auntof6 (talk) 00:46, 20 April 2009 (UTC)

It can if so desired. It was a tad buggy at times with the new changes and since I figured few people used it, I disabled and then removed it. I can look into fixing it and bringing it back. (Though likely not before next week, I'm rewriting HotCat atm.) --TheDJ (talk • contribs) 01:13, 20 April 2009 (UTC)

Please! I found it very useful in checking for links to disambiguations or making sure I got the name right (such as Railway vs. Railroad) when writing an article. (I did click it, by the way, though almost always in a new tab.) In the meantime, where's the old code that I can put directly in my monobook? --NE2 01:38, 20 April 2009 (UTC)

You can use the previous version by placing

importStylesheet('MediaWiki:Gadget-navpop.css');
importScriptURI(wgScript + '?title=MediaWiki:Gadget-popups.js&oldid=284486624&action=raw&ctype=text/javascript');

in your monobook, which uses the version before the change. Amalthea 06:59, 20 April 2009 (UTC)

Thank you :) --NE2 09:04, 20 April 2009 (UTC)

I'd also like to see the feature restored, please, as I made constant use of it. Thanks for all the work, by the way! --Ckatz^chat _spy 09:32, 20 April 2009 (UTC)

Alright, it's back. You'll need to refresh your browser cache. Cheers, Amalthea 10:47, 20 April 2009 (UTC)

Thank you! --Auntof6 (talk) 21:58, 20 April 2009 (UTC)

Users status

Resolved

I just noticed that hovering over user names now produced a report with their user rights and whether they are blocked. I can't find the code but I guess it's your doing, great job it's very useful! -- lucasbfr ^talk 10:05, 20 April 2009 (UTC)

#feature suggestion: user group lookup. BTW, a preemptive answer on any request for being able to see if a user is autoconfirmed, which i'm sure will be requested at some point. This is not possible, because autoconfirmed is not a distinct group. You can be part of it, and then drop out later due to a different editing location for instance. Autoconfirmed status needs the "context" of a specific request/edit that user is doing in the software at a specific time from a specific location. That context is not available when someone else checks the groups of a user. --TheDJ (talk • contribs) 10:51, 20 April 2009 (UTC)

Non-latin usernames are being marked as not a registered username.--Kwj2772 (talk) 10:26, 2 May 2009 (UTC)

Fixed, check User:ﺾﺶﻚﻰﭹ for example. Thanks, Amalthea 11:09, 2 May 2009 (UTC)

Fixed a related bug with previewing contributions of these users. —TheDJ (talk • contribs) 14:27, 3 May 2009 (UTC)

wrong edit count

The edit count feature is sometimes incorrect. For example, it says Kenny on Kumhos (talk · contribs) has made 12 edits, but he actually only has nine, including deleted ones. --Ixfd64 (talk) 22:06, 23 April 2009 (UTC)

The toolserver reports 12 as well: http://toolserver.org/~soxred93/count/index.php?name=Kenny%20on%20Kumhos&lang=en&wiki=wikipedia So at a database level he has 12. I don't think it matters terribly much, but if needed I can ask the developers if there is a reason for this. --TheDJ (talk • contribs) 22:41, 23 April 2009 (UTC)

Bug: Disambiguation to wiktionary and case

If you dab with popups to wiktionary, the script changes the word to upper case. That's right for wikipedia pages, but wrong for wiktionary. In that cases the capitalisation should be preserved. Example: reunion to wikt:Reunion. That changed the link to wikt:Reunion, but sholud have been wikt:reunion, quite a differnt page.

Maybe the code change isn't all that hard, but I don't know (yet) where to start.--ospalh (talk) 17:34, 28 April 2009 (UTC)

IE 8

Resolved

I downloaded Internet Explorer 8 to my Windows XP, and now Popups won't work! What can I do to fix it? Also, does anyone know how to turn off the color-changing tabs feature? Thank you very much!! Reywas92 ^Talk 22:57, 29 April 2009 (UTC)

It did work with earlier versions of IE ? (Unfortunately, I don't have IE8, so I cannot track this problem, does anyone else have Windows/IE ? ) —TheDJ (talk • contribs) 23:14, 29 April 2009 (UTC)

I got it to work; it may have had to do with the popup blocker. But the colored tabs are still annoying. Thanks, Reywas92 ^Talk 23:25, 29 April 2009 (UTC)

Can you make a screenshot of that ? —TheDJ (talk • contribs) 01:07, 30 April 2009 (UTC)

I'm sorry! I was just ranting about IE 8's new features I'd like to turn off; there isn't any problem with popups. :) Reywas92 ^Talk 02:18, 30 April 2009 (UTC)

How did you get it to work? I have the same issue, though it works if I enable the new "compatability view" feature. (And yes, those pyschedelic tabs are retarded.) PC78 (talk) 13:05, 1 May 2009 (UTC)

Same behaviour here under IE8; navigation popups only work in Compatibility View, which is a real shame because some HTML float thingies work better in "strict" mode. Is anyone looking at this problem? -- Michael Bednarek (talk) 12:05, 9 May 2009 (UTC)

I got a Javascript error in IE8 if that is of any help:

Message: Not implemented

Line: 171
Char: 5
Code: 0
URI: http://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki:Gadget-popups.js

Like suggested above, it does work in "Compatibility View" mode. Astronaut (talk) 09:01, 15 May 2009 (UTC)

Thanks that helps a lot. That seems like "setExpression". Googling turns up:

I'm seeing the same issue with IE8 and setExpression. From MSDN: 
http://msdn.microsoft.com/en-us/library/ms537634.aspx

"As of Windows Internet Explorer 8, dynamic properties have been 
deprecated and are only supported for Web pages displayed in IE5 mode 
or IE7 mode."

I'll see about fixing that, though there will likely be more issues. —TheDJ (talk • contribs) 10:57, 15 May 2009 (UTC)

Try clearing out your cache, and perhaps it will work now. If the same or any other errors are still reported, then I would love to hear about it. —TheDJ (talk • contribs) 13:24, 15 May 2009 (UTC)

Fix is available here. Cheers, Jack Merridew 13:30, 15 May 2009 (UTC)

That works. Thank you very much, TheDJ! Or should I say Dank u wel! -- Michael Bednarek (talk) 14:52, 15 May 2009 (UTC)

Nice, resolved than. Thanks (Bedankt) for the feedback. —TheDJ (talk • contribs) 15:24, 15 May 2009 (UTC)

ARIN lookup only in IE?

I access Wikipedia through various browsers, depending where I am. When I'm using Internet Explorer, the Navigation popup tool gives me a useful "ARIN lookup" link when I hover the mouse over an anonymous IP address user page or talk page link.

However, this useful ARIN lookup feature doesn't appear when I use Firefox or Chrome. Can it be added for those browsers? Thanks. =Axlq 02:53, 6 May 2009 (UTC)

Um, anybody have an answer? =Axlq 02:02, 26 May 2009 (UTC)

I can confirm Axlq's observation: the popup box in IE7 for Special:Contributions/66.66.66.66 contains big & bold the "username" and lastEdit|lastContrib|sinceMe. The next 3 lines contain

contrib•log•ARIN lookup•count

edit•history•un|watch•talk|edit|new

whatLinksHere•relatedChanges•move. The rest of the box contains that user's most recent edits. All these are clickable links.

The popup in Firefox contains the big & bold "username" and a menu strip "actions • user • popups" and the list of recent edits. The three menu items produce each a drop-down menu with many clickable options, but "ARIN lookup" is not among them. It seems that popups in Firefox doesn't distinguish between a proper username and an anonymous IP when displaying data on hovering over Special:Contributions/<someID> . -- Michael Bednarek (talk) 05:34, 26 May 2009 (UTC)

Ah, this is simple popups vs. menu popups. Menu popups has 2 modes. shortmenus (the default) and menus. You can switch by adding "popupStructure='menus';" to your monobook.js —TheDJ (talk • contribs) 09:09, 26 May 2009 (UTC)

In spite of searching, I don't find any file called "monobook.js" anywhere on my computer, as far as I can tell. I don't have Firefox, I'm using IE and Chrome. IE shows the "ARIN Lookup" option, but Chrome doesn't. Any suggestions? =Axlq 23:01, 26 May 2009 (UTC)

Your monobook.js —TheDJ (talk • contribs) 23:15, 26 May 2009 (UTC)

(ec) User:Axlq/monobook.js. :) That's a javascript file which is automatically loaded if you're using the Monobook skin (see Wikipedia:Skin). I'm a bit surprised though why the popups mode should depend on the browser used? Amalthea 23:20, 26 May 2009 (UTC)

Mostly because IE 6 used to be very bad at those menu's. Probably no one has tested them since IE7 and IE8. —TheDJ (talk • contribs) 23:29, 26 May 2009 (UTC)

Thanks. I am not using any particular skin, just whatever Wikipedia wants as a default. I find it curious that I have to create a subpage just so popups will work consistently across all my browsers. Anyway, I now get the ARIN Lookup selection in Chrome. I had to clear all the browser data to get it working. =Axlq 21:37, 1 June 2009 (UTC)

"encodeURIcomponent is not defined" error

Resolved

I'm seeing an error with Popups when hovering over certain links, such as those for user contributions and user talk in the enhanced watchlist page. (This is with the Gadgets version, using Firefox 3.0.10 on Windows XP.) The message in the error console reads as follows:

"Error: encodeURIcomponent is not defined
Source File: http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript Line: 7359"

Any ideas? (Apologies if this has been noted before.) --Ckatz^chat _spy 17:06, 7 May 2009 (UTC)

Yikes, will fix ASAP —TheDJ (talk • contribs) 17:14, 7 May 2009 (UTC)

Wow, you're fast (and good!) Thanks for fixing that. Cheers. --Ckatz^chat _spy 00:42, 8 May 2009 (UTC)

newswire poke test

Resolved

just ignore _→AzaToth 18:58, 10 May 2009 (UTC)

Losing content after references

Resolved

– per this comment. Amalthea 09:58, 12 May 2009 (UTC)

I was editing 2009 swine flu outbreak, and I did not see the External Links section or the footer templates following the References section (which is just the reflist|2 template). On checking these sections appeared approximately 2 times out of 7 when I clicked the "article" bar to reload the page. Mike Serfas (talk) 09:31, 12 May 2009 (UTC)

What does that have to do with popups? Seems like a server caching or parser error (and I seem to remember having read of similar problems at WP:VPT). Amalthea 09:38, 12 May 2009 (UTC)

The error seemed to go away just as I removed this code from Monoscript.js, and seemed to return somewhat after I reenabled it - but it is intermittent, and I'm not sure that it is relevant. Mike Serfas (talk) 04:30, 15 May 2009 (UTC)

Popups is a large script, that add significantly to the load of your browser when installed. So it can very well influence other scripts and trigger race conditions and bugs in other scripts. These kinds of problems are often the most difficult to track. —TheDJ (talk • contribs) 13:30, 15 May 2009 (UTC)

Broken in chrome

Popups don't work in my Google Chrome browser. The problem extended to my other browsers (IE and Firefox), but was fixed when I updated the code on my monobook.js page and cleared the cache. The problem remains in Chrome though.--Bkwillwm (talk) 02:39, 1 June 2009 (UTC)

It started working again in Chrome. No idea why.--Bkwillwm (talk) 03:33, 1 June 2009 (UTC)

Named ref breaks preview

For example, the preview of Project Chanology. Appears to be due to referring to a following named reference rather than a previous one. OrangeDog (talk • edits) 21:24, 9 June 2009 (UTC)

I don't see this problem, perhaps you can make a screenshot ? Also browser an OS versions are important information if you report bugs. —TheDJ (talk • contribs) 01:51, 20 June 2009 (UTC)

Wiktionary

The popups show only the first language on Wiktionary if the word exists in multiple languages. Please try the word: تازه Maybe its a problem of the WikiLook extension for Firefox I use. But the help of this extension mentiones this page, because the programm somehow relies on that functionality. --helohe (talk) 00:14, 19 June 2009 (UTC)

Some links and or examples would be useful. —TheDJ (talk • contribs) 01:50, 20 June 2009 (UTC)

The extension I use (https://addons.mozilla.org/en-US/firefox/addon/7675) allows holding the Shift key and moving the mouse over a Word, then brings up the popup using this Navigation Popups funktionality. I tested it with this word: wikt:تازه .

Then you should contact it's developer. No one here is aware or participates in the development of this Firefox extension as far as I know. —TheDJ (talk • contribs) 20:54, 21 June 2009 (UTC)

Disambiguation of DN template

It looks like the disambiguation doesn't work if the link to disambiguate is inside a {{dn}} template. Try it out in my sandbox: With "popupFixDabs=true" in your "monobook.js" ("whatever_skin_you_use.js") hover over one of the "disambiguation needed" links, click one of the green links at the bottom of the pop-up, and see now changes made. I'm using Firefox 3.0.11 on Windows.--ospalh (talk) 14:17, 22 June 2009 (UTC)

This is logical because a template != a link. I'm not sure about a simply and elegant way in which to support BOTH methods in a single query at this point in time. If anyone has any good suggestions, I welcome them. —TheDJ (talk • contribs) 18:37, 3 July 2009 (UTC)

Firefox 3.5 - can't select text in popups

Resolved

On FF 3.5, can't select (and copy) text from popups. It was very usefull. Gustronico (talk) 16:32, 2 July 2009 (UTC)

Was just coming here to say the same. Sad face. Any fix/workaround? –xeno^talk 14:53, 4 July 2009 (UTC)
- I have not had time to look into this yet. —TheDJ (talk • contribs) 16:31, 4 July 2009 (UTC)
- Well, now that I updated my Firefox, I could confirm this. Problem lies with the draggability of the popup divs, apparently the mousedowns aren't passed through to Firefox anymore so that it can't start the select. I haven't looked at a fix for this, but simply disabled it for myself now since I never ever drag them around anyway (but copy text quite frequently):

popupDraggable = false;
importScript('User:Amalthea/popups.js'); //[[User:Amalthea/popups.js]]
importStylesheet('MediaWiki:Gadget-navpop.css');

I could add the option to disable draggability to the gadget script, but I'm kinda hoping that DJ might have some insight in how to fix this properly?
Amalthea 15:42, 15 July 2009 (UTC)

I've incoroprated this into the gadget, for now, so you can just add

popupDraggable = false;

to your monobook.js if you'd like to use the workaround. Amalthea 09:25, 25 July 2009 (UTC)

Thank the maker! (And you!) –xeno^talk 03:11, 30 July 2009 (UTC)

Sorry for asking, but is this supposed to help with the problem? I just added the line which is mentioned above to my monobook.js (in de-WP) - and nothing changed. Could someone please explain to me what I have to do in a way I can understand? I am not an monobook.js expert. Thanks a lot, --Scooter ^{(this one)} 14:44, 1 August 2009 (UTC)

Have you cleared your cache? The changes won't take effect until you do. See WP:BYPASS. –xeno^talk 16:02, 2 August 2009 (UTC)

De-wiki uses a copy of the NAVPOP script instead of pointing here, so that won't help. I'd suggest hoping that DJ can fix the problem, waiting for him to do so, and then having someone update the de-wiki version. Amalthea 16:22, 2 August 2009 (UTC)

I think i finally understand this problem. The issue is using "o.onmousedown" vs. addEventListener() I think. I'll try rewriting the event routines and then hopefully the problem will be solved. —TheDJ (talk • contribs) 15:49, 1 August 2009 (UTC)

Got it. The problem is that FF 3.5 supports the new HTML 5 drag and drop specification which includes the "draggable" attribute for html elements. Popups was also using this attribute keyword, forcing the element into the new D&D mode. This makes the div basically the "draggable" object with priority over that of selection (which is a drag operation) of the text. —TheDJ (talk • contribs) 17:55, 2 August 2009 (UTC)

Good work! Amalthea 19:48, 2 August 2009 (UTC)

Nice to hear. But who's the one to update the de-wiki version now? I'd really appreciate that. --Scooter ^{(this one)} 21:08, 2 August 2009 (UTC)

I'd suggest you ask de:User:Gnu1742, he's the one who imported the last version, and he's still active.
There have been some modifications to it, those need to be worked into the current version. Amalthea 21:53, 2 August 2009 (UTC)

Well, the problem is known for two weeks in de now, but nobody managed to solve it until now. Couldn't someone of you care about this? --Scooter ^{(this one)} 16:43, 15 August 2009 (UTC)

Unfortunately not. —TheDJ (talk • contribs) 20:31, 15 August 2009 (UTC)

Username contributions breaks

Resolved

The number of contribs breaks for User:Lifebaka. Any idea why? —M C 10|Sign here! 02:07, 25 July 2009 (UTC)

His registration date isn't retrievable via API. Which is weird, but I've seen that a couple of times with no apparent rule.
I've changed navpop so that it will display editcount and registration date even if one of the two is missing. This will take care of the bug, and now also display the registration date for users without any edits. Not particularly clean, but I didn't want to introduce new texts that need translating. Amalthea 09:23, 25 July 2009 (UTC)

Bug when disambiguating

When disambiguating [[Rayleigh]] to [[Rayleigh, Essex|Rayleigh]], the script also changed [[Rayleigh railway station|Rayleigh]] to [[Rayleigh, Essex|Rayleigh]]. Colonies Chris (talk) 08:27, 28 July 2009 (UTC)

Works for me on User:Amalthea/test20. Amalthea 13:19, 28 July 2009 (UTC)

Interaction with beta user interface

I am trying the beta user interface, and the popups have disappeared. Do I need to reload them to a different location? Thanks for any help. Mike Christie (talk) 22:38, 9 August 2009 (UTC)

Wikipedia:Vector#My Gadgets and Javascript tools are broken —TheDJ (talk • contribs) 00:47, 10 August 2009 (UTC)
Thanks; that worked. Mike Christie (talk) 11:17, 10 August 2009 (UTC)
I'm also using beta. My popups haven't disappeared, but something is acting differently. When I used a popup to revert a change under beta, the edit summary wasn't displayed for editing as it usually is. --Auntof6 (talk) 06:50, 10 August 2009 (UTC)
- As the above mentioned section says, the vector skin's user script file is vector.js. If you have previously configured NAVPOP in your monobook.js, you'll have to copy (or import) those settings. Amalthea 10:45, 10 August 2009 (UTC)

I have been using Beta but it will not allow me to use the "popupFixDabs" option, no added menu appears, tried adding script to the vector page mentioned above but that didnt seem to change anything. The option works fine on normal version of wiki for me. BritishWatcher (talk) 16:05, 22 August 2009 (UTC)

Have you made sure to bypass your cache once you added the option to your vector.js? Amalthea 13:28, 24 August 2009 (UTC)

Thanks it does work now, not sure if it was because i didnt clear cache properly or i may of entered the code wrong before. Works great now though :) BritishWatcher (talk) 13:41, 24 August 2009 (UTC)

Userbox

Is there a userbox for using popups? I know there's one for Twinkle, Huggle and others. --Scythre ^Talk _Contribs 12:18, 14 August 2009 (UTC)

popupOnlyArticleLinks=false and Vector skin

I've prepared a fix for a situation when one uses popupOnlyArticleLinks=false and Vector. The problem is that popups appear over actions menu and makes it less usable. Anyway source the fixed mouseOverWikiLink2 is below (we use it on pl.wiki).

function mouseOverWikiLink2(a, evt) {
	if (dealWithModifier(a,evt)) { return; }
	if (!getValueOf('popupOnlyArticleLinks'))
	{
		if (a.href == location.href+'#') { return; }
		// in vector dropdown menu?
		for (var i=4, tmp=a.parentNode; 
			i && tmp.parentNode && tmp.nodeName!='BODY';
			tmp = tmp.parentNode, i--)
		{
			if (tmp.id=='p-cactions')
			{
				return;
			}
		}
	}
	if ( getValueOf('removeTitles') ) { removeTitle(a); }
	if ( a==pg.current.link && a.navpopup && a.navpopup.isVisible() ) { return; }
	pg.current.link=a;

	if (getValueOf('simplePopups') && pg.option.popupStructure===null) {
		// reset *default value* of popupStructure
		setDefault('popupStructure', 'original');
	}

	var article=(new Title()).fromAnchor(a);
	// set global variable (ugh) to hold article (wikipage)
	pg.current.article = article;
	if (pg.timer.image !== null) {
		clearInterval(pg.timer.image);
		pg.timer.image=null;
		pg.counter.checkImages=0;
	}

	if (!a.navpopup) {
		// FIXME: this doesn't behave well if you mouse out of a popup
		// directly into a link with the same href
		if (pg.current.linksHash[a.href] && false) {
			a.navpopup = pg.current.linksHash[a.href];
		}
		else {
			a.navpopup=newNavpopup(a, article);
			pg.current.linksHash[a.href] = a.navpopup;
			pg.current.links.push(a);
		}
	}
	if (a.navpopup.pending===null || a.navpopup.pending!==0) {
		// either fresh popups or those with unfinshed business are redone from scratch
		simplePopupContent(a, article);
	}
	a.navpopup.showSoonIfStable(a.navpopup.delay);

	getValueOf('popupInitialWidth');

	clearInterval(pg.timer.checkPopupPosition);
	pg.timer.checkPopupPosition=setInterval(checkPopupPosition, 600);

	if(getValueOf('simplePopups')) {
		if (getValueOf('popupPreviewButton') && !a.simpleNoMore) {
			var d=document.createElement('div');
			d.className='popupPreviewButtonDiv';
			var s=document.createElement('span');
			d.appendChild(s);
			s.className='popupPreviewButton';
			s['on' + getValueOf('popupPreviewButtonEvent')] = function() {
				a.simpleNoMore=true;
				nonsimplePopupContent(a,article);
			}
			s.innerHTML=popupString('show preview');
			setPopupHTML(d, 'popupPreview', a.navpopup.idNumber);
		}
		return;
	}

	if (a.navpopup.pending!==0 ) {
	    nonsimplePopupContent(a, article);
	}
}

Regards, --Nux (talk) 14:14, 18 August 2009 (UTC)

BTW: I think this regExp values should be translateable (in strings.js): pg.re.contribs, pg.re.email, pg.re.backlinks; currently we use direct fix in setRegexps function:

	pg.re.contribs =RegExp('(title=|/)' + sp + '(?:%3A|:)Wk%C5%82ad' + '(&target=|/|/' + pg.ns.user+':)(.*)') ;
	pg.re.email =RegExp('(title=|/)' + sp + '(?:%3A|:)E-Mail' + '(&target=|/|/(?:' + pg.ns.user+':)?)(.*)') ;
	pg.re.backlinks =RegExp('(title=|/)' + sp + '(?:%3A|:)Linkuj%C4%85ce' + '(&target=|/)([^&]*)');

Thanks, Nux!
Hmm, I'm wondering though, wouldn't it also work to use the same mechanism used by the nopopups class, i.e. probably modifying markNopopupSpanLinks to mark vectorMenu? This seems less hackish to me.
Amalthea 15:14, 18 August 2009 (UTC)

(e/c) I propose an alternate implementation. During setup, we run:

if (!getValueOf('popupOnlyArticleLinks')) {
var vmenus = getElementsByClassName( document, "div", "vectorMenu");
 for( i= 0; vmenus && i< vmenus.length; i++ ) {
  var h5 = vmenus[i].getElementsByTagName("h5")[0];
  if( h5 ) h5.className = h5.className+ " nopopups";
 }
}

alternative method. —TheDJ (talk • contribs) 15:18, 18 August 2009 (UTC)

Your method is probably even more effecient Amalthea. —TheDJ (talk • contribs) 15:19, 18 August 2009 (UTC)

Implemented. —TheDJ (talk • contribs) 17:08, 18 August 2009 (UTC)

User space

The "space" option should link to Special:PrefixIndex&namespace=2&prefix=%s instead of Special:PrefixIndex&namespace=2&from=%s. Compare [2] vs. [3]. --Tgr (talk) 17:03, 21 August 2009 (UTC)

Done, thanks. Amalthea 21:05, 21 August 2009 (UTC)

popupAdminLinks

Resolved

Shouldn't popupAdminLinks default to true if the user is in the sysop group? --Tgr (talk) 17:28, 21 August 2009 (UTC)

i'll see about implementing that. popups likely predates the time that such information was available to scripts. —TheDJ (talk • contribs) 19:21, 21 August 2009 (UTC)

Hmm, I was about to fix it, using something like

wgUserGroups != null && wgUserGroups.indexOf( "sysop" ) != -1

, but that's actually too easy. The proper way would be through a siteinfo API request, and the proper proper way would then be to exacly activate all the links that have meaning for all groups a user is in, and the rights set for those groups. :)
Amalthea 21:05, 21 August 2009 (UTC)

I don't think it would be worth one more API call per page load. Also, perfect is the enemy of the good :) --Tgr (talk) 19:00, 22 August 2009 (UTC)

Usability problem: pop-up obscures content

The pop up is often helpful, but it also often obscures a huge portion of the image it refers or the caption of the image or the text surrounding the link the pop up is referring to. That's a big usability problem that diminishes the usefulness of the pop up.[4][5] To avoid that, the pop up should appear some distance away from the target link, and be connected to it like a speech bubble.[6][7] The idea is implemented, for example, in Google Maps. The pop-up can also appear outside the browser window, because the content inside the window is more important than other windows. And, maybe the pop-up can be translucent. -Pgan002 (talk) 08:08, 27 August 2009 (UTC)

Since the point is to help with editing, I'm not sure if this is actually a problem. --NE2 08:18, 27 August 2009 (UTC)

I think it helps both with editing and reading: the user does not have to open a new page to get an idea of a linked topic. And obscuring content is a problem just as much a problem when editing. -Pgan002 (talk) 18:05, 28 August 2009 (UTC)

The popup is draggable. Just push shift and pull it out of the way if needed. —TheDJ (talk • contribs) 10:21, 27 August 2009 (UTC)

I did not realize that -- it would be good to have a small (10x10-pixels) drag handle, like WikEd's resize handle. But the pop-up often appears in the way, and this unnecessary interaction (dragging) should be avoided. It would be better if the pop-up appeared further from the target. -Pgan002 (talk) 18:05, 28 August 2009 (UTC)

I fully agree that popups makes Wikipedia almost unusable with all those unintentional popups popping up. A long time ago I have asked to add a Ctrl-hover option so the popups appear only when pushing the Ctrl button. I am pretty sure that this configuration option still exists (I also remember that something did not work as expected and I gave up on using popups altogether). Cacycle (talk) 18:41, 28 August 2009 (UTC)

It is the option "popupModifier=" and it works for me. If you have a problem with it, please let me know. —TheDJ (talk • contribs) 13:36, 29 August 2009 (UTC)

I have added the popupModifier option prominently to option list. I have also tested this option. The problem is that it currently only works if you push the modifier key and then move the mouse pointer over the link. It fails, however, in the much more common situation were you already hover over the link and then push the modifier key. To make the modifier key a useful option there has to be an event listener for the modifier key. If you add this missing piece I promise that I will use popups again ;-) Cacycle (talk) 18:14, 29 August 2009 (UTC)

Oh, that works for me on Safari. You are using firefox right ? I'll take a look. —TheDJ (talk • contribs) 21:58, 29 August 2009 (UTC)

Yes, Firefox. It actually kind of works now, I have now idea why it did not before. Now there is a new problem with 'ctrl': the popup does not disappear when moving off the link, instead the popup moves around with the mouse pointer until you hit another link. Cacycle (talk) 22:56, 29 August 2009 (UTC)

What Cacycle describes is a slightly different but related problem. A better solution might be to first pop up a small, unobtrusive pop-up, and if the user moves the mouse over that, it expands to the full pop-up. This makes accidental pop-ups much less disruptive, removes the need to discover modifier keys, makes pop-ups usable with just a mouse, removes one configuration option, and makes the initial pop-ups less obtrusive. The small pop-up can even be made translucent, like in M$ Word 2007. The full pop-up should still pop-up further away from the target, though. -Pgan002 (talk) 08:10, 8 September 2009 (UTC)

I agree that popups hide actual text being read. As I read I often move mouse over the text, or select some portions of text, so mouse movement and stopping on link happens quite often. It seems that per documentation popups should be hidden when mouse leaves their area, however they aren't. It took me long time to figure out that I should click green icon and then click outside popup to close it, and it's really not comfortable thing to do. I could propose some simple popup configuration menu - to allow disabling popups by setting browser cookie, as I generally don't want to see them. —Preceding unsigned comment added by 193.238.213.215 (talk) 02:11, 19 December 2009 (UTC)

Broken user popuppopup

Resolved

For some reason, neither user nor user talk page link of Per aspera ad Astra (talk · contribs) will give me a popup. I haven't investigated myself yet. Amalthea 16:31, 14 September 2009 (UTC)

The link posted here works for me (on Firefox). Regards, decltype (talk) 13:28, 17 September 2009 (UTC)

Weird? It works for me now, too. I went through the motions to check if it was something on my end or a random fluke, of course, but it didn't appear to be (other pages worked, their contribs worked, reload/cache flush didn't help, ...).
Well ... resolved, I guess. Thanks.
Amalthea 13:52, 17 September 2009 (UTC)

Custom filter fails on Firefox

// initialize the array - only do this once
extraPopupFilters=[];
 
// define the function
function popupSpeedy(wikiText) {
  var dbTag = /[\s]*\{\{(?:db|speedy ?delet(?:e|ion)|speedy|d|rm|del(?:ete)? ?(?:because)?|csd|nn)(?:-(?:.+?))?(?:\|(?:.+?))?\}\}[\s]*/gi.exec(wikiText);
  if(dbTag != null)
    return dbTag;
  return '';
};
 
// add the function to the array (you can repeat this for lots of functions)
extraPopupFilters.push(popupSpeedy);

Okay, what I have here is a regex that retrieves the speedy deletion tag from a page (if there is one), and displays it on the popup. But for some reason this doesn't work on Firefox 3. It works on IE so it can't be all wrong. Any help would be appreciated. Regards, decltype (talk) 13:34, 17 September 2009 (UTC)

I think "?:" is does not exist in JavaScript. Cacycle (talk) 21:26, 17 September 2009 (UTC)

Its use should be valid within a regex literal. I also believe the conditional operator exists in JS but I could be wrong on that point. decltype (talk) 06:17, 18 September 2009 (UTC)

pg.wiki is undefined

When I visit the page Wikipedia:Tools/Navigation popups I got the following error:

pg.wiki is undefined
http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript&urid=243z2_310977428
Line 6024

and this is the line 6024:

pg.wiki.hostname = location.hostname; // use in preference to location.hostname for flexibility (?)

Does anybody knows what is wrong? Helder (talk) 19:56, 9 November 2009 (UTC)

It works for me. Temporary glitch, maybe?

Also, fwiw, line 6024 appears to be:

pg.wiki.hostname = 'en.wikipedia.org';

Earthsound (talk) 20:12, 9 November 2009 (UTC)

Strange parsing of Tools: interwiki links within popups

At first I thought this might be a problem with a userbox, and I discussed it at the author's page, but now I am thinking it's a problem with popups. If not (and I'm just crazy) feel free to trout me. The root of the problem, as I see it, is that an inter-wiki link with a tools: prefix gets interpreted as an internal en.wp link. To see the problem first hand:

You must have popups enabled (duh)
Go to the userbox here: http://en.wikipedia.org/wiki/User:Jake_Wartenberg/centijimbo
Mouse over the word "centijimbos" inside the blue userbox
When the popup comes up and shows the contents of the centijimbo article go down to the next-to-last line and mouse-over the word "tool".
The interesting thing is that popups then correctly shows the script of the tool - however if you actually click the word "tool" it will take you here as if the tool link was an en.wp article.
However if you click the "tool" link in the actual Wikipedia:Centijimbos article it works fine.

I have cleared my cache and all the page caches and made sure the pages were all updated with no change. Problem happens on IE and Firefox.

Clearly this problem (if it is a problem) is pretty low on the priority list. Just wanted to mention it. 7 04:29, 5 November 2009 (UTC)

It doesn't show the script, it shows part of the HTML source of the "Bad title" MediaWiki page: Just as if you click on the link you posted, http://en.wikipedia.org/wiki/:tools:~mzmcbride/cgi-bin/watcher.py, MediaWiki doesn't properly resolve the interwiki like it would if you placed it in double brackets (tools:~mzmcbride/cgi-bin/watcher.py), but chickens out first. If you point on other interwikis with valid titles, like http://en.wikipedia.org/wiki/:de:Foo, you also get a popup that goes nowhere, albeit without the garbage.
Popups could certainly be more verbose in the feedback it gives with interwikis that leave enwiki, but anything beyond that would either mean more maintainance or more ajax calls in the background. Amalthea 19:38, 8 November 2009 (UTC)

Thanks Amalthea - I should have come to you right off the bat. You've got all the answers. ;) 7 06:29, 9 November 2009 (UTC)

Popups over links to subsections of a talk page

I believe that i may have found a bug. Popups over links to subsections of a talk page like this one Talk:Chronology_of_the_Bible#"Descendents"? only show to the first reply even though mine is set to show 10 sentences or 3000 characters. I'm using firefox 3.5. Lemmiwinks2 (talk) 20:38, 26 November 2009 (UTC)

Popups is not a full preview. It is a small popup with the basic content. It filters out lists (which discussion with indentations basically are), tables etc. As such the first content after your reply that is visible to preview, is the next header. However popups breaks of previews at each (sub)section. —TheDJ (talk • contribs) 20:54, 29 November 2009 (UTC)

popups for bible verses?

How difficult would it be to get a popup over a link like this Bible or genesis 1:1–10 or Genesis 1:1–10 to show only that chapter or better still only the specified verses in that chapter? Lemmiwinks2 (talk) 05:05, 27 November 2009 (UTC)

Bug in CSS

There are some bugs in the CSS files MediaWiki:Gadget-navpop.css and User:Lupin/navpopdev.css, which prevent some icons to appear in some situations. These are the icons: and "Discussionitem icon.gif" (not available as an uploaded file). Those are the icons that MediaWiki inserts after certain kinds of links, just like it inserts the external link icon .

Here's an example of the proper code that first gets loaded from http://en.wikipedia.org/skins-1.5/monobook/main.css. This example just shows the code for one of the icons, the others have the exact same problem:

#bodyContent a.external[href ^="https://"],
.link-https {
	background: url(lock_icon.gif) center right no-repeat;
	padding: 0 16px;
}

/* And further down in the same CSS file. */
.ltr #bodyContent a.external {
	padding-left: 0;
}

Then the navpopup CSS files add this code:

.popupPreview a[href ^="https://"],
.link-https {
	background: url(http://en.wikipedia.org/skins/monobook/lock_icon.gif) center right no-repeat;
	padding-right: 16px;
}

But I think the code should look like this:

.popupPreview a[href ^="https://"],
.popupPreview .link-https {
	background: url(http://en.wikipedia.org/skins-1.5/monobook/lock_icon.gif) center right no-repeat;
	padding-right: 16px;
}

There are two problems in the navpopup code:

1: The URL is pointing to a non-existent image. The URL should not be ".../skins/...", instead it should be ".../skins-1.5/...".

2: The ".popupPreview a[href ^="https://"]" is probably needed to make the icon appear in the navpopup Preview windows. (But currently it probably doesn't since the URL is wrong.) The same goes for the ".link-https" class. But the redeclaration of ".link-https" should be made so it only has effect within the navpopup Preview windows, since when MediaWiki is upgraded to version 1.6, then that URL will probably break again.

Here's an example when it breaks:

1: Some text

2: https://www.test.com

You are supposed to see a padlock after both of the above lines. But when you have navpopups loaded you don't see it in the first line.

I can fix this in the code, but I would like to have it sanity checked by some other user first.

But the code in the navpopup CSS files is not complete, it doesn't add icons for sound files, video files and PDF files. So those files probably don't get any icons in the navpopup preview window. So another option is to simply remove the code. Since those icons are probably not that necessary in the preview window (they haven't even been there because the code is currently broken) and space in the preview window is at a premium so link icons perhaps are a waste of space. But I don't use the navpopup preview, so I'll leave that decision to those of you who use the preview.

--David Göthberg (talk) 08:22, 29 November 2009 (UTC)

I'll fix it. This is just very old css (2004'ish) a lot has changed. I think the best here is to simply remove this CSS for popups. —TheDJ (talk • contribs) 13:36, 29 November 2009 (UTC)

Popups not displaying correctly

As of logging in about 10 minutes ago, popups are displaying incorrectly for me. They display as a long column with no background, making them useless and obscuring whatever text is underneath. Is this perhaps related to the discussion of CSS above? I am using a fairly recent version of Firefox. Delicious carbuncle (talk) 16:12, 29 November 2009 (UTC)

Nevermind, it seems to have fixed itself through no action of mine. Delicious carbuncle (talk) 16:16, 29 November 2009 (UTC)

That is odd, exactly the same thing just happened to me today. I just now bypassed my cache and the issue fixed itself. Camaron · Christopher · talk 17:10, 29 November 2009 (UTC)

Bug: contributions not showing up

A new problem started occurring today. When I hover over "contributions" instead of seeing a user's contribution history I get "History preview failed :-(". This happens with all contribution links. Them From Space 10:27, 11 December 2009 (UTC)

I notice this too. And this doesn't limit to en.wikipedia (is it some MediaWiki update causing this?). --Moonian (talk) 10:35, 11 December 2009 (UTC)

You most often get this when you use the old Popups version that does not yet use the api extension. —TheDJ (talk • contribs) 12:17, 11 December 2009 (UTC)

Old popups version? Would that cause it to work forever and then stop working yesterday? -- Mufka ^(u) ^(t) ^(c) 12:22, 11 December 2009 (UTC)

Hmm, this may be related. —TheDJ (talk • contribs) 12:37, 11 December 2009 (UTC)

It seems that the bug has been fixed now. Thanks to those who have fixed it :) --Moonian (talk) 14:08, 11 December 2009 (UTC)