This page is currently inactive and is retained for historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as the village pump.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
If you followed a link to a specific bug, and you do not find that bug on this page, look in the archives (see archive index below).
How to report a bug, in one easy step!
I
Semi-automatically
To find the bug number, look at the section at the very bottom of this page, and add 1 to it, so that the number increments by one for every section. Then click here, add the bug number and a description of your problem, and save the page.
OR
I
Manually
Edit this page and paste the following text at the bottom of the edit box. To find the bug number, look at the section at the very bottom of the edit box, and add 1 to it, so that the number increments by one for every section.
{{subst:/New
|number=<insert bug number, e.g. 272>
|description=<Replace this text with a description of the bug>
}}
Note that there are several known, longstanding issues with Twinkle; check to see if the bug you are reporting would be a duplicate of one of them before adding the bug report.
There are several longstanding issues Twinkle is known to have, many of which will be fixed during or after Twinkle has been switched to using the API:
Two editors simultaneously reverting the same page may cause corruption. (Bug reports: 13; related: 254)
Twinkle will incorrectly report actions as complete when they have not been completed for some reason. (Bug reports: 36, 274, 279; possibly related: 235, 267) ::::This type of bug should be fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible. — This, that, and the other (talk)07:40, 18 April 2011 (UTC)[reply]
When placing warnings on a talk page, Twinkle will sometimes overwrite previous warnings. (Bug reports: 229, 243, 262, 280)
Several tabs (including di, arv, and xfd) do not close or indicate they've completed after they finish. (Bug reports: 263)
When batch-deleting images, Twinkle will occasionally delete the wrong image. (Bug reports: 270)
There are also a few non-bug issues that can usually be fixed by the user:
If Twinkle does not open a user's talk page after reverting vandalism, it usually means a problem with your configuration, or a popup blocker preventing the new window from being opened. There are also several other actions where Twinkle will try to open a new window for various reasons. (Bug reports: 266)
Certain issues in some browsers are caused by using an older style of Twinkle's configuration. Updating your configuration and bypassing your cache should resolve these problems. (Bug reports: 311)
If you are using the Vector skin, Twinkle must be installed via either your gadget preferences or in your vector.js file. If you recently switched from Monobook or another skin and find that your Twinkle buttons have vanished, be sure to check this. (Bug reports: 320)
Twinkle may load erratically in Safari and Chrome, due to a bug. This can be corrected when it happens by simply reloading the page.
That's a real fishy problem ,sadly I don't know why it happens, possible this kind of problem will go away when the apöi edit thingi is ready. →AzaToth13:36, 15 September 2007 (UTC)[reply]
It's a known problem, sadly I dont know why it happens, the only way for me to find the problem would be a full transcript of data transfered when this happens. →AzaToth13:11, 3 December 2007 (UTC)[reply]
Looks like bug 13 to me. This happens to me when I navigate away from the page, either by accident, or because the form appears stuck. Before leaving, the dialog reads "Error while posting form: error 200" or something similar (I am sure it says 200 as the error code). It seems to be caused if Twinkle is unable to post the whole form, but manages to post some of it. nneonneotalk16:13, 25 April 2008 (UTC)[reply]
The problem is that it's an issue I personally have never encountered. I highly assumes there is a flaw in the JavaScript engine people are using. →AzaToth13:55, 8 May 2008 (UTC)[reply]
I've only encountered it when accidentally navigating off the page before it's completely done -- in that case, the POST doesn't complete, but MediaWiki goes ahead and saves the data anyway, causing the truncated article. I've also got another hypothesis -- if the POST data is GZip encoded (or similar), and a transmission error causes corruption somewhere in the stream (which does happen from time to time!), the result is a malformed stream at some point, which would explain the weird "%3" characters right at the end of the truncated article. For the article you linked to, Silvonen, I've just gone and restored the missing content (a bot went and did the rest). nneonneotalk16:27, 8 May 2008 (UTC)[reply]
I did the revert Silvonen posted above and the damage was fixed by others (big thanks to bot and humans) before I logged in today. Here's what I noticed when TW was going through the motions:
gathering info on versions
dealing with likely redirect
opening talk page to the accused <---right here Netscape's Pop-Up blocker notice appears for me
error 200 (as discussed above)
completed
Now sometimes the article (with changes) appears, but usually it stays on this listing saying it's done, and I either close it or click a link elsewhere on the page. It never sends a message to any user talk, probably due to the pop-up blocker. Could it be related to the blocker combined with my now-defunct old-ass Netscape browser? I'm gonna stop using TW for now for the vandals and look into Firefox and such. Hope this info helps. Kresock (talk) 23:00, 8 May 2008 (UTC)[reply]
I have a suspicion about what might be causing this, or at least how it might be avoided. The normal Wikipedia edit form has the hidden "wpEditToken" field as the very last one — that way, if the submission is somehow truncated, the edit token will be missing and the edit won't get saved. The "wpSave" button is also near the end of the form, providing a similar precaution. If Twinkle is submitting the fields in a different order (as it indeed seems to be doing, based on quick browsing of the code), such that "wpSave" and "wpEditToken" come before the main content in "wpTextbox1", then a truncated submission could result in a broken edit. —Ilmari Karonen (talk) 18:40, 22 May 2008 (UTC)[reply]
I just added a kluge to User:AzaToth/morebits.js that should fix this: it modifies QueryString.create() so that the "wpEditToken" parameter, if present, is always sent last. It doesn't seem there's any higher-level way to fix this, either, at least until the edit API is enabled: QueryString.create() turns an unordered JavaScript associative array into an implicitly ordered HTTP query string, so the sorting of keys pretty much has to happen there. —Ilmari Karonen (talk) 13:04, 25 June 2008 (UTC)[reply]
Darn. Reopened. I have a hunch what may be breaking this time: if the API query used to fetch the version to revert to returns incomplete data, I suspect Twinkle may happily accept the truncated text and revert to it. If this is the case, the solution might be as simple as adding a check to the onload handler in Wikipedia.api.prototype in morebits.js to ensure that the response content actually ends with "</api>". —Ilmari Karonen (talk) 15:08, 19 August 2008 (UTC)[reply]
BTW, Shell, what browser were you using when that happened? My quick Google search suggests that there may be differences between browsers in the behavior of XMLHttpRequest when told to parse malformed XML. —Ilmari Karonen (talk) 15:27, 19 August 2008 (UTC)[reply]
On this same topic - when marking DB-COPYVIO with a blacklisted URL same problem - twinkle returns with no error but the DB tag is not added to the page (I ended up double/triple posting to users talk page). 7talk | Δ |23:25, 3 June 2009 (UTC)[reply]
Has there been any headway into this bug now that "API edit is ready" ? It also applies to db-g12 tags where the copied material is blacklisted. A user made a suggestion to simply nowiki the URL at the template-level, but this seems to throw the baby out with the bathwater (making it more of a PITA for admins to verify the tag). If Twinkle were able to detect the link was blacklisted, perhaps a nowiki=yes parameter can be added. –xenotalk12:21, 25 April 2010 (UTC)[reply]
This bug has been partially fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible. Twinkle now tells you when G12 fails due to spam blacklist, but it probably still notifies the user (??), and the only way to get around the issue is to add the tag manually. — This, that, and the other (talk)08:05, 16 April 2011 (UTC)[reply]
Seems to have something to do with nominating two redirects to the same page, though not always. It worked on more than one occasion with that redirect. Magog the Ogre (talk) 01:29, 22 December 2008 (UTC)[reply]
I can't see anything in the code that would cause Twinkle to overwrite an old RFD nomination, even if the one it overwrites redirects to the same page as the current one. My best guess here is that, for some reason, the server returned the text of the previous version of the page in the edit box...some sort of caching issue. Please let me know if this continues to happen. Ioeth (talkcontribstwinklefriendly) 16:37, 15 January 2009 (UTC)[reply]
I believe that MediaWiki doesn't register edit conflicts one has with oneself. I don't know if this behavior is new, but that explains all instances where people overwrote their own warnings or RfDs. I'm unsure if there's a way for Twinkle to prevent this. Amalthea11:44, 16 June 2009 (UTC)[reply]
Interestingly, I think I've figured out the error: when I loaded a page, and let it sit there for several minutes, it still edit conflicted: [16]. Perhaps loading page content after the submit button is clicked, rather than when the page loads, would help this, and also save time when opening pages. Magog the Ogre (talk) 01:27, 25 September 2009 (UTC)[reply]
Thanks, get back to me ASAP please. Also, this happened twice, number 4 was fixed by a bot.—Preceding unsigned comment added by Cssiitcic (talk • contribs)
Right, number 4 wasn't listed, I was only looking for missing page creations. Did you happen to look at the Twinkle feedback with these nominations? It lists the status of all the tasks it performs, so if one of them didn't report back with the successful edit then it most probably just got lost somewhere, or took unusually long and you navigated somewhere else before it finished? --Amalthea21:48, 12 December 2008 (UTC)[reply]
What's with the hurry? Just pay attention to Twinkle's feedback in the meantime, so you'll notice if it doesn't finish one of the steps and you can do it manually. --Amalthea22:00, 12 December 2008 (UTC)[reply]
But the purpose of Twinkle is to make vandal-fighting easier, if I have to go back and re-do a step Twinkle missed, that misses the whole point of Twinkle.Cssiitcic (talk) 15:46, 13 December 2008 (UTC)[reply]
You should always wait for the confirmations that all tasks have been completed, since it can always happen that one of them fails, and it might actually reduce the problem you are seeing. In any case it can help Ioeth to narrow down the problem. Also, AfD nominations aren't really a part of undoing vandalism, and IMO shouldn't be used in a fire&forget way in the first place. --Amalthea17:59, 13 December 2008 (UTC)[reply]
And, it's happened again, when I nominated TellEm T.V. The Mixtape. In case this is of any help, in both cases, it notified the initial creator, but did nothing else, and it said that the other tasks were completed, even though they weren't. It also seemed to "complete" them a lot more quickly than usual.--Unscented (talk) 23:58, 16 January 2009 (UTC)[reply]
Again it happened! This is so annoying! Can someone please fix this already? If you need to talk to me feel free to post a message on my talkpage. Anything to get this fixed.Cssiitcic (talk) 21:15, 18 January 2009 (UTC)[reply]
This happened again! Can someone please tell me what is causing this? This is getting annoying. It happens EVERY time I try to AfD a page. Please, can you fix it soon. Thanks!Cssiitcic (talk) 20:27, 11 February 2009 (UTC)[reply]
No, not really. You have explained the problem, no need to come here every time it happens. As it stands, this is only happening to you that frequently, so I'm thinking that it might be something on your end. In any case, I recommend you stop using Twinkle for AfD nominations, or at the very least fix the things it didn't do for you manually. You listed the one AfD twice today (1, 2) and you recently notified an editor twice about an AfD listing. --Amalthea21:37, 1 March 2009 (UTC)[reply]
Same thing happened to me when I tried to nominate Isaac Marshall for AFD. It failed the first time and succeeded the second time. The first time, it didn't do anything except for adding the log entry to the deletion log. The second time, everything was created successfully. Only difference between the two attempts is that I've ticked "notify if possible" in the first try, and unticked it in the second one. Laurent (talk) 08:42, 9 April 2009 (UTC)[reply]
I had this happen when trying to list files on PUI (subpages where not created), in my case the problem was that I had Opera set to "block unwanted popups" (default), once I set it to allow "all popups" from wikipedia.org it worked just fine. Try whitelisting Wikipedia in any popup blocker/safe surf/web security type features or applications you might be running and see if that helps. --Sherool(talk)21:58, 9 September 2009 (UTC)[reply]
Just like to note that User:Cssiitcic isn't the only one to experience this bug. When I nominated Radon therapy for AfD, the nom page and the template both worked, but the log entry and the notification failed silently (i.e. TW told me it finished them but it never did). Time was right about now (see my signature). --Thinboy00 @114, i.e. 01:44, 22 September 2009 (UTC)[reply]
Regularly, but at random, Twinkle will go thru some or usually all of the stages of listing an AfD, but miss adding it to the daily log. It appears to confirm that it carried out all the actions. I now always check for transclusion to the log, because it does it so often, but it would be interesting to know how often DumbBot is adding a stage 3 to a process that started in Twinkle. This might give an idea as to whether the problem is confined to a small group of users or scattered randomley through all users. Elen of the Roads (talk) 12:45, 20 January 2010 (UTC)[reply]
It happened to me today here, and I think I see a pattern: A few days earlier I had removed the article's AfD notice (here, using Twinkle) and its entry in the daily log (here, done manually) after an incomplete, manual attempt by another user.
Now I just thought, if Twinkle for some reason parses the wrong version of the article - see the history of List of schools in the Philippines - or double checks whether the article had an AfD template before, that might be a reason for the bug to occur. Radon therapy mentioned above also had previous AfD nominations, maybe an admin can look into the history of the deleted example above. --Pgallert (talk) 09:47, 8 March 2010 (UTC)[reply]
I believe that when CSDing redirects, Twinkle notifies the editor that created the redirect (i.e. moved the article to a new pagename). There is no way for Twinkle to automatically determine if someone tagging a redirect intended to tag it, or the article it redirects to (unless you want to get into assumptions based on the redirect's creation date relative to when the tagging is done, which can get pretty sticky). Twinke acted exactly as it was supposed to here, and no one's going to bop you for accidentally tagging a single redirect almost immediately after its creation when you intended to tag the article. ;) --Dinoguy1000 as 66.116.12.126 (talk) 19:20, 16 February 2009 (UTC)[reply]
Well, there is an easy way to check whether an article has changed since the tagger was looking at it, and judging it. Twinkle knows the revision id of the page when the CSD tagging was triggered, it can compare it with the current revision id of the page. If it changed, it could be a reasonable safeguard to ask the user if he really wants to tag it, probably by showing him the diff between the version he looked at, and the current revision, with a dynamic "Proceed tagging with db-XX" javascript link which will try again. I'm unsure if this is necessary however. I don't know how often that will happen; it would prevent two editors both tagging it at around the same time, it will make sure you tag the version you want to tag and not one where somebody might already have adressed the concerns. I don't think it would be much of a bother for editors, if it shows diffs then it will usually be quick to determine whether the tag is still warranted, so a second conflict will be unlikely. --Amalthea02:10, 17 February 2009 (UTC)[reply]
Twinkle (and probably Friendly) should be updated to use the API, instead of going back and forth between using it and using the edit screen - this would resolve TW-B-0250 even without devs fixing the underlying issue, and would prevent stuff like TW-B-0255 from happening. I know you guys already know this needs done, but figured a bug report would provide you a centralized location for discussion and updates (and maybe poke you into getting it done a bit faster). =) 「ダイノガイ千？！」(Dinoguy1000)21:29, 18 February 2009 (UTC)[reply]
It's a bit embarrasing, but I was the one pushing roan for edit api, but at the time it went live, my free time went to minus zero :( →AzaToth15:01, 19 February 2009 (UTC)[reply]
I can help if I am asked nicely. My time is next to zero too, but I want to do something real API related, and if it is a matter of converting code, I am available...--Cerejota (talk) 01:49, 15 March 2009 (UTC)[reply]
This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)08:05, 16 April 2011 (UTC)[reply]
TW-B-261 (acknowleged)
Status: Acknowledged
Resolution: none
As mentioned in TW-B-0260, clicking a radio button automatically submits a CSD request. This is nonstandard behavior for a radio button and causes improper tagging due to expecting standard behavior or simple mouseos. Request either using a standard select/submit form or changing the type of form element. chrylis (talk) 07:49, 23 February 2009 (UTC)[reply]
When I use the di tab the window does not close or reload or anything. It just finishes and stays open. It has never done anything but this. I assume this is a bug and not a feature request because every other tab has always refreshed or redirected when it was done. ▫ JohnnyMrNinja18:15, 13 March 2009 (UTC)[reply]
There's probably more, TfD noms for example. From a glance I don't know why though, everything seems to be set up correctly. Needs debugging. --Amalthea21:44, 14 March 2009 (UTC)[reply]
TW-B-279 (acknowledged)
Status: Acknowledged
Resolution: Dupe (pick yer bug report above (and in the archives))
Couple of problems with batch deletion: first of all, the tool does not delete all selected articles, yet reports that all have been deleted. Secondly, when using "unlink backlinks", the tool actually recreates a deleted article in order to do this, if they are in the same batch. The articles report in Special:log/delete as deleted, so they are definitely recreated by TW. – Toon(talk) 15:48, 15 April 2009 (UTC) --– Toon(talk)15:48, 15 April 2009 (UTC)[reply]
This is a known issue of Twinkle not reporting errors correctly (if at all), and has been reported multiple times in the past. I think we're mostly just waiting for someone to switch Twinkle over to using the API to fix this and several other known, long-standing issues. 「ダイノガイ千？！」(Dinoguy1000)19:30, 15 April 2009 (UTC)[reply]
(moved from a separate section up here) Amalthea21:04, 24 May 2009 (UTC)[reply] I saw this bug above, but I'm not sure if you guys are following. It's not that batch delete (I only do it on non-files) occasionally has errors and doesn't report them correctly; the problem is that it only deletes roughly half of the requested pages, every time, and reports that it's done all of them. Waiting longer after the notification doesn't seem to help. I seem to recall that I never had this problem with batch delete in March. - Dank (push to talk) 20:44, 24 May 2009 (UTC)[reply]
I agree, and it's really annoying. I can only guess at why this is happening now, and didn't before. I was playing a little with the rates of deletion, batch sizes, delays between deletions, but that didn't really bear fruit. I'm afraid that this needs a more fundamental rewrite. I've started working on the SD-downgrade-to-PROD tool for you, and am doing some groundwork there. Once it is done I will try and look at some of the most broken Twinkle tools, and rebuild them more robustly, with (gasp) error checking. If I had more time for concentrated work on these things, all of it would happen faster, but alas ... Amalthea21:04, 24 May 2009 (UTC)[reply]
Yeah ... it just inserts a new caption. To fix that I'll have to look at how MediaWiki recognizes image parameters, to figure out which is the actual comment (the last unrecognized parameter). Looking at User:AzaToth/morebits.js' addToImageComment that's a can of worms, I notice that code wasn't update to accept the File namespace (still only looks for "[[Image:"), and it also won't recognize stuff like e.g. "[[ Image:". Amalthea11:27, 27 April 2009 (UTC)[reply]
On the grounds that I currently have a BRFA open to tag any images listed at PUI that aren't tagged, you could disable it and let my bot do the tagging if it would be easier than fixing Twinkle... [[Sam Korn]](smoddy)11:54, 27 April 2009 (UTC)[reply]
Ah, nice. I'll keep the BRFA watchlisted so if it's approved I'll probably do just that. Fixing just that problem would probably not be a huge deal (just tweaking the regex and parsing the parameters), especially now that I see your code and don't need to think much about it. :) But I think it makes more sense to standardize it, and let the bot do it everywhere. Cheers, Amalthea12:44, 27 April 2009 (UTC)[reply]
OK, turned it off for now. "For now" since I'll still have to fix the problem, there are other reasons for tagging an image, standard IfD mostly. I'll leave this bug open because of this. If it's working correctly again I might reenable automatic tagging via Twinkle. Thanks, Amalthea11:19, 2 May 2009 (UTC)[reply]
For what it's worth, Quadell asked me to extend the bot to cover FFD and various speedy-deletion categories as well, so those probably aren't urgent. [[Sam Korn]](smoddy)11:12, 3 May 2009 (UTC)[reply]
For the record, Twinkle tagging image usages has been disabled here, here, and here. Still hoping to fix the functionality, but time is sparse, and Sambot is supposedly doing it anyway. Amalthea19:49, 13 October 2009 (UTC)[reply]
Rollbacks on Chrome normally work though, right? It got a result from the API it didn't like, but since Twinkle is parsing API results with xpath it might still be related to Chrome. Amalthea21:09, 24 May 2009 (UTC)[reply]
Not really sure; I don't use Chrome nearly enough to be able to tell you. I do remember performing some other actions; most of them worked fine, but I think there were a couple others that Chrome choked on as well. ···「ダイノガイ千？！」?Talk to Dinoguy100010:03, 25 May 2009 (UTC)[reply]
Is this persisting, BTW? I'm a bit surprised that nobody else has reported this problem, I'd think that other people are using Chrome as well. I don't really want to install Chrome if I don't have to (Google=evil), can you please check if this is still happening? Amalthea21:36, 4 July 2009 (UTC)[reply]
Off and on. It's pretty rare, and I typically just ignore it when it does happen (although a short while ago, I tried to revert a couple of edits and warn a user with Twinkle on the Vector skin; the edits all went through, but TW's windows never updated to reflect this). Also, why does Google=evil? MS is far more worthy of your loathe-time IMHO... =D (and one last point, hyperactive much? XD ) 「ダイノガイ千？！」? · Talk⇒Dinoguy100022:01, 4 July 2009 (UTC)[reply]
Hmm. Guess I'll have a look at Chromium then, sooner or later. :) And MS – not so when it comes to gathering arbitrary information I don't necessarily want to offer. I sure as hell won't install any Google products where I have even less control over what they grab. No, neither hyperactive nor on stimulants, I was just dismayed by the number of requests and bugs that kept adding up, the new vector skin that needed attention, and then AzaToth baited me with a barnstar, it all got too much to ignore. ;) But that's probably been it for the next month or so. :) Amalthea22:48, 4 July 2009 (UTC)[reply]
TW-B-306 (acknowledged)
Status: Acknowledged
Resolution: none
Apologies if this has been reported before. I have just nominated an article for deletion, but Twinkle didn't complete the process. It didn't add the AfD to the current discussion page and it didn't add the category - I had to complete these manually. I am using Opera 9.64 on XP and I have the Javascript Standard Library enabled. Bettia(bring on the trumpets!)10:20, 15 July 2009 (UTC)[reply]
Again, adding the category like here or here is not necessary since the template you're adding it to, {{AfDM}}, does not evaluate it. Twinkle did add the categories to the discussion pages, which categorized them e.g. in Category:AfD debates (Media and music). It's very very weird that it gave you that error message though, since people added AfDs via Twinkle just fine, both before and after you, and with a glance (and when I just tested it) I don't see a problem. Do you remember whether you got the same error message with your first AfD, or if that one just didn't finish, or claimed it did but didn't? Amalthea12:07, 15 July 2009 (UTC)[reply]
Yes, I did get that error message with the first AfD. Also, before I added the cat=M parameter, the AfD notice listed a number of instructions indicating that the process was incomplete. Like TheDJ has stated below, this probably is an Opera issue. Bettia(bring on the trumpets!)14:29, 15 July 2009 (UTC)[reply]
From what I can tell it actually was orphaned when it was tagged. I'm also not sure what you mean by "when scanning the CSD category"? When does Twinkle do that? As a matter of fact, it also doesn't check whether an image is really orphaned when people attempt tagging it, and I'm not sure it's really necessary anyway. Amalthea07:41, 23 July 2009 (UTC)[reply]
When I use deli-batch on an image category of CAT:CSD, I noticed that is unchecks some of the entries as "Disputed", which I assumed involved TW looking at the image description page to see subsequent changes since tagging. MBisanztalk18:27, 23 July 2009 (UTC)[reply]
Ah, I see, I didn't notice that it was deleted & restored. Image batch deletion doesn't know about the di-tags, or the CSD criteria. Pretty much the only thing it does is checking for Category:Contested candidates for speedy deletion on the page. What we could do is listing the number of images uses after every item, but doing that properly would need some rewriting. Amalthea19:19, 23 July 2009 (UTC)[reply]
Twinkle Unlink doesn't seem to be working on CSDs or batch image deletions (haven't seen much use for it outside of those, so haven't tested). The box is checked and I've changed very few Twinkle settings (see User:Drilnoth/vector.js). Using Vector skin, although that should now be more or less completely compatible, on FireFox 3.something. --–Drilnoth (T • C • L) 02:11, 2 August 2009 (UTC)[reply]
Sorry for getting back so late. It should work, but I haven't tested it in a while. Do you remember the circumstances of the unlinking? There are a couple of caveats, for example it only unlinks in Main and Portal space, and not with G6 deletions. Cheers, Amalthea12:26, 9 September 2009 (UTC)[reply]
The "Since" button does not seem to be functioning properly. I assume that after clicking "since" the previous diff is supposed to be the last edit made by another user. Instead, both diffs are the same user. For example, the result I get after clicking "since" on Fred Durst is this. ---shirulashem(talk)12:38, 21 August 2009 (UTC)[reply]
What it does is take the user who is at the right side of the currently displayed diff, find the latest edit he made (excluding the current revision), and show the diff from that latest edit to the current revision. I can't really say when one might be interested in that. It might be useful if you trust one specific editor, and are only interested in what happened since he last edited. It's possible that some underlying API call or provided ID now behaves differently than it used to, and the intended functionality is something different. Only AzaToth could say that, the tooltip he added to it is "Show difference between last diff and the revision made by previous user". What do you want it to do? I don't quite understand what you mean by "the last edit made by another user". The "Current" tab is showing you the diff between the currently shown diff and the current revision of the page, that's the only one I'm using myself. :) Amalthea13:53, 21 August 2009 (UTC)[reply]
I've never had much use for these tabs myself, beyond a bit of curiosity in regards to "since mine", but I usually just go through the history page to see that (I had actually forgotten these tabs were there until I saw this bug report). Personally, I can't quite wrap my head around what the difference between "last", "since", and "current" is actually supposed to be. 「ダイノガイ千？！」? · Talk⇒Dinoguy100018:51, 21 August 2009 (UTC)[reply]
"Last" always shows the very last diff of an article. "Current" only appears on diffs, and shows the change from the diff you see to the most current revision. This is particularly useful if you try to follow a fast-moving discussion, like a noticeboard or an article about a current event, and don't want to miss any changes: Leave the diff open, press the "Current" link from time, and you the combined diff of all changes since the last time you checked. Invaluable, to me, since in those cases trying to follow changes diff by diff takes too much time and/or clogs my watchlist. Amalthea19:46, 21 August 2009 (UTC)[reply]
As Amalthea points out, the tooltip says "... between last diff and the revision made by previous user." I interpret the last diff as the most recent revision (on the right side of the page), and the last revision made by the user before the user who made the most recent revision (on the left side). Otherwise, what is "previous" user? In practice, this would better enable you to see all the edits of the latest user. 99% of the time, when I look at a diff, I want to see all of that user's consecutive edits. How often do we click "diff", realize that it was the same user who made the latest diff and the one right before that, so then we click "Previous edit", and that edit, too, is the same editor, so then we go to the article's revision history and choose the article's latest version and the version right before that user so we can see all of what the user did. -shirulashem(talk)15:43, 16 September 2009 (UTC)[reply]
As a perfect example, I see on my watchlist that an edit was made to Peter Schiff by a user without a userpage or talkpage, so I'm naturally mildly suspicious. So I click on the diff to see what revisions the user made, and both revisions are by the same user. Then I click "previous edit" and again, sure enough, it's the same editor on both revisions. Then I have to go to the page history and find the last time the page was edited by a different user, and compare revisions. :) -shirulashem(talk)13:18, 17 September 2009 (UTC)[reply]
TW-B-325 (acknowledged)
Status: Acknowledged
Resolution: none
I am using TW on OS X 10.6.1 with Firefox 3.5.3. This issue has persisted through many incarnations of the OS and Firefox. Often time I will attempt to bring up a TW menu from the "CSD", "RPP" or ARV" buttons. When the menu comes up the formatting is really skewed. I am unable to scroll up or down on the menu and unable to close the menu. I am happy to take a screenshot and upload, if necessary. Does this ring a bell? Might it be related to AdBlock? This is not the case every time- it does often work, but other times it simply doesn't. Basket of Puppies15:00, 15 September 2009 (UTC)[reply]
I see. Have you intentionally zoomed in there? The positioning code for the window has apparently a bug, you can avoid it though if you reduce the zoom level before opening a twinkle window (Menu – View – Zoom – Normal should restore the normal zoom level). Amalthea15:34, 15 September 2009 (UTC)[reply]
Yes, I intentionally zoom in as my eyes aren't what they used to be. I'll try it out by making the zoom normal and see if this persists. Is there any way to keep the zooming and have TW render properly? Basket of Puppies15:57, 15 September 2009 (UTC)[reply]
If anything, I broke it, but it works for me?! Can one of you have a look into your javascript console and look for any Twinkle related error messages? Amalthea21:15, 15 September 2009 (UTC)[reply]
Hmm, thanks. I've reverted my change for now, so after another cache bypass it should be back to how it was. I'll have to investigate why that went wrong for you. Worked fine for me, as I said. Amalthea22:34, 15 September 2009 (UTC)[reply]
Just another data point, hope to be of help. I happen to be running both Opera 9 and Opera 10 (on different PCs), and I notice that in Opera 9, Twinkle works just fine, but in Opera 10, clicking "warn" on a user talk page brings up a popup menu that has a scrollbar but cannot be scrolled. Trying to drag the scrollbar flashes to the second half of the popup momentarily but it immediately reverts back to the top, making it impossible to click the "submit" button. It may be a browser bug, I'm not sure, but I hope this helps people locate the problem.—Tetracube (talk) 04:08, 21 October 2009 (UTC)[reply]
I have the same problem. I found a "workaround", you can press your TAB key until an item the TW popup is highlighted, and then move around the popup with either TAB or your Arrow Keys. But it is impossible to scroll down otherwise... > RUL3R>trolling>vandalism08:50, 7 January 2010 (UTC)[reply]
TW-B-339
Status: Resolved
Resolution: Won't fix
When using the XfD module, the "Select wanted type of category:" would only have effect on the stuffs below when I "click" on an item. But if I use the "up" and "down" arrow keys to move the selection, it stopped working.--Jimmy Xu (talk) 09:37, 8 November 2009 (UTC)[reply]
Yes, at least I also found that in "rpp" (when selecting "temporany" from the "Expiration:" drop-down by arrow keys, the "Iconify" is not affected). This also happens on some other morebits.js based user-scripts, such as Friendly and some scripts on zhwiki. Seems selecting by arrow keys would not raise the required event like "mousedown" or something? (Btw, sorry for the late response.)--Jimmy Xu (talk) 16:07, 13 November 2009 (UTC)[reply]
Well, once the dropdown loses focus, the "change" event will actually fire and you should see the result. Could probably be workarounded by also listening to the keypress event, but that would require some work to prevent executing it twice. I don't think that's worth the bother. Amalthea15:45, 28 September 2010 (UTC)[reply]
I just protected the Morse code article which was previously unprotected for editing but had move protection move=sysop set. Twinkle changed the move protection to move=autoconfirmed without being asked. There does not seem to be any way of preventing Twinkle from doing this on the pop-up window as far as I can see. SpinningSpark14:24, 18 December 2009 (UTC)[reply]
Issue is that the Twinkle protection settings underlying the offered options are set with no regard to current protection. I'm not yet sure how potential conflicts can be resolved algorithmically. Amalthea18:30, 17 May 2010 (UTC)[reply]
Ideally, Twinkle should read the current settings and use them as defaults unless modified by the user. But failing that, the pop-up should at least allow the user the opportunity to set move protection so that if you know what the move protection used to be, you can reset it manually. SpinningSpark21:14, 19 May 2010 (UTC)[reply]
Experiencing the same issue here; browser is Opera 10.10 (build 4742; “Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.2.15 Version/10.10”). Sebastian…talk07:18, 19 January 2010 (UTC)[reply]
This is not TW-B-325 for me in so far as formatting looks fine, more or less; the only thing that looks strange is a small purple shadow below the scroll down button. But when I close the popup, the mouse cursor stays in its most recent shape, i.e., it doesn't change anymore when hovering over hyperlinks or text input fields in this tab until I refresh the page – all other tabs work fine, though. Sebastian…talk09:07, 19 January 2010 (UTC)[reply]
I am now using Safari. I see that the pop-up can be dragged around the screen. Opera also can't drag it. This is of course not a big functionality issue, but it might help developers diagnose. =) > RUL3R>trolling>vandalism09:51, 19 January 2010 (UTC)[reply]
Twinkle still tags a page for speedy deletion after it was just deleted, causing the page to be recreated without content and the tagger as the author.AppuruPan (talk) 17:14, 27 February 2010 (UTC)[reply]
I have experienced this in the past. It is a bit annoying, to say the least. A quick test suggests that this only happens if the page is deleted during the actual tagging process. Twinkle checks before launching into the process. — This, that, and the other (talk)06:54, 28 February 2010 (UTC)[reply]
This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)08:05, 16 April 2011 (UTC)[reply]
TW-B-361 (acknowledged)
Status: Acknowledged
Resolution: none
When Twinkle is tagging a page that already has a Article issues tag on it, it does not group the parameters into the one template, instead, it places a new template, such as here. I then cleaned up twinkle's mess. Hamtechperson18:07, 19 March 2010 (UTC)[reply]
Speedy delete for unused fair-use image does not include the date automatically, and as the deletion process takes seven days, the images do not get filed properly (diff). ▫ JohnnyMrNinja18:45, 10 April 2010 (UTC)[reply]
Hmm, yes, all immediate image SD templates that had a delayed counterpart were deleted and redirected, such as {{db-unfree}}. You should by default use the "di" tab, and I'll try to make Twinkle behave properly (or just remove the delayed options from the csd tab). Amalthea09:08, 13 April 2010 (UTC)[reply]
This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) Specifically, the delayed CSD options have been removed from CSD, and replaced with text suggesting that the user uses DI instead. — This, that, and the other (talk)08:05, 16 April 2011 (UTC)[reply]
TW-B-368 (acknowledged)
Status: Acknowledged
Resolution: none
Twinkle appears to use a the users computer date/time for the section heading (if a new one is needed) and uses the system date time for signatures. See this discussion and example. If possible Twinkle should use the system date/time for the section heading. 702:46, 14 April 2010 (UTC)[reply]
Right. Hard to properly solve without an additional server query to get the current date/time. We could use magic words to write the section name into the page, but not when comparing existing sections to find the one for the current month. Amalthea09:20, 15 April 2010 (UTC)[reply]
Hmmm... doesn't TW do a pre-query to see if the user has been recently been warned within the last [x] minutes? Is there no time parameter visible at that time? 703:42, 16 April 2010 (UTC)[reply]
Well, that test is done with an equally incorrect time. :) Most folks automatically synchronize their clocks these days with some time server, so it's hardly ever an issue. Amalthea17:43, 20 April 2010 (UTC)[reply]
It has happened to me many times; usually I spot it and correct it - but it does make me look like an idiot, as I "warn" people from e.g. January 1980. I have to set my system date, in order to use old software. Example, [18]. Chzz ► 10:39, 27 March 2011 (UTC)[reply]
TW-B-370 (pending)
Status: Pending
Resolution: Fixed
Twinkle should be able to determine if a file exists on Commons or not. Several times, a bot closed FFD discussions as "Wrong forum, please nominate on Commons". See for example this page (there are more on this page), as you can see in the history Twinkle added these discussions. These aren't exceptions, as you can see in this search result. As these nominations clutter the log pages unnecessarily, send the uploaders pointless warnings and often create files pages to be deleted later anyway, one of the following options would be best to do: Either check if the file exists on Commons and if so, throw an error message telling the user to nominate it at Commons. The other option would be to nominate the file directly at Commons (the process there is similar to the AFD process here, as this is the mainspace there). I'd definitely prefer option #1, as often the reasons for file deletion here don't apply on Commons, but option #2 would probably be the more user-friendly one. Thanks for taking care of this problem. If my explanatation is too bad or there are any questions left, feel free to ask. --The Evil IP address (talk) 17:21, 19 April 2010 (UTC)[reply]
There are actually six cases:
Local file with local page → allow XfD, Puf, di, db
Shared file with local page → allow general db criteria (and possibly redirect db criteria)
No file with local page → allow general db criteria (and possibly redirect db criteria)
Local file with no local page → allow XfD, Puf, di, db
Actually, this still isn't working properly. I fixed it in the github tree as follows:
Local file local page → CSD XFD DI RPP Last Unlink
Shared file local page → CSD RPP Last Unlink (CSD F2 applies)
No file local page → CSD RPP Last Unlink (CSD G2/G6 apply)
Redirect local page → CSD XFD RPP Last Unlink (RFD applies)
Local file no local page → This case seems to be impossible, per IRC discussions.
Shared file no local page → RPP Unlink
No file no local page → RPP Unlink
Not a heavy problem, as a bot changes it back anyway, but the headings at MfD changed, see this bot edit. Twinkle currently uses ===[[year-month-day]]===, whereas the bot uses {{#formatdate:year-month-day}}{{anchor|year-month-day|monthname day, year|day monthname year|year monthname day}}. --The Evil IP address (talk) 18:07, 12 May 2010 (UTC)[reply]
Reporting users to AVI fails for me almost every time. Chrome, Windows. Sometimes things just hang, and sometimes it tells me AVI was complete but I have no edit on that page. — Timneu22 ·talk12:49, 17 May 2010 (UTC)[reply]
Do you happen to have any error messages in your javascript log (In Firefox, Ctrl+Shift+J, click on Error, latest errors are at the bottom)? I've just made a test report that worked without issue, so it's not entirely broken. Amalthea13:06, 17 May 2010 (UTC)[reply]
I still have this problem. I'd say ARV works about 20% of the time for me. Perhaps if there is a conflict, and that's the problem, the UI could say "edit conflict, trying again..." or something? I don't see anything in the logs still. — Timneu22 ·talk13:48, 18 May 2010 (UTC)[reply]
The bug just happened two more times. No logging helped, but I noticed that the vandal page had no other entries on it. Could there be some bug where it fails if it is the first entry on that page? — Timneu22 ·talk12:15, 20 May 2010 (UTC)[reply]
Well I don't know what to say. This still fails for me quite frequently. TW will show "complete", but my edit was not posted. To be sure it's not something else, I can also see that my contributions do not include an edit on the page. I'm using Chrome; think that matters? — Timneu22 ·talk12:57, 22 June 2010 (UTC)[reply]
TW-B-378
Status: Resolved
Resolution: Works for me
Open the "xfd" box for a category. In the "Choose type of action wanted:" select "Renaming", and type the new category name, without the Category: prefix, in the "Target page:" box. Type in a reason, and clock "Submit". The result can be seen her and here - the target name doesn't show up in the discussion or in the tag at the top of the category page. עוד מישהוOd Mishehu06:46, 1 June 2010 (UTC)[reply]
Works for me (I'm using the development/testing version of Twinkle, but I don't think the CFD renaming process was changed in the redevelopment). If you are still having this issue, don't hesitate to reopen this bug. — This, that, and the other (talk)07:18, 18 April 2011 (UTC)[reply]
TW-B-379 (new)
Status: New:
Resolution: none
When you click on "restore this version" on the history page, if someone has changed it in the meantime, it will overwrite them. This has led me to revert an already reverted article more than once. Could it check first and warn you? 930913(Congratulate/Complaints) 07:23, 8 June 2010 (UTC)[reply]
The xfd function doesn't reliably work. Often, it will only actually update the AfD log, but it won't create the AfD discussion page, it won't put the AfD template at the top of the article, and it won't warn the author. This happens quite often, despite the status screen showing that all edits were successfully made, and despite waiting for the script to automatically direct me to the discussion page (which doesn't exist). Also, just recently I was creating a bunch of RfD's for different redirects, and I was using the same rationale for each RfD. The first one worked perfectly, but the second one overwrote the first one, the third one overwrote the second one, etc. So, had I continued with all 6 or 7 RfD's, only the last one would have showed up on WP:RFD. I'm using Google Chrome 5.0.375.86 on Windows 7. SnottyWongyak17:37, 30 June 2010 (UTC)[reply]
You're right, thanks. And the first problem is very sporadic. In fact, I don't think it's happened since I made this bug report. Perhaps an update was made that fixed it. SnottyWongtalk14:29, 5 July 2010 (UTC)[reply]
I receive notification that there are pending changes on my watchlist and view the diff linked above. While the diff screen is open, I read the reviewing guideline.
Andyjsmith undoes 121.54.32.22's edits (diff), then subsequently makes a constructive edit (diff).
Unaware of Andyjsmith's edits, I decide to undo 121.54.32.22's edits using Twinkle's "restore this version" function (diff), thus inadvertantly undoing Andyjsmith's edits. I should have received notification of an edit conflict at this point.
This being my first experience with pending changes, I decided to review the page's history. Had I not done so, I would never have known I'd undone a constructive edit. Adrian J. Hunter(talk•contribs)14:14, 28 July 2010 (UTC)[reply]
Heh, funny that nobody mentioned that before. Twinkle searches whether a month section exists, but doesn't care whether it's actually the last section on the page – it just assumes. Amalthea14:50, 28 September 2010 (UTC)[reply]
<I've just initiated Twinkle, and I am having problems in which everytime I try to make an edit, "Reverting page: couldn't grab element "editform", aborting, this could indicate failed response from the server." appears. I am using a compatiable server and have tried shutting down all the gadgets and re-doing but it doesn't work. Candyo3222:59, 22 September 2010 (UTC)>[reply]
Which web browser are you using? Firefox or Internet Explorer, etc? Also, try clearing your web browser cache and cookies, restart your browser, re-log in, and try again. Does it work now? Also, remember that this page is for reporting Twinkle-related issues, not issues related to your browser. In this case, I am not experiencing your issue. I think I'm going to mark this as closed and invalid. HeyMid (contributions) 11:57, 26 September 2010 (UTC)[reply]
This bug is no longer relevant, given the improvements being made to Twinkle which will be rolled out on-wiki as soon as possible (i.e. within the next month...) Specifically, the edit API is now used; it is impossible for the "editform" error to occur with the edit API. — This, that, and the other (talk)07:59, 16 April 2011 (UTC)[reply]
TW-B-408 (pending)
Status: Resolved
Resolution:Pending completion of update
When AfDing an article creating by a user whose usertalk page is protected, the program never closes out the status screen and never directs to the discussion page. I assume this would happen with other types of Twinkle tasks as well. D O N D E groovilyTalk to me02:46, 30 September 2010 (UTC)[reply]
Yes. Unfortunately Twinkle doesn't cope well with unexpected errors, but I'm afraid there's little we can do absent a complete rewrite. T. Canens (talk) 11:43, 19 October 2010 (UTC)[reply]
Well, against all the odds, that's exactly what's happened. This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)08:05, 16 April 2011 (UTC)[reply]
TW-B-409 (pending)
Status: Resolved
Resolution:Pending completion of update
When MfDing a userfied article in userspace, Twinkle notifies only the original creator of the article, not the owner of the userspace. For example if Gigs created GigsCo which was then moved to User:RescueGuy/GigsCo, RescueGuy won't be notified if someone nominates it for deletion. I'm not sure if this is a bug or more a feature request. Ideally it would notify both people. Gigs (talk) 01:32, 7 October 2010 (UTC)[reply]
This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)08:03, 16 April 2011 (UTC)[reply]
Alright, I'm using both Firefox and Chrome for Ubuntu, and I'm running into an interesting issue on a script which relies on Twinkle. I don't know if it's your fault or AWeenieMan's fault, but Chrome is getting stuck on something that FF isn't.
PS. I've tried it on Windows and it fails there too. It can be reproduced by installing FURME, going to File:Harry Bemis.jpg and clicking tag -> and choosing any of the options below (i.e., the ones not in the dropdown), and clicking submit. Magog the Ogre (talk) 23:01, 29 October 2010 (UTC)[reply]
TW-B-415 (new)
Status: New:
Resolution: none
Not sure if this falls under "bug" or "feature request" but I thought I'd start here. Adding sticky/BLP prod to an unpatrolled new page that shows the [Mark page as patrolled] link in the corner does not mark the page as patrolled as it does when adding CSD tag. Not sure if this issue comes up with regular prod. —KuyaBriBriTalk14:57, 5 November 2010 (UTC)[reply]
TW-B-416 (pending)
Status: Resolved
Resolution:Pending completion of update
When nominating David Hightower Smith for deletion, Twinkle added the AfD discussion to the log, and notified the page creator, but it didn't add a template to the page nor create the actual discussion. I didn't leave the page of click anything whilst it was processing. Other than that, I have had no problems. Thanks. —HalfPrice20:59, 7 November 2010 (UTC)[reply]
The same bug (minus the non-creation of the AfD discussion, this task was executed as planned) appeared for me - I had to tag two articles as being listed for deletion by hand. Just like Half Price, I did not leave any pages during the entire process. --Soccer-holicI hear voices in my head...10:40, 4 December 2010 (UTC)[reply]
This bug has been fixed (...well, we hope) as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)08:05, 16 April 2011 (UTC)[reply]
TW-B-418
Status: Resolved
Resolution:Resolved
the Twinkle popup box for {{uw-csd}} (speedy deletion declined, doesn't match the template. The template requires that you enter the category of speedy you are declining, and give a reason, the popup does not ask for the category, and does not put the reason in the right place, so you get this effect
Just looked at the code. The only way I see is to add an ugly hack. (uw-csd, for better or worse, is the outlier in the user warning templates...) T. Canens (talk) 02:05, 13 November 2010 (UTC)[reply]
Okay, I fixed some issues in uw-csd so that it would output something that is at least somewhat sensible when the 2nd and 3rd params are not used. There will be no more ugly {{{}}}'s in the output when you use Twinkle. The problem is that other uw- templates take one single parameter for the page whereas uw-csd takes three. T. Canens (talk) 02:16, 13 November 2010 (UTC)[reply]
Hi Tim, thanks so much for working on this. I thought the three parameter thing might be a problem - I think whoever came up with the template overcomplicated it a bit, in an effort to cut down on the amount of manual input. The new text is fine - users can add a detailed explanation all in one place if they want. However, at the moment, if I test it I get this, so I think there's something still wants a tweak...? --Elen of the Roads (talk) 19:20, 13 November 2010 (UTC) Realised it was just a missing <noinclude> tag, so I've fixed it myself.[reply]
TW-B-420 (pending)
Status: Resolved
Resolution:Pending completion of update
When using any function, the close button has gone from the pop up box, therefore if you decide to abort a procedure for any reason there is no way out except to navigate away from the page you are on. NtheP (talk) 16:43, 19 November 2010 (UTC)[reply]
This might be due to the fact that the browser fails to load the red X image from the upload server. I'll see if I can fix this to use alternate text, so if the image fails to load for some reason, a letter X or something will appear that can be clicked instead. — This, that, and the other (talk)07:19, 25 February 2011 (UTC)[reply]
This will be fixed soon. If the red X image fails to load, the text "[close]" will appear, which can still be clicked. (It may be a while before the change is applied.) — This, that, and the other (talk)00:43, 13 March 2011 (UTC)[reply]
This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)08:05, 16 April 2011 (UTC)[reply]
TW-B-426 (pending)
Status: Resolved
Resolution:Pending completion of update
Twinkle inherited Friendly's cleanup tagging script (User:Ioeth/friendlytag.js). One feature of this script is that certain cleanup tags have subcategories of tags to help with greater specificity. For instance, the {{Notability}} tag allows you to specify the category that the article falls into, and the {{Globalize}} tag allows you to select which region the article is focusing on, etc. The way the script is coded, however, ignores these specific tags whenever they are grouped into {{multiple issues}}. For instance, if you tag an article with {{Notability|Academics}}, {{Globalize|Belgium}}, {{Unreferenced}}, and {{Wikify}}, the script will (appropriately) group them into {{multiple issues}}, but you will lose the "academics" and "belgium" specificity and just get a generic notability and globalization message. Instead, these specific tags should be split out separately from {{multiple issues}}, since it doesn't support those specific tags. SnottyWongprattle22:50, 28 December 2010 (UTC)[reply]
This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)07:45, 18 April 2011 (UTC)[reply]
TW-B-430 (new)
Status: New:
Resolution: none
If a page is currently PC protected, and then I try to fully protect it, the full protection goes through, but it fails to tag the page with the protection template. See Punjabi people (I added the template manually). King of♥♦♣ ♠ 06:32, 20 January 2011 (UTC)[reply]
TW-B-436 (pending)
Status: Acknowledged
Resolution: none
Twinkle doesn't seem to know what to do with stubs. This should have been obvious to me before-hand, and I don't expect this to be ironed-out any time soon. When a stub template is nominated for deletion, it is put up at WP:TfD instead of WP:SfD.[20] ▫ JohnnyMrNinja22:24, 9 February 2011 (UTC)[reply]
Twinkle does not seem to be marking pages as patrolled at new page patrol. I think this is a new development in the last few days. VQuakr (talk) 05:29, 19 February 2011 (UTC)[reply]
Confirmed, Twinkle is not marking pages patrolled. They must be manually marked patrolled, then do the tagging or CSD-ing via twinkle. N419BH04:53, 27 February 2011 (UTC)[reply]
This bug has been fixed as part of the current Twinkle improvement project, the result of which will be rolled out on-wiki as soon as possible (i.e. within the next month...) — This, that, and the other (talk)07:43, 18 April 2011 (UTC)[reply]
TW-B-439 (new)
Status: New:
Resolution: none
Nowadays, Wikipedia frequently replaces /wiki/ in the url to just /w/. But the usual revert choices that come up with twinkle don't come up when the url just has /w/. When I replace the w with wiki and hit refresh, the revert choices come up. I'm using Chrome. Weird, huh?—HalfPrice11:59, 22 February 2011 (UTC)[reply]
Twinkle isn't reverting properly, I'm getting the following error: 'Reverting page: couldn't grab element "editform", aborting, this could indicate failed response from the server'. -- Eraserhead1 <talk> 20:08, 23 February 2011 (UTC)[reply]
I think 440 and 441 are manifestations of the same problem. I can't tag articles with maintenance tags, report usernames, tag for speedy deletion, so it seem that Twinkle isn't working at all for me. – ukexpat (talk) 20:53, 23 February 2011 (UTC)[reply]
It seems that other javascript-based tools that also rely on the so-called "editform" thing have ceased normal operations as well. I've tried to use Lightdarkness'sARV tool to report a few vandals, and that tool has also failed today. --SoCalSuperEagle(talk)22:13, 23 February 2011 (UTC)[reply]
The best I can tell, looking at the edit histories of several Twinkle users, something changed on 23 February between 15:40 and 16:12 (UTC) that broke this and several other tools. If anyone can confirm of narrow down this timeframe, it might help the troubleshooters identify what changed. If anyone knows what might have changed, that information would be even more valuable. -- Tom N (tcncv)talk/contrib04:22, 24 February 2011 (UTC)[reply]
I have successfully upgraded the standalone ARV tool to use the API. My working version can be found at User:UncleDouggie/aiv.js. Now we just need to fix Twinkle! My changes to the ARV tool were rather extensive. However, if Twinkle is modular enough, perhaps I can easily deploy the same fix? I'll go start looking at it. —UncleDouggie (talk) 11:53, 24 February 2011 (UTC)[reply]
Twinkle is fairly modular. However, there is some failing code in nearly all 16 of the modules. Ugh! I presume that everyone wants user warnings first, so I'll start there. —UncleDouggie (talk) 12:17, 24 February 2011 (UTC)[reply]
I've managed to duct tape together the warning module. It needs a lot of polish still, but it will hold together for a few days. Known issues:
When the warning is complete, the user must close the pop-up and manually reload the page.
It doesn't test for edit conflicts. If someone else saves a change within the one second that it takes to issue the warning, it will revert the last change. It's only vulnerable during the update operation. Edits made while the user is deciding which option to choose will be retained. I know how to fix this, but I'm out of time right now.
23rd February, an upgrade was done on WP to use HTML5, which has buggered everything which screen scrapes. The recommendation from WM's tech team is that you use the API. My recommendation is that they stop buggering with stuff that works. Either way, this is what's causing the errors with the editing using twinkle, please have a shot at fixing, and also could you file a bug with bugzilla.wikimedia.org in case it's a fault with what they've done. Cheers.BarkingFish13:18, 24 February 2011 (UTC)[reply]
The tech team is 100% right. The developers of Twinkle (which at times included myself btw) have known about this for years. No one ever worked up the appetite/time to actually execute the required rewrite however. This is exactly why the techteam can't always wait for volunteer script writers to get their act together. For 3 years it was known this time would come, yet Twinkle is still not fixed. Waiting for volunteers is sometimes just not possible and then stuff breaks, and THEN they get motivated to fix. Remember all the thousands of userscripts that exist, most unmaintained, the rest in 'keep it working' mode. Very few is under constant active development. And again, I request you do not throw insults at the developers. —TheDJ (talk • contribs) 20:18, 24 February 2011 (UTC)[reply]
TW-B-443 (new)
Status: New:
Resolution: none
If I semi protect and select iconify, it protects OK, but does not put up the small padlock, it adds a plain {{pp-semi-vandalism}}, so I then have to edit and change to {{pp-semi-vandalism|small=yes}} Ronhjones (Talk)00:41, 8 March 2011 (UTC)[reply]
What else could "unnecessary disambiguation pages" be? Deleting these has been an explicit example of G6 in every version at least as far back as December last year (as far back as I bothered searching, and excluding the blanked version from March 13). עוד מישהוOd Mishehu05:13, 4 April 2011 (UTC)[reply]
OK, I've upgraded to the latest version of Firefox and now, when I click on the diff for a page, I no longer get the option to rollback and I have to do it manually? I've tried bypassing my cache and re-adding Twinkle but no difference --5 albert square (talk) 13:48, 3 April 2011 (UTC)[reply]
TW-B-447 (new)
Status: New:
Resolution: none
Twinkle doesn't load for me in IE 8. I don't get the tab at the top of the page, and when I'm looking at a history page, I don't get the "revert" and "welcome" options. It loads fine in Firefox, but not in IE. (I'm using Vector.) I can't tell if it's the "known issue" #311 in the list above, because that link simply reloads this page. Aristophanes68(talk)02:35, 15 April 2011 (UTC)
Insert non-formatted text here[reply]
It's not us that's broken, it's IE8 that has the issues. But Twinkle is going to be updated soon; the updated version will mostly work in IE9. But not IE8; so I'm sorry for those people on Windows XP (IE9 doesn't run on XP). — This, that, and the other (talk)12:11, 15 April 2011 (UTC)[reply]
TW-B-448 (feedback)
Status: Feedback required
Resolution: none
When placing a WP:CSD with multiple criteria, if one of these criteria is copyvio (db-g12), the url parameter in the db template is wrong. In fact, instead of being "url=http://www.example.com" it will be "url={{db-copyvio|url=http://www.example.com}}".
When Twinkle finds the dated section header it should add the warning to the bottom of the section instead of the bottom of the page as seen here. – Allen4names14:21, 30 April 2011 (UTC)[reply]
Twinkle is lazy: it checks for the presence of the current month's section header, but if it finds one, then it assumes it is the last section on the user talk page. So this sort of thing can happen. Perhaps this ought to be fixed. — This, that, and the other (talk)03:12, 1 May 2011 (UTC)[reply]
TW-B-450 (feedback)
Status: Feedback required
Resolution: none
Rollback links from contribs don't work. When clicking the red vandalism link, for example, while viewing a user's contribs, it brings up the generic diff page with no TW links and the revert is not completed. I'm using FF 3.6.13. -- Mufka(u)(t)(c)23:32, 23 May 2011 (UTC)[reply]
Dodginess happens sometimes with Twinkle. We are about to update Twinkle to a new, more robust, API-savvy version, which should alleviate or eradicate problems like this. — This, that, and the other (talk)06:03, 29 May 2011 (UTC)[reply]
@This, that and the other - fairy nuff; if it's just "shit happens; blame aliens" - that's not a problem. Just wanted to document it, in the interests of making it better. Cheers, Chzz ► 08:11, 29 May 2011 (UTC)[reply]
fail more gracefully when trying to do operations on protected articles
TW-B-153 (new)
Status: Closed
Resolution: none
Needs to fail more gracefully when trying to do operations on protected articles. Either needs to check whether the article is created or the first operation needs to be on the article which will cause an early fail. See Wikipedia:Redirects_for_discussion#Sarbajit_Roy for the mess I created trying to nominate a protected redirect for deletion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
![[23]](https://en.wikipedia.org/w/index.php?title=File:PIC00004.JPG&diff=next&oldid=429992559){kind=link}