Wikipedia talk:Twinkle/Bugs

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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.


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.

Not sure how to explain your problem clearly? Read How to Report Bugs Effectively for some general pointers.

Known issues[edit]

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.

TW-B-13 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

Two editors simultaneously reverting a page may cause page corruption. See [1]/[2] and [3]/[4]. MER-C 06:03, 15 September 2007 (UTC)[reply]

Not just my problem, too: [5]/[6]. Affects all forms of reversion, I'd say. MER-C 08:21, 15 September 2007 (UTC)[reply]
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. AzaToth 13:36, 15 September 2007 (UTC)[reply]

[7]/[8]. MER-C 12:55, 19 September 2007 (UTC)[reply]

Hasn't gone away: [9]/[10]. If only vandalism reversion was synchronized. MER-C 13:41, 30 September 2007 (UTC)[reply]

[11]/[12]. Hasn't gone away. MER-C 11:06, 8 October 2007 (UTC)[reply]

Two months later, still occurring. MER-C 11:09, 3 December 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. AzaToth 13:11, 3 December 2007 (UTC)[reply]

Was this caused by bug 13 or something else? --Silvonen (talk) 15:39, 25 April 2008 (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. nneonneo talk 16:13, 25 April 2008 (UTC)[reply]

Yet another example. This is getting annoying, especially because the tool users don't always undo the damage in a reasonable time. --Silvonen (talk) 13:14, 8 May 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. AzaToth 13: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). nneonneo talk 16: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:
  1. gathering info on versions
  2. dealing with likely redirect
  3. opening talk page to the accused <---right here Netscape's Pop-Up blocker notice appears for me
  4. error 200 (as discussed above)
  5. 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]

Another occurrence of this problem. I have asked the user if he will communicate his browser version. --TheDJ (talkcontribs) 17:59, 16 May 2008 (UTC)[reply]

This might be another example of the bug: link Kresock (talk) 22:18, 18 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]

Interesting, never thought of that. AzaToth 21:46, 27 May 2008 (UTC)[reply]
Hmm, see this bugreport on the edit API, which talks of similar potential problems. --TheDJ (talkcontribs) 23:11, 27 May 2008 (UTC)[reply]

Again... --Silvonen (talk) 07:24, 25 June 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]

I'm not sure if this is the same bug, but I ran into the same behavior - half the page was truncated on a twinkle rollback [13]. Shell babelfish 06:04, 19 August 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]
I was using Firefox 3.0.1. Shell babelfish 20:34, 19 August 2008 (UTC)[reply]

TW-B-36 (pending)[edit]

Status:  Acknowledged
Resolution: none

When reverting to a version containing a blacklisted link, TW says the action has been completed when it hasn't (blocked due to the spam filter). Was trying to revert to this version of James Morrison (singer). mattbr 19:28, 10 October 2007 (UTC)[reply]

This could be difficult to fix at the moment, will probably be easier when API edit is ready. AzaToth 19:22, 13 October 2007 (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).    7   talk Δ |   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. –xenotalk 12: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]

TW-B-229 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

RFD nomination removed an old one: [14] [15]. Magog the Ogre (talk) 19:55, 25 November 2008 (UTC)[reply]

Is this still happening? Could you you point me to a redirect or two that I could nominate for RfD to test? Ioeth (talk contribs friendly) 15:36, 3 December 2008 (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 (talk contribs twinkle friendly) 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. Amalthea 11: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]
It's been happening as recently as March 11th 2010 at Files for Deletion, see here. עוד מישהו Od Mishehu 07:40, 25 May 2010 (UTC)[reply]
This thread at WP:VPT seems to describe the underlying MW issue. Amalthea 10:35, 25 May 2010 (UTC)[reply]

TW-B-235 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

Whenever I try to make an AfD, the AfD page is never created. What should I do? Please respond ASAP, thanks! --Cssiitcic (talk) 18:30, 12 December 2008 (UTC)[reply]

Whenever? As far as I can tell that happened once to you in your last 100 contributions, while 1, 2, 3, 4, 5 and 6 were created just fine. --Amalthea 18:45, 12 December 2008 (UTC)[reply]
Can you give me an example of where an AfD discussion page was not created? Ioeth (talk contribs twinkle friendly) 19:05, 12 December 2008 (UTC)[reply]
MoreSteam: tagged and listed, but the discussion page was not created. --Amalthea 19:28, 12 December 2008 (UTC)[reply]
Interesting. I'll look into it! Ioeth (talk contribs twinkle friendly) 20:35, 12 December 2008 (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 (talkcontribs)
Actually to be more specific, number 4 was fixed by DumbBOT--Cssiitcic (talk) 20:43, 12 December 2008 (UTC)[reply]
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? --Amalthea 21:48, 12 December 2008 (UTC)[reply]
I don't know. The one time it took really long, but the other time it did not. Please reply ASAP.Cssiitcic (talk) 21:51, 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. --Amalthea 22: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. --Amalthea 17:59, 13 December 2008 (UTC)[reply]
Funnily enough, the same thing happened to me right now when I started Wikipedia:Articles for deletion/Fourth Album. All the ajax requests finished, but the page wasn't created since I had a blacklisted URL in my deletion rationale. --Amalthea 17:59, 13 December 2008 (UTC)[reply]


(outdent) This happened to me when I listed XxX I had to manually add it to the list of discussions. I use Opera as my browser. BigDuncTalk 22:17, 17 December 2008 (UTC)[reply]

This happened again to me!Cssiitcic (talk) 21:59, 9 January 2009 (UTC)[reply]
Is anybody getting any sort of JavaScript error when this happens? Is anybody able to nail down a reproducible test case of this bug? Ioeth (talk contribs twinkle friendly) 20:33, 15 January 2009 (UTC)[reply]

Chiming in with even more feedback: this also happened to me the first time I tried to create Wikipedia:Articles for deletion/Cartoon Alley‎.--Unscented (talk) 23:04, 15 January 2009 (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]
It's happened to me recently, see this diff[17]. dougweller (talk) 14:36, 19 January 2009 (UTC)[reply]
Again! This is pathetic! PLEASE can someone fix this?!? PLEASE!!!Cssiitcic (talk) 18:56, 28 January 2009 (UTC)[reply]
We are working on it. Please stop getting bent out of shape. We know what the problem is and we are trying to fix it. Leaving messages like the above is neither helpful nor necessary. Ioeth (talk contribs twinkle friendly) 19:21, 28 January 2009 (UTC)[reply]
Sorry about that, and I hate to bother you again, but I tried to AfD a page and I had to do it a second time. Again, sorry.Cssiitcic (talk) 21:58, 6 February 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]
Twinkle causing trouble again! Every time I try to make an AfD, this happens. And this time, by the time I re-did it, the page had already been speedy-deleted, so I accidentally re-created the page. See Wikipedia:Articles for deletion/Vault 2, fo more clarification of the problem.Cssiitcic (talk) 14:29, 20 February 2009 (UTC)[reply]
Again it happened. Seriously, it does happen EVERY time. What is the cause of this? Can someone explain this to me. ThanksCssiitcic (talk) 22:42, 28 February 2009 (UTC)[reply]
Once again the Twinkle Bug strikes! Should I even bother telling you guys? You seem to be ignoring me.:-|Cssiitcic (talk) 20:51, 1 March 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. --Amalthea 21: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]

List of schools in the Philippines did indeed previously have an AfD template. That edit was reverted in the next edit and the final edit was a new AfD template. The article has also been deleted twice before. SpinningSpark 21:29, 19 May 2010 (UTC)[reply]

TW-B-254 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

This might be impossible to reproduce and thus, not worth looking into, but worth mentioning. I tagged Build wiki page for CSD immediately after (at the same time) User:Marek69 moved it to Reston Public Library. Instead of leaving the CSD notice on the talk page of the creator of the page, User:Bamsy1105, it left the notice on the page of the user who moved it. -- Mufka (u) (t) (c) 18:45, 16 February 2009 (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. --Amalthea 02:10, 17 February 2009 (UTC)[reply]
Okay, that's my bad then. ;) A general version of the proposed fix would probably also solve TW-B-0013. --Dinoguy1000 as 66.116.18.58 (talk) 04:33, 17 February 2009 (UTC)[reply]

TW-B-257 (pending)[edit]

Status:  Resolved
Resolution: Pending completion of update

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 :( AzaToth 15: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]
MediaWiki API - here is a link in case anyone forgot about it. ▫ JohnnyMrNinja 22:51, 12 August 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)[edit]

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]

I agree, in principle. People will make that mistake only once, but it's non-standard. --Amalthea 20:20, 25 February 2009 (UTC)[reply]

TW-B-263 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

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. ▫ JohnnyMrNinja 18:15, 13 March 2009 (UTC)[reply]

Actually, I believe the arv tab also does this (or maybe I didn't wait quite long enough). ダイノガイ?!」(Dinoguy1000) 18:41, 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. --Amalthea 21:44, 14 March 2009 (UTC)[reply]

TW-B-279 (acknowledged)[edit]

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) Amalthea 21: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 ...
Amalthea 21:04, 24 May 2009 (UTC)[reply]
My heroine. (No, I'm not saying that Twinkle is my crack ... exactly.) - Dank (push to talk) 21:17, 24 May 2009 (UTC)[reply]

TW-B-285 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

Twinkle messes up image formatting when adding {{pufc}}.

Compare the captions to the first image between this edit and the previous one: Twinkle adds an extra | which removes the existing caption.

[[Sam Korn]] (smoddy) 14:48, 25 April 2009 (UTC) --[[Sam Korn]] (smoddy) 14:48, 25 April 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:". Amalthea 11: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, Amalthea 12: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, Amalthea 11: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]
Yes, I noticed the trial. :) Amalthea 11:18, 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. Amalthea 19:49, 13 October 2009 (UTC)[reply]

TW-B-296 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

In Google Chrome, I tried to rollback this edit as vandalism. When I clicked the rollback link, Twinkle blanked the article content (as it always does when performing an action), and then just sat there and did nothing. Checking the Javascript console, Chrome gives the error "Uncaught TypeError: Cannot call method 'evaluate' of null http://en.wikipedia.org/w/index.php?title=User:AzaToth/twinklefluff.js&action=raw&ctype=text/javascript (line 355)". I have not checked to see if any of Twinkle's other functions also throw errors in Chrome. ダイノガイ?!」(Dinoguy1000) 07:11, 21 May 2009 (UTC) --ダイノガイ?!」(Dinoguy1000) 07:11, 21 May 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. Amalthea 21: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 Dinoguy1000 10: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? Amalthea 21: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⇒Dinoguy1000 22: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. :) Amalthea 22:48, 4 July 2009 (UTC)[reply]

TW-B-306 (acknowledged)[edit]

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]

This is mostly a dupe of #235, but I'm curious about the category: I don't think that Twinkle did anything wrong here, it properly categorized the deletion discussion, but {{AfDM}} doesn't take a parameter |cat=. Cheers, Amalthea 11:08, 15 July 2009 (UTC)[reply]
Unfortunately it's just done the same thing again - I had to add the listing and category manually. As for the listing issue, I get the error message "Adding discussion to today's list: failed to find target spot for the discussion". Bettia (bring on the trumpets!) 11:42, 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? Amalthea 12: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]

I think the key here is Opera 9.6 with JSL. —TheDJ (talkcontribs) 12:54, 15 July 2009 (UTC)[reply]

TW-B-309 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

File:Vallavan ~ Front.png was tagged as Orphaned, but was not Orphaned. TW did not pick that up when scanning the CSD category. MBisanz talk 00:37, 23 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. Amalthea 07: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. MBisanz talk 18: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.
Amalthea 19:19, 23 July 2009 (UTC)[reply]

TW-B-310 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

Batch deletion doesn't work if the PrefixIndex page is opened like http://en.wikipedia.org/w/index.php?title=Special%3APrefixIndex&prefix=Star+Trek%2FFeatured+Quote&namespace=100 instead of Special:PrefixIndex/Portal:Star_Trek/Featured_Quote.
That's in addition to batch deletion being flaky anyway. Amalthea 09:22, 23 July 2009 (UTC)[reply]

TW-B-316 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

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]

Any news on this? I don't mean to be impatient, but the requests been here for over a month... –Drilnoth (T • C • L) 17:05, 7 September 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, Amalthea 12:26, 9 September 2009 (UTC)[reply]
It doesn't seem to ever work, regardless of namespace, whether a page is an image or article, etc. –Drilnoth (T • C • L) 19:51, 15 September 2009 (UTC)[reply]

TW-B-322 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

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. :)
Amalthea 13: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⇒Dinoguy1000 18: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.
Amalthea 19:46, 21 August 2009 (UTC)[reply]
Aah, I see now. Makes sense, and certainly has utility. ダイノガイ千?!? · Talk⇒Dinoguy1000 20:13, 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)[edit]

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 Puppies 15:00, 15 September 2009 (UTC)[reply]

A screenshot would be helpful, as I won't be able to reproduce it myself. Not sure I can help you then, but …. --Amalthea 15:09, 15 September 2009 (UTC)[reply]
Here's the screen shot. File:Twinklefirefoxosxscreenshot.png Basket of Puppies 15:16, 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). Amalthea 15: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 Puppies 15:57, 15 September 2009 (UTC)[reply]
Well, sure, I can fix the bug.
checkYDone, try it now, after bypassing your browser cache. Amalthea 19:00, 15 September 2009 (UTC)[reply]
Hmmm, not TW isn't working. When I click on CSD for an article or RPP nothing happens. Did I break something? Basket of Puppies 20:58, 15 September 2009 (UTC)[reply]
Not working here either. I've tried both Opera and Firefox. Eeekster (talk) 21:10, 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? Amalthea 21:15, 15 September 2009 (UTC)[reply]
There's an undefined variable (min) on line 2142. Eeekster (talk) 22:22, 15 September 2009 (UTC)[reply]
Warning: Unknown property 'column-count'. Declaration dropped. Source File: http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text 2Fcss&smaxage=2678400&action=raw&maxage=2678400 Line: 39 Eeekster (talk) 22:26, 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.
Amalthea 22:34, 15 September 2009 (UTC)[reply]
Thanks, it's working now. Was a bit puzzled because this happened after having to restore my home server last night. ;) Eeekster (talk) 23:04, 15 September 2009 (UTC)[reply]
Might it also now work with the zoom set to higher? Basket of Puppies 01:23, 16 September 2009 (UTC)[reply]
Could you try it again, please? Amalthea 20:41, 23 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>vandalism 08:50, 7 January 2010 (UTC)[reply]

TW-B-339[edit]

Status:  Resolved
Resolution: Red X 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]

Does it affect any other dropdown boxes in Twinkle dialogs? (actually, does Twinkle have any other dropdown boxes anywhere)? ダイノガイ千?!? · Talk⇒Dinoguy1000 20:01, 9 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. Amalthea 15:45, 28 September 2010 (UTC)[reply]
Yes, won't fix. Just tab out of the dropdown, and the form elements change as desired. — This, that, and the other (talk) 07:29, 18 April 2011 (UTC)[reply]

TW-B-345 (pending)[edit]

Status:  Pending
Resolution: none

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. SpinningSpark 14: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. Amalthea 18: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. SpinningSpark 21:14, 19 May 2010 (UTC)[reply]
Just noting that I've run into this issue =] –xenotalk 14:42, 21 September 2010 (UTC)[reply]
Protection using Twinkle has been overhauled in the new version. Coming soon... — This, that, and the other (talk) 05:09, 29 May 2011 (UTC)[reply]

TW-B-348 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

Opera cannot scroll down the blue popup. This happens with any action you choose. > RUL3R>trolling>vandalism 08:55, 7 January 2010 (UTC)[reply]

Is this a duplicate of TW-B-325? Plastikspork ―Œ(talk) 17:26, 7 January 2010 (UTC)[reply]
Sorry for taking this long to answer. It is not. The format looks fine, and the pop-up can be closed. It just won't scroll down. > RUL3R>trolling>vandalism 08:54, 19 January 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”). Sebastiantalk 07: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. Sebastiantalk 09: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>vandalism 09:51, 19 January 2010 (UTC)[reply]
That's strange; dragging the popup works fine here. Sebastiantalk 09:56, 19 January 2010 (UTC)[reply]
Right, sorry, Opera 10 can. I remembered Opera 9 being unable. Can anybody verify it? Juvenile Alzheimer blows. > RUL3R>trolling>vandalism 10:08, 19 January 2010 (UTC)[reply]

There is another issue: When sending to AfD, Opera is unable to create the discussion page and place it in the current list at WP:AFD. > RUL3R>trolling>vandalism 03:14, 22 January 2010 (UTC)[reply]

That part is #306. Amalthea 15:45, 18 May 2010 (UTC)[reply]

TW-B-355 (pending)[edit]

Status:  Resolved
Resolution: Pending completion of update

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)[edit]

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. Hamtechperson 18:07, 19 March 2010 (UTC)[reply]

Sorry friendly bug...Hamtechperson 18:12, 19 March 2010 (UTC)[reply]

TW-B-366 (pending)[edit]

Status:  Resolved
Resolution: Pending completion of update

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). ▫ JohnnyMrNinja 18: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). Amalthea 09: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)[edit]

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.  7  02: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. Amalthea 09: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?  7  03: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. Amalthea 17: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)[edit]

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
  • Shared file with no local page → disallow all
  • No file with no local page → disallow all
Correct? Amalthea 11:48, 20 April 2010 (UTC)[reply]
Sound right to me. However, "no file with local page" should probably also have XFD, as it might be a redirect and this would qualify for Redirects for discussion. --The Evil IP address (talk) 20:37, 20 April 2010 (UTC)[reply]
This seems to work properly now - files on Commons no longer have the XfD or DI tab. The CSD tab still appears, but doesn't work. — This, that, and the other (talk) 07:22, 18 April 2011 (UTC)[reply]
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
This, that, and the other (talk) 06:17, 24 April 2011 (UTC)[reply]

TW-B-372[edit]

Status:  Resolved
Resolution: no Invalid

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]

Getting some input at WT:Miscellany for deletion#Date header, maybe you'll want to comment there. Amalthea 18:43, 14 May 2010 (UTC)[reply]
Twinkle's date headers now match those used at MfD. — This, that, and the other (talk) 02:32, 16 April 2011 (UTC)[reply]

TW-B-374 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

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 · talk 12: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. Amalthea 13:06, 17 May 2010 (UTC)[reply]
Haven't noticed any errors. If I do another AVI I'll check for them. — Timneu22 · talk 13:14, 17 May 2010 (UTC)[reply]
If you do, can you please check if your report was likely to have edit-conflicted? Amalthea 13:27, 17 May 2010 (UTC)[reply]
Ok... may I suggest that TWINKLE should inform me of this in the UI? ;-) — Timneu22 · talk 13:30, 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 · talk 13: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 · talk 12:15, 20 May 2010 (UTC)[reply]
Happened again, again the page had no other entries. I think this is it! — Timneu22 · talk 15:32, 20 May 2010 (UTC)[reply]
Works for me with an empty list. Twinkle simply appends new reports, so that would be surprising. Amalthea 12:55, 22 June 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 · talk 12:57, 22 June 2010 (UTC)[reply]

TW-B-378[edit]

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 Mishehu 06: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)[edit]

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]

Bug 390, which I've reported below, gives diffs of a specific example of this. Adrian J. Hunter(talkcontribs) 14:28, 21 February 2011 (UTC)[reply]

TW-B-385 (new)[edit]

Status:  New:
Resolution: none

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. SnottyWong yak 17:37, 30 June 2010 (UTC)[reply]

Your second problem appears to be a duplicate of 229. (That still leaves the first, though.) עוד מישהו Od Mishehu 13:26, 5 July 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. SnottyWong talk 14:29, 5 July 2010 (UTC)[reply]


TW-B-390 (new)[edit]

Status:  New:
Resolution: none
Seems to be an instance of bug 379. Adrian J. Hunter(talkcontribs) 14:28, 21 February 2011 (UTC)[reply]

I used the "restore this version" funtion on a page with Pending Changes and was not notified of a resulting edit conflict.

I'm not sure whether this is principally a problem with Twinkle, Pending Changes, or an interaction of the two.

Please see this series of edits in the article history. Hopefully the edit summaries speak for themselves, but here are the salient points:

  1. 121.54.32.22 makes two misguided edits to Computer virus (diff)
  2. 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.
  3. Andyjsmith undoes 121.54.32.22's edits (diff), then subsequently makes a constructive edit (diff).
  4. 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(talkcontribs) 14:14, 28 July 2010 (UTC)[reply]

If I understand you correctly, this would appea to be a duplicate for bug 379. עוד מישהו Od Mishehu 12:58, 27 September 2010 (UTC)[reply]
So it is; I've noted that here and there. Adrian J. Hunter(talkcontribs) 14:28, 21 February 2011 (UTC)[reply]

TW-B-392 (new)[edit]

Status:  New:
Resolution: none

The "deli-batch" and "d-batch" function(s) do not recognize file description pages for non-existant files and/or files on the Wikimedia Commons. I've tried using gallery format and creating a list not all too different from a list such as Wikipedia:Database reports/File description pages containing no templates. Is there something I am doing wrong or is this a bug? Help on this matter would be appreciated. Thanks in advance, FASTILY (TALK) 11:15, 5 August 2010 (UTC)[reply]

TW-B-394 (acknowledged)[edit]

Status:  Acknowledged
Resolution: none

Warning added to last section of user talk page, not relevant month section. See [19]. I'm using Google Chrome. --me_and (talk) 12:19, 19 August 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. Amalthea 14:50, 28 September 2010 (UTC)[reply]
TW-B-449 has been marked as a duplicate of this bug. Allen4names 16:29, 1 May 2011 (UTC)[reply]

TW-B-405 (feedback)[edit]

Status:  Closed
Resolution: none

<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. Candyo32 22: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]
Candy, what skin are you using? Have you looked at WP:TW/DOC#Trouble? Amalthea 13:44, 26 September 2010 (UTC)[reply]
My browser is Firefox, and skin is MonoBook .Candyo32 14:29, 26 September 2010 (UTC)[reply]
WP:TW/DOC#Trouble. Amalthea 14:34, 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)[edit]

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 groovily Talk to me 02: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)[edit]

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 looks to me like a feature request, as this isn't part of the currently intended functionality of the software. עוד מישהו Od Mishehu 06:00, 13 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]

TW-B-412 (pending)[edit]

Status:  Pending
Resolution: none

bugzilla:25722 - Friendly causes the 'create' tab on image pages to become 'edit'. Moving from the bugzilla bug (hopefully right place). Bawolff (talk) 14:10, 2 November 2010 (UTC)[reply]

Could someone take a look at this please? Here is an example of viewing a file on Wikipedia, that is on Commons, and not on Wikipedia. Rehman 11:26, 4 December 2010 (UTC)[reply]
Tab shortening will be disabled when the new Twinkle is rolled out very shortly, so this problem will go away entirely. — This, that, and the other (talk) 06:24, 29 May 2011 (UTC)[reply]
Cool :) Rehman 07:05, 29 May 2011 (UTC)[reply]

TW-B-414 (new)[edit]

Status:  New:
Resolution: none
Rtrim issue on Google Chrom

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.

The code is the following (line 377), User:AWeenieMan/furme.js:

editSummary += 'adding ' + imageTags.replace('\n', ', ').rtrim(', ');

Firefox will jump into line 1120, User:AzaToth/morebits.js, into the following function:

String.prototype.rtrim = function stringPrototypeRtrim( chars )

Google Chrome, however, errors out with this message:

Uncaught TypeError: Object {{Copy to Wikimedia Commons}}, has no method 'rtrim'
/w/index.php?title=User:AWeenieMan/furme.js&action=raw&ctype=text/javascript:377
furmeEditText
/w/index.php?title=User:AWeenieMan/furme.js&action=raw&ctype=text/javascript:377
furme
/w/index.php?title=User:AWeenieMan/furme.js&action=raw&ctype=text/javascript:132
addOnloadHook
bits.wikimedia.org/skins-1.5/common/wikibits.js?283-5:52
(anonymous function)
/w/index.php?title=User:AWeenieMan/furme.js&action=raw&ctype=text/javascript:52

Magog the Ogre (talk) 22:49, 29 October 2010 (UTC)[reply]

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)[edit]

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. —KuyaBriBriTalk 14:57, 5 November 2010 (UTC)[reply]

TW-B-416 (pending)[edit]

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. —Half Price 20:59, 7 November 2010 (UTC)[reply]

Hmm, that sure does sound like a Heisenbug; have you noticed it happening elsewhere or did you open your debugger console? Worse, it's impossible to recreate it. Magog the Ogre (talk) 01:46, 11 November 2010 (UTC)[reply]
Yes, I got in a bit of hot water because it didn't put an AfD notice on List of The Nostalgia Critic episodes and I didn't notice. Other than that, no problems. —Half Price 22:19, 18 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[edit]

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

Hi Elen of the Roads. Thank you for your work on patrolling pages and tagging for speedy deletion. I just wanted to inform you that I declined to delete test article, a page that you tagged for speedy deletion under criterion [[WP:CSD#{{{2}}}|{{{2}}}]] because of the following concern: {{{3}}} Please review the criteria for speedy deletion and especially what is considered non-criteria. In future you should rather tag such pages for proposed deletion or start an appropriate deletion discussion. Regards Elen of the Roads (talk) 01:54, 13 November 2010 (UTC) optional reason entered in box[reply]

Is it possible to fix this. Thanks. --Elen of the Roads (talk) 01:56, 13 November 2010 (UTC)[reply]

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)[edit]

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 happens to me occasionally as well. --Kudpung (talk) 09:02, 21 January 2011 (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)[edit]

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. SnottyWong prattle 22: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)[edit]

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)[edit]

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]JohnnyMrNinja 22:24, 9 February 2011 (UTC)[reply]

Hm... It looks like, in User:AzaToth/twinklexfd.js, that the option for SfD is there, but it is disabled probably because it's not implemented properly yet. Just wanted to put that out there. Logan Talk Contributions 20:02, 14 February 2011 (UTC)[reply]

TW-B-437 (pending)[edit]

Status:  Resolved
Resolution: Pending completion of update

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. N419BH 04:53, 27 February 2011 (UTC)[reply]
Will be fixed in rewrite. —UncleDouggie (talk) 17:53, 8 March 2011 (UTC)[reply]
 Fixed for CSD, still broken for tag. — This, that, and the other (talk) 01:50, 12 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) 07:43, 18 April 2011 (UTC)[reply]

TW-B-439 (new)[edit]

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?—Half Price 11:59, 22 February 2011 (UTC)[reply]

 Works for me. Could you give me a URL of a page where this is failing for you? — This, that, and the other (talk) 07:42, 18 April 2011 (UTC)[reply]

TW-B-440 (new)[edit]

Status:  Closed
Resolution:  Dupe (bug TW-B-441)

After submitting a user warning the dialog switches to say "User talk page modification: data loaded..." and sits there. This is on a IP User talk page (if it is significant). FYI, there is a discussion thread with complaints from others too Wikipedia_talk:Twinkle#Twinkle_stalling_during_User_Warn Bagumba (talk) 17:44, 23 February 2011 (UTC)[reply]

Same for me. -- Eraserhead1 <talk> 20:03, 23 February 2011 (UTC)[reply]

TW-B-441 (new)[edit]

Status:  Assigned
Resolution: none

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]

N.B. Noticed in Bug TW-B-440. See also a thread at Wikipedia_talk:Twinkle#Twinkle_stalling_during_User_Warn. WoodyWerm (talk) 20:21, 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]
And I'll report the same continuing. - The Bushranger One ping only 21:45, 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's ARV 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/contrib 04: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:

  1. When the warning is complete, the user must close the pop-up and manually reload the page.
  2. 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.

We need an admin to copy User:UncleDouggie/twinklewarn.js to User:AzaToth/twinklewarn.js. —UncleDouggie (talk) 14:44, 24 February 2011 (UTC)[reply]

Done ([21]) with a minor fix to insert an extra line break ([22]). -- Tom N (tcncv) talk/contrib 16:04, 24 February 2011 (UTC)[reply]

You can see the testing results at User_talk:76.104.29.78, which had been a non-existent page. —UncleDouggie (talk) 14:48, 24 February 2011 (UTC)[reply]

Looks good. -- Tom N (tcncv) talk/contrib 16:04, 24 February 2011 (UTC)[reply]

More info on status at Wikipedia_talk:Twinkle#2011-02-24. Only Twinkle could be so important that it's status updates are split across 4 pages. —UncleDouggie (talk) 16:49, 24 February 2011 (UTC)[reply]

For discussion and coordination of development activity, see Wikipedia_talk:Twinkle#Code_restructuring. -- Tom N (tcncv) talk/contrib 06:17, 27 February 2011 (UTC)[reply]

TW-B-442 (new)[edit]

Status:  Closed
Resolution:  Dupe (bug TW-B-441)

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.BarkingFish 13: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 (talkcontribs) 20:18, 24 February 2011 (UTC)[reply]

TW-B-443 (new)[edit]

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]

TW-B-444 (new)[edit]

Status:  Pending
Resolution:  Fixed

{{db-disambig}} should be on the CSD list as one of the G6 templates. Logan Talk Contributions 18:24, 22 March 2011 (UTC)[reply]

I don't like {{db-disambig}}, because the criteria it lists are not actually codified at WP:CSD#G6. I'm happy to add it if I can have some proof (like some discussion at WT:CSD that it is within the rules of CSD. — This, that, and the other (talk) 08:03, 23 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 Mishehu 05:13, 4 April 2011 (UTC)[reply]
Can we please implement this ASAP? I prefer CSDing through Twinkle than manually, and I've been using {{db-disambig}} very often without any concerns about deleting from sysops. Logan Talk Contributions 17:45, 21 April 2011 (UTC)[reply]

TW-B-445 (new)[edit]

Status:  New:
Resolution: none

When using d-batch, Twinkle sometimes misses a few pages, even though it says that it has successfully deleted them. See Wikipedia:Articles for deletion/Regions of Republika Srpska (2nd nomination) (AfD batch nomination); it took me several runs of d-batch to delete all the pages. -- King of ♠ 01:05, 25 March 2011 (UTC)[reply]

TW-B-446 (new)[edit]

Status:  New:
Resolution: none

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)[edit]

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)[edit]

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}}".

Xionbox 11:32, 15 April 2011 (UTC)[reply]

 Works for me (see this diff. Can you show me a diff where you have had the problem? — This, that, and the other (talk) 12:13, 15 April 2011 (UTC)[reply]

TW-B-449[edit]

Status:  Closed
Resolution:  Dupe of #394

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. – Allen4names 14: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)[edit]

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]

Sounds like an issue on your end... Is this still troubling you? — This, that, and the other (talk) 00:24, 26 May 2011 (UTC)[reply]
I'm still seeing it. I've noticed it for several weeks. -- Mufka (u) (t) (c) 01:41, 26 May 2011 (UTC)[reply]
I just tried it from another account, on another PC, using FF 3.6.8 and had the same result. -- Mufka (u) (t) (c) 02:00, 26 May 2011 (UTC)[reply]

TW-B-452 (new)[edit]

Status:  New:
Resolution: none

File:PIC00004.JPG (edit | talk | history | links | watch | logs)

  • Twinkle did this;

a) tagged the file page [23]

b) notified the uploader [24]

However, it did not add the file to Wikipedia:Files for deletion/2011 May 20

Help. Thanks.  Chzz  ►  05:59, 29 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]
Thanks. I use TW a lot in my work. Not having to double check that it does what it says it does would be idea. Sven Manguard Wha? 06:05, 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[edit]

TW-B-153 (new)[edit]

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.

TW-B-454 (new)[edit]

Status:  Closed
Resolution: see github issue

I tried to AfD the redirect Ranorex GmbH which points to Ranorex Studio (AfD, not RfD, per WP:BLAR). The deletion discussion at Wikipedia:Articles for deletion/Ranorex GmbH and the log entry were created correctly, but the AfD tag was put on the target of the redirect, not on the redirect itself. Huon (talk) 10:47, 13 October 2018 (UTC)[reply]

Intentional behavior, since new articles in particular may be moved/renamed before between page load and AfD nom. See also https://github.com/azatoth/twinkle/issues/379 where I raise the idea of a notice before this happens. WP:BLAR suggests you should restore the content before xfd-ing ~ Amory (utc) 00:53, 14 March 2019 (UTC)[reply]

TW-B-455 (New)[edit]

Status:  Resolved
Resolution:  Resolved

Problem: The TW Tab does not show up; an empty space appears at its place.

Using "Vector" skin.

Site: te.wikipedia.org

It doesn't work in both Chrome 72.0.3626.119 (Official Build) (64-bit) and Firefox 65.0.2 (64-bit)

Other Observations:

  1. The TW did work well until recently.
  2. In My enwiki account, the tab appears normally.

__Chaduvari (talk) 09:00, 1 March 2019 (UTC)[reply]

https://github.com/azatoth/twinkle/issues/532 ~ Amory (utc) 00:53, 14 March 2019 (UTC)[reply]


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.