3.1 MiB
3.1 MiB
PC1,PC2,PC3,PC4,PC5,PC6,PC7,PC8,PC9,PC10,PC11,PC12,PC13,PC14,PC15,PC16,PC17,PC18,AuthorWMFAffil,source,phase,text,id,week_index,priority,closed_relevance
-4.51217998416782,0.2755959021547483,5.102118172735597,9.844034771816354,-9.864659796364323,-3.6216469136125315,2.790424427517677,-0.7896211162921519,1.1993855496239043,-0.9620045143563156,-1.6074406474290943,-0.5563570278530887,0.05492520768438158,-0.3446805824407031,-1.1154363740796676,0.41010897626324905,-0.7594303089266429,1.111180316825185,False,c1,3,"pawn character editing
seen on master branch (beta labs) as of 30 September.
open a page on beta labs in VE
begin editing at default location or top-left beginning of page
pawn character appears upon entering text
--------------------------
**Version**: unspecified
**Severity**: major
**Attached**: {F12377}",56791,13,Unbreak Now!,True
-5.660771915227272,1.3859379237600447,-5.674970364865263,-3.690083765089674,1.801365806587996,-3.0163252405451413,0.7175123884498209,2.582915095067401,0.8452632917799627,0.5492272451296643,-0.7595306338053049,-0.672517686875297,0.5445149531044868,0.6220932479417707,-0.14168047476882784,0.34276906537393825,1.338811040989783,-0.23464671768909828,False,c1,3,"**Author:** `Wikifram`
**Description:**
After the failure of VE (e.g. witness the opt-in at the three largest wikipedia versions), the WMF now comes with MW 1.22wmf19, which creates more errors than it solves for VE, as could be predicted by anyone remotely busy with VE. I have documented some problems I found with minimal testing, there are probably a lot more. The version doesn't do what the release notes claim (e.g. reflists can't be moved, not that they often need moving anyway; many templates can't be moved either), and doesn't solve the major problems that existed with the one thing that could somewhat be dragged, images.
Multiplying known problems instead of solving them, when there are plenty of major problems which have turned away most of your user- and testbase, is simply stupid.
No one is waiting for weekly updates (certainly not of this ""quality""). Please, PLEASE, stop it; get back to the bug list, solve the 50 most urgent ones, ''test them thoroughly yourselves"", and then come to us, present the improvements, and ''ask'' us whether we want to implement and test them.
--------------------------
**Version**: unspecified
**Severity**: major",56737,12,Unbreak Now!,True
-2.521099336037078,3.477535227787687,0.38313875837224387,-0.4619907621777186,-0.42424806254342695,-1.4899671815760538,-3.2884599032723196,0.9528488432189396,0.8722405860794129,-0.6905504665819233,0.11782256758974885,-2.2000705142228263,0.5351899530082584,-0.4889966367347185,-0.6497489484933867,2.060315230363634,-0.24164516413347226,-0.6377943152379115,True,c1,3,"See last line of this diff: https://fr.wikipedia.org/w/index.php?title=T%C3%A9l%C3%A9com_SudParis&diff=next&oldid=97023702 .
Steps to reproduce, as provided by user: Seudo.
1) Go to https://fr.wikipedia.org/wiki/Cumul_des_mandats_en_France - you don't need to save later
2) Click on Modifier
3) Place the cursor after the words « exercice simultané de mandats » (5th line, I think)
4) Click ""Plus->Référence""
5) Write something in the dialog, i.e. ""toto.""
6) Save the reference
7) Click at the left or at the right of the newly added reference
8) Watch pawns multiplyin' as you keep clicking.
Suedo adds that in his console Web he also got a Javascript error, TypeError: group.firstNodes[index2] is undefined (load.php:54) .
I was able to reproduce this as well, but only with FF (exactly like Seudo), only in the actual article - not in my sandbox - and only clicking at the left of the word. The user reports instead that this might happen at any point in the page.
My edits in the sandbox could not reproduce the issue but generated https://bugzilla.wikimedia.org/show_bug.cgi?id=54341 instead.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54976",56712,12,Unbreak Now!,False
-2.3136607206222974,-4.533429929092529,-1.4595325059547921,1.4980283596019004,-2.5717794715942217,-1.0969137553404678,2.1143452758022905,-0.8734356847652857,2.2925375747735988,0.6947168496477403,-0.7121844010374172,-2.8927124941265605,-1.1295140274268523,0.2692374612692445,-0.3115105898052448,2.1187403046404376,1.4320026520623517,-2.4979007403100724,False,c1,3,"For example, you can't copy/paste in the edit summary box.
--------------------------
**Version**: unspecified
**Severity**: major",56375,11,Unbreak Now!,True
0.3365330694446902,-11.364828594327996,3.7961360388373997,-0.7997266400733789,1.1285522387100526,2.2493745827165386,4.061552741859281,3.664198386748691,-0.4150549309662378,4.561353563993368,3.6582054809940625,-1.0133515438067833,1.7833982415021503,-0.18237342496675346,-2.105291445728369,-0.6410955766659422,-0.33627449803771947,-1.6893408540022403,False,c1,3,"https://en.wikipedia.org/w/index.php?title=Matt_Chandler_%28pastor%29&curid=37214846&diff=573675359&oldid=571858677
For some reason, multiple different unnamed references all get name="":3"" there.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54445",56341,11,Unbreak Now!,True
-3.248926985351006,1.9365095994995798,-2.5623162786571054,2.980891442784558,0.8212584046668945,1.1896342474719985,-3.198314068713014,0.49838209589176874,0.3899548525744172,1.446986825273612,-1.1104780759790878,-0.6877672392133778,0.956808064395489,0.013145544926701724,-1.538247635418359,-0.17711311398210705,-1.7323885534969579,-0.5997454529275876,False,c1,3,"VisualEditor seems to take particular pleasure in abusing circumflexes.
Issue 1: VE duplicates the first character entered after a circumflexed letter at the end of a line.
* Steps to reproduce: In VE, enter the text êtt (actually enter the characters individually, don't copy/paste) at the end of a line.
* Expected result: ""êtt"" is entered.
* Actual result: ""êtt<newline>t"" is entered.
Issue 2: At the beginning of a line, VE turns a circumflexed letter into a pawn character when removing text entered after the circumflexed letter.
* Steps to reproduce: In VE, enter the text êtt at the beginning of a line, then delete the last 't'.
* Expected result: ""êt""
* Actual result: ""♙t""
There's also some wonky behavior when dealing with circumflexed letters in the middle of a line, but I'm assuming that the descriptions above will be enough to help you investigate VE's blatant circumflexphobia.
--------------------------
**Version**: unspecified
**Severity**: normal",56047,10,Unbreak Now!,True
0.40335409354266094,-2.719738337929046,-0.43134717516658405,-0.717095139639276,2.754981735649199,-3.7336680055181333,0.6182365521728119,-1.5865416859819783,-1.3824143335684187,1.6053222774951816,-1.0288177781966015,-0.4871948404306361,0.5177759494897569,-0.6027648858689432,-0.7435340512721815,-1.1557034184423047,0.06778446018466444,1.6191750651121486,False,c1,3,"Since approx. August 30-31 VisualEditor breaks when Polish-language diacritics (ążśźęćń󳥯ŚŹĘĆŃÓŁ) are input. The characters themselves disappear and text around them gets mangled and moved around.
They're all input using AltGr (right Alt) + diacritic-less version of the characters, with the exception of ""x"" mapping to ""ź"" (so, respectively, azsxecnol).
I have been unable to replicate the issue myself, but it's definitely happening.
pl.wp thread: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#VisualEditor_a_polskie_diakrytyki
This is repeatedly breaking page text on the Polish Wikipedia, so I'm marking the bug ""highest critical"".
--------------------------
**Version**: unspecified
**Severity**: critical
**URL**: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#VisualEditor_a_polskie_diakrytyki
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53680",55747,9,Unbreak Now!,True
-6.4182018166840695,-2.9833706126048067,-2.6710709850212186,-0.11693633036275752,2.5387181306942055,-2.3777589137421966,1.4258719965307884,2.5724120433867483,-1.7821406089532421,-2.0392880554900272,-0.9905737867169582,-0.6510482752299278,0.09129198349106904,-1.3339645186791813,-2.332058574625107,-0.03358782220230366,0.27024186376815806,2.0707111410668855,False,c1,3,"I haven't worked out this out fully yet, but it seems that linking or annotating newly added text that contains accented or non-Latin characters frequently causes those characters to disappear. Re-adding them in the same word almost always results in their turning into pawns when, anywhere else on the page, the link dialog is subsequently opened or a link is inserted.
This happens everywhere on a page including body text, tables and image captions.
--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53747",55680,9,Unbreak Now!,True
-6.724166848066972,4.422504231313479,2.005624675428219,4.223151632486771,0.8946262330745787,2.2970857086963514,-0.9845467647159829,1.4329893442136528,-1.1836583728132761,-1.9122617150380847,0.5298413887994675,0.8407334340022541,1.3903405653293706,-0.15736891164726874,0.05158090353893119,0.5980124945222753,0.9858231243896245,0.16905793053997287,False,c1,3,"When inserting any template immediately before any word that is linked or has bold or italic markup, that word is deleted but continues to be displayed in the editing surface. The deletion can only be seen in review changes or upon saving.
To reproduce:
1. Open any page in VE.
2. Place the cursor immediately before a word (i.e. with no white space between the cursor and word) that is one or more of:
* A link
* Bold text
* Italic text
* plain text that you have just added one of the above to
3. Insert any template at the cursor position
4. Observe the word remains as expected
5. Review changes, and observe the word has been deleted.
Examples: https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=570195482&oldid=570194023
On en.wp PamD encountered this bug when inserting a maintenance template at the head of an article that started with a bold word.
--------------------------
**Version**: unspecified
**Severity**: critical",55334,8,Unbreak Now!,True
-6.068784772210795,-0.19124880694565327,-4.433084169334865,-0.41328185326615197,-0.7755081647317182,4.16395432525928,-0.1720344928605746,-0.5365520575093543,0.08286023719636698,-1.121667037012223,-2.3107834072483984,1.0998053006926154,-0.3576796681075338,2.0892748874983917,0.5691876487544851,0.14629050566537058,0.06795290049251723,0.29829697154151824,False,c1,3,"VE link insertion dialog when attempting to add a section link
Since the latest update it is impossible to create links to specific sections of a page in VisualEditor: As soon as you enter the # character the link insertion dialog gives an ""Invalid title"" error. See screenshot attached and bug 50881 comment 11.
I've reported this separately to bug 50881 as that is an enhancement to give proper handling of section links, but this is a regression that blocks all use of links to sections.
--------------------------
**Version**: unspecified
**Severity**: critical
**Attached**: {F11887}",55219,7,Unbreak Now!,False
0.024666938379469094,-3.2588388642715955,1.9203140624387913,-1.512408565436578,-0.32877538044903865,0.7272926783129237,-5.233055119051922,-0.9045025671721455,4.008511174701245,0.41714533353730854,1.0258348671045447,2.388615330971616,3.6661578349658246,1.5051076225664328,0.34299387753222454,0.6055466209519442,-0.40913563465474634,0.08527783219675888,False,c1,3,"Steps to reproduce:
1. Go to http://en.wikipedia.org/wiki/Post_and_core
2. Edit it with VE
3. Make some minor edit, by example, add a space after ""is a type""
4. Review your changes (or save)
Results:
The {{Interventions infobox|(...)}} gets removed.
--------------------------
**Version**: unspecified
**Severity**: major",54608,5,Unbreak Now!,True
10.568118871243644,-3.8655044545225117,3.2561967359408683,4.468546656014583,-6.296242038437496,-0.33075997261859014,1.1495233291955929,-0.039757229026998187,-0.22174913742926072,-0.9301423999364546,1.8108679771791292,0.7509641044206341,-1.846316133596483,-0.34875333589706337,2.6564090608241466,0.6050627542035165,0.2709562320640966,-0.5735581903735176,False,c1,3,"[error] PHP Strict Standards: Only variables should be passed by reference in /srv/phase3/extensions/VisualEditor/ApiVisualEditor.php on line 255, referer: http://server/wiki/index.php/Sandbox?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: trivial",54466,4,Unbreak Now!,True
1.7272726464220853,0.9702098854072663,-5.317430733885477,-5.864217672701456,2.562305743263311,-1.5182052468143254,-2.797041787443375,-1.3548558201543086,0.9092436173720706,-0.9018620074710921,1.5181157363678852,-2.3285935852487363,0.8232232672452713,-2.0211100200227508,1.319353167663306,-0.7260821754231566,1.3400677268002845,0.7842910988274017,True,c1,3,"<<When I was trying to add a link to Classic XI, (didn't know it didn't exist) it repeatedly took the word ""Classic"" and continually tried to make the link go to Classical music. [...] --buffbills7701 19:42, 1 August 2013 (UTC)>>
I tested this as well with Vector on both Chrome and FF, on it.wiki with the word Lettera (which is an existing page), it keeps insisting that I must link to Letteratura instead. I tried a workaround and was able to get Lettere, but it ain't the same thing.
Thanks!
--------------------------
**Version**: unspecified
**Severity**: critical",54420,4,Unbreak Now!,True
5.115840225596658,-8.380142698362196,-0.9371666153180964,2.442076619386059,-1.6776586455184697,-1.0084272235245775,-3.792233446451277,-0.9766705293005962,-3.074324765015981,0.6818281299134368,0.1569585240430027,1.8593997622370442,-1.483140275799908,1.3029646769070977,0.7626838983058439,-1.0486212025466382,-1.1023097301083344,0.4429139351071425,False,c1,3,"VisualEditor.php attempts to register a hook handler that was removed (summary credit goes to Ori)
stack: http://paste.tstarling.com/p/GuTJEM.html
Tim says:
> var_dump($wgHooks['BeforeWelcomeCreation']);
array(2) {
[0]=>
string(42) ""VisualEditorHooks::onBeforeWelcomeCreation""
[1]=>
string(44) ""GettingStartedHooks::onBeforeWelcomeCreation""
}
> print is_callable($wgHooks['BeforeWelcomeCreation'][0]);
> print is_callable($wgHooks['BeforeWelcomeCreation'][1]);
1
--------------------------
**Version**: unspecified
**Severity**: normal",54368,4,Unbreak Now!,True
2.413819634873932,-2.721744393894781,7.5671175755716575,0.56051273627252,1.5376378591568214,-0.4921105477298232,-0.3407908477760353,2.6717232524781456,-0.5191643796987997,-2.143317532515167,-1.796087784215387,-1.2939972342721155,1.1593211944847024,0.05352044512417198,-0.42344297279872034,-0.5074963190253123,-0.07085311960078089,-0.12639193688929695,False,c1,3,"Screenshot
Since the VE update tonight the save dialog is half out of the screen on FF 23/Win7, but sometimes only.
--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52326
**Attached**: {F11781}",54317,4,Unbreak Now!,True
19.451402701254704,-3.474995038869018,-7.116592398658474,4.265191569258299,0.42138592723604584,-2.4621498748381114,-1.2112300410537875,-0.5989430027737486,-0.5879029735975139,-2.6924421255163034,-0.9056397492252763,0.20855819225864458,3.3763074554825314,-1.1941593695640127,-0.7784037897023808,-0.369090165420908,-0.6030486832851067,-0.16227466270103075,False,c1,3,"https://de.wikipedia.org/w/index.php?title=Spezial:Letzte_%C3%84nderungen&limit=500&days=30&hideliu=1&tagfilter=visualeditor
---
29 July 2013
(diff | hist) . . Aurich [pending edits]; 19:40 . . (-1) . . 95.165.106.6 (Talk) (→Branchen und Unternehmen) (Tag: VisualEditor)
(diff | hist) . . Djihadismus; 19:30 . . (-980) . . 2a02:908:df31:8700:6861:a2d8:52b6:1392 (Talk) (Tag: VisualEditor)
(diff | hist) . . Thronfolge (Vereinigtes Königreich) [pending edits]; 19:30 . . (-2) . . 84.155.202.154 (Talk) (→Derzeitige Reihenfolge der Thronfolge) (Tag: VisualEditor)
(diff | hist) . . Lagerungskonzepte [pending edits]; 19:15 . . (+73) . . 81.217.18.166 (Talk) (→Stützlagerung schwimmend (SLS)) (Tag: VisualEditor)
(diff | hist) . . Andreas Müller (Fußballspieler, 1962); 19:13 . . (+233) . . 2.244.238.208 (Talk) (→als Funktionär) (Tag: VisualEditor)
(diff | hist) . . Nexus 7; 19:12 . . (+4) . . 88.130.17.139 (Talk) (→Zweite Generation (2013)) (Tag: VisualEditor)
(diff | hist) . . Räumliche Orientierung [pending edits]; 19:09 . . (-55) . . 72.89.247.161 (Talk) (für emotionale Betroffenheit lassen sich in der Literatur keine Belege finden.) (Tag: VisualEditor)
(diff | hist) . . Medien (Land); 19:06 . . (+226) . . 78.53.45.165 (Talk) (→Spekulationen über die Verwandtschaft von Kurden und Medern) (Tag: VisualEditor)
(diff | hist) . . Inka Bause; 19:05 . . (+42) . . 188.194.150.121 (Talk) (→Singles: ist das liebe 1987) (Tag: VisualEditor)
(diff | hist) . . Mississippi River; 19:03 . . (+1) . . 77.6.118.157 (Talk) (Tag: VisualEditor)
(diff | hist) . . Geständnisse [pending edits]; 18:54 . . (+1) . . 91.39.63.227 (Talk) (→Handlung: Grammatik) (Tag: VisualEditor)
(diff | hist) . . Vojtech Tuka; 18:53 . . (-23) . . 2003:4d:eb3c:f001:5452:a193:58c6:cc59 (Talk) (→Flucht, Prozess und Hinrichtung) (Tag: VisualEditor)
25 July 2013
(diff | hist) . . Lotta Schelin; 04:26 . . (+2) . . 92.76.236.197 (Talk) (→Nationalmannschaft) (Tag: VisualEditor)
---
Anons are editing the German Wikipedia with VisualEditor.
My suspicion is that logged-in users are hitting certain pages, the pages are being cached, and then anons are receiving these cached pages (with the VE init JS loaded).
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52202",54232,4,Unbreak Now!,True
7.795709607826762,4.160603357584652,3.081734431061239,-3.2271471312897395,-3.5447661137043562,5.078221669734263,-1.2419435425930558,2.4161198431007826,2.4580751396186296,1.1057096609117405,-1.832695634730414,-0.40150852204646736,-1.0040608985997537,0.8652205530889079,-0.5857031910723203,-0.05024977564447042,0.02607168768229129,1.3908094705469838,False,c1,3,"**Author:** `matthiasbecker1967`
**Description:**
According to http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Umfragen/VisualEditor_Opt-in the German Wikipedia community demands to postpone enablement of the VE for IPs until the VE is a robust and mostly bug free feature and to revert VE for registered users back to ""opt-in"".
--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49998
https://bugzilla.wikimedia.org/show_bug.cgi?id=52232",54202,3,Unbreak Now!,True
0.978698389898994,-17.87030840447756,-5.219350553128887,-2.57528116654891,-2.0435789281839716,5.860753879418819,3.0268900872052873,-0.6512663811995079,0.16230830206961455,0.5663839272797055,0.45979096968325317,-1.299343307635873,-0.15673968058057675,-0.4254804839054538,-0.5862718735158783,-0.48794828011230706,0.0694679201695978,-0.29366603853991413,False,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: major",53948,3,Unbreak Now!,True
-10.295329296324114,9.855675103636642,-0.0904495949616404,-3.7549456055636266,2.448085370719325,-0.5191575350540724,-0.3029290747611224,-2.4981838176425497,2.9386693887815527,0.892862282830408,0.3940261767263933,0.00020791806985775985,-0.5087736899311857,3.1584678169908678,-2.4343619849227185,1.164325583918314,1.4163464177004543,-4.100542653838889,False,c1,3,"Apologies if this is a duplicate; I haven't found a report about this.
If you add a new reference with VisualEditor, you can't immediately reuse it with the reference editor; it doesn't show up in the list. You need to save the page and re-open the reference editor for that reference to show.
--------------------------
**Version**: unspecified
**Severity**: normal",53689,2,Unbreak Now!,True
-6.380455580604876,2.2642611650076105,-0.9928919412474269,2.93099149330118,3.6854063591882142,5.385742396913729,1.901621730173808,0.2152009083483854,1.5028295804962453,2.795089976031792,2.136612933829245,-1.3823367519985539,0.6007820463686828,0.7368141709695593,1.0181445141947814,0.21944984614648444,0.27893030001844843,2.4696792213967482,False,c1,3,"Currently, the ""insert reference"" dialog is a bit confusing and buggy, and it takes two or more steps to actually type the content of a reference (most common case).
We should initialize the dialog with a micro-VE surface that immediately enables the user to type reference content. The selection of an existing reference can be pushed down into a separate section or tab.
(Per discussion w/ James)
--------------------------
**Version**: unspecified
**Severity**: normal",53152,1,Unbreak Now!,True
-3.4519211393553775,0.4812067509852387,-3.0648072370621335,2.9935483876212174,-7.195988800339766,4.563102765232183,1.4015914735742125,0.17602271431536026,-2.789214337410857,-0.5214517576100288,2.9939270987311537,2.1994237425071272,-3.3029554576340914,0.9929865146133583,-0.3820565021133202,-0.32841960727470765,-0.09091961236522605,-1.0020802194390162,False,c1,3,"data-mw.i seems to be dropped on edit in latest VE, which causes a loss of round-trip information for spaces etc.
--------------------------
**Version**: unspecified
**Severity**: major",53150,1,Unbreak Now!,True
4.603666380230232,6.5812339139844696,5.078628665105516,4.8469278512491085,-2.107419108661265,0.4822235204138272,0.759135379195099,1.0652114069148038,-2.3284239452285895,-0.5672468306386795,-4.927703897030016,-0.39962103872619714,-2.9070778164611735,-0.026481868864268954,1.089772601582693,0.45967944382810355,-0.96147538359231,-0.33332883882829334,False,c1,3,"This is a tracking bug only for blocker-level issues before the planned release of the VisualEditor beta to IP users on English Wikipedia. Please only add blocker-level issues (e.g. content corruption); ultimately, what qualifies as ""blocker"" is at the discretion of James Forrester, VisualEditor PM.
--------------------------
**Version**: unspecified
**Severity**: blocker",52848,0,Unbreak Now!,True
-5.260662907426241,6.625285776189582,4.989165489072082,-1.9424765275560598,-4.001793321090119,-1.7120083191692,0.9450861027180038,-2.637749219750253,1.7979597322966396,-1.0040793200608702,-0.5960012844766722,2.649752380187712,-0.5733907525960218,0.025877321242785634,0.44802746457684517,-0.08364809860206729,-3.4391673352678116,0.21171645960617202,True,c1,3,"It is possible to have a tooltip that will tell you what a reference is when you hover over the number in edit mode, as it currently does in viewing? It is inconvenient to editors to have to go into the references mode to view the source while editing.
(Request from En Wikipedia)
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://www.mediawiki.org/wiki/VisualEditor/Design/Reference_Dialog
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50110",52768,0,Unbreak Now!,False
2.406762827136576,-3.0101069187236806,-5.845064166505594,-2.5912416292603813,-0.42756948166881004,-2.392735681397351,-2.8647822675411465,-2.9241574380045643,-0.7018474534249215,-0.3276572405581115,-1.277864689727635,-0.7570576097594462,1.385145140821309,-1.9897951132667275,-1.7868949101638547,1.4474980369630168,3.0446787134893913,0.5358898615025594,False,c1,3,"screenshot
As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot.
Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21.
--------------------------
**Version**: unspecified
**Severity**: major
**Attached**: {F11031}",52731,0,Unbreak Now!,True
-3.045381270525978,-2.6412897833586104,-0.7383241170536916,2.2254120285934853,3.215526158473821,-1.0268066044762423,-3.1519413486557424,0.08550259916061775,-1.5700115983668486,2.4800302679163426,-3.3231413224014323,-1.143295502091698,0.24632522611255947,-1.8281455843970753,-0.4182712787338039,-0.07371613172387342,-0.5995050331037711,0.1748212956200781,False,c1,3,"Screenshot of problem
This causing:
* The label fallback (parameter name + ucfirst) not working.
* It is still available from the ""Add parameter"" dropdown.
* The user can actually add it again, causing a logic error.
I can currently consistently reproduce this on https://en.wikipedia.org/wiki/Taal%2C_Batangas?veaction=edit when editing the ""Population Consensus of Taal"" information box.
See screenshot:
- ""title"" is both in the sidebar and in the selectable cloud
- ""title"" isn't transformed into ""Title"" (the templatedata has no .label for this one)
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11920}",52715,0,Unbreak Now!,True
2.821311049377424,-2.7301969423443246,-3.0966101779557995,0.9982739089716164,1.779010907423244,-1.8616141976358351,-2.5137692309942206,0.5206699908268326,-2.516086073640934,0.9060928159869706,-2.6354446042228665,-0.5239118184051366,-0.08058299549039294,0.04044598142567768,-2.4436653025169592,-0.357366061425916,-0.406338328034048,-0.1545433019197635,False,c1,3,"The Edit tab for VisualEditor is sometimes not correctly initialized. Loading about 50 random pages, on one of them I will not have the ""Edit source"" tab, and the ""Edit"" tab will point to the wikitext editor instead of VisualEditor.
Chrome/Ubuntu, logged-in. Console shows the following error when this occurs:
Exception thrown by skins.vector.js: Object [object Object] has no method 'collapsibleTabs'
--------------------------
**Version**: unspecified
**Severity**: normal",52708,0,Unbreak Now!,True
-5.393421417787501,5.449935876600801,0.1379375505057574,-1.3093291389137782,-3.6759189784958575,0.9154345251251941,1.0360213536055403,2.0353263405557867,3.199367387226726,1.499750442920246,2.5409105868731463,1.6990092429064199,1.3802454456579185,-1.1652207875003322,-0.05140077829738221,0.6431510655314333,0.2839670805703056,0.24401412560623492,False,c1,3,"It might be nice to show a quick intro message for first-time user, could be implemented via GuidedTour. We may want to distinguish between new vs. experienced users.
Part of the goal of the message would be to help users understand the difference between editing in wikitext and VisualEditor, and to explain that wikitext cannot be entered in VisualEditor. We're seeing a fair number of users enter wikitext in VisualEditor, and adding a first-time explanation might help reduce this issue as we roll out VisualEditor to more wikis.
(Feel free to close this WONTFIX if we decide this issue is not significant in scale enough or the message would be too prominent. But having a first-time use message come up is not that unusual for a major feature change.)
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T51820}
{T89074}",52601,0,Unbreak Now!,False
-3.471407542215064,0.4680791582733388,1.3000332666447392,-2.9638539211921886,4.747750290760621,1.070390890788434,1.897276236126034,-1.600930076793115,-0.5335708416449012,-0.7832132940131911,-0.964017116345377,-2.000803266750374,-1.4287670013486125,0.2037929289999667,-0.5806050818912736,-0.3424958692827288,2.8483252920483704,2.022302702627976,False,c1,2,"After save of page using VisualEditor on beta, and clicking on Edit again (I am on the current page, as the content has been updated), I don't get the latest revision, but the revision I had before (the content switches back to the old version), and getting a warning that I'm not editing the latest version
--------------------------
**Version**: unspecified
**Severity**: blocker
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50716",52441,-1,Unbreak Now!,True
-5.55761982167461,-1.9024482534501903,-2.5873656008483135,1.7855199128998689,0.3497302468009259,0.6265349587684497,0.2781151885494708,1.2824969551916432,0.4222030597068184,0.5915548550538317,0.1308085844633209,-0.3824301220047944,1.119990401841381,-1.8226811505224778,-0.9203947922400522,1.9386021014470727,0.9234720610603089,-1.057712498919994,False,c1,2,"An attempt to save an article in the visual editor after a period of inactivity results in the ""Invalid token"" error message and saving fails. At this point, the user is completely stuck and their entire work is lost.
Loss of session data can also occur in the regular source code edit window, but is easily rectified by repeated saving; this doesn't work in the visual editor.
I would classify this as user-hostile behavior.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50402",52424,-1,Unbreak Now!,True
-5.273398223929413,2.574127448369282,0.44419308832845417,-1.2048495102816326,2.4047080410911317,1.6607485343754342,-4.449004945737565,-1.4003498498180473,-0.8904747838529589,-3.0617264532696224,0.821017412021293,-0.665495159950104,-1.3879531937181913,-0.6307325375203892,-1.7115043394838785,2.683793868749062,-0.14027001720641885,-1.8756938962017624,False,c1,2,"Screenshot
See the screenshot; I imagine the reference is being treated as existing within the template, rather than within the template within the page - it hunts for <references\>, can't find a tag in the template itself, and freaks the heck out.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51337
**Attached**: {F11303}",52423,-1,Unbreak Now!,True
1.2963661204620212,-9.858819922537089,-3.839968778891608,-3.4082799463754117,5.252852278010554,-1.5328311458369899,2.3021359328122832,0.48014116054091904,-0.6824570621377732,-1.5475236720050476,-0.08741697568259754,0.7111443802672226,1.130008043916256,1.4379879879053146,1.6802320110891982,-0.11954419257403776,-0.9777727108662195,-0.035855162584645495,True,c1,2,"The references list one is still there; did Trevor's change break it?
--------------------------
**Version**: unspecified
**Severity**: critical",52349,-1,Unbreak Now!,True
8.472442600441443,-14.559563496768266,-4.129101408750554,-0.9190691671227765,-1.9570455589699582,6.964266995352566,7.130755115817853,0.8415333821708525,-0.7028398784227884,5.439572634887117,6.297417690731052,-1.4929461024070996,1.8852403138683367,-0.9945173219644485,-0.4191190104083873,-0.8872056953296561,-0.05132286319187318,-0.5197527542746094,True,c1,2,"http://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FGNoSR&diff=561873747&oldid=561873385
Removes non-breaking space.
--------------------------
**Version**: unspecified
**Severity**: major",52339,-1,Unbreak Now!,True
6.223559625758146,2.8966070546082356,7.984795743425742,3.9054603210611383,-0.8634130360009632,-1.9862063849421918,4.54732149502238,2.368212474997935,-4.019816402466813,-1.2272578151512672,-2.0388958412758313,3.1374325697313123,-1.9440967507168194,0.402567679826217,-0.8613772085954654,3.1870515751483777,-0.5164550203403185,-1.3019123743305956,False,c1,2,"Log in to beta labs:
No navigation arrows exist in FF or Chrome
Special:Preferences shows no tabs
No links to VE exists even when Preferences are set
In regular editor, no controls appear
A number of pages e.g. user page show error Uncaught ReferenceError: mw is not defined load.php:1
--------------------------
**Version**: unspecified
**Severity**: critical",52264,-1,Unbreak Now!,True
-5.947014426359051,0.16368789935357064,-4.8687534258094125,-2.2079298262124327,4.9365629811041085,0.28795133393109573,0.22651353109360528,-0.11971515706418556,1.2626995882576584,-0.6382411911951973,1.2864358302605887,-0.7660133017894613,2.3897755268252614,-2.5208505974711777,1.1443386870259102,-1.3907791355550816,2.5665931204529295,-0.8364164616938901,True,c1,2,"I made a grammar fix (one word), and did not check the differences before saving. Mistake! :)
http://en.wikipedia.org/w/index.php?title=Abdullah_of_Saudi_Arabia&diff=prev&oldid=561571041
It looks like all it did was sanitize the templates, which isn't the worst thing on earth, but it's hard to verify that was all that happened (especially for a non-expert).
No recommended fix, exactly, but perhaps something to consider.
--------------------------
**Version**: unspecified
**Severity**: normal",52259,-1,Unbreak Now!,True
-4.054018929008614,3.2318149409971717,-3.6050247101010147,-8.740009352084474,-7.52633498293314,-0.6984654540315027,1.1000705014190846,0.33979874047190683,1.9637825919271588,0.5054692232913096,-0.5777528957731741,-0.6496397020083061,-0.3325523906915979,-0.6964454201779828,0.08297358455153958,-0.20332789531940465,2.6257740007356034,-0.43725691786402265,True,c1,2,"For deployment purposes, we will want VisualEditor to be enabled for all logged-in users but not anonymous ones; to do this, we'll probably just fail in VisualEditor.hooks.php#onBeforePageDisplay() if they're anonymous, according to Roan.
--------------------------
**Version**: unspecified
**Severity**: trivial",52246,-1,Unbreak Now!,True
9.358132380037985,-13.464060020431885,-2.092103116134437,-3.8007770804329093,0.3317876451516646,2.7085282354314604,0.047058372254549674,-0.6819861290185572,-1.088303036352896,-0.9695821352545506,-0.5782956107681483,1.0051819972424691,1.1579925809434632,-0.7738231188388989,-3.3967031301108785,0.3968250105308599,-0.8624892804127531,-1.1203371931434885,False,c1,2,"Screenshot
See screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11809}",52241,-1,Unbreak Now!,True
-2.040542517687186,-1.8510945683932771,0.707824382873131,0.4482494061570155,2.7029227067075787,2.4014913438370735,-0.2706370011027248,-0.33791426800196234,4.721353430762551,-0.46326695677341245,0.4548038133078558,3.445532559972192,0.3542366968480435,-0.40153063989389004,1.1696795723412077,0.8168252798210858,-1.5036070263632928,-1.4627703768351257,False,c1,2,"Screenshot
I am unable to click ob the icon to open the image/caption dialog, see screenshot. Instead a cross to move the image is shown.
--------------------------
**Version**: unspecified
**Severity**: trivial
**Attached**: {F11665}",52159,-1,Unbreak Now!,True
-4.534640090865404,-4.700939740210595,3.5609723581551656,4.695072171619777,2.8161064541662846,0.13786820699911773,1.5680652537939332,2.3992743731239057,1.6090482681985967,-1.0445497670056558,-0.5408445327992992,2.225723551653001,0.3383978032526027,-2.410607410138513,0.4355399341961661,-1.7722176604509778,-0.41963986124856456,1.560809698462289,True,c1,2,"When using the control/command+k shortcut, and manually typing the text of the desired page to be linked, duplicate links are produced. See http://en.wikipedia.org/w/index.php?title=User:PEarley_%28WMF%29/sandbox&diff=prev&oldid=561424914
--------------------------
**Version**: unspecified
**Severity**: normal",52140,-1,Unbreak Now!,True
-2.741052438894422,-3.6525879840779236,4.247891527506752,1.2807710509605914,2.0368219883053023,4.297304394320452,3.588530797222016,2.268453795492801,-0.9014985165969965,0.949956092567489,1.2404351491882797,-0.9488904478616963,-0.17937261353735234,0.688605675225082,-1.4862263227852708,-0.8388864750757863,-0.7984314751170454,0.7138043396123741,False,c1,2,"When doing a simple test edit on https://en.wikipedia.org/wiki/Chloroplast?veaction=edit and then previewing the diff, several transclusions of the form {{expand section|..}} show up with dirty diffs. This is very likely a DOM corruption in the VE that disables selective serialization.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Chloroplast?veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50070",52129,-1,Unbreak Now!,True
6.624088847573118,-7.514931289390033,1.3999825937464045,2.1081804418630696,6.047006224977547,-1.2561736812833426,-3.1907607777718785,-1.7137345464040479,1.1852051093190061,4.273075320607514,0.2649074818470116,-2.707525791754803,-0.5853681648842421,-2.238402092063784,0.8068458032715382,-0.06457192184970023,-0.836289524937512,0.3718063129087208,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Dina_bint_%27Abdu%27l-Hamid&diff=561398396&oldid=561397974
I added a single letter (""therafter"" --> ""thereafter""). VisualEditor duplicated the categories and the default sort.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50385
https://bugzilla.wikimedia.org/show_bug.cgi?id=50332
https://bugzilla.wikimedia.org/show_bug.cgi?id=54169",52120,-1,Unbreak Now!,True
10.083474109138315,-14.292897410968582,-2.1528307839273726,-2.2540248956114732,-1.1997819828519658,4.194133243558186,1.2484564694555411,-0.14197194159138415,-1.5388783139584632,0.4634291947595299,2.3220506820332676,-1.5267207227224522,5.1866280737410335,2.6164410099165307,1.9016933663585167,-0.7015414171153425,0.30004481838084995,0.06905244415196887,False,c1,2,"Self-explanatory; Firefox 21.0, Windows 7.
--------------------------
**Version**: unspecified
**Severity**: major",52115,-1,Unbreak Now!,True
-1.8765918876130299,-4.217282595602345,0.1409782993668678,-2.399851985596941,1.49187395424801,-3.332714119325801,3.4233226897451585,0.48752282643129163,-1.7412405423385955,-0.7872270011155669,-1.438216933656263,1.7676384128235931,-0.9131121307104069,-0.32035638543373945,-1.583637662176256,-1.406403391166173,1.4007491628726132,1.3097100456259547,False,c1,2,"Not sure if this is something that's been nixed and nobody has told me, but: tracking bug for adding cite template support to the VE's referencing setup. They're pretty universally useful.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50768",52110,-1,Unbreak Now!,False
0.5098804859355486,-3.0113994307717658,2.800962047979578,-0.5155366670631109,2.0180025078035966,-0.7768508319816833,0.3765752259468531,-3.9445998815337537,-0.803235053264501,-1.758343931945186,-0.5956984881030309,4.12681809940547,0.9529968123217847,-2.222860333570084,-0.6670184026803669,-1.3355436068109987,-1.6592681802708684,-0.30165116777095435,False,c1,2,"Screenshot
See screenshot. Kiiinda worrying - if this is something a group of people > me is seeing it may be a blocker.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/wiki/Joe_Flacco?veaction=edit
**Attached**: {F11445}",52073,-1,Unbreak Now!,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,True,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: normal",52067,-2,Unbreak Now!,True
5.559434363420705,-7.240183570592045,-5.4229561909882165,-3.3720900453041556,-2.5710154240030896,-3.874968315026412,-6.411458536046284,3.17169917961257,-5.047493556815522,-5.149954960684058,9.2013612774189,-3.3242389057668547,-9.910625652211468,0.5428738616242734,0.04952739174913301,-0.8173967627234562,-1.7538132839164637,-0.041295213884538384,False,c1,2,"They get stripped out when rendered back to HTML.
e.g.
<ref>Foo<!--bar--></ref>
->
<ref>Foo</ref>
--------------------------
**Version**: unspecified
**Severity**: normal",52059,-2,Unbreak Now!,True
0.04527470316274895,-6.521983468992565,-2.583759078704139,0.5800413157475548,-1.3948467934119178,-1.4819817013638896,-2.639503475871821,0.6599348618047265,-1.456655876334175,-1.1725703053731,0.30192000992994705,-0.474723717730992,2.425941480739766,1.5606498933597068,0.6152817374468187,-1.6530556534031446,-1.3700777855807327,0.25191193661923195,False,c1,2,"Moved from #48830.
Merlijn van Deen 2013-06-23 11:20:36 UTC
----------------------------------------
https://www.mediawiki.org/w/index.php?title=Git%2FConversion%2Fpywikipedia&diff=714194&oldid=713893
The only real edit is at the bottom.
Krinkle 2013-06-23 11:25:31 UTC
-------------------------------
This is due to the merging of the 2 <b> tags. Currently it fails compare custom
attributes like ""style"" when attempting to merge equal annotation sequences.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48830",52050,-2,Unbreak Now!,True
-0.9489138072252059,-11.919940896604306,-4.283161355979919,-7.277544241505069,4.999318932520497,-1.3395061730668414,3.067152196535962,10.452641284940842,1.0845737892003198,0.8825688803504699,-0.7334922799075736,-0.020383300589109643,-1.0109106288893503,0.3735159597709625,0.22426814373805826,-1.574078094080505,1.5590324520515566,-2.592130119336573,True,c1,2,"This doesn't work; not quite sure why/how. Should be fixed.
--------------------------
**Version**: unspecified
**Severity**: major",51993,-2,Unbreak Now!,True
-6.215925157545853,1.0463771685806655,0.6852208589037723,0.9137637929842386,1.828636128029685,-0.17086551379561288,-5.623513028725003,0.377522064900742,-0.3936648943334473,1.4931634260698328,4.524727262247353,-0.6524611756667886,-1.425495460106296,0.7283517743049019,0.8986436228298285,-0.5247254168936806,-2.2021827684839446,-0.27192347785584325,False,c1,2,"Steps to reproduce:
1. Insert the cursor immediately after the first letter of a link
2. Hit delete/backspace
3. Type a new character
4. The new character isn't part of the link, so select the entire word and click the link button
5. Re-enter the link article
6. Save your changes
Expected result:
If you started with ""[[Porcupine]]"", you should end up with ""[[porcupine]]"".
Actual result:
If you started with ""[[Porcupine]]"", you end up with ""[[porcupine|p]][[Porcupine|orcupine]]"".
This is just a common use case demonstrating a more general bug. Namely, if you create a new link that subsumes an existing link, the existing link is preserved within the new link instead of being replaced.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50098",51985,-2,Unbreak Now!,True
4.154113902606172,6.949924502378028,1.3443190409806185,-0.9548211839107693,-7.777440875920506,3.1526401177554684,2.524276128635484,1.327085717551272,-1.7248698832400762,0.020455425555899076,-0.13233397561861882,0.7437386187539898,1.1586456575068773,1.7800324507511016,1.2246354560468893,0.8486923214091469,-0.3371518792397201,-0.6594031203760449,False,c1,2,"http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version shows that the version of VisualEditor on beta labs is from May 28. The version of Parsoid on beta labs shows no date.
It would be convenient to have VE/Parsoid available on beta labs as well as on test2wiki and mediawiki.org
--------------------------
**Version**: unspecified
**Severity**: critical
**Whiteboard**: rmqa-2013",51846,-2,Unbreak Now!,False
3.736388007881281,3.407919773474358,1.1589173395337227,2.6046610509256194,-0.5391795755448792,6.084599638118171,-3.3006539881271895,-1.6213455171948423,-0.20277166357366333,1.36302072314058,-2.272057674327335,-1.4393079097443002,-0.20661399701255156,-0.7342946710319849,-1.4226981856072154,0.7439868719640352,-1.3925129345697909,0.4242135273593648,False,c1,2,"In this edit: https://fr.wikipedia.org/w/index.php?diff=94100781 VisualEditor seems to have emptied a reference (the one containing ""Maxime Pargaud"" as author of the cited reference).
--------------------------
**Version**: unspecified
**Severity**: normal",51828,-2,Unbreak Now!,True
-3.7652209374260552,1.0913481329732182,10.010032061159926,2.5080066261074974,-9.037116533483866,3.1926371996934053,0.2839875094334756,-0.21159261556062398,2.2192288493712917,0.5617665345952263,1.071887565684571,-0.8407922802207686,2.64130469768354,0.7197199694784047,0.9001311581181417,-0.09566697409899233,0.9653523753362239,-1.9569826619193957,False,c1,2,"See https://en.wikipedia.org/wiki/User:Mdennis_%28WMF%29/sandbox for the result of four different attempts to insert images. Each one resulted in something like https://en.wikipedia.org/w/index.php?title=User%3AMdennis_%28WMF%29%2Fsandbox&diff=560491469&oldid=560491343
--------------------------
**Version**: unspecified
**Severity**: normal",51763,-2,Unbreak Now!,True
2.412128624925366,-16.959765250364036,3.8734178164902353,2.0645510978340043,-2.0320540649073333,3.0306175551290853,5.235389208997927,-1.4391340410100049,0.6232125295312069,1.3830397040905495,0.85978318546299,-0.6635763096340714,-1.1633477032329944,-0.011350188389093852,0.5331305553380874,-0.5160785717085714,0.2982228827735709,-0.05478655315618952,False,c1,2,"https://en.wikipedia.org/w/index.php?title=McIntosh_%28apple%29&diff=560394609&oldid=560264020
--------------------------
**Version**: unspecified
**Severity**: normal",51737,-2,Unbreak Now!,True
0.20741251376410874,-3.2904097683803766,-1.070600565068295,1.8718316415413954,3.4377507361321142,0.3171216064092617,-2.2507918459224063,0.051274027767841346,-0.3963523354851802,4.096608923688544,2.940138321439439,1.6893128504334458,-2.8985782288298285,0.5269716540107758,0.3116872451992405,1.0985761678568813,3.2361579075461124,0.7238356987069718,True,c1,2,"Have a page with a <references /> block but no <ref>s and you get:
| Uncaught TypeError: Cannot call method 'connect' of null
This is bad.
--------------------------
**Version**: unspecified
**Severity**: normal",51668,-2,Unbreak Now!,True
-2.96104082065291,-6.161940359271268,-3.5383950687914734,0.9999656573290872,-0.14926017872823943,0.44817425743006134,1.3049355420600337,1.553514069947688,-0.6832573812829073,1.142468469424447,-0.28089269126473226,-0.08669998901403253,0.774059824916491,-1.6338589161545336,-1.0612365833464485,0.15414405343221116,-0.3751583428310934,-0.8524081168911848,True,c1,2,"https://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.
However, this bug is specifically about the HTML comments that are dropped, ""the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map"" and ""the position of the pushpin label: left, right, top, bottom, none"". These comments often have important messages to other editors, so they can not be stripped.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49603
https://bugzilla.wikimedia.org/show_bug.cgi?id=49655",51608,-3,Unbreak Now!,True
1.6815837666731448,-8.76301021685883,4.073179562978289,1.7161989740943828,2.2493772851010134,-0.12547673733699738,0.8009457616622431,2.3138898730431703,-1.4740930353380595,-0.47002083751440527,3.3021769890284047,1.389846268973242,-1.3475019456936925,-0.7267190740119824,-1.0971316351134934,-1.0002980086327822,-0.8858558336194794,-0.01650104967882271,False,c1,2,"Adding a file/media fails with wrong wikicode.
This wikicode is created, see URL:
[[undefined|link=https://commons.wikimedia.org/wiki/File:CV.03326.jpg|right|framed|424x275px]]
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174461&oldid=174460",51596,-3,Unbreak Now!,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,True,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: normal",51586,-3,Unbreak Now!,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,True,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: normal",51585,-3,Unbreak Now!,True
8.863106752607738,-2.3631173394395866,1.0698622452063589,0.691375814426769,2.5260955294881398,3.146628475827475,0.9949205072797369,-3.4685426908999597,1.401380604616253,-1.5163458055141263,-1.146228497677903,0.8415535226339765,-0.858771457589218,-1.513397073362162,0.44338244227809565,-0.6168232483196469,2.3152693504242015,0.00012531145065297622,False,c1,2,"I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532
--------------------------
**Version**: unspecified
**Severity**: critical",51577,-3,Unbreak Now!,True
-0.07684653397582553,-14.857879955106895,1.550554744563435,3.829098031247441,-1.5519345123534758,-0.14865979073037083,3.2526637038105983,0.21112841517755765,3.0587840463105387,0.4263949893008565,0.18007881919063973,2.8318935605001165,-0.21291674365989088,-1.891948987528767,1.951073723061099,-0.01685807157962138,0.04337087947327256,-0.3329927976325726,True,c1,2,"Should be user interface language.
--------------------------
**Version**: unspecified
**Severity**: major",51403,-3,Unbreak Now!,True
-1.0662629094251086,1.8312379403524695,-2.98695815827422,0.07621407975194994,3.6510696318348326,2.21119890376431,-2.0326166957609764,-0.5949608907879453,-1.4751665488254595,4.904055140634425,-0.21053569605134692,-0.7622298582000149,1.096118709801725,-0.5612545348912379,-0.7498390849208105,0.11074332363771575,-1.1905364478702667,0.23925586016006828,True,c1,2,"This is to restore the pre-December save workflow (Save dialog triggered, with Show Changes within it).
The ""Review and Save"" button in the toolbar will be replaced with ""Save..."" which takes you straight to the Save dialog (with the existing save box, minor edit, watch and disclaimer/legal)
Inside the Save dialog there should also be a ""Review changes"" button that triggers the wikitext diff as a dismissible dialog; whilst we're here, remove the Parsoid ""Something looks wrong"" button entirely, and replace the ""Looks good to me"" button with a normal close one.
--------------------------
**Version**: unspecified
**Severity**: normal",51258,-4,Unbreak Now!,True
3.7888186645225956,-14.531628033185378,6.966925116847854,0.8356368130575007,-0.01637728879314837,-1.7766989071818293,1.5560310105085895,1.08854089981967,2.6407988397631224,-0.242923702933469,-0.23455238613833762,-0.10098495168338228,0.3300446469345979,-0.8714507916793739,-1.2205249429234346,0.23827908424776295,-0.9010949716789504,-0.9667235353350612,True,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://pl.wikipedia.org/w/index.php?title=Ukryta_sie%C4%87&diff=36500666&oldid=36500549
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50720",50769,-6,Unbreak Now!,True
-5.8338636636155305,2.8693889640084684,-0.7437302572686377,2.250763398164579,1.3108384977052936,2.849927514837929,-3.3191070720322595,-1.5131304600144184,0.5460380487110679,-2.088894140056966,0.6878688950406726,-1.057091126565746,4.074751318685358,2.462997234236279,-0.6748943740766942,2.4627250102316416,-0.4221580229587236,0.31656485344557583,False,c1,1,"1. Create a page that has a heading at the very beginning
2. Open it in VE
3. Put the cursor at the beginning of the heading and press Enter
4. An empty heading appears above
5. Use arrow keys or mouse to move the cursor into this empty heading
6. See an error in the console
7. Type into the heading
8. See one error per key press in the console
In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.
--------------------------
**Version**: unspecified
**Severity**: normal",50526,-7,Unbreak Now!,True
-0.8836282683870347,-2.920087855448493,1.6946041401340537,4.279581185775669,2.7088087775200953,0.0753398564850809,-1.968267266113199,2.376379731126914,1.4737741933603208,2.199256783406196,2.365122974338948,1.5587660405159902,0.43623138252138993,2.544090251576124,0.1146560741717586,0.9884615073840094,-2.059182827810133,0.6600875705066536,False,c1,1,"1. Create a link using the link inspector button
2. Note that autocomplete feature doesn't appear
3. Hit save and note that link is stored as an external link ""[Foo Foo]""
Using the keyboard shortcut, however, works fine (Ctrl+K)
--------------------------
**Version**: unspecified
**Severity**: normal",50509,-7,Unbreak Now!,True
-5.915366891227981,6.765861015093968,1.0885386976680493,0.26557939676572895,2.7621371300904247,5.206194171546487,-3.5957093157333,-0.7225575399452622,-0.43177705047256404,-0.27194572754588187,2.0890748881204257,2.4937723949441537,1.4576150675700337,1.268384427513844,-1.66659928188643,0.11293590091368055,-0.640173308954075,-0.2720591801225629,False,c1,1,"1. Go to a page with a bullet or a numbered list. Edit with VisualEditor.
2. Place the cursor at the end of an item of the list. Press enter to create a new item. A new item has been created and the cursor is at the beginning, ready to receive input.
3. Type something.
EXPECTED
You are typing in the new line.
ACTUAL OUTCOME
A pawn appears at the end of the previous line and there you can also find the text you are typing. If you press Enter again the mess continues to grow. There is no way to clean the scene of the crime. The only way is to jump to ""Edit source"".
This happens at least at mediawiki.org with Firefox 22.0a2 (2013-05-07).
--------------------------
**Version**: unspecified
**Severity**: major",50468,-7,Unbreak Now!,True
6.159255885879688,-4.642619670003498,-1.4968797330616255,-7.6083304094154585,-4.090176482125811,0.7799486783937872,3.1051211910722616,1.1241960996604656,-1.0813059560317537,-0.8816471928732632,-0.9755689543809596,-5.207126944406953,-1.1813535388821794,-1.148105380445541,-0.022445213321234725,-0.48705730478138487,-1.9216389932168076,1.4337158661628913,True,c1,1,"Problems in IndentationAction that Ed it working on right now.
--------------------------
**Version**: unspecified
**Severity**: major",50390,-8,Unbreak Now!,True
0.9779209876811072,-17.869166481801205,-5.220754588238712,-2.573724832943941,-2.045751787897381,5.8621589869513695,3.033069990764658,-0.648528092627419,0.16008604090139456,0.564840665060971,0.4596904707659095,-1.2988538271834809,-0.15728522491547636,-0.4199638258141576,-0.5806607910693229,-0.49505974882820913,0.07376598578385929,-0.2870253615057923,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: critical",50386,-8,Unbreak Now!,True
-4.56520348851333,-0.5341932419376416,-3.8729853934223417,2.6922254750456545,1.580250999625394,0.3365730982277977,-2.693351690160584,0.9041087955184214,-0.9758881976443842,-1.3131024994679907,0.12443178533288757,-1.4591288268052374,-1.0352577096062312,-0.35865327901374755,-2.8896612154166177,-0.16545766716355387,-0.5532451694630359,0.4021983499674404,False,c1,1,"* Create a page starting with a list ('* list' is sufficient)
* Enter some text into the slugged paragraph above the list, then delete it with backspaces
* The paragraph now doubles in height, inspecting the DOM you see a <br> has appeared from nowhere:
<p><br><span slug></span></p>
Also this paragraph gets sent to Parsoid resulting in an extra line break.
Removing the text by using undo doesn't result in this bug.
--------------------------
**Version**: unspecified
**Severity**: normal",50385,-8,Unbreak Now!,True
-2.358187027513476,8.8217264848927,3.4105118296358263,-0.011684454432790092,0.9904652350819612,1.5836410146790942,0.8627282349743544,-3.0758775494310746,-1.7635701524931389,-1.0005921946888097,1.209137259207862,-3.222775810837816,1.404196550937721,-0.6600805893588024,2.207767855114093,-0.603355674836531,-0.11997511025223306,-0.14983861698517442,False,c1,1,"Lately, I've been noticing random pawn characters at the end of paragraphs all over English Wikipedia. The source of these pawns was a mystery to me until I tried using the Visual Editor today. As soon as I started typing in the editor, it inserted a pawn at the end of the line I was editing.
The pawn in question is the white pawn, typically the first piece to move in a game of chess. This makes me wonder if perhaps the visual editor has become sentient and is trying to initiate a friendly game with the editor. Unfortunately, playing chess on Wikipedia was banned in 2006 as a violation of WP:NOT,[1] so it's probably a good idea if we eliminate this sort of behavior.
Actual character: ♙
Unicode value: 2659
UTF-8 value: E2 99 99
Browser: Firefox
1. https://en.wikipedia.org/wiki/Wikipedia:Miscellany_for_deletion/Wikipedia:Chess_championship
--------------------------
**Version**: unspecified
**Severity**: critical",50346,-8,Unbreak Now!,True
20.24306698867508,-0.6917756522957745,8.803288074875766,-2.534718969023049,0.3734811255414262,1.2756419815221183,-4.148283119915671,0.6588077223646795,0.7366293234109915,3.5743898102823994,-2.2581668229709058,0.30862801544506757,0.6007259784809587,0.8045866758453482,0.2419427081222283,1.1506570710282715,-1.3932642070358903,0.4513392615584457,False,c1,1,"Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type ""Enter"" 2 times.
Type ""Up"".
Click Bullet List
Type Enter
Type Up
Type Delete
Wild pawn appears.
--------------------------
**Version**: unspecified
**Severity**: normal",50287,-8,Unbreak Now!,True
24.448877636478347,-0.5567143378171,7.242308961673146,-1.798470023822186,1.1508023911855507,1.7840605636665428,-4.618333321767853,-0.21950479594869332,0.7241512960971508,5.27155124017939,-2.6967869732309433,0.042042688515296245,-0.11617413931845366,-0.20872683207362286,0.2900429886046938,0.3900787647283041,-1.5151831416921018,0.5015146488475237,False,c1,1,"Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type ""Enter"" 2 times.
Type ""Up"".
Type ""Delete"".
Click Bullet List
Type q
Type Left
Type Enter
Type Up
Type Delete
Wild pawn appears.
--------------------------
**Version**: unspecified
**Severity**: normal",50286,-8,Unbreak Now!,True
6.114870697553091,-5.530426730081889,1.7396020787817683,-5.463044660683091,3.0779933962917543,-1.4053466377682595,-5.776347667026401,0.2985276101343083,2.0093364953808104,0.6067037223552214,2.3809199122151816,1.3585663864992161,1.5164500245095849,2.444106359670953,1.7774327035254744,1.413985736979419,2.2152462469332583,1.802316070820882,False,c1,1,"1. Open http://en.wikipedia.org/wiki/Enterprise_content_management
2. Add a space and remove it
3. Press ""Review and Save""
4. Wait forever.
The text stays greyed out and nothing changes. Changes can't be saved.
Same for any article I tried.
Ubuntu 2012.10, Firefox 20.0
--------------------------
**Version**: unspecified
**Severity**: blocker",50193,-8,Unbreak Now!,True
-9.556911846999826,0.9613305930232077,-3.2350163471972397,2.7524819611826588,3.795521962071494,1.4697902108265846,-0.6039947755146304,1.6264841014960312,0.40364883119662665,-1.1985164216103805,-1.5835220243404264,1.5843917094969033,0.07053676350771454,-1.3174208991129404,-0.17369111836548345,1.1552071895556657,0.5018927542225915,-0.14263727745731614,False,c1,1,"Multiple list items don't indent properly.
Steps to duplicate the bug:
Write a couple of lines. Mark all the lines and click the ""list"" button - producing bullet-list.
If the indent button is clicked when the cursor is on a single list item, that item will be indented. However, if you mark a couple of list items and indent them at once, the indentation is jumbled: some of the items are indented and some double-indented (and the item above the selection seems to be indented as well)
--------------------------
**Version**: unspecified
**Severity**: normal",50069,-9,Unbreak Now!,True
-2.4480151016694,-2.695938162227881,-2.2956375162143576,-0.5490618251106846,-1.2192330278834842,-1.2654487014500642,-2.3327884299324726,-1.9181859922000717,1.7562296289685049,-0.8846306069943375,0.7901615904019015,0.7712097080863931,3.040361063198443,-0.25605663462959516,0.5493133296792161,-0.31159596474240026,-0.7687161254735256,-2.1654128787507405,False,c1,1,"*that* was an amusing bug to find.
Tested on mediawiki.org.
Steps:
1. Write text in an ordered list item
2. Select some of the text
3. Hit ""end""
Expected:
Cursor at end of line
Actual:
Cursor at end of line, text gone
I would *suspect* this is an easy bug, unmark it if it's not.
Found bug on Firefox 23 alpha 1
--------------------------
**Version**: unspecified
**Severity**: normal",50022,-9,Unbreak Now!,True
6.75832531400135,-15.033694493687026,-0.47715858446113835,-2.2369249609797173,-1.3264407556329,3.3176075462189036,1.0006126590744833,0.18765222255127262,2.7652455007020444,0.3110811802037574,1.0723828040308354,0.6910424242146187,2.5910910011306454,2.4608824043746056,0.7309464772352303,0.2644142921062248,-0.2784239160209716,-0.8182315067038342,False,c1,1,"See Parsoid bug 47998.
--------------------------
**Version**: unspecified
**Severity**: critical",50006,-9,Unbreak Now!,True
1.0424361052911624,-5.314805340375688,-3.904620113713369,3.798711810219256,-0.43906413130742583,-3.8341138946758164,-3.527471042211474,-1.718758877715719,-0.05194360965351197,0.8080163290294315,0.7886215203805391,1.2607921923677503,0.07982815655840092,-0.9393942770056176,0.04792964442201697,0.5197182910035014,-0.7381319613197312,-0.027865769192158663,False,c1,1,"Steps to reproduce problem:
1. Edit https://www.mediawiki.org/wiki/Git/Commit_message_guidelines in VisualEditor
2. Add some text
3. ""Review and save""
4. ""Something is wrong""
5. ""Report problem""
Expected behaviour:
Make an http request somewhere and report back in the UI.
Actual behaviour:
No http request is made and UI is unresponsive.
console:
> Uncaught TypeError: Converting circular structure to JSON
> at:
> > mw.Target.prototype.reportProblem = function(message) {
> > var ...., report = { title: .., oldid: .., .. };
> > $.post(mw.config.get('wgVisualEditorConfig').reportProblemURL, {'data': JSON.stringify(report)}, function() {
debug:
var objs = [];
JSON.stringify(a, function (k, v) {
var i;
if (v === Object(v)) {
i = objs.indexOf(v);
if (i !== -1) {
console.log('dupe at #' + i, v);
}
objs.push(v);
}
return v;
});
dupe at #66
<p data-parsoid=""{""dsr"":[0,139,0,0]}"">
""The ""
<b data-parsoid=""{""tsr"":[4,7],""dsr"":[4,24,3,3]}"">commit message</b>
"" play an important role in revision control systems. They are the first thing other people will see of your commit.""
</p>
--------------------------
**Version**: unspecified
**Severity**: critical",49948,-9,Unbreak Now!,True
-1.1119337395458389,-5.643397160926085,1.00147674148565,-11.000838828287778,8.171086959779004,-5.286579698058318,5.137647990589321,-4.634152494479551,-2.8260058791181226,1.765993930440957,1.2764064518012987,1.6967430599600164,-1.7744185513770097,2.5115716188639823,-0.9330163091542873,-1.5147061887374904,0.2654820804902991,-1.1959063803920802,True,c1,1,"Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm).
--------------------------
**Version**: unspecified
**Severity**: critical",49842,-9,Unbreak Now!,True
-4.315954736021298,-2.7826790302296303,-4.801153167500795,2.669270450088677,0.5702379291675697,4.029535338267212,-3.1592518100803084,0.7668383298930274,0.9489281042767126,-1.0253731045871475,3.1995439984049256,-1.6091363296455619,1.076884760528499,-0.35916319424497534,-0.9257431588486185,0.8103966742842663,-0.12836632238172085,-1.2929483987287562,False,c1,1,"1. Edit a page with an unordered list.
2. Delete all the text on the last line.
3. Press the <delete key>. The bullet should be erased. Instead, it will
remain and the cursor will move to the end of the previous line.
4. down-arrow
5. down-arrow off of the empty line.
Turd appears in the empty line.
Very many arrow-key actions will produce the turd.
Firefox 20.0, linux.
--------------------------
**Version**: unspecified
**Severity**: normal",49817,-9,Unbreak Now!,True
-0.9744738520277902,-7.3041358720364435,0.9020576190761247,-4.844999957184678,-2.0083908742025818,-2.0578725758966407,-0.5147690745491662,1.624308603872056,3.821384658075927,-0.26139342060654247,-0.4615798761427543,0.3545458672968669,1.3645960841418887,1.7474644096053993,-1.054152261106645,-1.2440336366777691,0.2821228366384365,-1.5777036750517541,True,c1,1,"jQuery have WONTFIX'ed this bug (13821) so we'll have to work around.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
http://bugs.jquery.com/ticket/13821",49737,-10,Unbreak Now!,True
-9.811557756844012,-0.5410099434706854,-5.734246502077632,0.4281921369199393,1.8640194362238502,6.5244279943298915,2.1092432327172235,3.5638808784487646,-3.031913622860557,3.9062878451295013,1.143523605588578,0.7335274259322857,0.38814477557169,-0.005469557253133139,-0.9822281253412823,1.1734916140680651,1.3282242903564454,0.9539148348384459,True,c1,1,"This has reappeared (in live on hewiki and others) - if the page on load has bold annotation on some text, pressing the ""bold"" button doesn't remove bold but adds a second bold annotation (which can be removed, but not in a way that stops the text being bold).
--------------------------
**Version**: unspecified
**Severity**: major",49680,-10,Unbreak Now!,True
-2.541215129550782,-4.530783695922246,1.2300861003068597,3.848436158419143,8.05353112982097,5.201516391355101,-0.9140506422750114,-3.0912132919923936,5.239636702889712,0.6592333376670192,0.987610954897058,0.18214461635075563,-0.1847133831803509,1.029462576110161,-0.7532893282412632,0.8608249328105736,0.1652844155180735,0.9261741105103083,False,c1,1,"Make a selection that includes the first character, and press the access key for creating a link (Ctrl+K?). You'll get a JS error.
--------------------------
**Version**: unspecified
**Severity**: normal",49623,-10,Unbreak Now!,True
-3.781379843495966,-10.382822114284599,-8.683831534897136,6.048390252716404,-0.977398178685092,-6.3851103326315855,-9.91018320332573,-0.5201528699667055,-2.722360378062234,8.746158649777623,-3.549167768565059,1.2424158858245546,-3.408253328814263,0.17641344506105838,-1.0842524216997562,-0.4344775269848442,2.3447920400489437,-2.571111439410944,False,c1,1,"As the title says. The bug seems to be in postHTML:
array(
'postData' => array( 'content' => $html ),
'timeout' => $wgVisualEditorParsoidTimeout,
'oldid' => $parserParams['oldid']
)
should be:
array(
'postData' => array( 'content' => $html,
'oldid' => $parserParams['oldid']),
'timeout' => $wgVisualEditorParsoidTimeout
)
--------------------------
**Version**: unspecified
**Severity**: normal",49434,-11,Unbreak Now!,True
2.323453120524999,1.0468179294252096,1.9315284092803182,0.5251169133172879,2.302435707630912,0.1757956801463476,-4.7228892063718835,-1.1258673685896365,1.3653117411048694,4.455536870455488,0.3601433734841475,-0.8908352211273513,1.1948142291186556,-0.40425548352650953,0.792369450805408,1.1052425316258123,-0.3258656186767077,1.55457901491307,False,c1,1,"The link tool showing ""undefined"" in step 5 of the bug report
1. Hit an article on English Wikipedia and click ""Edit"" to invoke Visual Editor. I used http://en.wikipedia.org/wiki/Savage%2C_Montana.
2. Double-click any word to highlight it. I used the first word of the ""History"" section, ""Savage"".
3. Click the Link Tool icon, and the tool pops up.
4. Choose any article title in the dropdown (I chose ""Savage Land"") and press Enter.
5. The dropdown closes, and in the tool's text input, instead of saying ""Savage Land,"" it says ""undefined."" (See screenshot to be uploaded.)
6. Now click outside the tool -- somewhere else on the article. The tool becomes completely blank (see second screenshot) and article text disappears.
--------------------------
**Version**: unspecified
**Severity**: critical
**Attached**: {F10425}",49413,-11,Unbreak Now!,True
6.5019370485126515,-3.698001492746352,7.591083883006629,5.7325497282820805,-1.5210214798448014,-3.740639562288777,3.687941431187501,0.3664221202198017,-0.5107961209991524,-3.6204724248502016,-5.2413443592804985,0.38185062475820786,-3.7977057695190704,0.005245974825746735,0.5835287643153615,-1.9242364628109616,0.4999865565020363,1.6869393326070588,False,c1,1,"Master is failing jenkins tests right now due to some JSDuck failures.
Examples: https://gerrit.wikimedia.org/49364 , https://gerrit.wikimedia.org/r/57922
--------------------------
**Version**: wmf-deployment
**Severity**: blocker",49018,-12,Unbreak Now!,True
-7.321885802000493,7.530280078019441,0.26014594816376757,0.9923457753154183,-6.313863048938865,4.755033071310018,-1.578220191695638,-3.903613030745546,3.2793334127859266,1.2720853004701667,-1.537697982501061,-2.4323640909753785,-0.7553880042791716,-0.3485005237548071,-0.6486893336457209,-1.058747635486917,-0.15761740873292363,2.17492496729826,True,c1,1,"In preparation for making the VisualEditor the ""default"" editor, we should have the existing integration switched over for users so that they can see, test and feedback on the final UX for triggering edits in the run-up to switch-over.
--------------------------
**Version**: unspecified
**Severity**: trivial",48872,-13,Unbreak Now!,True
-3.695243113082558,2.323812914174816,0.25011612380937365,-1.805568601311256,2.883935596116137,-2.156546555977595,1.1507903028442135,-0.737651039789949,-0.03796539747996913,-1.942907408989572,-0.380002175002784,-3.10481533312154,0.9196361597205147,-3.9183565855263236,0.4645774757770047,-2.7851528243964547,2.0885197779233495,1.0802397650779885,False,c1,1,"Aaron Schulz wrote:
I noticed that https://gerrit.wikimedia.org/r/#/c/33971/ passed the tests but after it was merged, the new tests started failing for everything. The commit to revert it also failed so I override Jenkins and merged anyway, and the failures went away for new commits. This indicates that something broken is going, possibly Jenkins running tests just against master rather than master + the patch, which would explain this problem.
--------------------------
**Version**: unspecified
**Severity**: normal",48723,-14,Unbreak Now!,False
-8.446014220119903,2.3673947178493684,-4.101438454277188,-2.323793853083964,3.0866375322941657,3.0769477045559475,-2.6623869957158646,1.6607010078594349,2.708403057011946,-1.2651613877957169,0.9421147864839683,0.9290256110737378,-1.365292411534531,1.730856226423823,-1.3202043011431925,0.6000970283530465,-0.17733006539500318,-1.3299297915299961,False,c1,1,"0. Open a document with links already in it.
1. Click on a MediaWiki link, then click the icon to open the inspector.
2. Click anywhere else in the document to lose focus.
3. You're link has now been removed :(
Note that this doesn't happen if you have just created a link, or if you have edited a link, so I assume this is functionality for letting people abandon the creation of a link.
The only way to remove a link should be with the delete icon in the inspector, or clear formatting.
This doesn't appear to affect external links.
--------------------------
**Version**: unspecified
**Severity**: normal",48025,-16,Unbreak Now!,True
-1.467844064131269,7.716583491604705,1.099506563294721,1.063254676277725,-4.30707609893652,5.423535340862895,-0.20454604095016737,2.0390650986257572,-1.2239358527600865,-0.47259851285669363,1.1588141735061277,-0.24262489444282787,-0.4739920060382987,-0.7078419915350738,-1.0245614201909685,-3.48418692815595,0.20259470247209732,-0.14966698315749283,True,c1,1,"The re-write of the node API that dm provide up to the rest of VE is necessary for most of the added support that VE is aiming to provide this year.
[Mostly done now.]
--------------------------
**Version**: unspecified
**Severity**: critical",47062,-20,Unbreak Now!,True
-4.444916197117573,-6.5996427595664855,-7.613571125464883,0.6300658442222631,0.3161087342489516,-2.125615178544399,-3.699292788331979,1.7472343771298964,-4.2762739967671415,0.8000124945729583,-2.861621852619285,1.6219612909786523,5.261657931887337,0.8343891446719995,2.301347200137151,0.7806712733956613,2.7397453010242705,2.214132356585848,False,c1,1,"**Author:** `phil`
**Description:**
visual editor after deleting lines 3 and 4 - note that 4 is still visible and the gap inbetween 2 and 4 is marked as 'cannot be edited'
I had text
1
2
3
4
selecting the last 2 lines ( 3 and 4 ) and deleting and saving, on looking at the page again '4' is visible and there is a gap that is marked as 'cannot be edited'
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10499}",46926,-20,Unbreak Now!,True
-0.5024301069595665,-6.024181358025993,1.8327058447151217,4.7249558039462976,1.2462704719035944,-2.40935830937564,-3.405776837577567,-1.6592872288402103,3.5242062082638084,4.087911072979919,-1.2988940741664714,0.1566012271714321,1.05461562077654,-1.2256296639844981,-0.7280155222432425,0.16290493822465998,0.6837236385963188,0.6113520377991721,False,c1,1,"**Author:** `phil`
**Description:**
error message on save after changing bullet format
Blank page
Add some text e.g. 'test' and make it a numbered bullet
Save the page
Edit the page
Remove the text 'test'
Click on the '1' and click the numbered bullet control to remove it
Save page
""Error loading data from server: Unsuccessful request: Error contacting the Parsoid server.""
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10836}",46687,-21,Unbreak Now!,True
-0.7730949589665426,-2.94407365512013,-1.7165508878374425,1.591100281804179,6.148592071347386,-1.864855365834934,-3.5100367196416338,2.036580979953467,-1.034065920307205,3.5808367070979266,-3.4078605632490397,0.7810537166226934,0.3657720779868878,-1.4206548073966916,0.2530671794626098,0.7259340493473727,-1.3609796274735524,5.320088273948977,True,c1,0,"Pressing backspace creating a slug then deletes again:
* Create a new page (or go to an existing one), and enter ""AB\nCD\nEF""
* Place the cursor down-page of ""F"" and press backspace; ""F"" is deleted correctly.
* Then press backspace again; ""E"" is deleted, as is the remaining slug, and the cursor moves us.
--------------------------
**Version**: unspecified
**Severity**: critical",44655,-30,Unbreak Now!,True
0.978698389898994,-17.87030840447756,-5.219350553128887,-2.57528116654891,-2.0435789281839716,5.860753879418819,3.0268900872052873,-0.6512663811995079,0.16230830206961455,0.5663839272797055,0.45979096968325317,-1.299343307635873,-0.15673968058057675,-0.4254804839054538,-0.5862718735158783,-0.48794828011230706,0.0694679201695978,-0.29366603853991413,True,c1,0,"
--------------------------
**Version**: unspecified
**Severity**: major",44654,-30,Unbreak Now!,True
-7.171062982996228,-4.0696090076661005,-0.20137241155923924,5.674796338039596,8.582293201305408,0.5985266752321052,2.6159611857474134,-0.7546471551239577,0.8966851696057612,-1.307338529137231,-0.291405432582188,0.21815648085545525,-1.0448447124678593,0.548993787630768,-0.25073284822097985,-0.783048744523213,-2.271699140179657,1.8302483547363273,True,c1,0,"A paragraph when changed to be a heading using the toolbar drop-down has its content deleted (but the presence still stays).
--------------------------
**Version**: unspecified
**Severity**: critical",44555,-31,Unbreak Now!,True
-1.3209264113549581,1.7844375277383229,-2.8182015346914238,1.7389679064531522,-2.780234830084538,2.576569771044973,-2.050888035873403,1.5259339874907978,-0.27775511864170305,0.46170663797094225,-1.6608859258010291,-2.4730128365692883,-0.37670672787975423,-0.9408861621278026,-2.1129395734957606,0.7201005766529232,-1.0717699717874312,1.578407640961981,True,c1,0,"Start with an article with an inline alien - e.g. ""ABC<tt>:-)</tt>DEF"". Place cursor ""up page"" (in LTR, left) of inline alien; selection with keyboard down-page works as expected. Now place the cursor ""down page"" (in LTR, right) of the inline alien; selection with keyboard up-page fails when reaching the alien, clearing the selection and placing the cursor immediately up-page of the alien.
Note that in RTL this appears to work fine(!).
Confirmed in both Chrome and Firefox.
--------------------------
**Version**: unspecified
**Severity**: normal",44401,-32,Unbreak Now!,True
-1.6039525645606523,2.1476506106713664,-0.6100560918071967,5.164899920536363,2.992052607210406,1.6794604779256102,1.8558062159901931,2.192993023292663,3.851841661866107,-0.6983144394112619,-0.5306551711928877,-4.537699724219523,-1.031122872292416,0.26469762662748675,-0.21789406884705542,-0.020332634381790615,1.0839892562652127,1.4494066258419795,False,c1,0,"Post-December cleanup:
Rather than passing the type, length, attributes and (soon) annotations into the dm.Node constructors separately, we should just pass a reference to the data element. This will make a lot of things cleaner, and make the constructors more consistent between node types.
--------------------------
**Version**: unspecified
**Severity**: normal",44400,-32,Unbreak Now!,True
-10.67231869775389,2.520585391394288,-3.6326395470713333,0.6187411450449691,2.2657784460326433,2.854677929273225,0.9704385931823634,-0.7691342489920048,2.311262429497871,-2.7074877299196536,-2.123678971828174,-2.543859714034687,-1.7286952310105024,0.12843088881807763,-0.9868002878702775,-2.6949846845152163,-1.7973436335942308,5.700046276572668,False,c1,0,"When editing an existing link, the link inspector should grab the existing annotation and edit it, rather than starting over with a brand new annotation.
Destroying the existing annotation loses metadata we need for preserving syntactical variation (hrefPrefix and origTitle), which means that currently, simply inspecting a link without actually changing its target can cause that link to be changed in the wikitext.
--------------------------
**Version**: unspecified
**Severity**: normal",44282,-32,Unbreak Now!,True
-2.1902778659098123,5.049994628436771,-3.9199442336854773,-1.5730852970729212,1.1550699552499455,0.011770309112979715,-4.975983980668882,-1.1848002091389849,-3.7943331184056266,0.1284621305971827,0.43206591949601814,-0.8623942296990045,-2.969471416857628,1.5640567397324832,-1.5806165786301016,-0.6237115750417417,-1.851204128598593,0.5665963604918762,False,c1,0,"Steps to reproduce:
1. Go to a nonexistent page
2. Click the Create tab
3. Type ""foobar""
Result: ""f"" appears on a line by itself, ""oobar"" appears on the next line. The document model only contains ""oobar"". The ""f"" jumps around when rerendering (e.g. when you press enter).
Can NOT be reproduced if:
* you use Chrome
* you click out of the editor and back into it before typing
* you press Ctrl+A, Backspace before typing text
The editor document looks like this:
<div contentEditable=""true""><p><span class=""slug""></span></p></div>
I think the cause of this bug is that Firefox initially puts the cursor before the <p>, rather than inside the <p> or inside the <span>.
--------------------------
**Version**: unspecified
**Severity**: normal",44277,-32,Unbreak Now!,True
-1.233384501499247,-10.407867801511182,0.06280887369487687,-4.131511153926779,-1.3790972063218652,3.711691809775475,6.444202926041785,-3.7542799551310795,-3.614036908066618,5.634774458416038,6.421935913606568,-0.6790156997036413,3.500175336916005,2.8724177376234445,0.4357039116528325,-2.137998524673533,2.907268982884581,-1.8734145472033352,True,c1,0,"Taken from bug 42117 which I'm de-prioritising
--------------------------
**Version**: unspecified
**Severity**: critical",44221,-33,Unbreak Now!,True
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,0,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",44172,-33,Unbreak Now!,True
-6.833157023521769,-4.662371535652182,-7.756131340019145,-5.852091693548282,5.684106873148423,1.401590959474334,3.0449547792143337,1.4550719035782214,-1.920577466790501,-1.6949196816402394,-2.0814551920953654,-0.023340714916447958,-2.4526759689407944,0.4557644085752619,1.3568286695293832,-0.008450896428932653,-0.06398813845097973,-1.8360093520820018,False,c1,0,"Comments should be stored in the meta-linmod, right now they're just ignored, which leads to all comments being removed when we save a page.
--------------------------
**Version**: unspecified
**Severity**: normal",44124,-33,Unbreak Now!,True
-1.5901197632009703,-11.903386855489208,-6.284025081636026,-5.767542335209153,5.970863031633542,5.8699558071440965,4.111942906495659,5.013382736141806,-7.004647819907062,-0.7547807623342688,0.045222116789207956,8.357392192465635,0.6850773077828185,-4.905851335249841,4.25317247511435,-2.121036077107931,0.7164700860215445,-2.028942735425679,False,c1,0,"Currently these are being alienated, which is bad.
--------------------------
**Version**: unspecified
**Severity**: normal",44118,-33,Unbreak Now!,True
9.562779085016631,-13.318827108704644,-3.411959459291886,-1.5507001139225245,-0.41319948686420793,3.292439739863731,2.269292078961082,-2.088999011321572,-0.34034475624010885,-2.246982410672502,-3.53073305396742,1.4462418836837305,-2.8554824743750977,1.7781285358810495,-1.205958365324352,0.26809206423447624,0.01942067686807869,0.372254929657293,False,c1,3,"http://git.wikimedia.org/summary/?r=VisualEditor/core.git
Seems unneeded.
--------------------------
**Version**: wmf-deployment
**Severity**: minor",56813,13,Needs Triage,False
-3.8540307955159907,0.6880958493125853,-0.4274965727954907,-0.48317541876244885,2.3025137759671175,0.584917801492806,0.7577418300980456,-3.1762148469361997,-1.1708374217411968,-0.9956038680273256,0.38532161080314076,0.207179000893152,1.4168196030395404,0.5348074160513079,-1.2529072174892537,0.05139892675619412,0.4322264878168758,0.003359767933033053,False,c1,3,"Hi
Just like the title, if I edit the body of the text, at every newline it enters an ♙ character, and I have to manually delete every time (by writig, going back and deleting).
Also there are many other special characters displayed, like arrows for tab and return. Don't know if it's the same issue.
The wiki is hosted on a CentOS 6.4 box, running latest versions of apache and PHP, under a virtualhost. The client is an OSX 10.9 computer.
Please tell me if you need any additional information.
Thank you.
--------------------------
**Version**: unspecified
**Severity**: normal
**Platform**: Macintosh",56785,13,Needs Triage,True
4.984344757338075,-4.5248341877943155,6.045265537801811,-3.198128865754324,-2.5755172100835333,-3.9572988226747894,-0.5640704865141339,-0.6086605976421546,1.796041133318173,-1.5639799977875524,-0.3398884305869885,-1.1533609606985642,0.32547314369941827,-0.6599193400493633,-1.1976605617649305,-1.5374512381496102,-0.14664376556576286,0.7815298489396396,False,c1,3,"Inserting media with VE
Sometimes I cant add image, because it doesnt display. This time at https://cs.wikipedia.org/wiki/Seznam_památných_stromů_v_okrese_Rokycany
adding File:Kařízský dub, pohled.jpg with FF 23.0.1
--------------------------
**Version**: unspecified
**Severity**: major
**Whiteboard**: cirrus-fixed
**Attached**: {F12341}",56777,13,Needs Triage,False
-10.515886574003511,8.212667069753433,1.6051455362131328,2.5292078149784887,4.077390389254942,8.10238809478583,0.7253781760339892,-1.6066648101789096,0.9177038920569542,1.0756793138123335,1.0835832549601911,-1.5118966363112833,-0.538036201456598,1.1458046102222452,0.29469514396279894,0.14864397783073455,-1.02715816614766,-0.3214238118425239,False,c1,3,"When you want to drag an element to the very bottom of the content editable area, the last position available for the cursor is the end of the last sentence.
Usually you want to place elements not at the end of a line, but right after, in a new line. The behavior expected would be to see a new empty line appearing when you drag an element until the end of a page, and the possibility to drop your element in that empty line.
Tested with the {{Languages}} template at https://www.mediawiki.org/wiki/Groups
The last cursor position possible is at the end of the sentence: ""... to create your MediaWiki group."" Dropping the template after the last dot puts it at the end of the page, in a new line. The end result is correct, but the behavior is unituitive.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51666",56756,12,Needs Triage,False
-5.020756061593941,8.777030911207593,2.044378344442933,0.865849556487873,-3.7278880365482587,0.7308039901286556,3.0558851604079136,-5.613390538104514,-2.456883029091167,-1.1480140212188639,-0.8421653729289025,-1.6357495544584562,-1.5786160580812059,0.3036284261285802,-0.15833625920783057,3.500326480789605,0.8899473552421535,-0.40948303165903654,False,c1,3,"As user Selenium_user on beta labs enwiki, I have set my preference to opt-in to VisualEditor several times, but the preference then gets reset to default (opt-in not set) after a period of some hours.
This causes failures in the browser tests and I wonder if it is a risk in the production environment.
--------------------------
**Version**: unspecified
**Severity**: major",56671,12,Needs Triage,False
-4.071276701054999,4.239567368816161,-0.33898551500703356,-3.470112513077117,3.7231803043308234,-3.1129023685078945,-2.5123326514513153,-4.391043752889751,-0.9949712929622143,-0.3930431859687449,3.5648598189475105,-2.467656078383534,-0.69963339554028,-2.196682072889089,1.5758906856428476,-1.4326423004044264,1.575154655615956,-1.0911359089684836,True,c1,3,"Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 :
<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>
The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:
<<About half of the 18 references I typed into the article on Homesickness disappeared between yesterday and today. I was certain to follow the Save Changes procedure, but many different references reverted to the same single reference. [...] Same bug today. In VE, I placed the cursor in the text, chose ""Reference"" from the ""More"" menu, added a reference, (It appeared as it should with the appropriate numerical superscript), Saved the work, returned to check the page...references disappeared from the list. - Window 8, Chrome >>.
TeamGale adds:
<<Hello...I have the same problem [...]. I didn't realized that it happened while I was editing. I only saw it when I saved the article and the number of the references had decreased. This https://en.wikipedia.org/w/index.php?title=Michael_Giannatos&diff=next&oldid=573583391 is the change I was doing when it happened. Could it be related to editing a table with beta? Probably not since I don't see any table on Christopher Thurber's article. After I re-added the references and the new table, every time I click ""edit beta"" the refs are gone! Before I even do any change! Basically I can't use beta at all on this article! I don't have any issues using the source but, if it's something simple that can be done with beta, I prefer to do it with it. But I can't. Just wanted to say that this is happening to other articles as well. And it's possible to happen and people don't see it. That would be a problem to a long article with lots of references... Mozilla 21, Windows 8.>>
TeamGale again:
<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...]
Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>>
I think I saw this renumbering issue at it.wp as well.
--------------------------
**Version**: unspecified
**Severity**: normal",56654,12,Needs Triage,True
0.7357851638230386,-3.5728139688074805,1.2735835430648699,-4.028151348444091,-1.2307511357744487,-2.0125927361843914,-0.4920356346155472,2.0113023531259544,0.0821658507696918,-2.0137790597267053,-1.337185602058268,-2.353988142406437,-2.755684363144253,2.735857823679611,-0.6185424870269554,-0.7102308963039123,4.302122701315872,1.5320748636240273,False,c1,3,"After successfully section-editing <https://en.wikipedia.org/w/index.php?title=Black_Mail_%281973_film%29§ion=2&veaction=edit> using VisualEditor, I land at <https://en.wikipedia.org/w/index.php?title=Black_Mail_%281973_film%29§ion=2>.
This shouldn't happen. §ion=2 doesn't do anything with the implicit &action=view.
Possibly related to bug 53089.
--------------------------
**Version**: unspecified
**Severity**: normal",56645,12,Needs Triage,False
-3.481580176025371,-0.9046650403903183,-0.05091264215304747,4.580856081947084,2.995845304242099,3.1089732918148183,-3.598502355915241,0.3343251874025728,1.1803124188187317,0.3943203545349192,-0.8352609072186246,-0.4781242985252696,1.441927171806296,-0.5686640610535418,-1.1626688574655173,-0.5725026020886517,-0.20273498647945676,-0.04107927453676474,False,c1,3,"When an image caption on the first line of a page contains the string ""page "" (including the trailing space) followed by any text the right half of the VisualEditor toolbar disappears (everything right of ""more""). This includes the save button so edits cannot be saved (hence the ""major"" severity)
This is likely related to either bug 54379 (same symptoms) or bug 53312 (same trigger).
Comments on the VE/F report at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=574608525#Odd_one suggest this might be restricted to FireFox.
Minimal test: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=574608905
Real-world example: https://en.wikipedia.org/w/index.php?title=Clarke,_Irwin_%26_Company&oldid=574526057
To reproduce:
1. Create a page with any image on the first line of page
2. Give the image a caption containing the string ""page "" (including the trailing space) followed by any text.
3. Save the page
4. Load the page in VE and observe the right half of the editing toolbar.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53312
https://bugzilla.wikimedia.org/show_bug.cgi?id=54379",56642,12,Needs Triage,False
-0.4809752279124231,-10.622707556401465,-5.161820744743107,-11.608575413441255,-1.5116527182330275,-0.0052416322798991555,3.6412269830323547,-9.404568813686465,-1.1774772277013756,1.840873505921393,1.622117625650414,-1.183538375224491,-0.7578269258922612,0.8300050781400818,-0.4017074775827343,0.2959811769027938,1.443329837988747,-1.4046675121391763,False,c1,3,"'coz I likes it.
--------------------------
**Version**: unspecified
**Severity**: normal",56636,12,Needs Triage,True
-3.0780513185757576,-0.846526661442315,2.0766683991948156,5.736788276798587,-0.3172034432046694,0.9685859512792441,-1.7918943864158141,-0.15553998965251808,1.1714628868176313,0.9989668755934753,-1.3428793670795884,0.2790081474313495,1.123472170116092,0.6691573837483018,-2.2687980730305535,3.4780966701464346,-1.3914661735048368,-1.852178078883658,False,c1,3,"subhead shows ""2"" in the wrong place
seen in Firefox not in Chrome:
choose some text and pick a headings format. Subheads with numbers show the number below the selectbox. see screen shot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12017}",56614,12,Needs Triage,False
2.9331095871048434,-9.884664976736893,-4.554939279517869,-0.0197572144226712,2.148830882131503,-5.5056905002305845,4.887674766859111,1.2254761235752487,0.5958411006996819,0.754307526869713,-0.6248696895548287,0.6913877651280254,-1.7168639787450113,2.3368815345923455,-2.0221966587868496,0.6751384636421549,1.147190810484487,-1.1565850162294389,False,c1,3,"visualeditor browser tests don't use MEDIAWIKI_PASSWORD, they still use secret.yaml.
--------------------------
**Version**: unspecified
**Severity**: normal",56600,12,Needs Triage,False
-2.5208138806183022,0.35775652297711247,-2.7441849793053947,-1.9107688156796667,-0.9178015844543801,0.15024310777805439,-3.604928587159252,2.6825206849999654,4.265907486522716,-0.4117750114066876,1.594290202564315,0.8691348422290013,-3.1144341241126705,0.5067927185236751,-0.229755264606891,-0.22366889144566815,1.8186345337767313,3.3253991567668493,False,c1,3,"If you click to use LaTeX, the ""math editor"" option, you cannot cancel or escape out of input. VisualEditor adds the <math></math> tags regardless and this can only be removed by saving and going to source.
Ideally, a cancel [X] or keyboard options should work to remove this.
https://www.mediawiki.org/w/index.php?title=User:Keegan_(WMF)/sandbox&action=history
--------------------------
**Version**: unspecified
**Severity**: normal",56591,12,Needs Triage,False
-0.5031915667901043,3.1288843230050283,1.170656355499684,-0.9851987908429929,-1.742168184506376,0.9363159676585953,3.2942742562641714,-3.0258797709149543,-1.44257773795719,0.44969551461849466,1.5122612815749599,0.6851503772253034,0.42914031798604046,-0.744074984456125,-0.057901891775818726,0.658186212482851,0.261663261286752,1.0027544595630131,False,c1,3,"Sikuli ( http://www.sikuli.org ) is a tool for testing desktop interactions, such as mouse clicks and keyboard typing.
This tool is needed for testing typing in different languages, because the usual WebDriver tests are not able to generate proper keyboard events that completely emulate typing in advanced input methods for Japanese, Chinese and Indic scripts. We have many bugs in this area in the VisualEditor (e.g. Bug 52716), so we need proper regression testing.
This week I worked with Željko in the WMF office and we built a prototype test that uses Sikuli to test typing in Japanese:
https://gerrit.wikimedia.org/r/#/c/83966/
This works on Željko's laptop. The next step is to get it working on the virtual clients that run our continuous integration tests.
Thank you!
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",56393,11,Needs Triage,False
-1.3388061418044044,-0.9813139455569093,-9.361807751693098,-6.228556617251636,-5.278279029858847,-2.5351162973874013,-3.3505986497070657,1.5648723956066157,-2.573830527678397,-0.38399993546488886,0.9264122935178052,0.3134216023127545,-1.7247403171831168,-1.2947892340650822,-2.0013048535306353,0.21750834027972973,-0.011205316086716266,1.0415748665645863,True,c1,3,"VE allows editing text between <pre>...</pre> tags.
That is, you seem to be able, for example, to add working wikilinks and references. Once you save though, everything is rendered as wikicode, as in [[France]] and <ref>France</ref>, and of course is not clickable.
Thryduulf argues that ""VE shouldn't show it as working if it won't work after saving"".
--------------------------
**Version**: unspecified
**Severity**: normal",56382,11,Needs Triage,False
10.614999183600172,7.777830228714588,3.0693733432647186,-5.682601886302663,-1.855145922903588,0.7265742385869474,1.1601279291645064,1.0663832346976503,-3.5267859351360737,-1.1539490055629456,-0.7343855607863583,0.6107236232006394,0.2480851054799702,-0.5544299847762701,-0.1949793280597527,4.8178047370541055,-0.6202771566099632,-0.5357292708224006,False,c1,3,"In some templates (e.g. Template:Infobox fornminne) on Swedish Wikipedia, the image in it is shown in full size when you enter VE.
Article: https://sv.wikipedia.org/wiki/S%C3%B6dermanlands_runinskrifter_305
Screencast: https://dl.dropboxusercontent.com/u/8363895/out-8.ogv
It does not behave like that for all templates though. In an article with Template:Kommunfakta is seems to work fine. E.g. https://sv.wikipedia.org/wiki/Botkyrka_kommun
Behaviour is observed from two different users and in both Firefox and Chromium.
--------------------------
**Version**: unspecified
**Severity**: major",56371,11,Needs Triage,False
-6.5794137131880674,0.5125829534751194,-2.7074276854425605,1.6513763985225065,4.638669477620027,-4.835516394639738,-1.6371044518610267,-1.5154319327297636,-3.467851630465719,3.8724189464848315,-0.5919694792949715,-2.3009298458142258,-1.0939157048850738,2.5898251148130678,0.7560346328558865,0.285526306309293,-2.139380740760967,1.245843315871453,True,c1,3,"<<[...] When you edit an old version of a page, you get the ""save page"" at the top of the page, but a ""restore page"" button instead of the ""save page"" button at the edit summary page, even if you have made changes in the older version (and thus aren't simply restoring it). Why we have two different buttons (save and restore), when we have only one name otherwise, isn't clear. Beneath the ""restore page "" button, the small text says ""By clicking the ""save page"" button, you agree..."". It doesn't indicate what I agree to by clicking the ""restore page"" button though... Fram (talk) 14:08, 19 September 2013 (UTC) >>
--------------------------
**Version**: unspecified
**Severity**: normal",56329,11,Needs Triage,False
-3.0333420078467257,-2.216155318703823,6.190776790746579,1.775525216181196,2.4407376577395743,2.170439008976971,-1.5800458842817582,1.4989896498454471,3.8793689428082363,-1.120676032271989,-0.5947569435680435,-0.6571778153935645,0.5364968062784676,-0.44098870482543884,-1.4741109035169275,0.8553163195639782,-0.21934813951721543,1.007642454982902,False,c1,3,"Try clicking the commons template in https://pl.wikipedia.org/wiki/Omega_Centauri?veaction=edit for an example. This bug appeared a while back, and seems to have regressed.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50970",56301,11,Needs Triage,False
1.8130332913415104,2.159016170314537,3.7863813742305084,-0.35158287895358964,-0.19704019446451998,3.1527789702185176,0.7872455123487425,0.18323726811900826,-1.4463263373249962,0.16756122237825277,1.3833522397160514,1.5307083430781983,2.389586882098074,0.0493188687556696,-0.46125488778579804,1.1521579405546012,0.6151288971787665,-0.8698354078208903,False,c1,3,"**Author:** `renukaalurkar`
**Description:**
1)Log into http://en.wikipedia.beta.wmflabs.org
2)Go to your user page
3)Click on Edit beta tab
4)Click on More
5)Click Media
6)Enter santa claus, select a image from the selection of images
7)Select the image(the image is displayed in light blue)
8)Again click on More, then Media and select another image.
Expected:The original/old image should be replaced by the new image.
Observed: The new image is added and the original image is also displayed.
Another observation: Also, suppose there are 4 images Image1, Image2, Image3, Image4 one below the other. If Image2 is selected and I try to replace it with a new image, the new image appears in the place of Image3(instead of Image2).
Observed on Firefox and Chrome.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51033",56285,11,Needs Triage,False
-10.735685507794395,7.738869053567381,-3.235781545997062,-4.448363071923026,-0.823926435261658,1.302777515406078,-0.7331145019137244,2.55983379537301,-2.241932978727094,-1.1717531772638314,-2.5200238035451754,-1.5588925736906667,-0.044993180340281214,-1.4907037546868542,-0.6040208622438001,-1.722417248244796,2.612177761851031,-1.104793854676931,True,c1,3,"Which is something like '' this '' as opposed to something like ''that''. Of course this is also true for the source editor, but since the wikilink tool already gets rid of spaces at the beginning or at the end of a word, I wanted to make sure this can/should also be done when just formatting it (and it's being requested).
--------------------------
**Version**: unspecified
**Severity**: normal",56270,11,Needs Triage,False
-2.878129662396206,-0.20628529629187753,-2.9435543198904544,-12.950139568967833,5.764996310740969,-0.4886509446342392,4.7961757199619965,-4.358322660557714,0.8623369960881382,3.1576685092839503,5.450882996266229,0.3894186577908456,1.2809179955997023,-1.4217597215676832,3.2563325908969043,-1.3805262646178658,0.06194416535395142,-1.3347584929429877,True,c1,3,"It is not easy, but you can create an empty wikilink with VE, https://en.wikipedia.org/w/index.php?title=Ascending_cholangitis&curid=5544827&diff=572776141&oldid=566427601 (I was able to reproduce that somehow, I think I just added the link to an empty space).
I can't imagine a situation where this is desirable or useful, please correct me if I am wrong.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",56266,11,Needs Triage,True
3.675409272086488,1.2749005093304415,-1.5027789243144927,-1.49944393654062,2.264597353848926,-3.7908637546939765,0.6833776377143366,-0.0132944897315041,-0.3559102728970583,1.1919859817833558,0.29792585454384746,-0.4638865984106433,-0.018110151306419908,-1.9538528105994697,-0.699299735865071,-1.360145048949723,2.6271850466304256,1.954076910022369,False,c1,3,"I updated Flow, Parsoid, and VisualEditor on toro. Adding a new post worked fine and brought up VE (after a long delay during which the text area should probably be locked) and I could WYSIWYG. \o/
But existing summary and some posts on http://toro.wmflabs.org/wiki/Special:Flow/Sandbox_2 that have images and links in them show stuff like
<a rel=""mw:WikiLink"" href="".//Subpage"" data-parsoid=""{""stx"":""simple"",""a"":{""href"":"".//Subpage""},""sa"":{""href"":""/Subpage""},""dsr"":[89,101,2,2]}"">
suggesting Flow is having problems figuring out Parsoid HTML content.
I had set $wgFlowUseParsoid=true, now I think obsolete. I tried setting $wgFlowContentFormat='html', didn't seem to change behavior.
Firebug reported some XHR errors, possibly from some VE API call, but now not.
If the issue is existing content doesn't render right, this is fine to mark WONTFIX. We haven't promised data compatibility yet.
--------------------------
**Version**: master
**Severity**: normal",56257,11,Needs Triage,True
-4.87584732640833,1.8649217949174925,-2.733044265314522,1.9398569993171115,0.16355085668377267,2.6069808344218215,1.1465418274973018,2.2095691525313494,-5.06732274780811,-1.1774295814942848,1.4292306960262269,0.9863748572048279,0.8218177057824656,-0.8119123230875873,-0.6504468875227793,-0.8179867540391026,0.005583999233322645,0.44139000612655654,False,c1,3,"Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.
MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.
For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.
--------------------------
**Version**: unspecified
**Severity**: normal",56205,11,Needs Triage,False
3.854874037909694,3.033185530625019,6.564278682310476,-1.1630769937217955,-4.280834499470508,0.1529467102908133,1.5669155438840745,0.55796771630269,-1.1946058368562102,-1.9918926978827773,-2.5935845921704352,1.2924460959539508,-0.08326095779376352,1.529978254468146,1.2173907664965773,-1.4312277667775408,0.5102864046138675,3.576596653109922,False,c1,3,"Using FF 23.0.1 and Google Chrome 29.0.1547.66 m. Try edit w:en:Ondine's curse from a section #Treatment and prognosis. When logged the page shows to be in process, but never allowes editing. Why I log of editing via VE is possible within seconds.
--------------------------
**Version**: unspecified
**Severity**: blocker",56182,11,Needs Triage,True
-1.6231233378449055,0.16220520282739948,2.696666808277328,8.207565954836953,-0.15537202871788403,-1.1367673275257373,1.219567533981154,-0.35041153901797184,-1.8427583983799987,-2.4978520911219046,-1.8612426951520789,-1.7165167839690971,1.2149382503053658,0.81610638875134,-1.2749437221864817,-0.09900987827234858,0.7285023613503314,1.5019976554213568,False,c1,3,"When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.
Possibly related to bug 53632??
--------------------------
**Version**: unspecified
**Severity**: normal",55979,10,Needs Triage,False
-0.6991169236619088,-1.5996255850058763,-2.736549999199827,4.2419003889915246,-1.1893912761884975,-3.8070501332328046,-0.34925508499414093,-0.9891920988808249,-1.8324242383766935,0.9095022025529378,1.417486772376575,2.1396617703909335,0.047444204290882475,-0.9309174984875734,-1.0992038902816663,-0.5774430704765932,-1.3484498420452922,-0.39583756105918844,False,c1,3,"This is going to give you a headache
{{Infobox ship begin}}
http://en.wikipedia.org/wiki/Template:Infobox_ship_begin
is used in 26840 pages. I provides styling for tables used to make infoboxes relating to ships. It is used like
{|{{Infobox ship begin}}
{{Infobox ship image
|Ship image=[[File:Whydah-model.jpg|300px]]
|Ship caption=The ''Whydah Gally'' (1716–1717)
}}
{{Infobox Ship Career
...
}}
|-
|Commanded by:
|Cap't. [[Lawrence Prince]]
...
|}
The template transcludes {{WPMILHIST Infobox style}} which provides CSS styling
class=""infobox {{#if:{{{2|}}}|{{{2}}}}}"" style=""float: right; clear: right; width: 315px; border-spacing: 2px; text-align: left; font-size: 90%;""
So the table start tag and its styling are separate.
Unsurprisingly VE fails to edit pages with this template correctly. The following was reported at
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=572065469
Open the article in the visual editor, e.g. by visiting https://en.wikipedia.org/wiki/Whydah_Gally?veaction=edit
Observe the article now leads with the out-of-place text
<nowiki>class=""infobox "" style=""float: right; clear: right; width: 315px; border-spacing: 2px; text-align: left; font-size: 90%;""</nowiki>
try to click ""save page"" but note that it is not active
make a trivial change so that ""save page"" is active. Click it
Click ""review your changes"", not that it says that
<nowiki>{{Italic title}}{|{{Infobox ship begin}}</nowiki>
was replaced with
<nowiki>{{Italic title}}{{Infobox ship begin}}
{|{{Infobox ship begin}}</nowiki>
--------------------------
**Version**: unspecified
**Severity**: normal",55927,9,Needs Triage,False
-8.469051899989227,0.6332570398372113,1.969179610940472,5.12921531380189,7.094154739307887,8.809046211009765,1.6221792624593725,1.0662799603717525,1.4364055950025383,0.3263271151435916,1.337443874329829,1.920547931728539,-0.02199554843161078,-2.4774640677983637,4.453706339518262,-1.2357087165524627,-1.2955266169147708,0.4258321432846406,False,c1,3,"This is a strange edit, where a new editor inserted an image in the image description of an existing image. A bug or something that should be able to be done?
https://sv.wikipedia.org/w/index.php?title=Dry_Martini&diff=prev&oldid=23709630
--------------------------
**Version**: unspecified
**Severity**: normal",55896,9,Needs Triage,False
-0.12268248832702877,-1.351833061855638,1.6787946781517213,2.1887289521979656,1.5450818363210375,2.7969098354588153,3.115372208115107,-2.300102268463364,0.06921629527625972,0.6625546023844864,1.60316519188595,-1.019781654047955,0.1923329533347946,-1.2571709708949514,0.6697086337280096,1.2111654037605548,-0.1910168166831443,0.6247551956977018,False,c1,3,"**Author:** `lionel.allorge`
**Description:**
In an infobox, items are in a certain logical order, for exemple, the image item and the caption are next to each other but the VisualEditor sort them alphabetically making it more difficult to find them.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",55891,9,Needs Triage,False
-1.0750805678191138,0.6827729988847988,-1.2760885143364504,-0.3283644922581358,3.971272785420006,1.8360765204868124,-4.650116396737558,-0.4835113884668354,2.2525933309027364,-2.7328297498941456,-0.4914082354915208,-1.9171015618162426,2.273277903237493,-0.3486805627089682,-1.2795448685452548,1.904559859411733,1.9913182365905897,2.9630255014928197,False,c1,3,"Bug pic
Should this happen or shouldn't it?
Btw, steps:
1* Install AssessmentBar from https://en.wikipedia.org/wiki/User:YuviPanda/AssessmentBar
2* Go to an article.
3* Go down to a picture or find the infobox.
4* Click on the picture or infobox (when it's halfway through the AssessmentBar) and it will highlight the AssessmentBar (treating it like a picture or an infobox) AND/OR Click on the part of the AssessmentBar where the picture or infobox is getting highlighted and the infobox or picture will get selected instead of the AssessmentBar.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11559}",55889,9,Needs Triage,True
-6.512807148345466,0.35871924374890796,-3.341037616707357,-1.3874281189637214,5.43770029440673,-1.0583129824970963,-1.764142568395,2.9078518201467336,1.4420124558703582,-1.530623216502296,0.7292811155497678,-1.6699630400767913,0.6290159833285056,-1.5738947617326717,-0.28485946085992353,-0.24981056770710752,-0.9665263176797736,0.12626150120318225,True,c1,3,"Try to start a line with a wikilinked word as you might do in the source editor.
1) Typing the opening double square brackets will not trigger the no-markup warning.
2) The opening brackets will immediately disappear, the closing ones will stay.
3) When you reach the second closing bracket, VE will also add another one on the following line. (If instead of moving to step 4 you use the keyboard arrows around the word, you will not be able anymore to type something outside the brackets, and will need your mouse to place yourself outside of them).
4) Keep typing something instead, then press Enter: whatever you added is automatically copied to the next line, while the ""third"" square bracket is furtherly moved onto the next line.
5) Now add the brackets to an already existing word, correctly triggering the warning. Save anyway.
6) Review the changes. The brackets that triggered the warning did not trigger the nowiki tags as well. An opening one and a closing one are gone, and what is left is weird anyway. (This can also be triggered before saving by hitting Back Space, but I can't say where).
The brackets that we added in the first place are all gone, the duplicated text is gone as well, just a lonely closing bracket stands still.
https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=61362482&oldid=61361463
Reminds me of https://bugzilla.wikimedia.org/show_bug.cgi?id=53079, actually.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57207",55856,9,Needs Triage,False
0.8377692034762494,-0.03336262005703894,-2.3179481531696435,-6.685148571249683,1.1870924068346222,-2.1098968079562104,0.43343932789940354,-0.20873234022489737,0.5588765045016967,-1.140735784110693,0.6071990635516737,-0.9032930344315522,0.9590498670048944,-2.2980835892694196,-0.5168220932977006,-1.6020091858778178,0.2819865946883442,0.08353101115741235,True,c1,3,"A user at it.wp reports that he could not successfully replace a picture with this edit https://it.wikipedia.org/w/index.php?title=Castello_di_Serravalle_%28Bosa%29&diff=61339995&oldid=61339964, although he managed to do so on other occasions, so he knows how it works.
He just replaced Bosa Castle.jpg with Veduta del Castello.JPG, and correctly previewed the latter.
But upon saving, the pic was gone - the field is empty. He tried again later, and managed to reproduce this behavior.
Other users, including me, are not able to reproduce this.
He's using Chrome with Snow Leopard. Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62366",55853,9,Needs Triage,False
-3.6579795809752698,-0.9428321184391404,-5.26266354085657,-4.035826444244326,2.0364969001251527,-2.7261875932691098,-3.0683284342663635,-1.4681394490214479,-4.111410389608231,-0.3035439863519045,1.6996130199073813,1.225617313501629,-2.5684983521340765,0.29406383334882236,-2.2947411398605775,0.02882958289292964,-1.3127963918027754,0.6195141083806248,False,c1,3,"en.wp user Fram reports:
""When I add something that VE decides needs ""nowiki"", it usually gives the warning ""Wikitext markup detected"". However, when I add <references/> to the bottom of a page, he wraps it in ""nowiki""s, but no warning appears (while it does work with e.g. {{reflist}})""
My testing at https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=571756019&oldid=570197356 shows that <i> and <small> also get nowikied without triggering the warning.
<!-- --> neither triggers the warning nor gets nowikied. I am about to start a discussion about whether that is desired or not.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56213",55839,9,Needs Triage,False
1.0715450316455857,-1.829000680615355,4.369653118241004,3.3776869388998305,0.4455884375470407,-2.0986679117610647,-2.0899520210962463,-1.6101589113053953,-2.6899146852328366,-3.215579249390572,1.0594256982184702,-0.3891485286538936,2.3734515194533943,1.0324012099868431,2.3407486538895936,1.5671310329909618,1.0343033377189983,0.20627319680563772,True,c1,3,"The German template for quotes:
https://de.wikipedia.org/wiki/Vorlage:Zitat
eats refs, or rather their display at the end of the article, if the refs are inserted in it & the article is loaded in VE. Example articles:
https://de.wikipedia.org/wiki/Arvo_P%C3%A4rt -> ref 5 & 8
https://de.wikipedia.org/wiki/The_Rolling_Stones -> 26, 123-125
https://de.wikipedia.org/wiki/Chick_Corea -> ref 12
Report:
https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122231626#Einzelnachweise_am_Artikelende_werden_im_VE_nicht_angezeigt
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50474",55777,9,Needs Triage,False
1.8209317270054535,-5.481453254225613,0.9770886329851542,0.6857611582100862,0.5300772780134284,-1.0834736978514241,-1.8216449384416826,-0.8157708738426482,1.1306741724413794,2.704320937478628,-2.0418767435010556,2.8045658003334877,0.1310249138373809,-0.3268688149486465,-2.035068048773436,0.2981466890546316,-0.719709456540816,1.149044884941304,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=Epigram_%28programming_language%29&oldid=567048374&veaction=edit and click ""save"" (note that save box warns about corruption) and then ""view changes"" (ignoring the changes I have since made). The pre block has been corrupted.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",55775,9,Needs Triage,True
5.378945593107513,-1.0737358812335547,8.654797432379908,7.575363498748365,2.6775611373064416,4.251718784953141,0.37677301132994945,-3.203011552495378,4.755976698819835,-1.24851849819935,-1.8169191944763647,-0.9862711096092077,-2.2846515228870974,0.6102395166706902,1.9091999370668287,-1.16858647617366,-0.13854770238521308,-0.4559691682121132,True,c1,3,"A De.WP user suggested to include a preview for the edit summary. Report:
https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen
--------------------------
**Version**: unspecified
**Severity**: enhancement",55729,9,Needs Triage,True
-5.357825287241305,-1.646498469969103,-3.5730528915227104,-2.7888550626504642,3.003507761387146,-1.451979634296299,0.18076006363413377,-0.21713357765751629,0.8762055354170133,-2.4587194772786423,-1.182768146052219,-2.8480702448305157,0.2230076585565648,-2.8399039463053133,0.9706369036269278,0.5221137958591344,-1.432227619928869,-1.4527765048803825,True,c1,3,"See https://it.wikipedia.org/w/index.php?title=Bisanzio_Lupis&diff=61160806&oldid=51778070 .
When creating a section for references and adding the relevant tag,
it will suppress the Related Articles section - just the heading, not the content.
I reproduced it easily in my sandbox by just adding the contents that you can see in the diff above.
Note that it is not related to the reference being added in the same edit; here for instance https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=61285258&oldid=61285224 it was added previously.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",55699,9,Needs Triage,False
-3.93430949750237,2.8477567042140564,-1.7324800322303684,0.28824788279203495,0.29384132230515914,2.694236217532694,-2.023245416589476,-0.8999300248368591,-3.101375454730304,-1.6374880875157483,-0.5656513334384794,0.026727099770728735,-0.22357990900368296,-0.40249043696936404,0.14823873336859705,0.9912275129611158,-0.7767771809171061,-0.6094221099558812,False,c1,3,"The Wikitext warning is triggered in some circumstances without the user having entered Wikitext. The one cause I can reliably reproduce is where there is nowikied markup on the page from a previous edit.
To reproduce:
1. Load https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&oldid=571089410&veaction=edit
2. Click anywhere on the last line of Section number two (the line that contains ""[[Manhatan]]"" and an ISBN, both of which are enclosed in nowiki tags).
It seems that the warning is triggered by the existence of wikitext markup in the VE editing surface, rather than by its addition.
--------------------------
**Version**: unspecified
**Severity**: normal",55661,8,Needs Triage,True
-6.296239534128852,4.2727999742501055,1.9283919344611746,-3.3688778718365042,-4.191474860321927,-1.8899018812280546,-0.6851530180289558,-0.8428348532470984,1.0768401293934984,0.9098572898039032,0.7048261136962282,1.5914650974421256,-1.111828490738878,-0.6305393666214076,0.8504253201315208,0.6914266295859075,-1.859743591321287,-0.7192822270894113,False,c1,3,"There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible.""
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49806
https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",55659,8,Needs Triage,False
3.2698877988492803,-0.5098687835097788,-3.3466604516772627,-3.8907331125148104,1.5038615580545485,-0.4545792090211048,-1.3631626494881797,0.8412132364568444,-1.3599049782720118,1.9785934459601915,-2.2682364577425957,0.060895756058988226,-0.6092088703783158,-0.26236715932231114,-1.1132913977281085,1.9101681845436038,1.85638733130835,-2.0709136659687863,False,c1,3,"In some odd circumstances the text immediately following an image is duplicated. You can see the effect in
http://en.wikipedia.org/w/index.php?title=Danny_Nalliah&oldid=570830443&veaction=edit
where the text '''Daniel (Danny) Nalliah''' is duplicated.
To make things more confusing it does not occur for every revision
http://en.wikipedia.org/w/index.php?title=Danny_Nalliah&oldid=570591483&veaction=edit
works fine.
To make things thoughly weird in this revision in my sandbox
http://en.wikipedia.org/w/index.php?title=User:Salix_alba/sandbox&oldid=570839025
the text '''Daniel (Danny) Nalliah''' does not appear. Yet it magically appear in VE
http://en.wikipedia.org/w/index.php?title=User:Salix_alba/sandbox&direction=prev&oldid=570839025&veaction=edit
This issues is discussed at
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Still_looks_like_VE_Feedback_to_me
--------------------------
**Version**: unspecified
**Severity**: normal",55643,8,Needs Triage,False
8.028762891206648,-1.2583386717031324,-1.2734746307780647,-9.399901652644546,2.4190571970419015,-4.901263230479585,0.14050195567894708,1.3066987310421077,-0.10795021443433192,-2.2274583231372787,-0.192837736999095,-2.1204686869026883,3.311143247854774,4.732122807850301,1.3094488650976208,1.6746472693317034,0.49274015731585474,1.648202619186269,False,c1,3,"I cannot paste text into the edit summary with Ctrl+V or right click and paste when I use Chromium Version 28.0.1500.71 Ubuntu 13.04 (28.0.1500.71-0ubuntu1.13.04.1). Nothing happens. It works fine in FireFox though.
--------------------------
**Version**: unspecified
**Severity**: normal",55632,8,Needs Triage,False
5.7124724497063095,-2.5797267864417783,-0.0926637914758004,-4.3040758946980375,-0.2976641172821495,0.9430528236882709,4.2164552865146545,-6.847521986552299,-2.0185274104373194,0.8710551141278531,1.944481974693892,0.43009446004872465,-0.11329597708719774,0.5975424311594528,-1.7889591901518909,1.0291122465174047,1.842002813780682,1.3128288064848295,False,c1,3,"We have moved ULS and VisualEditor tests to their repositories. Delete the code from browsertests repository.
--------------------------
**Version**: unspecified
**Severity**: normal",55582,8,Needs Triage,False
7.4207783824684554,2.484250530614844,4.143510554557572,-0.1621689691041618,-0.608669293114355,1.149278385851524,2.242547895767358,-2.399515408385632,1.8354864762470504,-0.39327365158378136,-0.06056175552209142,-1.8439572196406817,-0.7017190218555553,2.1993313078399552,1.3020525547035424,-0.09042458704404327,-0.8111278073935504,-0.7202876231990187,False,c1,3,"At the moment we have similar setup code for browser tests in 6 repositories:
https://github.com/wikimedia/qa-browsertests
https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://github.com/wikimedia/mediawiki-extensions-VisualEditor
https://github.com/wikimedia/mediawiki-extensions-Wikibase
Figure out a way how to reduce code duplication. We should probably create a Ruby gem.
--------------------------
**Version**: unspecified
**Severity**: normal",55581,8,Needs Triage,False
12.8072898209839,-3.1693840549516246,6.468093750361781,-1.7180828068743987,-5.130658722305743,0.47232773955561935,1.935196911266475,-3.469086933884186,-2.217965790134482,-1.0968176590030612,-1.8320632912873007,0.46426832666945006,-0.5468793825993599,1.6234475018722403,-0.3970016515618475,1.0461647034780706,-0.15809112056621144,0.14155572130576988,False,c1,3,"README.md[1] file has information about Selenium tests in
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
Add links to:
https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://github.com/wikimedia/mediawiki-extensions-VisualEditor
https://github.com/wikimedia/mediawiki-extensions-Wikibase
1: https://github.com/wikimedia/qa-browsertests/blob/master/README.md
--------------------------
**Version**: unspecified
**Severity**: normal",55580,8,Needs Triage,False
13.751860238607879,-7.02427362753198,-2.397648067705852,-2.041433253556026,0.9491273752696106,-0.5899201604568156,0.34773776615996876,1.3377292555027562,1.1996551192298746,-1.5235666199059428,-1.033597770449573,4.679608137302762,1.1871869477906851,-3.920783763795284,2.6022007177861477,0.5164624548456151,0.7532746412308511,1.1266060165946337,False,c1,3,".ruby-gemset and .ruby-version should be removed and RVM setup should be moved to Gemfile[1].
Repositories that are doing it right:
https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://github.com/wikimedia/mediawiki-extensions-VisualEditor
Repositories that should be updated:
https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
https://github.com/wikimedia/mediawiki-extensions-Wikibase
https://github.com/wikimedia/qa-browsertests
1: https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/blob/master/tests/browser/Gemfile#L1-L2
--------------------------
**Version**: unspecified
**Severity**: normal",55579,8,Needs Triage,False
17.281212208174615,4.058499430329366,2.6447655548878046,-4.206106038077201,-4.314653792540157,4.123640845284453,1.1978568479554603,-1.3558131517358412,-3.0417081443604497,-1.9862129573548013,-2.970324770428394,3.4301412995480414,-1.2774807848497138,-0.5667171771718493,0.8079636156625023,1.501959507747434,3.322431392213306,1.663106657246152,False,c1,3,"Who gets e-mail notification is documented in jobs.md[1]. At the moment Chris and I get notification for all jobs. Michelle is added for MobileFrontend, Rachel and James for VisualEditor.
Nik Everett should be notified for CirrusSearch, Amir and Niklas for UniversalLanguageSelector.
1: https://github.com/wikimedia/qa-browsertests/blob/master/docs/jobs.md
--------------------------
**Version**: unspecified
**Severity**: normal",55578,8,Needs Triage,False
-3.7170647536714396,-1.2280384292940774,-0.31935890802780875,-1.2999700887377053,4.367826296975,-1.8369637117073907,-0.10465484705253747,2.4395373346633344,2.0238311694284334,1.2782091308239094,4.21747832159218,0.0026255652927249518,2.3862449323591077,0.060053277052548815,0.7986079982956795,0.5711449614172392,1.659874428537606,1.0436782752744904,False,c1,3,"I could not replicate this in LTR wikis (en.wiki or MediaWiki.org) but I suspect this is not so much ltr/rtl but floating behavior of the templates and images.
See example here:
https://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9%D7%AA:Mooeypoo/%D7%A2%D7%95%D7%A8%D7%9A_%D7%97%D7%96%D7%95%D7%AA%D7%99/%D7%91%D7%93%D7%99%D7%A7%D7%95%D7%AA_%D7%95%D7%9E%D7%A9%D7%97%D7%A7%D7%99%D7%9D?veaction=edit
The top two images are regular images (not templates) - they are perfectly editable if you remove the template at the top. They got their shielded status after I inserted that template.
Steps to reproduce:
1. Edit a page
2. Insert some image (or more) to top
3. Save page
4. Edit again, insert template ""{{עליות}}"" just above the images.
5. Save.
6. Edit again. Observe: The images jumped to the left (wrong float side) and are now uneditable.
7. Interesting fact: Remove the template and save, then go back into the editor and the images are still uneditable.
--------------------------
**Version**: unspecified
**Severity**: normal",55542,8,Needs Triage,False
-5.6825965673020296,1.4166641597357543,1.3977544811766762,-0.4688126923111068,0.764839649548634,5.68488805615038,4.553218647587824,-1.7896836779536383,0.7362671982241216,3.9755954990989864,4.056086773845539,0.23536562658317606,0.006002209310294049,1.5599285370242804,0.8440100240811175,0.8011744012293016,-0.6769472333048961,-2.650860456403588,True,c1,3,"If you open https://fr.wikipedia.org/w/index.php?title=Anna_Mouglalis&oldid=95468238&veaction=edit you'll notice a weird order of paragraphs. This is due to an extra space in the ref tag for the second reference. VE might probably autocorrect similar situations.
--------------------------
**Version**: unspecified
**Severity**: normal",55535,8,Needs Triage,True
-7.377830342194169,2.142804695552428,-3.549246425180522,0.7765604164872295,-0.56690818480181,1.7494462255670464,-2.6004490192026504,1.1229073352603738,-0.9670247784207195,0.6133871903703509,0.09530136044825577,-1.0498185336804187,1.7812266210657355,-0.8794098732605287,-1.1673740196081495,0.7417004763399558,-0.42130338829567626,-0.515738730414756,False,c1,3,"To reproduce:
1. Go to this page: https://he.wikipedia.org/wiki/%D7%90%D7%9C%D7%9B%D7%A1%D7%A0%D7%93%D7%A8_%D7%94%D7%92%D7%93%D7%95%D7%9C
2. Edit the infobox at the left side.
3. Behold! Some parameters appear both at the left panel (used) and also on the right panel (unused). Specific example, look for the parameters ""בן זוג"" and ""בת זוג""
4. If you click the parameter ""בת זוג"" for example, on the left side (the used one) you will see data. If you click the one on the right side, it appears with empty textbox as if it's new.
5. Click on the right side (as if to add param again) on ""בת זוג""
6. Click again and again -- the parameter will keep being added to the list on the left in duplicates.
And if the page is saved, the parameter is now completely removed.
This has happened specifically in the hewiki but might be related to more than just RTL.
--------------------------
**Version**: unspecified
**Severity**: normal",55515,8,Needs Triage,False
-4.24865399440328,-2.294918361720928,-6.277744680023654,0.972650363423214,-0.6327156495563702,0.5041532934335822,-5.28267424724685,3.721774992063002,-4.080545308227023,-3.464998181660291,6.421795290115918,-0.5707618203926355,-3.249503835707178,-1.8116166335166377,0.23994917778677127,0.8211211843668058,0.7385275879833817,0.024811706543544476,False,c1,3,"Currently whenever a user enters a link when no text is selected the first character of the displayed link is always capitalised. This is often incorrect, e.g. in the middle of a sentence or for articles like [[iPhone]] or [[grep]].
Especially until bug 50678 is fixed, correcting this is not at easy or intuitive.
So, at least until bug 48789 and bug 50945 are fixed and the display text is settable in the dialog, and probably beyond that, it would be best if the displayed link used the same case as the search term entered. i.e.
User entry -> wikitext equivalent of desired output
Green -> [[Green]]
green -> [[green]]
iPad -> [[iPad]]
HAMmer -> [[Hammer]]
london -> [[london]]
Yes, this will result in some wrong captialisations, but no more than at present and will only be temporary (as noted above)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50678
https://bugzilla.wikimedia.org/show_bug.cgi?id=50745",55495,8,Needs Triage,True
-3.887115647475138,-2.536185778183075,-0.32752153196790346,3.960188076653081,-0.010862600640565434,0.9946314366628262,-2.337848483306385,-0.6524037573117389,1.2862655608134907,0.2583844776253743,3.725532278037146,-0.31428946552211356,-0.06489522637997958,-0.6134936266852504,-0.9722631009924161,1.4428871807550785,-1.0757727139565763,-0.3023042760567456,True,c1,3,"This is somewhat related to bug 50321.
Steps to reproduce:
1. Open your own sandbox/userpage (not a page in the mainspace) in VisualEditor.
2. Add a link to a word (""xxx"").
3. Control-click/right-click/command-click the new link to open the link in a new tab or new window.
4. Discover that VisualEditor has sent you to an invalid URL: http://en.wikipedia.org/w/Xxx or http://en.wikipedia.org/wiki/User:Whatamidoing_(WMF)/Xxx
--------------------------
**Version**: unspecified
**Severity**: normal",55491,8,Needs Triage,True
12.168612738146708,-4.849844200145213,8.17855914797612,0.7410362940598463,-6.364302883364109,2.3299682558884296,2.9643611135753405,-1.4434506728888565,-0.4002705942369069,0.4097845209029458,-0.5464448978913539,-0.9953620889003345,-0.7784857349572905,-0.5421137485864147,-0.3605318244122353,-0.9911362880177734,0.5518571099967664,-0.3508157199331623,False,c1,3,"Requested by James Forrester at QA mailing list:
http://lists.wikimedia.org/pipermail/qa/2013-August/000339.html
--------------------------
**Version**: unspecified
**Severity**: normal",55467,8,Needs Triage,True
2.415568687998267,-2.003404418419553,-0.3738478639278515,1.5848687691613494,1.024425036599972,2.7043500809081653,0.2453453058880255,2.352468314936197,-0.005304959311940471,1.9815756273115621,-2.2021921554895547,-3.247671095461091,-1.3401399617089096,0.7386746355641458,-0.7737512349595397,0.7772211034736602,-1.6629324328710715,-0.7416013529492416,False,c1,3,"**Author:** `molly.white5`
**Description:**
Only show the edit summary input box after the user clicks ""save"" (sort of like in the VisualEditor).
--------------------------
**Version**: unspecified
**Severity**: normal",55450,8,Needs Triage,False
-11.896298131652506,6.000008677916387,-4.8154636927801455,-2.74606315176644,-0.9537717179200064,2.2276870590903313,0.40174025353626863,1.8800535783702856,2.4370507184748824,-1.4828352678034356,-1.8746811720906043,2.1668098397307594,-1.1078274638396808,0.5710516658762694,0.3744397746407335,-1.2131116807980482,0.796862338259426,1.6423788539023174,False,c1,3,"At the moment there doesn't appear to be a way to replace media - that is, to click on a media element, and select a different piece of media for that element. That's not a big deal at the moment, but we're going to move to a world where media settings are more complex - where alignment can be specified, referencing can be specified and permitted, so on and so forth.
The result of this is that media elements will have a lot of data associated with them - media it's pretty hard to type out again if you find that the image (or video, or...whatever) needs to be replaced. It would be good to have a way of replacing images without losing the associated caption, size and alignment.
--------------------------
**Version**: unspecified
**Severity**: normal",55409,8,Needs Triage,True
5.337843153987693,-3.9049013875656673,1.8781945078776374,1.1130257827118024,2.761093828247998,-0.9282002240183327,2.711756255173987,-2.669653181052909,2.658170438856475,-1.2486511568905279,-1.5765718378939069,-0.6491446587100212,-2.6134546397085066,0.7286743168245611,0.6009545354233348,3.4065304789695903,1.9156248357772194,1.4367970543421447,False,c1,3,"We need a search-and-replace feature in VisualEditor. This seacrh box should also support ULS
--------------------------
**Version**: unspecified
**Severity**: enhancement",55326,7,Needs Triage,True
-1.5045874051660975,-4.387324141167818,-0.28010835441194004,0.8040743654572957,-0.45953682912906635,8.516509763504045,0.5589572562685321,-0.727293924703602,4.841278622403471,-0.926908112365274,-1.7798965078319016,0.719387970307976,-2.335455943145309,-0.2094501101967836,2.9580942060502613,0.9816007852586089,-0.22826650957113093,5.134357343256256,False,c1,3,"There should be a facility in VisualEditor for creating new table or edit an existing table
--------------------------
**Version**: unspecified
**Severity**: enhancement",55325,7,Needs Triage,True
-7.464580049742825,2.182865932712687,-4.083350118996691,-4.225995845649184,4.2690369073287755,-3.004071249612779,-0.5875275939369677,1.21661106296038,1.1165519269905404,0.18358647383769178,0.036296756117113915,-2.7583501588651522,-0.2991477316871478,0.33115034717387637,-0.777396311426827,-0.804871449765149,-0.6789465361976316,0.03491791469221872,True,c1,3,"User report:
<<So I put a space and then a backspace. Go to save, review changes to check and make sure it is a null edit, then it goes to this ""processing"" dialogue but then it shows ""Could not start the review because your revision matches the latest version of this page."" So then I press the little back link on the dialogue, but it just goes back to the processing dialogue. If the page is small, the processing is really quick, so before I can even press back again, it goes back to the ""Could not start"" warning message. Even if I do manage to press the back a second time quickly, it will only stay at the save dialogue for a split second and then again bring me to the warning message, although ''then'' pressing back does take me to the save dialogue securely. FF 23.0.1 Win7.>>
I managed to reproduce this on Chrome as well, so which is the intended left button behaviour?
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",55314,7,Needs Triage,True
0.16224900103615614,-2.591472095908186,-0.17455769929476972,-0.108050548854278,0.05605037669203372,-2.0497724225635876,1.9469744965292959,0.2285947127004319,-0.4215817634011088,1.0693348646271357,-4.310024953385723,0.5543488041620364,-3.8033378911115454,1.8159080036136626,0.7041036540628305,1.1851179064858597,1.3720260991040496,-0.47064313758901255,False,c1,3,"**Author:** `ryuch`
**Description:**
VE not can be enabled by options in preferences for beta testing.
When I click 'edit' on an article, the progress bar appear but does not finish initialization.
--------------------------
**Version**: unspecified
**Severity**: normal",55301,7,Needs Triage,False
-7.671910020257437,1.401674969991051,-3.577284340511289,-0.11262428462994212,0.633664987847893,-3.160661426590794,0.9704523283920308,-2.0637854068186203,-0.2727690211619291,-0.27088274784135624,0.39832331762525763,0.4381387176625191,1.6482598560713866,-0.0546944068634021,-1.16524043262769,0.7168875258929794,-0.6393669973796928,-0.08664318635266377,False,c1,3,"cucumber features/visual_editor_anon.feature:5 # Scenario: Basic edit fails
because VisualEditor these days shows an introductory disclaimer:
This is our new, easier way to edit. It's still in beta,
which means you might find parts of the page you can't edit...
and so it fails with
expected ""You are not currently logged in.
which isn't visible until you dismiss the popup.
I think the same explains a
timed out after 5 seconds, Element was not visible in 5 seconds
that I'm getting in the similar
cucumber features/visual_editor_logged_in.feature:5 # Scenario: Basic edit
after applying gerrit 80709.
The popup is in a div containing an iframe containing more divs until class=""ve-ui-mwBetaWelcomeDialog-content"", and then tests have to click outside it to dismiss it; and some day it will go away.
Instead it seems better to set the ve-beta-welcome-dialog cookie to 1 upon visiting the site, which will turn off this disclaimer dialog.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55295,7,Needs Triage,False
-3.6572877169658384,-2.8599163966128565,-4.9765796630870245,-0.8673115437946223,0.5461108530977061,-0.9591596735783515,-5.659150952798503,-0.7520151960474835,-4.253838480178362,0.8368016406115748,3.5068239399486063,-0.07031627628067083,-3.020049362281326,-1.8088171252707848,-0.2705705166613548,-0.5494881265098334,-0.14079118700890603,-0.6499213813515388,True,c1,3,"User report following:
<<If I start with a blank page, type in ""<br>"", select the entire text, press the link icon, select say ""France"" as the link, upon exiting the link dialog I am left with a link to [[France]] but the anchor is shortened to ""<b"".</nowiki> I don't get any ""Wikitext markup detected"" warning. >>
This is true for other tags as well (I tried with <b>).
--------------------------
**Version**: unspecified
**Severity**: normal",55280,7,Needs Triage,False
-4.255185348855741,5.485711749674259,3.030949798955291,3.245971155948025,3.401989604730681,7.189427571120675,0.15473645941883873,-1.8661316442754528,-0.9229746020459503,-0.612205557732433,2.407282092011935,-6.762360862137071,-0.8219926623472871,-2.324588217503841,1.9722210056886151,-1.0130588741903628,-1.564257443707631,-0.010765678819227853,False,c1,3,"While I was fixing a simple grammatical error, VE threw in a > sign at the start of a template further down the page thus breaking the template.
https://en.wikipedia.org/w/index.php?title=Tesla_Model_S&diff=next&oldid=569876875
--------------------------
**Version**: unspecified
**Severity**: normal",55262,7,Needs Triage,False
-6.1878223597773685,4.801765164043079,-1.4791526872326575,2.4405863742612093,2.04837228375769,1.4487040918350764,-5.669025297069929,-1.1636615682924094,-4.892057118007074,-3.040882107858156,4.269576597991115,0.8229018338293235,-6.702381677190821,1.9799593291564754,-1.6394854920235065,-2.2423073347172213,-0.24875711988324345,-0.5284614523898854,False,c1,3,"If I focus on the save button using [tab] from textarea, [enter] don’t save the page.
Apparently the focus goes on the <div role=""button""> while the click event is listened on the span.
--------------------------
**Version**: unspecified
**Severity**: normal",55257,7,Needs Triage,False
-4.303772310397539,2.9611584646405795,-0.1634595653589237,-0.5459420768696048,0.6798158138655099,-1.1710729534790834,-1.2057359395305642,-2.0156165877078975,3.2537564743469023,-0.944901091849387,1.4248405475982708,-0.5130856437096822,1.8500982111417148,-1.1188875902427013,0.6560294619086786,-0.2278436433569545,0.6672214634649325,-0.7712454546835208,True,c1,3,"Seems I had written about it in an unrelated bug, sorry. This happens on itwp: in order to do this
http://it.wikipedia.org/w/index.php?title=DNasi_attivata_da_caspasi&diff=60101664&oldid=60089990
I had to delete the word and link it back again. Our guidelines about style
require pages in that section to appear with the capital letter, so we need to be able to fix that easily.
It is also reported on en.wp, the user states <<When trying to correct a lower-case letter to a capital letter at the beginning of a link, I deleted the lower-case letter and found I couldn't type a capital letter and have it become part of the link, nor could I seem to extend the link over the capital. Eventually, I typed the capital after the lower-case letter and then deleted the lower-case letter. It might be good to have some way to extend a link over adjoining letters/words/text. Mount Flatten (talk) 05:31, 22 August 2013 (UTC) >>
Thanks.
ps. Might be related to https://bugzilla.wikimedia.org/show_bug.cgi?id=50745 .
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50745",55210,7,Needs Triage,True
-0.3368525882560296,-1.9629532829988943,3.562621817683574,-6.36320008211608,1.5878758711475056,-0.4247476148203755,1.6933632551757558,0.34379037532384527,2.9926921022727866,1.236996083929042,0.9477553188821841,-2.642173124517484,-0.47582687709822036,2.091172963292413,-1.8060295335435508,0.5064800182709204,-0.48081749518639605,-3.177375942896562,True,c1,3,"See http://en.wikipedia.org/w/index.php?title=User:Christian75/sandbox2&oldid=569697466 .
If you edit the page with VE you won't see the broken template at all.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",55205,7,Needs Triage,False
-2.316894372670254,-4.451948582804201,-4.270631228676761,-2.0666991676654343,0.26044429735603314,-2.4155719718117794,-0.4697072952439445,2.92862454748467,2.423707614441149,-1.6582809180637095,-1.9212764176768231,-2.2348027733954465,0.11746371062432548,0.1551953267252406,-1.4300462812948433,1.1154747478663256,-0.8056369485885774,-1.8236238813531342,False,c1,3,"Currently there is no way to use {{subst:DATE}} in a template invocation in VisualEditor. If you try to paste it into the value of a date field, it won't work because you get
|date = date=August 2013
which won't parse.
VisualEditor should actually set the date automatically, always, for such templates (e.g. refimprove).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52345",55201,7,Needs Triage,True
0.7211277774492859,2.92812860863069,3.960729538361015,2.6863156075320935,-0.4809834622628634,1.6733335217965222,-1.5276141773266714,-0.32791216724514194,-2.089356220725155,0.45905040963909105,2.148565574185064,0.08859842606356128,-1.723858804074533,-1.3611923077859003,-0.32031901114721784,-1.142159448140289,-0.9856432532642684,0.6414730610863397,False,c1,3,"If I add an unprefixed link to [[Main Page]] on
https://www.mediawiki.org/wiki/Wikimedia_Engineering/WMF_Tech_Days_2013
using VisualEditor, the link points to [[Wikimedia Engineering/Main Page]] when previewed in VisualEditor (by right-clicking and opening in a new tab). ""Review changes"" suggests that the correct link will be added when saving the page, so this issue may be limited to the editing surface.
--------------------------
**Version**: unspecified
**Severity**: normal",55190,7,Needs Triage,True
1.0178594550656102,4.63649892319642,-2.9153282606711617,0.223132486432841,1.6840720087526089,4.390713551393533,-0.13708394091633114,-1.956843512237492,2.2669740780256564,-0.4068584524342942,1.1102441994635313,-3.2963504904639764,1.1191872849687026,-1.6425354036121815,-0.36675694946923176,-1.5899674905950765,-0.6642349530501385,0.3283838453720789,True,c1,3,"On de.WP, a user tried to replace an outdated link within an existing ref via VE and ran into a nowiki.
diff:
http://de.wikipedia.org/w/index.php?title=Kin-dsa-dsa%21&diff=121506430&oldid=117367043
report:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121759646#nowiki_bei_unbeschriftetem_Link
I could reproduce that; the previous is showing it prior to saving, too.
--------------------------
**Version**: unspecified
**Severity**: normal",55183,7,Needs Triage,False
-5.620112143107871,0.06315325403877559,-0.7570263920383802,3.7493576791875984,1.2026755866189172,-1.1270339151701871,-1.0855091585494252,0.06338474519952009,0.036158351950117906,1.4018690365850919,-1.5837602705080092,1.6772096297176267,0.6731869141259632,-1.0900715899330304,-0.5551210250483516,0.3536457977585295,0.3993936455232274,0.39818065306723516,False,c1,3,"When I add a reference and add a template of type ""cite web"" in the reference, the template only allows me to enter a single author last name and a single author first name. To enter multiple authors I'm supposed to use the attributes ""last1, first1 through last9, first9 for up to nine authors"", but VisualEditor doesn't seem to offer the possibility of adding these attributes.
There is an ""others"" field, but this is only supposed to be used for people who are neither authors nor editors, e.g. illustrators.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",55166,7,Needs Triage,True
0.3971939396791715,-7.071706694172864,-3.6325832054309135,0.2913025923754502,4.427482952468788,5.774814229099015,0.06608703678760364,0.338592250974988,3.3975689810634773,-0.378407659974501,0.2564812176693705,-0.19096810094266936,0.13346839551520073,0.6269928226338486,-1.9399790048251329,-1.3175302785212581,-2.171540632460816,2.503550486380105,False,c1,3,"Screencast
When trying to add a new section and a reference list an existing template (defaultsort) gets removed, see screencast attachment.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11699}",55114,7,Needs Triage,False
-3.613417596087919,0.6120404191163349,-0.8906337686184767,-0.6094310921171588,2.7340528873706083,-0.9905270537616792,-2.601208624481778,-1.953864397477326,-0.7058994333488602,1.025766335853831,-1.5479965099301098,-2.506621342220119,-1.2116187963914289,0.5238029967538287,-0.04316939562315181,0.6110489593763082,-0.6636857552962278,0.7287549573165697,False,c1,3,"**Author:** `sumanah`
**Description:**
On mediawiki.org, I have enabled the ""Add an [edit] link for the lead section of a page"" gadget and the ""Enable section editing via [edit] links"" Preference (in the Editing tab).
If I go to a wiki page on mediawiki.org and click ""edit"" or ""edit source"" next to the title of an article (e.g., on https://www.mediawiki.org/wiki/Wikimedia_Labs ), then the VisualEditor link correctly thinks I want section 0, the lead section:
https://www.mediawiki.org/w/index.php?title=Wikimedia_Labs&veaction=edit§ion=0
but the ""edit source"" link thinks I want section #1 and thus brings me to edit the ""Background"" section:
https://www.mediawiki.org/w/index.php?title=Wikimedia_Labs&action=edit§ion=1
This may be a problem with the gadget rather than with VE, but it only started recently, so I think it might be a VE-related issue. (I have looked at Bug 51030 - ""Edit link for lead section no longer works"" which sounds sort of separate.) I shall also mention this bug in the talk page of the relevant gadget.
--------------------------
**Version**: unspecified
**Severity**: normal",54910,6,Needs Triage,True
-0.7128106936327185,1.5035595710197764,0.718869841264393,0.4844639429389479,-1.1510178597263299,0.6454262040570857,-2.4251570168110295,-0.041769733341238346,-1.5043147278673434,0.049816089889486825,-2.143610773636708,0.4819329223458906,0.46049586211816296,-0.869083392904785,-2.1061892130151576,0.02140177032235835,-0.683358678841735,0.7425210176363832,False,c1,3,"**Author:** `sumanah`
**Description:**
close-up of error message and greyed button
1. Try to use the VE to create a page at https://test2.wikipedia.org (while logged in, if that makes a difference).
2. Click ""Save page"" button.
The ""Save page"" button greys out and ""Error: Unknown error"" shows up to its left. The user assumes that the page has not been saved. But it has been created, e.g., https://test2.wikipedia.org/wiki/Kim_Stanley_Robinson .
By the way, if the user reacts to the error by clicking Review changes and then getting back to Save, everything works fine.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11279}",54908,6,Needs Triage,False
-3.336623937277847,1.0011645171507535,-2.6984837754998914,-5.773696948208836,7.431643181341144,-5.213640794189969,0.12690511449990627,-3.9235664571607765,-0.4565067741363532,1.6984466613886209,-0.7829848818959357,0.8268074546895667,-0.4361263143049694,-1.1768532349217597,0.7786503674479484,0.9216556113463935,0.46227214274954687,0.17665318258460716,True,c1,3,"This does not affect Firefox, from what I saw - I used Chrome.
I'd add a screenshot but it is really just as the summary says,
the number is there and it is working but you can not see it because the equivalent for ""Watch this page"", which is ""Aggiungi agli osservati speciali"", overlaps it (only the last word, of course).
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",54847,6,Needs Triage,False
3.037050516315014,-3.672740440780597,0.08757653538544474,1.8531131459412897,2.5425396708390213,1.2012912883261027,-2.086535086221544,1.1177898478415598,-0.899566768117581,-0.9460147336851885,-1.4904772896591056,2.3254464971606597,3.3501994613370707,3.3719911887028253,0.9541373643634614,1.175978086537547,0.48143450246043096,-0.5959376371286618,False,c1,3,"Screenshot 1
https://de.wikipedia.org/wiki/Knebel transcludes https://de.wikipedia.org/wiki/Konrad_Knebel
Only 2 lines are transcluded but the VisualEditor does not detect the end of the transclusion, see screenshot 1.
The other 3 lines are handled as content of this ""template"", see screeshot 2.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Knebel
**Attached**: {F11960}",54814,6,Needs Triage,True
9.756837492600788,-5.894617790869216,-4.875584455336906,-1.5421553175793363,0.1224309463553298,2.1607792129132957,-2.7678737646977973,0.8244929078915851,-2.9002514162616437,-1.9911773629325338,0.6545266491903998,-0.2864585780420389,4.441578951652843,0.8218052647842073,0.8005599692358887,-0.08631432607430684,0.5596331564767489,0.69449162127156,False,c1,3,"Input in VisualEditor and Output after saving (+ Parsoid Server output)
MediaWiki:
1.22alpha (ffa9b0a) 19:02, 11. Aug. 2013
VisualEditor (Version 0.1.0)(0e76b1b)20:01, 11. Aug. 2013
ParsoidServer:
commit 808cc39c81df83daaec458c81edbd126fd1dd19a
Author: Subramanya Sastry <ssastry@wikimedia.org>
Date: Mon Aug 12 16:15:24 2013 -0500
Adding more than one empty line isn't possible in the VisualEditor extension. Is this a desired behaviour?
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11917}",54798,6,Needs Triage,False
-3.7949038698444557,3.8034104583352324,2.12027670401584,-1.591173548403344,-2.236402520566908,1.318998472676652,-0.20705703381490714,6.106159338159205,2.972640028971499,-1.0400332256191422,-0.5157075331257857,-1.7250906193221869,-1.0906307171553955,1.1080572648971874,-0.8886723506491307,-0.30772137943057054,-1.640950408037524,-0.5323484953980027,True,c1,3,"Pages started with a copy/paste of layouts (i.e. http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Football/Players ) are very, very common. VE does not seem to support this right now, making VE a very secondary choice to create articles. Probably related to https://bugzilla.wikimedia.org/show_bug.cgi?id=33105 , please feel free to mark this as a dupe if needed. Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54787,6,Needs Triage,False
-8.43609203004461,1.1709030932410975,-0.6457066519283874,1.049498760521772,5.233808256181803,3.6265940519735675,-0.28437976570949264,-2.944080542375389,1.3666821439333905,1.6608658947777988,0.908867664408894,-4.125490823221864,0.9064876256586696,-1.83055531986128,1.5499120682432173,-4.508178927057719,-2.061085993933173,2.851329935340015,False,c1,3,"All the references adding in this edit: https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=568232613&oldid=568231803 were added using the ""use existing reference"" option.
It seems that only when I added the same reference on the same line (trying to reproduce a different bug) did it reuse the existing ref rather than creating a duplicate one.
--------------------------
**Version**: unspecified
**Severity**: normal",54755,6,Needs Triage,False
-1.9498459892827114,-8.2220917948783,0.21690075956047394,-2.8390700201416994,-2.7977630030779306,6.055827467662542,2.2777658778420156,1.4212461390590607,0.00513086751650621,0.26863211988373514,0.3716462320060838,-1.24683413473237,0.6538948814044745,3.7851117321473353,0.35927714325462645,1.9874788678904967,-1.4777035302651005,-0.37658678501192533,False,c1,3,"See https://pl.wikipedia.org/w/index.php?title=Wikipedysta:G%C5%BCdacz/brudnopis&oldid=37221362&veaction=edit for an example; only one citation appears as insertable.
--------------------------
**Version**: unspecified
**Severity**: normal",54742,6,Needs Triage,False
-3.4773697555627447,-2.2527920400982246,-5.611834600416083,-6.418143912279792,2.6881783942190896,-2.84222874498412,-1.4777927572339822,-2.6350649541468867,3.789455817346899,-1.4361348865135817,2.2707085259651785,0.8458295782997178,0.62931472478913,-2.537477038898222,0.8925165135060409,-0.14556428036029628,0.8773668545841995,0.5629204166526864,False,c1,3,"**Author:** `hagurganus`
**Description:**
When typing an edit summary in the Edit Summary window, I was unable to backspace. It seemed to let me highlight and _replace_ text, but even then, I could not highlight and hit the backspace key to _remove_ the text, I had to highlight and hit spacebar to simply enter a space, etc.
It could be that this is intentional, but I highly doubt this.
--------------------------
**Version**: unspecified
**Severity**: major",54733,5,Needs Triage,True
-7.911658719051685,5.695638390304463,-3.2807328790373074,-4.8566737521554595,0.6672186821608128,-1.2459924532288567,-0.6263380035298498,0.65073026497975,2.450718180954744,2.76642374357556,-0.30807465071377216,-2.34008820658658,0.70091201063941,-2.0438706391174,3.437454803347431,-1.292200018620839,0.7328832388980346,-0.7542914921867314,True,c1,3,"An editor reports that he lost his work when an extensive edit unexpectedly triggered the ""wikimarkup"" popup and - after he dismissed it - the ""save"" button became unresponsive. The button appeared as normal but did not react to being selected.
He was using Windows 7 and Firefox.
I reproduced this using Windows 7 and Chrome (didn't matter if I removed the wikimarkup or not), and on further investigation found that the ""save"" button will respond as expected after a delay.
The issue, of course, is that if this editor aborted his edit because he thought the system would not save, others are likely to think that as well.
Not sure if anything can be done to make the save button immediately responsive or to figure out why it wouldn't be or to make it apparent to editors that the option to ""save"" will return.
The conversation can be found here:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=567809017#Wikitext_error_message
--------------------------
**Version**: unspecified
**Severity**: normal",54669,5,Needs Triage,False
-4.898702135124134,-3.099980308972725,-2.6193431344998768,-1.3368080311305286,-4.801085304114443,-2.085507987728144,2.3320788062636355,5.018721451037679,-1.1520572771134345,-0.06987095060959625,-0.29115373069263306,1.0640380007286045,1.7310667716399886,-1.7799640780486117,-1.1377074917712422,0.17399028972429342,0.4611629794853871,-1.0952770892575288,False,c1,3,"en.wp user Ruud Koot suggests that certain tools, such as underline and font colour (bug 52645) that are not normally wanted/needed in articles shouldn't be available to new editors.
Personally I think everything should be available (this avoids the need for new classes of editor permissions) but just not shown by default. What is shown/not shown by default needs to be configurable on-wiki per wiki (and possibly per namespace).
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49617",54646,5,Needs Triage,False
-3.6628872526555787,2.7043124902243356,-3.3012610792286434,-3.0156497197061207,2.3549463432054427,4.049509703519398,0.12777984923220753,0.38234577673641146,-2.531804611713932,3.1458687102778784,0.6827420732079532,-1.4441219998353434,1.2039008165801905,0.2250537521549365,-1.081447059581798,-0.9560929759209529,-0.8500534168719308,1.1136586723213344,False,c1,3,"en.wp user Ruud Koot reports that occasionally he gets "" weird, random and unexplainable corruptions of wikitext on save"" when using the VisualEditor.
The only example he gives is ""e.g., a __NOTOC__ being replaced with a copy of the categories""
Bug 48231 might have something to do with this, but I confess to not understanding all the technical language there.
--------------------------
**Version**: unspecified
**Severity**: normal",54643,5,Needs Triage,True
-6.975504536563863,0.5990051564301186,-2.0404562197439535,-0.7613478684386887,1.4345749732781936,0.08986347180868437,0.9981296399821051,1.9211820707303704,-0.6974372212984074,0.7189364366924025,-1.1869381690163232,-0.3081474081773359,-0.45320286194091786,0.6704438839527622,-0.38049457526904895,0.18186636118453717,-1.9491036713732903,0.6534709033882116,False,c1,3,"en.wp user Ruud Koot reports:
""Occasionally, after a medium-sized editing session, the visual editor will silently refuse to save my edits. When clicking the save button the progress bar appears, disappears, and you stay in editing mode, with no new revision appended to the history. Trying again sometimes resolves the problem, sometimes it requires edit operations to be done in a different order or be broken up into smaller increments, saving in-between.""
He also asks, ""Do you keep any statistics on how often an editor presses the save button versus how many times this actually results in a new revision being saved?""
Bug 51423 might be related.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51243",54640,5,Needs Triage,False
-7.905441095321578,0.4757095733301604,-4.708454261657485,-0.44549759783998366,-1.5295393166817743,-0.9350724619200792,-0.6029669558291264,1.772026756849884,-2.676941406626912,3.28154668081274,0.3859922496115127,-0.20490015287279884,-0.21873669600094559,-2.2768882213102573,-0.5988355645836076,-2.2657397448730014,-1.793632326305724,4.693192812137413,False,c1,3,"en.wp user Ruud Koot reports:
""When performing structural editing tasks (i.e. things which are slight more complex than changing typos or adding a sentence in the middle of an existing paragraph) it is very easy to get the editor into some weird state where it is impossible to get out of other than aborting the edit session and trying again more carefully. This includes things like introducing ""bulleted headers"" and ""bulleted bullets"", which cannot possibly be represented as wikitext.""
He notes that ""Copying and pasting around text and editing pages with tables [is a] fairly reliable method"" to reproduce it.
--------------------------
**Version**: unspecified
**Severity**: normal",54639,5,Needs Triage,False
-9.36720224081759,3.6802007309699185,1.769649785168415,3.1797781625026973,1.0756724883349642,4.424329711467365,0.25954242740211253,-0.7042145792546401,1.9140593872340002,3.6482646476951803,3.0398880284145293,0.3629773543981092,1.5845188844171259,1.3516102988723047,-2.6608727180928775,-0.030848053885132676,-2.4427611997671175,0.04192847496887375,True,c1,3,"If a page starts with a bulleted list, there's no way to put the cursor ""in front of"" the list styling. If you want to add a non-list paragraph, you have to make a new, blank first bullet item and then remove the list formatting from the paragraph.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52032",54620,5,Needs Triage,False
2.1381006775992737,-3.4289917500761753,-1.2052022518741285,-0.21022242580992956,2.119144107528802,0.5809900683257088,0.13108932585495392,0.17149110667421202,-1.298054053265734,-0.14829595905424853,0.1878420278569104,0.09227739621963482,1.7348759631704507,-1.3865937158458492,-1.5176178614063067,0.30395673916224875,-1.8054572650249283,-1.7973912540735701,False,c1,3,"Today's Featured Article edit notice displayed in Firefox 22/Linux/Monobook on a 481px high window
Edit notices should scroll when they are larger than the height of the window. Presently the bottom of the message is unreadable. The screenshot attached shows en.wp's ""Today's featured article"" edit notice displayed in a 581px high window (which is what I normally use for browsing).
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51755
https://bugzilla.wikimedia.org/show_bug.cgi?id=52667
**Attached**: {F11480}",54602,5,Needs Triage,True
-4.287310950263144,7.297322566257083,-1.5066757385412473,-0.005853889350661223,1.2320678937004796,3.394421055890616,-0.10449122010337941,0.1194037825807161,-0.2195888405397748,-0.1256831870895203,-0.4951342111785011,-1.1210934565242483,0.14297702304413473,-0.5508420101585552,-1.426443559345958,0.3125692524858479,0.42597696048680067,1.0153527936791076,False,c1,3,"**Author:** `gnu`
**Description:**
The unusually buggy deployment of the VisualEditor has caused large numbers of English Wikipedia editors to have bugs to report. But the process of reporting bugs is a cumbersome many-step process -- starting with a requirement to ""log in"" using a credential that most editors do not have.
The rest of the Wikipedia universe uses a universal login system in which you log in with the same username and password to everything, and it all works together. Somehow Bugzilla didn't get integrated with that.
So instead anyone with a bug report for Visual Editor -- assuming they can even find Bugzilla, perhaps from a comment in an RFC about disabling the Visual Editor, as I found it -- then has to get through the ""New User"" process, which includes providing an email address, checking mail at that address, and accessing a URL which then demands that a new password be created and remembered.
This step should be avoided for logged-in Wikipedia users.
I'm sure that many, many Visual Editor bugs are noticed by editors, but are never reported due to the pain of the reporting process. This shortage of bug reports may serve the political purposes of the WMF in attempting to ram the new editor down the throats of the community, but it is not a good management practice, nor will it result in eliminating the bugs that make the Visual Editor too troublesome for naive use at this point.
(The remaining process of bug reporting is also cumbersome and complex -- but
in this bug report I have no suggestions on how to fix that.)
--------------------------
**Version**: wmf-deployment
**Severity**: normal",54595,5,Needs Triage,True
0.6160970299419604,-2.0408959309085333,3.730362977839704,1.18092926427861,4.45122282221317,0.8330437819248735,-2.2823821510151006,0.868688755284967,-0.1829718104585153,8.332827798909614,-2.251598194401951,0.15454739888470126,-1.4554766181382846,-1.1600491825750567,3.6173583948154375,-0.013859876137825744,-1.5794621335516774,-0.2738016462127202,False,c1,3,"From en.wp user Cryptic C62:
The beta button on the toolbar ""should not be labelled ""Beta"", not ""BETA"". The latter looks like it might be a mysterious acronym. ""
--------------------------
**Version**: unspecified
**Severity**: minor",54586,5,Needs Triage,False
-9.2040269261647,5.408831392204274,-2.3049659778296494,2.090684304623986,0.7545478498756999,1.2214286842682716,1.6626169850747141,-1.4219078090481778,-2.0241633865968165,-1.2658637204329768,0.46456531808743007,1.2375055147632954,0.01875128114299418,-0.6324820629842449,-0.23823603179051123,1.3058757033427748,-0.5262287451139295,-0.16741433516214532,False,c1,3,"Where articles use the {{ref}} and {{note}} pair of templates to generate footnotes, e.g. [[List of highest points of Canadian provinces and territories]], it is impossible to edit the contents of the notes in VisualEditor.
The {{ref}} template is editable in the transclusion editor, and works as expected.
The {{note}}-generated notes are apparently one block. No transclusion icon or indication of uneditablility (green stripes) appears on mouseover or when the block is clicked.
If a link in the notes is clicked it functions as a link would in read mode- ie. the link is followed and you leave the page. VE gives no warning about unsaved edits (although Firefox does).
If the backlink to the location of the {{ref}} template is clicked it functions as above - i.e. it loads the page in read mode at the position of the note, exactly as if you had followed a link to that anchor from any other page on the internet.
It is possible to select the block when selecting content before and after the block, although no indication is given that it has been selected. Once selected it is possible to apply bold/italic formatting to the block and other selected text using the B/I buttons, but it is not then possible to remove it using these buttons while the note block is selected. It is possible to remove bold/italic using the clear format button. The clear format button does not remove any links in the notes block, but does remove links from any other text selected at the same time.
--------------------------
**Version**: unspecified
**Severity**: major",54579,5,Needs Triage,False
-2.6867353718576656,5.7502277762014415,-0.337678258123697,-0.6774970115641247,-1.1074904780048698,1.49069419962559,-1.3511601302849972,3.5416838791354124,-2.190057120425566,-2.3754686836820262,-0.40950719596137475,-0.5696926813220208,1.304860424581007,0.8658952782652918,-0.022332768282407045,-1.3022326056362188,0.1633051229914828,-0.5272477255576091,False,c1,3,"When a user has installed a gadget that relies on data from an external server, VisualEditor appears to wait indefinitely for that server to respond. Normally this is OK, but when that server is down VE will apparently wait forever (or at least longer than the 5 minutes I was prepared to wait) for a response.
The source editor appears to give up after a wile (2 minutes?), and loads as if the gadget was not called. VE should exhibit this behaviour too.
Tested with the HAPPI gadget ([[User:EpochFail/HAPPI]]). As of 21:52 UTC 05 August 2013 that gadget depends on a server at wikipedia.grouplens.org that is not responding
--------------------------
**Version**: unspecified
**Severity**: normal",54563,5,Needs Triage,False
-1.3815812098880644,-2.880827288506664,-3.638778245084687,2.8910602501584206,-1.379036911117462,1.5711676352216595,-4.492439653144257,0.3041098667574813,-1.0939867345062873,-0.848386043053512,-1.5899740819305692,-1.2475850960030368,0.3705167302533572,-2.8080992721562295,1.0995283387506225,-1.0567303740096718,0.10504513241703206,0.1684220133679275,False,c1,3,"At line 42 of https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&diff=567254040&oldid=566841354 attempting replace what appeared to be an empty image caption with ""The [[Sun]]"" (using ctrl+k for the link, no wikicode) resulted in the insertion instead of:
The <a style=""white-space:nowrap"" data-mw=""{"target":{"wt":"val","href":"../Template:Val"},"params":{"1":{"wt":"4.6"},"ul":{"wt":"byr"}},"i":0}"" rel=""mw:WikiLink"" href=""Sun"">Sun</a>
The images were left over from testing for Bug 52341 and so that bug may be related.
--------------------------
**Version**: unspecified
**Severity**: normal",54544,5,Needs Triage,False
-11.644912533739896,1.672312082691871,0.4368045404373113,10.022946715511644,-4.521319153189118,0.39594626886907625,0.617421390716455,0.6643966065751231,5.278705900293976,1.981459513644431,0.3359918664225483,1.5368410380680146,1.0997154469767545,-0.03811808973313191,-0.20139345729153124,-1.0216156351894665,0.10325022365591141,2.8030375561479985,False,c1,3,"visual editor easily doubles mouse clicks and key presses. this can be seen, amongst others, on section editing, saving, adding a reference. to avoid bug reports in the line of ""please remove one mouse click while creating a reference"" create a (visual) design guideline mandatory to follow for all developers to minimize mouse clicks and key presses, and maximise screen estate available for editing/viewing the article.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54520,4,Needs Triage,True
4.937324328335105,-3.709388573883958,-2.9869395786162745,-3.7802324038729953,0.9601478944778934,-5.788316073443438,1.3879089707852978,0.4519262597170889,2.067724598253096,-1.7565022759239075,-0.43548000058841474,-1.0652468881998347,-1.149854057446296,-1.221734382345498,0.33853391790079623,2.7859793651050424,-1.0545518381046957,0.7217921104167917,True,c1,3,"Currently, De.WP talk, user talk, Wikipedia, Wikipedia talk..pages show for the last section not [Edit source] as En/Es/xy.WP do but [Add section / Edit source code / Add section] (Abschnitt hinzufügen Quelltext bearbeiten Abschnitt hinzfügen). It neither breaks anything technically as far as I can tell right now nor does it mix in VE interface but, where ever it might come from, it should be fixed asap
http://de.wikipedia.org/w/index.php?title=Diskussion:Immanuel_Kant&oldid=120880638
http://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:JEissfeldt_(WMF)&oldid=120853192#VisualEditor_.2A_Projektseiten
--------------------------
**Version**: unspecified
**Severity**: critical",54491,4,Needs Triage,True
-4.868369659817988,4.940513073612198,-2.2266232910698562,-3.4073768308208026,-3.6823800902878188,0.7531819191490592,-0.5077971045752587,2.404560549743223,7.348483939408457,0.9407279363609611,1.2763557693063015,5.572901421672553,1.0891230170230939,-1.5676724075394204,2.630307958284292,-0.23878905824539498,-0.9913444636382955,-0.15164128281923306,False,c1,3,"It would be helpful to be able to selectively disable VisualEditor (we should to indicate to a user who'd otherwise see VisualEditor that it is disabled, to reduce confusion). This would enable users to shield pages where VisualEditor/Parsoid cause roundtrip issues.
A hidden blacklist category could be included in a page or template to achieve the desired effect, and could be used by developers to prioritize roundtripping issues.
--------------------------
**Version**: unspecified
**Severity**: normal",54489,4,Needs Triage,True
1.8397072871426325,-0.6714110529980228,1.6782598701181435,3.2927454313961846,-1.0003987498991342,0.324323490306645,3.3736351160738183,0.6635853349235188,-3.1766281239899508,-0.07323283477305687,1.1038772958884455,-0.7689616882090045,2.586730287615178,4.147224204940304,-0.4451358194533084,0.42171873268304655,-0.560130080170254,-0.4532095534467335,True,c1,3,"If one opens the VE editing interface, the user experience in relation to image formats varies significantly. The report:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121153156#Bilder_werden_im_VE_kleiner_angezeigt
has several examples with different browsers like
FF 22 / Win 7: edgewise images smaller; rest bigger.
Chrome 28 / Win 7: all significantly smaller.
See also screenshots in perma link.
--------------------------
**Version**: unspecified
**Severity**: normal",54487,4,Needs Triage,False
1.8916351815098076,-5.170326051554671,-6.930348627146593,-2.3649478932445565,2.1500491705372595,0.40164715067354506,-3.01595672611559,0.022957614955319394,-2.535196030773685,-2.899977699317044,0.43703054569566424,0.76160943524498,-0.3152318198904762,-1.6146529164709755,-1.634478193982312,0.5399737589073429,-1.0974541883779394,-0.8955419894808467,False,c1,3,"The displayed table (Firefox 22/Ubuntu)
See [[fr:Special:redirect/revision/95505705#Pr.C3.A9sidents_de_l.27universit.C3.A9]]
The lines of the table using {{ligne grise}} are uneditable because of {{ligne grise}} (which just adds bgcolor=""#F2F2F2""…). But they are displayed wrong (see attachment) because the <tr> is wrapped in a <span>. Not really WYSIWYG…
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11257}",54485,4,Needs Triage,False
-3.4949173121973254,4.322028855579802,-2.02488655127876,1.2233284251780452,0.5549514661105628,-1.6184809034199001,-0.5134117952094099,0.7076799928406738,1.162317304349674,-0.883349585741843,-1.419622348743098,1.4354882247879421,0.04992737171274708,-1.2183033350005381,-0.3174253668055016,-0.9370027195257307,0.0893691115654518,0.9799520415900649,False,c1,3,"**Author:** `kwwilliams`
**Description:**
http://en.wikipedia.org/wiki/User:Kww/singlechartreftest is a simple test case for accessing references created by the singlechart template.
Singlechart directly creates references when called, using #ref (it cannot use <ref></ref> tags because of issues involving the parsing sequence of templates and references). It will either create them with a default name that it generates algorithmically, or it will use the value of the ""refname"" parameter.
When editing http://en.wikipedia.org/wiki/User:Kww/singlechartreftest, if the editor attempts to insert reference and chooses the option to ""use an existing reference"", three of the existing named references (sc_BillboardHot100_The Hollies, sc_Norwegian_The Hollies, and sc_Dutch100_The Hollies) aren't displayed at all. These are references that are available for the editor to use, but have not been currently reused in the article text. An examination of http://parsoid.wmflabs.org/en/User:Kww/singlechartreftest shows that Parsoid did pick up these names so VE should be able to display them.
sc_UK_Hollies is displayed, but no text is associated with it. Similarly with germancharts. Attempting to include these references works. Both of these references should have the full reference text displayed, although the editor should not be permitted to alter it.
{{Certification Table Entry}} and {{albumchart}} should have identical problems.
--------------------------
**Version**: unspecified
**Severity**: normal",54478,4,Needs Triage,True
-1.667153849400945,-2.268128041098768,-1.6383594917906912,-2.2407437818719353,-4.8065556556906195,2.501955028104322,0.9065821112611872,-3.306635269577706,0.7083268253576973,-0.3987326197668457,-0.42382397183049214,0.023130442388158645,-0.10616347960349248,0.6694502428720766,-2.155220854686786,-0.6612248933246794,-1.0211062543476799,-1.5062881568568585,True,c1,3,"http://en.wikipedia.org/wiki/.tl for instance,
if you click on the Edit tab, nothing will happen.
--------------------------
**Version**: unspecified
**Severity**: normal",54467,4,Needs Triage,True
3.2135722832245457,-3.029432634012254,4.428211381656784,-0.4558039531027308,0.9772649400587423,2.944733541457432,-2.51293528685811,-1.5960054933033199,2.1650504371903594,-1.2583436412554647,-0.3082750929764888,-2.0472207293920928,1.8300634920437107,-2.3543190820943196,-1.8412037269886068,-0.49193976465511624,0.860119974641018,-1.2380705243809782,False,c1,3,"Toolbar mixed with #p-personal
See the image. And I got the opposite, the toolbar staying at top of the article.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52504
https://bugzilla.wikimedia.org/show_bug.cgi?id=52326
**Attached**: {F11123}",54433,4,Needs Triage,True
-3.539864620160343,-5.141942692899413,-6.965970559607236,-2.360150428554655,0.9238271980364512,-3.007421930947496,-2.2126034039111655,0.9894281418995842,0.8568363624167383,-2.183571599455686,3.3423318314606747,1.2393525348259138,-0.5703372719232229,-1.0202338466756342,-1.8914666892491803,-0.9763053042804202,-0.18902503040981689,2.1046189760419836,False,c1,3,"1. Got to [[fr:Disjonction logique]]
2. Edit it with VisualEditor
3. Try to modify the table. You will get a big blue rectangle allowing to edit {{clr}}, but you can’t edit directly (clicking on headings and using ↓ works) the <td>.
Of course, there is no reason why this article uses float & {{clr}}, but I know some similar cases where it is useful to have floating tables + {{clr}}.
--------------------------
**Version**: unspecified
**Severity**: normal",54431,4,Needs Triage,False
-2.9321280378652013,-5.4990171001700325,-3.946137724178616,0.3166650241822828,-0.6769437042099733,1.1283824386877999,-3.8727195032324455,0.854173099358371,0.4571892566772704,-2.212965341822211,3.801047946941132,-0.771068426566524,-1.003763308821016,-0.3931045435102529,-1.0421315197813525,-0.6408974359145213,-1.427825258281111,0.7398034921384082,False,c1,3,"Sometimes when entering a link in the link input widget the first suggested target is automatically inserted, even before you finish typing, making it very difficult to choose a different target.
Steps to reproduce:
1.Load a page in VE
2.Press ctrl+k to enter a link
3.Try to enter a link to [[Portable Document Format]], [[Classic (album)]] or [[Thing (assembly)]].
--------------------------
**Version**: unspecified
**Severity**: critical",54421,4,Needs Triage,True
13.734984420906489,-5.20626138757671,-0.47159934504523093,-2.8368904219865385,5.593045900217485,-1.33623809843969,-0.5871829165284135,-0.8828227978117557,0.24766227749516212,-2.169059165908576,-1.1058502458053507,-1.1176560659879478,0.8373104132173195,-2.0899523309442154,-1.7654665638362532,0.35661669206650604,0.1779408408866332,3.282022548284816,False,c1,3,"- Chrome 30 (canary)
- https://en.wikipedia.org/w/index.php?title=Narayana_Gosain_Temple&oldid=565414421&veaction=edit
When selecting the following:
> <selected>
> h2.Transport
> p.It is situated within 20km from NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar.
> h2.References
> references.
> \n
> </selected>
> \n
> h2.External links
.. and cutting it, and then ctrl-Z. It restores both content and selection properly
When selecting the following:
>
> h2.Transport
> p.It is situated within 20km from <selected>NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar.
> h2.References
> references.
> \n
> \n
> h2.External</selected> links
.. and cutting it and then ctrl-Z. It restores the content properly, but the selection is restored only within the first paragraph:
>
> h2.Transport
> p.It is situated within 20km from <selected>NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar.</selected>
> h2.References
> references.
> \n
> \n
> h2.External links
--------------------------
**Version**: unspecified
**Severity**: normal",54410,4,Needs Triage,False
-3.6434051345465157,1.0718831024522562,0.5685693005382539,1.822320666124337,2.2009924427066947,-3.297128927287715,-1.1150413161234818,-3.182303262850144,-0.48969251602792335,-2.1587893301402743,2.3079023373946774,-1.8508265914332254,1.219077271707325,1.171287776810578,-0.18248435983605482,-1.4656838872795777,-0.40225357319492305,-1.0927097406821926,False,c1,3,"Screenshot: 2 extra bullet points & template content edited
Browser: Firefox 24
When editing this page[1] on sv-wp two weird things happen:
1) The bullet point on the bottom of the page duplicates into three bullet points
I expect it to show one bullet point, like when viewing the article.
2) I can edit the text of the template used in the list[2], though when I check the diff, it hasn't detected that I edited the template text
I expect the text of the template to show a blue background when clicking on it and *not* be editable.
[1] https://sv.wikipedia.org/w/index.php?title=Byrackorna&oldid=22981861
[2] https://sv.wikipedia.org/wiki/Mall:IMDb-titel
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:Skalman/bullet_point_test
**Attached**: {F11912}",54374,4,Needs Triage,False
-4.432356276537021,-3.66480328562311,7.151005515882893,6.314048002718427,-7.5626290681794845,-5.043081544049012,3.5876089759000225,1.2097817138504396,0.8518618506450295,-2.267614460816104,-4.250246491191854,0.2352591375518034,-2.6172028468801622,0.0872654317349264,0.07275859124692197,-0.6961134736733465,0.7169484464824272,1.5269699863849275,True,c1,3,"Request to introduce drag and drop for text passages; there are also bugs for images around (obviously).
Report:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121095343#Drag_.26_Drop_von_Textabschnitten
--------------------------
**Version**: unspecified
**Severity**: enhancement",54364,4,Needs Triage,True
-2.8602569306625787,-5.021487585949931,-5.952894412071501,-2.4602190664249757,1.5315715789548237,-0.23245760234059765,-0.9446575001908082,0.2178745887094497,-2.1204333065655043,-1.0905875818084243,1.226730419979853,-0.038492051705061536,-0.005788134597118244,-1.6090767996991193,-1.5708405097970712,0.1475512981965724,0.21710439357934574,-1.4388169100231427,True,c1,3,"https://pl.wikipedia.org/w/index.php?title=Octan_etylu&curid=217010&diff=37144425&oldid=37144363
This may be a template that got subst'd in VisualEditor. It produces this text:
<div class=""do-not-make-smaller refsection references-column-count references-1column"">
<references />
</div>
Something sensible ought to be done with this, but I'm not sure what the right answer is. (Yes, that's in English, even though it's not an English-language project.)
--------------------------
**Version**: unspecified
**Severity**: normal",54307,4,Needs Triage,False
1.2801500282425073,5.622687850892525,6.977951261204595,1.8515752970028014,-5.984058691259868,2.547664326245581,-1.3696467712761544,0.21563588454525717,0.16902053602838918,-1.6643588225779276,-2.026176711098527,0.20930764441044003,0.46724606293442905,-0.8936159347763715,-0.2596085221158857,1.1863288652313313,-0.39923014843688964,-0.01726032369354491,True,c1,3,"Image of issue
Upon loading VE in Thai wikipedia in an article with a bulleted list, spaces are added after bullets in the edit view. Attempts to remove the spaces remove the preceding bullet. Spaces are not added upon Save, but will lead to confusion for editors.
Duplicated in FF, Chrome. Ubuntu, OS 10.6.8
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11736}",54291,4,Needs Triage,False
-9.035662439436864,6.117728851181738,-3.0455455649239926,1.501829577680088,-1.2660163393790345,-1.7723570890887075,-0.44059231983116653,-2.230261376919675,-1.4113534289649208,-1.828113972083107,1.9321296996355968,-1.4548439105059234,-1.241655782293229,0.597864439860369,-1.3541428003865494,2.5874198536109168,-1.794820129146863,-0.980230388091597,False,c1,3,"link target takes over media settings dialog
If text has a size specified, e.g <font size=12>, then you cannot edit it in VE at present. The bar that notifies you of this is fixed to standard line height so you can click on links that extend above or beyond this, e.g. <font size=12>text with a [[link]]</font>.
If such a link appears in body text, then clicking it takes you to the link target in the same window (i.e. exactly the same as if you clicked on it in read mode). If you ctrl+click to open in a new window/tab then you get the same behaviour as described for section links in bug 51122.
If such a link appears in an image caption, then ctrl+clicking has the same effect as in the paragraph above/bug 51122. Left clicking does take you to the linked page, but instead of using the main window it uses the media settings dialog's frame (see screenshot). You cannot close this frame - the close button has been replaced by the link target and it doesn't respond to escape.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11727}",54285,4,Needs Triage,False
-1.529617316346247,-0.08563902344395835,-0.35544190302713297,-3.171724722371676,-5.53852812839712,7.080738102542845,2.635515938400922,-1.8430356823599041,-2.199378093373994,4.499995496878622,-0.31354830680358825,0.42472052109810643,-1.4792850003080344,-1.12557537236873,3.76679530719741,-0.9209129575135722,-1.258509505973326,-0.04286685493088216,False,c1,3,"A user at en.wp comments that VisualEditor looks best in the Vector skin, but that it would be better if ""manual CSS theming"" were supported.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54270,4,Needs Triage,False
-3.921267884598267,-2.1648717263669095,0.5676460154343417,-3.46178489625044,2.8115047147779113,3.9537554525536818,-0.4135218542336414,1.936130351504009,-2.1476196598067716,-2.339896768346961,-0.32237423546075084,-4.096452741116667,3.4085380500621945,-2.615595817687722,6.9587089008505805,0.3431143693218903,2.8498648106176896,-1.8559323524367903,False,c1,3,"References 5-8 were not saved
At https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=566402676&oldid=566401436 only four of the 8 references I added were saved.
The second references for each statement had the same title as the first but were a different URL. They appeared in the editor as being there (see attachment) but were silently not saved.
--------------------------
**Version**: unspecified
**Severity**: critical
**Attached**: {F11698}",54269,4,Needs Triage,True
-6.161200062688115,-0.7631494731481823,1.8791224042274841,-1.5209383708221462,2.138569519258905,0.8296253095868191,3.5371924896025897,1.6678211012776458,-1.2493147922173247,-0.6080184996658007,-1.839567327691055,-1.6064143092187966,-1.688886127968395,3.669416110340997,-0.08645372845575228,-2.052849726334818,1.0301201956414545,2.554095608526179,False,c1,3,"At line 138 of https://en.wikipedia.org/w/index.php?title=Wikipedia&diff=566045928&oldid=566042453 parsoid (presumably) has added nowikis around around a space following a HTML comment. I don't know whether the comment containing references is relevant or not.
--------------------------
**Version**: unspecified
**Severity**: normal",54266,4,Needs Triage,True
-8.622148865276285,-1.8574097136920855,-5.251298143316463,0.07516322519717478,2.9307334793992483,3.2290970838612543,3.589640654410606,0.7617967976113577,-1.355464642468814,2.699438978124638,1.4592351509077948,-3.0420977306640298,-0.19503202755902027,-0.2406404129099906,0.7885709858780059,0.42121267128273593,-1.2286960340126056,1.3313856140972373,False,c1,3,"The wikitext insertion warning now works, and is visible regardless of the position of the user on the page.
However, its color scheme is the same as other regular, confirmation-type notifications like ""you've added this page to your watchlist"".
Wikitext insertion is an actual problem, rather than ""just"" a confirmation or feedback notification. We need it to be more visible, possibly by using a different color scheme. Maybe not a big red blinking bubble, but something more noticeable than a white bubble with a light blue border.
--------------------------
**Version**: unspecified
**Severity**: normal",54264,4,Needs Triage,False
3.864225040966432,-1.3805170095126549,-4.475970713701518,-4.454253281286755,-1.638549852839128,-0.3429625409808811,0.19287156379252934,1.0522040445609289,-5.27025621448418,-2.5035672873974546,1.7583663627734842,2.9510363295838955,0.00045085920943321867,0.5174668672593299,3.2343868216304186,0.019589380135073164,-0.06656571121529065,-0.859412089119665,True,c1,3,"Labeled Section Transclusion (<section begin=""2012-07-monthly""/>Text here<section end=""2012-07-monthly""/>) is not supported. This is used for status reports on MediaWiki.org. The first step is to alienate it. Currently it is treated as raw text.
--------------------------
**Version**: unspecified
**Severity**: normal",54252,4,Needs Triage,True
5.020501919390043,-11.315526547804286,1.6087127443105658,-1.620296608480082,-2.536175279887044,1.6599019642552866,0.8505538146639102,-1.0237852524795288,-1.3202555491730292,-0.8515022622444155,-0.828776389210792,0.8533597000697595,0.7600489104392048,-0.5133840000357601,-3.229830723587422,0.12788504393272324,-0.6080087207235783,-1.1665232406811064,False,c1,3,"Screenshot of problem
See screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11666}",54251,4,Needs Triage,True
-6.6134691534321,1.3958676725228365,-2.044776836981491,3.8340780908039216,-0.030769619001492443,4.361629428227276,-2.711568428976915,0.11521909199516062,4.0192624591876465,-0.4226828543695724,-0.48854645579633527,1.7726863820681935,1.6280753201585467,-0.60386629369739,0.21214604088191447,-0.34989175293032504,0.030970069020074042,-0.6631501616742845,False,c1,3,"One of the biggest interface issue is the new reference dialog. The use is presented with a window and no real guidance on what to do.
Some brief instructions guiding the user to choose an appropriate citation template would be good. This obviously needs to be customisable on a wiki basis. For en.wikipedia you could have something like
""To add a reference please choose a citation template like {{cite web}}, {{cite journal}}, {{cite book}} or {{cite news}}. Click the jigsaw icon to insert one of these templates.""
The message could be specified by a page in the MediaWiki: namespace.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54250,4,Needs Triage,True
-0.3983815140510427,1.8966288864757814,1.9615988004036424,0.6890135589274466,1.032498407461703,3.777203971844176,0.4302351228869199,2.994794028083945,-1.5879186165140782,0.7181195667970339,1.3791209520518053,2.4623572912367786,2.663574873630992,-0.8263681997441727,0.6899259112521765,1.3724312611085454,2.3139024116712887,-0.20861733405213223,False,c1,3,"The Behavior switches like __TOC__, __NOTOC__ are occasionally useful in the article space and __NOINDEX__ is a useful in the user namespace. Some way to insert these in visual editor would be handy.
Bug 49996 and Bug 50855 also address magic words, but don't seem to cover the Behavior switches.
This was discussed at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Some_ideas_for_29_July
--------------------------
**Version**: unspecified
**Severity**: normal",54248,4,Needs Triage,False
3.2529039024654476,-16.306934340233855,0.5609084494865044,-5.110128581796272,-0.22625561653884207,3.30379009771411,2.7702629870095405,3.3483499643211627,2.6066852147279533,2.042460637908695,2.415865002481705,-0.9172813312061732,1.1357369960927075,-0.07697415251270723,-1.2312199362093557,-0.0063707694361407885,-1.0984300864251175,-0.992000450284937,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=Cruz_Azul&diff=564888460&oldid=564725284 - very strange.
--------------------------
**Version**: unspecified
**Severity**: normal",54242,4,Needs Triage,False
-2.57587563374479,-0.027212678153986758,0.815068317691388,-0.8475058105059936,-2.0219352288255665,-2.21059736027987,-0.5997645996313956,-2.1936036517763067,-0.7433161341655873,-0.40528581644399697,-1.632941101911041,-0.31959337468990023,0.8769517048924005,-1.0765403150057944,-0.44354795692178506,0.3792268212995677,-2.1933969959877215,0.10045554586749339,True,c1,3,"Inserting media, namely images, into complext tables leads to problems. A user tried to put an image into a table listing Intel CPU sockets on De.WP and the search function went back and forth in being able to find the image he knew was on Commons and how it is labeled.
Table:
http://de.wikipedia.org/wiki/Prozessorsockel#Intel
Image:
http://commons.wikimedia.org/wiki/File:Intel_Socket_1150_IMGP8593_smial_wp.jpg
The file fails to show up, if you put its name in manually once you reach ""5""
Report:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121004381#Bildeinbindung
--------------------------
**Version**: unspecified
**Severity**: normal",54218,4,Needs Triage,False
-5.1494219401424495,6.91433280257181,0.410953625026238,2.848631340636136,4.006505994065797,2.314778285067474,-2.2830224225194917,-0.3687929240669756,-1.4518072754761386,-2.6556640859559333,-1.8071111122435675,-0.796979093017661,0.34146119631046723,1.8377955896217797,-3.0480720472024676,1.6901876524702837,1.314403489248438,0.4004455536587568,True,c1,3,"If one tries to move a reference using Ctrl + X to pick it out, Ctrl + V doesn't work, i.e. the reference doesn't seem to be stored in the clipboard.
If one selects the sign to the left of the reference as well, Ctrl + V provides the reference number but not the content, which gets lost.
If one selects the sign to the right of the reference as well, Ctrl + V provides the sign to the right but the reference gets lost.
If one selects a sign to the right and to the left of the reference, it works.
Report: http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=120995561#Einzelnachweise_in_der_Zwischenablage
--------------------------
**Version**: unspecified
**Severity**: normal",54212,4,Needs Triage,True
-0.18601195413617777,0.9960573540113717,-5.740648693521104,1.239921435660626,-2.5244773800118443,1.504269493371228,-2.262802054974369,1.126805816085045,-1.125174669539243,-2.5266937706778845,-0.4576216405317095,-2.0376421490918455,5.440560743363358,1.3875533599424488,0.4057727694395723,-1.1678390042529876,0.2353217320379386,-0.48089150182299023,False,c1,3,"Screenshot of VE on an iPad (3rd gen, iOS 6, en.wikipedia.org)
Dimensions Dim.. without OS menu bar
iPhone / iPod 320 x 480 320 x 460
iPh?o.. Retina 640 x 960 640 x 920
iPad (portait) 768 x 1024 768 x 1004
iPa.. (landscape) 1024 x 768 1024 x 748
So that means at least under 1024px (not accounting for MediaWiki sidebar, that is to be subtracted from that)
Measuring on my MacBook Pro in latest Chrome I measure exactly 1281px as the minimum window width to have the toolbar be one line. 1331px to account for vector-hd mode and allow a bit of breathing room between the left and right half of the toolbar.
When at 1281px, the width of just the toolbar (subtracted the mw sidebar) is 1103px.
So, a lot to cut down on. Any ideas?
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11563}",54205,4,Needs Triage,True
3.105450636769666,-2.9404763367843305,0.8388976135233293,-0.673692589811469,-1.9418621507569274,1.3115530927066266,0.8509711367998749,2.253073341693712,1.0903954617299239,0.11829876860743038,0.5455943705082835,4.39799267426095,2.1620273665039607,-0.849110731733119,0.5111609369913834,-2.5117395490448144,-0.7460321235512859,4.425502901818754,False,c1,3,"Per http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Content_transclusion_causes_WTF_mode
If trying to add a template, only adding content (empty) and click apply, following error is thrown:
TypeError: content is undefined
http://bits.wikimedia.org/static-1.22wmf11/extensions/VisualEditor/modules/ve-mw/dm/nodes/ve.dm.MWTransclusionNode.js
Line 192
--------------------------
**Version**: unspecified
**Severity**: normal",54198,3,Needs Triage,False
-6.7949136482486026,1.0039035957659177,-3.302618581922456,-2.046670395900838,2.806291968588046,-1.5328047385653916,2.3976626445981504,-1.4886270716302104,3.6682844383141875,1.100012892580322,1.5498267274683415,-1.4543073272035891,-0.3592914358107304,1.4427239963784064,-1.9699705929296534,-1.578683617485137,-0.39544195548935845,2.8309319388920624,False,c1,3,"Unlike the standard source editing windows, VE doesn't confirm closing the page if you have made changes, making it very easy to accidentally close a tab and lose all of your edits.
--------------------------
**Version**: unspecified
**Severity**: normal",54169,3,Needs Triage,False
-2.7127366900763885,-6.56248381074892,-4.161853131521967,-3.427852444347375,3.661825622044217,-4.601173058993283,1.1119389373072615,3.2694555347190497,5.605196313346571,3.4293360372163217,0.6129906378777008,-1.0625244628375312,-0.3826999711891048,0.21968921486991544,1.1884043030768359,-1.0297287551859704,-3.0162504820513063,0.26604215844998946,False,c1,3,"""Wikitext markup detected"" message should disappear automatically when there's no more wikitext. Now the user must click it to make it go away.
--------------------------
**Version**: unspecified
**Severity**: normal",54155,3,Needs Triage,True
2.1802433534590766,3.7507217578900054,-0.4761055270712031,0.5586436831926858,0.012215665918138052,1.306110013699224,0.1523012881814383,2.078603992546984,0.29290609844152293,1.2741539181848651,2.2724448662768,0.7634326978489416,-0.3674409971392283,0.4512762097320486,-0.29534010328827964,-1.6486164666651648,-0.4655523218263433,-0.1784423162875468,False,c1,3,"Tested on Firefox 22, Monobook and Vector skin. DOES NOT seem to affect Chrome 28 on Vector.
Steps to reproduce:
- Open the [[Olive Branch High School]] in the visual editor.
- Press CTRL+A to select everything on the page.
- Press Delete.
The result will be that the entire document becomes uneditable since there is no editable section anymore that the user can click. The console will report the error:
- ""TypeError: node is null""
If you don't click anywhere else after pressing delete and start typing the visual editor will behave extremely wonkey. I have seen behavior that ranged from adding an unending steam of pawns to cursor focus jumping all over the page. Additionally, the console will fill with a hailstorm of errors (Below is just a small sample).
- Error: ve.dm.Document.getNodeFromOffset(): offset -1 is out of bounds
- TypeError: parent is null
- Error: Unbalanced set of replace operations found
- Error: Unbalanced input passed to document
- Error: Invalid retain length, cannot retain backwards
The above is likely just a consequence of the deletion . If i look at firebug's output it seems that Ctrl+A will delete these lines:
<p data-parsoid=""{"dsr":[0,45,0,0]}"" class=""ve-ce-branchNode"">
<span class=""ve-ce-branchNode-slug ve-ce-branchNode-inlineSlug""></span></p>
--------------------------
**Version**: unspecified
**Severity**: normal",54125,3,Needs Triage,True
-3.653962243017954,-2.9249850096525005,-1.5755228771694885,0.9100478166727242,2.357395904082559,3.844082450763672,-0.37235130364273594,0.386967779884149,-3.2587789407885523,-0.9278843224761211,5.60557497157736,-2.9669716226936362,-1.1155164347057571,-0.2739371497871286,1.5484134048050242,-2.8784302468170044,-0.9110964269245845,-0.44033849144598514,False,c1,3,"en.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a <br clear=all> was duplicated minus the leading <
Possibly related to bug 51304?
--------------------------
**Version**: unspecified
**Severity**: normal",54124,3,Needs Triage,True
12.036869241811225,3.639840602901021,4.069420456986098,-2.5947769731298633,3.452330904847431,0.1009529653276855,-6.405440087820276,1.5884580730283893,0.011887227582002557,1.9368733938628786,-1.5866381781112593,-0.35121510612660023,-1.7908382900124646,-1.3339876852048,1.3582113919498164,0.4514342195950559,-2.3535276265533294,0.31585662637377543,False,c1,3,"(Tested on Firefox 22)
It seems that the ""&editintro=Template:BLP_editintro"" URL is accidentally reversed on Monobook.
Steps to reproduce:
(Vector - Working correctly)
- Navigate to [[Martin J. Silverstein]].
-- The ""Edit"" link will be: https://en.wikipedia.org/wiki/Martin_J._Silverstein?veaction=edit
-- The ""Edit Source"" link will be: https://en.wikipedia.org/w/index.php?title=Martin_J._Silverstein&action=edit&editintro=Template:BLP_editintro
(Monobook - Working incorrectly)
- Navigate to [[Martin J. Silverstein]].
-- The ""Edit"" link will be: https://en.wikipedia.org/wiki/Martin_J._Silverstein?veaction=edit&editintro=Template:BLP_editintro
-- The ""Edit Source"" link will be: https://en.wikipedia.org/w/index.php?title=Martin_J._Silverstein&action=edit
As far as i can see only the source editor can load a template when using the ""EditIntro"" parameter in the URL. In monobook, it seems that the EditIntro parameter is accidentally added to the Visual Editor link instead of the Edit Source link.
--------------------------
**Version**: unspecified
**Severity**: normal",54116,3,Needs Triage,False
11.014952124694833,-9.577921480289454,15.299837632649417,-1.9141582714517202,-2.9087544300866446,1.0760273000696465,1.4060286497866112,-0.7799799805675737,2.84909342721239,1.0360313465817965,0.6626397260626455,0.7709211371814957,0.3561936775070018,-1.5201328412126003,0.02817175714461051,0.7424302130527505,2.475654660126118,0.705217904537579,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=Karma_in_Hinduism&diff=564615505&oldid=564615290 and https://en.wikipedia.org/w/index.php?title=Karma_in_Hinduism&diff=565801063&oldid=565800169
Reproduced at https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&diff=565853026&oldid=565852620, https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&diff=565853312&oldid=565853264
--------------------------
**Version**: unspecified
**Severity**: normal",54107,3,Needs Triage,True
3.1854733931427117,-9.941541363541202,-7.939060357902031,5.824295992307361,-0.5495830877681559,-7.0289365084523965,-8.4368377640839,0.5280719260801355,-3.776606150951432,4.352665791422005,0.6393961190662814,0.36579980601569706,-4.547455143577667,1.14062262540408,-0.11985582807459316,-1.2111357538863199,0.22516743100865266,-0.6284755127179511,False,c1,3,"Reported at: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Link_formatting_trick
Simplified test cases here:
[subbu@earth lib] echo ""[[Foo|'foo']]"" | node parse | sed ""s/foo/<i>foo<\/i>/g;"" | node parse --html2wt
[[Foo|'''foo''']]
[subbu@earth lib] echo ""[[Foo|'foo']]"" | node parse | sed ""s/foo/<b>foo<\/b>/g;"" | node parse --html2wt
[[Foo|''''foo'''']]
--------------------------
**Version**: unspecified
**Severity**: normal",54103,3,Needs Triage,True
-8.702467492580332,8.183226278674784,-0.4218449393472685,3.656557854806892,1.5373271809374356,6.249662795497523,-0.49706151404872045,-0.48834921900125494,1.7169795466292197,0.7950040604172637,-0.4685314260797302,0.5930114573804683,-0.13385865584641188,-0.3755141839100702,1.9297799396937805,0.333255720669558,1.40215619664943,0.6403272163039284,False,c1,3,"This bug is about the generalisation of the solution deployed in bug #50929 in the Wikimedia environment. Having in mind the medium term of the deployment of the VisualEditor in many/most of the MediaWiki wikis, it could be a good idea to give the sysadmins the choice of enabling or disabling the VisualEditor by default for registrated users, with a LocalSettings parameter wgVisualEditorDefault.
This would give the choice to the sysadmins to enable by default or not the VE for registrated users (for anons there is already the preference wgVisualEditorDisableForAnons), and this could be directly used in the Wikimedia environment to replace the parameter $wmgVisualEditorDefault.
To resolve this bug, the patch https://gerrit.wikimedia.org/r/#/c/75541/ could be generalised by renaming the new preference ""visualeditor-betatempdisable"" into ""visualeditor-preference-disable"", and depending of the variable wgVisualEditorDefault either the positive preference (for alpha/beta environments, ""Enable the VE"") or the negative preference (for production environments, ""Disable the VE"") would be used, the other preference being hidden with wgHiddenPrefs.
In the normal scenario the wiki change from beta to production environment, it would be easy for the sysadmin to change the wgVisualEditorDefault value from false to true and this would automatically activate the VE during the change, so that the users are aware of the new setting and have the possibility of seeing the new editor (some welcoming message could be displayed then) and if users don’t like it they are given the possibility to disable it (or not if the relevant preference is hidden, but this is a sysadmin/community choice).
I point out the default messages visualeditor-preference-enable/disable should have a general-wiki phrasing, and any Wikimedia customisation (about namespaces where it is enabled, about the time the parameter is available before possibly hide the preference) should be customised in the WikimediaMessages extension (see my comment https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c34 ).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50929",54086,3,Needs Triage,False
-5.3876806426426445,1.334811971429465,-3.4920656280882074,0.11424683508203626,-0.5728076442618694,-0.14910430060296032,-1.738564054411512,0.40722679862173805,-2.544434391277802,-1.5058704426906249,0.04286125279810893,0.02609280816723447,0.7859351958157728,-1.5052185646978136,-2.017293832867543,-0.7757426433928158,0.06871836744349546,-0.5759758016528882,False,c1,3,"I saw bugs that are similar to this one, for example Bug 51289, but nothing exactly like this one.
References that are added by templates are not recognized by the references tool. I am not talking about templates like the English Wikipedia's {{cite web}}, which go inside the <ref> tag, but about template that add the <ref> tag itself (with {{#tag:ref}}).
This can be in infoboxes (Bug 51289) or in any other template. The Hebrew Wikipedia, for example, uses such a template, {{הערה}} very extensively, because mixing right-to-left text with left-to-right XML tags like <ref> is very hard to edit. This means that most of the references there are not usable for reusing in the ""Use an existing reference"".
(This also means a bunch of other things, but I'll report them separately.)
--------------------------
**Version**: unspecified
**Severity**: normal",54083,3,Needs Triage,True
-2.6570862582913874,-4.776111619149205,-3.711134297201381,3.684119361945495,-1.5901192340574426,-4.166542984815887,-5.676300084973908,0.9888717620853748,0.2511018458627976,5.973296511633171,-3.591135507812149,-0.044368199698144206,1.5208302399709002,0.7903466782298603,2.270958899615237,-0.452422040688476,-1.0815200728527925,2.875065879472923,False,c1,3,"A5b writes:
Edit page, then click save to get ""Edit summary"" Window. Don't touch mouse, put some description, using the keyboard. Then we want to change checkboxes ""minor edit"" or ""watch page"", without using the mouse. Press <nowiki><Tab></nowiki> key, and you will be directed to the link ""minor edit"" not to the checkbox. second Tab - is ""Save Page"" button. Next - ""review changes"". Next three tabs - for links in the footer of this windows.
Is it possible to change tab order to this (e.g. using tabindex argument or via rearranging divs and other elements):
*1. ""description""
*2. ""minor edit checkbox""
*3. ""watch page checkbox""
*4. ""Save page""
*5. ""review changes""
*6. anything else
Or even move ""save page"" and ""review"" to be just after ""description"".
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback#Wrong tab-order on the ""Edit summary"" window
--------------------------
**Version**: unspecified
**Severity**: normal",54080,3,Needs Triage,True
-5.067346959491527,4.595222501858906,-0.7034618474781045,-5.867926989676631,6.294477145396346,0.35625512056105735,-0.9020281052757229,-1.5999671938851492,-0.875636664198051,-1.0946054799977545,0.5234593687494185,-0.5739249182449686,0.4144592274351022,-1.2913215029709684,1.8295927907559415,-1.0715848600012183,-0.5541174530383507,-1.1631020736027171,False,c1,3,"When I select text that ends in the middle of the word and add a link, only the selected part is linked. Also, <nowiki/> is added after the link.
For example, in https://en.wikipedia.org/w/index.php?title=Ramat_Yohanan&diff=565789129&oldid=553919950 I selected ""South Africa"" and added the link. I saw an AbuseFilter warning when I was saving, but saved anyway to report the bug :)
Being a seasoned Wikipedian, I expect the whole word to be linked, although now that I think of it, I can imagine that linking a part of the word can be useful, too. So I'm not completely sure whether it's a bug or a feature.
This may be related to Bug 50127, though the description is not the same.
--------------------------
**Version**: unspecified
**Severity**: normal",54044,3,Needs Triage,True
-1.909676672898994,-3.197682670403328,4.645927364632261,-4.770543981586483,3.0772070828985267,1.9260356455049534,1.7946555977118344,-2.863500029278108,0.6695803708156581,0.1602114643392012,1.2446358923825698,1.3414592407354224,0.15299886611175229,0.7295198731394148,-2.147266689049719,-0.6060230061138767,0.5301190569396594,2.989066110854118,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=User:Octalpuss/sandbox&oldid=565273394, which, blanked, turns into https://en.wikipedia.org/w/index.php?title=User:Octalpuss/sandbox&oldid=565667534
I appreciate with the lack of comment-editing (or comment viewing) preserving these is usually A Good Thing, but we do need a better way of handling them.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60830",54036,3,Needs Triage,False
-8.564213867267997,5.580817804478897,1.6484236981105695,6.101593314623363,4.334191858476755,2.575974947199085,-2.2117670844486783,0.2903728875711372,1.191859070311442,-2.0746842199143978,0.9513094053940514,0.5190639270548547,-0.31967978483866943,0.8418636023348247,0.1281189892553396,1.3718740653610315,-0.6922964521955911,0.19241862431155643,False,c1,3,"PamD at the English Wikipedia reports that there is no easy way to add new content between a reflist and a template that follows it before you save the page.
This is a problem if your workflow is to add the stub template before adding the external links, which is entirely reasonable.
Steps to reproduce (option 1):
1. create page with references and a reflist.
2. add a template (e.g. a stub template) after the reflist
3. add content between the references list and the template (e.g. an external links section).
Steps to reproduce (option 2):
1. Go to a page with no content between a reflist block and a template (e.g. https://en.wikipedia.org/w/index.php?title=Tyson_R._Roberts&oldid=565739822&veaction=edit )
2. Delete all content after the reflist:
3. Add a template (e.g. a stub template)
4. Add content between the references list and the template (e.g. an external links section).
There is a workaround: select the reflist, press the right cursor key once, press enter. This gets you a blank line with which to work from.
Desired behaviour:
There should be somewhere to click between the reflist and the stub template, just as there is after the page has been saved and reopened in VE.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52620",54032,3,Needs Triage,False
-3.3634619384318527,-0.5503617348232464,1.383557066995813,5.312988949095103,1.9950582889669684,4.538056574260357,2.2408311281109787,1.153932065796245,3.5312827054719476,-0.8101191369027005,-1.1532919456532726,3.039662261492281,-1.9950260437498706,-0.18463603751815594,3.0331276333361687,-1.4053709870552316,-0.6412864373545742,-0.21059971233880148,False,c1,3,"TemplateData should allow some parameters to have default values which are prefilled when using the VisualEditor transclusion manager.
An example would be the current date for accessdate in citation templates.
--------------------------
**Version**: unspecified
**Severity**: normal",54028,3,Needs Triage,True
-0.9580254615883628,0.14200279912506453,-0.4612171908799123,0.6155022565954025,-0.23950544776259192,2.3701210654809763,-1.551781903254522,1.567331852240991,1.9733453154403382,-1.1297723894961305,-1.9266160545190567,-0.9961352862271117,0.2492357355366117,-0.3086815018470297,-0.804975339994952,-0.7600038823452968,-0.5376782928987394,0.16230867596889564,False,c1,3,"**Author:** `lovefilms`
**Description:**
The screen shot of the missing Production section trying to edit
When click on Edit to edit a section of an article, for example,
https://en.wikipedia.org/wiki/Blue_Jasmine#Production
the result page https://en.wikipedia.org/wiki/Blue_Jasmine?veaction=edit#Production appears to be a huge toolbar on top, and the section of ""Production"" is almost invisible - see attached screen shot.
Also, the toolbar should be clearly marked with visible borders to distinguished from the contents of an article. Now it's almost blurred into the article and very confusing.
--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC
**Attached**: {F11047}",53998,3,Needs Triage,True
-7.350284949588838,0.004192493783365947,-2.250474747087278,0.9154792686800219,1.8050110422721821,-1.8452593412953746,-1.744565773228734,-2.1150588246143758,-0.5759755749866049,9.496115474565766,-0.7927402812274846,2.179910899225832,-0.5584035474323192,0.9123952630183547,-0.1659269792269349,-1.0564792945156634,0.450158345381245,-1.699392901361473,False,c1,3,"If you type, say, 'cite w' into the template selector, it drops down a list of possible templates. Hitting return inserts the one that was selected from that dropdown. Great!
Hitting 'add template', however, does not; it returns 'cite w', a non-existent template. It would be good if 'add template''s behaviour could mimic that of the return key.
--------------------------
**Version**: unspecified
**Severity**: normal",53989,3,Needs Triage,False
-3.2814038929119107,1.5711447899963407,-1.3252191354620795,-0.5415310506922901,0.23225502655434227,2.897447413215829,1.579905649689727,0.529971302844513,-0.19860648566606087,0.31820279033514254,-0.2736028813813407,-2.935003214295759,-0.20773707423253374,-0.15038970747798075,0.22554566172481216,-1.3805086680592276,0.024482870413215396,0.13864100881205643,False,c1,3,"**Author:** `l736ewiki`
**Description:**
I'm an user on it.wiki, where VisualEditor is now enabled by default on the whole ns0.
I was trying to modify a long article, on a specific section, and needed to introduce wikicode (namely {{...}} for a paragraph replaced by an empty section).
VisualEditor forced me to switch to legacy mode, but whenever I try to edit the specific section, through the local ""Edit"" command at section level, the legacy editor always opens in the basic editor the whole article and not just the selected section.
This is heavily annoying when dealing with very long articles, with plenty of sections.
--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Mac OS X 10.8
**Platform**: Macintosh",53976,3,Needs Triage,True
2.0461141713221562,-1.5280663592650914,-0.06390071880840864,-4.6331218151082005,-3.0878188848043653,1.1461250089754162,-0.4415551023841493,-0.692491349038848,4.023283900889897,-0.6908486681862049,-0.39337097465801163,-1.9453483652925323,0.25934190991133077,-1.0995671697095206,-0.4875963033783668,-2.8175930785953627,-0.8305009637817111,-0.12840279764375095,True,c1,3,"http://it.wikipedia.org/w/index.php?title=Pieve_di_San_Giovanni_Battista_%28Pieve_Fosciana%29&oldid=60196986
If you tried to edit with VE, the missing image link would just disappear.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",53968,3,Needs Triage,True
-4.483373638931928,2.8201148891166206,-2.175023591468692,1.1663643261391363,-1.979516010098819,1.6183656367164845,-5.969173858401291,-0.6505753664731444,-0.7517410550884865,-2.42939201669727,1.7043767392444509,-0.30876886432285755,3.1875257399627577,1.5856918745760362,2.0747705925667095,-1.533571797354783,-0.4484104979948813,1.8274887745156507,False,c1,3,"An anonymous editor at en.wp reports:
""I was attempting to correct a minor error at [[Class 455]]. Although I was only attempting to change one word, the editor changed,
:...in common with the Classes 313 / 314 / 315 / 507 / 508 units.""
into
:<nowiki>...in common with the Classes <a href=tel:313 / 314 / 315"">313 / 314 / 315</a> / 507 / 508 units.</nowiki>
and then complains of a formatting error and refuses to allow the change to be saved. The editor seems to be interpreting the list of class numbers as a telephone number.""
I have been unable to reproduce this using Firefox 22 on Linux, including editing the article in question.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53315",53959,3,Needs Triage,True
-3.538425770877036,3.252353854974533,1.983454518702107,-1.0765382424708227,-3.3072342868358366,-2.9045726107527563,-1.3912622593187116,-1.4499894364699375,-4.66964181450324,1.6268619180930957,3.200937864536004,-0.11404945768207231,-2.768488143601264,0.454243556359061,0.09716918285775922,2.359526825538662,-1.44658350500077,0.9265021623429914,False,c1,3,"User Atethnekos at en.wp reports:
""If in the source code there is <<nowwiki/>blockquote>, and in VE I select ""<blockquote>"" and delete it, when I save the <nowiki/> is left behind in the source code.""
See https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=565596201&oldid=565596137 for an example in by sandbox. Further testing shows that it also happens with other tags and even with plain text:
https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=565596772&oldid=565596703
--------------------------
**Version**: unspecified
**Severity**: normal",53950,3,Needs Triage,True
-5.028197671445881,3.4492418826634896,-0.7926563881660194,4.516881931458933,-0.16583032842084533,0.24991034857227068,-4.248941115917772,0.7391372534619328,-5.472638756811387,-2.2245261478297107,2.926875620503449,1.6170296289002264,-1.962572976749768,-0.5082875589385836,1.31144699487501,1.0512960923533226,0.3493652461943435,0.025940061911687406,False,c1,3,"This is related to Bug 51741, which is about adding support for <references>...</references>
If the page already has <references>..</references>, and the last use of a named reference is removed, the entry inside <references>..</references> needs to be removed otherwise an error is generated after save.
Steps to reproduce:
1. https://de.wikipedia.org/wiki/This_Is_War?veaction=edit
2. Delete one of the named references, e.g. [16] at present
3. Save & Review your changes.
Expected results:
The reference is removed from the content and the references list.
Actual results:
The reference is removed from the content, but it remains in the references list, and if saved the error is:
""Cite error: <ref> tag with name ""rockspot_1"" defined in <references> is not used in prior text.""
--------------------------
**Version**: unspecified
**Severity**: normal",53938,3,Needs Triage,False
-0.6668612451126821,-6.983761633513087,-1.2151104136136102,4.6926359221671605,-0.2294769353453699,-4.084935221284489,-4.150118777657299,-0.15909733133896503,-0.28128202864712976,0.6777570187967834,2.31148194665537,0.04609457792629512,-1.3579097427407127,-0.3203065238143896,-1.1192934390936529,-0.9285363693305051,0.4311452146323831,1.4380528969512334,False,c1,3,"Steps to reproduce:
1. https://nl.wikipedia.org/wiki/Dolichognatha_petiti?veaction=edit
2. Click on infobox and edit translusion
3. In the first parameter (afbeelding), add 'blah', and apply changes
4. 'Save' & 'Review your changes'
Result:
| afbeelding =
-| afbeeldingtekst =
+| afbeelding =
+blah| afbeeldingtekst =
Expected results:
-| afbeelding =
+| afbeelding = blah
p.s. [[nl:Dolichognatha petiti]] is currently on the parsoid topfail list
http://parsoid.wmflabs.org:8001/topfails/15
Regarding the actual bug, I saw a similar diff ~20 hrs ago:
https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&curid=39469556&diff=565437324&oldid=565416618
--------------------------
**Version**: unspecified
**Severity**: normal",53925,3,Needs Triage,False
6.294287038937023,-0.8396367449437765,-5.165597450228162,-2.821500226377283,0.3405342115156418,2.4501179167098472,-4.789677856812077,1.2579713772783392,-1.7088253222502534,0.189949918849579,2.498705477232718,0.8294305306549477,-1.297630390052122,-2.40763417883306,-0.2810232788454483,-1.0797059754682514,-0.13538175396416974,0.800047926011582,False,c1,3,"English Wikipedia user PamD comments:
""Editing [[Pikku-Vesijärvi]] I noticed that VE's suggested DEFAULTSORT was exactly the title. VE should be set to drop the diacriticals when suggesting DEFAULTSORT - should have been ""Pikku-Vesijarvi"" with a plain ""a"".""
Looking at some other wikis it seems some do use diacritics in DEFAULTSORT (at least the Czech and Estonian ones do at [[cs:Édith Piaf]] and [[et:Édith Piaf]) so this seems like something that should be configurable based on each wiki's policy.
--------------------------
**Version**: unspecified
**Severity**: normal",53907,3,Needs Triage,False
4.960857475483769,-8.705516571157919,-3.084253115382788,1.5887311836184113,-0.15436804095059942,-0.4847633559800909,-2.0162011153592885,-0.13085088425955704,-0.23154778055645525,-1.5062712512161354,-1.8694461821919786,-0.9082233074596678,2.2752485111739364,-0.9722265995566683,-1.8758143769931017,0.5195700159358801,0.19852337471947923,-0.5361939128551512,False,c1,3,"**Author:** `jduranboger`
**Description:**
screenshot of the bug
Does not appear ""insertar multimedia"" button (insert multimedia), and can't inser image selecting from the dialoge box in the spanish version. This problem happen in firefox 22.
Attached:Screenshot
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC
**Attached**: {F11730}",53905,3,Needs Triage,False
-3.2818993344800806,-0.43263241971006217,-3.5664578976019197,-3.0871021907221867,1.7510598959818564,-2.275826291545689,-0.020619371979931245,-2.7199667388280546,1.8018046769212475,-1.868602964942049,-0.3831116268125796,-2.6943176344970525,0.8975656747333609,-0.9897596042916592,-1.037560150772598,-0.031044050121162015,0.766936219227109,1.2643112385990307,True,c1,3,"A user - Cryptic C62 - reports on English language Wikipedia:
**
If I click directly on a collapse box (created with {{collapse top}} and {{collapse bottom}}), the transclusion button appears and works correctly. If I highlight a collapse box by clicking and dragging my cursor through it, one of two things happens:
A: A transclusion button does not appear
B: A transclusion button does appear. Clicking on it opens a new template window, rather than editing the existing collapse box.
Occurs in Firefox v21.0, cannot replicate in Chrome v28.0
**
I attempted to replicate this myself and found that I sometimes got result A and sometimes a transclusion button that *did* edit the existing collapse box. I could not get his result B.
I tested it on other templates, and it did not seem that dragging through other templates ever brought up the transclusion button, but never say never. :)
--------------------------
**Version**: unspecified
**Severity**: normal",53880,3,Needs Triage,False
-9.303328065311137,3.818160684353945,-1.8125109295346622,-0.22962735374687582,4.136528942118845,1.246868932624383,0.563126238858505,-1.4417302098827323,-0.8656734870725751,0.695520424450824,0.9234407856246851,1.228702299787775,-0.1636549879599647,0.6606171718226745,0.4140305184148234,-0.12741316306250072,-1.2229435099032666,0.5440881146335024,False,c1,3,"I've noticed quite a few edits going to the VE feedback page http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback page which don't really seem to be VE feedback. If you follow through the new editor experience its quite obvious why they are being directed there:
1)New editor finds a page, they want to edit and clicks ""Edit""
2) They have a question, they see the big ? in the top bar and click it
3) There are two options: ""user guide"" and ""Leave feadback"", the second is obviously the one for questions so they click that
4) There is some complicate text which is tldr and a nice box to ask your question. The user types in that and
5)Bingo, a new section on the feedback page
This senario probably explains why we are getting a few simple signature with no comments. As the ? is much more prominent than the Help in the left sidebar its grabbing the users attention so diverting users away from our main help system. This showing up to be a continuing problem with about one such post a day. A way needs to be found to direct users to the right place.
--------------------------
**Version**: unspecified
**Severity**: minor",53875,3,Needs Triage,False
0.12980265556933768,-0.6616341778034638,1.2289961824570241,-3.4876895163399477,6.134580770016669,-0.290053010655271,1.0595973922368334,1.8444356642636346,0.9171005584905942,-1.578480745740435,-0.5639285909756042,-0.058078211326314744,-0.037597065351161696,0.9743932690406591,-0.31027995065701575,0.1802083959832116,-0.2895749285742131,1.2795797274825225,True,c1,3,"Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule).
This is a proof of concept for doing this more broadly.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54160",53858,3,Needs Triage,False
-7.3431289848302725,-1.1765170048422888,-6.081498060474333,-3.8448665804076207,1.0571500171483417,-4.8242733673784315,-0.9386986589826316,0.7489329074102457,4.245824756522184,-0.9049173968112298,-1.4491737847182902,-0.41189207144854767,0.15526555098209194,0.801715075517313,-1.7688442056786027,2.706963236599148,-0.14200022123827272,1.5585056053574362,False,c1,3,"Edits that would trigger this error silently break VE:
""Sorry! We could not process your edit due to a loss of session data.""
On save, it shows animation indicating it is saving, but then does not save, leaving you in the editing screen. It doesn't refresh to update your session data, so the edit will never succeed; and it doesn't show you the error message.
To reproduce: start an edit, then logout, and try to complete; or v-v (and more common) start one as an anon, then log in.
--------------------------
**Version**: unspecified
**Severity**: normal",53835,3,Needs Triage,False
3.7250673426916747,4.740872500301855,5.051439197486825,-0.4457901701360997,0.9953896344346491,6.1323666287323215,-0.5160524866646865,0.5179284010109029,-1.5789353332559068,1.7516535832345328,-1.3509571717070978,0.8120586611825253,-0.7044330755561461,0.5121103888370602,-2.058283053213248,0.5819376480293877,1.581675681337505,2.521954587587282,True,c1,3,"From https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#Krytyczne_zaniedbanie_interfejsu:_wersje_przejrzane
The Polish Wikipedia uses FlaggedRevisions or PendingChanges and has deployed both notices upon opening a page and a different text on the ""Save"" button to reduce confusion by new editors. These notices are not appearing in VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: major",53833,3,Needs Triage,True
1.3234459417783806,-0.9468597150143463,-1.6747477376543767,2.708625866628919,3.8376472490893856,0.8958818211330277,-2.4068146676276196,3.1657676194374913,-2.1386913084579415,-2.967598173829346,1.71296674627339,-1.9786817477170766,-0.9910224237334697,-0.49681961077502024,-1.3358784557405166,-0.5987140679006007,-0.10164504120273099,-0.5362217174952175,False,c1,3,"Long <pre> blocks rendered in Firefox 22 on Xubuntu Linux. Monobook skin.
When <pre> blocks contain lines longer than the width of the page, the <pre> block formatting finishes at the right edge of the page but the text continues. Shortly afterwards the page background finishes and the text continues onto a plain grey background. The html page though is rendered much wider than is needed to show all the text though (very approximately double the required width).
Example page: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=565361164#save_page
Firefox 22, Xubuntu Linux, Monobook skin.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11594}",53831,3,Needs Triage,True
-5.766360865418042,8.238020865581,1.6780759870245916,0.9557397199845576,3.7213940251835536,1.5679482241723874,-3.284049622470274,-2.859627486430047,2.899117481778373,0.026390958481159466,1.5957452203908091,-2.5262825415166494,-0.23315723262438315,-1.6432438261551638,0.4831938291613005,0.8720085356095513,0.19519460744961026,0.7770340383960248,False,c1,3,"1. Visit any page on Wikipedia today.
2. Click ""Edit"" to enter VisualEditor.
3. Find a section heading and highlight it.
4. Press the DEL key on your keyboard to delete it.
5. Click ""Save Page"" then ""Review your changes.""
The heading text has been removed, but the following wikitext has been left in its place.
==<nowiki/>==
Cancel the save, go back to the empty heading, and place your cursor in it. Press DEL in an attempt to delete the empty heading. As a result, the entire paragraph below the old heading turns into a heading.
So how on earth do you delete a heading? I canceled my edit, re-edited, and this time, I highlighted the heading AND the first line of the paragraph beneath it, and pressed DEL. Regardless, the whole paragraph turned into a heading again.
I finally managed to delete a heading by placing the cursor at the end of the preceding paragraph (after the last character of the paragraph) and dragging all the way to the end of the heading, then pressing DEL. Now, the heading was gone and nothing else turned into a heading.
In short, you must delete some kind of invisible character on the LINE ABOVE the heading, in order to delete the heading. This is not expected behavior.
--------------------------
**Version**: unspecified
**Severity**: normal",53829,3,Needs Triage,True
-5.628965067728684,3.7620141495974124,2.531619061089277,5.268426687302601,9.18481214146922,2.8911926427975496,0.15207737255626075,2.8090804511141307,-1.333774730760064,-2.9919961530416446,-1.5789395012829144,2.198516407328033,-1.5790980545728504,0.04797892840440188,0.06127221717466913,0.3118066165974381,-3.835348593752099,-3.3139566761430825,False,c1,3,"At the English Wikipedia, a user requests that the tooltip which is shown when hovering over a link (shows the link target) also be shown when the link inspector icon is shown (i.e. when the cursor is in the middle of the link).
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51824",53827,3,Needs Triage,False
2.4922972936288814,-5.375467835491801,0.8314873848527462,1.2753839791429278,2.28661437367115,1.21908766169239,-2.4968173462546512,-0.27910753022839935,-0.5392934018191973,-2.3947150284852414,-0.15357342625293668,1.048523917374556,1.0230934430671876,-3.3640945986792463,-0.6306475678692705,-0.36969204568049263,-0.15914203751577438,-2.066389823558151,False,c1,3,"Screenshot from [[pt:TV TEM]]
In the page
https://pt.wikipedia.org/wiki/User:Helder.wiki/Testes?veaction=edit
the image is a lot bigger than it is on view mode
https://pt.wikipedia.org/wiki/User:Helder.wiki/Testes?action=edit&oldid=36476193&preview=yes
This is a minimal example for the problem reported at
https://pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia%3AEditor_Visual%2FComent%C3%A1rios&diff=36476052&oldid=36474378#Logo_desproporcional
which can be seen on this article:
https://pt.wikipedia.org/wiki/TV_TEM?veaction=edit#footer
The screenshot provided was this:
http://s22.postimg.org/owzuay0jl/image.jpg
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://pt.wikipedia.org/wiki/?oldid=36476128&veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51628
**Attached**: {F11577}",53826,3,Needs Triage,True
-5.583220582250625,7.084862857321646,1.6833445375467981,1.1957831954304208,-0.48018156366828346,-0.09706079904259335,1.04442696142873,-0.7364762178470108,-1.4017690180963658,0.7535815460075241,0.46767150496059795,-2.099325013619868,1.5182563601549073,1.242583611749711,-0.6356278247063409,-0.23838444229941136,-0.42557863093299764,-0.002900765832288821,True,c1,3,"From English Wikipedia:
I've noticed in several articles today that the article title has displayed, in VE, on top of the lower border of the editing header bar. I've not noticed it before. I prefer to edit in a window less wide than my laptop screen, as reading long lines of text is a pain.
On investigation: if I reduce the editing window to the point where the Question mark in a circle to the left of BETA is underneath the greyed-out ""Decrease paragraph indentation"" icon, there's a critical point where reducing the window width a little more moves that Question-mark back slightly to the right and jumps the article title up to display on top of the lower border of the editing bar.
And a second problem: if I reduce the width even more, then the article title is displayed in a very narrow column. Look at Sengattuppatti, reduce the width, and at a point where the lines of text are still perfectly workable (perhaps you're working from a text open in another window on the screen), the article title is reduced to the extent of losing letters. Reduce the window so that ""Tiruchirapalli"" is the first word of second line (that's about 50% of my screen width, and a likely width for consulting a source document on screen beside the WP page I'm working on), and note that the article title now displays minus its last four letters. Not wrapped, just disappeared. Ugly. In multi-word articles, it displays as a column but again truncates long words - try Thomas Lumley-Saunderson, 3rd Earl of Scarbrough.
I'm using Firefox 22 on Vista. PamD 10:18, 22 July 2013 (UTC)
She adds that the original screenshots (truncated to hide non-free elements) demonstrate that her windows were not unreasonably narrow and that she ""might well want to have two 50% width windows, one for the source and one for my article.""
See images:
*http://en.wikipedia.org/wiki/File:Screenshot_of_title_overlapping_border.jpg
*http://en.wikipedia.org/wiki/File:Screenshot_of_truncated_title_word_in_narrow_window.jpg
Original thread here:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=565350848#Article_title_overlaps_header_bar_in_slightly_narrow_edit_window.3B_article_title_letters_lost_in_narrower_window
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52187
https://bugzilla.wikimedia.org/show_bug.cgi?id=51867",53820,3,Needs Triage,False
-2.219755504651076,-5.499239095779595,-0.6711351686257725,1.9814379237972655,-0.38013937813969256,-0.009421040042137507,-3.158092684552643,0.4954765693761415,0.5486971333053879,4.296370065177564,-0.5086258058832747,-0.3665045638080604,1.863716788666678,-0.4489380564202934,-0.7702482303062945,-1.066413180523735,0.8442129773512297,-2.1315201179074466,False,c1,3,"If the only template is removed, the dialog is almost entirely blank. It should reset back to the 'New template' form, or do something with all that white space.
Steps to reproduce:
1. Open Transclusion dialog
2. Add 'cite web'
3. Remove 'cite web'
Result:
Stare at the whiteness
Expected results:
Something, anything, except a sea of white
--------------------------
**Version**: unspecified
**Severity**: normal",53812,3,Needs Triage,True
1.70093710455849,-7.803155749159187,4.489065624915675,3.427532520415535,4.226648903608757,1.6071217361055454,-0.3798267609060346,-0.8080108096344543,-0.1777550552036619,-1.6942408772338031,-1.041417694530423,-1.2276791956799427,0.6162205875864939,-1.0204906899624069,-2.7578779116359646,0.7548452353698936,0.49977045915818596,-0.4366934996859364,False,c1,3,"Screenshot of the table
See the link above and the attached screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://pt.wikipedia.org/wiki/La_Liga_de_2006%E2%80%9307?oldid=36362539&veaction=edit
**Attached**: {F11541}",53806,3,Needs Triage,True
-1.4564690122735957,4.557634118614818,-1.7894381980940075,-7.46935023112577,2.3048993947794862,1.4031704315691342,1.2795040988959645,-2.9842428600125563,-0.25764910897066146,0.21592913397411273,1.6450997962609502,-0.48225692099472484,0.7659359683923483,-0.7600681506582019,0.608680547381101,0.05016098511690298,0.3498646134298182,1.1382419747732258,False,c1,3,"The page https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide/he was created by the Translate extension. It's impossible to translate it using the source editor and trying to do this gives the user a link to the translation interface. But it seems to be possible to edit it using the VisualEditor. I didn't actually try to change anything, because I was afraid of breaking something badly.
I'm also not completely sure whether it's a VE or a Translate issue; I file it under VE because there are other issues in which VE behaves differently from the regular edit action, such as Bug 51459. But it may also be on the Translate side; CCing Niklas and Siebrand.
--------------------------
**Version**: unspecified
**Severity**: major",53805,3,Needs Triage,True
-0.16390906063873745,-4.068217756416322,-1.0559935578798711,3.9782416479323173,-1.411283620204347,0.4214546541764499,1.2614997601411666,-0.4044251581615331,-2.5598256128317853,-0.14583711509673147,0.7029862058360927,-0.06990622177604022,3.013217427356162,-1.3664779160738467,-1.266467509250604,-0.33384232300026917,-0.4170583812778481,-0.4465311191289547,False,c1,3,"Screenshot of VisualEditor in Mozilla Firefox with Firebug enabled (which creates the blue overlay that indicates the contained element is bigger than shown and shows its size in the ""Schnellinfo""-Box
Original Bug title: VE: Page settings: Languages list cut off
In the page settings dialog, the languages list is not completely visible. This is due to the higher CSS selector precedence of
.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden)
over
.ve-ui-panelLayout-scrollable (setting overflow-y:auto)
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11501}",53793,3,Needs Triage,True
-8.258934367701068,6.4310821442633745,7.1286091127328,6.621247846028367,1.8922558205986206,3.73393528408935,1.8687365382688945,-0.5492000936542328,-0.22804554163221075,0.1866538185782387,1.046195144470064,2.152009981227212,0.5793656009677051,0.6086969879552253,-0.011983628162574256,-1.0318932284855478,-0.2864998201465636,2.563759897078188,False,c1,3,"Many templates are redirects from a short name to a long name. An example is
http://en.wikipedia.org/wiki/Template:Commons_cat which is a redirect to
http://en.wikipedia.org/wiki/Template:Commons_category and has 68742 pages transcluding it. Even though Commons_category has template data specified, and http://en.wikipedia.org/wiki/Template:Commons_cat/doc redirects to http://en.wikipedia.org/wiki/Template:Commons_category the visual editor does not pick up the correct parameters in the template dialog box.
There should be a way of making the dialog work for redirecting templates without having to duplicate the documentation.
--------------------------
**Version**: unspecified
**Severity**: normal",53791,3,Needs Triage,True
5.027247758072091,7.759807798718889,3.5698832402099434,1.1477272653653832,-2.250458073462114,3.0431893277384834,-1.4088496507357817,1.2204906169857632,-0.12447603233532917,-0.7169159646706476,-3.505125772422734,-2.445130555617681,-1.5125376742539673,0.5024831574409125,-2.108756625721461,0.9451039437127319,-0.29225511224728007,1.96082522664947,True,c1,3,"Reported on English Wikipedia by User:Cryptic C62:
""Upon opening the transclusion editor, or upon moving a component up/down using the arrows in the bottom left, the Wikipedia search box and accompanying buttons occasionally appear in front of the transclusion editor. The behavior does not occur consistently.
Occurs in Firefox v21.0, cannot replicate in Chrome v28.0""
See image:
http://en.wikipedia.org/wiki/File:VE_Searchbox_Passthrough.jpg
--------------------------
**Version**: unspecified
**Severity**: normal",53771,2,Needs Triage,False
0.5378556099997827,4.667894116665202,-1.1155478964093941,2.0675512166777987,3.9714242828198763,-2.6053341811392565,0.7545752154251133,1.9228066623080151,0.15294826482822377,4.3470523321883405,-0.5710740584905958,-0.4896907550964281,-0.5259165512627249,0.36581470538910477,0.10839944666752555,0.03904929225482101,0.6111075445983836,-0.3709114979023789,False,c1,3,"After clicking the ""Save page"" button in the ""Save your changes"" dialog, the spinner (progress bar) appears for a few seconds, then vanishes again. The ""Save your changes"" dialog remains open and the edit is not saved.
Here is the output of the JavaScript Console in Chromium:
Uncaught TypeError: Cannot read property 'info' of undefined load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…ext%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130719T023752Z&*:83
ve.init.mw.ViewPageTarget.onSaveError load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…ext%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130719T023752Z&*:83
oo.EventEmitter.emit load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…xt%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130719T023752Z&*:124
ve.init.mw.Target.onSaveError load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…ext%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130719T023752Z&*:16
ve.init.mw.Target.onSave load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…ext%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130719T023752Z&*:16
proxy load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…l%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130719T023752Z:10
fire load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…l%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130719T023752Z:12
self.fireWith load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…l%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130719T023752Z:14
done load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130719T023752Z:119
callback load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130719T023752Z:129
The error is reproducible (with this exact console output) even when I make further edits to the article content or change the edit summary and then go back to the ""Save your changes"" dialog: I can't save seem to save my edit at all. Haven't yet seen this occur in other articles, though (this was an enwiki article).
--------------------------
**Version**: unspecified
**Severity**: normal",53759,2,Needs Triage,False
-10.25463938273876,2.2027014506996316,-2.661511823503858,2.830229848085667,5.781608448829097,4.027179070501449,1.426716607355952,2.1945385414418133,-1.9746300371138528,-0.6005440756597507,0.8939667832277571,3.2691506183695767,1.0089718441712616,-1.744268665818299,-0.5873592110523234,-0.06598584637965976,-0.8858900376771739,0.8716488841145946,False,c1,3,"In the visual editor, the button to remove formatting activates if the cursor is placed on a formatted (bold or italic) character. However clicking the button has no effect unless text is selected.
Either the button should be disabled when no text is selected, or clicking it when no text is selected should have an effect (probably remove formatting from the current word).
--------------------------
**Version**: unspecified
**Severity**: normal",53756,2,Needs Triage,False
-2.779366168738312,2.681216689155061,-0.5169318449875302,-3.016697265655417,-0.5380837866627758,2.1927396331955125,2.7183561006592187,-0.7360235617610509,-3.846327102192091,0.8392878559348347,4.324493206603062,0.06166576268211932,-0.6140484776356647,-0.5664269700116886,-1.228498655571916,-1.7361850136727437,0.3064214388462396,2.5415810103998577,False,c1,3,"The English [[Barack Obama]] article has dozens of categories. When editing the categories using Page settings, only the first few of them are visible and editable, and it's impossible to get to the rest of them, because there is not scrollbar.
--------------------------
**Version**: unspecified
**Severity**: normal",53752,2,Needs Triage,False
-3.627038106042775,3.6116791374003654,-3.1989432946138248,-5.795241068368219,-3.1161358022407395,0.34823589592608784,0.7408873918214303,-1.9879155969435551,-1.4132775705666956,-1.7604458757692907,-1.1152407957247996,-0.34104491290091565,-0.014191908256250052,-1.3274488062690297,-0.4796111042435154,0.07880859544129137,-0.6164662672044801,0.13922135803070135,False,c1,3,"As reported on the Swedish feedback page:
http://sv.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2F%C3%85terkoppling&diff=22695791&oldid=22693792
When there are blank lines before and after HTML comments, it seems like it is not possible to remove all of them.
Ideally it should pe bossible to edit this version:
http://sv.wikipedia.org/w/index.php?title=Abrostola_major&oldid=21896423
in a way that it gets like this:
http://sv.wikipedia.org/w/index.php?title=Abrostola_major&diff=22695707&oldid=21896423
But in VE editing mode it is not possible to format it like that without accidentaly deleting templates on the page. Is it perhaps because of the HTML comments?
--------------------------
**Version**: unspecified
**Severity**: minor",53732,2,Needs Triage,False
6.430381155515821,-3.8589788956159037,-5.636147361476175,2.993120925708335,1.3538583641434407,-3.306342011258108,-3.6287915162963156,-0.6105289965217926,-2.6191142637317872,9.023452136815191,-4.783038730106699,0.0461482185497093,-1.062173577597064,-1.776093410079549,0.5434240418943865,-3.2026665221381605,2.123574543291208,-1.8398062435478852,False,c1,3,"js/lib/pegTokenizer.pegjs.txt currently contains the following:
var base_urls = {
'RFC' : '//tools.ietfs.org/html/rfc%s',
'PMID' : '//www.ncbi.nlm.nih.gov/pubmed/%s?dopt=Abstract'
}
base_urls['RFC'] is wrong; the hostname should be tools.ietf.org .
I spotted this when looking at Firebug's HTML tab while VisualEditor was
open on https://en.wikipedia.org/wiki/MD4#Security .
--------------------------
**Version**: unspecified
**Severity**: normal",53726,2,Needs Triage,True
-9.522419640657777,3.7248780848641765,-4.003242069189385,-1.3407684117186658,-0.30594532126842333,-1.7974189102799154,0.511255412632166,1.5966808273585893,-1.854522896058083,-2.094462736607156,-2.8812187892307297,0.542494970864704,-0.4280291899611708,-1.6633442682679687,-0.199790748315678,-1.7945605697861278,-0.3900378055509288,0.36006227121125645,False,c1,3,"At the moment, categories are pushed right to the bottom of the page. This is mostly useful, but not always; it causes policy issues if there are stub templates around. While this is not something we can or will support, the fact remains that we're essentially imposing a structure on wikis by saying ""categories will always go at the bottom"".
What would be a nice way around this problem, at least with existing articles, is to have newly-added categories stuck immediately after existing categories - wherever they are in the page. We get some degree of consistency within articles that would otherwise be lacking.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53714,2,Needs Triage,True
-2.8215575463015727,2.6519684921771223,0.06025498714180699,-0.17646490439761087,1.5810527177357612,0.007317330849691883,-2.715328924337996,1.322950237088261,2.888976456705441,2.8429308192400704,0.2576966978730084,-1.0029659230884906,2.2670940171481893,0.43287522378528376,1.3815912178881256,1.560969660008361,-0.7534297033110505,0.6894833030553438,False,c1,3,"If you add multiple templates in one transclusion it is possible to rearrange them. Once rearranged, once cannot select the parameters from the first template anymore.
Steps to reproduce:
- Open any random page in the visual Editor.
- Open the ""Transclusion"" window. Select the ""Cite web"" template and click the ""Add template"" button. It should be added with two default parameters.
- Click the + icon in the bottom left of the Transclusion dialog, and click the button to add another template.
- Add another ""Cite web"" template as described in step 2. Again it should come with two default parameters.
Right now you should have a transclusion window containing two cite web templates.
- Click the bottom template, and press the ^ icon to move that template to the top of the list.
- Now try to click the default ""Source Title"" or ""URL"" parameter in the top template. It is no longer possible to select or alter them.
- Extra: If you move the other template as well the same problem occurs; In that case both template's parameters can no longer be edited.
Tested on Firefox 22 and Chrome 28 on Windows 7.
--------------------------
**Version**: unspecified
**Severity**: normal",53674,2,Needs Triage,False
-1.3393704801292594,-5.956709885619087,-3.408694366294375,1.3160853175975729,0.08679167721570424,-1.2877931408962793,-1.996372313264784,2.0997129559558294,0.14784843825080163,3.5866393149533042,-1.4248099692856664,0.4750957948047281,1.6925803718056178,-1.8734345435453048,-0.548244405508747,0.5937514268673074,-0.36264115997830926,2.556793794517044,False,c1,3,"**Author:** `ignatzmice.wiki`
**Description:**
The button to cancel edits and return to read mode is labeled ""cancel""; clicking it brings up a dialog box with buttons ""OK"" and ""cancel"". Clicking *that* ""cancel"" cancels the cancel and returns to editing mode—not blatantly wrong, but confusing. Perhaps the first button should be renamed ""discard edits"" or similar?
Original thread: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564868353#Ambiguity_in_.22Are_you_sure_you_want_to_cancel.22_dialog.3F See also bug 47676, closed as WONTFIX.
--------------------------
**Version**: unspecified
**Severity**: normal",53655,2,Needs Triage,True
8.413589582561373,-0.6738372324640931,0.5708051655396709,-3.0388512129397443,1.3247557041444815,2.773314665041057,-2.0741596079785234,3.504736186020461,0.13257824244914362,-1.8110106818416756,0.2622177734387918,-0.1572930200925715,2.944412056998721,4.1211316641139,0.6604824598232941,0.39368954265864287,0.19652416327061117,0.6417215013419992,False,c1,3,"Steps to reproduce:
1) Open https://en.wikipedia.org/wiki/Jam,_Iran?veaction=edit
2) Double-click repeatedly inside one of the templates (e.g. infobox)
The following JavaScript error appears on the console:
Uncaught Error: Offset could not be translated to a DOM element and offset: 442
Chrome 28/Ubuntu
See also: bug 51526
--------------------------
**Version**: unspecified
**Severity**: normal",53653,2,Needs Triage,False
4.002053364957499,-1.5020018295639321,1.5172961984237006,2.5342030451792965,0.18591952073928253,2.9470811055170536,0.30962905821277253,0.9411019606679684,0.7957568089970608,2.698837101027932,-1.6976451373740724,0.9544030109591868,-1.4004103365149154,-0.10207995234771783,1.2898852308811302,-0.2055067802409526,-1.0277180298920077,-0.5242746516697914,True,c1,3,"The ""leave feedback"" link renders in grey, which might suggest to users that is not a functional element. Issue raised by English Wikipedia editor Hhhippo.
--------------------------
**Version**: unspecified
**Severity**: normal",53619,2,Needs Triage,False
2.482642207948864,0.9588962138066197,-0.9227764145882311,-1.5386493854056442,3.2497977755806047,-0.5788527785028388,-0.9055921007156513,-0.7452249688984696,-0.08738554541860977,3.690269208011774,0.222588167857523,-1.1731521134254683,1.218135205510353,-0.34915557053244406,-0.5525381129442746,1.0831036166075496,2.3614841819715737,-0.7752051101406774,True,c1,3,"Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)""
The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?""
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up
--------------------------
**Version**: unspecified
**Severity**: normal",53618,2,Needs Triage,True
2.857312876539829,-8.045643515195847,3.2390809252976673,-0.8649706539959745,-0.5356518597145601,-1.447674110800484,-3.1408710579217747,2.778143106829038,-2.138745203969261,-3.4129509836746337,1.0039589128510786,-0.22884780467661514,2.2529144125357212,2.7265923111194015,1.911279515240226,0.5634333790170183,1.8588589599840841,0.26494602762655206,False,c1,3,"The image from [1] and is not rendered on VisualEditor [2].
[1] https://pt.wikipedia.org/w/index.php?oldid=36419116
[2] https://pt.wikipedia.org/w/index.php?oldid=36419116&veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51248",53567,2,Needs Triage,False
-8.13820380641057,2.1347226699310227,-4.129627446034984,-0.07114571309888151,-1.8353332012556334,0.8417599609011546,0.7815229690500995,-0.5778888683212173,-0.5011591346630629,0.14558718554832684,3.240006672722109,-1.8707402244229034,1.5407352959934784,-1.155586495883132,0.24561626910792178,-2.327355388453275,0.48432464824178667,-0.03580942137496401,False,c1,3,"At https://en.wikipedia.org/w/index.php?title=List_of_American_Dad!_characters&curid=2082680&diff=564675517&oldid=564302759 a user added a link using wikitext. The VisualEditor added <nowiki> tags around it (correct according to apparent design, incorrect according to desired behaviour).
However, it also added <nowiki> tags around every other bit of pre-existing markup in the paragraph. This is incorrect according to my understanding of the design because even if they did want to include a literal string surrounded by square brackets they did not want to alter the existing markup.
Bug 5069 comment 5 suggests to me that this isn't that bug but a different one, but not what number that other bug is.
--------------------------
**Version**: unspecified
**Severity**: normal",53554,2,Needs Triage,True
1.7492155255856496,-1.3597805694423055,0.18314795153626307,0.41913952881508787,6.648107798745647,-1.274808951437501,-3.415693926845896,-3.9655906474155973,-3.993752539858259,-0.14090348795052066,1.446859413421231,0.3879322070988003,0.9928703264425405,0.3591607714353442,0.3392996370263406,-1.0021815566245003,-0.2774950871282662,0.5258227862442106,False,c1,3,"Using Firefox 24, Ubuntu 13.04
What I did:
1. I was editing a page[1], made several small changes (fixing typos, rephrasing)
2. I clicked ""Save page"" which brings up the save dialog
3. I wrote a summary and clicked ""Save page"" again
4. The blue throbber line appears, disappears and leaves me with the save dialog still open (not saving anything)
5. I open the JS console and when I try to save again I see:
a. The HTML is submitted to the API
b. Before the response arrives (?) a JS error appears: ""TypeError: editApi is undefined""[2]
c. The API responds with a ""200 OK"" which includes a JSON error[3]
When I open the JavaScript console I see the following: 1) The HTML is submitted to the API, and while that request to the API is in transit a JS error appears:
[1] https://www.mediawiki.org/wiki/VisualEditor/Portal/sv
[2] File: https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.visibleText%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130717T024027Z&* Line: 85
[3] {""servedby"":""mw1203"",""error"":{""code"":""unknownerror"",""info"":""Unknown error: \""tpt-target-page\""""}}
--------------------------
**Version**: unspecified
**Severity**: normal",53534,2,Needs Triage,True
-10.942880802290066,7.751039256683036,-1.2743152557792286,-1.5323411341768125,3.119832367157783,-0.7588986050850683,-0.8557495064487863,-0.4442702654599955,-0.2773638665821507,-1.479213760874956,2.0767360544104476,1.2835201695455505,-1.6577568518033408,0.7653456127298215,-0.09978179013543897,0.864803011387977,0.25177580183404213,0.07780123233721059,False,c1,3,"If you place the cursor after the last character of a link and start typing then your text becomes part of the displayed text for that link: [[Fish]] → [[Fish|Fish and chips]] rather than the inte.nded [[Fish]] and chips or [[Fish and chips]] which would be expected from a WYSIWYG editor (even if it isn't what is wanted).
There is no way to edit part of a link at all, the only way around it is to unlink the whole phrase and relink the part you want linked.
This is not usually a problem, as you can work around by starting from after the space after the link.
However, this is counter intuitive if you want to add punctuation after the link (add it after the space, delete the space, add space after the punctuation). It also means it is impossible to add unlinked text when the link ends the line, as happens often on disambiguation pages. For example try adding context to the links at Mandi#People. Apparently a workaround is to insert a line break, add the text and then delete the line break. I've not tested this myself though
It is possible this is the same as bug 50945 but I don't think it is.
--------------------------
**Version**: unspecified
**Severity**: normal",53531,2,Needs Triage,True
-4.108991466856552,8.579939641390897,0.08359302555977166,-4.790081857451037,-8.08764923835471,3.2410522556791026,2.9902183660156405,-0.928957636459521,-2.3214062835588916,-1.2727509000017752,-2.5871803643302216,-2.7683749156359694,-2.924332389620231,2.952731673048768,-1.7615315247576753,2.8650769162352407,0.5137986641777075,-0.38709747292811847,True,c1,3,"Editor HHHIPPO on English Wikipedia notes that the tab key does not increase indentation (as promised in the greyed out icon on the ribbon) but rather jumps from citation to citation. (For me, it also lands on wikilinks in templates.)
--------------------------
**Version**: unspecified
**Severity**: normal",53530,2,Needs Triage,False
0.8020441851548283,3.430685426543352,-1.0404619214407074,-3.1651346601878507,-0.12249373478256698,2.8804272618401905,-2.4046762491601523,-2.7526822903372583,1.7678598067154827,-0.22479780964836316,0.7745808780295693,-1.6966519278381855,2.6381028494925225,-1.4988327699916661,0.2519698486703099,0.019155740145801736,0.47089016425540753,-0.3238801696627882,True,c1,3,"On English Wikipedia, a user reports the following:
*Added leading whitespace to paragraph in VE. Text appears fine in VE, with leading whitespace as an indentation.
*Saved. VE adds nowiki tags before the whitespace and after the first few words. Text displays without indent.
*Tried removing the whitespace in VE.
*VE won't allow the whitespace to be removed, but instead will only permit the first few words to be deleted.
This is with Chrome 28 + Windows 7. I'll see if I can work out the conditions that would have created the first problem. - Bilby (talk) 02:37, 16 July 2013 (UTC)
VEspaceremoval.png
I tried to replicate this myself.
*Added whitespace to the lead of an article, and it nowikied. http://en.wikipedia.org/w/index.php?title=Quadrangle_%28architecture%29&diff=564486949&oldid=563578917
*It turned the first word into an uneditable element. See image: http://en.wikipedia.org/wiki/File:VEspaceremoval.png
*Curious as to what the nowikis would do to formatting, I found an article that had formatting on the first word. It added space, no ""nowiki."" http://en.wikipedia.org/w/index.php?title=Marloth_Park&diff=564487138&oldid=557816381
* It allowed me to remove the space in VE.
(Also using Chrome on 7.)
--------------------------
**Version**: unspecified
**Severity**: normal",53528,2,Needs Triage,False
-3.162137134112599,0.2972120554434987,-1.7834929172942324,-0.03961461708302272,0.2297033668444155,-0.7977525978428787,-1.8438045579146207,-1.7356025371904216,-0.8968930019934754,-0.49163064678280133,4.7657169838240865,0.108790119085594,2.2393607170676573,1.0649123560344593,0.5506692363335235,-1.5157193359760062,0.21113523278155966,0.0668452330056335,False,c1,3,"I meat an annoying problem. I tried to upgrade my wiki from 1.20.6 (0727d6a) to 1.22wmf9 in order to use VisualEditor. (nginx/1.2.5 php_version5.3.23 on Linode VPS)
The serves running few wikis using one set mediawiki software. I tried to php update.php the largest 1.5G Chinese version, but the script simple give no response.
example:
[root@moegirl maintenance]# php update.php
[root@moegirl maintenance]#
I tried other smaller site, it react like this:
<pre>
MediaWiki 1.22wmf9 Updater
Going to run database updates for enwiki
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick)
... 0
[root@moegirl maintenance]#
</pre>
The web updater works good for small wiki, but the 1.5G one will receive ""Timeout""
The most annoying thing is when I tried to upgrade same database to 1.22wmf9, all of then works as normal. Only the major linode VPS we are using have this problem.
Anyone had ever meet same problem? Is this a new bug? How to solve it?
--------------------------
**Version**: unspecified
**Severity**: normal",53514,2,Needs Triage,True
7.634461866489982,-11.04526034136034,0.8728878241076004,-2.0659721845845604,2.7987443887816172,-2.516628816286216,3.794143967478118,2.8565508432887796,-2.804228005263899,0.19702741375034272,-1.6212398275694682,0.4090896764462191,-1.340376216667437,1.3433145116994991,-3.163602427040226,-0.35135308646127605,1.3939066741145598,0.3761619224501651,False,c1,3,"Dunno why but:
https://en.wikipedia.org/w/index.php?title=Fish&veaction=edit loads VE-edit mode
https://zh.wikipedia.org/w/index.php?title=%E9%B1%BC&veaction=edit doesn't.
--------------------------
**Version**: unspecified
**Severity**: normal",53481,2,Needs Triage,False
7.129800262504025,-1.018993876029084,-2.161074672974374,-4.953784212628834,1.3766919197026082,0.5248703402618391,-2.7109536118020108,-1.9870406701841703,-1.0515639345449734,-2.618826906619763,-2.4658505185464237,-3.015210962148709,2.39017606133287,0.03648992004052243,1.2963199493481223,-0.23859576547522554,1.2419061318831977,3.1269097565085238,True,c1,3,"From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#How_did_it_go_to_Vedit_mode.3F
""After saving an V-edit on Shiva, I saved the page. From contents, I clicked on a section. Instead of going to the section, it went in Vedit mode. --Redtigerxyz Talk 09:48, 14 July 2013 (UTC)""
The problem was replicated in at least two articles, and only appears when reorganizing or removing sections. The editor is running Chrome Version 28.0.1500.72 m and Windows 7 Home edition. I couldn't replicate it using either Safari or Firefox on a Mac.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7",53456,2,Needs Triage,False
0.42165979384448793,-5.5893645525890765,-6.971467281998354,2.42297558806436,-1.1316244212465416,-0.8187282505704878,-7.276177293188079,-0.16066789563491757,-5.180717885057565,-1.175719781388259,2.534765490347201,0.5822399810146719,2.540591888323634,2.7774882085765835,1.7486978734778775,-0.7214484087767497,-1.116013305459622,0.6701724626219969,False,c1,3,"Screenshot
Multiple uses of a references are shown in the reference list:
Default: is ""1.0 1.1 1.2 1.3"" etc.
Some wikis, like dewiki, uses ""a b c"" etc.
VE rendering always use the default.
This is configured onwiki with [[MediaWiki:Cite references link many format]]. It depends on usage of $2 or $3:
Default content: [[#$1|$2]]. $2 responsible for showing ""1.0 1.1 1.2 1.3"" etc
dewiki content: [[#$1|$3]]. $3 is responsible for showing ""a b c"" etc
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11692}",53453,2,Needs Triage,True
-3.533714884091072,2.3405366284309572,-0.22158791895670404,-6.676035029410947,-3.302559093045687,-3.1047106344396243,3.596404666430014,-3.140561454755839,2.882663061983213,3.5751172233261386,3.7721583975843793,2.1557993169805414,1.3773103173901227,-1.9196874527363357,2.0182322165862585,-1.305571347932609,3.736770231460012,-0.896420705257184,False,c1,3,"I was surprised to find that I couldn't add any categories with the Visual Editor. I'm sure if we can add images, references, and templates, we should be able to add categories without too much trouble. Is this feature in beta or something?
--------------------------
**Version**: unspecified
**Severity**: normal",53452,2,Needs Triage,True
-1.3605456176247963,-0.969855015051067,-4.9218500168975226,2.920790737675221,4.3085450679829105,-0.7434089308443693,2.4404422363738663,0.8223149976480603,3.13155441678151,-0.6279229216355073,-0.6651891275814199,-2.9720729437496622,-1.0399541828475583,-2.1876534815918993,3.0169263967657036,0.31297382431262183,2.154462153365076,0.20979567192099702,False,c1,3,"Can't reliably reproduce but I was turning text into a link, enter a url but didn't save the new link target (so it was saved as an internal link with the label as link target), then when entering the Save dialog and saving, this exception was thrown.
> Uncaught TypeError: Cannot read property 'end' of null
load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cexperimental%2…ageTarget.icons-vector%7Crangy&skin=vector&version=20130716T133516Z&*:9463
* ve.ui.Context.updateDimensions
load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cexperimental%2…ageTarget.icons-vector%7Crangy&skin=vector&version=20130716T133516Z&*:9463
* (anonymous function)
load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cexperimental%2…ageTarget.icons-vector%7Crangy&skin=vector&version=20130716T133516Z&*:9499
* proxy
load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130715T175253Z:10
--------------------------
**Version**: unspecified
**Severity**: normal",53440,2,Needs Triage,False
-7.672765875648395,5.454614956409127,-2.0023750903037616,-0.8150583497198558,1.3495786055678225,-0.6546326400850984,-3.177286731932939,-0.18866014874816955,-1.851465675814615,1.2382949207071565,4.284517146697054,-1.0557878962726663,-2.1425659612544807,-0.6588775857821734,0.3287757628321515,-1.2406130300859466,-1.1696305763422112,0.9060603257251796,False,c1,3,"There's a few problems, if we end up solving them in different ways we should create separate bugs for one or more of them.
1) Changing the label of an internal link
Given a simple link like [[example]] or [[Example]] (e.g. no custom label), when changing the link target, it seems to the user that the link has not updated since the label (which is all we see in the editor, hovering the link does nothing since it isn't a clickable link in edit mode).. since the label has not changed.
Now one could argue the label shouldn't update at this point so that the sentence still reads the same (e.g. when changing intending to change the link from ""He was [[foolian]]."" to ""He was [[Foo|foonier]]."") and to be consistent for cases where the link does have a custom label (in which case it is more likely the label should stay the same?).
However given the following two cases:
* ""... is an [[United States|American]] thing ...""
-> "" is a [[Germany|German]] thing ...""
* ""... according to [[David Tennant]] ...""
-> "" according to [[Russell T Davies]] ...""
It is very common that the label should change to the target automatically (the second case) or at least be easy to change right after (first case). Ideally for the first case above it would automatically change to Germany and then the user can correct it to German.
2) Change the label of any link
Whether internal or external, it seems quite difficult to change the label of a link. When selecting the entire link text and typing over it, it currently behaves as follows:
> Some <a>link</a>
Select link (has to be done manually (tedious and error prone)
> Some [selection]<a>link</a>[/selection]""
Type ""hello"".
> Some <a>h</a>ello.
wtf?
Though I'm open to other ideas, I'd recommend we start by putting an input field in the link inspector for the label so that they can be changed together. Though even without that, one should be able to replace the label without opening the inspector or running into the weird ""<a>first char</a>other chars"" case.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48463",53438,2,Needs Triage,False
2.5489574282608616,4.537341228308318,0.8488711213262619,-1.9556170683703877,1.4470431312173089,-0.1538206579110174,-0.43198286602590397,0.9437171082164867,-0.2757531295702781,-2.151952143133702,-1.278791044277607,0.11156556039967747,0.9280296366811127,0.0902378667731778,-0.5902365805252368,-0.9228037896264023,0.7918884023690176,-0.7972756168797426,False,c1,3,"XML file of syndicated watchlist, slightly modified
MediaWiki creates Atom feeds for watchlists. I use a feed reader to read a few on Wikia as well as en.wp. The feeds from Wikia are all sensible and useful but the one from en.wp includes edits that do not exist. Attached is an XML file that I generated with wget (through the assistance of persons on #mediawiki) which I have slightly redacted to remove my watchlist token. Edits which did not occur can be found c. line 229 where the syndication claims that User:FelGru edited the page Everything That Happens Will Happen Today and starting around line 373 there are a spate of edits to categories by User:InMontreal which also did not occur.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11634}",53427,2,Needs Triage,False
-7.466388661857895,-1.3594328701800915,-0.3209398430733703,3.0150959069775043,-1.1128810438086918,-1.4007260499611798,0.10163321284524685,-1.9345294368056005,-2.1723116675435796,0.3881624534600068,3.5528203511416616,-1.7746130942852307,-2.4010479728216687,0.567524616639278,-2.2939461530395473,0.020499586910293632,0.8185861621888739,1.2758916959740996,False,c1,3,"See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564459649#Italicizing_wikilinks
When someone italicizes (or bolds) a wiki link instead of placing quote marks around the link itself (like ''[[link]]'' ) it pipes a link with the same text but with quotes (for example [[link|''link'']] ) creating unneeded wikitext.
--------------------------
**Version**: unspecified
**Severity**: normal",53422,2,Needs Triage,True
9.432352739436485,-3.3994719759024523,2.8782148294628946,1.6832955224953556,-5.555571301499411,0.8706537124732325,4.519642495894332,-0.29663974065643545,-1.8237974101669856,0.13731889204472925,-0.9190246917218317,0.00340602191085404,-1.3728213130553542,0.7788739609317634,-1.977156873626292,-1.4814772575923645,-0.1508963610544578,1.1730864003872312,True,c1,3,"Reported here: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&curid=37904286&diff=564438586&oldid=564436653
IP editor removes contents from last section of page. VE replaces heading text with nowiki.
Diff:https://en.wikipedia.org/w/index.php?title=Best:_The_Greatest_Hits_of_S_Club_7&curid=3428260&diff=564438205&oldid=564438086
--------------------------
**Version**: unspecified
**Severity**: normal",53417,2,Needs Triage,True
2.1505765162128463,-3.4212757905904727,4.082252005109922,3.110312826448731,0.7622766534742098,-1.3197756322979155,1.2631396078944004,1.0994554574460524,1.381303953127225,-1.1130582520489463,-0.1667794683814856,-1.9116409449789185,1.9216602291938165,1.8194143397823286,1.4366166955038429,-1.1027257918484537,-1.0885064723319124,-0.06547191032065869,True,c1,3,"Copied from English language Wikipedia:
When the user edits for example, a {{Legend}} template, color picker may be very useful. We should also think about adding there a table of basic colors. --Rezonansowy (talk) 13:32, 15 July 2013 (UTC)
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564427033#Color_picker
--------------------------
**Version**: unspecified
**Severity**: enhancement",53409,2,Needs Triage,True
-4.650022137214289,0.18994563938731268,-2.9108828837229,-8.105147869035015,-0.22330785583045087,-3.7550309248288674,3.988656617758642,2.2262343740795196,3.7458865572450177,0.7546733318790704,1.94451642054424,-1.4609164578031009,-0.2838578938909553,-0.5450515840555612,1.6347439916022433,-0.9767929087900928,-1.6078458510088536,-0.29537726057392466,False,c1,3,"How can we Disable VisualEditor completely to have old style (for example in en.wikipedia which is activated how can we disable completely the too and make it like old style)?
--------------------------
**Version**: unspecified
**Severity**: normal",53389,2,Needs Triage,True
1.8872954884906226,-12.409504624530147,4.038514770939706,-1.8264006453161117,-4.719210791060695,3.3143805663861023,1.9232503118027466,-0.0984691624446459,2.897051097818557,0.9218855317775407,0.510185267845046,0.6108086649822304,0.12707573245163228,0.29302917921227056,-1.10860205551052,0.0685953486095347,-0.20158352902850396,-1.2507849160040405,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=Wormshill&diff=564367057&oldid=557770558 for example.
--------------------------
**Version**: unspecified
**Severity**: normal",53369,2,Needs Triage,False
7.555942286401434,-4.052658278076606,-4.195542053766168,0.5000197600678744,-1.0596118128650438,-2.0184833951171037,-4.143587816627873,-0.8562957985090504,-2.1470662431240033,2.8718397384058116,-3.596076617295612,-1.3099607745748798,1.7858884434616864,-0.7733218062657468,-1.1073745271427775,-0.7345811224701722,-1.7189616903064782,1.0715985217190271,False,c1,3,"**Author:** `brunsa2`
**Description:**
I currently have VisualEditor running on an Ubuntu Server with Nginx, MediaWiki version 1.22alpha, Node.js 0.8.22. I get timeouts (504) when trying to use the VisualEditor (running Parsoid in debug often gives messages such as:
T:html: {""type"":""TagTk"",""name"":""body"",""attribs"":[],""dataAttribs"":{}} {
""0"": ""WARNING: RETRY:"",
""1"": {
""code"": ""ETIMEDOUT""
}
} Retrying Page Fetch request for null, 4 remaining {
""0"": ""WARNING: RETRY:"",
""1"": {
""code"": ""ETIMEDOUT""
}
}
Retrying Page Fetch request for null, 3 remaining ). I've tried with as many possible headers from a REST client and do not get any errors from Parsoid with that.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
**Whiteboard**: aklapper-moreinfo",53366,2,Needs Triage,True
-2.549125834225971,-2.637039640383252,-3.3731824635540857,-3.213032338689767,2.8060576000624575,0.9593843911260771,-3.246657989053412,2.4825017972170307,0.9225660124402455,-1.2155959262760612,-0.9400738357041516,-2.9807111255669922,0.2904341488171611,0.2245500976486392,-0.7380672853199188,0.06820478385574452,-0.9202218215466142,1.2329876601640473,False,c1,3,"When editing a page the editor seems to ignore the ""&oldid=prev"" parameter entirely. Instead of editing the old revision, the editor loads the most recent revision.
Steps to reproduce:
* Navigate to http://en.wikipedia.org/w/index.php?title=Baylor_University_Institute_for_Oral_History&diff=540967084&oldid=prev
* Press ""Edit this Page""
I would except that the editor would load the page currently displayed on the screen. Instead it seems to omit &oldid=prev entirely, and loads the most recent revision instead.
(Tested on Firefox 22, Monobook skin. Possibly related:50615)
--------------------------
**Version**: unspecified
**Severity**: normal",53364,2,Needs Triage,False
7.875024685942451,2.194723585654483,2.5768857523117745,1.728434924644998,-6.845079142954232,0.5458318535134725,-0.8426909647726264,1.926080497835036,3.7475493893881726,2.0552925693629787,-0.08929835278894238,0.6004386237318107,-1.712909951888018,0.08597533678708569,0.44384300476314476,0.3572994083387479,1.5481818895044837,0.14852812773344515,False,c1,3,"Hi,
In VisualEditor pagesettings>>languages below MediaWiki:Visualeditor-dialog-meta-languages-section the option button should be available 'Visit ULS language settings' for current {{contentlanguage}}wiki >> Then dialog box of ULS language settings should open up
*To understand further the need for above request,please do refer to survey
data and analysis provided at
http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#feature_to_make_content_language_input__default_28864
Thanks and Warm Regards
--------------------------
**Version**: unspecified
**Severity**: enhancement",53356,2,Needs Triage,True
3.7832407866023368,-0.5699991563662934,0.10112086978910995,3.3005587758793107,-6.326340076251231,-0.5632037212085271,-1.2866198999555731,1.317061564459431,2.0165301578768515,-1.1241689171312932,1.5927984969324487,-0.27306599303771384,-0.8183722945826482,-1.4119077711502408,-1.2568343424331605,0.36354388994956816,0.6040426093681159,0.6077178145445916,False,c1,3,"All wikis,other than english wikipedia ULS input options for input should be availabe as dropdown menu on VisualEditor toolbar [[:File:VisualEditor.toolbar.png]] just below the page settings [[File:VisualEditor - Toolbar - Page settings.png|80px]] with sign [[File:WMF-Agora-Input settings-000000.svg]] + enable input methods/'select input method'/name of current selected input method as heading.
*To understand further the need for above request,please do refer to survey
data and analysis provided at
http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#feature_to_make_content_language_input__default_28864
Thanks and Warm Regards
--------------------------
**Version**: unspecified
**Severity**: enhancement",53354,2,Needs Triage,True
-9.893442010734343,5.6707271545080715,-1.8832494281454046,1.8586023605004502,1.9100017416398067,4.716555490375594,-0.763328000643062,-0.7708143263008584,-0.7155911215295248,0.3900812981653523,1.6848588750767513,-0.9698833583551579,-0.04210046505165277,0.8630223550055742,0.6393430387848582,0.19752062430313444,0.12910733171694289,-1.29856842989607,False,c1,3,"It would be very usefull if VE added the title of the section automatically to the edit summary, if the user only changed contents in one section. This is not the same request as bug 48429, the section should be added even if the user edited the whole page, but only changed contents of one section.
Rationale: The automatic section in the summary is very usefull if you check edits of other users. Two examples:
1. A user adds a new external link (without summary). Without the section you have to look at the diff, but if the edit summary contained a /* External links */ you can guess what the user did even without summary.
2. You want to find the user who added the image to section ""Foo"". Even if there are summaries like ""+image"" this doesn't help you much, but the summary /* Foo */ +image does help you. The section is also usefull if no additional summary is given, in the worst case you have to look at all changes to the whole article and to the section ""Foo"" to find the author.
Pseudo-algorithm:
1. Find the position of the first and the last change in the new text (i.e. find the common initial and final strings in the old and the new text).
2. Find the first headline above the last change (a line that starts with that character or before it and matches the pattern for headlines).
3. If this headline is before the first change, you found the section.
4. Else look for the next headline before it of higher level.
5. If there is such a headline, go to step 3, else more than one section was changed.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53343,2,Needs Triage,True
0.09372285286582205,-2.308498901849717,-2.8602451951278827,0.047351578439880804,2.3659982541290594,0.6212661105801156,-2.048812475332842,-0.6145701926086224,-1.042262376342411,2.827181472929987,-0.5020070774560592,1.6299437505836687,2.1309103573204378,0.6902853161108258,-1.4739754173581074,-1.080008916053178,-1.623897687907764,-0.7889802922605751,False,c1,3,"Screenshot
If you double-click ""create reference"", having clicked ""insert new reference"", it generates...well, see the screenshot. Even when the window is closed, this persists for all subsequent loadings of the references tool on that page.
Windows 7, Firefox 22.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11430}",53341,2,Needs Triage,False
-3.4110102201172503,1.9666009246526883,-0.5703228093092196,0.10468247921439167,-1.9458678099218945,1.0666346805637261,-4.793904093023064,1.070275792078328,-0.512584646430454,3.8485501562724576,-0.9668930424626625,-0.2831378921306541,0.8276063642960128,0.23566777850891807,-0.7256326248810696,-0.6643474278411673,0.08477764122858411,-0.5630573245920394,False,c1,3,"Reported on EnWiki by John Broughton:
Steps to Reproduce:
(1) Click the ""transclusion"" icon
(2) In the lower left of the resulting dialog box, hover over the ""+"" sign until the bracket pair (""[ ]"") is visible; click on that.
(3) Click on ""[ ] Content""
(4) Click on ""Apply changes""
Now none of the ""insert"" icons work, and a number of other icons on the tool bar also don't work. (The user guide is silent as to what these brackets are ''supposed'' to do.)
I can confirm the same issue also occurs for me on Firefox 22, Monobook interface.
--------------------------
**Version**: unspecified
**Severity**: normal",53340,2,Needs Triage,False
-6.591857934081725,2.469167939076126,1.637345984171919,3.3454323514219766,2.744547079756763,2.1382539310572763,-3.131954508449485,2.9535867786426193,-1.0971516301261812,-2.2072832838324583,0.7227886597726427,-0.5476263925691911,-0.1155328099939874,0.48975717920946593,2.2492997201983593,1.1781998716818882,-0.2195639481092715,-0.7977393568559354,False,c1,3,"Galleries are not supported yet (bug 43037), however it is possible to select a gallery object and press delete. However that operation doesnt appear to work correctly all the time.
Steps to reproduce
1. Go to a page with a gallery (https://en.wikipedia.org/wiki/Branford,_Florida?veaction=edit)
2. Click on the gallery
3. Press delete
Expected results:
The gallery is removed
Actual results:
The gallery object remains, and the object after the gallery is affected.
In the case of [[Branford,_Florida]], the ""See also"" changes from being a section to being a piece of normal text placed above the gallery.
However, the same procedure at on [[Lip]] results in the 1) gallery being removed (yay!), 2) the two section titles being merged together (not so good).
--------------------------
**Version**: unspecified
**Severity**: normal",53332,2,Needs Triage,False
-4.834010875775171,-0.22723304558504687,-2.12294730491843,1.744040971031776,-0.6416015768657762,1.932903785806132,-2.008754470852222,1.3917473351694918,-0.23648654539374458,1.0086323800666612,0.522040471667955,0.12238228981502841,-1.4871956008287235,-0.6253577521913165,0.6895668813736178,0.1435164852175612,-1.4355280748541195,0.350755099708836,False,c1,3,"When trying to describe complex template parameters there is a need to be able to link to a specific documentation page. For instance in in the Taxobox there is a need to link to the main doc page
http://en.wikipedia.org/wiki/Template:Taxobox/doc
as there are lots of subtitles in using the template.
Further there is also a need for links in some of the individual parameter.
For the ""name"" parameter the description currently reads
For plants, see [[Wikipedia:Naming conventions (flora)]]. For all other living things, the name should be the most common vernacular name, when one is in widespread use, and a scientific name otherwise.
as the precise policy on whether plants should be given common or latin names is quite involved. There other places where there is a need to provide links to further information: [[Wikipedia:Conservation status]], [[APG III system]] of classification of flowering plants, [[virus classification]], [[Template:Species list]] and [[Template:Taxon list]] for some sub templates used.
Good documentation requires sufficient detail, more than can be provided in one line.
I've a few thoughts on how this could be implements, the whole template could have a ""documentation"": ""Template:Taxobox/doc"". You could allow wikilinks inside the ""description"" or provide an optional ""link"" parameter.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49772",53311,1,Needs Triage,False
-4.5726790772855255,1.8786812656685683,8.808221389449798,5.58028354925609,-0.3383631885869181,1.0843987472657328,1.1871636380454893,-0.5354330622430432,1.4320544694162032,-0.574842350540318,-0.4490882577139059,-1.3152473305576047,-0.7479471472615096,0.3502356298650282,-1.2095430866417605,1.0181073575218293,-0.8806582371267245,0.4127810926892421,False,c1,3,"Here in VE, the {{Discogs master}} template usage at the bottom of the page in the external links does not render.
Escaping the ampersand in the page name seems to make it work: https://en.wikipedia.org/w/index.php?title=Bossalinis_%26_Fooliyones&diff=564046051&oldid=564034183
So possible entity escaping problem
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Bossalinis_%26_Fooliyones&oldid=564034183",53280,1,Needs Triage,False
14.074021497579672,1.5740322035144825,-5.354792463313419,9.768490137828621,-3.570424930012842,-4.380871687397939,1.9168416842095084,-2.4426141229066833,-0.24953772995957207,6.682575398802745,-1.897466825368237,-0.6300290186527399,-2.847200837680189,-0.8403718069416071,2.1307188905966967,0.7624144474824938,-2.5979042263007006,0.5387464522651932,False,c1,3,"**Author:** `jduranboger`
**Description:**
In Wikipedia in spanish its neccesary tranaslate the interface for link of edit section still apear ""edit surce"" it should be ""editar fuente"".
En Wikipedia en español es necesario traducir la interface para el enlace de Editar secciones, sigue apareciendo como ""edit source"", lo correcto es ""editar fuente""
--------------------------
**Version**: unspecified
**Severity**: trivial",53249,1,Needs Triage,True
-2.012062696049674,-7.490631801898578,2.7204311893634525,2.3510852431164118,-0.22552916874864765,1.1290121079587425,1.4837024431753747,-2.3461834903431096,-3.8532780275331806,-0.3025548895774506,2.1549086990412216,0.11844622754327871,5.170555749862589,2.231031511768304,2.0419157581895178,3.015097067129574,0.36738706163854506,0.6407032315665704,False,c1,3,"Compare
1) https://pt.wikipedia.org/wiki/?oldid=36380720&action=edit&preview=yes
2) https://pt.wikipedia.org/wiki/?oldid=36380720&veaction=edit
There are two images in the first case, but they disappear in the second case.
--------------------------
**Version**: unspecified
**Severity**: normal",53244,1,Needs Triage,True
-6.334149776646257,0.16560716695725652,-4.112606498729074,0.9646035843846219,5.389841793537471,4.284338865511548,-4.773569061811887,2.447953931621367,2.322841795509561,-1.571459443059159,-3.5673936428771666,0.3088136230957301,0.2526877564343648,-1.2608848413690428,0.270271757822905,0.2803962429710342,0.2943503503219367,0.9425596319068197,False,c1,3,"Sorry if this turns out to be a duplicate - a search trough the bugs containing the words ""copy paste"" doesn't seem to turn anything up though.
The problem is as the title says: Cut and Pasting a section in the visual editor will remove all the formatting provided that section contains an image. Tested on Firefox 22, Mono skin.
Steps to reproduce:
- Navigate to https://en.wikipedia.org/w/index.php?title=Microsoft&oldid=563598458 and edit the page with the visual editor.
- Cut the ""1972–83: Founding and company beginnings"" section entirely. Eg, anything between the ""1972–83:"" in the section header, and the ""Hodgkin's disease.[4]:231"" in the section content. (This will also select the image in the section)
- Click the location where the section used to be and paste the text - technically speaking pasting anywhere causes the problem though.
The text that is pasted will be stripped of all formatting, and the image that was selected will be gone as well.
--------------------------
**Version**: unspecified
**Severity**: major",53220,1,Needs Triage,True
2.28454034691953,-3.2425107384270717,-0.3872583422074012,-0.22735954234257405,1.8411615680577293,1.2607260663110347,-2.803087903906655,0.12587143568569498,-0.4419718768052659,-3.32969198646138,-0.7406190198315024,-0.5558436170448748,3.3413592641312966,3.0874595805055787,1.119794524151387,0.3431970566273131,0.5735341720654608,0.1290332784512087,False,c1,3,"Compare the result of the wikitext
#1
#
#
#
#
#6
in the following URLs:
1) https://pt.wikipedia.org/wiki/?oldid=36373624&veaction=edit
2) https://pt.wikipedia.org/wiki/?oldid=36373624&action=edit&preview=yes
Visual Editor show us a list with 6 elements, but MediaWiki will only display two items.
Maybe this is related to Tidy?
--------------------------
**Version**: unspecified
**Severity**: normal",53200,1,Needs Triage,True
-3.2139519872363986,-1.5108905437557443,-3.278950765538525,-3.4122390273549827,5.609735414981756,-3.7476232320479097,-2.805624306260756,-0.7816045300513257,-0.4338980333246093,-2.6380888193177343,0.582525612320508,-2.6709705637383996,0.15034467536523266,-2.3916417522813487,2.018505951621277,-1.3544522284780962,1.349747151831673,-1.7315975935371513,True,c1,3,"Copied from English Wikipedia:
I was trying to edit a template in a table after the bug of the references inside template was fixed, but the edit broke the whole table. This was also happening before with the references bug. I don't know if the two bugs were reported together...maybe not. [http://en.wikipedia.org/w/index.php?title=Defiance_%28TV_series%29&diff=563767420&oldid=563763824 Here] is what happened.
<br>When I edited the template with the 12th episode, the cite error didn't appear. But when I clicked to save it, the 12th episode moved at the top of the table when it should be at the bottom. I reverted the edit and re-made it using ""edit source"". Can this be reported? Thank you [[User:TeamGale|TeamGale]] ([[User talk:TeamGale|talk]]) 16:58, 11 July 2013 (UTC)
**
This one has been around a while, but I think perhaps it wasn't properly reported earlier. I can't fidn it.
--------------------------
**Version**: unspecified
**Severity**: normal",53191,1,Needs Triage,False
-5.046445464489064,9.261871606034596,1.2941682384864244,-3.587903535101992,-2.552747118540881,4.071096941154033,-0.29969180933290396,-5.7871264860231415,0.5257240929896553,-1.1853661569170417,0.5448992324864159,1.1448564566872672,1.241179167965453,1.4832792233316576,2.342830435334948,2.4437842900837126,-0.8322295271631315,-0.174414038949525,True,c1,3,"See http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563842762#Reference_Issues:_Omnibus_Edition
User Joe Decker has detailed the steps necessary to add a reference to an article using a citation template. While I have as per his request entered some of these as separate bugs or enhancement requests, I am opening this one to note the complexity of the process. As he describes it, it is 73+ steps to achieve in VE what can be achieved in 11 in the older processes.
--------------------------
**Version**: unspecified
**Severity**: normal",53188,1,Needs Triage,False
-2.4720650551607983,1.7368305600571468,-4.695362189955723,-4.793005055467378,1.8651090025700716,3.3785826958904,2.266628162420175,1.5555775074457632,-0.7665019038392731,-0.4207139077745792,0.5213808052749243,3.282070505032233,0.6761000498460117,0.7637386827379231,2.4896333966790634,-2.8144166359826928,-3.1670358912729153,0.7388732677437717,True,c1,3,"Unclear why the second option is bolded. An editor on English Wikipedia suggests that if only one of them is going to be bolded (create new source/use an existing source), it should be the other way around.
--------------------------
**Version**: unspecified
**Severity**: normal",53183,1,Needs Triage,False
-7.780381511205727,1.210788458657131,-1.5516752043066084,5.17759766143327,3.628662552963591,3.8224938407023474,-0.8300223126596569,0.4458286932021621,-1.720630264235474,-2.5521648186170056,-1.5249454140731522,0.6258658795341474,1.2687900442887297,-1.2173903901325112,-0.8353047939261771,-1.5005801771373257,0.4060066411306096,-0.7459946611783632,False,c1,3,"**Author:** `kwwilliams`
**Description:**
There have been some bug reports focusing on the ordering of template arguments, but there's also a problem with changing the basic layout of the templates. Look at http://en.wikipedia.org/w/index.php?title=Raven-Symon%C3%A9&diff=563794138&oldid=563793891 where a vandal changed the birthname. The parameter order has been maintained, but the diff is still virtually useless because of the spurious formatting change. If the editor changes the value of one parameter to a template, that change is all that should be made to the source.
--------------------------
**Version**: unspecified
**Severity**: normal",53175,1,Needs Triage,True
-5.780546756456154,3.0420360337420576,2.474964207229462,-1.975827994042286,2.679862727416467,-0.20980154924340833,0.5150798990727123,-1.1465674297700865,-0.12606246755812942,2.6335606489934857,0.78479988113041,-0.8700194569331197,0.5061148452486868,0.09803379467513818,-1.8904688219290269,-2.0240429538388462,1.48877290344785,-0.8846331610084195,True,c1,3,"In http://en.wikipedia.org/w/index.php?title=Renewable_energy_in_Seychelles&diff=prev&oldid=563530801, the contributor says that he selected the words ""diesel generators"" for linking, but the editor inserted the nowiki to prevent the plural being part of the display.
See http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563816729#Changing_link_text_often_results_in_bad_code.2C_wrong_links_and_unmatched_.3C.2Fnowki.3Es for this and other cases. I'm afraid i'm not quite sure how to report this, since I'm not sure what's happening.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=33091",53173,1,Needs Triage,True
-6.561865996425054,-4.070534745959494,-5.967066622495169,1.7952664617632004,-1.9413429882341682,1.3711222012225803,-6.461665819393393,-0.9836480006766871,-5.112556774533546,-0.5972953807142787,0.9344170303325021,1.801440928443072,3.486689107263533,4.6422507919758225,3.7146419062133775,-0.954609755617335,-0.3803113485053755,2.1855836295707114,False,c1,3,"The screenshot is the result of the following:
1. go to article
2. blank article, removing everything
3. type ""1""
4. type ""2""
..and what you end up with is:
1
12
The text is, in addition, impossible to delete.
--------------------------
**Version**: unspecified
**Severity**: normal",53169,1,Needs Triage,True
-6.489872123005483,-0.8190943666536246,-4.611617503808011,0.29448475993678436,-1.8455055474580773,3.1883073537616964,-0.333175047230986,-3.808610236205242,2.041543651340988,4.705996693864096,-0.10283989979814656,-1.0540294965439592,-0.5508463563290222,-1.3545900576472318,2.2028719421433696,0.7270271398364532,-0.7102812910250277,1.624222586606712,False,c1,3,"It would be nice if double-clicking a parameter name in the template inspector - in the 'insert' view - inserted it, to minimise scrolling and such.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53165,1,Needs Triage,True
-1.4304145442200817,-4.643741436951087,8.190967807565134,1.0761233016780172,-0.020167154413532895,0.8095667685117731,2.0594589027953463,2.18929838598331,0.4791383432889723,-0.9179511502629993,-1.1547760991196612,3.226287486289892,-0.5037113267386566,-0.7453276708966614,-0.35904928891845067,-1.859024098008219,-0.03252826677031373,0.41669582359828294,False,c1,3,"Finding the categories under page setting is non intuitive. Adding another icon next to references would help usability.
This is discussed at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Icons_are_incomprehensible
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50239",53153,1,Needs Triage,False
-5.561342334906588,4.004376380801947,0.2982633481536858,1.462474632378723,2.8307873335368083,-2.859243713525048,-1.047953244909916,-0.9433437808469731,0.6436041535480936,0.008501927232847706,0.9304381704180567,-1.4144637080329745,0.6669074868394356,1.55106637350152,0.024960426602094188,1.1188297636517341,0.13275704453684112,1.8540428005064367,False,c1,3,"English Wikipedia user PamD reports that sometimes after replacing one stub template with another she is unable to open the page settings dialog unless she saves and then reedits the page.
I have done a small amount of testing and can confirm that the following steps will reproduce the bug, but only intermittently:
1. Open a page in VE that has one or more stub templates (e.g. any article in [[Category:England stubs]])
2. Delete the/one stub template by selecting it and then pressing the delete key
3. Launch the transclusion tool from the toolbar
4. Enter a different stub template (e.g. Wales-stub), select it from the list and then click ""Add template""
5. Add the template to the page by clicking the ""Apply changes"" button. In my testing I never entered any parameters or options, PamD has not specified whether she does or not.
6. Click the ""page settings"" button on the tool bar.
If the dialog opens, choose a different article and try again. In my testing it failed to open just under 50% of the time, PamD implies it happens less frequently to her but doesn't specify.
A bit more detail is at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563709233#Can.27t_open_.22Page_settings.22_after_changing_stub_template
--------------------------
**Version**: unspecified
**Severity**: normal",53134,1,Needs Triage,False
12.146787032500223,-1.4310059000519324,2.609753247703214,-1.3061148763553936,-3.366057087435383,1.9461258610332062,-5.134016336953988,2.0404859141606386,-4.4032302403236505,0.2574023302484738,8.252934880564881,-0.8314046839972,-4.901197042410094,-1.0093342093811195,-0.5206462045716629,-0.5007275976510839,-0.05743129602596597,0.8916343296496272,False,c1,3,"VisualEditor appears to be inserting ""null"" into external links occasionally.
Examples:
https://en.wikipedia.org/w/index.php?title=Carrie_(musical)&curid=7695755&diff=563576490&oldid=563235599
at [[Ithaca College]] in [[Ithaca, New York]] by the Macabre Theatre Ensemble,<ref>[null http:///www.icmacabre.blogspot.com]</ref>
----
https://en.wikipedia.org/w/index.php?title=Embarcadero_Delphi&curid=349208&diff=563574811&oldid=561383018
Delphi has large communities on [[Usenet]] and the [[World Wide Web|web]] (e.g. [null news://newsgroups.codegear.com)] which
--------------------------
**Version**: unspecified
**Severity**: normal",53132,1,Needs Triage,False
-0.1783624913282189,-1.397009233902482,-1.0653473413837329,1.8084269975333407,2.9333629514678456,-1.600043942423888,-0.5374859521318678,-0.040490341528587936,0.322180635432713,-2.330130882093044,-0.8505896380195579,-0.7072550455664892,2.3790929175502025,0.059649037991095,-1.3003366557408444,-0.8659144404664603,1.1800721020376355,3.2145301855381625,True,c1,3,"Copied from En Wikipedia:
***
When editing a template, when I click remove template, and then without closing the dialog, click add -> content and enter some text, the template is not removed and the editor hangs on saving and reviewing changes. --WS (talk) 11:47, 9 July 2013 (UTC)
***
Tested with the same result.
Maggie
--------------------------
**Version**: unspecified
**Severity**: normal",53130,1,Needs Triage,False
-9.26506451767454,1.0912481673826342,-4.732211812558367,-3.527877993439377,-1.7784817474524315,-3.456574723371671,-1.19347286582932,0.755089299961672,0.6600844218578951,1.863984312721139,0.9157651446869326,4.0339820509263165,-3.14469430606115,0.05329064572933273,2.6439459742407783,0.05232183734829232,-1.340224250869192,-2.106446588115227,False,c1,3,"Some users add [[links]] to edit summaries, which can be really helpful; unfortunately as markup it needs checking to ensure that it isn't borked. Accordingly, would it be possible to render the edit summary in the 'review changes' pane, if one has been provided?
--------------------------
**Version**: unspecified
**Severity**: enhancement",53125,1,Needs Triage,True
-1.4765364440790887,-0.9872180962625929,0.8977575558195348,4.568413063176982,1.897085362005881,3.3879526411440963,1.7024832113596222,-2.69165193160132,-0.5617070170380285,0.753548546033791,2.179505064844587,-0.11621034297837696,-1.301340160658583,2.1254487896641043,-0.7433804939402888,1.1238942025120067,-0.42834034435793344,0.46098702071386577,True,c1,3,"De.WP often uses ""{{:Target page}} in its disambiguation pages and VE produces two problems: 1) The subsequent non-template disambiguation entry in the list gets sucked into the content of the previous template-entry; 2) the template blocks the option to edit the entries surrounding it. See:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563687401#Transcluded_pages
--------------------------
**Version**: unspecified
**Severity**: normal",53119,1,Needs Triage,False
-4.833357870332561,1.993528733458355,-0.24369760268456986,2.715524576423075,-0.7232763762830323,-1.8897870597953368,2.215574095371868,3.5005170613166077,-1.2324844970400295,-0.8994244164249712,0.5612778066934125,-1.9824738405011029,0.27591284467365496,-1.1971500514583635,0.07826084892865293,3.161449127477544,0.6902804967921965,-0.03695245274642445,False,c1,3,"When a raw URL with no markup (e.g. http://www.sucs.org/~cmckenna/photos/quizes/tq2012/July/Jun03key.png ) ends in .png, .jpg, .svg or .gif [capitalisation variants not tested] but does not work (e.g. it gives a 404 error) then only the filename portion of the URL (Jun03key.png in this example) is displayed in the visual editor. Visual editor cannot then edit this URL to correct it, meaning that typos, etc cannot be corrected without using the source editor.
Links to other image formats (e.g. tif), html pages, .txt files and pdf files, and all urls enclosed in single bracket markup work as expected and are editable in the Visual editor. See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox2&oldid=563642435 for my sandbox testing.
This is not unlikely related to bug 51092 in some way.
--------------------------
**Version**: unspecified
**Severity**: normal",53103,1,Needs Triage,True
4.007246830664679,-6.270834011635259,2.865423911976002,-7.563969222158721,-3.3450507118278425,-1.1801750471605363,1.4071492210842091,0.29417344159909153,1.848266910883302,-0.5176390277722032,-0.032699411643399845,-4.091563837410489,0.30125428000958054,-2.9314834605293596,1.477025755075557,0.36200460110290356,1.3711070514579393,0.9823235186360295,False,c1,3,"I just attempted to make https://www.mediawiki.org/w/index.php?title=Lua_scripting&diff=728272&oldid=728271 with VisualEditor and got https://www.mediawiki.org/w/index.php?title=Lua_scripting&diff=728270&oldid=664107 instead.
--------------------------
**Version**: unspecified
**Severity**: normal",53094,1,Needs Triage,True
-6.58080747760756,3.958341125684516,-1.9739265110174848,0.653351400485835,4.772967285179625,1.0991881182317031,0.8367907593517678,-0.4462319054379914,1.5312605063130296,-0.43179164537945347,0.6323389418576584,-0.8545045065493987,0.4125181220204017,0.16399732388077126,-0.16620321047485653,-0.16347841055133283,-0.3131255888942239,-0.5839096103025496,False,c1,3,"Screenshot of ripped-apart link inspector
I can consistently reproduce the following:
* Select an unlinked word
* Create the insert link button (with intention to turn the word into a link)
* If you hit Return immediately after (before it has finished opening) it will replace the focussed node with a new line. Though that is a separate bug and arguably an invalid use case (why would one be pressing Return at this point, the user hasn't even seen the options yet. It interpreting it as intend to replace the node isn't entirely unreasable, but that's a separate bug - bug 51075).
* At this point the link inspector dom has blown up. Part of it is gone, and the other part is left half-way across the screen at a seemingly arbitrary offset (see attachment).
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11776}",53077,1,Needs Triage,True
3.4404396590456305,1.0841115600766251,-3.2438239220442444,1.6246139970569953,-4.3395250380138926,3.4169391579779065,1.5314703392079476,1.4279525230684595,-0.30902709022275665,0.06157611751636871,1.0828015799618327,-0.8410187759869928,0.48785827645886304,-2.687025930991959,0.5471290888826692,-1.8339485151202024,1.0633322864510901,-1.5706323257103287,False,c1,3,"**Author:** `FT2.wiki`
**Description:**
Tried to add {{cn}} to an article, visual editor silently added NOWIKI../NOWIKI tags on saving, which had to be manually removed.
http://en.wikipedia.org/w/index.php?title=XFS&diff=563579994&oldid=562618140
Unclear if this is the same or different as other <nowiki> issues on bugzilla
--------------------------
**Version**: unspecified
**Severity**: normal",53072,1,Needs Triage,True
3.870079752171914,-7.43367817161187,-3.677188519440252,0.5025776606318442,-2.3795442228960626,0.7577719421595088,-2.040202468517089,-0.007651284287335691,-4.214816576698579,1.2447855249319986,0.7421935218649987,2.210209628352784,-1.307546609471034,-1.5867652771337903,-1.1992111972317927,0.053350860850766124,-1.4370454992916701,-0.9003063434181637,False,c1,3,"corrupt <class> identifier in DOM for Link
see screenshot
what is this ""class""?
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11753}",53066,1,Needs Triage,True
-6.316273858107644,5.439400239197127,2.313055229468187,1.4132214266278171,0.3061080628251145,2.1128629192253463,4.786727915151112,-2.3326238024225887,-3.018166666623215,1.3460450291010169,1.7539061557499669,-0.6045623331510777,-0.4010496179908669,-0.44493827690837584,0.6313895959688081,-0.09218257791113305,-0.3681090811324381,0.8378839268645561,False,c1,3,"Reference editing on, for example, https://en.wikipedia.org/wiki/Friedrich_Nietzsche?veaction=edit, sometimes takes you to the wrong citation. I'm not sure what the problem is. My only current theory, as a luddite, is that the difficulties the VE/Parsoid has with references in templates may be responsible for a numbering screwup somehow between read and edit mode.
--------------------------
**Version**: unspecified
**Severity**: normal",53058,1,Needs Triage,False
0.004207811869469502,-11.091038390274356,1.3768179724661387,-1.278308147677997,-3.077775077907103,-3.1291771642492483,-3.5338236297165464,-1.384258548357904,2.5164895199901745,0.4882731231225348,5.390512734275557,2.4511369179772657,-4.8678541584515385,0.1398240720772872,1.661091614635347,0.2606669872097037,2.0582193109383393,-2.5499462984141816,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=User:Okeyes_%28WMF%29/sandbox&diff=next&oldid=563541289 for example; It should be [[''death'' metal]].
--------------------------
**Version**: unspecified
**Severity**: normal",53054,1,Needs Triage,False
-4.886477415929293,0.9451731025650858,-0.37101654159584285,1.077240589341569,2.9170081494583022,4.2774402320961045,-2.8669531551574754,-0.992744387276887,1.1408561976120661,-1.9820999738999867,-0.12245340787603531,-2.0136266665581855,1.7984111558267015,0.6832876088798141,-2.5185336595187002,-0.1842358649030521,-0.016758653840972304,-1.6944733297302683,False,c1,3,"a screenshot with the problem
To reproduce:
1. Go to https://en.wikipedia.org/wiki/Boris_Ponomarev?veaction=edit
2. Click the template at the bottom of the article.
Observed: The transparent bluish color that shows the template tool (puzzle piece) goes all the way up to the paragraph that precedes the page, even though there's a lot of spacing between them because of the infobox on the side.
Expected: The transparent color must only cover the template itself and not other elements.
See the screenshot.
Tested on Firefox 22.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11723}",53048,1,Needs Triage,False
-4.47623278676082,-1.8239857398680712,-1.460120083987869,-0.07515276701264728,4.1156061271875615,4.701843345837742,2.652323571933132,1.0880308357594393,-3.5522616399400055,4.838587475985788,1.8696332129824467,-3.2501288609097854,0.2116158342421981,-0.19148267300086896,0.39688952224177587,0.11388242501125692,-3.5520456539469976,-0.34728797853274385,False,c1,3,"Possibly the most vanilla dirty diff ever, if it is a dirty diff - in https://en.wikipedia.org/w/index.php?title=The_Painted_Bird&diff=563388980&oldid=544897993 the VE has added an extra space (before ""novel"").
--------------------------
**Version**: unspecified
**Severity**: normal",53024,1,Needs Triage,True
-7.629102612612236,4.249994735738916,-1.0871388898296743,1.8547136586373636,-0.5724710043416265,2.668205646441206,1.6589769084429324,-3.0166256519650454,-4.6481505460451515,-0.5328755936194405,1.563242471113758,-0.5853568492746722,-1.1981261638158607,2.0688804277576303,-3.75639877121163,-0.2190613466101209,-2.843143708744195,-1.867492516744414,False,c1,3,"On enwiki, at least. If you highlight a link, format-clearing does nothing; if you click on the link to the point where the system registers (i.e., the link icon pops up), ditto.
--------------------------
**Version**: unspecified
**Severity**: normal",53018,1,Needs Triage,True
-1.1276257141248087,-4.662867194908234,5.11384847864587,-2.5712829451546995,-0.24406371908542407,4.546676413783131,1.047513661129658,1.2575605595621098,0.004093516698659927,-0.5036299404739912,-0.7264290672365665,0.3442617542793147,-0.33593925998086505,0.905079475894377,-2.6462381327989952,-0.7921996988443507,1.3345137307730737,-0.1535323006345044,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=Vicarious_Visions&diff=563488422&oldid=563388782 and https://en.wikipedia.org/w/index.php?title=Vicarious_Visions&action=edit&oldid=563488422 for how the markup for that appears.
--------------------------
**Version**: unspecified
**Severity**: normal",53017,1,Needs Triage,False
-5.471333862757074,2.9635060424471646,-1.9809521562213135,1.3309084225463832,4.618918582409391,-1.7260676696362727,1.256943472120506,-0.7038393980624126,0.31298635219663196,-0.9361115176472565,-0.07746749709729084,-2.933179878100243,0.2708332816637333,-1.8237490037809763,0.006750185022449173,0.07598500028502653,0.4562301858799416,0.140289303773234,False,c1,3,"There appears to be an elusive bug in the references editor where, when a reference contains a template, the blue highlight surrounding the template in the reference is sometimes misplaced outside the references editor and therefore not usable.
I've seen this myself a couple of times (in Chrome/Ubuntu), and it usually just stopped happening after a while and I'm not able to repro it now, so it may be some kind of timing issue. Robert Rohde also reported this today (July 8) and provided a screenshot of the bug here:
https://upload.wikimedia.org/wikipedia/en/5/5f/Bad_Ref_Edit.png
--------------------------
**Version**: unspecified
**Severity**: normal",52991,1,Needs Triage,True
-5.536446096785689,-1.511683582373104,-2.383020220575638,0.030598865479868786,1.1594654095972543,3.2316360459936924,-3.130420705787615,3.5470227327678185,1.0717768021655352,1.0778188624410348,0.39507830896595975,-2.0115008715970024,-1.5793314849545528,-0.36332087377285127,1.4661926438666848,1.608851979977027,-1.8572425867246154,-0.369644704877099,False,c1,3,"1) Open an article such as
https://en.wikipedia.org/wiki/Convex_function?veaction=edit
2) Click in a non-linked word ""function""
3) Click in the link button (CTRL+K)
The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided.
Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used links..."")
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50160",52986,1,Needs Triage,False
6.246068461554044,-1.5408018297192179,-0.9600530262122628,-4.753375790687136,0.07622314131731656,-0.6134784354695747,-2.5658324697146098,0.3527106261841656,0.5236642263421069,0.6060064806266112,-2.5151585903318576,1.058916934075121,0.24980613028683152,-1.372751759332242,-1.3982923022888194,0.0454905121024769,-0.6537257724700775,0.8601948140337414,False,c1,3,"How to reproduce:
* Go to https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/Client_download?veaction=edit
* Set the caret behind ""supported by the Timed Media Handler extension""
* Try to drag and drop ""Support for Ogg Theora and WebM"" directy to where you have set the caret.
Current behaviour:
* Selecting not possible (Dropping mode starts immediately like if something is selected but the caret suggests that nothing was selected)
Expected behaviour:
* I can select ""Support for Ogg Theora and WebM""
----
You receive this bug's description kindly in English.
Rainer Rillke
--------------------------
**Version**: unspecified
**Severity**: major",52977,1,Needs Triage,True
-6.088169466361226,-2.2320218619628687,-2.055530354868937,-5.049998569449393,3.508570139035545,1.9769425235514484,3.745594439300807,1.016163380943158,1.5791836353366622,2.581758272159627,4.372266328943773,0.24819017564972867,1.2286777283562649,1.1327614912961241,-1.0310609817119998,-1.6276253552104594,-0.7576490780406132,0.4107620016632303,False,c1,3,"There are so many things that do not work, I suggest to test the software better before deploying. I will open a second ticket for a new recent issue.
--------------------------
**Version**: unspecified
**Severity**: normal",52975,1,Needs Triage,True
-7.0120075650425076,7.039978496330807,-1.2324571199012322,-2.977764526190172,1.0616927687652364,0.7648054568190579,-0.4691305792618268,-4.711156586622335,-0.4034405086185445,0.17483873263137806,2.6505213768091838,-1.2706850585735014,0.6470509587260604,-2.1695482347784036,0.3186602130229952,0.27285253638126333,-0.9945651479108835,-1.0301470906548522,False,c1,3,"If there is a link to an non-existent article or page it shows up in red when viewing a page. When you click to edit with VisualEditor, the redlink shows up as blue which makes it appear that it is linking to a page that has already been created.
For example, in my sandbox I created a link to the non-existent page ""testinggg"" using [[testinggg]] in source. After saving the page I returned to the sandbox and saw the link in red. I clicked to edit the page with VisualEditor, and the link turned blue. It should remain red if the page has not yet been created. You can try this for yourself in my sandbox:
https://en.wikipedia.org/wiki/User:Keegan_(WMF)/Sandbox
This may be a Parsoid issue?
--------------------------
**Version**: unspecified
**Severity**: normal",52974,1,Needs Triage,True
-5.128908220699804,3.9843516216018635,1.193709143633125,0.567849662303366,5.069450629088889,3.5687187569460423,1.4024862426197267,-3.8063050251425503,0.12793964077706804,0.10795948715233994,2.6578754524375063,-3.7292109942973894,1.532539239885498,-2.87928473736565,3.582515778159194,2.6498503187374105,0.7803444058921067,-2.0722876121974836,False,c1,3,"I tried to copy text from a plain text file (in the Kate editor). The line endings were not preserved and the whole text was copied as one big paragraph.
You can see an example here:
https://www.mediawiki.org/w/index.php?title=Language_portal/Definition_of_Done&oldid=726988
It's the first version of a page that I created in the VisualEditor. I formatted the first few lines manually, but left the blob in the end as is.
--------------------------
**Version**: unspecified
**Severity**: normal",52946,1,Needs Triage,True
-8.545438828080108,6.749224169900664,0.39250062518954465,2.4473286233592857,0.12693485438401053,-0.6989829673065275,-0.026325494700743413,-0.780218182824618,-0.3989949491258056,-0.9017792717388868,3.1112969289701957,1.7156949166771398,-0.15928817773591586,-0.3863461453773871,1.141099452866289,0.4169064272882166,-0.5346960014926694,-0.1237155390541993,True,c1,3,"On English Wikipedia, it is stated that some common templates need a context specific editor.
Examples offered by (and with explanatory text by) User:Clem Rutter
****
*[[Template:convert]]
([[Template:frac]]
Those are simple- all we need is to display the parameters so they can be changed, when focus is lost they just display. For useability you could enter the the inline-template-editor by double clicking or ctrl-shift -click.
*[[Template:fact]]
*[[Template:cn]]
These two are more complex as editors are there to change the *cn to a reference- of which the *sfn template is ideal. So here on a double-click, you need to change a *cn to a *sfn and enter the inline-template-editor to add the fields which are Name|Year|pp=page-lastpage. For a sfn, on leaving, you need an alert that offers to take you to the reflist to confirm or edit if that reference is missing.
*[[Template:sfn]]
Explained above.
*[[Template:efn]]
Simplicity- there is only one parameter. Though an alert may be needed if the Notes {*{notelist|notes=}*} structure is not in place.
*[[Template:reflist]]-
fiendishly complex from a programming pov but functionally simple- as the functionality we need is
add a line in wiki code- I C&P common ones from a master list of commonly used texts in field that I keep in a subpage, or as a textfile on the desktop. An easy technique to teach when you are training at a museum or library as you can give your students the file on usbstick
change some data- for instance an isbn number
this can be achieved in a popup wikicode editor- or even gedit, vi, geaney, wordpad as no parsing is required.
([[Template:infobox]]
it is totally essential to just be able to change the content of a field visually. It is desirable to add new fields but this is of lower priority nigh essential, and this wont be achieved until the issue of recursive templates is resolved. (That rates as essential on my list.)
I leave the list there for a Linus test, so if you could pass this on to your dev team and ask them to add these to the functional specification. Here is an example of a sample edit for them to try Swanley it keeps coming up on my watchlist:
*first three references contain raw urls- probably could do with a *cite template her- not mentioned above
*fix a *cn
*change item in infobox
*convert acres to hectares needed
All of that could be easily achievable.-- Clem Rutter (talk) 18:20, 5 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: normal",52915,0,Needs Triage,False
3.0090994520643,5.2736416334315415,3.0565274031146004,2.367846018771258,-3.4093718099166215,2.0376551183240457,-1.060019413595949,2.8381170318226827,0.34835677478830673,-0.5078574173190038,0.6208388065431834,-2.640669811099337,-0.7896826010200426,-0.9738904011441867,-0.6440027642736279,2.9337367546634527,0.5115406100855056,-1.4585629060569743,False,c1,3,"screenshot of CE after transclusion editor
https://en.wikipedia.org/wiki/Luton?veaction=edit
Edit the infobox template. Don't do anything, but apply changes. A lot of the blue links in the infobox are now rendered as black pipe code, for example [[List of towns in the United Kingdom|Town]] instead of Town.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11424}",52909,0,Needs Triage,True
-8.656669063593242,5.466371971260589,3.5732588229689135,6.375663589531627,6.238212820393498,5.320175248313703,-0.8819528702498207,0.20677516526456324,0.6408795908212893,0.25726066508053336,0.6928917465740279,-1.3856570939682962,1.1082362478379353,0.7619151901944949,-0.44384075971161696,1.0280228078109972,-0.32301533398668014,-0.30104858011843283,False,c1,3,"Take a page with a reasonably sized infobox.
Make your browser window 11"" size or something
Scroll down a bit
Click the infobox
The infobox has become selected, but the anchor for the editor, being in the top right, is often out of view well under the toolbar. This leaves the user without a proper hint.
--------------------------
**Version**: unspecified
**Severity**: normal",52907,0,Needs Triage,True
-7.532916540621013,1.9171172065248179,-0.14975667168852702,-2.7780882296224463,8.387442981311553,-0.6391560076101346,1.8108202053131652,2.2205233248057694,-0.29967299863680913,0.1283656828158053,0.9087645994595688,-0.6808702970372756,0.20230788536654387,-0.3758132069125928,-0.8829055483359234,1.1621449653547282,2.5909619773239596,1.7864464293143982,False,c1,3,"In some respects the save dialog is partially modal, which is a strange and unfamiliar concept to some.
The content is not editable, and partly blurred. Yet I can click links inside the content. The buttons in the toolbar have a functioning look, but don't actually work. Also, when clicking outside this dialog, I would expect it to dismiss, but it doesn't.
--------------------------
**Version**: unspecified
**Severity**: normal",52903,0,Needs Triage,True
1.4991847468986506,-0.18632729343598164,-3.1076956857610583,-0.23754654494236616,4.681879213155689,2.3615052872539053,-2.842854789505159,0.5804132478262506,-1.419048184499884,-2.3708189991392308,4.361322189157345,-1.9101157719408564,-3.317655015208639,-0.5447833552794954,0.3160541898763167,-0.7242192776710994,-2.0414457721169037,-0.048028219777416226,True,c1,3,"Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-)
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387",52835,0,Needs Triage,True
-3.688336458375058,-0.19619751761113058,-1.9162742571966316,-3.832307332333037,5.213707484009522,3.747667286091242,-3.3986533218242108,-2.687112046100512,-1.1991005674789945,6.186226741480057,-4.227802968314646,-2.3145609095180726,-3.111315026755743,1.6809386192501687,1.7650140680014328,-1.553853816423415,2.0376268702835905,-3.3833048295323813,False,c1,3,"If a user triggers the abusefilter through the VE, they're informed ""'''Error:''' The modification you tried to make was aborted by an extension hook"".
Probably not helpful.
--------------------------
**Version**: unspecified
**Severity**: normal",52828,0,Needs Triage,True
-6.462730566555539,1.717584552212422,-0.6453078972961084,2.249277371633493,2.7573198273711363,2.4006628098085754,0.24149492098715708,0.6901467307555313,0.8707617231916598,1.811721863605099,0.2510152666064571,-1.713452934975559,0.6955977416098604,-1.7659627601216283,0.8983355855366089,-2.8438506709683358,-1.436223377682327,-0.37233253872309824,False,c1,3,"With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled.
--------------------------
**Version**: unspecified
**Severity**: normal",52817,0,Needs Triage,True
-1.5955172944915714,-5.960603614333374,6.077326299020715,3.2455132932510073,-0.005864395294602032,1.7864061400377718,-0.45153859620276293,-0.9696717112415434,2.9830574528109866,-0.6569693936475867,-0.3473048955862321,1.4082145069140275,0.583847194955851,-0.20926448116974328,-2.5095541861316604,-0.09025366133298629,0.4971939814197561,0.6667499193197679,False,c1,3,"Try removing the whitespace at the top of https://en.wikipedia.org/wiki/Burr%E2%80%93Hamilton_duel and see what happens.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid.wmflabs.org/en/User:Jdforrester_(WMF)/Bug_50797?oldid=564303673",52797,0,Needs Triage,True
-8.030800314925973,0.37046072226866755,4.949113792135517,5.9560468072690345,-0.9002296397489129,-6.426095404824853,5.137201004376636,0.14865476731951488,-0.927877771083003,-0.057031543541286034,-0.6430448269102,-1.3273924072534526,-1.4288212900495374,0.2301752194777693,-0.5334426085788717,0.47559059395264214,0.14171544667788893,0.15421352255446474,False,c1,3,"We very deliberately have user-specific preferences for default image sizing, rather than specify a fixed size in each article - it compensates for varying screen sizes. The VE isn't factoring default size preferences into account.
--------------------------
**Version**: unspecified
**Severity**: normal",52766,0,Needs Triage,True
-5.981603311191065,5.660329383596125,1.7070256177442218,2.3937947452162853,2.5062128683771214,4.046534561303562,0.12537298786493078,-2.0682512930157277,0.35795771216349637,-0.2832193727111827,0.4424564006464178,-2.516329871808434,0.15079600742460997,0.20133139723891524,-2.45078447377294,0.0686925139567377,-1.2372492357176224,1.177614231467875,False,c1,3,"In the case of an edit conflict, the structure of the VE means that the common workaround (taking discrete wikimarkup changes, copying them, opening the newly revised article, pasting them in) doesn't work. What's the plan to handle ECs in the VE?
--------------------------
**Version**: unspecified
**Severity**: normal",52753,0,Needs Triage,True
-0.6202808669118949,0.14555760404567586,-0.2266557687516908,-4.841757058671519,2.205569494439108,-0.507166236685726,0.2032412737620577,-2.191786440587196,-0.05738013653436902,1.6111345193609994,1.0943379370785338,-1.3375374191299871,2.7038436977683467,2.8451259285532293,2.076940196999699,-1.962472147805097,0.6765078551089492,0.8748665629509451,True,c1,3,"Copied from English Wikipedia:
When I've added one template using the transclusion icon, please offer me a button which says ""Add another template"", rather than insisting I click on various totally non-intuitive bits of the window to achieve this! I've just managed to add two separate stub templates, but it was still an uphill struggle. PamD 07:32, 4 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: enhancement",52744,0,Needs Triage,False
13.135820649033427,-13.326755008747895,1.9203812124161317,-4.144047397558072,-0.48214776629467304,3.6142166346904006,0.018681654258890568,0.22762884496734404,2.5836853641370254,0.2065691564764789,1.0047948662719528,0.8000379296761695,2.786954217348475,2.1895066532322653,0.5682486468755927,0.34228228202599387,-0.2664668627548632,-0.8019923374290141,False,c1,3,"See https://en.wikipedia.org/wiki/File:VisualEditor_-_Cite_template_layout_issue_%28TemplateData%29.png - Firefox 22, Monobook.
--------------------------
**Version**: unspecified
**Severity**: normal",52738,0,Needs Triage,True
-6.20847940989519,-4.741595037243599,-4.521062298494586,-3.02262617023164,4.2353926852865875,6.169020400926375,2.0807005799318263,0.7723748159448259,2.2501428575059688,-0.17584142263895597,-0.43996869852743936,-1.161172540459221,-2.2134720679617503,3.7890460105018615,-1.3885048161270284,0.6704082971157796,0.42588614420861726,0.18385153563501944,False,c1,3,"If you add categories to a page and save, the newly-loaded version does not include the new additions.
--------------------------
**Version**: unspecified
**Severity**: normal",52737,0,Needs Triage,True
-3.81415510749215,7.569652521137314,0.1843130724148203,8.5297833506793,0.8755928444320205,5.445348866529745,-3.692383894375463,-1.4359947663179415,-1.9171123011989901,-0.2331187549082614,1.1865898977244105,-2.105670973118309,-3.335170731139603,0.41154380230708476,-0.3763447233224442,0.1490863461516112,-2.0726873867964617,-0.708476642950582,False,c1,3,"This edit:
https://en.wikipedia.org/w/index.php?title=Percy_Jackson:_Sea_of_Monsters&diff=562794756&oldid=562792500
is an example of a dirty diff where VisualEditor/Parsoid appears to have wrapped <nowiki> tags around existing <nowiki> content (in this case the ""|"" symbol in the title of a cited website) inside a template inside a reference.
--------------------------
**Version**: unspecified
**Severity**: normal",52724,0,Needs Triage,True
-3.828031584202722,0.1362069189413493,-1.0125812084299657,-5.572256202007109,1.4417174253122185,2.613540557445588,1.3584114959703317,-0.7886545675273323,2.9139843551361473,2.0628230357490276,1.3285241971442043,0.9652139805700413,-0.3288764145340526,1.6226705461978925,-0.484118295436188,-2.269927564629846,1.9480229387415278,-1.4391084215539816,False,c1,3,"I can't seem to find a way to add alt text to images, which is pretty important from an accessibility POV. Any mechanism I'm missing?
--------------------------
**Version**: unspecified
**Severity**: normal",52709,0,Needs Triage,True
-2.3543854581474433,3.7972202125747465,2.153226349510149,3.0066773341701216,1.7759856198630941,4.070775169044239,0.3373499601105605,0.8206233550601617,0.8648733429245445,0.20333245445750237,0.9506993781485984,-3.558542542028804,1.3412962722816393,-1.529774498569251,0.9289246507606785,0.8359737722289753,3.0761937284581107,-0.9946017755537819,False,c1,3,"This came from the VisualEditor feedback page in Hebrew. I couldn't replicate, but the problem is evident in this diff:
http://he.wikipedia.org/w/index.php?title=%D7%A2%D7%96%D7%99_%D7%90%D7%99%D7%96%D7%91%D7%99%D7%A6%D7%A7%D7%99&diff=14341709&oldid=14341704
The user only changed the link at line 20 (blue, left) but VE seemed to have injected a bunch of wikitext into the template box above.
--------------------------
**Version**: unspecified
**Severity**: normal",52684,0,Needs Triage,True
-6.636629568468388,5.22385418134634,4.187779606980175,3.350364057500429,-1.1551974926751334,6.817520263076173,1.9772009617348596,-1.1775125598239677,0.3398405989695924,0.938747079018162,1.5187696713283683,-4.053250019702602,-0.21089481124221354,-1.5925261275861677,2.5814544836508135,2.1906085584282735,0.20756602336195518,-2.2810090571561887,True,c1,3,"This null edit to an article (https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&diff=562710419&oldid=562703260) made the category hidden inside of a template in use on the page (template in question: http://en.wikipedia.org/wiki/Template:Episode_list) visible in the editor. It should not be visible.
--------------------------
**Version**: unspecified
**Severity**: normal",52675,0,Needs Triage,False
2.783787420891428,-7.478435698959272,-3.7592564647017657,0.9773194963937479,4.359906682961407,-0.6087232844194409,0.37428802023576146,4.10200400722653,2.3292087163638557,-2.7666073147970427,-2.07877526498026,-0.6572235791846422,-1.3150689000796145,-1.5120281160677584,-0.1460278386674574,0.535221656448521,0.7720915210041859,2.8623356483976155,False,c1,3,"**Author:** `wikipedia`
**Description:**
Using the [edit] next to the lede (section=0) only allows invoking the source editor.
Ideally there should be consistency, and VE options should either be always shown, or never shown.
--------------------------
**Version**: unspecified
**Severity**: normal",52653,0,Needs Triage,True
-4.576896719351391,-3.998617458894655,-2.4060081848099344,-8.02528435027565,0.9178555771407098,-0.8919796437288587,3.706499996279832,-0.7237477919683457,2.663979636196804,1.398723368814987,2.4324792566172886,0.6201191724108905,-0.421475384288132,3.336361629063818,-1.7565213092067054,0.47500801168324347,-3.553737491728671,-1.1476933429296494,False,c1,3,"See https://en.wikipedia.org/wiki/File:Visual_Editor_-_Implosion_screenshot_for_bugreport.png - it only seems to appear if you have previously resized a different image.
--------------------------
**Version**: unspecified
**Severity**: normal",52651,0,Needs Triage,True
1.984159033111824,-9.361248192406233,-3.0283723724484,-3.9228439179396752,-2.254215884549385,2.862347620781712,4.494580528896749,1.1433799445378776,-0.8109844962557711,2.344310776757408,3.668768061195403,-1.2334198620001626,-0.4753837981434881,1.5549356729599628,1.6807075862120406,-0.7394618775441779,2.716278242007082,0.5014424210246335,False,c1,3,"There are currently two similar, but distinct post-edit notifications on some Wikimedia wikis. I'll attach screenshots from <https://test.wikipedia.org> momentarily.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",52642,0,Needs Triage,True
-2.9952091204142626,-8.030705280114088,2.3348668525867957,1.2317840411459886,-5.428225297447298,4.292355448006081,5.1251237603063435,0.5709816928552625,-0.07686743207486321,2.1393496785965613,1.7871867313531076,3.107995690561726,-0.3275560456265776,-0.44264351913114197,1.3893133218814322,0.18908465237681282,0.5707566616001596,-0.4148575038807234,False,c1,3,"There seem to be several dirty ref sections in this diff:
https://en.wikipedia.org/w/index.php?title=God_of_War_%28series%29&diff=prev&oldid=562631132
--------------------------
**Version**: unspecified
**Severity**: normal",52637,0,Needs Triage,True
1.586184912510229,-5.16656552362727,-3.2434927290721234,-1.5235431838781701,-2.533936278123924,-2.71359469089582,-7.815403798623936,0.43856555528919694,-1.8645703835819598,2.7873335443982086,-0.8052116830592606,2.6332123146439264,-0.4844489227624136,0.433691388470403,0.7781490367744057,-1.2161359268182548,1.0912530111667162,-1.458998806496618,True,c1,3,"To reproduce
1. Click puzzle piece
2. Type cn ([[Template:cn]] redirecting to [[Template:Citation needed]])
3. Press enter twice.
(I was experimenting see if there is a quick way to get out of the template dialog; this would be useful for templates like Template:cn that are commonly added without parameters).
4. Type 'foo'
5. Click 'Apply changes'
6. It shows 'Template:Fooifsubst'
7. Code is generated as '{{Cn| = foo}'
--------------------------
**Version**: unspecified
**Severity**: normal",52627,0,Needs Triage,False
1.5075058345650771,-4.365164759247545,-2.686887128862578,-2.0405296929789376,1.181191935803028,1.381989786665933,-5.130316994909716,3.086270150245221,1.3311260935374711,-1.4509145903170073,1.597609180822817,1.7133555768348236,1.4712020639413468,-0.07590457591335209,-0.7724901039706653,-0.22758339527828153,1.2139899064234065,0.8840185448893421,False,c1,3,"**Author:** `wikipedia`
**Description:**
To reproduce:
1. http://en.wikipedia.org/wiki/High_Speed_2?veaction=edit&vesection=6
2. Wait, hopefully the VisualEditor loads, and does not hang
3. Click ""BETA""
4. Click Leave.
5. Try to type in this dialogue box
What happens:
6. The window scrolls around with each and every keypress.
7. The Leave BETA dialogue is very hard to complete.
What should happen:
6. The window should not scroll
7. The process of leaving should be easy and reliable.
--------------------------
**Version**: unspecified
**Severity**: normal",52602,0,Needs Triage,True
-0.9816755736910285,-1.368856050886011,-6.114815246724628,-7.630196814262154,2.3318613988185484,2.184166848431782,0.7463841508833813,-4.006879763511137,-3.0727885269259403,-1.5670922507802585,-0.6897396064753067,-0.4638000919031052,0.19212081803517833,0.6802025866519106,-2.063006551537121,1.4845860510627524,-0.49067708555809864,2.4186926684349173,False,c1,3,"When editing a section with VisualEditor the page loads and saves just fine. However, if you next edit a different section *without refreshing the page*, VisualEditor does not recognize the version of the page you just saved as what you are editing and loads the last revision and warns you that you are editing an old revision. This occurs in Chrome and Firefox using Windows 7 as I've tested it.
From https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Editing_section_results_in_dirty_page_cache_--_have_to_reload_page_before_doing_additional_edits
--------------------------
**Version**: unspecified
**Severity**: normal",52596,0,Needs Triage,True
-6.003395056309685,2.424524702225277,1.0132324553886676,0.5024284149252884,-0.29372954868859025,4.769758718942145,3.712423604544484,-0.3397060356019674,-1.81579653039288,1.1469588651417046,1.715368347670292,-0.13629364862899784,0.1821473213750071,-0.006530055511301924,-1.327236330588855,-1.2399115141930153,-0.6962205913591025,1.9656007885722937,True,c1,3,"Not sure if this is possible, but a user raises concerns about the behavior of VE opening the whole page for editing instead of editing specific sections, given that it increases the load time.
See:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562566677#edit_one_section_only
--------------------------
**Version**: unspecified
**Severity**: normal",52592,0,Needs Triage,True
-5.613886579555356,3.0875150745878805,-3.169236718669591,-3.5040722538262035,1.6928877461821363,4.234996672867,3.2727633941695276,0.8836582094333499,-4.43333400267029,0.4360951147960934,0.07192288159341631,0.03717364648304211,0.3767779102346105,2.775932973745326,0.8728801464347873,-1.3220454596934041,1.8505791601294705,0.3952304859100526,False,c1,3,"Similar to bugs 50093 and 50527; users need to be warned when they're using markup in the VE. This is a source of a pretty large amount of corruption on enwiki, and I'm not sure how sustainable the community's patience for that is.
--------------------------
**Version**: unspecified
**Severity**: normal",52581,0,Needs Triage,True
8.598523880075305,-2.15268084304331,5.455598348274815,4.660322204183309,-0.5148474417501283,1.6506510926569973,0.41376003828035035,-1.5951680647342736,0.9520308426457282,-1.0064091702376596,-0.7351565687817718,-0.3942981065276463,0.33652679654428796,-1.296168273250593,-2.037562116019364,0.7726418666058199,-1.012283497516591,-0.2627335803446986,False,c1,3,"**Author:** `warnckew`
**Description:**
Screenshot showing infobox DIV HTML code
Launching VisualEditor to edit http://en.wikipedia.org/w/index.php?title=United_Nations_Security_Council_Resolution_1693&oldid=541044487 makes the heading of the infobox show some unexpected HTML contents, as shown in the attached browser screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11621}",52567,0,Needs Triage,True
2.421703670334082,-5.80207395510377,0.4272634334556784,2.1730671512461126,2.3969361441356063,0.14237941428468814,-0.8578822613593715,-0.9346386793753829,0.09758336253193184,-1.6746099442967775,0.04541093962096365,-1.6782040765678916,2.967486022558341,-1.57492696921266,-1.001329422022864,-1.0194688535016625,-1.2496636054572752,-0.8333090275997135,False,c1,3,"I have noticed an unexpected behavior while tesing Visual Editor with Malayalam Wikipedia. Describing the steps below:-
1. Added the following text on a page
ഡിസ്രയേലി
2. When pressing a backspace immediately after the above text, it becomes
ഡസരയ
ie. many characters in between the original text disappeared. The expected result was ഡിസ്രയേ
--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50507",52566,0,Needs Triage,True
-4.226446630463347,-0.358121282786799,2.0292048657320585,6.142167066849689,3.276853653318095,5.200523044891869,0.7272289749328538,-1.6228451669053063,3.911962222409616,1.8894748934094396,2.7195691356245697,0.6039428805944855,1.0323748631473966,0.9834442575831845,-2.009925165094602,-0.9027689649513648,-0.5632928656393028,0.1272764046648176,False,c1,3,"Steps to reproduce:
* edit a page with VE; save
* edit the same page with VE
Expected result: normal editing, no warning
Actual result: there's a warning telling the user they're editing an old version of the page
--------------------------
**Version**: unspecified
**Severity**: normal",52555,0,Needs Triage,True
1.0601829472784803,-0.321157988420687,6.910523439129811,3.6855069828382003,-2.328938025334338,0.10771593425520609,3.216465203893349,-2.056978069449899,-0.0159552818233073,-0.3340900894862324,-0.02505715406220732,-0.6428890010601808,-0.02135552647113048,1.31668787829721,-0.15831999070655467,1.8991349686670493,1.4693248220810935,1.8883503348654538,False,c1,3,"See http://en.wikipedia.org/w/index.php?title=Michala_Petri&diff=562483360&oldid=562482770
It looks like VE inserted categories and default sort at some random place in the DOM, potentially cutting encapsulated transclusion content in two?
The Parsoid template encapsulation and round-tripping for this page looks fine:
http://parsoid.wmflabs.org/_rt/en/Michala_Petri?oldid=562482770
--------------------------
**Version**: unspecified
**Severity**: normal",52554,0,Needs Triage,True
-8.061903427347527,5.440867952760854,0.9759837349177296,0.401556817265889,2.6908119939097266,1.937922556077756,0.045627114795690815,-0.7697906438029309,-1.884223158594266,-0.9148456200737689,-0.5363075620779125,-1.8469717336324036,1.2376365630826576,1.3746078198402554,-1.0180295416264897,0.02138559309915644,1.5527038939513378,1.6782505235410794,True,c1,3,"I've observed this myself:
Clicking ""Page settings"", or the reference, image, and category buttons in the top right brings up a dialogue box for input. To close this box there is an X in the top right. However, when I am not at the top of the page, this dialogue box pops up beneath the standard editing options. This makes it impossible to close the box without adjusting the screen magnification.
In addition, the opening of these boxes freezes scrolling of the underlying page, which not only furthers the problem above, but is also simply annoying and unnecessary, as I can no longer move to another part of the article I wish to see without closing and reopening the box. Reywas92Talk 03:00, 2 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: normal",52553,0,Needs Triage,True
2.137351431552722,-3.7170801992508054,1.1831739624212005,-0.39044831244182354,-3.97543515184652,7.050702534076293,2.930393077138471,-0.6423463720896628,-2.2242091246877065,0.6091851360603879,0.35793699945057433,-0.5593057418531401,-0.1917023391306758,-1.7347989721604016,0.6581691419450086,0.733552973304733,2.019568905405989,-0.1876743716963316,False,c1,3,"This edit was flagged by VE as DOM-differing, and looks like a dirty ref/transclusion:
https://en.wikipedia.org/w/index.php?title=Abolitionism&curid=38894&diff=562492192&oldid=560500423
--------------------------
**Version**: unspecified
**Severity**: normal",52550,0,Needs Triage,False
-3.844398177434455,3.5058675401292945,-2.5030387230221702,-6.578037872655334,1.137167910279566,-3.300782137035073,1.713646522634396,0.5252870844013238,-3.7614495274403774,-2.24042218205679,-1.3485786462217815,-4.183090408004532,0.5662492694641683,1.6630811609431033,-2.2895862815808696,-1.6129409268851127,-0.7695859668010551,1.5218630634811363,False,c1,3,"**Author:** `Shirudo`
**Description:**
While filling out the feedback form, the form jumps down the screen with every keystroke, until it's mostly out of view. Once there, only the current line that I'm typing in is visible right above the edge, and every few keystrokes (seemingly randomly) make the entire screen jerk up and down quickly. If I scroll down or drag the form back up so that it's centred again, it just jumps back down once I begin typing again.
If it makes a difference, I'm using Firefox 22 on Fedora 18, with Gnome 3 Fallback.
--------------------------
**Version**: unspecified
**Severity**: normal",52538,0,Needs Triage,True
1.2264669250632534,-2.5184063464649373,-4.4709375963594145,-2.3549876604713673,0.11490932790295594,0.900539401776981,-3.1774050619881007,0.6050441733226802,3.3166138703051926,-2.171556367642915,-0.2225557790247823,1.8242074930636794,0.4121227427382155,-1.0989124693978098,-1.676037795325934,-0.5479619621463062,-1.525837813673804,0.723638904398072,False,c1,3,"Enter a wiki with VE and ULS. (Enable ULS in preferences if needed.)
Start editing a page using VE. Press the headings style dropdown.
Observed: IME selector appears near the dropdown.
Expected: IME selector must not appear. It's not a place for writing things.
Background: there's an <input> element hiding there to capture click events (according to Roan).
https://gerrit.wikimedia.org/r/#/c/68339/ may be able to fix it (though some modifications may be needed).
--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: ve",52529,0,Needs Triage,True
-2.7729560709107255,1.060129327947406,-2.855328618423462,0.18478375423000748,-0.5808038288100171,-1.4692903371069925,-0.6005767543676157,-1.0309876156589644,0.20710284399662593,-0.7049333765570127,0.26989310852306536,0.3794511784169301,-0.07113023781122774,-1.1319081640064388,-1.5169138010371706,-0.08344204861095583,-0.27336964162630517,-0.8746315760945216,False,c1,3,"I note that if an editor uses old markup in VE (like [[link]]), it gets enclosed in <nowiki> tags
Could we have an additional tag added to the Edit summary, (similar to the Visual Editor tag we have?) which states somethine like ""Old wiki markup""
That way, we can keep track of, and rectify all the cases where the old wiki markup is used while using VE, and remedy it rather than clutter dozens of article with nowiki tags which might not be removed for days
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49820",52527,0,Needs Triage,True
-0.04661519254989299,-2.6059130257547967,-2.9583176985285835,-4.307696536108833,3.022855668912285,0.761313652188492,4.478554851292466,-1.0650096979168184,-0.33735411111610136,1.6732756880742858,2.7320029068224483,-0.7526601658622436,0.482570088322972,-0.29120054933197714,-0.5060571765006632,-0.8591985381192513,1.180762723053414,0.6371195016515088,True,c1,3,"http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#.22Submit.22_button_doesn.27t_show_up
Epicgenius reports the buttons not showing up, I have his same config and was not able to reproduce the issue.
--------------------------
**Version**: unspecified
**Severity**: normal",52524,0,Needs Triage,True
0.6973506725962371,3.928038439390253,0.3478786872745019,-3.8262504978979406,-1.6865876421803416,0.5503597425511544,-0.16682796512686604,-4.756302379745829,-3.270730201311994,-1.0083040954517166,2.708307024698733,-1.5748535691525714,1.7213090751730622,-0.895354650562445,0.7361337018457288,0.785954584281964,-0.18714438716921555,-0.6793714973572065,True,c1,3,"Pamd reports:
If I open [[Queen Anne Grammar School]] in VE, I can see two superscripts linking to references - and 29 references in the reflist. Some of them perhaps most, are the refs which were deleted in a [http://en.wikipedia.org/w/index.php?title=Queen_Anne_Grammar_School&diff=562382386&oldid=562381869 series of edits] 9 hours ago while the article was being moved from AFC to mainspace. If I open it in Edit Source, it's a respectable little stub with two refs and no sign of the other stuff.
Full report at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE_picking_up_old_version_of_file.3F_-_27_ghost_references.21 .
It does the same for me (Vector on Chrome).
--------------------------
**Version**: unspecified
**Severity**: normal",52521,0,Needs Triage,False
-7.923693999235459,-3.561815835298786,-4.928783413503483,-0.565887788388279,5.854829266156408,-1.690468940349298,3.682209160774657,5.420882635399604,-1.5198605327428871,-0.7686135843919502,-1.0571276232162372,-2.015668882530071,-0.835967256585703,-1.3298530681999519,0.5832616624281686,-1.8172858132481484,0.5061778938190544,-0.43123027529065316,False,c1,3,"When marking all content on a page, and hit «delete», then, while the content is removed, also the input marker is removed, so you can't input anything new directly.
--------------------------
**Version**: unspecified
**Severity**: normal",52519,0,Needs Triage,True
1.3711154735991422,-3.7885152502764523,-1.0581054917105348,-0.2753970878874913,0.1312899950238552,-0.1930960896508226,-1.862214839585751,0.8235031871779904,2.3504865507340282,-1.6999666612576996,-0.12939431554836744,-0.8618908050110721,0.7589065223209923,-1.0872022941040864,-2.456272909576417,-0.8924415530682122,-0.7506411110489283,-0.4711858301068803,False,c1,3,"**Author:** `harshanh1979`
**Description:**
I have tested VisualEditor at ml.wikipedia at the following page
https://ml.wikipedia.org/wiki/%E0%B4%AC%E0%B5%BC%E0%B4%A4%E0%B5%8D%E0%B4%A4%E0%B4%B2%E0%B5%8B%E0%B4%AE%E0%B4%BF%E0%B4%AF%E0%B5%8B_%E0%B4%A1%E0%B4%AF%E0%B4%B8%E0%B5%8D
I tried to correct the text ൻറെ to ന്റെ. But the editor doesnt allow to input the characters ് െ etc. Unwanted changes happens somewhere else in the paragraph while trying to input the above mentioned characters.
--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Linux
**Platform**: PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50566",52507,0,Needs Triage,True
1.819841485542026,-7.866577739835316,0.9182944780550919,-2.1017693307563934,-0.03580980890716989,-0.32195923733586496,-0.6054897049635546,2.542244994067038,-0.13788616207477747,-1.2770235128885248,-2.1322388420789444,-0.17621571039814565,0.4396738127871247,-1.0756559012504412,-2.2309707829187544,-0.39283680568119284,0.93870314223563,-2.4379197274964675,False,c1,2,"Screenshot
See screenshot, from https://en.wikipedia.org/wiki/Jitter_%28disambiguation%29?veaction=edit - that line near the top shouldn't be there.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11385}",52468,-1,Needs Triage,False
8.868142157923936,-10.221576623073574,2.7880062089502466,-2.074073701872677,-2.883959655008277,2.023592689968009,-0.001513331225056369,-0.2472278936290665,2.128595642269782,-0.20829318951818898,-0.23611548358685264,0.41513773366096873,0.8936118229631282,-0.9601405193577626,-1.8977775540634272,0.14192470809588217,-0.3928666358153037,-1.2802237290805452,False,c1,2,"Screenshot
See screenshot - from https://en.wikipedia.org/wiki/Iphigenia?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11382}",52467,-1,Needs Triage,False
-2.216259591590627,3.4912488404172493,-1.5935989686640273,-7.193160514732568,1.7410231208740097,0.16182485292840232,-0.8560727611761081,-4.109235455397704,2.7965906812038437,2.802472165911662,1.6247599859287916,-1.3451313687785431,0.4821413838698021,0.20191968651977366,-0.39403349700984514,3.185738013959801,-0.36951865755146596,1.8007505244306705,False,c1,2,"If I open the VisualEditor and add a link to say, ""Edward Coke (politician)"" in my sandbox, and then right click on the link and open it in a new tab, it takes me to https://en.wikipedia.org/wiki/User:Okeyes_%28WMF%29/Edward_Coke_%28politician%29
This seems somewhat suboptimal.
--------------------------
**Version**: unspecified
**Severity**: normal",52466,-1,Needs Triage,True
-7.035823212720928,0.12670503710019787,0.16000823581906687,-0.6912419185362957,2.569659084581729,-1.3177469811667093,0.6536232039106435,-1.855440702593858,3.463902504018903,-1.3356960725143265,-0.19497316603991655,0.6312754434100731,0.04425920547476636,-1.057901255838273,-0.889438282429559,-2.8260028553051257,-0.327158555182977,5.080384320931371,False,c1,2,"We have users reporting errors when trying to save on https://en.wikipedia.org/wiki/Colorado_14ers - can someone take a look at the log and work out what's happening? They were only adding text and a reference.
--------------------------
**Version**: unspecified
**Severity**: normal",52463,-1,Needs Triage,False
-1.5010204729536991,2.1014517342643124,1.8825290767398322,-2.4706159320259617,6.2076275727054355,-2.791947260632433,1.126241709405659,-0.8237787822387785,-0.46415520700888196,0.3387561194817712,1.6024042816725763,-0.49163241470007624,2.4766946583425913,1.8090038142726845,0.8905860955589313,-0.45626036990566354,-1.216804594947846,0.17393706783245588,True,c1,2,"Can something - perhaps a faint background color or an outline - be added to make clear when one is in editing mode?
Copied from http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Make_editing_view_more_distinctive_from_article
I like the visual editor, and I predict that more people will edit WP when it's introduced. However, there is one thing that bugs me: After I clicked the ""Edit"" Tab, the view of the article does change only slightly - so sometimes I do not know that I am already editing, especially when I scroll down the article. I'd suggest a visual hint: A modal popup, a slim outline of the editing area or a more distinctive design of the tool bar, for example. Mateng (talk) 12:00, 30 June 2013 (UTC)
Hear, hear! Perhaps a (faint) background colour? There needs to be some visual clue. JohnCD (talk) 12:17, 30 June 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: normal",52456,-1,Needs Triage,True
5.14863929100558,-7.766398084912486,-4.846926730933175,-6.2123963863188445,1.5588925552803885,-2.107482791215105,-0.23547361545724677,-0.9154110339704393,3.164998832030788,-1.4273801826400203,0.0070936368029523855,-1.112180702197013,1.4356617285831388,-3.436377585288885,-0.28906387585530346,0.35984098179871876,1.5265148835361246,1.8144751236414078,False,c1,2,"screenshot
It was working fine previously. I can reproduce this on both fr.wp and en.wp. See screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11359}",52455,-1,Needs Triage,True
-5.644172415211734,0.7894114642652692,-1.8672976633987304,-0.931646340366664,5.805972231402514,0.2627439298574392,0.14299640273218284,-5.346278641350587,1.0004788583229784,-0.41962005216170084,4.3268755939851555,-5.914399593269725,-0.41465577644601126,-1.2833396973190148,2.5137006785198244,-0.2993491253050876,0.2357795354900949,-1.6383147100173834,True,c1,2,"I twice got the error alert box when saving. However, it turns out that it did save both times. The first time, it did the intended edit (https://en.wikipedia.org/w/index.php?title=Participants_in_World_War_II&diff=562174851&oldid=561500927). The second time, it did a dirty diff for a pipe character (| -> <nowiki>|</nowiki>) in a section of the page I didn't edit.
--------------------------
**Version**: unspecified
**Severity**: normal",52437,-1,Needs Triage,False
0.9806178876900788,2.3796277284510836,0.33124149924487867,0.027900598013041567,0.2822438291407603,-0.899017647098728,-0.7654613337125973,4.409759360955712,-0.5845864426141892,-0.32683260856650875,2.5477820588362197,-0.08155603685155755,-0.9534478103178516,2.233916492073787,-0.7357945334396634,-0.44010919079761346,-0.5891247947677186,-0.5599285009557353,False,c1,2,"The following HTML does not seem to properly round-trip through VE:
<p><a rel=""mw:WikiLink"" href=""././Foo"">./Foo</a></p>
While the ././ prefix is not ideal (see Parsoid bug 50426) VE should still preserve the href on unmodified content. Instead, it seems to prefix another ./, which then results in diffs like this one:
https://en.wikipedia.org/w/index.php?title=DreamWorks_Animation&curid=1509817&diff=562129988&oldid=562129729
--------------------------
**Version**: unspecified
**Severity**: normal",52428,-1,Needs Triage,True
-1.4177423992341112,2.9810152074965472,-2.7589218053575557,-4.356181166091415,-0.043327018606972745,0.7950776825168351,-2.2308375811325667,0.37716829238360394,0.5818100614139283,0.39831738723357457,-2.1077414151291345,-0.2846268974410572,0.6260645172411761,0.8409573452609447,0.27815776311045415,-0.8251723310254895,0.7937362873796541,-0.3462002610472845,True,c1,2,"Taken from VisualEditor feedback page:
Trying when editing articles to think ""Could I use VE for this?"" I came on an article where the {{AfD}} template had been removed and needed to be restored. The easiest way to get that right is to call up from the history a version with the template in place, and copy it from there to the current version. This doesn't seem possible in VE: after selecting the template so that it is highlighted, Ctrl-C doesn't copy it, and right-click doesn't offer a ""Copy"" option. JohnCD (talk) 21:29, 28 June 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: normal",52421,-1,Needs Triage,True
-7.882124380275069,1.2680945609929353,-2.029890341652564,3.5826718070045818,2.518898761832994,2.889386453299223,-0.3081217039326605,0.14810491666396508,-0.3332984432917548,-0.7969041963837018,0.6310833528214066,2.1887846265322466,2.229699398488285,-1.9347637188933882,-1.593430267416374,0.29162612057816945,0.5979084668249366,0.37673145478262327,False,c1,2,"If a header line is preceded by an empty line, and one tries to remove that empty line by placing the cursor at the beginning of the header line and hitting Delete, the empty line is removed as expected, but the header line turns into Paragraph formatting, which is unexpected and incorrect.
Note that the behavior is correct if the line preceding the header line is *not* empty: in that case we want to merge the header line with the previous line, and the header formatting should be removed.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50995",52418,-1,Needs Triage,False
6.837240769709373,1.3796901499065033,-5.929574292267365,1.1266302613344643,-8.996105896478449,0.7341491297371892,-3.457246187387237,0.09452062062073097,-3.1603639849654606,-3.5049137859368464,0.8935971293384015,-2.678325194532282,2.7059643750858755,1.3000117311786274,2.062144346874491,1.5225885416688012,0.13668693560672396,-1.007358320029774,False,c1,2,"Would you believe that.
[6/29/2013 1:44:17 PM] JavaScript - https://pl.wikipedia.org/wiki/Gródek_(obwód_lwowski)?veaction=edit
Event thread: readystatechange
Uncaught exception: Error: WRONG_ARGUMENTS_ERRError thrown at line 39, column 4 in <anonymous function: ve.copyDomElements>(domElement) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.visibleText%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130629T021004Z&*:
return doc ? doc.importNode(domElement, true) : domElement.cloneNode(true);
called from line 38, column 3 in <anonymous function: ve.copyDomElements>(domElements, doc) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.visibleText%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130629T021004Z&*:
return domElements.map(function(domElement) {
called from line 9721, column 3 in <anonymous function: ve.ce.GeneratedContentNode.prototype.onUpdate>() in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
this.$.empty().append(ve.copyDomElements(store.value(index), doc));
called from line 9711, column 2 in VeCeGeneratedContentNode() in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
this.onUpdate();
called via Function.prototype.call() from line 10325, column 2 in VeCeMWTransclusionNode(model, config) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
ve.ce.GeneratedContentNode.call(this);
called via Function.prototype.call() from line 10366, column 2 in VeCeMWTransclusionBlockNode(model) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
ve.ce.MWTransclusionNode.call(this, model);
called via Function.prototype.apply() from line 50, column 2 in <anonymous function: ve.Factory.prototype.create>(name) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
constructor.apply(obj, args);
called from line 8132, column 4 in <anonymous function: ve.ce.BranchNode.prototype.onSplice>(index) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
args[i] = ve.ce.nodeFactory.create(args[i].getType(), args[i]);
called via Function.prototype.apply() from line 8089, column 2 in VeCeBranchNode(model, config) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
this.onSplice.apply(this, [0, 0].concat(model.getChildren()));
called via Function.prototype.call() from line 9824, column 2 in VeCeDocumentNode(model, surface, config) in https://bits.wikimedia.org/pl.wikipedia.org/load.php?debug=false&lang=pl&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130629T021004Z&*:
ve.ce.BranchNode.call(this, model, config);
At this point `store.value(index)` is [undefined, undefined] on Opera, but [<span...>, <dl...>] on Firefox. Since `index` is not undefined, this would indicate some sort of an internal inconsistency.
--------------------------
**Version**: unspecified
**Severity**: normal",52417,-1,Needs Triage,True
1.976070783206597,2.3235927842948456,-1.449456543813529,0.28031942857323866,0.5305290965029252,4.544074154029922,-2.1005411664449025,-2.0553688298945443,-0.9888559100299755,-1.7497971502523253,0.23150574033867377,-2.204713635207192,3.956593789560799,0.617414033984721,0.2456119522655209,-1.154800944457521,-0.030696338937252543,0.7357035018157194,True,c1,2,"If an infobox contains an image that is wider than the infobox's natural size, then editing the page cause the infobox to expand, without properly wrapping the adjacent text. The result is that the infobox covers up the adjacent text.
See http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Text_appearing_behind_infobox_.2F_behaviour_after_editing on 28 June 2013 for the initial report. The report came from a user running Chrome (version 27.0.1453.116) on Windows XP; I confirmed it in the en.wp article on Southampton using Safari 6.0.5 (7536.30.1) and Firefox 22.0 on Mac OS 10.7.5.
--------------------------
**Version**: unspecified
**Severity**: normal",52416,-1,Needs Triage,True
8.272839227709232,-12.752219395092743,-4.398333018763868,-1.7785143232478136,0.18441183294746477,1.8220806164835912,0.9964234319468224,-0.9216946433528639,-3.976365266070327,-1.5873341865652582,-0.16547887780913673,2.340213407326396,3.9613097292992605,5.021907813445871,-0.5144533743854787,0.05559998738101124,-0.1485080874521787,0.6113017936266874,False,c1,2,"https://en.wikipedia.org/wiki/Birbal has 3 references; https://en.wikipedia.org/wiki/Birbal?veaction=edit has 24.
--------------------------
**Version**: unspecified
**Severity**: normal",52380,-1,Needs Triage,False
-6.164345011217156,-1.2116734057498846,-1.7373592111742528,-1.1487743196301183,-1.4916219743253751,-0.1886091707924794,3.7362839125886653,-2.2768998712157367,-1.23416534636487,1.9704907620526022,3.0573040249809282,3.736751806929015,1.9420609440823742,1.1647872754120838,-1.8849619769958688,-0.4943579230249645,-0.45714649733199453,-1.996834708417532,False,c1,2,"screenshot
I'm not sure if this is bug 49514 ; feel free to dupe if it is.
See attached screenshot: the toolbar appears on top of the save dialog, which makes it difficult or impossible to save changes.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11157}",52364,-1,Needs Triage,True
1.1921740081523962,-5.9541486033488145,3.935775932369644,1.1905105448506985,-0.17229271826545534,3.7232015726557846,-0.9873693283239389,-1.3341190139494126,0.4597361644552934,-1.2177045421383301,-0.8164484934626892,-0.32293828825184556,0.7128709284540604,-0.8016063639708149,-2.551140452183175,0.6930567485027463,-0.6180224676984348,-0.4300337935030867,False,c1,2,"Screenshot
Try modifying the infobox in https://en.wikipedia.org/wiki/Defiance_%28TV_series%29?veaction=edit for example - see the screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11137}",52361,-1,Needs Triage,True
-8.725358776814383,-0.9712100596543944,-2.8826520734183116,-0.6403785752121198,-8.159734807705034,1.3276485129115938,2.754447510542229,1.4687014019100513,5.644189038094637,1.7205277492418443,1.5352143375543021,2.7845806932590618,0.5771047272757817,-0.0046926853041338035,-0.24078341960515637,-0.000831686309381019,1.9329530100313208,3.7569148682803286,False,c1,2,"Users expect to be able to select, drag and drop most elements of the page, including snippets of text, templates & other transclusions, and references, just like they can do with images.
--------------------------
**Version**: unspecified
**Severity**: normal",52359,-1,Needs Triage,True
-4.261482895327398,1.6697075488054587,-3.8383178175911894,-0.39210963746565863,-3.5503541737476123,0.8273129132329302,-2.792709134475049,1.7148871623608648,-0.9426803367198799,-1.3274781692741047,3.789197345755617,0.13475952799459368,-0.5482213886994103,-0.3001217331567334,-1.3853288819310094,-0.2294215653155126,0.022563914595640888,-0.6637495053598663,False,c1,2,"It is usual to use [square brackets], [...] inside quotes to cut or complete sentences in quotes. As for today, VisualEditor will add <nowiki> tags like this:
<nowiki>[Square brackets]</nowiki>
<nowiki>[...]</nowiki>
This is not a big deal since the users will keep seeing the same in the published article, but it adds unnecessary cruft in edit source mode and it's wrong.
Also, according to Bug 47678 this means that editors won't be able to edit the content inside those brackets with VisualEditor, because of the <nowiki> tags.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T54268}",52331,-1,Needs Triage,True
1.2702402686201153,-16.83788922696343,-2.0282724230945117,-2.2528002817291704,-0.9184150190807964,3.6318469286844737,4.844310556497061,2.1898417141021596,-0.3434407818443341,1.7949039441062924,1.9556733005279,-2.8087921745143873,0.2556965001145146,-0.5959855676344832,-0.43108939413410763,-0.834110867629493,-0.4447462940052894,-0.11190144748182607,False,c1,2,"Fairly self-explanatory.
--------------------------
**Version**: unspecified
**Severity**: normal",52313,-1,Needs Triage,True
-9.077875477160312,0.8822832401161413,-1.428315118676304,1.528912753201265,1.5524485632618026,-0.8911380284343867,0.32626189997164623,-1.9383671524013488,0.5032006443138872,3.795576682472687,-0.8981825851223189,0.7833818485167898,-1.1608818557023195,2.401781355055064,-1.8456921777190805,-1.3516304433334032,0.31116364313958544,-1.601797614402925,False,c1,2,"The history page of any article has an 'edit' link on it; this currently takes you to source editing, which seems highly likely to confuse users.
--------------------------
**Version**: unspecified
**Severity**: normal",52312,-1,Needs Triage,True
4.917536333042115,5.230310195709123,3.0348465122037247,-6.483280322904218,-0.7134936646620039,1.6402103322977355,-1.3966225240864265,-1.3416469938366413,-4.094203344387323,2.7384043619158636,-1.4927401296788676,0.9716891459950492,-0.08177511404643667,-0.16640235003658344,-2.055443482366117,-1.0104727523168453,0.5536290080392274,-0.5745400894727735,True,c1,2,"This is what Alberobello looks like under VE
When trying to edit http://it.wikipedia.org/wiki/Alberobello (tested with MonoBook on FF and Vector on Chrome) a few ""carriage returns"" appear in the first lines. I'd also add that I spot these in https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet : the line which says ""Test split on multiple lines""? It isn't.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11918}",52295,-1,Needs Triage,True
6.890810434304543,0.07194193296007434,-0.5363952597034771,-4.867552576762156,-0.5174913337953085,-0.32842457825887406,-0.6908164330965585,-1.1689929413577294,-2.0990073724448948,-2.6970280131802413,-1.0831359325579362,0.277733368131617,0.09944821132148451,-1.2685873229622255,-0.4884287464671315,-0.5963558841679316,-1.689787466680475,0.4690170518633423,False,c1,2,"When VisualEditor is enabled there is no option to enable ULS, where I could type in Odia in the search bar using ULS.
When VIsualEditor is enabled there typing is possible only in English. There is no option to change the language using ULS where as it works normally in the search bar. I have tested it for Odia Wikipedia for the article on Colombo: https://or.wikipedia.org/wiki/Colombo on Mac OS X 10.7.5 using browser Firefox 21.0.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11913}",52293,-1,Needs Triage,True
-5.4036060799917705,-3.563308872995835,-2.961934191594036,-6.225642647038595,0.5390892879393754,-5.39185673429664,2.925867232261756,1.9319451105181198,2.7703589008072917,0.8055543850732949,0.5497215213879811,-0.29883473943040295,-0.0963640167784181,0.3915732316578051,-0.8025299048752803,1.939175478116498,1.7562572950302042,1.333519690584956,False,c1,2,"See https://en.wikipedia.org/wiki/Mitochondrial_DNA?veaction=edit - the links appear, via source editing, to be perfectly normal, and yet you can't interact with them and they display oddly.
--------------------------
**Version**: unspecified
**Severity**: normal",52290,-1,Needs Triage,True
-5.455015585540941,0.9888663034952181,-6.6165828828171325,-2.1044549039280906,-2.7196629787568893,0.9210487453279577,-0.6750821748420188,-1.0281277772040385,-1.1172474311133853,-1.5063539985251495,1.3507026006669922,2.0838175373733483,2.46603288921571,1.4684150568664451,-0.12434477845184944,-1.1556147357316855,-0.5038044132982714,0.6959810676530356,False,c1,2,"Fairly self-explanatory. The reason this is important; being able to copy references across is crucial when using multiple references from one source item. If I have a book by Jones, from 2003, and I have a reference that reads <ref>Jones (2003) p.23</ref> for one statement, and want to cite page 57 for another, it's a lot easier to change the page number than it is to type everything out again.
--------------------------
**Version**: unspecified
**Severity**: normal",52283,-1,Needs Triage,True
-2.335505064058879,-0.44117434917543363,-0.7533656730645504,5.35261641590831,4.556921961126296,0.176634711020073,-0.9378735848679423,-3.188042468544961,-0.6478964423348834,-2.9274959966996357,2.35593938487353,-2.616312073350594,-4.701487246974774,1.1580730073681913,-0.6465514515414705,1.1709616653969794,-2.1260153210128934,1.1217602005529173,False,c1,2,"When you add a category to a page using the page settings dialog, it gets added as a wikilink [[:Category:xyz]], not a category inclusion [[Category:xyz]].
Seen on testwiki and enwiki.
--------------------------
**Version**: unspecified
**Severity**: normal",52278,-1,Needs Triage,True
-3.0619395847899757,-3.181090046562966,4.470964845948227,5.082406094853472,0.4935231921216503,-0.15358881814121628,-0.835336944394327,0.9749820525158178,1.849823686841112,-1.791009474628793,-0.7749787988070698,-0.6589216020758533,2.4084751573615932,0.5747472518808445,-0.21556951290877002,-0.2944217777868049,0.07052187744832006,-1.600446136910873,False,c1,2,"Screenshot of bug
When scrolled down the page, the top of the save dialog is obscured by the toolbar. See screenshot.
See also other z-index bugs: bug 49514 and bug 49275.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11882}",52276,-1,Needs Triage,True
-1.4184858677301215,-7.800820031482381,1.6276407023301225,-0.49907204291693497,-4.466989604108688,2.028463611908748,-1.015941039991226,1.278953474919219,2.6779122581927837,-1.2230716596674012,-0.6910979105427937,3.1397443987391105,2.622505769841324,-0.45122406538364324,1.6268096098382712,-0.24499865342206062,0.9313655133161489,-2.045554192984458,False,c1,2,"See https://en.wikipedia.org/wiki/Microorganism?veaction=edit#See_also for example; that should be divided into 3 columns.
--------------------------
**Version**: unspecified
**Severity**: normal",52267,-1,Needs Triage,True
0.18158721910101683,-6.590844402241824,4.7604239809003595,2.037257801689564,-3.0210007077949235,3.4028868314586527,2.570477031126736,-0.15181364379405876,1.3885295292511577,-1.2203122909669397,-2.171428416608044,-0.836144405456784,-2.1199868907776223,-0.8133432814856789,2.1892656345279917,0.35210249112889597,0.3086251261223456,-1.407799660087376,True,c1,2,"In this edit:https://en.wikipedia.org/w/index.php?title=Blepsias_cirrhosus&diff=next&oldid=561719692
Bold/italic formatting was removed by an unrelated action (addition of text). See editor's description here:http://en.wikipedia.org/wiki/User_talk:PBASH607#VE_issues.3F
--------------------------
**Version**: unspecified
**Severity**: major",52258,-1,Needs Triage,True
1.200737375696613,-6.088435506004744,-4.340311115016062,6.298286134657061,-1.738329544552922,-4.0126120394904845,1.0668130688139925,0.4170644047210721,0.05574876265451606,3.7903330957684087,0.8762769630103837,1.004098420006162,1.9470374099749024,0.12829063931314977,-0.5708044358065383,-0.5532799699370058,-0.03934242106008101,-1.252273324794507,False,c1,2,"When you use 'become' to log into a shared account, ~/.bashrc isn't run.
catrope@tools-login:~$ become visualeditor
local-visualeditor@tools-login:~$ cat ~/.bashrc
# Shortcuts
alias ..='cd ..'
alias ll='ls -ahlF --color=auto'
alias l='ll'
# Environment
export PATH=$HOME/bin:$PATH;
local-visualeditor@tools-login:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
local-visualeditor@tools-login:~$ . ~/.bashrc
local-visualeditor@tools-login:~$ echo $PATH
/data/project/visualeditor/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
Adding $HOME/bin to $PATH would probably be a nice thing to do in general.
--------------------------
**Version**: unspecified
**Severity**: normal",52249,-1,Needs Triage,True
-6.23152651921265,-7.18226453786825,-0.31065829545647894,4.99935835705441,-0.9847343168956808,-8.242664903892967,2.1415662165685836,0.6460991090318297,1.7559751353741666,7.686478763550065,-0.12124456269255246,-1.105589189525736,-0.40080414431095956,-0.41141471689188513,-0.22794479506438137,3.157680983926136,1.6986891362417775,-0.11841308491867397,False,c1,2,"catrope@tools-login:~$ become visualeditor
local-visualeditor@tools-login:~$ screen
Cannot open your terminal '/dev/pts/97' - please check.
However, running screen as myself and then running 'become visualeditor' in each screen window does work.
--------------------------
**Version**: unspecified
**Severity**: normal",52248,-1,Needs Triage,False
-6.903931221674508,-0.2799591649175248,5.799232027409566,9.707269137254215,3.719093828456647,5.468138650331211,0.12216577701991138,-3.365016173818288,0.5194906776269513,-1.302422877302536,-0.688439094358436,-2.022654406066434,-0.14961762517441635,0.22620279186245185,-2.020777388297971,-0.8225133110181477,-0.4252260607051659,-0.8488145604369652,False,c1,2,"Adding a template to a page (say, https://en.wikipedia.org/wiki/Eugene_Lies ) for some reason blocks the opening of the page settings dialogue.
--------------------------
**Version**: unspecified
**Severity**: normal",52242,-1,Needs Triage,True
-6.482779261570929,-2.288661000098287,-4.070108233068403,1.1983117606981253,-0.10558867266150695,-4.498474085935285,0.7607658945169185,1.8876137231976777,-1.586562152834373,-0.9532909800006162,-2.931230916874615,0.19913061251528585,-0.17943315288270067,-0.9376660309898237,-2.786962455069132,0.7976624597133088,3.3183973841576524,1.0535680845929585,False,c1,2,"What ""not working"" means is that templates, links, references and images cannot be interacted with, at all. References and templates don't acknowledge they're there, images bug out, and the link inspector does not appear for links. I've had a group of users test this, and they've all reported wildly inconsistent results; this is happening for some but not for others, with no correlation in OS, browser or even skin.
--------------------------
**Version**: unspecified
**Severity**: major
**Whiteboard**: aklapper-moreinfo",52226,-1,Needs Triage,True
3.6906241014907146,-9.905379887882466,3.1709658693529192,1.705858068328875,-2.650202653848026,-3.937799062471023,-3.925168630198289,2.0138435350139456,-1.0630459574196816,-3.7204909747164985,4.8877653477838425,0.7116060424951631,-7.624994961056276,1.7150785157230422,-0.6826447648122711,-0.38515031628728424,1.1811698050687987,-0.39688768265241303,False,c1,2,"VE rendering of [[WUEC#External_links]] does not match MW rendering.
--------------------------
**Version**: unspecified
**Severity**: minor",52213,-1,Needs Triage,True
-5.1290950277928005,-1.9181626711803403,1.340104652645195,5.359235492201316,0.30602448746944055,2.7569601685863647,0.4507654035244357,-0.6800712948106835,-1.1091458057667662,-0.9861380001912279,-0.24753954014936275,-0.42248169046419604,1.2030452455521465,-1.6855470058563635,-2.894472568625515,-0.0473036822307949,0.7347166824670361,1.4932207819002496,False,c1,2,"screenshot
When floats (like images or templates) are located at the same level as references, the blue rectangle of the references prevents the user from selecting (and editing) the floats. See attached screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11749}",52211,-1,Needs Triage,True
-1.0178764514985081,-3.969764473428965,-0.2639939931725106,0.6409540955949535,-2.332668639398799,1.2143987140600359,-1.2245037343402538,0.47874606500840755,1.0906793215764445,0.1623391096164637,1.1015594415531695,0.9789693740014236,3.242642113600622,-0.7968192565033956,-3.034746335578358,1.2168221757955233,0.14399697139639134,-1.4631521439085313,False,c1,2,"screenshot
Steps to reproduce:
* Click on the heading format drop-down menu. Don't close it.
* Click on the Page settings menu.
Expected result:
* The heading format drop-down is closed before the Page settings dialog shows up.
Actual result:
* The heading format drop-down remains open (and selectable) on top of the Page settings dialog (see attached screenshot).
Observed in Firefox 21.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11748}",52210,-1,Needs Triage,True
5.967980253831136,-16.03669806181045,-4.454969681891852,-5.477708896099274,-1.4237520775361094,4.776649864826013,-3.3000160023155405,2.1036460202214373,-0.5445165521603704,0.873298789888274,9.963256388116957,0.01743849986567647,-2.1986942782099996,-0.8927301082741073,-1.4270313429155639,0.5195081854746587,0.9851808314973345,0.5711190443637901,False,c1,2,"See [[testwiki:VisualEditor:Little or big]].
--------------------------
**Version**: unspecified
**Severity**: normal",52207,-1,Needs Triage,True
-1.4281909965566812,-0.33971909078904083,-4.550747613898334,-0.7429964073695065,-1.5984756176915214,0.5691158472527873,-0.3463433774015918,1.9478329254502342,-1.9255863962574584,-2.9236228736009178,-1.6850118728903827,-0.9231268300881166,2.8017307976052495,-1.3010070212422797,1.3818479748190073,-2.446530665470706,0.1917614386253883,-0.3179695203146917,False,c1,2,"**Author:** `swalling`
**Description:**
Looking at the logs for the latest GettingStarted schema (GettingStartedNavbar_5496876) I am not finding a page-save-success event since June 6th.
This may have something to do with the VisualEditor split test or maybe not. I am seeing very few events (28 total) of any kind being logged on enwiki after 2013-06-20 when logging for the VE split test was enabled. This is obviously wrong, since there were more than 150 revisions tagged as gettingstarted-edit yesterday alone.
--------------------------
**Version**: unspecified
**Severity**: normal",52204,-1,Needs Triage,True
-6.981046346033718,3.8904343113606323,0.9212049458413283,1.616655077801303,5.475946131712114,1.850340409858579,1.6944943337559897,2.0526775176672034,-0.026273357733765212,-0.1536563575041221,0.4172606735144919,0.19380039710526775,-0.26267149810363577,1.6919415503077317,-1.8399886994875336,0.9407183343226064,-0.3544131657106073,-1.4074579264705378,False,c1,2,"Specifically, a lot of JS-dependent things simply don't seem to work. Mostly those are gadgets (no big deal) but on reload, section edit links take you to the source editor. This is probably the most critical; I can imagine a workflow in which a newbie makes a change in the VE, saves, sees something else to tweak, goes to edit...ack! Broken the site!
--------------------------
**Version**: unspecified
**Severity**: normal",52181,-1,Needs Triage,True
-0.21545093672605686,-5.261866390260263,4.268128022953466,2.183718554919135,-0.36574107671794875,-0.8472986581855407,4.999080698349366,-0.7950365930783821,1.3438971787769385,0.08990459760721592,-0.4456616467173449,-2.000949787679451,-2.084799501243796,0.7234059088299256,-0.08456814017682301,-1.9477326981218241,-0.45430325863766285,2.6580210993174243,False,c1,2,"Normally I would rewrite the bug description for bz, but JohnCD has given a very good demonstration on-wiki of strange cursor movements when navigating using arrow keys:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=561499916#Some_funnies
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=561499916#Some_funnies",52168,-1,Needs Triage,True
0.45764317975845836,-5.665767573011188,-5.573821836293222,0.46493754747975014,-0.8559315887424002,-1.5765984900583838,-2.386655793334349,2.567246865849265,-0.9802572305861892,-2.9454734947755172,-0.4929779615023926,1.378916850619641,4.160804095751857,0.5148154106715657,-0.5452498614235619,0.17315707908992337,-0.163144281329326,-0.38343338976514496,True,c1,2,"In general,
{{foo
bar =
* 1
* 2
* 3
}}
… is RT'ing to
{{foo
bar = <nowiki>* 1
* 2
* 3</nowiki>
}}
Examples:
* https://en.wikipedia.org/w/index.php?title=Riddler&diff=561149660&oldid=561096940
* https://en.wikipedia.org/w/index.php?title=Schuylar_Oordt&diff=561438828&oldid=561406705
VisualEditor bug (to prevent dirty-DOMing and so hide this bug on RT) is bug 50070, but this will still occur when users edit the template unless this is recognised as valid.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50070",52147,-1,Needs Triage,True
3.67625076235761,-5.3719835319660625,-5.791242606571425,3.8252119960071456,-5.755882560957799,-1.8034018141970494,-0.6420617605673469,-1.1770113942318612,-0.4212440662028335,-2.0035410404159,-2.05152917621255,-2.2730924875265774,1.627837782191894,0.14134168867082764,0.8300129408394108,-1.102706104466244,0.42689942354733357,0.6486240459387485,True,c1,2,"After modifying site.pp and provisioning, I got:
notice: /Stage[main]/Role::Eventlogging/Mediawiki::Extension[EventLogging]/Git::Clone[mediawiki/extensions/EventLogging]/Exec[git clone mediawiki/extensions/EventLogging]/returns: fatal: unable to access '/root/.config/git/config': Permission denied
resulting in:
err: /Stage[main]/Role::Eventlogging/Mediawiki::Extension[EventLogging]/Git::Clone[mediawiki/extensions/EventLogging]/Exec[git clone mediawiki/extensions/EventLogging]/returns: change from notrun to 0 failed: git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/EventLogging.git /vagrant/mediawiki/extensions/EventLogging returned 128 instead of one of [0] at /tmp/vagrant-puppet/modules-0/git/manifests/clone.pp:40
--------------------------
**Version**: unspecified
**Severity**: normal",52143,-1,Needs Triage,True
-4.07158446508303,0.6187270126810667,-5.611997556431486,0.8224727711158295,-1.7695829367259526,0.8716574878080474,-1.8423862916665872,2.4260302117455907,-2.431085070580469,-2.6393841227987416,0.2908315654517044,1.0651135793800404,0.2688582311898471,-0.22345453962662365,-0.585077335010677,1.4523920847231344,0.9209759203974575,-0.2746373504213555,True,c1,2,"[Not urgent.]
Frameless images are special; the caption is meant to be the alt text, unless alt= is also set, in which case it's ignored - but Parsoid outputs a <figcaption> for images regardless of type (thumb, framed or frameless) - and doesn't output the alt at all, which is bug 45208.
There's a hack in VisualEditor to ignore <figcaption>s for these as part of bug 50113, but Parsoid should fix these in due course.
--------------------------
**Version**: unspecified
**Severity**: minor",52142,-1,Needs Triage,True
2.412128624925366,-16.959765250364036,3.8734178164902353,2.0645510978340043,-2.0320540649073333,3.0306175551290853,5.235389208997927,-1.4391340410100049,0.6232125295312069,1.3830397040905495,0.85978318546299,-0.6635763096340714,-1.1633477032329944,-0.011350188389093852,0.5331305553380874,-0.5160785717085714,0.2982228827735709,-0.05478655315618952,False,c1,2,"https://en.wikipedia.org/w/index.php?title=History_of_Delta_Air_Lines&curid=38607247&diff=561387547&oldid=557734729
--------------------------
**Version**: unspecified
**Severity**: normal",52116,-1,Needs Triage,True
27.878467436767263,2.1016453892760403,7.15254675372767,0.7662895355449777,2.760694952592451,1.7313244108632773,-0.48578329730226866,0.24371114443046227,-0.014700984759207503,-0.9618383093835967,1.6989478703037606,-1.2069159078297538,3.004279588467372,3.838653035866214,4.3845000981745565,-0.8786825964299825,0.05859451146619965,1.3532274246619769,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Laura_Pannack&diff=561375041&oldid=561336738
The change should have only italicized a few publication names. Instead it changed...
* Winner, Magenta Foundation award<ref>{{cite book |last= Pritchard | first= Lisa |authorlink= Lisa Pritchard|title= Setting Up a Successful Photography Business: How to be a Professional Photographer |url= http://books.google.co.uk/books?id=Nn4Zt5SBcswC&pg=PA134&lpg=PA134&dq=laura+pannack++Setting+up+a+Successful+Photography+Business&source=bl&ots=jPQTB9IuYE&sig=7xtX-t9WFQYB76Xo_ZlU06BnIrE&hl=en&sa=X&ei=QehaUZGZCJSa1AWR_oCICw&ved=0CC8Q6AEwAA#v=onepage&q=laura%20pannack%20%20Setting%20up%20a%20Successful%20Photography%20Business&f=false|accessdate= 2 April 2013 |year= |publisher= A & C Black Publishers Ltd|location= London|isbn= 978-1-408125-77-9|page= 134| quote = Laura Pannack ... twice winner of the Magenta Foundation Award}}</ref>
to...
* Winner, Magenta Foundation award<ref>{{cite book |last=Pritchard | first=Lisa |authorlink=Lisa Pritchard|title=Setting Up a Successful Photography Business: How to be a Professional Photographer |url=http://books.google.co.uk/books?id=Nn4Zt5SBcswC&pg=PA134&lpg=PA134&dq=laura+pannack++Setting+up+a+Successful+Photography+Business&source=bl&ots=jPQTB9IuYE&sig=7xtX-t9WFQYB76Xo_ZlU06BnIrE&hl=en&sa=X&ei=QehaUZGZCJSa1AWR_oCICw&ved=0CC8Q6AEwAA#v=onepage&q=laura%20pannack%20%20Setting%20up%20a%20Successful%20Photography%20Business&f=false|accessdate=2 April 2013 |year=|publisher=A & C Black Publishers Ltd|location=London|isbn=978-1-408125-77-9|page=134| quote =Laura Pannack ... twice winner of the Magenta Foundation Award}}</ref>
--------------------------
**Version**: unspecified
**Severity**: normal",52108,-1,Needs Triage,True
8.78393437074719,-12.647242214413396,-7.984224145842878,0.3705938470429233,-1.5525623872768568,0.8579168665531347,-4.744325915347299,-0.2894201929287687,-1.902001025603194,-3.2937579976442457,6.7878244057611905,-1.9101653042721702,-5.267160212968016,-2.3072241946450793,1.0534850628776118,-1.960573047037348,0.9565635870810734,-1.0688240160695925,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Laura_Pannack&diff=561336738&oldid=557984097
<ref name=""telegraph""/> --> <ref name=""telegraph""></ref>
Weird.
--------------------------
**Version**: unspecified
**Severity**: normal",52106,-1,Needs Triage,True
12.90028705437365,-13.00122188602576,3.3939505981237765,0.18476440162701468,-0.8765189196820563,3.204956540749583,3.7733778594493286,-1.2273775089696453,0.5352117472382073,0.9920704799590778,0.5865112212779962,-0.5865078754363107,-0.7743790314460801,-0.506145694109434,0.06370703436448899,-0.38579938848320117,0.18957338088623588,-0.1476320507920632,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Christopher_Walken&curid=167790&diff=561335042&oldid=560573850
https://en.wikipedia.org/w/index.php?title=Complement_fixation_test&diff=561335484&oldid=540954235
https://en.wikipedia.org/w/index.php?title=List_of_first-class_cricket_records&curid=5507023&diff=561342472&oldid=560120426
--------------------------
**Version**: unspecified
**Severity**: normal",52101,-1,Needs Triage,True
6.730168786243491,-4.222479438185529,-0.9879558342605321,-3.50482910069222,4.648402039725589,5.594364265469063,-2.4277778254606193,-4.353169474550142,2.5916983835574783,2.315579775233532,-1.5894439161839142,-0.22107434903550338,-0.7721525200645933,-2.970118397977699,4.1677859889957665,-3.5105355311344604,0.29676839137962574,0.8835600093596294,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Paula_Deen&diff=561368754&oldid=561308417
I did a section edit to link ""Food Network"". This was the resulting diff.
--------------------------
**Version**: unspecified
**Severity**: normal",52099,-1,Needs Triage,True
-1.0814092620736435,-2.2602126129059226,-3.1403871529079534,1.36135088788904,-1.306727858459098,-0.6713407773024258,-1.6096916998693294,-1.8134145983452945,-0.5528714221670897,-0.028202601443213737,0.21011194567042857,-0.6451888925622262,1.160466640876693,-0.5030668555282789,-1.3634367583000744,-1.0040579669159815,0.26714437533279956,-0.19952826017408687,False,c1,2,"Screenshot of bug
The ""review changes"" flyout looks broken and doesn't actually do anything.
There's a script error:
SCRIPT70: Permission denied
load.php, line 18 character 453
With ""format JavaScript"" enabled (a real godsend of IE's dev tools) we see that the error is occurring on the first line of this for statement:
for(i=0,len=oldDoc.head.childNodes.length;
i<len;
i++){
I tried to get a better output using debug=true, but this seems to totally break VE (in IE10 at least).
--------------------------
**Version**: unspecified
**Severity**: critical
**Attached**: {F11482}",52086,-1,Needs Triage,True
1.8872954884906226,-12.409504624530147,4.038514770939706,-1.8264006453161117,-4.719210791060695,3.3143805663861023,1.9232503118027466,-0.0984691624446459,2.897051097818557,0.9218855317775407,0.510185267845046,0.6108086649822304,0.12707573245163228,0.29302917921227056,-1.10860205551052,0.0685953486095347,-0.20158352902850396,-1.2507849160040405,False,c1,2,"See https://en.wikipedia.org/w/index.php?title=Royal_Lancaster_Infirmary&diff=561254127&oldid=560972172 for example.
--------------------------
**Version**: unspecified
**Severity**: normal",52080,-1,Needs Triage,True
-8.417252315971778,0.636612459186729,2.0098073264598497,4.306558553549818,2.8493342602507115,1.6578209596853364,4.631526051008197,-1.014278835318439,-3.77185397265153,1.4992211606649386,1.2664472983316393,-0.3197835795458902,-0.5802059480812973,2.782469217669017,-3.8358250151133637,1.075045796097991,1.3273134677505436,0.8109623152703607,False,c1,2,"If a user hits edit, removes a category and saves, the read-only article they're then presented with still includes the old category - or at least, does on https://en.wikipedia.org/wiki/Sumali
--------------------------
**Version**: unspecified
**Severity**: normal",52072,-1,Needs Triage,True
-1.0917227933145157,-3.6538281565808823,4.215076030007857,3.988439792286388,0.5325220169174294,7.1193067143420725,3.7419564916294688,0.05608717283319031,-0.5725940866939466,1.1385671517814133,1.3331317055596963,-5.273323031480457,-0.8995407661644084,-0.9799977793880563,1.8091568488555954,2.3966919231837682,-0.10959161764165404,-1.4063247239068417,False,c1,2,"In the following edit, VE saved the internal page representation instead of the wikitext:
https://nl.wikipedia.org/w/index.php?title=Eurosong&diff=prev&oldid=38007082
--------------------------
**Version**: unspecified
**Severity**: normal",52049,-2,Needs Triage,True
-5.390048313441513,-0.11838651105695774,-6.745701786778607,-6.836774248106514,1.195904369551132,-3.310586333600429,-1.5977450804714834,0.1978236232664387,-0.7630150905824341,-2.2441515976430004,-0.337393629082666,-0.18354610465263133,-0.09611331323862338,-0.8148718789774625,-1.2283850457499534,-0.2960116536052019,-0.9177663427329067,-1.3527479960019315,False,c1,2,"When viewing [[testwiki:Visualeditor_image_captions]] in VE, the images cannot be seen. They are still ""known"" though - they don't vanish on save.
(My testing of this issue led to the filing of bug 50008, but the issue there seems to have gone away now. However, this one is still showing up for me, so I think this is a separate bug.
Please close this bug if it turns out to have fixed itself.)
--------------------------
**Version**: unspecified
**Severity**: normal",52035,-2,Needs Triage,True
-4.156049891010513,1.4600512696767023,-2.6100921152564585,-4.967095249323803,0.49243907740663095,-0.19302026494676694,0.9338939201629524,-1.0098485486856095,4.400405409405174,0.252443299352743,0.34297960883118295,4.106919858045945,-0.09604681396782144,-1.046082757155105,2.2590320179437127,-2.2573928044272393,1.5408661226904947,-2.017141642848613,False,c1,2,"Assuming we do not yet have something like this, it'd be awesome if this Jenkins plugin could be installed:
https://wiki.jenkins-ci.org/display/JENKINS/Embeddable+Build+Status+Plugin
I want to be able to embed such a build status image on some website.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",52022,-2,Needs Triage,True
11.65296531133922,0.9669387289947551,2.824850481361292,-1.2039249785047481,-1.3953127674463168,0.5875735653988687,-1.7141436405954389,-3.7951080923701914,0.7295895448093235,1.082624969470145,-0.877244339314132,0.5881378742963637,-0.9865954447447995,-0.11104302043230518,-1.3817395642540555,-0.0950905889151436,-0.5845442831818624,-0.04349852238322205,False,c1,2,"I have tryed to add {{Commonscat|Saint Robert of Molesme}} to the article w:cs:Robert z Molesme using VE. VE adds ""="" behind parametr in the code. See this revision: https://cs.wikipedia.org/w/index.php?title=Robert_z_Molesme&oldid=10436403
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://cs.wikipedia.org/w/index.php?title=Robert_z_Molesme&diff=10436403&oldid=10436394",52019,-2,Needs Triage,True
-1.4936101305240654,-2.359040111770593,-2.65020352063123,1.5567811459186833,-1.0006993191939473,2.254501777667044,-1.0695351190250237,-2.48875757658085,-1.8013447069341935,1.6532432990670651,-1.5924053957989477,-1.3640805552276276,0.41183100367277614,-0.07481298099105604,-2.3640826989011114,-0.45334758316556434,0.11395283877503037,-0.7024382684804726,False,c1,2,"After loading the Visual Editor on
https://pt.wikipedia.org/wiki/Quadrado?veaction=edit&debug=1&uselang=pt&useskin=vector
and clicking in the template which shows the text ""Wikicionário"", in the bottom right corner of the page, I get the following error on console (Google Chrome 28.0.1500.52):
----
Uncaught TypeError: Cannot read property 'description' of undefined
----
It comes from the line
----
if ( data.description !== null ) {
----
of the following script:
https://bits.wikimedia.org/static-1.22wmf7/extensions/VisualEditor/modules/ve/dm/models/ve.dm.MWTemplateSpecModel.js
--------------------------
**Version**: unspecified
**Severity**: normal",52016,-2,Needs Triage,True
-4.353796027760895,5.275112703000062,-3.675060452631234,-3.396897474254305,-0.7244397534275211,-2.3238569340172326,0.8989553330185167,-2.534526195403635,3.5240878278757064,-0.5928476410291577,1.4712241823047383,-1.208835222167752,2.0074656459572253,-0.7128584082112717,1.5685604590248827,-3.7380666038880555,-1.201974983131195,1.5290865648942027,False,c1,2,"A user suggested at
https://pt.wikipedia.org/wiki/WP:Editor_Visual/Coment%C3%A1rios?oldid=36175459#Alternar_entre_editores_sem_sair_da_p.C3.A1gina
which there should be a way to alternate between the two edit methods (visual/source), to avoid having to do two edits, when e.g. we are not able to finish our edit using the Visual Editor (maybe because we underestimate its difficulty, and changed our mind while using VisualEditor).
--------------------------
**Version**: unspecified
**Severity**: normal",51986,-2,Needs Triage,True
5.447329891068248,0.4819124103671708,12.666469368441668,-3.1876749017396766,-1.4262246622860815,-1.1381998283516177,4.592005103108488,-5.93015817528322,-2.242126740282923,0.7543457506993123,1.4528136798267997,-0.7819710589878102,-0.6849321072327115,0.26679602830428983,-0.9819439450348142,-2.11182892308347,1.2836417266890139,-1.9206199099315238,False,c1,2,"When I open
https://pt.wikipedia.org/wiki/Jorge_VI_do_Reino_Unido?veaction=edit
I see several warnings like this on Google Chrome:
The page at https://pt.wikipedia.org/wiki/Jorge_VI_do_Reino_Unido?veaction=edit displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Commons-logo.svg/22px-Commons-logo.svg.png.
--------------------------
**Version**: unspecified
**Severity**: normal",51984,-2,Needs Triage,True
-1.8572304272720195,4.688218035877227,-3.009109420481746,-1.3276435175349817,0.46002656970614675,2.8676374581998196,-1.8212994427184732,2.0900700414741795,-0.37177132648274214,-2.4007632048317036,-2.0799131557771897,1.4098450202992294,1.325486637992816,0.9264876055008084,-1.8087899908763214,-0.5060358004665377,2.195543881354145,-0.7129624874350464,False,c1,2,"Screenshot
See associated screenshot; that's the VE, in edit mode, on it.wiki. You can apparently still type into the window, but aren't given the toolbar or, for that matter, the ability to save. Erica is currently testing it.wiki's default gadgets one by one to see if any of those are causing the problem.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11224}",51960,-2,Needs Triage,True
4.4802826821001,1.8313531906681924,0.03987513192793912,-4.761810176543683,-5.871134676260194,6.82611057929257,-1.7786704581850978,0.17465238447022874,-1.909982107601672,1.4672901100040443,-5.8650921726590335,-0.7299814800126943,-3.4707843123778703,0.8575116075389912,0.49718672701399047,-1.7735531803054347,1.9577430693708247,-0.9793007865276342,False,c1,2,"At present, VisualEditor is invoked when clicking on the Edit link of sections. Please provide 'Edit Source' link in addition to that for each section.
--------------------------
**Version**: unspecified
**Severity**: normal",51950,-2,Needs Triage,True
6.263048982921227,-2.6824513637816523,-2.0639726496165274,0.004356079282713976,-0.9086007480433965,0.49380170640585086,-2.51803726263814,-0.12265172895361179,-1.7826764141606932,0.6979884366935245,-1.951197531118002,-0.16402050096052778,-0.6555587063821298,-1.5494772963257928,-1.7354933569049718,0.7806147205625604,-0.5732911744190856,2.029789869284884,False,c1,2,"When I edit https://en.wikipedia.org/wiki/Golden_tortoise_beetle in VE, the template names at the top and bottom are suddenly in Uzbek (""Turkum:Biologik turlar"" and ""Andoza:Chrysomelidae-stub"") and parts of the contents of the rendered infobox are in Uzbek as well (""Kingdom:"" becomes ""Olam:"" etc.).
More evidence of VE's growing self-awareness? Caffeine-induced hallucination on the reporter's part? Inquiring minds want to know.
Chrome/Ubuntu and FF/Ubuntu.
--------------------------
**Version**: unspecified
**Severity**: normal",51939,-2,Needs Triage,True
-1.1510846268900763,-1.4190970342350226,-3.477320586229437,-2.2151567576917346,-3.010713076527569,-0.2924391999741901,-1.7667977141501305,-1.8589493538086814,0.28820510202628735,-0.7249902059094318,0.467973550252728,0.11924821665444263,-8.89561945189854e-05,-1.3842327782306478,-1.4049072150449637,1.262549819976182,0.29634065110813834,0.7655057556940068,False,c1,2,"Screenshot of problem. Compares VE view and MWParser view.
Wikitext [[/Foo/]] should be interpreted as a link to ./Foo with label ""Foo"". This is likely a bug in Parsoid but I'm filing it in VisualEditor for now (feel free to make dependant on a Parsoid bug, or if it requires no action from our end, re-purpose and move there).
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11096}",51919,-2,Needs Triage,True
-4.594307146392657,4.385538203551953,3.854139269310565,-1.3514667033811247,0.20419838733547713,7.347080713783902,1.9200431991908786,-0.2816224711052407,-3.180187306057248,0.45509496068059185,0.9789785590783473,-0.03136117955794715,-0.4077993455893756,-0.6447186146014134,1.7846887838643495,5.995414382266528,-2.6898615624907922,-2.4917620590120366,False,c1,2,"In particular it appears that the |pictured parameter in a file link is not being recognised. Take a look at https://en.wikipedia.org/wiki/User:PamD in the VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: normal",51891,-2,Needs Triage,True
-5.296923598372279,3.982807800927745,-1.1095840193860838,-1.2536075443568226,2.0579994736267024,5.063952357937442,1.5709992547900073,-1.3376308557288406,-2.546455649118017,-0.7685247711168066,0.32633642059016843,1.432379982745277,0.9719561038500335,0.9485768786214663,0.6684913360483131,-0.5106820161806328,1.547648647496658,0.6012597739306991,False,c1,2,"If one creates two list items and then tries to bold them at the same time, the items are removed and replaced with a pawn symbol. This is reproducible on the version currently deployed on the English Wikipedia.
--------------------------
**Version**: unspecified
**Severity**: normal",51877,-2,Needs Triage,True
-1.8598070942824516,-0.3239267698616928,1.0540288288942072,4.358321181055548,0.8681694337003247,3.1521283433909426,0.17316212459874514,0.39330576676833673,-2.1409807870038584,-2.8917150194582915,-2.3574752024332586,-0.6320118961829835,0.4549461935401671,-7.314518735966696,4.940217014881058,0.2088968373851393,1.6341372208666536,-0.5861969027260487,False,c1,2,"In the following edits, images that were already in the article were duplicated on save, and the duplicate was truncated:
https://fr.wikipedia.org/w/index.php?diff=94163829
https://www.mediawiki.org/w/index.php?diff=713109
--------------------------
**Version**: unspecified
**Severity**: normal",51824,-2,Needs Triage,True
5.9652516070389385,-4.68455704018009,12.865885203171793,-0.7354157378381674,-0.5349740238560156,6.6575992124890195,0.29600410392980514,-0.6890978193414969,1.0807673730596667,1.3974521178211496,1.6929836364260722,-1.5128348343493216,0.5374530377234032,-0.8193570105471082,-0.13312603325503147,3.876908553420271,-0.8085711288303113,-1.7628078348357354,False,c1,2,"See https://en.wikipedia.org/wiki/User:Kephir/acid
In the VE: https://en.wikipedia.org/wiki/File:MediaWiki_acid_markup_-_VisualEditor.png
In the normal, rendered page: https://en.wikipedia.org/wiki/File:MediaWiki_acid_markup_-_native_rendering.png
--------------------------
**Version**: unspecified
**Severity**: normal",51810,-2,Needs Triage,True
-8.504893784371927,7.447806570990622,-4.9240698636163,-6.645673012581517,-0.9532028421409634,3.5336818288075644,-1.7547720128242998,4.079928158994566,1.6302635801756136,-1.9684878284370235,-1.8742290115470333,0.1560061456483004,-3.228576974821755,2.062673442798208,0.45717530929685424,-0.014082188865521983,-1.5301248437368964,0.2585424212884273,False,c1,2,"Tracking bug; the VisualEditor doesn't seem to work in IE8 (this may be a feature as well as a bug). I'm going to recommend that people upgrade, and mark this as an enhancement, but: it would be nice to have an official statement on if this is coming, if so, when, if not, why, etc.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51802,-2,Needs Triage,True
6.40564237929277,-2.4185573480720244,3.093021332470336,-0.9695821297092788,-3.537620603669556,1.6438516125179328,-7.53307367761451,1.0843591670476709,4.628888662112849,4.474383279256827,0.3609206655913755,1.633416924916345,2.7241238455209853,2.7659077049270735,1.9075092913632794,-0.8153807721733286,-1.518612945332662,0.7005483210975336,False,c1,2,"https://en.wikipedia.org/?diff=560548908
Step to reproduce:
1. Click on the ""Media"" button on VisualEditor toolbar
2. Choose a media to insert
3. Click ""Insert media""
4. Save page
--------------------------
**Version**: unspecified
**Severity**: normal",51795,-2,Needs Triage,True
0.2979140169303416,1.0838367269940896,1.1064016934718701,3.9646398322470278,-2.9570652927628918,4.2638687452861355,-1.3404342672100826,-0.8556562026901676,0.8279606783184024,-0.7816063516235872,0.46118684457590353,-1.6705934724626617,3.0501579184729817,0.5250382749691891,-0.9722022071966192,0.36333394294012566,-1.4010771106795203,0.6365972276354082,False,c1,2,"Screenshot
Check out the top left of the screen; interacting with an image, in a resize-y way, causes resize-like highlighting to appear in monobook.
Windows 7, Firefox 21.0
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11696}",51768,-2,Needs Triage,True
2.666609961942495,-15.7531090186045,5.405826123978766,1.8307689629506565,-1.5446010415710159,0.9653958623775514,3.220576511455895,-0.4520897306044875,3.7851954421725678,1.2331800910761483,1.011817521233644,1.3737878267546046,-0.1628302416201901,0.23748058654915116,-0.45988289746670397,0.38634349465041506,-0.4384741650485646,-1.0927328647279824,False,c1,2,"See (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611
--------------------------
**Version**: unspecified
**Severity**: normal",51756,-2,Needs Triage,True
1.4158247094468766,3.0327960889633943,-1.667538840264502,2.767750387777466,1.6670068184977849,0.7543953513983819,0.5541935198835848,0.22927786433214958,-1.8835121281499345,2.0634425355716415,0.9976677111080341,-1.6271079424549593,-0.698621315315628,0.08567247933633304,-1.509519300994504,1.0845455655131222,-1.041401536477747,0.04561549061168324,False,c1,2,"If you explicitly declare positional parameters in a template, and then edit it with the Visual Editor, the Template Inspector converts it to implicitly declared positional parameters - i.e. {{some template|1= foo |2= bar }} becomes {{some template|foo|bar}}.
Now, if an explicit positional parameter contains an equals sign, then the Template Inspector puts nowiki tags around it. So {{some template|1= foo=bar |2= baz }} becomes {{some template|<nowiki>foo=bar</nowiki>|baz}}. However, ""foo=bar"" and ""<nowiki>foo=bar</nowiki>"" are not equivalent wikitext. For example, nowiki tags will break wikilinks.
There's an example of the difference in this diff:
https://www.mediawiki.org/w/index.php?title=VisualEditor:Template_test&diff=712906&oldid=712905
See the effects for the revisions before and after (look at the ""Inline template"" section).
Before: https://www.mediawiki.org/w/index.php?title=VisualEditor:Template_test&oldid=712905
After: https://www.mediawiki.org/w/index.php?title=VisualEditor:Template_test&oldid=712906
--------------------------
**Version**: unspecified
**Severity**: normal",51739,-2,Needs Triage,True
0.2551282115377247,-1.098781044264916,4.62850624902217,3.8035412592493865,-0.42069635978930053,4.250278244270501,-2.1839322475385012,-0.6051072450100388,1.8912168576567512,2.801519148069806,-0.5977018948995356,-0.10064505357038867,0.6188970283934774,-2.2553574713746944,1.7108130588036214,1.4608648136477094,-1.8781114315850473,-1.3867125841703563,False,c1,2,"Screenshot
See associated screenshot. This was an attempt to include ""foo"" in a string-based parameter in the infobox on https://www.mediawiki.org/wiki/VisualEditor:Template_test
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11624}",51730,-2,Needs Triage,True
-1.4259425274263942,3.3269827957768285,-0.3058449245315291,-13.444043222768872,1.1003989988016667,-3.4332789875372995,1.1213507304562285,-7.657923191514983,3.757768381271613,-0.7221020311313371,1.1818122923212218,3.3408830891158834,-0.6280576136637439,0.13177979738890144,2.3579646613943455,2.6314493773591634,-0.7843506261463784,-0.5658809960559814,False,c1,2,"If I want to track a bug, I can just vote for it. This is pretty common practice, as I understand it.
But voting seems to be disabled in the VisualEditor product. Can we have it please?
--------------------------
**Version**: wmf-deployment
**Severity**: normal",51728,-2,Needs Triage,True
0.6663595307984553,-3.9442352964914313,3.3187123613714427,1.07982405761144,1.4861371825616532,-5.32528519574818,-6.582813761412185,-2.0862236151340925,3.293048262928938,9.239442365873403,-2.3448344897092994,3.991530999641527,-0.4664074483147038,1.7559775480734858,-0.23683565019235253,0.24468507736819614,-1.80621682304728,0.17024887026579694,False,c1,2,"Go to <https://test.wikipedia.org/wiki/IPod?veaction=edit>.
Click ""Page settings"", enter ""hello"" for the default sort key, click ""Apply changes"".
Click ""Page settings"", clear the default sort key, click ""Apply changes"".
Review your changes. VisualEditor wants to insert ""{{DEFAULTSORT:}}"" into the page. I don't think we want this behavior.
--------------------------
**Version**: unspecified
**Severity**: normal",51724,-2,Needs Triage,True
6.202350183513438,-3.3543683049130397,5.816095277382836,3.738155694528638,-3.698581698757282,-2.868324677233801,-0.9512654138234913,-0.8973309772024279,-0.9719116527695889,-2.117114198420163,0.4735360075691424,-0.6135140114876663,4.494872196866773,0.22899907208463777,3.6817769435935697,0.4455011223819667,1.2664405550534605,-0.6142908263169311,False,c1,2,"The URL was served for me in 22.766 s and contain spurious entries (without visualeditor tag) like
21:47, 17 June 2013 . . (0) . . Feedback: Wikipedia:File Upload Wizard . . DenakiPanos70 (talk)
This practically equivalent search was served in 1.645 s: <https://en.wikipedia.org/w/index.php?limit=500&tagfilter=visualeditor&title=Special%3AContributions&contribs=newbie&target=&namespace=8&nsInvert=1&tagfilter=visualeditor&year=2013&month=-1>
--------------------------
**Version**: master
**Severity**: major
**URL**: https://en.wikipedia.org/w/index.php?limit=500&tagfilter=visualeditor&title=Special%3AContributions&contribs=newbie&target=&namespace=&tagfilter=visualeditor&year=2013&month=-1",51714,-2,Needs Triage,True
2.474214067664127,-3.1808925024579136,3.3985022690398345,0.5493138991921043,3.2512960501385013,-0.39713713535364725,0.7021909768161327,-3.935462876160479,4.527163978930876,-0.5278303971909546,0.4557276852137906,-2.0503820384186584,-0.40393247749147587,-0.46700552300586473,0.27072273115129164,-0.14516089961730522,1.3539293633332152,-1.9340525108028066,False,c1,2,"**Author:** `rachelqa99`
**Description:**
On this page, we cannot create a reference: https://www.mediawiki.org/wiki/User:Cmcmahon%28WMF%29/references_bug
We can create a reference on this page: https://www.mediawiki.org/wiki/User:Rachel99/VisualEditor_Feature_Test_Charter/refs_demo
--------------------------
**Version**: unspecified
**Severity**: major",51706,-2,Needs Triage,True
-5.471510432656942,-3.2953971115584775,0.1961478851646774,0.9528762480195487,5.688461153919411,1.8990406990559954,-0.37353303903111,1.08425333787415,0.8823787354790025,-3.2588097446363635,-0.7313043394532817,-2.57384568006389,-1.813914688840918,-4.420058825258608,5.155233854884496,0.18301047688711233,0.21001565901371122,-2.1063249694380244,False,c1,2,"A user reported this edit
<https://pt.wikipedia.org/w/index.php?title=CMM_-_Canal_Meninos_e_Meninas&diff=36129698&oldid=36129686>, where he just meant to delete a sentence. However the content was duplicated and templates were substituted in this duplicated version.
--------------------------
**Version**: unspecified
**Severity**: normal",51701,-2,Needs Triage,True
-2.0438348792650913,-11.524012014716089,-1.5860535243894418,0.5819338906633429,5.501692188365013,3.3996808435003496,1.9854105147130943,3.9869502962725534,2.000485380072214,1.0148056013939133,2.4912236728441335,-3.411461104471104,2.7032903731914173,1.55306588760135,-0.16591255677947014,0.8126065093189313,1.2800934663127534,0.13252453447096202,False,c1,2,"See https://en.wikipedia.org/wiki/Daryle_Singletary?veaction=edit - the first three (but strangely, not the last) discography tables.
--------------------------
**Version**: unspecified
**Severity**: normal",51691,-2,Needs Triage,True
-0.6056022445946887,2.220673791917143,1.9986045510662613,-3.957355596366794,-1.1935851031361988,1.7115959128481435,1.33437655572052,-0.45570293808928797,-1.428440143025314,0.3316880001228881,0.9887833461794515,0.06595080698670186,0.9470889452379039,0.3158290909345691,-3.567681567061787,0.8530784883526981,1.4269745265150082,1.695938509027972,False,c1,2,"See the bottom of https://en.wikipedia.org/wiki/Chad_Griffin for example - it also occurs at https://en.wikipedia.org/wiki/3rd_Brahmans and https://en.wikipedia.org/wiki/In_re_Estate_of_Gardiner (each time in a different language; Russian, Vietnamese and French respectively).
I have no idea what's going on, but this seems pretty important to solve for.
--------------------------
**Version**: unspecified
**Severity**: normal",51687,-2,Needs Triage,True
-4.674932469037293,2.663386772658061,5.157597563698552,0.5879205528745819,-0.2367902031480148,-1.0424172811214991,3.6406317995700013,-2.12144794235654,1.9169898154371967,1.0421763161339745,1.727732033886992,5.432407993478813,-0.5423204677207245,1.2953305189554989,0.19284451561127636,-0.8828223851657773,-1.1759175309982597,0.3006359126298761,False,c1,2,"An example is https://en.wikipedia.org/w/index.php?title=Valotte&diff=559961373&oldid=559939306 - another is https://en.wikipedia.org/w/index.php?title=The_Day_the_World_Gets_%27Round&diff=559962523&oldid=559851975 where the VisualEditor seems to have taken it upon itself to drop content and convert templates into pure reference tags
--------------------------
**Version**: unspecified
**Severity**: normal",51684,-2,Needs Triage,True
-1.748022261936698,-5.734907249936553,4.976047188202024,0.3464215954301977,-4.545332396880298,5.335521365219709,0.7818213259846463,-0.6476422909680855,2.7927929864177283,0.3916289016875769,0.058370935722214856,-0.5802021197727751,0.008606841396414211,0.6226603397071404,-1.4005093777175643,-0.1547955614407841,0.2452752890172336,-1.848683465467296,False,c1,2,"See the tabs on https://en.wikipedia.org/wiki/User:Panpog1 for example.
--------------------------
**Version**: unspecified
**Severity**: normal",51683,-2,Needs Triage,True
13.551084932714073,-2.5240870768034576,-0.5256680170438024,-3.5736793610519384,-4.31818363794965,1.667499486123907,2.484094236478266,2.350450609632898,-1.1938271925755453,-1.1855473869400543,-2.4615875693425044,-2.680926354304498,-1.6735469771186287,0.4434493521780407,-1.832277908093353,-1.52082131581949,0.4361682350745175,0.757933114709066,False,c1,2,"**Author:** `bellayet`
**Description:**
At bn Wikipedia ULS does not working with recently added VisualEditor beta.
--------------------------
**Version**: unspecified
**Severity**: normal",51643,-3,Needs Triage,True
-3.895791047355304,-2.7069147920524177,-5.41859761160557,-17.455776960493452,-3.9672781580265597,-2.7881989226905555,2.7591714701658185,-8.766992911099669,5.509779875654352,-0.71916890127188,1.3162177412450844,0.3597897226487541,-0.45721861554068965,-2.9584115990919937,5.581479991289135,-3.768477634659446,-1.9817226638234589,-1.0031867985318725,False,c1,2,"I failed to find it under extensions where I was expecting it to be.
--------------------------
**Version**: unspecified
**Severity**: normal",51637,-3,Needs Triage,True
-4.619743711341895,1.6565992515208379,-1.328703344589016,-2.5118224524355286,-0.5036686951172736,1.1659214897481351,-0.880476220661297,-1.9833748234117263,0.18617823446418524,-1.7369793424366278,-2.2712088285321608,0.8096246512210847,-0.10627527495290057,0.3218908658927173,0.012041439944945331,0.45797035823620313,0.6071738941122289,0.10786803348488694,False,c1,2,"The preference ""Use the wikitext editor for editing sections while VisualEditor is in beta"" should be enabled by default.
More generally, users have the option to use or not to use the VisualEditor at the top of the page, but not at the section level. Some users in the Hebrew Wikipedia complained that it's disruptive, and I agree with them.
Another possibility is to have two section edit links, like it is at the top of the page.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49666",51621,-3,Needs Triage,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,True,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: normal",51587,-3,Needs Triage,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,True,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: normal",51547,-3,Needs Triage,True
11.138806871920586,-6.661109219525511,-2.6711549941135058,-4.297260784904259,-1.5985205577558874,2.264830209922513,3.3476298256900927,1.612052521757167,-3.395990126963695,-0.4628792192048117,-1.0644216548592862,0.6947397851388379,-0.9450117877444573,1.7035455727041517,-3.2799126528367153,-0.32155966560622185,-0.6375589012500039,0.3330543008814455,True,c1,2,"Currently links with mw:WikiLink/Interwiki get alienated
--------------------------
**Version**: unspecified
**Severity**: normal",51545,-3,Needs Triage,True
-7.644715829829641,-4.854113558715719,-2.5104762777016862,2.2379382521332727,-0.16939058049442185,1.4365005006850444,3.9932619979546553,4.864318236739014,-3.764118112653878,9.604899441598757,1.1959312701858944,-0.6715539902334702,-0.4947685779112039,1.0861993378490515,-1.0180565979194451,1.093336741966204,3.1735284036040747,-0.8586279499230349,False,c1,2,"The link inspector shows valid links as red in the autocomplete function. This is potentially very disruptive and confusing for editors, new and old alike, who pattern-match 'red' to 'this page does not exist'.
--------------------------
**Version**: unspecified
**Severity**: normal",51540,-3,Needs Triage,True
6.2551629494546965,-2.2634953094500787,1.9060482980649098,-1.1244392904300144,5.240465744684755,-0.990414323726149,-0.6294406609905829,0.8146423185581165,0.6914493196314426,-2.59819228228419,-0.08453991255046933,0.7980027185576799,-1.2282179756649523,-2.3931549791110576,0.5708972901649885,-3.449115267908929,-2.072545092582481,2.058287754616906,False,c1,2,"https://en.wikipedia.org/w/index.php?title=User:TheDJ/sandbox&oldid=559712952
Try adding a gallery that was made using <Gallery></Gallery>
Anything following the opening <Gallery> tag seems to be enclosed inside it. Also when saving, the following might apparently occur: https://en.wikipedia.org/w/index.php?title=British_Rail_Class_50&diff=prev&oldid=559199747
Discussion: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=559712784#Spurious_gallery_tags
--------------------------
**Version**: unspecified
**Severity**: normal",51525,-3,Needs Triage,True
1.1751286973446784,-9.132065723439366,5.406370143793996,-2.660741142537488,0.6725244783723594,-1.2221978092602936,2.2685181341391365,-3.943631328856115,0.06737667806315767,-0.2160281757421858,0.6127630008927212,3.4878633013634746,0.3776701388100654,0.20115508630083223,-3.384576546499209,-0.14761461688145328,1.2664558925570775,2.321950097959369,False,c1,2,"See https://en.wikipedia.org/w/index.php?title=Breast_cancer&diff=558696523&oldid=558695500 and https://en.wikipedia.org/w/index.php?title=Downward_causation&diff=prev&oldid=558735268 for example; I have...no idea what's happening.
--------------------------
**Version**: unspecified
**Severity**: normal",51522,-3,Needs Triage,True
-7.0241106177780495,2.1823955226993235,-2.3074508919850487,-8.780969174259603,1.5087667844246306,-3.930691938765869,0.07440501286508194,-4.455826405125386,1.7145192526199289,2.606427577193206,-0.790221022375651,-0.8937862368401079,-1.3647168302428527,0.33983695709155537,1.9628863620741654,1.5317477342199206,-0.5552485492173806,-1.7492752944527628,False,c1,2,"As requested at https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=559578396&oldid=559577689
Whether this is something there will be a generalised use case for, I can't say, but it's kinda a nifty idea in theory. I'd stick it on the ""we'll consider it when everything else works"" list.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51486,-3,Needs Triage,True
-1.5239356960888963,-1.192495047815333,2.7870392601204834,0.3836618331960353,-0.28104174405770993,6.0698904378527905,3.4615369795816386,1.8009434100281427,-3.52140598010845,0.6944700934555037,1.3042641997993507,-0.39913061254893845,0.5743636993761734,-1.6742435190138876,-0.5762018286390136,-1.0889058726040584,-1.0936255651422686,-1.1949121635593811,False,c1,2,"When editing for example http://pt.wikipedia.org/wiki/Rana with the VisualEditor, all the red links are shown as blue links.
--------------------------
**Version**: unspecified
**Severity**: normal",51475,-3,Needs Triage,True
-3.7772570878951535,5.582140581169625,-0.24278374569142258,1.5996112702816965,0.844723308304727,-1.253902420074718,2.253377413834472,-2.1094154665968348,-0.6631625200010987,-1.1485408447737426,0.04279836976490303,-2.4912692862075074,0.48704866805010116,1.2481113624175357,-1.1147316502261697,-1.5264073752779166,0.5545800510156633,-0.7831848180988037,False,c1,2,"The number of browser tests and the number of browser test builds have both increased to the point that our original idea of a mid-day build and a late-day build (Pacific time) no longer serves us well. The builds take long enough that they run essentially back-to-back all afternoon every day.
I suggest we run all the builds at 11:00 Pacific time to have timely build information available around deployment time during the US working day.
Then I suggest that we run all the builds once at 19:00 Pacific time (GMT-8) so that the results will be available for analysis in the morning Croation time (GMT-1)
--------------------------
**Version**: wmf-deployment
**Severity**: normal",51418,-3,Needs Triage,True
-3.3386288332840315,-4.709753695598392,-3.4173613689890363,3.125986124953271,5.040757342566373,1.3004748182292374,-2.943419484353157,1.9846111143406295,-0.2665053101320932,-3.4427470900610997,-0.04661429717925092,1.1306428464751124,-0.14753412727177118,-0.11035077534652782,0.4250746831805756,-0.4514043271309006,-0.46074425686798925,-2.206211702747254,False,c1,2,"The image is loaded
editing article [[:zh:港鐵都城嘉慕電動列車_(直流電)]]
if there exists a wikilink to a file, then the file will be loaded which should not happen.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11725}",51384,-3,Needs Triage,True
-4.809576944412365,1.4666904935426555,0.4231780414978594,2.8895805532390537,7.975607217263525,6.591642851266491,-3.4453492568960433,0.21265853944364776,-1.0396327174162443,0.6823719170280818,-2.4247595277247083,2.026184142383503,-0.2816181224065595,-0.7151715392323439,-0.7870599989248532,1.135682692247471,1.2432496277551797,2.3527350369721587,False,c1,2,"To edit an article using the VE, the URL is ""...?veaction=edit"".
But, by loading the page with the VE, the URL is changed and becomes the same than the one to display the article.
There is consequently an inconsistency between the URL and the page content.
""?veaction=edit"" and all other URL parameters should not be changed/removed.
--------------------------
**Version**: unspecified
**Severity**: normal",51336,-4,Needs Triage,True
-1.2143644520982613,-8.864057635034378,-5.259834259988654,-3.9803769558821305,-5.7311850793823265,3.4702789173917106,6.392933940075442,-0.495344556416201,1.7097275554545635,1.4586172749231663,0.9592517935658766,-0.8369300738796301,-1.8735556707509957,-0.40424497183725094,3.4284555310120544,-0.8487739539769847,0.8703817075017415,-0.5160742746000377,True,c1,1,"VisualEditor's new features should be exposed for testing outside of our local development environments.
--------------------------
**Version**: unspecified
**Severity**: normal",51084,-4,Needs Triage,True
3.5932749331209206,-3.0898851844349853,-2.561499824995513,-2.150239808533014,-2.2100725017801226,-2.275331129930455,-2.761566796316381,-0.08371744262085676,0.6789896582341403,-2.8574487312605417,0.12548048663894873,-1.9484999445942686,0.06219370471220387,-0.5196085128636154,0.0847376530362709,1.379151300615981,0.5395762457532864,-0.809053862134419,False,c1,1,"I updated the translations of several VisualEditor messages in translatewiki.net. The changes were committed to Gerrit, and it looks like LocalisationUpdate ran several times since then, but I still don't see them on the Hebrew Wikipedia.
For example, let's take the message Visualeditor-linkinspector-suggest-matching-page:
1. Update in transatewiki.net: https://translatewiki.net/w/i.php?title=MediaWiki%3AVisualeditor-linkinspector-suggest-matching-page%2Fhe&diff=4721642&oldid=4682586
2. Commit to Gerrit: https://gerrit.wikimedia.org/r/#/c/63552/1/VisualEditor.i18n.php (line 1661)
3. Still not updated in he.wikipedia: https://he.wikipedia.org/w/index.php?title=Special:AllMessages&prefix=visu&filter=modified&lang=he&limit=5000
--------------------------
**Version**: wmf-deployment
**Severity**: normal",50893,-5,Needs Triage,True
-2.95482917324374,6.872652338335804,3.497298205818673,2.4552026501100683,-1.964334856723085,0.8754117670614954,-0.060560317521723306,-2.5522338030339164,0.13264330615104913,-2.366912190878516,-2.0104896038900626,-2.380368183269261,-0.7885136965367812,-1.308641657553511,-0.5460294185666434,1.253375186911525,-1.199885790947456,1.3265215492605689,False,c1,1,"**Author:** `swalling`
**Description:**
Placing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page. While VisualEditor correctly represents this text in read-mode, when it editing it displays thumbnails for the linked images instead of the link and text. (Screenshots of the error and associated markup to be attached.)
--------------------------
**Version**: unspecified
**Severity**: normal",50669,-6,Needs Triage,True
-4.765782812636254,8.388206556151747,2.081079324546362,2.632747163790646,-6.961107708211374,3.123648536940098,-2.4471308412861363,1.8844836139960774,-2.389343225223379,5.403390906948573,-6.247998696159587,-3.846422770705499,-3.518514161181037,0.5957489224608894,1.4918693569252097,0.5782869816047458,2.1520186246419906,-1.7404655882605644,True,c1,1,"(This is only for action in the immediate run-up to VisualEditor deployment as beta.)
The section edit links should point to VE rather than the wikitext editor as part of the 'being the default editor' schtick. This should only apply to wikis with VE on 'beta' rather than remaining on 'alpha'.
--------------------------
**Version**: unspecified
**Severity**: normal",50658,-6,Needs Triage,True
-1.6223175158790433,1.5949484606292916,4.065049103004441,9.759614360569568,0.5780472737843876,-2.3810659411413235,2.3836003495102878,-0.11321061625065137,1.2342774498240567,-0.7203940406122618,-0.43233126332477045,-1.9717356122815928,-0.1645793846179613,-0.7263833834123892,-1.6003352378645332,0.48060287778646293,0.7369193842858188,0.46224894031769126,False,c1,1,"Feedback gets submitted to a page given by the message MediaWiki:Visualeditor-feedback-link. The link can differ from language to language.
But feedback gets submitted to the link for the user-chosen interface language, not the wiki/content language and so hitting different pages.
ex.:
german interface: https://de.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/R%C3%BCckmeldungen&diff=prev&oldid=118691535
english interface: https://de.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=prev&oldid=118691557
This may apply to other messages as well
--------------------------
**Version**: unspecified
**Severity**: minor",50645,-6,Needs Triage,True
13.206833793638605,-4.604725006701244,-3.009607829753003,-2.804534960899237,-1.2309755259730384,3.841404866832285,-1.8616345961296137,-0.06913866897491897,-0.8583407323401908,-1.5666317306547057,0.276109498008553,0.5406570035039173,5.010295060915287,0.9182360418386244,0.9808699512052232,-2.6763962878763525,0.0216048455210176,1.9348036926648982,False,c1,1,"Screenshot of the English Wikipedia using VisualEditor, 2013-05-18
VisualEditor seems to be expanding certain image links. Screenshot attached.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11087}",50596,-7,Needs Triage,True
-3.0462077152127867,-7.10363040311744,-2.9167911127059813,-6.133530724289524,-3.6935880089462403,4.030622725609059,2.1925909030973214,4.598641457770824,2.692175270667841,-1.1865886638403782,-2.68672237498075,-2.3749008669461222,-2.6779554653084032,1.8584018392941601,-0.2519582839553509,-3.8443607992719886,0.18791644749914016,-1.0894614095338595,True,c1,1,"Not sure how to proceed on this one.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50558,-7,Needs Triage,True
-1.0408605927820562,-0.3922369561676682,2.9459147504526264,0.8858921524659027,1.1330144166371579,6.8752645443569875,-2.4688956288800687,0.6293828890820299,-2.6116476183515216,1.572372473159148,1.6570020395434244,-0.899422060288288,-0.33548330378972047,0.869139651128096,1.189326255781804,0.06053076429384446,-0.08472415878417516,-0.5892856799803221,False,c1,1,"1. Edit http://en.wikipedia.org/wiki/Refrigerator
2. Look at the list in paragraph ""Production by country""
The list has extra empty lines, some with a bullet, some without.
The saved wikicode is OK, though.
--------------------------
**Version**: unspecified
**Severity**: normal",50527,-7,Needs Triage,True
-6.139402608081975,0.5436800708332896,-4.411492821497655,2.157248963056549,-0.6874125225902658,-0.5768034195299823,-1.9701778529314886,-0.7341998019965698,-1.3356738578183749,3.1960904202389635,0.33350134160404155,-0.9674430069540325,-0.34151496113171387,-1.0125668278313729,-0.11907309766664032,1.5022683878121141,0.9214964733625253,-1.267052172299887,False,c1,1,"VisualEditor is currently unable to display the parameters in the template editor in the same order as the wikitext because they are provided as a plain object.
And per the JSON specification (and as proven by inconsistent behaviour in different browsers), objects are ""an unordered set of name/value pairs""[1].
And even if JSON would support it, once in javascript, we have the for-in statement and Object.keys() which do not have a reliable cross-browser logic for the order of the keys.
Though Parsoid is able to roundtrip the order (since it has the original wikitext and can put them in the right order), we can't.
I'd recommend the output is updated to output an array of some kind.
So instead of :
{ foo: bar, bar: quux }
It'd be something like this:
[ { foo: bar }, { bar: quux } ]
or (Trevor's idea):
{ keys: ['foo', 'bar'], values: ['bar', 'quux' ] }
[1] http://json.org/
--------------------------
**Version**: unspecified
**Severity**: normal",50523,-7,Needs Triage,True
-8.938178749629254,1.7104761755387017,-1.3872631065853192,-0.6048444770889542,1.414554105554525,1.105274407030522,1.6469168747652354,0.106317588519803,1.9713404626126512,1.475936708898458,1.1111998451758898,-2.003053353003778,0.15418682901256275,2.1986363775742914,-1.0615643312226206,-0.8636426374353943,1.8265669117992875,-2.1218667837301473,True,c1,1,"If you try to change a link anchor by pasting plain text over the old anchor (or part of the old one), it won't work. The new text will just stay plain.
You can't use the link dialog for this either, since there is no anchor field.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50489,-7,Needs Triage,True
2.4223674360697216,-4.8375609375457636,-3.156131661324979,1.5534109117778359,-2.282607757336028,-2.295839386341652,-1.0257139427443063,-3.3461441605063125,-1.037809265759594,-2.635377056288253,0.2094248914004906,-1.149765632876351,1.1316073805328744,-2.371995467273891,-0.8600869755889002,-1.3774066903299764,0.5081848705393315,0.2326585319557004,False,c1,1,"**Author:** `the.anonymouse.wikimedia`
**Description:**
screenshot of editing my .js file with VisualEditor
When editing user skin .js and .css page ([[Special:MyPage/skin.js]] and [[Special:MyPage/skin.js]]), line returns are replaced with ↵ symbols. I attached a screenshot to this bug report of editing my .js page with VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10832}",50471,-7,Needs Triage,True
0.5634732761192836,-2.6090098069831704,1.971595574557245,5.79507224272701,0.8353331267931872,-1.8143293294463854,-3.021184281042918,0.7742116747229731,-0.14067571069220391,2.634428195965297,-1.5069024935495627,-1.3575436656220656,1.4214229550853101,0.6052697421604218,-0.37719687609290276,0.08855018771057152,-1.7459127963699999,1.34088773894309,False,c1,1,"VisualEditor link dialog box incorrectly showing red text, 2013-05-13
Go to <https://www.mediawiki.org/wiki/Sysadmin_hub>. Click ""edit"". Highlight the word ""wiki"" and click the link icon in the toolbar. A dialog box pops up incorrectly showing ""wiki"" in red text (indicating that the article does not exist). Screenshot attached.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10762}",50433,-7,Needs Triage,True
7.178497023272541,-10.38899020685072,1.1322232234740568,2.6678586269136586,-2.689370903164408,-1.844385697727681,-2.409753084610029,-0.5794986451396107,-0.016713711941422182,-2.6313401723391765,0.7660698575321039,-0.21696927025179835,4.50923506111739,3.1065918826564207,1.6217108741895814,-0.27531578936253365,0.024361153842016314,-0.5287531682716147,False,c1,1,"VisualEditor message key exposed on mediawiki.org, 2013-05-13
URL: <https://www.mediawiki.org/wiki/MobileFrontend/Photo_upload/Analysis>
Error: see attached screenshot
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10756}",50431,-7,Needs Triage,True
-2.6696431770221314,2.0399943799961626,0.5949100491587949,0.5042392375047784,1.0498349843880037,2.370350307551436,-1.2409475920300705,-0.43227002121463765,-5.05372439111594,8.843159757436869,-1.688934987660687,-1.03578462451218,-0.7856303199181136,0.300610764053709,-0.6016170023210803,-0.5624433644219445,-3.354638513566144,1.420175528674536,False,c1,1,"When the VisualEditor replaces the normal ""Edit"" tab with ""Edit source"" it deletes any selected/active state on the tab. This results in an active edit tab becoming non-active when you are on &action=edit.
Additionally on a non existent page ""Create"" gets replaced with ""Edit source"" instead of something like ""Create source"".
--------------------------
**Version**: unspecified
**Severity**: normal",50316,-8,Needs Triage,True
0.016179989322190558,-3.9014988165241338,5.159876541371933,1.4529667362874386,-2.5105941773844784,4.243837735596844,1.3325487012953987,-0.06026485898965386,-0.7784727947947984,0.9500225728434399,1.467679442114758,1.5680148993300096,1.5222632709617057,-2.561066230477886,0.245532087672359,-0.5081474111923019,-0.9704935938023569,0.2868559377077651,True,c1,1,"As per Subbu's report. (The corrupted table is going to be a different bug.)
--------------------------
**Version**: unspecified
**Severity**: trivial
**URL**: http://parsoid.wmflabs.org/_rt/en/BMW_801",50179,-8,Needs Triage,True
-2.379073766768928,-0.010796274253582538,-1.4846562776623635,2.1232634221695186,-5.710246120857027,1.3972519678208302,0.5118651096280846,1.0952848380362883,-1.8158204163141032,2.617233401780359,1.8887887938558854,-0.9131621201469173,-2.2716356838859904,2.2754461130375256,0.8324516246869473,-0.39449306074646395,1.7085266661076737,-0.3667399789279371,False,c1,1,"In MW, annotations loaded from the document will have data-parsoid attributes, and so will have difference store indexes to new annotations. If two words with differently indexed bold annotations are placed side-by-side they converter will close the first one before opening the second, e.g.:
<b>Bold on load text</b><b>added text</b>
Which Parsoid converts to
'''Bold on load text''''''added text'''
--------------------------
**Version**: unspecified
**Severity**: normal",50110,-9,Needs Triage,True
-3.893279729896088,-4.039251304279222,-6.068354695096792,-2.4174344231873692,-0.2587101619066362,3.2288977106964216,-3.777019080126507,3.987244827879902,-5.660716588971646,2.691870146423228,1.33454632599635,-2.714878887137856,-5.724697334415084,-0.19302207665271887,1.3518961730470442,-3.563088957454533,0.11763017943947096,0.7764944041112922,False,c1,1,"https://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213
All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra </span> and </table> got added automatically.
Where's that ""partial serialization"" mentioned before?
--------------------------
**Version**: unspecified
**Severity**: normal",49860,-9,Needs Triage,True
-3.0381034986650555,-6.758944881980263,-5.072880213850089,-1.8497974084652817,8.223247150491849,-4.23933039408274,-2.891970653157059,-0.4558174610695541,-0.9945498298563324,-1.355456725204606,-1.6071359333725244,1.2566526204408353,-0.5469523941896544,0.11122965715880628,-1.6469919602844185,0.23239039225487798,-1.2897015073509561,1.1811924459285235,False,c1,1,"I have ""1 notice"", ""You are using an alpha version...."".
1. Clicking the notice, it pops up.
2. Click the message contents, the popup hides.
""1 notice"" remains. Maybe it will go away when I save the page I'm editing?
3. Save the page, and edit again.
The notice is still there, and even expands when the editor is started. Blargh!
--------------------------
**Version**: unspecified
**Severity**: minor",49816,-9,Needs Triage,True
0.6683349745472267,-2.934969678046251,4.228538753344964,1.9553385576457698,-8.353802799532767,1.4126739906245602,8.392159635280251,4.429973432245934,-2.4367704431442396,4.794606008100768,4.524034206262991,-1.5402941412706213,0.7593966356956066,-1.6848203926678793,1.4732238902826857,3.4974846753051945,-0.7534267563313796,0.9280266430180533,False,c1,1,"Add RTL support for page-, paragraph- and block-level elements in VisualEditor, as well as support for multi-language use in articles.
Full proposal (GSoC2013 project) is available here: http://www.mediawiki.org/wiki/User:Mooeypoo/GSOC_2013_Proposal:_RTL_Support_in_VisualEditor
--------------------------
**Version**: unspecified
**Severity**: normal",49814,-9,Needs Triage,True
-0.3877897925368372,-1.5615787576822093,-1.3473904905687561,2.3375882764587352,6.545976929750115,0.1008038520532113,1.4656601838245402,0.7917848032140659,2.374464075066191,3.404233460797389,1.4470480123769742,1.4147265916230858,0.41448078511634545,-1.5125697852213689,0.5165896665380583,-0.20559411225161406,1.6520376916942323,2.770539411340935,False,c1,1,"CSS and JS pages shouldn't be editable using the VisualEditor, but only using the regular source editor. These pages should only have the ""Edit source"" tab.
(It may make sense to have them editable using the source code editor that is used for Lua, but that's a separate issue.)
--------------------------
**Version**: unspecified
**Severity**: normal",49768,-10,Needs Triage,True
-2.7836334954947257,-2.649850932448471,-2.340808387986378,2.9412154588728887,2.48756411973267,0.5547155356397062,-2.6294792284818493,-1.6994111129512226,-3.041228095264116,2.383436437298184,-0.740531035358047,3.1685069994593267,0.5309858550559072,-1.2826405960157676,-0.08639378225064931,-0.5536967285143971,1.0179386152931642,-1.067199870454501,False,c1,1,"**Author:** `benedix`
**Description:**
One of the feedback-mechanisms in the VisualEditor is broken:
'visual editor' -> 'review and save' -> 'something is wrong' -> 'report problem'
I made a little test:
http://www.youtube.com/watch?v=Zzt_2CBfTNI (35 seconds)
The feedback is sent to http://parsoid.wmflabs.org/_bugs/ but the request is canceled after a few seconds.
Btw. There is no visual feedback to the user that shows him to wait while the request is pending.
Lukas
--------------------------
**Version**: unspecified
**Severity**: normal",49755,-10,Needs Triage,True
-6.023098962503491,-2.3670773936210914,-0.7388586208438497,3.7226718779924353,2.4221888013318558,0.2304913932805288,-3.0812278971477487,-2.1475635040564844,-2.198961619464027,-2.2181994520620067,0.6872513391914303,-0.5158416798551697,5.4137666567547384,1.8684847215660385,3.4316845520692736,3.3104246950805054,-0.7158586103499781,-0.5126058921347989,False,c1,1,"See the URL for a demo.
The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.
In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"".
In the VE it is shown as
1.
1.
1.
1.
1.
1.
1. A
This is an edge case but it should should probably be identical in any case.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",49751,-10,Needs Triage,True
4.4249985183855625,-4.312402123806649,-1.1757676649952877,1.7023398331239554,3.2961145903172553,0.7324529782215474,-1.7788856968024795,-2.2972888122514634,-1.3181246249614822,0.4585328581415844,-0.00851554128888532,-0.5870602174540734,3.2892370588141944,0.6650009431035704,-1.1890580575229306,-1.2669459248645043,-0.7191807859800429,0.5769361088145415,False,c1,1,"**Author:** `mh87`
**Description:**
I tried to add a link to a word. The page containing this word already exsists so the Editor tells me ""Matching pages"" and lists the word.
When I click the matching word to add the Hyperlink the word says ""undefined"". After clicking ok the whole line gets deleted
MediaWiki Alpha 1.22
VisualEditor 0.1.0 (latest snapshot)
Chrome 26.0.1410.64 m
--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC",49546,-10,Needs Triage,True
-0.6547876280394571,1.3156516236969527,3.6303680703426764,1.897776258940878,-4.891202404867991,6.9406115067089535,4.143703693463306,-0.15373982362111224,-2.2001776044028443,1.3781658108314643,1.1486968179140997,-3.4365252444618353,-0.6438076430087492,-0.17285680943162074,-0.8585951743502456,0.3653766055920435,-1.8555192229020452,3.31178428270493,False,c1,1,"Performing small edits on pages with citations like http://en.wikipedia.org/wiki/JRuby results in a clean diff in Chrome, but produces a dirty diff when using Firefox.
--------------------------
**Version**: unspecified
**Severity**: normal",49419,-11,Needs Triage,True
-6.595875229799262,-0.8795845449751027,-2.281563319819732,0.8806806372117015,-3.4676786418964634,-8.503993637217269,5.539374123042411,2.9824384002119886,-0.15544759068351766,-0.29815266765308657,-0.5866912998535065,1.292408941585353,-0.8757157773508686,1.7395199829770114,-3.7907598465766936,2.6373141121185943,0.6414693049080322,3.4697233443499576,False,c1,1,"Cursor correctly appear and blinks in slug, but surface completely does not know about it, so when user start typing it does not convert slug into paragraph (for block level slug) or delete slug (for inline slug).
--------------------------
**Version**: unspecified
**Severity**: normal",49258,-11,Needs Triage,True
3.6088870237211688,2.189887177414473,-3.104011871445529,0.10482941047579675,-0.4074857697800267,-2.438654781584137,3.2835995831806644,-1.6299615948308852,2.2788152721146497,-0.19833310713165364,0.12147520869084572,-1.2434253306432215,-0.4358293716338473,1.3026214895063735,-0.740461916138984,-0.3057551566850992,0.8513702355209019,2.0585445324688383,False,c1,1,"Currently we can't use the UnicodeJS.wordbreak library to emulate word skipping (ctrl+arrow / alt+arrow) functionality as wordbreaks appear either side of whitespace and between multiple whitespaces:
|One| |Two| | |Three|
Moving forwards we expect the cursor to stop in the following positions:
One| Two| Three|
Moving backwards we expect:
|One |Two |Three
--------------------------
**Version**: unspecified
**Severity**: normal",48794,-13,Needs Triage,True
-8.10560939509855,6.888398896148061,-0.1722859532230956,1.4223599128585378,0.1380478308973494,0.8045069294995382,1.4363834316966777,-1.2720990898803808,4.776230027372511,1.0449531895844713,2.74606395775507,0.05829509542975986,1.2636782700435267,-1.0070188195018344,0.616423213355719,0.4852072552516691,-0.8277316697453071,0.8523942523889494,False,c1,1,"DM nodes should be able to handle their own children, rather than having the converter do it for them.
This means we need a .static.handlesOwnChildren flag or something similar, and a way for .toDataElement to recursively invoke the converter to convert a sub-DOM to a sub-linmod.
Reflecting this, CE nodes should be able to take control of the rendering of their children as well.
--------------------------
**Version**: unspecified
**Severity**: normal",48619,-14,Needs Triage,True
-2.5569509604252456,6.283453246936631,0.9268232815792565,1.0746341156193258,-4.607780537477421,2.2093263074060827,-1.6971263742973886,-0.020952793287167093,0.5676616272194738,0.6236657805910903,-2.3638888908654723,1.0724310640848917,-0.11855828375136301,-1.8339369275443689,0.9917606982252014,-1.0520012621423769,0.3868507530491605,-1.1583428943332221,False,c1,1,"Currently VisualEditor users can't touch infoboxes. It would be great to have edit access to the text fields of infoboxes.
Being able to update images would be a plus.
Modification of the infobox itself (e.g. addition of new fields) is out of scope here.
I'm filing this request in relation to
""Wikidata provides data for Wikipedia's infoboxes. The goal of this project is easy editing of the data for a given infobox on the Wikipedia, without having to go to Wikidata.""
http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#On-site_editing
By the time those Wikipedia infoboxes would be filled with Wikidata data,
""easy editing"" should be provided by VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: enhancement",48520,-15,Needs Triage,True
-7.1212842465264075,9.997581166172225,-1.4147187962086747,-5.094285619934001,-2.475698857559861,-1.3145647920555832,0.5204093347947252,-1.5317944259710181,-0.023788470467473566,0.0521291679019118,1.384496042490595,-1.461460908315209,1.3419342110672492,-0.8939080988277244,-0.32599779055562284,-1.0362430254568973,1.6196154813166517,0.7439274518431154,False,c1,1,"So Molly and I are at LibrePlanet talking about bug 37933.
We decided that while Wikitext --> HTML --> LaTeX is possible, it's not terribly useful and doesn't really take advantage of the structure of Parsoid - we see it as adding an extra stage to the parse, which will potentially add to the time the parse takes, as opposed to having a generalized token stream and only starting to convert to a format after the token stream is actually ready.
Obviously this means a few of big things, potentially:
1. The DOM post processor needs to either run before the HTML5 tree builder, on tokens or some other structure, or it needs to be emulated for each format. I'm leaning towards the former, because if we're going to export to multiple formats it would make more sense to have one file for each format that builds the export from a token structure, rather than two files each, which build the export and do the postprocessing.
2. Because we aren't actually dealing with HTML, necessarily, in the end, we shouldn't be talking about tokens with HTML-specific tag names. Probably we could just use canonical Parsoid-specific names - something like http://www.mediawiki.org/wiki/Parsoid/RDFa_vocabulary - or maybe something similar to the *_NODE attributes in DOM nodes, with a mapper to some canonical integer values that are defined in the base Token class.
Footnote: As I was thinking about this and trying to come up with how I wanted it to look, I realized that the problem was that I was looking at it as wanting to convert between WT and either LaTeX or HTML, but if we wound up following our long term plan, ""LaTeX export"" would also require HTML-to-LaTeX, because HTML would be our storage mechanism. So I think it might be better to rewrite each bit of our system to convert each format to and from a canonical internal representation, rather than to and from any one other format.
I'm posting here because I want thoughts and feedback. It should be noted that bug 37934 would also benefit from any of the work we did on the generalisation problem - and we could probably open a tracking bug to figure out all of these things more generally.
--------------------------
**Version**: unspecified
**Severity**: normal",48516,-15,Needs Triage,True
0.5765322570481501,-2.9578261804266734,1.275310502923201,0.5472271304551384,3.190717999604421,4.0683788542925505,-7.129940891139569,0.7046547100704781,2.4615025795522483,-0.23462888713244467,0.9422712695173128,0.21682293093062865,2.056558420285414,1.066974826871629,0.4488370813996374,-0.24644509070309695,0.876663442900701,2.651673912389251,False,c1,1,"Steps:
1) Go to http://en.wikipedia.org/wiki/Jean_Nicolas
2) Click VisualEditor
3) Without moving the cursor or anything, enter the following character: a
4) Click ""Review and save""
5) The whole content of the article has been replaced with just the character.
--------------------------
**Version**: unspecified
**Severity**: major",48506,-15,Needs Triage,True
-2.084565741485819,2.0016292633933404,1.76309830036654,-0.6178777440610581,-4.233672091672972,2.269982500619263,-3.772102444511835,0.5942188702460474,0.38650634309068177,-1.2963806070154664,2.990429255319412,1.473340958671425,3.507371919141293,3.9736505660725765,0.07984468159772451,-0.7393574690282345,0.2559689803319709,-0.6427188263118675,False,c1,1,"Steps:
1) Go to http://en.wikipedia.org/wiki/Nicolas
2) Click VisualEditor
3) Left-click any link
4) A small popup with only one item appears, click on it
5) Click outside of the popup, for instance on a blank area of the article behind
6) Link has disappeared
Step 5 is what many users do to cancel.
--------------------------
**Version**: unspecified
**Severity**: major",48505,-15,Needs Triage,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",48320,-15,Needs Triage,True
-5.9484797006323635,2.625905801318158,-0.9425122482274766,-0.24299878731570934,-1.0870352562471295,0.6468736794273569,-0.9838496396971692,-3.8972020774998763,2.8228822600762147,0.5736980122427671,0.44838088615801874,1.2992824844717805,0.8149534205213795,-0.11275879951697831,-1.4934613485191734,0.07552232006343124,-0.3993679417558862,-0.23495694558736413,False,c1,1,"We have a job that sanity-checks our API server, which is a primary part of our ability to communicate with the VisualEditor. It fails because the process forks off several workers to handle requests, which sets off big red blinking alarms in Jenkins.
Do we need to add in an option to not fork? Do we need to add in some other method of doing this (like a ""start a background process"" Jenkins builder)? Or can we work around the file descriptor issue?
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/",48296,-15,Needs Triage,True
6.443637990922133,0.8528489612025094,-1.2992598300423914,-1.225181201605817,-2.4580933520441084,5.485210804999638,-2.257549500201317,-1.9490672604757209,-1.9746531732387098,-1.8450369190783373,1.4494427720309733,-1.405441631196479,-1.689546715050703,-0.7963734204778943,-2.0058763338169965,0.15654554713666569,1.53231679018827,2.2697704743898424,False,c1,1,"Screenshot of {{disambiguation}} on [[Loco]] at en.wikipedia.org
Using {{disambiguation}} on a page and editing it with VisualEditor shows an incorrect rendering.
Attached are screenshots and dumps of the active DOM for the PHP parser and Parsoid/VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10462}",47341,-19,Needs Triage,True
-4.631429342789147,2.4948775133098025,0.7487028036880474,5.612420487456683,-0.8817961975547057,-1.2860823403328916,-0.3955451701393802,2.8336485203806157,-1.8771753241625782,2.881764919763757,-3.7796551424328593,-0.12520003344260866,-1.568969114223803,-0.6740439231147759,0.4779893590807882,1.9182152877608203,0.7882928497310846,-2.1217511022276256,False,c1,1,"See http://parsoid.wmflabs.org/_rt/mw/VisualEditor/Node_types for example. (This URL currently doesn't work because the /mw prefix disappeared in a recent change.)
* border=""1"" is normalized to border=1, but only in the table's attributes, not in the rows' attributes
* | rowspan=""3"" is normalized to |rowspan=""3""
--------------------------
**Version**: unspecified
**Severity**: normal",47024,-20,Needs Triage,True
19.530375435038906,5.283906862066566,-6.992436166536802,1.8355893159625483,-0.5530649169662963,0.2352590579566871,-1.8825225299979218,0.2616471299219517,1.0808250320030084,-1.5134059318063238,-0.6734108767564551,-1.4065795760538284,0.791100458435996,-0.508186262872182,-1.5841022634221953,-0.4570849931584745,-0.029007990255187854,-0.7031787821884423,False,c1,1,"Send a POST request with any content at all to a Parsoid URL containing a colon, and you'll get strange crashes. Strangely, the behavior differs between localhost and enwiki:
POST /localhost/VisualEditor%3AMetastuff HTTP/1.0
Host: localhost:8000
Content-Length: 3
HTTP/1.1 500 Internal Server Error
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 66
Connection: close
ParserError: Failed to parse the JSON response for Page Fetch null
(Note that I didn't even get a chance to send the POST body, the 500 occurs as soon as I send the double newline that terminates the request header.)
For this case, the Parsoid log shows:
ParserError: Failed to parse the JSON response for Page Fetch null
worker 10132 died, restarting.
POST /en/Talk%3AWQKO HTTP/1.0
Host: localhost:8000
Content-Length: 3
Foo
[Parsoid closes the connection without sending anything]
Parsoid log:
There was an error in the HTML5 parser! Sending it back to the editor.
Error: No source to parse
at EventEmitter.parse (/var/lib/parsoid/Parsoid/js/node_modules/html5/lib/html5/parser.js:44:20)
at /var/lib/parsoid/Parsoid/js/api/ParserService.js:579:6
at /var/lib/parsoid/Parsoid/js/api/ParserService.js:284:4
at /var/lib/parsoid/Parsoid/js/lib/mediawiki.parser.environment.js:185:3
at [object Object].<anonymous> (/var/lib/parsoid/Parsoid/js/lib/mediawiki.parser.environment.js:209:4)
at Array.1 (/var/lib/parsoid/Parsoid/js/lib/mediawiki.ApiRequest.js:60:4)
at EventEmitter._tickCallback (node.js:192:40)
TypeError: Cannot read property 'childNodes' of undefined
at /var/lib/parsoid/Parsoid/js/api/ParserService.js:597:34
at /var/lib/parsoid/Parsoid/js/api/ParserService.js:284:4
at /var/lib/parsoid/Parsoid/js/lib/mediawiki.parser.environment.js:185:3
at [object Object].<anonymous> (/var/lib/parsoid/Parsoid/js/lib/mediawiki.parser.environment.js:209:4)
at Array.1 (/var/lib/parsoid/Parsoid/js/lib/mediawiki.ApiRequest.js:60:4)
at EventEmitter._tickCallback (node.js:192:40)
--------------------------
**Version**: unspecified
**Severity**: critical",46969,-20,Needs Triage,True
4.079099775101472,-4.096677005995316,4.314924128304185,4.848679600980938,-0.2580488132804172,-2.71895331737443,-4.176575085469543,-2.8607237997404518,0.911225296036164,-1.1100015597545925,4.038236238916065,0.503696372412904,-3.9178469920855337,-1.6103109832418792,1.0083242768021279,-1.4301294066153414,-0.799116782389433,0.3890692165501679,False,c1,1,"**Author:** `phil`
**Description:**
I created a page using the normal editor that was
<gallery>
File:Example.jpg|Caption1
#REDIRECT [[Target page name]]
</gallery>
Trying to load this page in VE gives an error message
"" Error loading data from server: Server error. Would you like to retry? ""
--------------------------
**Version**: unspecified
**Severity**: normal",46927,-20,Needs Triage,True
-4.185432178098607,-0.8032735662862986,-3.339302058097209,-2.9296472928439,1.4200720017202761,-0.8987744103507181,-0.05088627689389025,-2.6923690856871416,-2.7218845774682574,0.24273436982960206,-1.0731688486164377,0.9353355422498064,1.0144122989004294,-0.6327313881088941,-1.4114228569824796,0.040974045791161096,0.2117459553873864,0.3715951225782794,False,c1,1,"**Author:** `mwalker`
**Description:**
On chrome 24 and firefox 18.0.2 -- rapid switching between the edit tab and the view tab will cause multiple toolbars to be displayed on both the edit tab and view tab.
I note that the page DOM becomes more and more unusable as I keep switching.
As I am switching when I still see the 'loading' indicator; I am guessing that this is caused by a non complete initialization of the editor.
--------------------------
**Version**: unspecified
**Severity**: normal",46838,-21,Needs Triage,True
2.297672386357853,2.79387397632026,-1.7210633692498636,-5.436803779126174,1.9413804761717506,4.373849420409573,1.7128773425649921,-3.2617760863846836,1.5751996188639792,-0.522114819950688,0.24835699090773877,1.2906782401536308,-0.8508747726958337,2.716854690617856,1.6590887215789003,0.5393248911923092,0.5865903631361118,1.8577005407792566,False,c1,1,"**Author:** `phil`
**Description:**
Selecting some text and applying Header 6 to it has no affect
The normal editor does not offer this option so it seems inconsistent for it to be an option in the Visual Editor
--------------------------
**Version**: unspecified
**Severity**: normal",46780,-21,Needs Triage,True
-4.239009188926306,2.264572588452623,-2.123159325487787,1.0205006140501554,6.320318384346049,-0.008209532716867196,-3.4584637875873216,-3.1108939225954315,-1.1332285508805933,1.0595748042090092,-3.076038877865785,-3.9872290596259123,0.12867922423765688,-3.3687037369428587,0.951461939662062,-1.2959902168166728,2.152788125631247,-1.224678907669747,False,c1,1,"**Author:** `phil`
**Description:**
Link includes the word 'and'
I edited the space after a link so that the word following was right next to the link. I then realised this was not what I wanted so added the space back
The preview indicated all was well with the space included but after saving the word after the link became part of the link
Example:
The text I had was
""A page about a test pilot and his job""
'test pilot' was a link
I edited the page and put the cursor before the 'a' in 'and' and pressed delete.
I then pressed Space to move the word back to its original position
Saved - the preview indicated all was well
After saving - 'and' had become part of the link
Looking at the page in the normal editor it seems the space has not been put back - the Visual Editor display indicates that it has
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11010}",46779,-21,Needs Triage,True
22.092599117736633,-1.0954087140793796,-7.334274919052476,7.500921384863455,-1.9966416678757701,-1.887265798105362,3.6972448470147308,0.5060354913624086,2.0352154168365244,2.927140595860741,-0.11643166521183712,-0.4656619464788314,-0.2833212291111078,0.20701311307773818,0.15156188162779394,-0.30655162788091384,1.2588811242222635,-0.3362291054469704,False,c1,1,"Open stand alone editor. Trigger LinkInspector with cmd/ctrl+k or LinkInspector button.
Uncaught TypeError: Cannot read property 'data' of undefined ve.ui.LinkTargetInputWidget.js:84
ve.ui.LinkTargetInputWidget.getTargetFromAnnotation ve.ui.LinkTargetInputWidget.js:84
ve.ui.LinkTargetInputWidget.setAnnotation ve.ui.LinkTargetInputWidget.js:63
ve.ui.LinkInspector.onOpen ve.ui.LinkInspector.js:95
ve.ui.Inspector.open ve.ui.Inspector.js:206
ve.ui.Context.openInspector ve.ui.Context.js:355
ve.InspectorAction.open ve.InspectorAction.js:44
ve.Surface.execute ve.Surface.js:193
ve.Surface.execute ve.Surface.js:186
ve.ce.Surface.onDocumentKeyDown ve.ce.Surface.js:330
proxy jquery.js:775
jQuery.event.dispatch jquery.js:3063
elemData.handle.eventHandle
--------------------------
**Version**: unspecified
**Severity**: normal",46686,-21,Needs Triage,True
-3.692700294979556,1.0497326441134032,-4.056298216112911,3.7212440466298116,0.6292186301261165,2.355778205261058,-1.9437487588161906,-0.7691607399543765,-1.8773895487513446,-2.337826726136382,0.8970305019537581,-2.341146234006044,-0.6284663779784188,-0.40335762478382087,-3.114430668392796,0.7611366491428782,-0.25581902868909356,-0.3041841278355706,False,c1,1,"nowiki tags
edit a line in VE such that it starts with a space
VE unexpectedly inserts <nowiki> tags on the text of the line
edit a line in VE such that it starts with a text, and add bold or italic to the middle of the line somewhere
VE inserts <nowiki> tags up to the formatted character and leaves the rest of the line alone
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10444}",46478,-22,Needs Triage,True
3.4444345448727653,-7.239174516927254,-2.808253631804554,2.7351509592455963,-0.5424070579048357,-4.2281330301542654,-4.6581496786333,-1.9601664912590637,-1.377665038845833,2.4204040734384584,-2.0293311732739197,-0.17105665652505908,0.7146895404105953,-0.22579259184599287,-0.8755874754052559,-0.6015729603114672,0.4891515806433804,-0.5276579008866651,False,c1,1,"**Author:** `mail`
**Description:**
Hi,
when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:
{""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}
My config is as following:
require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");
define( 'NS_VISUALEDITOR', 2500 );
define( 'NS_VISUALEDITOR_TALK', 2501 );
$wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor';
$wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk';
$wgVisualEditorNamespaces = array( NS_MAIN );
$wgVisualEditorNamespaces = array();
$wgVisualEditorNamespaces[] = NS_VISUALEDITOR;
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgHiddenPrefs[] = 'visualeditor-enable';
$wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/';
I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",46313,-23,Needs Triage,True
-5.98159710706072,2.678058360218877,-3.432643516420942,-2.2754539892198853,-0.727763525021374,0.2745871039188985,-1.1379520198119204,1.5431527549096877,2.102651548422778,2.181317585695827,-1.0635595414120513,-2.5182412687590796,0.18354242148613853,-1.2068112163397178,0.5290846524103019,-1.0181547117737795,-0.5117216469212417,0.48869818308872914,False,c1,1,"Just very recently I started to work with semantic wikis intensely which use the Vector skin as a standard and where it does not make sense to switch back to MonoBook.
Having said this, I would like to suggest that the ""Refresh"" tab (purge) of the action menu at the top of a page is not collapsed with miscellaneous other tabs but always displayed expanded between the ""Edit"" and ""View history"" tabs.
Especially for beginners it would be very helpful to make them aware of the possible need to refresh a page.
--------------------------
**Version**: unspecified
**Severity**: enhancement",45925,-25,Needs Triage,False
-6.852656726361139,0.8518910635295587,1.9758441892440537,0.7660245222105206,4.262768831269286,6.743264639103541,1.6293430151000985,0.6932352230508001,-1.1514732025064702,0.9222297423300025,2.4383277713943676,1.4568933802690933,1.6902894339224859,1.1094456829417236,-1.0678006488266316,0.16418786253359266,-0.7084790110689357,0.4752746887891457,False,c1,1,"The link inspector currently depends on a function which decides whether a target is an internal or external link, making it impossible to link to a new or existing page named like a URL.
This is related to bug 43063.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43063",45841,-25,Needs Triage,True
8.747367525412121,-3.425341218774026,3.148774753520591,-1.1343160468716527,0.5787206924476935,-1.5483716922036792,-1.5295552006415818,-3.002063037542607,1.753318735290723,3.6430727413074706,-0.13578250145863668,2.3427541977441857,1.1184371249686036,-0.8228470539981769,-0.5794473446019515,-0.09078852689234829,1.5923595788867024,2.7201009230796256,False,c1,1,"**Author:** `Coiby.Xu`
**Description:**
I'm testing VE and meet such error: ""Error loading data from server: Server error. Would you like to retry"". And the output of Parsoid says: ""non-200 response: 404 undefined"". According to http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2012_12#Error_loading_data_from_server:_Server_error._Would_you_like_to_retry.3F_2, the bug should have be fixed.
P.S. I'm using latest VE and Parsoid.
--------------------------
**Version**: unspecified
**Severity**: critical
**OS**: Linux",45566,-26,Needs Triage,True
-6.325120637178852,-1.4544250014563413,-3.5382355002912576,2.376664209534198,5.748249463009666,1.9945642912582005,-1.3789706085072604,0.20370938462120064,-2.314479875805116,2.4334714606659142,-1.7438746186870693,-0.38051697473892643,0.6724466098486062,0.8757933963329885,-0.9394604395149511,1.3680344881926658,-3.0244750118705346,0.8623323984591769,False,c1,1,"The VisualEditor toolbar has a section for ""notices"" between the ""Leave feedback"" and ""Cancel"" buttons. This includes the ""You are using an alpha version of the VisualEditor. It may be slow and make erroneous changes - please check each edit that you make."" notice, as well as a relevant edit notice where one exists, separated by a gray line. However, when there is no edit notice, the section still says ""2 notices"" and places an empty div resulting in a gray line at the bottom.
--------------------------
**Version**: unspecified
**Severity**: normal",45460,-27,Needs Triage,True
-7.702279272305203,3.503935801160285,-3.236400406990624,-0.6207320783825037,1.8196394112288572,-2.1557471916797164,-2.6648119702262747,-0.16313867473026158,-2.2152724205316483,-0.5469233325631304,2.818771065932229,0.35250023891491056,-2.1816358630143995,0.04761277501230943,-0.08428751058125616,-0.679951254394906,-0.1532372672983333,-1.7859696491456372,False,c1,1,"In investigating bug 43089, we found that removing a link trail (i.e. [[Link]]s --> [[Link]]) is impossible in the VisualEditor. This is a Parsoid bug, can be reproduced with this command:
echo ""[[Link]]s"" | node parse.js | sed 's/Links/blah/;' | node parse.js --html2wt
This is a further result of our steadfast approach of ""if the tests aren't broken, it's working"" -- we didn't consider changes for a long time, and now that changes are possible, our hacks for roundtripping don't always work....
Suggested solution:
1. First try to find the initial link text (sans trail) in the current link text. If it's there, the new trail is whatever is left.
2. If that failed, try to find the old trail in the current text with a regex like /s$/. If you find it, emit it.
3. If both of those fail, don't emit a link trail. The trail has been modified enough that it's probably just within the text of the link now, and we won't lose meaning by just using the [[link|text]] syntax.
--------------------------
**Version**: unspecified
**Severity**: normal",45429,-27,Needs Triage,True
7.603954320769148,-2.0570499498474906,1.4201912907779715,-0.01602708813482412,-0.34794661560409745,-2.0280002638446737,1.7804526931356124,-5.032799431914605,0.6753822512551008,-0.7074065991527787,0.09370764110360952,-0.555440641033405,1.0398298523585976,1.3647746404672318,0.6851199764058746,-0.3717876647258682,0.8858387558637533,0.38578657923480475,False,c1,1,"**Author:** `aderumier`
**Description:**
Hello,
I'm trying VisualEditor, last git version (21 december), and I got an error 500 on POST /api.php, when I try to edit/create a page with visualeditor
php-fpm error log give me
Call to undefined method Title::getEditNotices() in extensions/VisualEditor/ApiVisualEditor.php
Any idea ?
--------------------------
**Version**: unspecified
**Severity**: normal",45323,-28,Needs Triage,True
1.5839242501307793,-9.125782351238525,1.22411188591186,8.339177931784734,-4.462350607119676,-2.242786872664838,4.149370402554934,-0.5805621374261152,2.5804212315167883,1.1524222458620512,1.1299047701407194,0.4277196676491013,0.49345816856454094,-1.0734377787789207,-0.7825516965620372,-0.3938386761660535,-0.11667406254496715,-0.7481598180550293,False,c1,1,"https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/VisualEditor.git;a=blob;f=modules/ve/ui/tools/buttons/ve.ui.OutdentButtonTool.js;h=ccb5e6cfbf8edc3b5f8326941fe50db8417dd85e;hb=HEAD#l29
Change
visualeditor-outdentationbutton-outdent-tooltip
to
visualeditor-indentationbutton-outdent-tooltip
--------------------------
**Version**: unspecified
**Severity**: normal",45258,-28,Needs Triage,True
17.459424479009744,-3.368817201394835,0.5966933356504356,-1.953143945607384,-2.8524248887355923,3.381753001246582,0.3614964567545087,0.31059930101584254,-0.9475429725787672,1.493578229925805,0.5869144145223628,-0.6702079369390849,-1.4896527655579428,-0.44679529336680623,-0.6707770777951012,-0.5027805018464779,-0.17138228454653626,0.21998696681757024,False,c1,1,"The reporter is missing in the IRC announcements of new issues in #mediawiki.
Observed IRC output:
(NEW) VisualEditor: Support <hiero> extension - https://bugzilla.wikimedia.org/43118 normal; VisualEditor: General; ()
(NEW) File will not change from original version - https://bugzilla.wikimedia.org/43117 normal; MediaWiki: File management; ()
(NEW) prevent update.php from updating database schemata of wgSharedTables - https://bugzilla.wikimedia.org/43116 enhancement; MediaWiki: Installer; ()
Expected IRC output: ""()"" replaced by ""(UserName)"":
(NEW) VisualEditor: Support <hiero> extension - https://bugzilla.wikimedia.org/43118 normal; VisualEditor: General; (Raimond Spekking)
(NEW) File will not change from original version - https://bugzilla.wikimedia.org/43117 normal; MediaWiki: File management; (Adam Cuerden)
(NEW) prevent update.php from updating database schemata of wgSharedTables - https://bugzilla.wikimedia.org/43116 enhancement; MediaWiki: Installer; (Gregor Hagedorn)
--------------------------
**Version**: wmf-deployment
**Severity**: normal",45119,-29,Needs Triage,True
2.780533349701732,-0.74705081968321,5.541686849944767,4.671599041656747,1.51187977734581,-0.18030355087058603,0.9204625321125395,0.8629836112948451,-1.4435819263021972,-1.9973695050011173,-1.9323651394332302,-2.6687475157476985,-0.46892426742606563,-0.8833771743296843,-2.258052649301444,1.465058780944504,-0.19181768728071047,1.3716844677383724,False,c1,1,"After enabling the VisualEditor editing interface, as usual in the Vector skin, the tab appears but then the page actually never loads for editing.
--------------------------
**Version**: unspecified
**Severity**: blocker
**OS**: Windows XP
**Platform**: PC",45078,-29,Needs Triage,True
-6.65922464184046,2.201771515257999,0.7757539085305574,4.837643611598209,5.937548392171582,1.3014930027311713,0.28100102013251593,0.5745715352174221,0.8172205564316695,-2.0221977558325084,-0.6249765610533835,0.2103458313510993,0.5817333598735637,0.3674197082652615,-1.1053913310855545,-2.2358594324846,-1.4688112484784708,0.2971040357874706,False,c1,1,"The correctness of a Wikipedia article to a great extent depends on the correctness of the link targets. Presently, Visual Editors give no Visual feedback of the target.
Enhancement 1: provide a tooltip for the target when hovering with the mouse over a link. This will be helpful for mouse-based computing devices.
Enhancement 2: Open the link editing dialogue box directly when clicking the link. Presently when clicking on existing links, only a small chain-link icon appears, which has to be clicked again to open the dialogue which shows the link target and allows editing it.
I believe the link-chain-icon step can be skipped.
--------------------------
**Version**: unspecified
**Severity**: normal",45064,-29,Needs Triage,True
-2.766241096619205,0.37028897622495904,-1.3697934381529286,4.312287080518236,5.9339200912450085,0.8025689312224256,-1.9701189942893427,-2.6123636501746215,-0.9524204560813736,4.709937623788932,-3.7772652532117688,3.450999420726607,-2.167263417844773,1.2810206715312136,0.8625692018024411,-0.795469304417354,-4.1872441232038735,-0.4201772020056429,False,c1,1,"""phantoms"" text is wrapped into a ""div class=""ve-ce-phantoms"" "" which adds a linebreak because div is a block element, see https://en.wikipedia.org/wiki/User:Raymond/nowiki
Better to use a span I think.
--------------------------
**Version**: unspecified
**Severity**: normal",45056,-29,Needs Triage,True
-3.18386305888778,-6.476793438410262,-1.9907442847072065,2.535677476366698,-0.961368013542851,1.4168810695621963,1.172129482958347,1.8548771823691719,1.2943128845357745,1.0980207380536475,2.6348088882588203,0.38819317380612883,2.536340396001061,-0.6348576500848573,-2.024340661430769,0.2614600191595996,0.3728317080096819,1.2152854685450543,False,c1,1,"Screenshot of state after escape
Steps to reproduce problem:
1. Open link editor for a link on a page
2. Enter a new page type
3. Hit Escape
Expected:
Annotation editor closes.
Actual:
ve-ui-inspector hides, ve-ui-context-menu re-appears. But ve-ui-context-frame-overlay (and thus ve-ui-suggest-select) stay visible and interactive (taking hover and clicks). Though interaction is ignored at this point (clicking a different suggestion does not affect the actual link anymore).
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10181}",45055,-29,Needs Triage,True
-9.817599641753072,2.867218530863685,2.109446963580716,5.849190590384734,-0.7612715873678355,8.499170073742684,1.5079101489908897,-1.5303189186880943,1.293781586110266,-1.1471225415853619,-1.480485098574344,-3.1194302442380444,-2.1073047603322355,1.4904902315625552,-0.9586199173961303,-2.864197730381692,-1.0972374151660942,2.7818382210520047,False,c1,1,"Pressing escape while editing a link with the suggestion tool open causes the context menu to close without ever hiding the suggestion tool in the dom.
--------------------------
**Version**: unspecified
**Severity**: normal",45051,-29,Needs Triage,True
-5.293177680084527,-0.8582557332827765,-0.19323939732869455,1.3672150533234841,4.369609463520964,1.9591611695230464,2.0588637277184896,2.534121663724016,2.9901877364118192,-2.0179683676990963,-2.4074489366007734,-2.5968086440406815,-2.7944220938006437,1.1645947320497276,1.4230906446428317,0.6649863735822013,-0.44807415159249087,-0.18659509047463807,True,c1,1,"Right now, VE grabs a hold of the edit-section links. However, for current deployment this should not be the case - they should remain pointing to the wikitext editor.
--------------------------
**Version**: unspecified
**Severity**: minor",45036,-29,Needs Triage,True
20.637480612243657,-3.8733872717509215,4.812280426478587,0.294053564719541,1.3795782940877626,-0.07103340101224731,-1.2352491019310792,1.16083000802666,3.142769423363384,5.826652787682704,-1.9257295979469409,-0.047478669970610454,-1.722396535854191,0.8287379724498862,0.42016150659141616,-0.2919256444927586,2.2074636362359756,-1.4731607909678281,False,c1,1,"Open the editor, Hit Control/Command U.
Throws Exception:
Uncaught TypeError: Cannot read property 'start' of null
--------------------------
**Version**: unspecified
**Severity**: normal",45033,-29,Needs Triage,True
3.580858376268242,-4.820637633263303,8.382667209360651,3.2873406327937618,-3.2097089563824523,3.735397963330268,2.097355256706579,-1.9042077606577634,0.3571317418233767,0.03985846232247248,-0.3376163224110118,-1.5390953659782622,-0.41444422111684176,-0.09113930785546209,-1.2781482207647352,-0.3667186504345684,0.21600640449661812,-1.8542533155562444,False,c1,1,"Seen on the VE-editing interface of https://www.mediawiki.org/wiki/VisualEditor:Test
--------------------------
**Version**: unspecified
**Severity**: normal",44983,-29,Needs Triage,True
14.729232856577937,-0.3616358013580445,-9.90316692084187,5.155658105564086,-0.8222239509261641,-1.118657440405792,0.6837466563469654,2.885208333390612,3.923556120691731,0.8983695415051818,0.6405899463612807,-0.8026387500284577,3.0085546846200946,2.206843504291653,1.03239823624003,0.003975589797109325,0.4596662028327707,-0.4675990289057499,False,c1,1,"Reproduce by create a new article with VisualEditor.
Return down about 10 lines.
Type some text, hit command+k (open link inspector)
Select an item in the dropdown. Hit enter.
Page may freeze but will eventually produce this stack error:
Uncaught TypeError: Cannot read property 'type' of undefined ve.dm.Transaction.js:214
ve.dm.Transaction.newFromAnnotation ve.dm.Transaction.js:214
ve.dm.SurfaceFragment.annotateContent ve.dm.SurfaceFragment.js:450
ve.ui.LinkInspector.onClose ve.ui.LinkInspector.js:172
ve.ui.Inspector.close ve.ui.Inspector.js:204
ve.ui.Context.closeInspector ve.ui.Context.js:341
ve.ui.Context.hide ve.ui.Context.js:255
ve.ui.Context.update ve.ui.Context.js:196
ve.ui.Context.onChange ve.ui.Context.js:86
(anonymous function) ve.EventEmitter.js:96
ve.EventEmitter.emit ve.EventEmitter.js:43
ve.dm.Surface.change ve.dm.Surface.js:278
ve.ce.Surface.onSelectionChange ve.ce.Surface.js:293
(anonymous function) ve.EventEmitter.js:96
ve.EventEmitter.emit ve.EventEmitter.js:43
ve.ce.SurfaceObserver.poll ve.ce.SurfaceObserver.js:178
ve.ce.SurfaceObserver.start ve.ce.SurfaceObserver.js:67
ve.ce.Surface.onUnlock ve.ce.Surface.js:313
(anonymous function) ve.EventEmitter.js:96
ve.EventEmitter.emit ve.EventEmitter.js:43
ve.dm.Surface.undo ve.dm.Surface.js:322
ve.HistoryAction.undo ve.HistoryAction.js:43
ve.Surface.execute ve.Surface.js:162
ve.ui.LinkInspector.onClose ve.ui.LinkInspector.js:161
ve.ui.Inspector.close ve.ui.Inspector.js:204
ve.ui.Inspector.onFormSubmit ve.ui.Inspector.js:102
proxy load.php:775
jQuery.event.dispatch load.php:3058
elemData.handle.eventHandle
--------------------------
**Version**: unspecified
**Severity**: normal",44935,-29,Needs Triage,True
-8.640792227819544,2.202643978548032,-3.565847534866238,0.45265519406688237,7.082314155756475,-2.0241252078905148,4.156761897083732,-0.6195955798108979,-0.5236644187402462,-0.46571150354749413,-0.7337022095279857,-1.4168401482544921,-2.488712642519806,3.2339032640292213,-2.476387458998111,1.204320680150519,-1.61338742740724,1.1647811939024024,False,c1,0,"When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place.
--------------------------
**Version**: unspecified
**Severity**: major",44925,-29,Needs Triage,True
7.733920331817496,-7.435287721878636,-0.3314400611812136,-6.172713451567981,-5.206432588844303,2.761045258528445,-3.495230233979269,2.515821521640677,0.4800000910179456,-1.7746034954385812,2.786840455431744,-1.3549123763107978,-2.605577160101319,-0.30209192189868794,-1.03655462963573,-1.5456111751204404,-0.2285866811375279,-0.04229773415119209,True,c1,0,"Point to [[Project:VisualEditor/Feedback]] for now.
--------------------------
**Version**: unspecified
**Severity**: normal",44920,-29,Needs Triage,True
2.7336389397386305,-8.9252112049293,-0.7677803727203383,-0.1029502840513088,1.9890374057016502,-4.832584154243492,-0.40873338977548723,6.625745790110221,3.2054934377713753,0.7718152272654661,-2.085095966579311,-0.7605981448491913,0.5359408985288376,-1.298558643505444,1.3416515458164682,0.4824546636828252,-1.5374592834943297,0.34037364599896747,True,c1,0,"Toolbar tooltips should also suggest key-commands - e.g. the bold button's tooltip should be ""Bold (Cmd+B)"". Not hard-coded but created live, though there may be i18n issues.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44012",44919,-29,Needs Triage,True
3.8703331194080266,-3.009882301715299,-8.150238042378305,-2.602369566637835,-1.1185056720560795,6.305762662507872,4.587296597981539,-0.5496927688919997,-0.1999665541946523,1.9212625519905284,2.384895102362688,-0.9363446597342038,-0.07187600063746036,0.7233313074908345,-1.9051696002700824,-0.2513250804672885,1.32745832543002,4.338642460966967,False,c1,0,"Via viewPage.pageName (mw.config wgRelevantPageName)
Creating or editing pages, the mw.notify send uses the db-variant straight from wgRelevantPageName.
Should mw.Title.textify it for proper localisation and normalisation.
--------------------------
**Version**: unspecified
**Severity**: normal",44848,-30,Needs Triage,True
-3.789597573162969,6.40488881838294,0.38124028970523227,-5.406705838679954,-1.2776015094010957,0.2619562061025036,1.6895067015216183,-1.3667922983692065,1.0176886233737823,-0.6449771899568013,0.33959557703216214,-2.721576874991735,-0.8196552494963116,1.6736772395552553,-1.1175361717664662,1.014606883134666,-2.793925399413122,-0.91478687275964,True,c1,0,"Right now we have Internet Explorer support removed because it fails to support a number of features, mostly around ContentEditable. However, as a major browser we need to find a way around these shortcomings.
--------------------------
**Version**: unspecified
**Severity**: major",44847,-30,Needs Triage,True
1.9956901323880056,-6.398101965451684,-4.160372578363397,2.2979738316717113,-0.8889141004159642,4.155489528194023,2.3746002250511884,-0.2789967649615465,2.7710245018475854,5.206566599124052,1.025688654433631,-1.524578602968512,-0.9063972938188103,1.0483726243919511,0.4433628341776581,-0.11906106523379567,1.615094291851204,-0.7603618863328669,False,c1,0,"Create a link at the beginning of the document, select it and open inspector.
Uncaught TypeError: Cannot read property 'left' of undefined rangy-position.js:215
(anonymous function) rangy-position.js:215
(anonymous function) rangy-position.js:295
(anonymous function) rangy-position.js:348
ve.ce.Surface.getSelectionRect ve.ce.Surface.js:1190
.......
--------------------------
**Version**: unspecified
**Severity**: normal",44842,-30,Needs Triage,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,0,"
--------------------------
**Version**: unspecified
**Severity**: normal",44764,-30,Needs Triage,True
6.758151016533567,4.200836776130089,-0.734153165505294,0.9288989983370035,-2.9204945923466097,2.1424857062387446,-0.7200105007036912,1.6502280906608418,-2.9417858824450525,-2.0724860360754898,-1.4234629186583216,-1.0265854976835287,2.798390558540161,0.36514753545735434,-0.1375387502804708,0.8969708895254097,1.1323575554511704,0.544050870438171,False,c1,0,"The VisualEditorMessagesModule class does not implement a ::getModifiedTime() method, and the default falls back to timestamp 1 (Thu Jan 01 1970 00:00:01), which, together with the max() with global MediaWiki Epoch is stuck on Wikimedia servers on 20120908T000000Z[1].
> > mw.loader.getVersion('ext.visualEditor.specialMessages')
> < ""20120908T000000Z""
https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob;f=wmf-config/CommonSettings.php;h=8481e9b30130288b187cac5ebd7a6993320c91c4;hb=HEAD#l1347
Assigning to self, being worked on. Filing as reminder and as future reference.
--------------------------
**Version**: unspecified
**Severity**: major",44670,-30,Needs Triage,True
-1.6745966815486886,-5.595781256033259,0.44691058254185734,1.6303081260534706,-3.493439367748763,2.3464954326783385,6.3916210235970885,-0.034264865391126054,-1.5888027498494046,3.2089971577877616,4.196343691148677,0.07855622369612503,1.7495566623375982,0.4280547134356416,1.8962952662754038,1.1741516092234834,-0.7536039585977885,-0.36589230534408257,False,c1,0,"Fatal error: Call to undefined method Title::getRedirectTarget() in /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php on line 305
No stack trace currently as it seems the fatal log is empty...
--------------------------
**Version**: unspecified
**Severity**: major",44456,-31,Needs Triage,True
0.6880006731242441,-16.77717485667353,-2.4487671739013575,0.905368287175804,-1.9026730559413694,2.5148346331124616,2.1437936003688085,-1.7732465422315182,1.0157556326812116,-1.5761932512616803,-2.2708958873236584,-0.7570380256521849,-1.474278838383957,-0.2515167962054745,-0.32407117733649926,-0.2590639897163559,0.10387110459897686,-0.20078529983702453,True,c1,0,"
--------------------------
**Version**: unspecified
**Severity**: blocker",44335,-32,Needs Triage,True
1.8069215407524255,-2.9842570269163655,-2.8140298237011994,-3.315774181062526,3.4575752889574916,4.291403092531826,-4.13159729194596,0.19047255411942787,2.1811060808944047,2.9541615325540205,-2.234475214994049,-0.3996490352586547,-0.16429116555421786,-1.4330991238815294,0.45111031513722555,0.1676994981060076,2.3830956964845047,-1.4641356616314711,False,c1,0,"The tooltip on aliens (""Sorry, you can't edit this with the Visual Editor"" or whatever) should be i18ned.
--------------------------
**Version**: unspecified
**Severity**: normal",44123,-33,Needs Triage,True
-10.023104859272971,1.6688498561811365,1.0583465089304092,6.711515840570473,7.417507290765371,1.7398660526759657,2.7052151746199735,-1.8392263122828632,-2.005660378919562,0.38623771303232424,0.497727454291077,0.12383011919490494,-0.5932590017460422,-0.30386381436591403,0.10971893549745015,0.3559239192322984,-0.41755722747062207,-1.104162296239985,False,c1,0,"When editing the text of a list item, a change marker is set on the paragraph, but that paragraph has .internal.generated=='wrapper', so it's unwrapped by the data->DOM converter. This unwrapping step destroys the change marker; instead, it should be merged into the list item.
--------------------------
**Version**: unspecified
**Severity**: normal",44120,-33,Needs Triage,True
-2.212742752530125,0.9878955625692853,-2.039140840905974,-2.531608605557588,3.9343179184445565,-0.2508244169589704,-0.4097236978682721,-0.6929765631778638,-1.3650316395510225,-2.514633028374618,-0.9415450561225613,-2.2831306231431308,2.850305709636596,2.678412847474922,1.9711037265206528,-1.017776321582322,2.998575962943695,-0.3738868795932002,True,c1,0,"See https://www.mediawiki.org/w/index.php?title=VisualEditor:Templates&diff=605499&oldid=605498 - previously this was edited without incident, but now we've switched from the 19 August build to the 12 November one, it's now changing the wikitext of this table.
--------------------------
**Version**: unspecified
**Severity**: normal",44111,-33,Needs Triage,True
-0.09264297532192423,0.6013658990376385,2.6035807282272287,-2.006056795788866,6.0189881733646935,2.7971318232916023,0.40221716153323506,-2.3143650176947532,-3.0904644130423744,-0.22946904910056176,-2.4498891160466427,1.0668036495227986,-1.394111335947719,0.6181149707174001,0.46280738642299024,-3.8177847413436266,-2.099964184926854,2.9190171689743494,False,c1,3,"When saving some page using VisualEditor, ""characters left"" (e.g. 255) is under the text which comes from the Pending changes extension.
I have a picture to explain more. It's taken from the Finnish Wikipedia where is the Pending changes extension.
https://commons.wikimedia.org/wiki/File:To_explain_a_bug_with_VisualEditor_and_Pending_changes.png
--------------------------
**Version**: unspecified
**Severity**: normal",56802,13,High,False
30.0568055504147,-4.828971954354117,5.343960913245187,-3.6848450240532205,-0.468664438316124,3.3247568803857463,0.10504878637702042,-1.2578642776608029,-0.10143382872314999,-0.7281879977854313,-1.0041372919157974,-0.6719120242384241,0.4442802583701164,0.07788571422632184,0.1796069327900689,-0.3964433598162531,0.3595393917292402,0.00936169213739979,True,c1,3,"From T56721 comment 2:
> When I copy a portion of content beginning with a header, then paste it
> elsewhere in the same document, everything is retained /except/ the header.
> However, if I begin before the header (the paragraph before the header, for
> example) the header is retained.
>
> For example, copy everything from 'Start' to 'Finish' on this test page:
> https://www.mediawiki.org/wiki/VisualEditor:Test1234567
>
> Everything is retained except the H2 formatting on 'Start'. See this
> screenshot as an example too:
> http://images.wikia.com/trevortest/images/5/54/Header_is_lost.png
> {F16005520}
--------------------------
**Version**: unspecified
**Severity**: normal",56728,12,High,False
1.268646711452043,-0.978904873800527,0.7135332329351911,-2.7572504562540203,1.0269980197999098,0.6233121838640809,1.1884520916586343,2.0597300187566323,-2.7187816433670244,3.5001191843624166,-0.24141826234420805,0.8149778292543215,0.1890215952510541,-1.1179526354296523,-0.5477442999178912,-1.1256971045352613,1.8374656506678393,1.2333755485827294,False,c1,3,"Currently on MediaWiki.org, categories cannot be removed from the 'Page Settings' modal. This is true of new categories added and existing categories.
https://www.mediawiki.org/wiki/VisualEditor:Test1234567?veaction=edit
Inez says he's working on a fix now.
--------------------------
**Version**: unspecified
**Severity**: major",56727,12,High,True
0.6612299476796584,-4.7031035105320385,-2.847875516544825,-2.0815030150902625,-0.07507787885073425,1.631984376358737,-3.070885736313137,-0.24013916368972488,1.2594171476863532,-2.0448892910179572,0.4706717944265968,1.177538711891992,1.852411067615304,-0.7934349686268769,-1.4075509714566916,0.25406924178451346,-0.294695693950884,-1.3352831081453709,False,c1,3,"Comparison of content
I am on Mac OSX 10.8.5 on Firefox 24.0
Steps to reproduce:
1. Navigate to any article and open the VisualEditor (https://en.wikipedia.org/wiki/Kitten?veaction=edit)
2. Copy any selection of text that has formatting (bold, italics, link, header, references)
3. Paste the content elsewhere in the same VE document.
4. You will see that all formatting has been stripped. See the attached file.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12231}",56721,12,High,True
-2.067700069491914,0.5529954910479002,-1.8716049216133115,-0.7221733245065134,-0.9203225609094252,0.08957358671706683,-0.8489550194157411,-2.030619548697654,1.2799038306529853,-1.9932690590194029,-0.7919907653574692,-2.3387035840906765,1.5207473798228164,-1.4503486083929804,-0.5538954493104908,0.3479705612921244,0.9157872405648864,0.1862885750494334,False,c1,3,"Edit link for VE missing in automated test
Seen on mw.o and test2wiki, with examples from automated tests and manual operations, but I do not have a consistent repro.
Seems to happen more frequently for Chrome than Firefox.
The lack of an edit link causes automated tests to fail from time to time. I had thought it might be an artifact of the automation, but one of our candidates for VE QA also encountered the issue and conveniently provided a screen shot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12179}",56706,12,High,False
-9.377781824953233,5.669536083328477,-1.5372034019302472,3.8483812806844906,3.6723346473785505,-0.02094700214721623,0.08020671409098945,-1.5428529558093445,1.47929649254266,-1.9140303759603823,-0.6742668099530857,0.7875044167805618,0.3653953954412237,0.6386747932885708,-1.6119019006802664,-0.2157466800611918,0.328063054679129,0.7587077303845928,False,c1,3,"This is the root cause of bug 54335. Basically, you open the language inspector (or the link inspector, for that matter), make a change, then close the inspector by clicking elsewhere into the document (as opposed to by using the arrow or by pressing enter or escape in the link inspector's text input).
Narrated call stack:
* A mouseup event fires on the document
* ve.ce.Surface.onDocumentMouseUp() starts the observer and polls
* The observer notices that the selection has changed and emits a selectionChange event, which ends up invoking ve.ce.Surface.onSelectionChange
* onSelectionChange sets a render lock and changes the model selection
* ve.dm.Surface.change() emits a change event
* ve.ui.Context.onChange() notices that the selection changed while an inspector was visible, so it closes the inspector
* ve.ui.AnnotationInspector.onClose() saves the changes the user made to the model, by indirectly calling ve.dm.Surface.change()
* (at this point, we have a change() call stack frame nested inside another change() frame, which is always a bad sign)
* The transaction processed by onClose() annotates text, which causes an update event to be emitted
* ve.ce.ContentBranchNode.onChildUpdate() responds to this event and calls renderContents()
* renderContents() checks to see if the surface is locked for rendering; it is, so it bails and doesn't render the change
When I briefly talked to Trevor about this issue, he said something about emitting an event asynchronously. I dismissed it at the time, because it would just move both problems (having to lock to prevent the model normalizing the selection / event storms, but having to not lock to allow inspector changes to render), but now I think about it I think it has merit. We could have ve.ui.Context.onChange() asynchronously close the inspector, from a setTimeout(). That would avoid the nested change() thing, and it would allow the render lock to be lifted before the inspector is closed.
Alternatively, onSelectionChange could only lock against selection changes and still allow transactions. But the nested change() seems like a code smell anyway, the order of event handlers might get messed up for instance, and the caller would observe multiple changes from calling change() once (that's the root of the problem here).
--------------------------
**Version**: unspecified
**Severity**: normal",56675,12,High,False
-2.1924663242059226,2.438430259588248,2.836062200160736,6.835146581152328,1.4777854538478943,0.10007623628668139,-4.445909596675751,1.139345238263965,1.6984937562851934,-1.6298419281080831,4.065342805641526,-0.057325650983564014,-3.135678783349241,1.0056306066046163,0.08966798283699706,-0.22852540193943827,0.19343583677118326,-0.9236538437168158,False,c1,3,"1. Create a page with <source lang=""JavaScript"">some content here</source>
2. Edit the page in VE. Note that the <source> tag renders correctly
3. Use the alien tag inspector to edit the contents of the <source> tag
4. The <source> tag rerenders as an empty block
This is because the HTML <source> tag is self-closing and cannot have any content. This leads to strange situations like:
>>> extensionNode[0]
<source lang=""JavaScript"">whee</source>
>>> extensionNode[0].outerHTML
""<source lang=""JavaScript""></source>""
To avoid the HTML behavior for this and possibly other tag names, we should create an XML node rather than an HTML node to build the wikitext string for the preview.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57429",56577,12,High,False
4.76080089056337,-14.946584459009214,8.388734701124644,-0.050962774076839246,-0.025427352609983633,-0.833562888380206,2.129864886915665,1.0860594689369978,2.5975133578513754,0.2309314345833151,0.09363745159096082,-0.12754475942416876,-0.009232062277686914,-0.49519642564851374,-0.8081685840084987,0.16920498560275693,-0.7493017663878085,-0.8003150012828508,False,c1,3,"https://en.wikipedia.org/w/index.php?title=Daniel_Rowe_%28footballer%29&oldid=570278760&veaction=edit
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54341",56445,11,High,False
-4.13441806389671,0.43454054083212235,3.662814537209787,2.39090576812126,-3.288065888505065,-3.4222182052192682,0.7757634236080184,-3.7737845397359915,2.948685767911819,-0.86042065510863,1.2851355374921076,-0.5091329393999463,-1.1729752785136647,1.3689692925480035,0.07753845309612917,0.6927565743717202,-1.132590181057833,-1.20105130992944,False,c1,3,"**Author:** `swalling`
**Description:**
Steps to reproduce:
1. Place your cursor in page text.
2. Navigate through the text with left-right arrow keys, until you get to a reference
3. When the ref tool popup appears, you cannot move past it with arrow keys.
--------------------------
**Version**: unspecified
**Severity**: major",56443,11,High,False
-5.504558388133561,-3.6121767670542866,-1.1418177499019837,3.807770108876329,1.8848149783250072,1.275348567940897,0.3133630687768063,1.8523997897805278,-0.8408908106013787,-0.9967178936381478,0.8901804209611037,0.9363272908939748,2.0097785806772537,-1.9988549615331141,0.10669071144634934,1.7223036123887798,0.34116941894351527,-0.11772407661105522,False,c1,3,"Copy/pasting a template that existed prior to the current session only pastes, as literal text, the unformatted text output of the template. Template boxes, etc are ignored. Images are ignored unless they have alt-text, in which case the alt-text is pasted in the position the image would be if shown.
Templates added in the current editing session can be copied and pasted as expected.
Possibly this is a result of the fix to bug 49396?
To reproduce:
1. Load any page with 1 or more templates or images, e.g. https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=573844495
2. select and copy a template or image
3. Paste the somewhere else in the page.
Expected behaviour: the full template or image is pasted
Actual behaviour (templates): Only text output of the template is pasted, unformatted and unlinked.
Actual behaviour (images): Only the image caption is pasted, unformatted and unlinked.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49396",56410,11,High,False
3.2056889168729152,-12.587650482157596,-5.326792698935428,1.9656332655742386,0.5013493795994972,2.525754028718901,0.39491762403197317,-1.103529162405881,1.1475074084387091,-2.408808961253931,-0.9299347217534324,1.5617154923483965,-1.3651758111482168,1.403083606839247,0.6088794707898257,-0.6471712588927383,-0.2317940870455304,0.6390151061507103,False,c1,3,"Parsoid is flooding the global job queue.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: [see comment 9]",56406,11,High,False
0.3610913228444006,-4.559924920054096,-0.619992505562049,3.6574893817949796,6.046530554324137,-2.387283061903812,-3.486215393396379,2.115101322695665,-0.9634249721005604,1.453123037662845,1.652193125599458,-0.6188837877183377,-2.989357742762212,0.06967684527891738,-0.981976381756807,0.1276629313494753,-0.8044516792919736,0.07254749340403399,False,c1,3,"When a page has an image on the first line and the image caption contains a <center> tag or a <div align=""...""> tag (where ... is ""left"", ""right"" or ""center"">, the right half of the VE toolbar (Beta, Page settings, Cancel and Save) are not visible. Obviously this means you cannot save any edits.
Curiously, <p align=""center""> does not exhibit this problem.
Example from an article: https://en.wikipedia.org/w/index.php?title=Little_Tich&oldid=573770305
Minimal test case: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=573786703
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54642",56379,11,High,False
-4.131183247556824,-2.2787320036316068,1.3913705564304983,2.6336687789986155,-3.168263468792922,2.0079534350198367,4.276657707651814,1.7857977766766875,-0.7294155584485048,3.54376410464498,2.614204909518143,1.567198430672695,0.6024299001544913,2.1935597652342285,-3.381009277955857,-1.7828632980933232,0.5076955524370208,-2.022386580100243,False,c1,3,"Because firefox converts path attributes to absolute URLs, the hashes don't match up, so VE pastes the plain-text equivalent content (empty string).
--------------------------
**Version**: unspecified
**Severity**: normal",56377,11,High,True
-4.724081180705126,3.7548483876593686,-3.446862898017562,-1.3785848887737582,3.979812655673522,2.9533074912853694,-2.0006795248129734,0.3753690783053715,-2.108574511746286,0.3829051976223532,0.5920101754339777,0.10711870600976159,-0.6099376456765979,1.1526325214129107,-0.46883584515856036,0.9642549432660728,0.6879187912425981,0.5642584082058948,False,c1,3,"This is extremely weird, and is relatively new, and I am at a loss.
Steps to reproduce:
1. Put cursor on some word in the article.
2. Select ""More -> Language"" in the toolbar
3. Click ""Change Language"" button in the widget
4. Choose any other language (for example, ""Hebrew"")
5. Close the inspector by clicking anywhere else.
6. Notice: The word is surrounded with a language span, but it has the initial en/ltr values instead of the chosen annotation.
7. Save the article.
8. Click on ""Edit Source"" --> the language span contains the *correct* annotation (he/rtl)
Expansion on that:
1. Repeat the above through step 6.
2. Select a separate word and annotate it with some random link.
3. Inspect the original language span -- *now* it's updated!
One more weirdness:
1. Repeat above through step 6.
2. Put the cursor back on that annotation, and open the inspector
3. Observe: While the surface shows the span as en/ltr, the inspector widget shows the correct annotation (hebrew/rtl)
This happens in master and in the live mediawiki.org version.
I've spent a while tracking what is wrong with the annotations, and they seem to be correct in the inspector itself. In the ""onClose"", the annotation is the correct he/rtl one, being then sent to AnnotationInspector onClose, and then to the SurfaceFragment for execution in the fragment.annotateContent( 'set', annotation )
That annotation (the final one that's sent to the fragment) is the *correct* annotation. And yet, somewhere along the way the update stops.
I tried stepping into the code inside ve.ce.Surface onChange and the annotation remains the correct one. It then continues to ve.dm.Surface 'change' method where the annotation is still the correct one (he/rtl)
And yet somewhere it doesn't update the surface.
Link Inspector seems to work properly, though, and both link and language inspector rely on AnnotationInspector, which makes me think there is an issue with Language specifically, or that perhaps something has changed with the definition that needs to be updated in the Language inspector.
I'm not sure if the problem is in the Language Inspector (though that seems a bit odd, since the annotation remains correct throughout) or somewhere in the process of updating (and that seems weird too since *links* are working fine).
I'm at a loss. Help is appreciated!
--------------------------
**Version**: unspecified
**Severity**: normal",56335,11,High,False
-7.2031225324539205,1.2707889095561988,-2.1201550255999617,-0.4776944906224443,0.5424589842219745,2.0460053632357216,-1.3078056347736444,1.204499178035269,-2.310237121772186,-1.6548091141294314,2.6977142731999844,0.44460360320060843,-0.20583098063371352,-0.5369460544721587,-0.061931872450157854,0.004627335422633605,-0.015506024194930745,-0.10267252352969458,False,c1,3,"Following on from the reports at bug 51142 comments 5-9
In every case where the last character of a link is non-alphanumeric and any text is inserted before that character. It seems that the underscore behaves as an alphanumeric character, and that script is irrelevant. It doesn't matter if the link was added in the current editing session or not.
e.g. [[Link|Link.]] → [[Link]]<nowiki />s[[Link|.]]
but [[Links]] → [[Linkers]] (this is the expected behaviour for all situations)
See https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=573654600&oldid=573653290
If due to this a non-alphanumeric character that was previously mid-link but now becomes the last character of the link, adding any character before it triggers the bug again.
See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&diff=573655981&oldid=573654600
In VE it is easy to include trailing punctuation (particularly commas and full stops) in a link without realising it (this is a side-effect of the WYSIWYG), meaning this occurs more often than might be expected (see comments at bug 51142).
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51442",56332,11,High,True
10.72638501826209,0.7076829063124954,1.4788959949861962,-2.6077780454504476,0.06396964914426828,-4.037963675376895,-0.1517378240959042,-3.3250836576987974,0.24608914259604608,-1.1446712683527718,0.08135354709991871,-1.919967270176819,2.18863372397993,0.6874214738366522,1.1302231657606923,-1.9456286973807582,-0.6831827935359002,-0.05610451032902364,False,c1,3,"Current VisualEditor-Version:
commit c98a964d5f8495f0d16af9229abbeb0449042d1e
Merge: 3d01a5b e7aed52
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date: Wed Sep 18 01:11:46 2013 +0000
Merge ""Fix check for preformatted when stripping whitespace""
Browser: Firefox 24.0 on Windows 7 64bit
Description:
I updated my VisualEditor via git yesterday. Before that I didnt update for 4 weeks. Now when openening a page on my MediaWiki in VE-Editmode I cant assign a page category (See screenshot).
I tried to debug with Firebug: When I click on categories the following error gets fired:
TypeError: style is null
http://XYZ/load.php?debug=false&lang=de&modules=ext.visualEditor.core%2Cdata%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T072806Z&*
Line 9
--------------------------
**Version**: unspecified
**Severity**: blocker",56322,11,High,False
-5.388805708828295,-1.113745364175296,-4.0538536381827655,-2.1210968752030728,5.785039098006717,1.1384583461992677,0.8042802644508562,1.4347842627365455,-1.1878191234137228,-2.592331405730772,-1.3564299679224252,-0.5407792846457482,-0.9490671141210774,-0.34967786648740695,1.047481853772953,0.9207499757894857,-0.5927126766700451,0.37526147240705643,False,c1,3,"Steps to reproduce bug:
1. Edit a page
2. Insert a transclusion, apply changes
# The transclusion is now selected (VE does this automatically for newly inserted nodes)
3. Type a characters
# Selected content is removed, text is inserted
4. Undo
The expected result is the text being replaced with the transclusion. Instead a pawn is inserted.
Upon further inspection I noticed that the transclusion isn't lost, however. In fact it is right there when you Undo again (after getting the pawn).
So it looks like the pawn was inserted as a transaction in the middle of removing the transclusion (its own transaction but not supposed to be?) and inserting the text.
We auto-select the template after insertion and it is relatively easy to accidentally press a key afterwards. And Undo then shows the user something scary (their template appears lost). A fairly high priority bug regarding user experience.
Not sure if this is a regression or not.
--------------------------
**Version**: unspecified
**Severity**: major",56314,11,High,False
-8.432583471894427,4.888524292473509,-1.2953200660410005,-0.4871571027615632,-0.6364211847341266,-1.7350111543756639,1.2904597744894666,2.1452665295873032,-0.9505581816253694,3.0869758822914886,1.2765105676202677,-0.438852173608136,-0.09838659719966447,0.6769365976309016,1.3612927008555245,-0.6517351144912881,2.0710532599634925,0.09563302234833482,True,c1,3,"From en.wp.
John Broughton: <<So there is now a new toolbar, and - bizarrely - the icons for media, reference, reference list, and transclusion '''are no longer visible'''. They are now under the ""More"" menu.
Okay, one could argue that these four are, somehow, ''advanced'' editing options (no matter how critical they are to editing articles). But I'd love to hear from someone as to why Bold and Italic (the first in particular ''rarely'' used in articles) still have icons visible on the toolbar, while five other formatting options are now under ""More"". It really, really would have been better to have a ""Format text"" drop-down menu that had all seven text formatting options on it, and to leave the media, reference, reference list, and transclusion icons where they were, visible on the toolbar. Or, worst case, leave them under the ""More"" menu [one more click, and thus one less reason for experienced editors to use VE, because this '''makes it more cumbersome to use''' those four things]; at least then they wouldn't be paired with formatting options with which they have little in common. [...] (And don't even get me started on the ''sequence'' within the new ""More"" drop-down menu - apparently the ''least'' important choices are at the ''top'' because that's the way that ''no one else'' does drop-down menus, so obviously everyone else is wrong?!?)>>
Andrew Davidson: <<Bold formatting is not rarely used. It is used in all articles right at the beginning to emphasise the name of the topic and any synonyms. But this usage is quite specialised and subject to the conventions of our manual of style. The VE should understand this. Either the use of bold text should be handled by a style sheet/template/wizard approach to article creation. Or the appearance of the bold option in the toolbar should be context sensitive so that it only appears when editing the lead of an article and warnings appears if it seems to be used incorrectly. >>
Salix alba: <<One problem I get is the toolbar frequently splits into two lines. If my browser less than 1100 pixels then the toolbar wraps leaving lots of white space which could be usefully filled. I'd be happier either with single line with more drop downs or two full lines, just not empty space.
I guess different editors will want different things on a toolbar. Doing inline maths you would want italics, sub, and sup to be easily added plus greek symbols eiπ. Other editors will have different requirements. Tooltips would be handy to get shortcuts for each action, (no I will not read the help page). The wikitext editor's toolbar manages to make a lot of things easily accessible.>>
--------------------------
**Version**: unspecified
**Severity**: enhancement",56271,11,High,False
1.5561448135825224,8.79071048012431,1.5737313916025641,1.1461469164800966,-2.9260402372079133,-1.1322010214439364,0.7912061927458689,-2.8902345422849467,0.5436663815768364,0.4593947859683434,1.7669371068500115,-0.08890841784030523,2.5115362029656785,-2.666822646877938,0.7058452789020464,3.8371476064327856,1.7850865113281669,-1.0794759791698714,False,c1,3,"I thought there was a bug for this, but I can't find it...
Warning: Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.22wmf16/includes/context/RequestContext.php on line 281
The amount of the warnings seems to have increased a lot more in wmf16/wmf17
Such occurrences and stracktraces can be found in logstash with `_type: mediawiki` and `channel: recursion-guard`.
",56193,11,High,False
-3.3373416063582404,6.451970815205776,2.612614258846474,1.8996715675902793,-7.756260204378217,1.1121131800950896,-2.7590120156578806,2.7227486357873465,2.1383372404409924,-2.5105928927967307,-0.7302578814827632,-1.0968470323267023,0.9364738336730389,0.7954756171808937,0.7005059211323044,-1.025028157496201,0.41548984157639857,-0.3005136290393209,False,c1,3,"e.g. Template:Information could be documented at TemplateData:Information instead of inside the source code of Template:Information.
Pros:
%%%1. More standard use of ContentHandler for JSON across projects
2. Document templates without needing to make edits to templates that are potentially transcluded across large swaths of pages
3. Easier to implement custom editors for ContentHandler pages than for portions of wikitext pages.%%%
Cons:
%%%1. Would need to have two separate systems - one for the JSON storage, then another to transclude the generated documentation onto template doc pages, e.g. with <templatedata /> or {{#templatedata}} or so (no params needed, because the TemplateData namespace page can be of the same name, like a talk page)
2. Would need to rework the existing editor (sorry, mooeypoo) to work with the new system%%%
--------------------------
**See Also**: {T52512}",56140,10,High,
-1.9654390331416232,-1.5393231727879613,-3.364136238949138,0.6995116866203333,2.6089731184219027,-2.7348200095968918,-2.449120194591586,0.7256004596106668,-2.1193654215922013,-2.301357586702001,4.714213772429973,0.2291228442987412,-3.17027277551931,0.20782167740735602,-0.8439942017943824,-1.425194927144528,-0.5591691117430101,2.761650268872235,False,c1,3,"When requesting random images from Commons' MediaWiki API and requesting a thumbnail for it, I often get a HTTP 500.
For example:
GET http://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg
HTTP 500
<html><head><title>Error generating thumbnail</title></head>
<body>
<h1>Error generating thumbnail</h1>
<p>
Error creating thumbnail:
</p>
<!-- http://commons.wikimedia.org/w/thumb_handler.php/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg -->
<!-- mw1154 -->
</body>
</html>
Usually when trying again, it just works.
I've been getting these errors in many different environments:
* When reading articles and HiDPI plugin swaps the src attributes (the larger version would fail maybe)
* When opening the VisualEditor (rendering the new DOM means we re-parse the <img>tag and thus re-request it, thus making it more likely for the error to happen again)
* When working with gadgets that render image galleries through requesting file category members and the thumbnail url.
I don't think the scenario is relevant, there is either something wrong with the thumbnail generator script that is triggered by lots of images. Or there is a few faulty servers in the upload.wikimedia.org pool that cause the errors.
--------------------------
**Version**: wmf-deployment
**Severity**: critical",56045,10,High,True
-3.7075032708759608,6.048167184851049,-3.4876040345861803,-0.25038360188664843,-0.5171821796691874,-0.35842080404079213,2.571510821553354,2.0680693519401694,-1.3788259872451676,-0.9529750793252658,-0.6512823164607258,0.27041966785880844,-0.4556713826480028,0.34553552318958847,-0.07255541479942451,-0.6374809391341821,0.263292070464785,-0.06112281049459267,False,c1,3,"The VisualEditor UI has an interface to check what version is currently deployed (similar to Special:Version), when asking around people seemed to assume that this has been disabled purposely on the cluster.
However this does not seem to be true.
For one, the configuration around is working perfectly fine.
Though the HEAD commit is retreived by MediaWiki's GitInfo class without shell (it just reads from the .git/HEAD file directly), I additionally verified that $wgGitBin (used for calcuating the commit dates with `git show`) has also not been disabled in production and works fine (tested on tin.eqiad.wmnet).
The .git directory itself is not excluded from our deployment scripts. Though partial syncs using sync-dir or sync-file will naturally not sync the .git directory, when using scap or sync-dir on an extension directory, it will be updated just fine.
And, in fact, [[Special:Version]] does show a git hash (maybe not the best one, but it does show something).
It doesn't work for extensions because the git data is stored in mediawiki-core (e.g. mediawiki-core/extensions/VisualEditor/.git is a placeholder file with a pointer to mediawiki-core/.git/modules/extensions/VisualEditor), and the pointer is hardcoded to the location of the working copy on tin, namely /a/common/php-1.22wmf16, which doesn't exist on apaches.
For example:
krinkle@mw1017:/apache/common/php-1.22wmf16/extensions/VisualEditor$ git show
fatal: Not a git repository: /a/common/php-1.22wmf16/.git/modules/extensions/VisualEditor
krinkle@mw1017:/apache/common/php-1.22wmf16/extensions/VisualEditor$ cat .git
gitdir: /a/common/php-1.22wmf16/.git/modules/extensions/VisualEditor
I'm not sure whether the resemblance of /a and /apache is a coincendence or whether one is intended to be a shortcut of the other. Either way, it seems fairly trivial to make this work.
I'm not sure what the semantic meaning is of these directories (/a/ seems to be an existing but unused directory on all hosts other than tin).
Depending on whether it is really empty we should probably just create a symlink from /a to /apache on all machines that have /apache (except for tin), or if /a is used for other stuff, put symlink inside and have one from /a/common to /apache/common (except for tin).
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=36271",55972,10,High,False
-3.8311015817922875,2.2393705121701935,2.8472358601681655,1.9539116801690217,-4.734598350654592,1.9170375804927156,2.395278767484659,2.225980095222871,-2.1691295795503107,-1.4664776186731325,-1.3851692612393869,-2.888511192135195,-1.5471098250114697,2.037586461249118,-1.57362781749003,-2.248908914730717,0.8698615803645884,-0.5243990547941964,False,c1,3,"On translatewiki.net during running repoupdate script: Randomly the script bails out with
hash mismatch
key_verify failed for server_host_key
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
This happens since migration of Gerrit to the new server two days ago.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55895,9,High,False
-6.053869025166748,3.2944612324009377,-1.6696586336152652,-0.06261441926621614,-4.782224545644278,0.5204644303344268,-0.12677082442499366,-2.535373186762255,1.830458357542964,-0.7274869082666786,0.11680434761818503,0.28209559346492896,0.41406895148973666,-1.4109751070378307,-0.774153213042446,1.1191705926503417,1.2021271590798517,1.3245482439701444,False,c1,3,"The Multimedia team has come up with this framework, wrapped in an extension, for experimental features. It's part of our rollout plan to get it on test2 and mediawiki.org, so we can also start deploying extensions that use its framework.
VisualEditor, Multimedia, Mobile, and E2 are all planning on using this framework in the coming quarter to gate features they aren't ready to release on an opt-out basis.
Please review for security and performance (in particular the update jobs for user counts may be tricky for the latter) and add it to the extensions enabled on mediawiki.org and test2.
Thanks!
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Extension:BetaFeatures",55865,9,High,False
7.411899922813161,-1.1980232445668157,-6.178301968336173,-1.3190595172049615,-1.9864972669292562,-1.3066183845597836,-0.943731745404901,-0.07119615011200886,-0.12102264127198176,-0.7056788311473792,-0.7137768103494775,-0.636158730327672,1.1602405771542896,0.8237278669822015,-0.7807924785852043,-0.4066323940574579,0.12473419532100682,-0.28427157496854805,False,c1,3,"https://gerrit.wikimedia.org/r/#/c/82796/ - sha1: 8587e2e4b4f90ca9cdba0f39e647b235921a5ae8
Missing on git.wm.o, gerrit, github:
https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMassMessage.git
https://github.com/wikimedia/mediawiki-extensions-MassMessage/commits/master
km-mpb:~ km$ git clone ssh://legoktm@gerrit.wikimedia.org:29418/mediawiki/extensions/MassMessage.git
Cloning into 'MassMessage'...
[snipped]
Checking connectivity... done
km-mpb:~ km$ cd MassMessage/
km-mpb:MassMessage km$ git log --oneline
85283ca Localisation updates from http://translatewiki.net.
b9ccd1c Autocomplete suggestions for spamlist input
3027dc6 Localisation updates from http://translatewiki.net.
8d106e1 Localisation updates from http://translatewiki.net.
[snipped]
Luckily this is a pretty minor change, so I can re-do it, but it really shouldn't have disappeared in the first place...
--------------------------
**Version**: wmf-deployment
**Severity**: major",55836,9,High,True
4.022356275451195,2.9795931062703964,-1.7304810175020116,1.6768926028132132,-3.5619191559283436,-2.2218811156198077,1.3179679344510173,3.1065584971857625,1.9697553291514296,-0.4573203261479035,0.7280874684304965,1.9367319363309157,1.8761196691551274,0.7758414220861889,0.6804469249183285,-0.9898159203310748,1.3092503152841315,0.9425036371646776,False,c1,3,"*Problem Description: If for spelling correction purposes only few charecters within any word are selected and replaced with other charecter of same or lesser length, without movement of arrow keys or spacebar, save button does not get enabled, so effectively we would not be able to save the change.
**Additional details : Problem was identified when we were trying to reproduce bug 53758, intution is it may be some how indirectly related to bug 53758
*Tested Browser and OS =Firefox+Win7
**Were enabled: VisualEditor+ULS Method of input = अक्षरांतरण language=Marathi
Script=Devanagari (Non-VE source edit environ,ULS Method of input = अक्षरांतरण
works normal)
Steps to reproduce:
* Steps to reproduce:
1. Go to existing page with considerable Marathi Devnagari text may be like
https://mr.wikipedia.org/wiki/अभिमन्यु
2. Go to माझ्या पसंती (Preferences), संपादन and enable last option:
यथादृश्यसंपादक कार्यान्वित करा (केवळ मुख्य(लेख) आणि सदस्य नामविश्वात) - this
enables VisualEditor
3. Click cog next to इतर भाषांमध्ये
4. Under क्षेपन (टायपींग ईनपुट) make sure to choose अक्षरांतरण
5. Select any random marathi word from existing paragraph text
6.Make the changes in the word by changing alphabate but see that length of the word remains less after the change.
**Please note do not move arrow keys or spacebar
7 Save button does not apear
--------------------------
**Version**: unspecified
**Severity**: major",55788,9,High,False
-1.0995286935035629,15.894793651351595,5.1284020726394,5.8106569497909115,1.220928189117412,7.798959137747166,-1.4612984591948512,-0.6064782845158385,-2.7427799132350925,-1.276158195106123,0.2562628209784772,3.7211261871323167,2.4792571602671347,-0.5914350282509702,-0.9775053463779466,-3.665374089838301,1.0160186852767128,1.6224064395007518,False,c1,3,"In the mid to end 2021 timeframe, the Parsing Team is aiming to start migrating read views for Wikimedia wikis from the core parser to Parsoid.
https://www.mediawiki.org/wiki/Parsing/Parser_Unification is the wiki page for this project.
This is a tracking task for getting this done. Subtasks track the specific work for getting this done.",55784,9,High,
-1.2720232198747885,-1.564255407477365,-2.367274914313864,1.0705247799607713,-3.361604317809989,-2.029237286648135,0.4997411618369183,2.355013080344443,0.41518138787348335,-0.6933241409863342,0.9636237895322322,1.174623384856247,3.5917994622678524,0.5792021657636175,-0.583523398424588,-0.038375097265954505,0.5729066907661642,1.0791506494411374,False,c1,3,"*Problem Description:Where text is already present,Along with any of above problems, Some times edited aspect is shown in edit window but does not reflect in edit preview
**Additional Details : Probably problem arises when we insert any additional charecters or word between two existing words in a sentence.
I suppose this would be easy to reproduce screen shot & will do it soon.
* Steps to reproduce:
1. Go to existing page with considerable Marathi Devnagari text may be like
https://mr.wikipedia.org/wiki/अभिमन्यु
2. Go to माझ्या पसंती (Preferences), संपादन and enable last option:
यथादृश्यसंपादक कार्यान्वित करा (केवळ मुख्य(लेख) आणि सदस्य नामविश्वात) - this
enables VisualEditor
3. Click cog next to इतर भाषांमध्ये
4. Under क्षेपन (टायपींग ईनपुट) make sure to choose अक्षरांतरण
5. Select any random two marathi word from existing paragraph text
6. insert any additional charecters or word between two existing words in a sentence.
**Problem is not always but frequent .Tested on Win7 +Firefox
--------------------------
**Version**: unspecified
**Severity**: major",55758,9,High,False
5.437589972712615,2.1690188512557853,-1.2907543828250265,1.3851201010026308,-4.607300385684992,-0.4959955650714679,1.240823113863259,2.3680403398816368,0.5591777643758875,0.15047785679256354,1.569100772002431,0.6631960106644894,1.8903200744323252,1.388100171483507,-0.9469981050713292,-0.2650729968999186,0.5647075905223182,-0.14751998463797866,False,c1,3,"*Problem description : spell correction of any word eats up text (with continuous motion) on right side until you press spacebar
**Additional Details: The problem is quite frequent but not always.Observed specially when we give backpace and add up more charecters to the word than earlier length of of the word
* Steps to reproduce:
1. Go to existing page with considerable Marathi Devnagari text may be like https://mr.wikipedia.org/wiki/अभिमन्यु
2. Go to माझ्या पसंती (Preferences), संपादन and enable last option:
यथादृश्यसंपादक कार्यान्वित करा (केवळ मुख्य(लेख) आणि सदस्य नामविश्वात) - this
enables VisualEditor
3. Click cog next to इतर भाषांमध्ये
4. Under क्षेपन (टायपींग ईनपुट) make sure to choose अक्षरांतरण
5. Select any random marathi word from text
6. delet few charecters with backspace
7. Add few new marathi charectes to the word
8. If the problem is not observed in single effort try spell corrections again in some other words
*VisualEditor+ULS Method of input = अक्षरांतरण language=Marathi
Script=Devanagari (Non-VE source edit environ,ULS Method of input = अक्षरांतरण
works normal
*Tested Browser and OS =Firefox+Win7
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51472",55757,9,High,False
-0.7355886671544107,4.246455682086278,-0.8420281731039818,-4.405858142109121,-2.2030788034864406,-3.2658519667830204,-4.297974512993706,-0.9965923564838924,-3.043970765576449,-1.9478099471279622,2.044720791279848,-3.562434589836708,-1.4328756366925477,-1.9166677763328392,-0.05010152514605348,0.3733909101945657,1.468760223464025,0.49021903287970203,False,c1,3,"an IP editor at en.wp reports:
""At any given page, as long the edit box is selected (with the cursor blinking) pressing 'page down' or 'page up' takes you to the end of the page. Firefox 23.0, Linux Mint.""
The example page they gave was [[Jet Lee]]
Using Firefox 23 on Xubuntu linux with the monobook skin I am unable to duplicate that behaviour, but:
At [[Jet Lee]] and [[User:Thryduulf/sandbox2]]: pressing page down or page up works as expected once but then does nothing. I then click anywhere in the body and again one of them works once, and then not until I click. However, once I've viewed the end of the page it expected.
At [[User:Thryduulf/sandbox]] and [[Timbuktu]] it works as expected from the start.
At [[Nigeria]] I saw the same behaviour as at [[Jet Lee]] but when I returned to the top of the page it went back to working only once.
At [[Great Balls of Fire]] page down worked once, then didn't. I clicked and it worked as expected subsequently.
At [[Malvern Link]] I saw the same as at [[Nigeria]], but after pressing page up both page up and page down then worked as expected.
I'm struggling to see any pattern.
Bug 33047 was suggested as having potential relevance, but that was fixed in October 2012 so my gut feeling is that its unlikely.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51957
https://bugzilla.wikimedia.org/show_bug.cgi?id=50726",55750,9,High,False
1.6365988765912323,-2.7437559886719445,-6.03512907559451,0.01944299033963226,1.4696411141781471,-2.4935632256270828,0.1335210069048438,-3.3979834292403357,0.1888951949297848,-1.4848077358080847,-0.02573414605151214,-0.6519266266039465,2.3172547702204565,-1.331076448445946,0.2688078217002481,0.798470583887899,-0.10051156799047045,-0.92657489550489,False,c1,3,"My goal next week is to be able to run the VE tests in a mediawiki-vagrant instance. When I added the role, I get puppet errors. Just in case you ran into this, here's the error:
notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns: Installing ffi (1.9.0) with native extensions /usr/lib/ruby/1.9.1/rubygems/installer.rb:552:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns:
notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns: /usr/bin/ruby1.9.1 extconf.rb
notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns: Results logged to /home/vagrant/.gem/ruby/1.9.1/gems/ffi-1.9.0/ext/ffi_c/gem_make.out
and all that contains is the line
/usr/bin/ruby1.9.1 extconf.rb
There's an extconf.rb in ~/.gem/ruby/1.9.1/gems/ffi-1.9.0/ext/ffi_c , so I ran that line, it created a Makefile, I ran make, and it built something. But the next time I ran browsertests, it failed again.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55712,9,High,False
2.488989545391625,1.6211822561089662,-0.4331748814501495,-7.060579882354264,-8.27140409290306,-0.8911850869400351,-2.4058173489904653,-1.0998198677562048,4.450929471281543,-1.590312149657076,-3.28498435378099,-0.25722041919456606,-0.3908034603312549,1.1223171311696127,-1.3515564160769449,-2.4697564916801,1.759895363715292,0.8246677839597927,True,c1,3,"Similar to bug 52120 for ULS. Once we've got this running on merge, we'll want to move to running on submit (V+2 submit?), but for now…
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52120
https://bugzilla.wikimedia.org/show_bug.cgi?id=57560",55691,9,High,False
-2.5864760852790853,4.063180172301998,1.352295632219139,2.950719374044822,-1.1965558120890634,2.476028283235954,1.1570088614903522,2.520399397211674,-2.6421406757289887,-1.4726512265395888,-1.0181729295424256,-0.5027673321521103,0.7442016808244034,-4.442553085860114,-0.08995585085780888,0.20480567070849343,0.20904295358855407,4.490937520510907,False,c1,3,"When editing, clicking in the middle of or adjacent to an existing word in Latin, Hebrew, Arabic or Cyrillic scripts (others not tested) and pressing ctrl+k or clicking the link icon selects that word as the suggested sequence that is desired to be linked. When doing the same in Thai text nothing is selected by default.
--------------------------
**Version**: unspecified
**Severity**: major",55679,9,High,False
-4.57796612140176,-2.504460756605292,-4.334715183865111,-0.3927448260903157,6.887213648666787,-1.3533802515388562,-0.2130242526570747,-4.2087428912266125,0.15419187881231344,-2.0307110539236803,0.0652326853410865,-2.5765196916103266,-0.1690363968408226,-2.070242450186375,-0.053488328934097495,-1.7841317699690369,0.8049260103126599,-0.5760889805428002,False,c1,3,"I tried editing [[Fred Pittman]], including adding a comma after a link. The editor auto-added it to the link text, which wasn't what I wanted, so I selected the comma and clicked the remove-formatting button. This replaced the comma with a snowman. Woo!
I'd also say that the auto-link-addition heuristic is a little buggy if it includes commas, but that's maybe just me. :)
--------------------------
**Version**: unspecified
**Severity**: major",55642,8,High,False
-8.252709331820554,4.749440711085725,-0.6718218555172086,4.405247981790946,1.0904295963349293,4.414235624822016,-2.5619357373043194,0.3293360725898532,-0.8704132600499203,-2.054440805467811,0.74376638097845,-0.7766401577452116,0.6871607440313401,-0.34876936088239674,-1.2753190891540607,-0.2574503011441086,-1.049744519638826,-0.5654155638857112,False,c1,3,"When adding a link from scratch (without marking an existing word first) the cursor ends up being at the beginning of the new link rather than at its end -- which stops fluent typing.
Reproduce:
1. Go to an RTL wiki.
2. Go to a new sentence or new paragraph (cursor should be in an empty space)
3. Create link, followed by enter/enter to close the inspector
4. The cursor appears at the left of the word (which is the beginning in RTL) rather than the right of the word.
--------------------------
**Version**: unspecified
**Severity**: normal",55560,8,High,True
-0.4217579368486417,1.0994573464418185,1.2170591030067612,1.4861589995815172,-6.286822993942934,-4.755346612199183,4.001062219986355,-5.346982704805911,-2.68240753242409,-1.585716097605527,-0.003661630994862719,1.4165900276879417,-2.2337263672518493,-1.1853357547729586,-0.7533775303058823,-0.2863211238575435,0.9950136063749004,3.319591095489039,False,c1,3,"**Author:** `wojciech.r`
**Description:**
When I edit existing content in <source> tags, while editing it, error is shown about invalid language specified (lang=) and after saving it puts fragment of HTML code of this tag divs and entities into source of page and my code is broken.
https://www.mediawiki.org/w/index.php?title=VisualEditor:Test&oldid=773552
--------------------------
**Version**: unspecified
**Severity**: major",55543,8,High,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: normal",55507,8,High,True
5.634823697703766,0.6390861758450033,3.10110882578903,4.023373882836928,-0.9566311813444723,0.45490797856065446,1.1572159079867168,-0.09480615676367582,-0.37629285902056686,2.8956690537202574,-1.157410922094707,0.42288433581982643,-0.7493030614188507,-1.5396923653867218,0.5822438844489142,0.8670839496706978,1.6950981877127707,0.7726208060904576,False,c1,3,"For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".)
Example institution page:
http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma
Example course page:
http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013)
--------------------------
**Version**: unspecified
**Severity**: normal",55477,8,High,False
-3.9964152363493763,-0.8859754394252572,-5.87122628506129,2.2136496711504132,0.31729926926131524,-0.3450872587343983,-2.3680814194795596,1.752414328534209,-2.794862044102085,1.8046961190627533,-3.1741253211737224,-1.5068644206013742,-1.6644697993488862,-0.8496539758799262,-0.7307998948256369,-0.6376606642693798,1.91358061349764,-2.468619219452053,False,c1,3,"The final case in ve.dm.Document.getMetadataReplace() applies if insert.length > remove.length. But in this case only the 'retain' and 'insert' fields are set on the returned object. In ve.dm.Transaction.pushReplace() we only add the {retain,remove,insert}Metadata fields to the operation if the 'remove' field on the object returned from getMetadataReplace() is not undefined. So these fields won't be set correctly if insert.length > remove.length.
--------------------------
**Version**: unspecified
**Severity**: normal",55445,8,High,True
-7.182374487034453,0.41762344242452265,-5.673881481990998,-3.033516126143591,-0.8190572957924591,-0.5411733514858373,0.3995961115429303,-1.8144983585520982,-1.773248770732962,-0.9599142307042703,-1.6954218918575812,-0.7664826622226942,-0.11955339984692959,-0.5408227123607077,-1.6829061804804946,-0.5498033036527983,-0.3102552703125081,-0.840123227923445,False,c1,3,"In ve.dm.Document.getMetadataReplace(), we only merge metadata if the amount removed is larger than the amount inserted. But this could end up putting metadata in odd positions, for example if you have Foo[[Category:Bar]]BazQuux and you delete 'ooBa' and replace it with {image}xxx{/image}, then the category ends up inside the image.
We should always merge metadata when a segment is deleted, so that it appears outside any new structure added.
--------------------------
**Version**: unspecified
**Severity**: normal",55444,8,High,True
0.45115253334864347,-1.7741044059042288,-1.9967683288311076,4.716840736946262,-0.09985519055691183,-2.950269072850168,1.3271979416793167,1.4259566902532672,-3.396877474369422,-0.9824964078186582,1.0326071095073615,0.6500707348806667,1.0576287939963822,-0.2851689930303696,-1.318194267673488,-0.5288968624677378,-0.23077862978110097,-0.08723203048044192,True,c1,3,"Right now VisualEditor transforms the HTML Parsoid gives us (which is nicely-structured <figure>s) into the mess of <div>s that MediaWiki's PHP parser throws out (up?). This is so that VE's rendered HTML magically inherits the styling that the images get on the read page, which includes
Instead, we should just style these using CSS. However, this is difficult because the styles are specific to <div>s with known classes (and Parsoid's HTML has no <div>s), and is often over-ridden in wiki- or user-specific CSS (e.g. Wikia's sites' skins, or that on Cherokee Wikipedia).
From quickly playing around, a basic CSS style that implements core-MW would be something like:
figure
float: right;
border: 1px solid #CCC;
padding: 3px;
width: 172px;
background: #FAFAFA;
font-size: 13px;
margin-right: 1.2em;
img
border: 1px solid #CCC;
figcaption
padding: 3px;
font-size: smaller;
line-height: 1.4em;
width: 15em;
margin: 2px 0px;
padding-top: 0px;
--------------------------
**Version**: unspecified
**Severity**: major",55436,8,High,False
1.1067067315284116,-3.8484052276506997,-1.629779819259916,3.4403957071259414,-0.14179396929796578,-1.8746703342850453,0.9831714831417981,0.9868265177107122,0.1528419754103707,1.584864661582678,0.6978250572882949,0.8387536834706626,0.7620971901400466,-1.7866936434223364,-1.1302627935480487,0.6188514060002607,1.321979935395049,0.5106270958784298,False,c1,3,"Right now it is only intended for data about custom wiki-made templates.
To support magic words and parser functions, we'll need to make a few changes to make sure there are no conflicts or wrong assumptions.
A few random points:
* 'titles' parameter in the API module
* The PHP parser prefers native magic word over templates (creating Template:PAGENAME and using {{PAGENAME}}, will not use that template).
* Should there be an implied property 'type':
- type:template -> {{Foo}}, {{:Foo}}, {{Template:Foo}}, {{Project:Foo}}
- type:parserfunction -> {{PAGENAME}}, {{urlencode:123}}, {{#special:Watchlist}}
* parser functions don't have numerical parameters, and the first parameter is separated by colon, not by pipe. So we need a way (both in TemplateData and VisualEditor) to insert unnamed parameters without using numbers.
e.g. {{urlencode:Foo|WIKI}} is correct, but {{urlencode:Foo|1=WIKI}} or {{urlencode:1=Foo|2=WIKI}} or {{urlencode|1=Foo|2=WIKI}} is wrong.
--------------------------
**Version**: unspecified
**Severity**: normal",55413,8,High,
-1.0454071742202422,0.26479126408411346,6.210566982675498,3.5793423975043925,1.335233803995835,0.22327270099255436,-2.1694585228084287,0.6578712363456253,4.947515900861965,-1.6241264385126395,-0.29866469846973365,-0.9574015801877211,2.3348090873967418,2.7370079530945794,0.8405902887693069,-0.7840417725468831,-1.4120023065821263,0.46686963037736606,False,c1,3,"Steps to produce the error
1. Edit a page with VE
2. Cut a block of text containing a reference tag
3. Paste it somewhere else
Now try to move the cursor by arrow keys
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux",55385,8,High,False
-4.83016138561228,-2.4424433961958076,-2.380874800252517,-8.864494212880228,2.420345735759663,3.6248430183169464,3.651535988410193,-0.5595452711161379,-0.06064182598472151,1.0108123305367034,2.1448053832155964,2.9377819846828546,-0.3975539855210499,1.0714478428420025,1.5237116617335529,-0.5743696365660556,-2.8236400514110747,-0.8837945805991525,False,c1,3,"Only workaround I can think of is to create a fake hidden selection whenever a FocusableNode(s) is selected on it's own.
--------------------------
**Version**: unspecified
**Severity**: normal",55375,8,High,True
-10.38272923984905,4.420021750382915,-0.7613798715298721,1.0626686163360528,2.035156948143033,10.14279798912028,0.5587805880132333,-1.9103276952999053,1.9278184245758017,-0.8291267169388261,-0.6728577111536969,-0.2209416659757394,-2.0908174278282274,2.431612209478849,0.9814685291173912,0.20255861901386257,-1.838108515631687,-1.4045779841261252,False,c1,3,"This causes an exception to be thrown if you try to delete a content node at the end of the visible document (e.g. a reference list)
--------------------------
**Version**: unspecified
**Severity**: normal",55366,8,High,False
-2.6515085864263277,-2.7569214454967153,0.0906886182116935,0.5577750044495144,5.201974319485027,1.4144241612842465,-2.924536964662749,1.2591604740318396,0.532975036566335,-1.0978344073699322,3.3690859266907514,-0.5288011808010434,1.0609530031939354,4.550750050141648,2.7558167877684,3.940982256578214,0.7942764158058864,0.20614871904572118,False,c1,3,"1. Copy and paste an unnamed reference
2. It doesn't appear as a subitem in the ref list
3. Undo. The reference is now index 0.
--------------------------
**Version**: unspecified
**Severity**: normal",55365,8,High,True
-5.181308419085218,-7.26038903579204,-1.3150967658033625,1.8267038370465767,3.47778309125291,-3.7599652606762897,0.5239889687575268,0.2920119337139926,3.061461097515682,3.480980747526816,2.784325780195022,-1.7480619080695394,0.0659305082650441,1.5827494324324656,1.4075482998025795,3.01196677038152,-2.7701522489823485,1.3332371829716243,False,c1,3,"Select text around a content node (e.g. a reference: ""foo [1] bar"" ) and then copy paste it. Note you now have extra newlines.
--------------------------
**Version**: unspecified
**Severity**: normal",55364,8,High,True
-2.4466076500007734,-8.803216073056703,-5.588926804890065,-0.8629067002093771,5.709051507040979,-1.433481218955758,-1.920822257306213,0.5434338855731718,3.443793272615471,-1.740747356694936,5.914720950880165,-1.5429617119974193,-4.720328442667365,1.6895740701761817,0.8238141140439357,2.2741634109876876,-2.782535777033046,-0.6059505013591413,False,c1,3,"1. select a focusable node only (e.g. a reference)
2. Cut it (ctrl+x)
3. Note you now have no cursor/selection
--------------------------
**Version**: unspecified
**Severity**: normal",55362,8,High,True
-3.3769926003189465,1.9213860455914293,-1.8197806500435387,4.621651979914633,-3.8045197593548212,-2.3725816749539517,-1.8646141032600605,2.744484321918089,-2.7336987499724437,3.0564793559016765,-2.4738727809952934,-0.6497732938705101,2.7531740687732245,1.0600684470057846,0.4358000653802616,0.1805133801349771,-2.2714431995120945,1.5124109858737944,False,c1,3,"example 1
new issue as of Aug 26, seen on test2wiki
this is easily triggered by an automated browser test but can also be triggered manually:
while typing edits, click the Save page button.
click Review
Edited page and diff view contents are not the same. See screen shot examples 1 and 2.
ex 1: ""asfdaEdit"" in edited page vs ""asEdadit"" in diff view where original page has ""Edit""
ex 2: ""aaqaaaStarting"" in edited page vs ""aSqaaatarting"" in diff view where original page has ""Starting""
in at least one case, the actual saved contents of the page differs from the buffer that appears upon clicking Edit to invoke VE, see example 3
--------------------------
**Version**: unspecified
**Severity**: major
**Attached**: {F11309}",55360,8,High,True
-4.758568592874725,-3.0183628516178427,0.6631734643051566,-1.8861508365851951,6.210268805628967,3.9127291809286886,2.5834427109298064,0.3468285902040871,-1.937929899698881,1.0753791716336227,1.2715618078863034,0.1766043268492481,-0.15996164707565175,2.0452891070161794,-2.1488107530728637,-0.9953635663298361,-0.47988373161985676,-2.244505146798928,False,c1,3,"See https://pl.wikipedia.org/w/index.php?title=Wojnicz&diff=37347163&oldid=37312891 for an example - I'm not sure what the problem is, here, since that's a meaningless tag :/.
--------------------------
**Version**: unspecified
**Severity**: normal",55345,8,High,True
-3.564840302408258,0.01034789441614059,-3.100689118570866,0.597796794777075,-1.95915388138426,1.0442564480793737,-0.05109762988131905,2.064461339833403,-1.668691537369046,-0.3503258797445783,1.104452055377029,-2.0077024937341346,-0.013661959861524409,-1.1056595624798655,-1.6226279778523742,-0.411658479595839,-1.0483960826172631,-0.6844380689055458,True,c1,3,"From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE.2C_Sfn_template_within_reference.2C_Vcite_error
Adding a <ref> tag (e.g., a bibliographic citation) inside another <ref> tag with a different group (e.g., an explanatory footnote), displays as desired in VisualEditor, but when you save the page, it isn't visible because of T22707 in Cite.php
This is most likely to happen with a ref-creating template like {{sfn}}, since VisualEditor doesn't have the buttons to created nested ref tags directly.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=570036528&oldid=570035364",55303,7,High,False
-2.201606054093214,1.817822463961825,-0.21604447033499952,-3.502425423432289,6.997906520566225,-2.295990999364652,0.5817182311697398,1.3307461774872635,2.150013937950325,0.2637636701250896,-0.4097583605257258,0.12494799475038132,-0.42113903001523934,0.16042918378145288,-0.6628860327272479,-1.7105412087004042,-1.648914571599214,0.6270985358842613,False,c1,3,"The editor has the title and tooltip ""LaTeX"". This is not entirely correct. It's just the math environment subset for LaTeX that we can handle and support.
The label also conflicts with the visual symbol, which clearly communicates the Math function using the sum symbol. Remember that many people might not even know what LaTeX even is, causing further confusion.
The problem here is that we want to explain to the user that we want him to enter the math using LaTeX, because otherwise he might not understand how to enter his formula. Perhaps that is why the LaTeX label was chosen.
We should find a better way. Perhaps using a label or placeholder. ""Enter formula using AMS-LaTeX""
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43058",55251,7,High,False
-5.299707380234132,-2.464864108313611,-4.834924594875954,-0.17903369051562434,1.646206875269535,-1.43495699591678,-1.518130765460934,0.044585110313555554,-1.3896496844649986,1.147697453710589,1.099992714677542,-2.7965673111598432,-0.43149350748057635,-0.37318669318009956,-2.664951527065191,1.2554366518107094,1.5232188731299792,-0.16731585084364897,True,c1,3,"From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Bold_and_nowiki.2C_other_markup
If you add a nowiki tag by itself, the angle brackets get escaped out (&lt;nowiki&gt;, or does just plain </nowiki> work here at Bugzilla?). If you add a nowiki tag plus some wikimarkup, like an asterisk at the start of a line or bold text, it doesn't. This results in unpaired tags, sometimes functional wikimarkup, and always unexpected results.
Try this:
* You need a </nowiki> tag '''here'''.
--------------------------
**Version**: unspecified
**Severity**: normal",55228,7,High,False
-7.4927615993146475,8.63146514109005,3.646418390592711,1.074235905785831,-8.52076138625377,4.458417199961444,-0.09742216619567223,0.4539437790995188,1.365087109948543,-0.6174268775492777,-0.9011123753791592,-0.9332906184221138,0.10895362833367628,-1.3188577944892752,-0.17192080271544175,-1.2837409338885806,0.9563125731264341,-0.5044520119691163,False,c1,3,"At https://en.wikipedia.org/w/index.php?title=Churnet_Valley_Railway&diff=prev&oldid=569277862 it seems that a table ending with trailing new line syntax
|-
|}
caused pawns to be added to the article. As discussed at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569732999#Chess_pieces_still_happening this syntax, although technically wrong, will continue to be added to articles. VE and Parsoid should therefore deal with this cleanly without the addition of any pawns to the article.
--------------------------
**Version**: unspecified
**Severity**: normal",55214,7,High,False
-2.212844030087899,0.15314261310496136,-2.3028583014259016,-3.713468558094133,2.212064808866654,-6.032694559826451,1.1828037946144043,-2.237654346986952,1.4097747797776732,-0.27213556717203957,3.2605791696773614,0.44986787833595065,1.0999364929573252,1.416004372269554,-0.3171953025998313,1.1338613854752033,1.506927554523381,2.2628591408499776,True,c1,3,"<<If I edit a blank page, press on the number list or bullet list icon and then press enter, the page remains blank but I have no cursor. Then other strange things start to happen. Pressing the link icon does not seem to do anything. I can press some icons (transclusion, references, etc) and they will appear, but if I then exit it, pressing it again or any other icon does nothing. Undo works though. FF 23.0.1 Win7. --Atethnekos (Discussion, Contributions) 21:27, 21 August 2013 (UTC) >>
Same for me, on Chrome the cursor does not disappear and you can press icons more than once, but if you type a word it will be split on more lines and you won't be able to wikilink it.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",55206,7,High,False
-9.512822468503003,1.5156862187456195,-2.5010997983500722,-0.06489094586650435,6.71306678766382,0.0251248315104613,0.930227103295258,-0.6012709394923113,3.724485665594539,0.453895741263211,1.4957847351599844,-1.034307653929782,-0.015082209361062304,-0.5109578580300491,1.3996913797016797,2.2826163306568925,1.2101676785500175,-1.0172030470574442,False,c1,3,"There is no way to convert an image wrapped in a link to wikitext, so we shouldn't let a user do it. A plain image, on the other hand, can be link wrapped and we already handle this correctly.
--------------------------
**Version**: unspecified
**Severity**: normal",55151,7,High,True
-10.62835700690221,8.044115865759377,1.3776248928196182,3.7642348918170514,2.705225151763769,2.613765361625374,0.22904128190229756,-2.2956076004559525,-0.5999205526666147,1.067109511138483,0.24465874776810725,0.8339326940541236,0.2376124922677807,0.5457898306944031,-0.7477972376889461,0.14766888981898926,-0.6089266674840536,-0.5166618293414855,True,c1,3,"Implement non-linear transitions between steps. This is one of the key goals of the planned update to the API.
The idea is that each step has a callback function which decides which step to proceed to. This callback is called when an event occurs, such certain mw.hook, a user-provided event (there will be a way to tell the tour to check at a particular time), or a page change.
There can also be global transitions, which apply throughout the whole tour (for example, clicking ""edit source"" at any time may transition to the first step of the wikitext editing flow).
Simple use case:
Have a single tour with the basics of both wikitext and VisualEditor editing. When you click ""edit source"" or ""edit beta"" at any time (unlike today, you don't have to be at the beginning), it transitions to the appropriate step. You can then walk through the basic flows of the editors (as today)
More elaborate:
Your are in a detailed tour for VisualEditor. You are in the step for the references dialog. You click the template button, and it transitions to the step for adding a template. When you walk through and save that, it transitions to a step for saving the reference.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55143,7,High,False
-7.7377984966735145,4.684968944332084,-1.6710556043297213,-2.4371834663771077,0.6931923914924161,-1.034508803841644,-1.0566323681433492,-0.5660244725354537,-1.0288726996199187,1.0536491463909838,3.5459241068212477,-0.246403659493033,-1.9983771671826247,1.1409914867191517,-1.6725589014236584,-0.17207798782008366,0.5626962003756322,0.1270488349358494,False,c1,3,"This seems sporadic, and while it doesn't happen all the time, it does happen a lot, so I hope I am giving enough details to repeat this:
1. Put the cursor on an empty line without text.
2. Click the ""Bold"" button.
3. Type gibberish fast (ldkjlskdfjlkdjs lskdjf lsdkjflsdkjljsf....)
4. Witness weirdness: new characters pop up in the line underneath or in between the bits of gibberish, and if I try ""backspace"" to erase the lines even weirder stuff happen (like characters popup instead of being deleted, etc.
This doesn't happen when I typed regular language, I suspect, then, that it has to do with the speed of the insertion?
But after a single occurrence of this bug, the behavior of delete/backspace creates further bugs even if I stop typing quickly, or start new lines, etc.
--------------------------
**Version**: unspecified
**Severity**: major",55079,7,High,True
2.40151048431146,0.19253924279146695,-0.24764159854777112,-1.2262592060003725,-1.8341712673652908,2.2323922118200725,-1.9057449694868422,0.8077604810988838,0.6468002444346165,-1.9511210150152234,0.5013746797100014,-2.2295044772008854,0.9360325435646164,-0.4056216470666927,0.12643971146898103,-2.383438488990921,-0.23703164943357247,-1.0360922306613596,False,c1,3,"From WP:VE/F page (http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=567413854)
------------------------------
Following a report on frwiki, I tried a simple modification by changing a text into a wikilink. VE messed up the article by duplicating parts (not even complete parts), see [http://fr.wikipedia.org/w/index.php?title=Gen%C3%A8ve&diff=95604102&oldid=95601955 diff]. It seems to be reproducible on this article. --[[User:NicoV|NicoV]] <sup>([[:fr:Discussion Utilisateur:NicoV|Talk on frwiki]])</sup> 15:51, 6 August 2013 (UTC)
------------------------------
A cursory investigation back then revealed that this could be because of incorrect DOM fragment reuse for figures which all had about=null.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47326",55071,7,High,False
7.2902505509631474,-3.606244409373515,-2.52245859877754,-0.6338126130214377,-0.49478816873771503,0.017789103877653867,-3.526450675005398,2.4482116710032757,0.6815443673990098,3.5670155070799066,-1.1307661313449442,-0.9545877470575964,0.47773301060236806,-1.464178546081122,-2.063244825677424,-0.19983222967867265,-1.7754601769696179,1.9750742117409608,False,c1,3,"Create an empty document by deleting everything. Enable Input method (e.g. Ibus Chinese Cantonese). Start typing, e.g. ""jung"" (select ""中"") then ""gwok"" (select ""國""). The second character will overwrite the first, leaving just ""國"" instead of ""中國"".
Observed using chromium and firefox on Ubuntu. Happens with the following ibus input methods: Chinese cantonese, Chinese Pinyin, Korean, Malayalam swanalekha, Hindi inscript. Does not seem to happen with Kannada inscript.
--------------------------
**Version**: unspecified
**Severity**: normal",55064,7,High,True
-9.964954158313567,3.2832791096066742,-3.887427913507876,-5.05863136379708,2.1175906984188417,-6.954147441690459,3.457488371888439,-0.12760887133003093,0.3550706025181187,-2.1158698011565438,-0.8350698950260669,-1.912854085987974,-0.7529490717324512,0.46672109164823894,1.2404861597205104,-0.6986994966503244,-1.1042933998799715,-0.36364388489877353,False,c1,3,"Quite often we get bug reports for issues that have been recently fixed but not deployed to the smaller wikis.
It would be very useful if we had build numbers that we could access (e.g. ve.version) in the client so we could tell quickly how out of date the deployed code is before we waste time debugging an issue someone else has already fixed.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55050,7,High,True
2.5891537807607343,-8.23475726494015,4.4108226556379115,3.3740518676416755,-4.543668696214702,-1.2099740521766182,2.0790820024435535,-1.511468723666023,-1.0927930051354626,-0.873798491840641,-1.1498677194863278,1.0046646370554388,0.31220946927399007,-0.451316892474785,-3.023974872701147,-0.01464399176155684,-0.521297205034408,-1.277621368033221,False,c1,3,"Line height example
See screenshot for 1.25em vs 1.5em.
--------------------------
**Version**: unspecified
**Severity**: trivial
**Attached**: {F11545}",55045,7,High,True
0.07366188979841048,-9.80790873155663,6.671129336112781,1.7584129350840283,-1.387047154205419,5.222715869719126,3.134449345043561,-0.2661656899353896,3.039259683178509,2.6061793436754943,2.847055666261858,-0.10848159222019826,0.5763378525885532,0.5114501407011396,-0.7140343378207046,-0.031346744043912744,0.05270558366993883,-1.688374776648881,False,c1,3,"See the third example at https://www.mediawiki.org/w/index.php?title=User:Miya/VE4&oldid=762831.
--------------------------
**Version**: unspecified
**Severity**: normal",55012,6,High,True
-6.877720954429373,-0.5141358927527566,4.1162145889267485,5.237340778397635,8.234021140826497,-2.741812357151338,-0.5768983069806382,0.08545615288709602,4.389120892119906,-1.4899064561805542,1.9684423895991663,-2.4739286376945415,-2.215880976520342,1.0224573250615787,-0.29134498551474675,1.1844601138822917,1.6139907529522943,0.7943032061616344,False,c1,3,"I cannot take a screenshot ;)
* Scroll over a the toolbar
The button group outline, focused button box, and finger pointer flicker for a frame, then disappear. Now the buttons to not go <click>, and I have the arrow pointer.
--------------------------
**Version**: unspecified
**Severity**: normal",54987,6,High,False
-4.330475498032888,-2.2153165535299593,-3.691101782090948,0.1805814848787024,0.9747507320033477,1.383345720261948,-0.7899472512154784,-1.4790212832406189,0.22031854969796627,-1.1990613131306587,0.2674239770209672,-2.5875894933231285,1.3001927438210932,-3.406827629797208,-0.6966985352530584,-1.7461415341170414,0.774340314654747,0.6805596168175463,False,c1,3,"screenshot
I opened a wiki page, clicked ""Edit"", modified some stuff in the first paragraph involving links and a footnote reference. Next, I demoted my outline from Page title to Heading, lowering all subheadings as well. Said action was performed by triple-clicking each heading like, then mousing to the heading toolbar and clicking on the next level down.
I believe I was on the last heading, when some magic combination of arrow keys and actions involving the heading level toolbar (I may have cursored down and hit <return> this time) caused a total HsiT scramble. A sequence of characters of roughly equivalent length replaced the heading line I had been editing.
The damage seems to have spread elsewhere in the document. See attached screenshot.
Separate but related bugs from the same editing session have been filed, jfyi to flesh out this story ;)
--------------------------
**Version**: unspecified
**Severity**: critical
**Attached**: {F11397}",54981,6,High,True
-3.947596027271179,2.557298169197505,-3.1252794752028663,-2.641088964993828,-1.2080689593244167,-0.027705806409969114,-0.13570605051934947,0.8407073700394404,0.6075073393481971,-0.45069221324103825,0.08426662710806054,-0.47968496989484066,-1.5891559531029325,0.023416944686738717,0.430621203861957,0.21503449100561864,0.5780544186686358,-0.15749769179130602,False,c1,3,"We currently use meta tags to mark up template-affected attributes:
http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Templates_in_attributes
This turned out to be problematic for several reasons:
These meta tags can end up in foster-parentable positions for inputs like this:
<table><tr title=""{{echo|foo}}""></tr></table>
They can end up outside of an extension fragment, which makes it hard to reuse fragments. This currently blocks https://gerrit.wikimedia.org/r/#/c/65575/
We have been discussing moving this information to data-mw ever since we added that as a public interface. Subbu has sketched a possible encoding in https://gist.github.com/subbuss/6092148/raw/e153a444b6e252d9eebd690e996e28cdbb859df7/gistfile1.txt
We should work this out further in http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Templates_in_attributes
and implement the resulting spec.
An issue to consider is the interaction between template content editing (http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Template_content) and templated attributes. For simple cases like echo '[[{{echo|foo}}]]' | node parse, we currently only add mw:ExpandedAttrs/Transclusion info. For echo '<div title=""{{echo|foo}}"">{{echo|</div>}}' | node parse however we add both mw:Transclusion and mw:ExpandedAttrs/Transclusion. The templated attribute can already be edited as wikitext in the mw:Transclusion interface (data-mw.parts). We might want to omit the attribute interface here in favor of the general template-affected content interface.
Fragment reuse is another issue to consider. We currently don't reuse attribute expansions. These are relatively rare and cheap, so this might be ok for now. We should however choose a representation that makes it easy to add caching for these later.
Currently the VisualEditor completely ignores information about template-affected attributes, so no deployment coordination will be required as long as the mw:Transclusion interface does not change.
--------------------------
**Version**: unspecified
**Severity**: normal",54913,6,High,False
-0.29240239857590167,-0.7181819900753776,0.48109481556381084,-0.34170400032890247,0.04100487044077428,0.47296954796179125,-1.1522181408270402,-0.9105435799894817,-2.16009936689954,-1.2906158768618994,1.6057827449013389,0.837218780320977,-0.5008688706034023,-0.8181362138036343,-2.6037129071500003,-1.268196916521254,-0.8041671990787981,0.6021268775771567,False,c1,3,"Screenshot
On wikis with FlaggedRevs, the interface historically displays buttons in the order [edit][pending changes]. This seems logical.
Under the VE (screenshot attached) it goes [edit][pending changes][edit source]. This doesn't ;p. Restoring the previous setup (so that it would show as [edit][edit source][pending changes]) would be good.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11122}",54848,6,High,False
-4.567808071656746,4.489022298630502,-3.010209586307365,-7.731148530898291,-2.3189317035812422,-6.953986293208923,5.238196963254237,0.7415967533754554,-2.3084028338349754,-0.12324358263724822,-1.7540731418405002,-3.7110204599441055,-3.1337196687776077,1.64957693324616,0.8308488731564694,4.308938472948388,0.8936652845478308,-0.28013873179035076,False,c1,3,"Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well.
--------------------------
**Version**: unspecified
**Severity**: normal",54845,6,High,True
-6.677182091107596,-1.3892180998912096,-1.8012056521710296,3.4400276267016157,-0.03220818027185912,0.5098179693176723,-0.9716696982831055,-2.545998944507911,-0.3411818770171092,-1.094014102423047,1.9638432729986541,-0.8245823572301045,-0.9235602742029618,-0.5847960066988236,-0.545346403906354,0.5058467489124948,0.19142279632243575,1.9338727559253786,False,c1,3,"If you copy a block level element and try to paste it all the annotations (links, bold, italic etc.) are removed and it is just pasted as plain text. You need to select the whole line with the selection region going all the way to the right of the screen.
For example in
http://en.wikipedia.org/wiki/User:Salix_alba/VE_test
selecting the whole of the final paragraph and coping and pasting loses anotation.
Examining the clipboard in this case its something like
<meta charset='utf-8'><p data-parsoid ...</p><br class=""Apple-interchange-newline"">
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52770",54771,6,High,False
4.470715416185175,-14.397904205583703,9.26417180834627,0.08011800103571143,1.3710666042592805,2.677759560469494,2.5367244732174443,-0.7463079672407179,3.3963868156110903,0.9515220600646828,1.1218311495138704,1.1587902652316744,-0.1247703286469184,-0.8152202228923713,0.7256063204514636,-1.3633866504966574,0.6834852978576993,-2.014683861998276,False,c1,3,"See https://ja.wikipedia.org/w/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Frozen-mikan/sandbox&diff=48779068&oldid=48778951 which used https://ja.wikipedia.org/wiki/Template:%E3%83%AA%E3%83%B3%E3%82%AF%E4%BF%AE%E6%AD%A3%E4%BE%9D%E9%A0%BC/%E6%94%B9%E5%90%8D
--------------------------
**Version**: unspecified
**Severity**: normal",54752,6,High,False
12.494930484167304,-3.401305763275614,-4.137407310599425,0.02512784995685058,2.07001537004536,-0.41474694188734285,-3.1304950191821543,-2.8256890291527172,-1.1087120292968278,-2.741774567764949,1.896140436802542,-1.6704583125227586,5.2147585607451585,2.5215326941855194,1.4444100940893954,-0.6612759563784015,-0.4304593356189159,-0.5757902735247453,False,c1,3,"Output after saving
My setup:
MediaWiki:
1.22alpha (ffa9b0a) 19:02, 11. Aug. 2013
VisualEditor (Version 0.1.0)(0e76b1b)20:01, 11. Aug. 2013
ParsoidServer:
commit a4fec47e5201c329925967376f4106abd11178e3
Merge: fdb6e06 30315ed Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date: Fri Aug 9 02:43:12 2013 +0000
When I put in a simple Unsorted list the Parsoid Server throws an error message:
Incompatible constraints 1: LI P {a:{min: 0, max: 0}, b:{min: 1, max: 2}, min:0, max 0}
Attached you find the resulting output after I saved the page. Notice the extra Line that got added by Parsoid.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11826}",54751,6,High,True
-6.553324931753861,2.604655201262908,-2.3399233043756222,-3.4479317075060627,2.5852492707781782,4.4625697242241955,2.6141785922177965,0.8699907451493653,-0.123252725036256,-1.912908106758616,-1.6443840772585259,2.2835430231475433,-2.37627973271485,-1.4762575939281568,5.93765409998571,0.8081804749523387,-1.0114994671157502,-1.4097836093864602,False,c1,3,"It is requested to implement a keyboard shortcut for Save the edits. Ctrl+Shift+S combination will be the most suitable for this, as it is being used by the conventional editor right now.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54745,6,High,True
3.8596303795948663,-2.2792188016884865,-0.21704518613310064,1.2182760462958662,-3.76904385329334,-0.14311555843202828,1.351677336956862,-1.6342179125659162,0.7761068083382092,0.5069678202919663,1.190828365664554,-1.0887185621412951,1.7214578299214902,-2.5019577334524152,-2.0898965685901985,2.3608504537181396,2.300218419609851,2.4732672994821403,False,c1,3,"When you edit captions and input Japanese text with Japanese input method (of ことえり, the default Japanese method of Mac OS X), for example 生醤油 (kijouyu), the cursor will place itself after the first character, but it should place itself after the last (3rd) character. Tested on Firefox and OSX, but may happen in other browsers and operating systems. Thanks to Takashi Ota and Josh Lim for testing and reporting.
--------------------------
**Version**: unspecified
**Severity**: major",54716,5,High,True
7.905823626756554,-1.7266993221066418,2.307618441852579,-0.005719378757734095,-1.4013717798005243,1.5855464494573723,-0.19104653191757404,-1.539819801378798,5.898669110058509,-1.696629212976295,-2.3732739955500355,-0.2139726711262877,-2.0242753047394606,0.9517478061934606,0.5519486105804274,-0.20121123994435375,0.13686945377059612,-0.5126308300125015,False,c1,3,"The Swedish chapter would like to get Notifications enabled on their wiki at se.wikimedia.org. Please use the default settings.
Poll here: http://se.wikimedia.org/wiki/Tråd:Wikimedia:Bybrunnen/VisualEditor_och_Notifications
/Jan
CEO
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",54714,5,High,False
6.1629332847834934,-9.52594511522075,3.4699616317893636,-5.3406171581016375,-2.411294514983757,0.640648103056537,3.7102467771902026,-6.72589877629305,-0.6095960244183583,-1.6602480106175155,-2.6419008392113748,0.40027651547595244,-3.500663385007371,1.9606111048653156,-0.023661290421316927,-1.2906886751436144,0.09732403658557853,-0.2749058014567567,False,c1,3,"Because we love Mark:
http://m.mediawiki.org/wiki/Extension:BetaFeatures
--------------------------
**Version**: unspecified
**Severity**: enhancement",54686,5,High,False
-8.541442290343719,-1.3779632491042726,-5.271290132769709,0.7096936964521592,0.7547811128172917,0.8535786374869494,-0.8350094752661246,0.5987723943429973,0.11549178356960821,-2.470148860410598,-0.2904576518865625,1.7465661881389305,-0.7954784811222888,-0.9401243524584002,-0.6614683629439861,-0.89981788232554,-0.9477860990726644,-0.5266510744676538,False,c1,3,"When the list of potential articles is longer than the displayed list there is no way to see other articles without continuing to type part of the name. In some cases this isn't going to be much of a problem, but when there are lots of items that could have the same title (e.g. [[Nexus]]) it essentially requires you to know which disambiguator is used, defeating the point of the suggestions list.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54670,5,High,False
-3.061768561010205,-1.7624233268415566,0.9570106425908698,2.107167053787449,-3.2534161204822953,-2.8698355991201905,-1.230945283262587,0.3641125400425236,2.5897042782338717,1.7940410588200129,-1.8726974084633472,0.3468952267706853,-0.492900777677014,0.6364462848988888,0.42042070768891726,1.5249453563778934,-1.3368766780196368,-0.6092155174359832,False,c1,3,"Screenshot FF, vector skin, mediawiki,ca-action
[Regression]: mw-notification-area makes vector-hover-dropdown closing
----
How to reproduce:
* Be an admin at Commons or have otherwise at least 3 entries in your ca-action dropdown.
* Fire mw.notify('foo') in your js-console
* Scroll to top
* Click the message ('foo') to ""hide"" it
* Hover the ca-action arrow.
* Try to click ""protect"" (see screenshot)
As soon as your cursor is over the mw-notification-area (made visible in other screenshot), the dropdown closes.
----
Expected behaviour: Can move/protect page. Dropdown does not close out of the blue.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**Attached**: {F11622}",54659,5,High,False
12.511135003109798,0.7993712768578813,-0.44362631980457046,1.238325309307562,-0.8394065241716467,-1.8789953873645477,-5.390670322099692,-1.0356711281853777,-3.711817792239417,-1.0237864031797033,3.4324388058120854,-1.239653826337552,-0.2465065021666737,1.141695964574514,1.7856087703588432,-0.01591063760219935,2.2906973917102897,-0.9154478138624671,False,c1,3,"At http://en.wikipedia.org/wiki/Raven-Symon%C3%A9?oldid=566906720 , if you edit anything in the document, the infobox is deleted, but if you make a null edit, the infobox is retained.
This appears to be a bug in selser: if the HTML doesn't change, the wikitext doesn't change, but any small change in the HTML results in the infobox being deleted. I verified that VisualEditor isn't dirtying anything, but just to be sure I also reproduced this on the command line by just making a 1-character change to the HTML as shown below.
I think this may have something to do with the double }} closing in the infobox.
$ mkdir tmp
$ cd tmp
$ wget 'http://parsoid.wmflabs.org/en/Raven-Symon%C3%A9?oldid=566906720' -O originalHTML
$ wget 'http://en.wikipedia.org/wiki/Raven-Symon%C3%A9?oldid=566906720&action=raw' -O originalWikitext
$ cp originalHTML editedHTML
$ vi editedHTML # Change '<h2>Life and career</h2>' to '<h2>Life and careeer</h2>'
$ node parse.js --html2wt --selser --oldtextfile originalWikitext --oldhtmlfile originalHTML --inputfile editedHTML > newWikitext
$ diff -u originalWikitext newWikitext
--- /home/catrope/tmp/originalWikitext 2013-08-08 14:34:46.463998552 +0800
+++ /home/catrope/tmp/newWikitext 2013-08-08 17:04:41.596239434 +0800
@@ -1,29 +1,7 @@
{{Use mdy dates|date=June 2013}}
{{pp-move-indef}}
-{{Infobox person
-| image = Raven-Symoné 2011.jpg
-| caption = Raven-Symoné in 2011
-| birth_name = Raven-Symoné Christina Pearman
-| alias = Raven<BR>Raven-Symone
-| background = solo_singer
-| instrument = [[Singing|Vocals]], [[piano]]
-| birth_date = {{birth date and age|mf=yes|1985|12|10}}
-| birth_place = [[Atlanta]], [[Georgia (U.S. state)|Georgia]], U.S.<ref>{{cite web |url=http://movies.msn.com/celebrities/celebrity-biography/raven-symone/|title=Raven Symone:Biography on MSN |accessdate=2008-07-15 |year=2008 |publisher=[[MSN]]}}</ref>
-| genre =
-| occupation = Actress, singer, [[comedienne]], dancer, television producer, [[fashion model]]
-| years_active = 1989–present
-| label = [[MCA Records|MCA]], Crash, RayBlaze, [[Hollywood Records|Hollywood]]
-| associated_acts = [[The Cheetah Girls (band)|The Cheetah Girls]]
-| website = [http://www.myspace.com/ravensymone Raven-Symoné Myspace page]
-| module = {{Infobox musical artist|embed=yes
-| background = solo_singer
-| genre = [[Contemporary R&B|R&B]], [[pop music|pop]], [[Hip hop music|hip hop]], [[Soul music|soul]], [[dance music|dance]]
-| instrument = Vocals, [[piano]]
-| years_active = 1993–present
-}}
-}}
'''Raven-Symoné Christina Pearman'''<ref>[http://www.mlive.com/entertainment/saginaw/index.ssf/2008/08/ravensymone_steps_out_of_chara.html]</ref>, (born December 10, 1985), known professionally as '''Raven-Symoné''' (pronounced {{IPA|/ˈreɪ.vən sɪˈmoʊn/}}, as though unaccented), or simply '''Raven''', is an American actress and singer. Raven-Symoné launched her career in 1989 after appearing in ''[[The Cosby Show]]''<!-- Per http://www.imdb.com/name/nm0712368/filmoseries#tt0086687 her first episode of ""A Different World"" was Nov. 2, 1989, while her first Cosby Show episode was Sept 21, 1989. --> as Olivia. She released her debut album, ''[[Here's to New Dreams]]'' in 1993; the single, ""[[That's What Little Girls Are Made Of]]"" charted number 68 on the US ''Billboard'' [[Hot 100]].<ref>[http://www.billboard.com/song/raven-symone/that-s-what-little-girls-are-made-of/450772#/song/raven-symone/that-s-what-little-girls-are-made-of/450772 That's What Little Girls Are Made Of – Raven-Symoné]. Billboard.com. Retrieved 2012-05-19.</ref> The next album, ''[[Undeniable (Raven-Symoné album)|Undeniable]]'', was released on May 4, 1999.
Raven-Symoné appeared in several successful television series, such as ''[[The Cosby Show]]'' and ''[[Hangin' with Mr. Cooper]]'', in the late 1980s and early 1990s. From 2003 to 2007, she starred in the [[Disney Channel]] series, ''[[That's So Raven]]'' in which she played Raven Baxter, a psychic teenager who tried her best to keep her psychic powers a secret. During her time on ''That's So Raven'', Raven-Symoné released her third studio album, ''[[This Is My Time (Raven-Symoné album)|This is My Time]]'' (2004) which was her best selling solo album to date, charting at number 51 on the ''Billboard'' 200.<ref name=""billboard.com"">[{{BillboardURLbyName|artist=raven-symoné|chart=Billboard 200}} Raven-Symoné]. Billboard.com. Retrieved 2012-05-19.</ref> After a year of the end of ''That's So Raven'', she released her fourth studio album, ''[[Raven-Symoné (album)|Raven-Symoné]]'' (2008). The album peaked at number 159 on the ''Billboard'' 200. During 2003 to 2006, she participated in four soundtracks from Disney, [[RIAA certification|RIAA-certified]] double-platinum album, ''[[The Cheetah Girls (soundtrack)|The Cheetah Girls]]'' (2003), RIAA-certified gold album, ''[[That's So Raven (soundtrack)|That's So Raven]]'' (2004), ''[[That's So Raven Too!]]'' (2006) and RIAA-certified platinum album, ''[[The Cheetah Girls 2 (soundtrack)|The Cheetah Girls 2]]'' (2006). The soundtracks sold a combined 4.1 million copies in the U.S. alone. As of April 2008, Raven-Symoné has sold 314,000 albums in the United States.
@@ -32,7 +10,7 @@
In 2012, Raven-Symoné ranked number eight on ''[[VH1]]''{{'s}} ""100 Greatest Kid Stars Of All Time"" list,<ref name=""GKSAT"">[http://blog.vh1.com/2012-12-02/and-the-1-greatest-kid-star-of-all-time-is/ Greatest Kid Star Of All Time]</ref> and ranked number one on ''Loop21''{{'s}} ""10 Richest Black Actresses Under 40"" list.<ref name=""RBAU40"">[http://www.loop21.com/entertainment/10-richest-black-actresses-under-40 10 Richest Black Actresses Under 40]</ref>
-==Life and career==
+==Life and careeer==
===1985–99: Early life and career beginnings with ''The Cosby Show''===
Raven-Symoné was born in Atlanta, Georgia to Lydia (née Gaulden) and Christopher B. Pearman. Raven-Symoné is of [[African-American]] <ref>http://www.tv.com/people/raven-symone/</ref><ref>http://xfinity.comcast.net/slideshow/entertainment-aachildactors/3/</ref><ref>http://ethnicelebs.com/raven-symone</ref><ref name=""imdb"">http://www.imdb.com/name/nm0712368/bio</ref><ref>http://www.nndb.com/people/017/000103705/</ref> and [[Native Americans in the United States|Native American]] ancestry.<ref name=""imdb"" /> At age three, her family moved to [[Ossining (village), New York|Ossining, New York]] where she attended Park School.<ref name=""birthplace"">Charlotte Moore (January 25, 2004). [http://www.pe.com/lifestyles/teen/stories/PE_Fea_Teen_raven0125.a11bc.html Raven takes flight]{{dead link|date=September 2011}} PE.com.</ref><ref>[http://ftp.rootsweb.com/pub/usgenweb/la/winn/bios/sym1569.txt Rootsweb.com]{{Dead link|date=May 2010}}</ref> As an infant, she worked for Atlanta's Young Faces Inc. Modeling Agency and was featured in local print advertisements. At age two, she worked with Ford Models in New York City and appeared in ads for [[Ritz cracker]]s, [[gelatin dessert|Jell-O]], [[Fisher-Price]], and [[Cool Whip]].
--------------------------
**Version**: unspecified
**Severity**: normal",54638,5,High,True
1.7283478017124803,0.40490054246949114,-1.2910429391328897,-0.40931757204976404,-2.646652334418645,0.5285926638507512,-2.203095010658732,1.52565156520863,-0.36590496832118474,0.8883602336384868,-1.790126845038181,0.5960476442676306,1.614881584826493,-1.2308154494204606,-1.785497026034971,0.9978067756798413,1.0675633621184526,0.5753823773387727,False,c1,3,"**Author:** `sandrobt.wiki`
**Description:**
When trying to link a page with less than or equal to 3 characters, the page is often indicated as New Page in the link box. For example, try to link ""A"", ""AB"" or ""ABB"" on en.wiki (both with capital letters and in lower case, the latter being redirects).
Notice that this problem doesn't happen with CD and NBA, but it does with Cd and Nba (all these pages are redirects on en.wiki).
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50898",54596,5,High,True
-0.36914227940261624,5.146310517250274,10.857570211014078,6.606445307626493,3.0595791276305166,4.66265353894367,-0.09885496004274863,0.3781143010405029,3.204581598004781,0.4094311930828427,1.0590748324163761,-0.17606707040269098,0.36940225595523035,0.45613046537344815,-1.4488662969949644,1.360880743557888,2.4089953950954994,-1.1690938139232656,True,c1,3,"From Cryptic C62:
Load VE on any page. Click and hold the left mouse button anywhere inside the browser window. Move the mouse on top of any button in the VE toolbar. Release the left mouse button. This activates the button.
--------------------------
**Version**: unspecified
**Severity**: normal",54561,5,High,False
-9.517465016766845,9.538868180153045,0.5830497804967472,2.704216593580494,-0.4218858919054945,4.230101021647664,-1.9922989749791977,-1.5447344455937242,-0.15299220236985295,-0.5736526223422658,-2.2145601031070163,0.8998803609200443,-0.7292819830754445,0.9254676734104299,-1.2958412599678288,1.2656625441150935,-1.130018079197214,-0.9929367675252353,True,c1,3,"As an editor has pointed out on Mediawiki, the link dialog appears below the selected link. If an editor has selected text at the bottom of the visible page area, the dialog appears ""below the fold"" and the editor must scroll down to access it. Dialog should be forced to appear in the area currently visible when it is activated.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54526,4,High,False
-1.5892895415425616,0.01113912426540864,-3.7868750616967617,-7.522037331604484,-2.9699445126854367,-5.438026388983799,-2.434357076742736,-2.572818132639799,-1.6408322716711599,-0.6118644063998646,-1.4369607950747354,-3.619219957836748,-0.10254906741403325,-1.5724429714607315,0.21462395409923118,2.8886114737490742,-0.0253666106192314,-1.6788633010017064,True,c1,3,"At https://en.wikipedia.org/w/index.php?title=Indian_massacre_of_1622&oldid=564508110&veaction=edit, I can not unitalicize 'Nemattanew' (""In the spring of 1622, after a settler murdered his adviser ''[[Nemattanew]]'',"") in Firefox/Iceweasel 21. It marks it as unitalicized in the toolbar, but if you click away and click back it shows italics again.
I confirmed it wasn't related to my preferences by testing logged out (still in Firefox). However, it does work fine logged out in Chromium.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Indian_massacre_of_1622&oldid=564508110&veaction=edit",54517,4,High,False
-5.141255097177202,-2.1713638526938954,-2.0825167863615235,0.01029934002909405,4.146840993643595,-0.9141683405155212,-1.6398414097793657,0.6165548187526667,1.9029479640286218,-0.34582631860716884,-0.3530202490121619,-2.363856421641464,0.11179681822506637,-0.6796747370309211,-0.8043469519304303,-1.0203735473380926,-1.2537232026273495,-0.5560815117386129,True,c1,3,"It should go without saying, but you can't see it anymore when you scroll down, on occasion :D
A few unrelated ways to reproduce this:
1) http://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=prev&oldid=567022295 here, the removed lines triggered this bug (original reporter experienced this while creating a page with that text). Also, when VEditing the version on the left, an ""up arrow"" before the very first word.
2) http://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=567025383&oldid=567025004 that is, throw some text on an existing link, you'll lose the toolbar as well.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52433
https://bugzilla.wikimedia.org/show_bug.cgi?id=52441",54504,4,High,True
-1.853045627054759,-11.477104514179645,-5.904419095377209,1.4890808141519507,-1.5521296421461872,0.4502663403890226,-0.5598459389617245,1.5899507901700498,-1.8518712386731715,-0.6410495486440153,3.270282561146971,-0.7707337988390603,3.3072853434862086,-1.116098916733249,-0.7718913463173767,0.06919380053452773,-0.6337305588990318,-1.4800137958821478,False,c1,3,"Specifically [[Template:Football kit]] which was created in 2004 by some young genius.
The rules which cause problems are:
.ve-ce-protectedNode * {
position: relative !important;
top: 0 !important;
left: 0 !important;
bottom: 0 !important;
right: 0 !important;
...
}
in ve.ce.Node.css
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61497",54499,4,High,False
0.21528726095937412,1.337204067050072,-2.9427707239405905,-1.3599280201883224,-5.278962001602013,0.29850285514181785,-1.5494358992064905,-1.2767448667092314,-1.3621962290577314,-2.4039901951004663,-0.5384659686412578,-2.052814591587635,4.941468377078971,1.6497119967888212,0.9994418738154147,0.023363588388348566,0.5461250571509,0.5777367860937084,True,c1,3,"In the VE editing Window, VE does now not show references or only some of them on De.WP; both in editing the entire article and only the respective section:
http://de.wikipedia.org/wiki/Google#Einzelnachweise 1 out of 55
http://de.wikipedia.org/wiki/Chaim_Perelman#Einzelnachweise 0 out of 1
http://de.wikipedia.org/wiki/Seilkorb#Einzelnachweise 5 out of 15
http://de.wikipedia.org/wiki/Joan_Coromines#Fu.C3.9Fnoten 0 out of 3
Three people looked at it but it is hard to track down a pattern. Perhabs (wild ceteris paribus-guess) related to 51741?
Report:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121153367#Einzelnachweise_am_Artikelende_werden_im_VE_nicht_angezeigt
--------------------------
**Version**: unspecified
**Severity**: major",54490,4,High,True
-2.931504614608171,0.36036601341922037,1.870492553240858,0.9129059114783067,1.9245706705332304,0.4694850339056089,1.8272246005177681,0.16930252867893236,-0.25138437672377073,1.0202692961602757,0.9768235219929031,2.2279968669536157,0.3254198507131263,0.43076318975230343,-1.866133319171785,1.5990675963337597,1.9067164754021089,0.5418540380145245,False,c1,3,"Looks like we don't account for the API returning an error in ve.ce.MWTransclusionNode.prototype.generateContents. Unconditionally response.visualeditor.content is accessed.
API has a clear path both for dieUsage() and result === success.
--------------------------
**Version**: unspecified
**Severity**: normal",54483,4,High,True
-8.769234592524967,-0.5298105999350646,-3.639277563879663,-1.3481155901682451,-5.0614208539252825,1.2705893287659988,3.7974325815836343,-2.8756609691531154,0.680817118222006,1.5255793708529453,2.8081154084044306,-0.9783996045058281,1.089304828917323,-1.5227079502109069,0.8076697776396689,0.155365123978788,-0.11986308059077677,-1.156405349064525,True,c1,3,"We want to be able to treat some pairs (more than pairs?) of annotations as the same, edited in the same way:
* code / tt
* b / strong
* i / em
--------------------------
**Version**: unspecified
**Severity**: normal",54477,4,High,True
-0.822056121737408,1.187040446110787,2.224089501906363,2.084282892072122,-2.585772060132139,-2.6627565593791855,0.6546625873256069,0.11893212992278146,0.7728803567359015,-1.203325072940809,0.26764378268046496,4.919782231772035,0.17853639415074962,-2.085947610207591,0.39267768044060425,0.432370147714449,-1.771665198709907,0.5637955697553305,True,c1,3,"VE changed the edit tab selectors as part of their UI update to show it's in Beta.
Now, on English Wikipedia, with VE enabled:
* ca-edit is source editing
* ca-ve-edit is VE editing
In a blacklisted browser:
* ca-edit is source editing
* ca-ve-edit is hidden
The tours need to be adjusted accordingly.
--------------------------
**Version**: unspecified
**Severity**: major",54476,4,High,True
-1.2195008552736377,5.113253437424017,-1.3814830218895953,-0.0208900865701116,2.340446676490508,3.9670705279100904,-3.023244765890331,-0.85052773734569,2.7761892425675105,1.6396115434990186,0.49992581502149713,1.6216163182786618,1.8897442934940987,-0.39280976036270054,-1.7168469496820093,0.37148266455582685,-0.4288982945571551,1.6053448585379673,False,c1,3,"From user:PamD at en.wp:
Clicking on the ""Read the User Guide"" link (within the Beta/questionmark popup) has the effect of losing all current editing, because it opens the User Guide in the current window, without warning that it's going to do so. Imagine: half an hour's editing, find a problem, remember seeing that link and think it might offer advice, click for the popup, click to open the User Guide, and ... one very unhappy editor. I suggest that either the User Guide should open in a new tab or window, or, if this is impossible, there should be a warning ""Read the User Guide (and lose any current edits)"".
--------------------------
**Version**: unspecified
**Severity**: normal",54475,4,High,True
-6.174237040828137,-3.466008334887997,-3.9080769549605403,0.04931431790693841,6.081565424671471,1.2733460827727703,2.1683978036491274,-0.12570260866821242,-3.0302570470497043,0.7138339799642717,-0.7064556304827789,0.602467225406947,-1.9541635735405318,0.39975869846836076,0.2904164933812394,-2.2143573499219142,-2.6423186863475197,0.7409932335726277,False,c1,3,"en.wp user:Wouterstomp asks.
""When no image is found, please display a message saying so, now it looks like nothing is happening (especially [if you] missed the short busy animation of the search bar)""
The context is the image insertion dialog.
--------------------------
**Version**: unspecified
**Severity**: trivial",54463,4,High,False
-10.16099226231652,2.928298114998949,-2.170747659391143,0.879001588443576,8.386946808214443,2.4721422743541623,3.5227250705271116,-0.07366396403817918,-4.863819272320666,-1.4256234314078395,-0.5233349140207428,2.9879289664223414,-1.2501488022581189,2.1700571051970217,-2.2170097966081177,-0.6273662840301846,-0.8117893985421601,0.18141848329383126,False,c1,3,"When a user tries to inset an image or other media while they have text selected, the text is replaced by the media. This probably is not what they want and is contrary to how the transclusion editor works (inserts the template after the selected text).
--------------------------
**Version**: unspecified
**Severity**: normal",54460,4,High,True
-5.7291056921863595,-0.7040255049177713,0.3709742647788765,-2.631429871969414,-4.117356929416291,0.23198159193706203,1.7016279771406433,0.8176435067247468,0.3509721541708998,-0.51371192290034,0.16155446988731859,-3.825292532545638,0.39008110259370055,-1.6684484825036363,-0.22156913006222823,0.8472581725351127,-2.1595810332015413,0.4495827493130451,False,c1,3,"As of recently the toolbar no longer goes in/out of floating mode after opening an inspector. It will stay in whatever position it was (fixed/absolute, top/left/right/height)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52504",54441,4,High,True
1.944440321719901,-4.875070110700863,2.6804801053615215,-2.632588847512669,-5.327347490752922,-1.1770865143742315,-1.5513580691581232,3.705374347688553,1.418788108200446,-1.6553563665949116,0.8029264587040981,3.0129160975978966,0.2443701266156264,1.2458078658300398,0.4578336520403292,1.2711974456307311,0.32376587220411146,1.2783344040560596,False,c1,3,"Similar to bug 51289 and bug 52398 references that are defined in image captions do not appear in reflists. Example at [[Radiocarbon dating]].
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51289
https://bugzilla.wikimedia.org/show_bug.cgi?id=52398
https://bugzilla.wikimedia.org/show_bug.cgi?id=50459",54427,4,High,False
-5.894367454790595,2.2950446626169665,0.6554783213716,-0.2643436137423628,-0.37970923505254606,2.5751617562683036,5.731629335802608,1.4474505552278694,-5.863233815074237,1.672413048237134,2.888676217506552,0.9072701226303137,1.5940379502294335,-0.17556641044850352,-1.8484302806646964,-1.0055882254271264,2.117826074546434,3.337795845095136,False,c1,3,"At https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=566679647#Spellchecking_wikilinks_causes_odd_behavior en.wp editor Cryptic C62 has identified that spellchecking links causes inconsistent and apparently unpredictable behaviour. Undoing that change sometimes introduces another layer of inconsistent behaviour.
On some occasions both correcting the spelling and undoing it works as it should, but there are at least six types of undesired behaviour where some or all of the link is unlinked.
Detailed examples are at the above link.
--------------------------
**Version**: unspecified
**Severity**: normal",54372,4,High,False
-4.090582588687352,0.5034703213178968,-2.64757601847006,0.6744220598695625,2.1381884195680474,-0.043958263025944966,0.4117682722428917,0.5769301957789534,0.07333752202428329,0.8857799949048735,0.34379642397904275,-0.709778168668584,1.44386034894309,-1.8735755596115018,-0.5413494044172618,-0.9737253224971025,-2.415275050157656,-0.7695503519051177,False,c1,3,"The current beta notice for VisualEditor is currently easy to miss. While it uses a circled ""?"" and the text ""BETA"", it can blend in with the rest of the VisualEditor editing interface pretty easily (I only really noticed that there was any kind of warning today).
The notice that VisualEditor is beta software should be made more prominent.
James has suggested showing a more prominent notice for first-time VisualEditor users (presumably based on a cookie).
My preference is to make the notice dismissable (using a hidden user preference).
--------------------------
**Version**: unspecified
**Severity**: normal",54366,4,High,True
-2.9141949838431565,1.1121202589644366,-1.383718697807895,-1.2582140219218245,1.1307697322197643,1.0724184639806544,0.3420539053005154,-1.325779566561283,1.8011636477467807,0.09811128162441829,0.49298692149275425,3.095984465564346,-0.4051268294523158,-1.0400320575811994,2.0528403282759964,-0.15383798113981512,0.7919176225387836,1.593809970574238,False,c1,3,"One of the pain points we're seeing is that disabling VisualEditor is cumbersome. Even though there's now a user preference to disable the software, going to [[Special:Preferences]] is disruptive to user workflow.
James and I discussed the possibility of adding a switch to the user interface to enable or disable VisualEditor.
This switch might be located in the personal tools section, it might be a sidebar section, or it might be elsewhere. It should be viewable from ?action=view, ?action=edit, and ?veaction=edit.
This switch might affect only VisualEditor or it might affect all ""beta"" features deployed to Wikimedia wikis.
This switch will be available to both logged-in users and anonymous users.
I believe this is a high priority bug to address.
--------------------------
**Version**: wmf-deployment
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54862",54355,4,High,False
-4.424917421499567,-2.7722468010828987,-4.506772893974407,2.2125553481646993,0.6063572617079958,3.275758328569191,-1.3939077456758282,0.9402870939235238,0.7181334922355322,-0.7744000255523242,2.372975582300946,-1.4789222527994177,0.4030613358426538,-0.5922810786568622,-2.6347953744875316,0.8396504510347356,-0.8757261852044064,0.1524309610109913,False,c1,3,"wrapped inline alien: incorrect highlighting in chromium
If an inline alien gets word wrapped, then selecting it leads to incorrect highlighting.
Reproducing: make a <tt> ... </tt> with enough content to word wrap. Select with the mouse (or use CTRL+A).
In chromium, the highlighter erroneously draws a box enclosing the first character and the last (see first attachment).
In firefox, the highlighter erroneously highlights to the end of the first line only (see second attachment).
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11839}",54339,4,High,False
-4.640050186224181,4.071600033720827,-1.731713897209291,-0.6981431678667613,-0.28286723545582715,-1.2428813864097221,-2.2336198861779675,1.7001199552150088,1.9286202056629984,-1.977894306343038,0.18218414395795435,-1.6039588713469741,1.675691422806584,2.934366533606833,0.018015116267322107,0.3686405856774328,1.6487392068479891,0.29376085374886585,False,c1,3,"Toolbar overlapping page head links Firefox 22/Linux/Monobook
In Firefox 22 on Linux with Monobook skin (not tested in other combinations) sometimes the VE toolbar overlaps the page head links and tabs (userpage etc). See the screenshot.
I haven't figured out how to reliably reproduce this but the following sequence /usually/ seems to work.
1. Make one or more changes to a page in VE
2. click on an element near the left or bottom of the window (to trigger bug 52317)
3. open the save page dialog
4. with the dialog still open, scroll to the very top and very bottom of the page
5. close the save dialog without saving
6. click a different element and repeat steps 3 to 5.
7. scroll to the top of the screen and observe the position of the toolbar.
If it doesn't work, try again from step 2.
It doesn't always work, but actions like this do seem to trigger it more often than not. I don't know whether this is dependent on bug 52317 but it was in testing that bug that I found this one.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52317
https://bugzilla.wikimedia.org/show_bug.cgi?id=52433
**Attached**: {F11800}",54326,4,High,True
1.3648799883488425,-0.47799704493094275,-0.5975554457512633,4.067347670311791,-2.3324583762815854,-0.45461080203734006,-4.691038644578199,0.14081627094977278,-1.9250591386702252,1.94538615520315,-0.7678277095185879,-0.7663373400419069,-1.5137011922062236,-1.54902849256704,0.3633013861435499,0.39433684092089843,-1.7512837612847674,0.31468933009812416,False,c1,3,"When working with tags in edits, the tag can be localised in the page history (and recent changes, etc.). For example the history of [[mw:Localisation]][1] shows ""(Tag: VisualEditor)"" where ""tag"" links to [[mw:Special:Tags]] and ""VisualEditor"" links to [[mw:VisualEditor]].
When viewing the same history in Dutch[2], this log line part displays as ""Label: Visuele tekstverwerker"", which in itself is a correct localisation for Dutch. When inspecting the links, the following observations are made:
Observed:
I. ""Label"" links to Special:Tags (expected)
II. ""Visuele tekstverwerker"" links to ""Visuele tekstverwerker""
Expected:
III. ""Visuele tekstverwerker"" links to the documentation page in the content language (in this example ""VisualEditor""). Otherwise each wiki would be expected to have documentation in all usable user interface languages (or at least redirects) to avoid red links.
[1] https://www.mediawiki.org/w/index.php?title=Localisation&action=history&uselang=en
[2] https://www.mediawiki.org/w/index.php?title=Localisation&action=history&uselang=nl
--------------------------
**Version**: unspecified
**Severity**: normal",54276,4,High,True
-5.289434372455327,4.089849234257436,-0.5188534836009797,4.714188189466572,2.044254371423607,-0.39866281085398403,-4.392006178826932,0.49429427040685825,1.0362714690735941,-1.7695770846915044,2.040707608626344,-1.7069858718487447,1.8255612893356359,3.002927091044514,1.064338170527253,0.49629913203319553,-0.20548188924233624,0.11912556380382688,False,c1,3,"Mike Christie at en.wp reports that when performing the sequence:
1. copy template,
2. paste template,
3. edit parameter of pasted template,
4. paste template
Step 4 pastes the template with the parameter values added in step 3 not the original ones.
""To reproduce:
1 Edit [[User:Mike Christie/Sandbox3]] in VE.
2 Select the 13 C (produced with {{chem|13|C}} ) in the middle using the mouse; make sure to select some text on either side, since pasting a template doesn't work unless it's embedded in a string. The colons are there to make it easy to be sure you've got some text in addition to the template.
3 Copy the selected text and then paste it at the end of the sentence.
4 Click on the pasted template, click on the jigsaw piece, and change the 13 in parameter 1 to a 15. Apply changes.
5 Now paste again at the end of the sentence. You'll see that the pasted template contains a 15, not a 13; so the copy/paste buffer was modified by the edit to the pasted template.""
Another test case using a different template:
1. Edit https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=566402676#Section_3:_tl.2C_etc_templates_added_in_VE in VE
2. select ""tlp: {{tlp|as of|1999}} :"" and copy it to the clipboard
3. paste the template elsewhere.
4. edit the template you have just pasted (change parameter 2 to 2013) and apply the changes.
5. paste the template again.
Expected result: tlp: {{tlp|as of|1999}} :
Actual result: tlp: {{tlp|as of|2013}} :
Interestingly, pasting into a text editor gives the 1999 value as originally copied, not the 2013 value you get pasting into VE.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49396",54271,4,High,True
-1.4212699276262084,-3.891842974729352,-0.6134126423445956,-1.8914272410158377,2.659367168193716,0.18811047551624482,-1.8672180989510219,3.797107974914387,2.409557199949856,0.5402605451553084,1.1850539214314622,1.3129485397009846,1.835235016082975,-0.13549171387229197,-0.44169783031232157,-0.6853634669410646,0.8104943710643748,-0.4670526569795823,True,c1,3,"ve.Factory.prototype.create throws an Error, ""No class registered by that name: undefined"" when using the link widget. It can be reproduced with:
1. Start with blank document
2. Hit Ctrl-K
3. Type some page name that doesn't exist
4. Hit escape twice.
This leaves a broken widget that takes several clicks (not sure the exact pattern here) to clear.
5. Try to open the link widget again. It won't be possible, either with Ctrl+K or the button.
This is live on English Wikipedia.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50446",54256,4,High,True
2.2260301742223896,-10.027403886656447,6.048550487137344,-4.938288827393187,2.3442250761903707,-1.517609082765532,2.3950538298119737,-3.083127189066494,1.4706297585254322,2.3711911049557166,1.8049544482034618,1.6127377804278,0.24237036525129874,0.9200417387310509,-2.1277469262197863,0.4552664768105108,2.9927746026598543,-1.4569770297747064,False,c1,3,"See https://sv.wikipedia.org/w/index.php?title=Tjeckiens_president&diff=22846804&oldid=21540497 and https://pl.wikipedia.org/w/index.php?title=Mi%C4%99dzynarodowa_Federacja_Tenisa_Sto%C5%82owego&curid=407381&diff=37148333&oldid=37118048 - no duplication (ahahaha) steps of which I'm aware, I'm afraid.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54169",54238,4,High,True
-0.6081278823226475,-1.5866531360115133,-4.5407499406342975,-7.344608166656915,3.6674813085338127,-4.301730733507448,0.4778268234526788,-6.294638938233427,0.26110126307018067,-1.4865808966304779,1.378966408688409,-3.152979837628024,3.137465554074841,-0.5504815012799185,2.7671373696627173,0.49222293050674565,0.0758920458447252,0.8135208802302396,True,c1,3,"Following a report of the issue by a user, I attempted to add multiple consecutive references. I began with bare URLs and started with 6. You can see that VE thinks it is going okay (http://en.wikipedia.org/wiki/File:VEmultiref.png), but when you save it only saves one (http://en.wikipedia.org/w/index.php?title=User%3AMdennis_%28WMF%29%2Fsandbox&diff=566304458&oldid=566304152)
I tested it all the way down to two.
In case it was an issue with bare refs, I tried it using citation templates, and it would also not save two in a row. It still only saved one:
http://en.wikipedia.org/w/index.php?title=User%3AMdennis_%28WMF%29%2Fsandbox&diff=566306613&oldid=566306049
I'm using Chrome, Windows 7.
--------------------------
**Version**: unspecified
**Severity**: normal",54228,4,High,True
-1.0765800718480296,-1.225884119334081,-3.2618066539080797,-2.280607040090137,0.5319775422196125,5.073382838839621,-1.4563903537094847,0.44609042141607325,-3.466228664063996,2.3511218568111865,3.4180940312663526,-0.32849991619580954,3.7446723044041055,0.12415886712838908,1.4764944001808287,0.5214947605663061,-1.2120434236515634,-1.472103344771418,False,c1,3,"+++ This bug was initially created as a clone of Bug #50170 +++
1. Edit [[mw:VisualEditor:Sfioj]] in VE
2. Make a selection such as
These wor[ds are ve]ry bold
3. Click the ""Bold"" button on the toolbar
The selected text goes extra-bold, in Firefox 22.
I should mention that in my case, the font is Arial, which has an extra bold ""Arial-Black"" variant.
Basically the same as 50170 except that this is narrower.
--------------------------
**Version**: unspecified
**Severity**: normal",54189,3,High,False
1.3761080485241393,-2.515980667394265,-0.945348839725936,-2.2584661451634167,2.5774326889359043,-1.4821099876134989,-2.691561636108679,1.8938443400439633,0.11907210276146091,-1.0044766080770384,-2.0583135989901367,-1.05841342126693,2.3122917931921916,1.8605906809895663,0.19070373959632203,0.7642585284442909,-1.7500881316922,-0.6100438660610081,False,c1,3,"**Author:** `jonathan_haas`
**Description:**
To reproduce:
Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
1. Click on infobox
2. Hit the ""a"" key
3. Hit ctrl+z
Repeat steps 1-3 as long as necessary (about 1-6 times)
Current result:
Instead of being restored on ctrl+z, sometimes the infobox is replaced by a pawn.
The article begins with ""♙The Binding of Isaac"" then.
Also, ctrl+z should probably also restore the selection, so I think it's another bugh that you have to repeat step 1 every time.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52113",54185,3,High,False
0.9500353350158952,-5.122174421585424,3.4728499904738293,-0.029888943031508353,-0.5648188500475035,-1.2373275264424646,0.39298510709434176,-0.9787984065439711,5.117080968066167,-0.6504659327093751,-1.8956665692490724,-0.7885238833917474,-1.4323990672435238,0.7885657366795922,-0.8455898020921424,-0.6347509617220999,1.267886394257115,0.09611891085673174,False,c1,3,"**Author:** `jonathan_haas`
**Description:**
I can't find a possible way to add or edit tables, except changing the content of cells.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52641",54181,3,High,False
4.932447051744839,-0.3649603856641104,3.1922756202852973,-0.4892605823920412,-0.4873520271651029,-0.9297732770457018,3.9406127658455583,5.670320290203618,-2.620123348176789,0.4533622380734865,0.5500964087904672,-2.80455776050868,0.46868157885263617,-1.6840810071213448,-1.0326556703718905,0.5147592407830066,-0.6122497587862642,1.0740240820691567,False,c1,3,"screenshot
When using German language (on German and English Wikipedia, but also likely everywhere else), the layout of the minor changes & watchlist checkboxes on the save dialog is not appropriate when viewed in Firefox. Attached is Vector; same problem exists in Monobook.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52176
//attachment VE_de_Firefox_save_dialog .png ignored as obsolete//",54175,3,High,False
4.643860033233727,-10.591471238733167,-0.633702961557228,1.9274054796746483,-2.1485464089671336,-0.011606863964118252,-1.3658227391754112,-0.05025646882869145,-0.1052686227923611,2.7995684128982345,1.981752230495926,1.136110873020441,0.3477867686455558,0.4898628686497881,-0.11617423022662443,-0.7932681339495802,-0.6300783260392936,-0.17399963569287724,False,c1,3,"**Author:** `jonathan_haas`
**Description:**
To reproduce:
1. Goto http://de.wikipedia.org/wiki/Hint
2. Open visual editor
3. Select all (ctrl+a)
4. Enter ""foobar"" (without quotation marks)
Expected:
- page contains ""foobar""
Actual:
- page contains
ffoffoffoffoofbar|foffoffof
foo
| = cursor position
--------------------------
**Version**: unspecified
**Severity**: major",54171,3,High,False
-9.443861287822973,3.6661200816652197,-2.9430547249900822,-0.07037553814230857,1.4019279383212797,0.8953161200420237,-3.3670341759292883,1.6727163763073434,4.053579371191413,-2.407982828211406,-2.0217938629027197,-1.2288715835101056,0.725776357602383,-0.7478378660670275,-0.665029226436042,0.4264145438923098,-0.650886572818971,-0.21597735836127097,False,c1,3,"When a reference is edited, the updated version will not appear in the reference list when attempting to insert an existing reference. Instead, the reference that will appear in the reference list will be the reference as it was when the page editing started.
To reproduce, go to a page with references. Edit one of the references, and don't save. Then, do as if you wanted to insert an existing reference and look at the list of existing references. The edit to the reference you have edited will not appear.
--------------------------
**Version**: unspecified
**Severity**: normal",54160,3,High,False
-8.978512974547593,2.97115223625217,-4.645585807774983,-4.748856092627253,3.363360590852344,-2.3851284065000593,-0.06418756717367202,-2.35497040673836,0.6801458914174364,-2.7310696613296996,-0.7711795663096539,-2.491852795216214,0.6979581421379368,-4.211841182267964,2.5255047605746723,-0.5310966352583031,1.358332649874532,-0.5821808402401436,False,c1,3,"When an existing reference is inserted, it is put at the start of the paragraph the cursor is currently in, regardless of where it is in that paragraph. This has happened to me while I was attempting to use in a paragraph a reference that was already used in that paragraph: the reference got inserted at the start of the paragraph and I was not able to move it. I tried again some times but it still did not work and I had to use the wikitext editor.
--------------------------
**Version**: unspecified
**Severity**: normal",54159,3,High,True
2.900722550303058,0.6164960310680225,-0.8235536506476162,1.269636639813621,3.196255496058983,2.5563091795939252,-5.555999980589524,-0.5713192953974338,1.995778546177102,-0.22643917700774363,2.489444600153902,-0.3316042294272492,0.21043612880076523,-0.5881023477560792,-0.3341385871342739,1.7258845579157793,0.2967551618429358,1.380890060245567,False,c1,3,"Tested on Firefox 22 (Monobook) and Chrome 28 (Vector)
Steps to reproduce:
- Edit the [[Nodeulseom]] page in the visual editor.
- Click reference [1] and edit it.
- Click the hyperlink in the reference and point it to ""http://www.koreatimes.co.kr/"" (Eg: Just remove the last part from the reference)
- Apply the change.
- Hit ""Save Page"" and review the changes.
Instead of replacing the old link, it seems that the preview suggest that the link will be duplicated, leaving both the old and new link in the reference.
(Diff)
<ref>[http://www.koreatimes.co.kr/ (The Korea Times)][http://www.koreatimes.co.kr/www/news/nation/nation_view.asp?newsIdx=5635&categoryCode=115 <!-- Bot generated title -->]</ref>
--------------------------
**Version**: unspecified
**Severity**: major",54127,3,High,False
0.864878179134005,2.038066786060945,2.2973032386345373,-0.05718882467367159,-0.2551101401690131,1.4390889788350731,-1.9191191805658718,-1.908766732531339,2.522710774156926,-1.4984183706959455,-0.3944737792722579,-0.7055062487810414,1.561900949414321,-0.6218603596970826,-0.9955732581040673,0.5075408795266343,-0.2664218623636996,-1.8529452806328226,False,c1,3,"This makes sense for ULS because they have a reasonable number of merges in a day, see https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/extensions/UniversalLanguageSelector,n,z
This would entail:
* Put the ULS tests into their own Jenkins build, and possibly into their own code repo the way Mobile is
* Have Jenkins kick off the build of ULS tests targeting beta labs upon code merged in the ULS branch
* Report the build status after each run
This came up because we found Bug 52115 in a timely way.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52890
https://bugzilla.wikimedia.org/show_bug.cgi?id=53691
https://bugzilla.wikimedia.org/show_bug.cgi?id=57560",54120,3,High,False
1.5958225971255255,3.89792177463805,0.9107542614807329,-1.0723106638546949,4.186182672665627,-0.38805684857039313,-2.4880322965599255,1.423486244922353,0.5729492285595219,1.8864039642460462,0.05714007575568969,-1.9758633201127442,0.015929777236135756,-0.5703145081239684,-0.4616760661969579,-0.7398234592122728,-0.7735819339484739,0.674463506821273,False,c1,3,"Tested on Firefox 22 (Monobook) and Chrome 28 (Vector)
Steps to reproduce:
- Open any random page in the visual editor. Personally i used [[Botnet]].
- Add the word ""Test"" to the page.
- Press Ctrl + Z to undo the edit. Keep pressing till the edit is gone, then press it once more.
Once you have done this, the Redo button and the Redo shortcut (Ctrl+Shift+Z) no longer seem to restore the previous edits. Any subsequent edit seems to reset the undo / redo buttons to an ""There were no previous edits"" state.
Inconsistent results:
Besides the above result that i can always reproduce using these steps, i have seen various other results. I have seen each of these at least twice but no matter what i try, i cannot seem to find any method of reproducing these reliably.
- An entry in the console log stating ""Error: Cannot roll back a transaction that has not been committed ""
- An entry in the console log stating ""Error: Range error: Range is no longer valid after DOM mutation ([WrappedRange(""Zz"":1, ""Zz"":1)]) ""
- The redo button suddenly inserting ""♙"" once in Chrome.
- The undo button suddenly inserting an endless steam ""♙"" in Firefox.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51532
https://bugzilla.wikimedia.org/show_bug.cgi?id=52185",54113,3,High,True
2.8849644936451013,-0.9151834081192316,-1.6102620454055376,0.9037539454702623,2.9660888583854823,2.69410419047726,-6.4766231888028,1.152944566610588,0.46843331149039213,0.9679210273336816,-0.7181635726551048,0.5436620160680499,1.5574798165377373,-0.4754538046840917,-0.07778148282058428,0.49789666457630183,-0.3544838245865176,0.37381944985162785,False,c1,3,"Firefox 22 - Error console.
Tested on Firefox 22 (Monobook) and Chrome 28 (Vector)
Steps to reproduce:
1) Open the [[Martin J. Silverstein]] in the visual editor.
2) Click on the empty line between the ""Diplomatic posts"" and ""United States Ambassadors to Uruguay Uruguay"" template
3) Click the ""Transclusions"" button, add the ""Botnets"" template and apply the edit.
4) Try to use any button on the visual toolbar that creates a window, or try to open any existing item that creates a window. This will no longer be possible.
Console log:
- The added screenshot is the error console as seen in Firefox. On step 3 the ""DOM Offset"" error is added.
- On step 4 (And after every subsequent click on an element that creates a window) the ""Cannot create a window"" error will be added.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11357}",54112,3,High,False
0.3857195780832807,-17.320988630263596,-2.4905348463467902,0.720572497595102,-2.2788145930481507,4.1358736443401005,4.3778941157332545,-1.0268884792504147,0.5147230210374096,0.906250560665633,0.6030756684509337,-1.0192252918844953,-0.6734565465395965,-0.20605855026025832,-0.07176715128770095,-0.5053900738153995,0.12872868368817847,-0.23037179217508674,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: major",54102,3,High,True
-6.739111408718898,3.7325136916263517,-0.5135863675661909,0.8986650046464433,3.692146820436396,-0.6132933434384983,0.1618426094310763,-1.9574562248438534,-2.0493748423215377,-1.2252361543317867,-0.16453888280104367,0.8795193177180487,0.8730537104516896,0.8302657468763206,0.1618312680733922,-0.6087380712752337,0.014097366867431571,-0.7126596152108973,False,c1,3,"From bug 49820 comment 27:
John Broughton 2013-07-25 23:13:48 UTC
If it's not one thing, it's another ... The popup message is now visible no
matter where in a page the wikitext is being entered. So that's progress.
The popup is still too inconspicuous for my tastes (and a great opportunity for
A/B testing), but that's not what I'm posting about. My concern is with the
link that the popup message includes (the label is ""wikitext""; the target is
[[Help:Wiki markup]]). If that link is clicked, the system **asks the user
whether he/she wants to leave the editing page**. That's a bit user-unfriendly.
I realize that smarter users can right-click and then open the link in either
another tab or a new page, avoiding the question of whether they want to leave
their editing session. But if we're aiming at the average user, it would be
great if this link were pre-defined as opening another window, so that a simple
click on the link didn't result in a perturbed user.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51585
https://bugzilla.wikimedia.org/show_bug.cgi?id=51122",54093,3,High,True
18.361276820674412,-7.784462868210463,6.605648997913725,-2.8617187204490624,2.9127448691545124,-4.007419324533384,-3.246988512072847,2.380338715409427,3.0817651877201007,-1.9072637867232536,-1.404335273784503,0.36676680518509497,2.179923127353669,-2.8940695391432607,-3.4044074763960306,1.9279173576644792,0.2570310337523971,0.8284160240505865,False,c1,3,"Reported: https://en.wikipedia.org/wiki/Wikipedia_talk:Tags#Incorrect_tagging
and
https://en.wikipedia.org/wiki/Wikipedia:VPT#Blanking_filter_misfire
**See Also**:
* {T54049}
* {T54062}",54077,3,High,True
-8.232006434367259,4.703393008233583,1.8291454469822916,6.730713411106849,7.114964586669002,7.235166384200384,-0.4920798849517176,0.9515373920026561,2.012632363866775,-1.6253391146948974,-0.8206639693429651,1.3620123338484842,0.07660354433307504,1.2307920229053648,2.930630941540884,-1.0079377149387927,-1.6189271922469732,-2.5820553083082576,False,c1,3,"If the TemplateData for a template specifies a default value for a given parameter (see bug 52028) then that value should be prefilled when that parameter is added to the template.
An example would be the current date for an accessdate parameter.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54029,3,High,False
-4.201008528568747,5.602700366507062,0.09879663512233705,-2.2194519059843776,-1.546606668786775,3.9757327615476283,2.6481168527197925,4.299547495184856,-2.9779778587492682,0.6383251513663435,1.4902739409733248,-2.471190201742318,1.1158083514927242,-0.79837119710783,-2.3628664743002186,-1.9170943254786468,-2.6980026232578074,2.0855517477617695,False,c1,3,"In Firefox, scrolling a large VE page is very slow, with visible pauses between repaints, predominantly because of the floating toolbar. Calling disableFloating() on the toolbar from the JS console causes scrolling to be roughly as fast as scrolling the non-VE page view.
Timo says he knows how to fix this.
--------------------------
**Version**: unspecified
**Severity**: normal",54014,3,High,True
-3.274094052665832,-0.7040033878927918,-2.9070950090418393,1.426956775007623,-0.85873081874211,2.04886305604086,3.1859282981093946,1.9067173276782645,-4.296302016938228,-1.3219892749787747,-0.9492195531998866,2.380668885972895,0.5082680839502052,2.1665674746029886,-2.109515136293011,-2.2340926490303312,-0.03205006986687686,0.15923952326883373,False,c1,3,"Using the backspace or delete key to delete plain text on a large page takes hundreds of milliseconds per character, predominantly because ve.dm.Document.prototype.commit() is called, which leads to ve.ce.ContentBranchNode.prototype.onChildUpdate(), which leads to ve.dm.Converter.openAndCloseAnnotations(), which calls containsComparableForSerialization(), which is apparently O(N).
Bug 52012 also affects backspace performance.
--------------------------
**Version**: unspecified
**Severity**: normal",54013,3,High,True
-6.414452002303445,2.109320050890595,-3.1521930525338497,-6.003372385243399,4.3099670516961766,-5.840542840811205,1.1331497953881797,-2.8748276860823845,2.250049921795066,0.7740391393626052,1.1176248145294578,2.094810104614214,0.6120364997825045,0.46774117359962997,-0.3981039864785858,0.6864535996331683,-1.5944843956687662,-0.8977463534949592,False,c1,3,"When a blocked users attempts to edit a page in the classic editor they see a large, red-bordered notice that tells them:
*They are unable to edit, but they can still read
*Who blocked them
*Why they are blocked (shows them the block log extract)
*When the block expires
*That they can usually edit their talk page and email other editors and aministrators
*What to do if the block is unclear or doesn't seem relevant
*How to appeal a block (links to policy and guide)
*That they can view and copy the source of a page
In contrast when a blocked user attempts to edit a page in VE
*No notice appears, and editing works as normal
*When they click ""Save page"" they can review their changes and enter an edit summary as normal
When they try to save their edits they see a small white box with a message that tells them:
*There was a server problem
*Their request was unsuccessful because they have been blocked
They can then choose only ""OK"" which takes them back to the save page dialog.
This is very bad because
*The message they see appears to say they caused a server error - cue panic mode for non-technical users (""Help! I've broken Wikipedia!"" - that is exactly the reaction I would expect from my mother.)
*They have wasted potentially lots of time on an edit they cannot save
*It doesn't tell them what being blocked means
*It doesn't tell them who blocked them or for what reason
*It doesn't tell them what they can do to get help - they can't ask questions at the page that seems to be about asking questions for example (see Bug 51875)
*It doesn't tell them when the block expires, how they can appeal it or how they can contact anybody.
For some users it is even worse that that - saving fails silently: Bug 51999
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51999
https://bugzilla.wikimedia.org/show_bug.cgi?id=51454
https://bugzilla.wikimedia.org/show_bug.cgi?id=51547
https://bugzilla.wikimedia.org/show_bug.cgi?id=53009",54004,3,High,False
-4.407378081851652,-1.982009210549256,1.946280048971449,-5.46334431933628,-0.8780214998056911,-1.4135388933438475,3.4940350323424925,4.1376514191574065,2.4207108216720643,3.67001550921022,3.3335273110230346,-0.556701774116944,1.403071691383098,0.2780734555335842,-1.2030719947969972,-0.5571230246646094,1.158556229860806,-0.03964690337668397,False,c1,3,"Users can't reuse a reference belonging to non-default group. It's just not shown on the list and I've been unable to get such refs to show up there.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51838",54000,3,High,True
-5.2760281747625335,2.1195280187395014,0.8433699455322738,-5.555298184881523,5.089423012349343,-5.777586531853703,0.7978194536371825,-4.954099758076924,1.2030845189954897,1.1513306064325892,1.3238389488146072,-1.2629235333425075,-0.6785437120392794,-0.5491761642466333,0.3386053038690253,-1.586496146524554,0.8393161027204037,0.45578693262111947,False,c1,3,"A user on en.wp has reported the following:
""Editing anonymously from my school computers is blocked, and for fun I tried editing a page using VE. It lets me edit the page fully, ''until'' I try to click the save page button. No matter how many times I click it it doesn't save, but there's no notification telling me why it doesn't save. A bit weird really""
I blocked my legitimate alternate user and then tried to edit a page. The editor loaded fine but when I clicked to save the edit I saw the message:
""Error loading data from server: Unsuccessful request: You have been blocked from editing.""
I am on a shared connection so I do not want to do any testing of ipblocks, etc.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52004",53999,3,High,False
-4.363023223692727,-5.08649011112661,4.07618860339792,4.213353865339149,-3.56033781450405,-6.563172945319974,-1.497193197819482,-1.7155043588436323,-4.4807256498781705,12.032718405890176,-7.905095919070517,-0.6223706887568455,-5.330269656361259,2.021173447213373,1.4794169743459031,0.17303665377217536,4.060009518533513,-0.7914396562742854,False,c1,3,"For instance instead of class 'tright' or 'tleft' just class 't' gets added. It is regression of this change: https://gerrit.wikimedia.org/r/#/c/75526/
--------------------------
**Version**: unspecified
**Severity**: normal",53995,3,High,True
0.10844856080153731,1.8873088391697976,-1.0549752728382007,-1.914288351445414,4.102949136834495,0.33122309209792333,-3.2240998900941165,0.8875454532158705,3.28729051437391,0.7862536022225006,0.3818566632209972,-0.020242661576575394,1.3812250643119763,0.026743313546738534,-0.3866087584953384,0.13666202862864701,-0.49507017791387076,1.271873500482682,False,c1,3,"Firefox - Detected script lockup.
Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28
Steps to reproduce:
- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.
- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.
- Click the ""Bulleted List"" button. A list bullet is added to the article.
- Click right after the bullet that was just inserted. Now click the ""Bulleted list"" button again.
Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)
In practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11897}",53987,3,High,False
3.1010815931695768,4.82649724644093,5.994489405757829,1.1925353838768311,0.41040056984892037,1.5278891636596297,2.074550908259096,0.30095045767805784,-2.8452713769784825,0.5109465265855988,-0.24487662325711845,0.17427033537228787,-0.9367426941582311,-1.3614599368404159,0.8924864494329485,6.619183139201439,1.732152818649204,-1.3120230441717062,False,c1,3,"The particular article in the URL field of this bug report doesn't not display the Save button in Firefox.
The Save button is displayed in Chrome, and it is displayed in other articles in Firefox.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit",53986,3,High,True
-2.1336729035448503,0.953668557208518,-2.414232017457003,-1.6850379199552328,2.3264116971321536,0.9217296900662422,-2.648164179212199,5.646471349131426,2.3463461411423276,-2.187919945811411,-0.6725530512197171,-0.3699764663135564,0.9155109609606984,-0.2311545528388379,-0.04720888604565765,0.9960429036265441,0.36789761298239254,-1.0003074075351714,False,c1,3,"(Tested in Firefox 22 and Chrome 28)
Steps to reproduce:
- Open [[Portland Ice Arena (Oregon)]] with the visual editor.
- Click the hyperlink button (Don't select anything). The hyperlink window should pop up.
- Now click anywhere else in the article without entering any data in the hyperlink popup.
- An empty popup balloon will remain behind. There are no controls on that popup anymore.
- Click around the article a bit - eventually that balloon will be removed. However, the link button will now fail to work no matter what you do.
This may or may not be related to bug 48549, which seems to have been fixed in todays deployment.
--------------------------
**Version**: unspecified
**Severity**: normal",53984,3,High,False
-2.7712083055430714,-1.885243418504471,-2.657325309450238,1.1599550734472928,2.843975869814232,0.45171936036221005,-0.9329516030924685,0.8242491768244683,-2.72774652854136,-3.36164812081694,-1.636029918649495,0.5670645303807846,-0.6121610765745098,-0.7844308166818106,-1.5252760862508437,0.9085201449367206,-0.756848487852054,-1.3550656422098672,False,c1,3,"The Hebrew Wikipedia frequently uses the template {{כ}} ( https://he.wikipedia.orgw/wiki/Template:Rlm ), which inserts the ‏ entity. This entity translates to an invisible zero-width control character, the [[right-to-left mark]]. This template works correctly when the article is rendered to the reader, but when the article is being edited in VE, the text behaves as if it's not there.
For reference, see https://en.wikipedia.org/wiki/Right-to-left_mark .
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/User:Amire80/ve-rlm",53978,3,High,False
-0.43504437695756915,-2.280781671222927,0.7209255003690664,1.8887279186183434,3.896065868977209,-1.8616806838259734,-6.654131340108373,2.775610242405888,-2.194322992977357,4.764301520389299,-0.4564113977115305,-1.70558303072665,-1.097473858862,2.9790347771810284,0.4174825447363828,-0.16587048636789004,1.9165519027254285,-0.5151769096475212,False,c1,3,"1. https://en.wikipedia.org/wiki/User:Raymond/Gallery?veaction=edit
2. Put the cursor after the first ':'
3. Press the down arrow - cursor should now be far right of window, beside the gallery
4. Type 'a'
5. Press Control-Z
Results vary.
1. Sometimes two characters will appear: 'A' <new line> 'a', and 'Save page' is enabled. Control-Z removes only one of them, and the 'Save page' button returns to disabled, with one added character still on the screen.
2. Sometimes a pawn appears.
3. Sometimes only one character appears, and the 'Save page' button remains disabled.
On the gallery at the bottom of https://de.wikipedia.org/wiki/Hollenegg?veaction=edit , option (3) happens most often.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53750
https://bugzilla.wikimedia.org/show_bug.cgi?id=56248",53957,3,High,False
-6.479859983722664,6.605292262417475,1.8420566969565897,-0.5290551919855548,-0.3766689669527922,3.001556961573735,1.3688068748511277,1.9394791684262516,-2.2061543830862056,0.2597607382884002,0.35142248165190715,-0.6839170859447941,-0.8823195887025168,1.6212183934910573,-1.0643730865688648,-0.256083889887056,-0.7512764506545998,-1.6171944053434695,False,c1,3,"Overlapping template selection box in Firefox 22 on Linux
When templates do not have a defined width the blue selection box extends the whole width of the window, regardless of whether the template does. This means that in some cases, e.g. at [[Where Does This Door Go]], the transclusion editor icon is displayed not on top of the template.
More seriously it also means that smaller templates to the right of larger ones are difficult of impossible to access because they are completely covered by the other template's selection box. At the same article, the ""Professional ratings"" translcusion is difficult to select (you need to click it in line with the slug between the templates on the left) and the tooltip icon does not appear.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49922
**Attached**: {F11785}",53933,3,High,False
-3.467962568757052,0.8970676967239317,-1.357151952601221,-2.868976916276843,0.43845202646395176,-3.3740824932109934,-1.6652341714158894,-2.2608028887428464,1.860427531934972,1.012917042223794,-1.2690600547083064,1.1349282970603103,0.8475532806935302,-0.35675214248494047,-0.1549382143657798,-1.2846219538397488,-0.6239191806926587,0.7845697233800746,False,c1,3,"Cloning from bug 50897 comment 2:
In the old editor, I would simply use TAB to reach the edit summary, type my
edit summary and press ENTER to activate the ""Save page"" button and save. If I
wanted to mark the edit minor, then I could type my edit summary, press TAB,
SPACE, and then ENTER to ""Save page"".
I can see that the new box for entering an edit summary allows newlines to be
entered. I am not sure this is a good idea, because I just used a WSYIWYG
editor and now ""What I see"" - well-formatted paragraphs describing my edit - is
not going to be ""what I get"" - everything smashed on one line in the article
history. But that is perhaps grist for another bug mill.
It seems that the ""Save page"" button never receives caret focus if I use TAB to
try to get there. This would seem to have accessibility ramifications.
--------------------------
**Version**: unspecified
**Severity**: minor",53918,3,High,False
-3.0219245415848026,0.7303032319701686,-3.1755007827485198,-2.1633916656725174,-0.5886268849642841,-2.709070614098197,-1.7545081709151642,-1.724093519999359,-0.9383192024984782,-1.068110277213778,0.6864057676057893,-3.3116600266565177,2.1714297032183083,-1.395106060898736,0.9509202814778588,-1.664068148325453,0.33649562203167394,-0.30477005638081667,False,c1,3,"(This sounds exactly like bug 50424, but that was marked fixed on 2013-07-15 with ""deployed within the hour"".)
I had made source edits to a mediawiki.org page over https. Looking at it 30+ minutes later I wanted to make one more quick edit, so I clicked [Edit]. VE worked fine, Save dialog, [Review your changes] worked, but the final [Save page] drew blue bars before doing nothing.
Firebug's network console showed the API requst visualeditoredit with
basetimestamp 20130723212405
format json
minor 1
oldid 745108
page Manual:How_to_debug
starttimestamp 20130723232059
was failing with
{""servedby"":""mw1139"",""error"":{""code"":""badtoken"",""info"":""Invalid token""}}
I had a similar occurrence a few days ago where the API reported badtoken. I can't remember the specifics of that, but I assumed it was my mistake because I was using multiple accounts on different wikis. This time I wasn't doing anything special. Connecting to https://www.mediawiki.org/wiki/Special:Version in another tab shows me as still logged in.
Maybe there are two bugs here: VE's inability to recover from this, and the lack of a ""VE had an internal error"" with suggestion as to how to what to do (e.g. copy the right-hand column of [Review changes]. Regarding the former, when I've lost state with source editing I usually find [Show preview] brings it back, maybe VE can implement something like this internally.
--------------------------
**Version**: unspecified
**Severity**: normal",53915,3,High,True
1.0963035692179264,4.597035708987313,0.7517797386914218,-3.5505454377298595,2.77534266133348,-0.803749596576639,0.8344368731208824,-4.59416216307874,-3.92274459913501,1.270987783830492,-2.592341227366906,2.6067257009549696,-2.183140858048313,1.750212352058922,-1.0731963739827144,-0.5783576894596447,-0.8692284569455752,-1.8058038655880821,False,c1,3,"If you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon.
--------------------------
**Version**: unspecified
**Severity**: normal",53902,3,High,True
-1.0265932783915055,-0.29662074078971656,2.6913750100743172,4.2499053261758615,-3.720115480125957,2.4049930747228663,-0.3139291538300393,-0.2209651797044023,-0.8221181664769671,-2.2704537619624836,-1.9970078617358096,-0.8834662061585739,0.874953144552308,-2.8823917443109406,1.0554398705140118,0.7276751170251827,0.39794960137546487,-1.8686989119176909,True,c1,3,"The error can be seen at http://ja.wikipedia.org/w/index.php?title=ロマン主義&diff=prev&oldid=48242310
Each language template in the lead sentence (e.g., {{lang-en}}, used for providing translations of the article title into English) was replaced by two snowmen.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://ja.wikipedia.org/w/index.php?title=ロマン主義&diff=prev&oldid=48242310",53883,3,High,False
-5.65778437451166,0.5779531341031756,-5.730076031530437,-0.41017560949200793,1.6461806255577662,1.3759338315839116,0.31505099369195655,0.9379264304801419,-4.024826559883985,2.6217541387173178,-1.5378981673609422,2.8800468457739496,0.02656605618661878,-1.3830167655727035,-0.15843009439831768,0.3026854642596956,0.12907315715626266,0.5333807747779502,False,c1,3,"The VisualEditor explicitly sets all images that are inserted using the dialog as thumb and right. ""thumb"" is fine, because it's not default, but that's what people want most of the time, but ""right"" shouldn't be there. ""right"" is the default for left-to-right Wikipedias, so it's redundant in English. The default for right-to-left Wikipedias is ""left"", so for these languages this behavior is unexpected.
The best solution is simply not to set the alignment and let the user change if it is needed.
--------------------------
**Version**: unspecified
**Severity**: normal",53851,3,High,True
-1.185635319840105,-0.37456658588816794,0.32041444018044274,-3.888395820722311,1.551803887204946,-1.828438936244107,-1.4556275492268522,-3.7902616284665935,0.30682000035109935,0.03809536336387431,-0.9825632225839898,-0.34401440512664905,-0.5805938592349884,0.32794991880466107,0.030013158628335646,0.595699308365558,0.35806735962260094,-0.6580077061538832,False,c1,3,"Given that I'm editing an article in an RTL wiki: https://he.wikipedia.org/wiki/ASCII
And I press the ""Transclude"" button in the toolbar (puzzle piece)
And I type ""A""
Then I should see a list of autocompletions of templates that start with A
Currently I don't see a list of autocompletions.
This bug is quite similar to Bug 51490.
[This was an experiment with writing bug reports as Cucumber-style test scenarios. Let me know if you don't like it.]
--------------------------
**Version**: unspecified
**Severity**: normal",53828,3,High,True
-3.6039575498722956,-2.3034068561003096,-2.6488054705338993,0.45498983930976666,2.9616992778314315,2.2285355539751066,-1.1718704402639633,-1.5099131620337647,0.5809571265632762,-1.315928114492817,0.3482380661845794,-1.5327946900618854,1.7557523752377548,-1.2420555116741312,-2.658881510586869,0.40079936792865734,-1.753024173156993,-1.5189908572578934,False,c1,3,"screenshot
When you click an infobox template in an RTL wiki, the puzzle piece icon is supposed to appear somewhere on the transparent blue background to make the template editable.
In an RTL wiki, this template appears outside of the transparent blue area on the other side of the screen.
You can test it with the following article:
https://he.wikipedia.org/wiki/%D7%9C%D7%95%D7%93?veaction=edit
See also the screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11560}",53819,3,High,True
4.77825038578961,-4.132634879345467,7.536429374821132,1.7022834567784244,-4.908761078777058,-2.4042753605129956,0.17507136916561095,2.2909173273078993,0.07878264788557754,-0.995516794935321,1.5489437718472447,-0.46627830032547835,-2.149895575896868,-0.8769753918298022,-0.6047457167118635,-0.3439601575916559,0.4764572826617435,0.6099600591175875,False,c1,3,"TempalteData-provided parameter list in template editor is not scrollable.
For example, try adding [[pl:Template:Okręt infobox]] to any article there.
Confirmed on latest versions of Firefox and Opera.
Screenshot: http://i.imgur.com/e3VSqVs.png
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51672",53739,2,High,True
2.5956333082331233,1.5272242616694722,0.23261534929461192,-5.938351138982524,-2.8929674449864518,1.4010694866180289,-0.20600803861408945,1.0235821900001363,-0.42908457634023917,-1.2585600778845558,-1.0031033525871478,-0.15830870541772035,0.7313578823610185,-1.1717282394684858,-0.41538331461956535,-0.7266689224988021,-0.16596293532474182,-0.40942309923841447,False,c1,3,"GUI for the existing TemplateDataEditor
Not the same as bug 50964: it would be really nice to provide a tool for editing TemplateData also outside VisualEditor (I even think it's better than inside VisualEditor because VE doesn't work on Template namespace right now).
The existing TemplateDataEditor script (created by Ltrlg on frwiki, translated for enwiki by me), can be a good start. Benefits for including some equivalent in TemplateData extensions are important :
* Available to all wikis
* Translations can be done like they are done for TemplateData
Links :
* http://en.wikipedia.org/wiki/User:NicoV/TemplateDataEditor
* http://fr.wikipedia.org/wiki/Utilisateur:Ltrlg/scripts/TemplateDataEditor.js
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50169
**Attached**: {F11375}",53734,2,High,False
-6.201589154088633,1.3254718115766426,1.772055485236752,5.963446053618078,1.5806308538166687,1.416002695795682,-1.9506961769382238,0.9161575426731013,-1.1270174576569725,1.8727594606310598,3.138594336062367,-0.7034883384868289,-0.10013222691414025,0.4163400222077849,-1.3402098723651603,-0.08144538276692975,-0.11868542683440331,-0.25849271353687175,False,c1,3,"In Visual Editor edit screen templates that produce a single line of displayed text (regardless of the length of that line) do not wrap on word boundaries.
Steps to reproduce:
1. Insert a picture or other right-aligned object that text should wrap around.
2. Transclude a template that produces a single line of text. {{EW charity|123456|This charity has got a long name to make it easy to test this bug}} is an example
3. Reduce the width of your browser window until the text produced by the template is longer than the avaialble space between the left margin and the picture.
Expected behaviour: The last word(s) of the text produced by the template wraps onto a second line.
Actual behaviour: The entire line moves to below the picture as a single unit.
Any template that produces two or more lines of displayed text (on an infinitely wide window) does not exhibit this behaviour and wraps correctly. For example:
""Long text<br>1"" wraps correctly
""Long text
1""
""Long text<br>"" and
""Long text<br>
<!--hidden-->"" all exhibit this bug.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52445
https://bugzilla.wikimedia.org/show_bug.cgi?id=50395",53708,2,High,False
-5.961659617438428,1.5844824019720072,-4.965511044933594,-3.7794594962858556,1.5773261421221263,-1.8451603711832454,-0.7116469233733937,-0.4602838392763957,2.3248340261466645,-0.9576057387541757,0.0622412576150837,0.13863179899387612,1.4213629439499895,-1.1101121892105725,-2.779831095366208,0.5219632833610734,1.2751176631088537,2.714798643702447,True,c1,3,"See http://it.wikipedia.org/wiki/File:Pic_-_VE_-_it_-_18_July_2013.png .
http://it.wikipedia.org/wiki/Tellururo_di_mercurio_e_cadmio
My understanding is that unlinking can be both done by the clear formatting button or by the trash button in the linking tool.
If you don't select exactly the word that you want to unlink (so if you include even just a space, which I guess can surely happen), you'll be able to unlink via the linking tool by clicking on the garbage can: but then, a weird cursor appears and you can no longer edit links or templates.
According to me and itwp users that happens with both FF and Chrome.
--------------------------
**Version**: unspecified
**Severity**: normal",53679,2,High,False
-3.3719799368551358,0.9497382259218679,0.8051888979309858,3.959343361807961,5.242892028882807,-1.4151975418314038,-1.2473757519149027,-1.9413089332386528,-2.6012220641004715,1.1716107849810093,-3.4844752242234245,-0.8176492034605921,-0.9550981154884504,0.9874092329981687,-2.5349072129141086,-2.3088946295108914,-1.6932982094761384,-0.0491356504510263,False,c1,3,"Two screenshots showing the search function applied to {{cite book}} on en.wp
A user on the English Wikipedia reports that when entering a template using the transclusion editor, the search for parameters fails when the parameter includes a space:
""when I start typing ""Source date"" (without quotes, of course) into the search box, something interesting happens when I get to the ""d"" - the search results say ""Unknown parameter"". That is, at the point where I've typed ""Source d"", then - essentially - the search fails; the search software decides that there are no matching entries.""
I've tested this with both {{cite web}} and {{cite book}}
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51822
**Attached**: {F11265}",53670,2,High,True
-1.13220211683932,-5.917428649520302,-1.9252121164769704,-1.0131504965835514,4.011447478870204,-1.9526006939816334,-1.2839929282925606,-2.931335490347324,3.2226241656783507,-1.5827711558349322,0.07436715599479182,-2.442686817955165,1.5009382036792172,-2.4640853370741347,-1.131993809511627,0.724072288797003,0.5880217068908917,-0.8480274755268675,False,c1,3,"**Author:** `kwang`
**Description:**
This shows the article and the visual editor save dialog
I added a link to a new page but it wouldn't let me save my edit. Every time I saved it would load but then display the save page dialog again.
I ended up creating the link in the source.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53093
**Attached**: {F11178}",53636,2,High,True
0.8162997292200784,-1.1742527087699006,1.6018074681798353,3.1884929513296694,-1.1420761746291053,1.6398328021215727,-2.7789422669918675,-0.05377103497874222,0.41871982871477686,-2.321461676682557,1.0704011663378874,0.1264494346345193,0.7657891507409924,-0.4579118400395892,-0.3690383238783701,-1.0138281956759638,1.15727348634616,-0.813196512828144,False,c1,3,"Browser: Chrome any version.
1. Open VE
2. Type or copy-paste സന്തോഷ്
3. Move the cursor to the end of that word.
4. Press left arrow to move the caret backwards.
5. In the second keypress onwards cursor is stuck.(like സന്തോ|ഷ് )
Expected: cursor keep moving to left.
Observed. cursor stuck.
--------------------------
**Version**: unspecified
**Severity**: normal",53596,2,High,False
-0.9349887696863743,-4.175510161127326,-7.529430746797292,0.9693699630144916,-2.8165994512841013,-4.326457892423449,-5.0688935854593975,-1.632298835150114,-0.9337310861962262,-2.533463046542353,5.157150224218476,-0.4718738305235325,-1.8033979991015068,-0.8864265637338198,0.27673527601688086,-0.15953465472851341,0.7052200144376559,-0.6712529281982105,False,c1,3,"On a regular page load:
* http://en.wikipedia.org/wiki/Roadblock_(disambiguation)
* Logged-out (Chromium Incognito mode)
We get this (did a full analysis while I had the data in front of me, but focus on ""On Edit"":
Top:
- [core] load.php?modules=startup
- [misc] load.php?modules=.. top queue ...
- [vector] load.php?modules=ext.vector.footerCleanup (bug 51564)
* [ve] load.php?modules=ext.visualEditor.viewPageTarget.init
- [core] load.php?modules=site
Bottom:
- [misc] load.php?modules=.. bottom queue ...
- [vector] load.php?modules=ext.vector.collapsibleNav (bug 51564)
- [misc] load.php?modules=.. jquery.ui ...
(dependency of something in the bottom queue, separate cache group)
On Edit:
* [ve] load.php?modules=ext.visualEditor.base,mediawiki,viewPageTarget|jquery.visibleText|oojs|unicodejs.wordbreak
* [ve] load.php?modules=jquery.byteLength,byteLimit|mediawiki.api.edit|mediawiki.feedback|ext.visualEditor.core,icons-vector|ext.visualEditor.viewPageTarget.icons-vector|rangy
* [ve] load.php?modules=ext.visualEditor.specialMessages
- [ve] api.php POST action=visualeditor & paction=parse
- [ve] api.php?action=query&meta=userinfo
These shouldn't be 3 separate load.php requests. Ideally it'd be 1, but we should at least cut it down to 2. We should figure out why they are split.",53569,2,High,False
-4.709300608567352,-9.042100193645414,-3.717553754824607,0.6204849905699168,5.5249313227256405,-4.263919174337019,3.5492175783360542,-1.2262399555214174,1.5216626500779777,0.3415357227876763,2.3042914572017295,0.11092119656974764,1.1874378451136631,-1.8653438320685551,0.13993686937273875,1.2874515996362885,-0.46899155934525927,0.9224849455400477,False,c1,3,"* Select some text forwards and copy-paste it, everything is great.
* Select some text backwards and copy-paste it, you now have an extra linebreak.
?!???!
--------------------------
**Version**: unspecified
**Severity**: normal",53538,2,High,True
-3.156902387925578,-5.421172249253951,-3.0031239311535014,0.1607658943513075,3.0029610463688874,-2.9394836927954437,2.656452201606453,2.7887641026520824,-1.7030803224593754,-0.09667966702422781,1.5219242597505462,-1.5107929984748323,3.279710177004744,-0.4182260314056707,0.3397349770455982,0.8156484930691247,0.9148214103908947,2.022629311205276,False,c1,3,"When typing in visual editor, sometimes pressing CTRL+Z will replace the last entered character with a pawn (♙).
I've encountered this most frequently when undoing text that appeared as a link when I didn't want it to (see bug 51531) but occasionally when undoing other text as well.
There are numerous other pawn insertion bugs, other editors have suggested possible relationships with bug 49732, bug 48346 or bug 51140, but none seem quite the same (e.g. there is no non-ASCII text, bold or italics involved) and all are marked as fixed. I encountered this yesterday and today (16 and 17 July).
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51762
https://bugzilla.wikimedia.org/show_bug.cgi?id=52113",53532,2,High,False
7.0028175662197505,-6.441396722968397,-1.970109830693863,2.6770291359257694,-4.777752575263436,-1.3647648802235253,-2.9503537227811196,-0.3450974279610368,-0.5410175287480158,-0.5446641436478137,0.5306560769503559,-0.6228240827856677,1.1822716240044158,-0.7951067777837215,-0.6504223212934965,-0.4136724559524807,-0.7965103438871911,-0.13005347818073498,False,c1,3,"Screenshot of problem
1. Open https://en.wikipedia.org/wiki/Pancytopenia?veaction=edit#External_links
2. Select Commonscat template block
3. Put cursor in heading after ""External links""
4. Arrow keys to navigate down (to after text in list item ""* [[CDC]]"")
5. Arrow keys to navigate right
> Uncaught Error: Offset could not be translated to a DOM element and offset: 2409
ve.ce.Document.getNodeAndOffset
ve.ce.Surface.showSelection
ve.ce.Surface.onChange
oo.EventEmitter.emit
ve.dm.Surface.change
ve.ce.Surface.handleLeftOrRightArrowKey
ve.ce.Surface.onDocumentKeyDown
proxy
jQuery.event.dispatch
elemData.handle.eventHandle
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11838}",53526,2,High,False
-3.7572242658310886,-4.271320676688518,7.466821518288572,8.044402524686818,-2.277284284099098,-8.468769690381087,-2.289245169982361,-1.5810818347193178,-2.138166030888426,4.903472141760735,-2.540162095155007,-2.331512169170556,-0.2652495295594868,0.9437212818355913,2.118178927421881,-1.070358258489089,-1.6106594171762438,2.100079497042751,False,c1,3,"When doing the steps outlined below, strange '9' character plus a newline appears and input it jumped backwards after 3 character.
See http://youtu.be/A7MWIdu3dtk for how it looks; Using http://en.wikipedia.org/wiki/Ansaldo_Poggi as test ground.
1. Place marker under ""References"" header
2. hit ""backspace""
3. type ""foobar""
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://en.wikipedia.org/wiki/Ansaldo_Poggi",53525,2,High,False
-8.786268920083014,4.575660032195085,-2.07103915226177,-5.8951280706528015,-2.068125261794581,-1.4172145614292333,-0.43679387998311636,-1.6234026855000248,1.277900208442998,2.7358348951335945,-0.10721565029638658,-2.1855558467880307,-0.3703431286344534,1.2941815664472758,-1.4672578469311226,0.587652219809218,-0.504598871568903,-0.1263742637446108,False,c1,3,"I use the ""link"" tool from the toolbar to in-link to other articles. However, after adding the link, the editor doesn't disappear. I have to click again, outside it, to make it go away.
--------------------------
**Version**: unspecified
**Severity**: normal",53523,2,High,True
-3.006527684929114,-2.2880268931675847,0.08707284393475234,-5.764976160586648,3.0601498468405315,-1.9279888171583188,1.6419189545696886,1.4464307867328818,-1.0488710385477147,1.6671573319423434,-0.6509032878246823,1.0008182538991541,-0.7381955022086641,1.312855815352843,-0.8448226182337653,-0.3277531930080362,-4.286690232248769,-0.5227765216524163,True,c1,3,"I think ""Clear formatting"" is important enough to justify a keyboard shortcut. For example, there are cases where the formatting can unintentionally continue longer than you want, such as when you add a link.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53682
https://bugzilla.wikimedia.org/show_bug.cgi?id=56453",53507,2,High,False
-3.6684417942991985,5.469483300598437,-2.6585351186169444,-3.687274365205892,6.207289268205717,-1.514327386418874,0.0847006136492281,0.8740126627315082,3.336409535645564,-1.335168119077362,-0.3399932686968734,-3.4268102749939793,-0.21810919946747287,-0.6088532623258542,-1.0142446344111535,-1.1425801791139574,1.0611899023943516,3.8111449181876784,False,c1,3,"Right now the SurfaceObserver locks and unlocks a lot, firing a lot of events and stopping and restarting a lot. We should make locks wider so that this doesn't happen.
We should also eliminate cases where the SurfaceObserver responds to a DOM change that was actually made by VE itself, and we should change pawning to no longer go through the model.
--------------------------
**Version**: unspecified
**Severity**: major",53502,2,High,False
3.543329616711819,5.9559105893725,-2.046179832853678,-1.1580535814609734,1.2423343875347999,2.7231901114603367,-2.211961553443854,-1.553898815530796,-0.8493270727142554,0.4296732812741295,-0.7246800873298249,-0.5963093949314605,1.5753707458702282,-0.46673567792022297,-0.30382360125016383,0.40619302159614384,-0.1603541449672634,-0.23113788955356518,False,c1,3,"Typing in the Devanagari script causes very unusual placement of vowels in relation to consonants. The correct place to put the vowels is always after the preceding consonant, but the VisualEditor causes very strange placement.
To try, I used the standard Hindi InScript keyboard (not ULS IME, but the operating system's InScript keyboard). I tried to type the word ""अंग्रेज़ी"" (the Hindi name of the English language).
To get that word with the InScript keyboard, type the following keys on the English-US keyboard:
Dxidjs;]r
The expected result is ""अंग्रेज़ी"".
The actual result on Firefox 22 is ""अंग्ेच़ीर"".
The actual result on Chrome 28 is ""्रेची"".
I tried this with Firefox 22 on Fedora 18.
I mark this as blocker, because in this state the VisualEditor must not be widely deployed on a Wikipedia that uses the Devanagari script, such as Hindi (hi), Marathi (mr), Nepali (ne) or Sanskrit (sa) (there are a few more languages that use it). It's OK to have it as opt-in for testing on these wikis, though.
--------------------------
**Version**: unspecified
**Severity**: blocker",53477,2,High,True
-4.82124851182512,1.9430703684369242,-3.540418846430015,1.0979233343381094,4.162769113827322,1.2973998731238663,-0.6136077113037466,2.4564200860647336,-2.817825007808901,-2.5234008304658797,-0.1417275336988646,2.3550710090117732,0.15590022360566635,-1.7668941328399965,-0.6602365437600994,1.3403373191547328,1.0975570602602132,0.8903274403090664,False,c1,3,"Some scripts, among them Arabic, Hebrew, and most scripts of India and SE Asia, are written as combinations of consonants and vowel marks that combine with them.
In most text editors and word processors, when the cursor is after a combination of a consonant and a vowel, and the backspace key s pressed, the vowel is deleted first and the the consonant.
For example if you have the Devanagari combination गा (ग [g] + ा [a]), these are two Unicode characters, which the font joins automatically. If the cursor is after them and you press the backspace key, then the second character ( ा) is supposed to be deleted, and only then the first (ग). That is what happens in most text editors, including MediaWiki's source editor.
In the VisualEditor, backspace immediately deletes the whole cluster. This behavior is unexpected for most users.
To complicate things, when the cursor is before the combined character and the Delete key is pressed, the expected behavior is to delete the whole cluster. This is what happens in the VisualEditor now, and this must be kept like that. For cursor movement, back and forth, the cluster must also be treated as one character, so if the cursor is before गा and the right-pointing arrow is pressed, the cursor is supposed to immediately go after the गा. This also works correctly now, and must be kept.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49233
https://bugzilla.wikimedia.org/show_bug.cgi?id=53757",53472,2,High,False
-9.784547559122382,3.5108748921071076,-2.8595301245005196,0.28876072534941444,1.6764197667975473,1.4048494860777667,-3.2736571720885066,0.8075039591896039,-0.052148228507620686,2.7882675777729835,-2.9344880406571368,-1.6071607306403806,-0.03308971154740803,1.4320120501836264,0.049392868526210165,-1.1064789506246178,-1.7325414032609836,-0.4616593455023055,False,c1,3,"With bug 49931 we currently extend link annotations when typing at the end. This makes it very difficult to type plain text after a link at the end of a paragraph.
We should change the logic to stop extending the annotation once a character is added that produces a new wordbreak.
There may be some odd cases as wordbreak logic can depend on more that two characters, e.g. a' has a wordbreak but a's doesn't, so trying to add ""'s"" to the end of a link label would break after the ""'"" even though it wouldn't if ""'s"" was added as one operation.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51442",53463,2,High,True
1.828064749552753,-10.021196307812916,4.775771639787944,-1.9847275632332497,2.6961224512045163,0.7269719443813507,-0.980133581029178,1.681167973088924,2.405507149246368,-2.6142102379252057,-2.9189853531261334,1.5843011156440856,-0.6282148882716374,-0.3896976478412091,-0.8056283572108276,0.9208426461895577,0.16371047805937788,0.03526446033128816,False,c1,3,"See, for example, https://en.wikipedia.org/w/index.php?title=Peaches_Does_Herself&diff=prev&oldid=564544238 and https://en.wikipedia.org/w/index.php?title=Carl_Rogers&diff=prev&oldid=564544061 - this is kinda a problem.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T53509}",53462,2,High,True
-2.017667621831852,2.2433218397256383,8.617803900780892,5.283982082167966,4.731297843928266,1.5847597022357542,1.0821238089498184,-1.9125824814841699,0.26817983770775133,0.14150887293538617,-0.02390981275916637,-2.4165989602544453,-0.9353760533959745,0.7731038309057672,-1.1117670592753095,0.9112014510855068,-0.5888605457163089,-1.2535822733558852,False,c1,3,"When creating a new article in the source editor, a box with the message newarticletext appears at the top. It doesn't appear in the VisualEditor.
Compare:
source: https://en.wikipedia.org/w/index.php?title=Aklotspa&action=edit
VE: https://en.wikipedia.org/wiki/Aklotspa?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: trivial",53459,2,High,True
-1.7186053838194923,-5.886028172154209,-0.6397106861036121,6.4338333838263155,7.029116796409218,1.135916222368681,-3.1618971498470567,-0.304965744846246,1.1284636541010187,1.1436559901932828,1.5481307474677881,1.5168272612700175,0.3152122363501575,2.4651086691410926,-0.6847901261627669,2.652472125184647,2.9452166334408236,3.4943961638290784,False,c1,3,"1. Edit page
2. Focus a link and open the link inspector, have the link input widget focussed
3. Make a change (or don't) and click ""Save page"".
The surface dims, but the inspector stays open and at full opacity.
--------------------------
**Version**: unspecified
**Severity**: normal",53439,2,High,False
-2.731355974853744,2.6979820145313766,1.2926789932141176,4.461283730998592,4.424543269582079,2.672162218240304,-0.02488718095412601,-0.006463444783384897,-1.8134562947164252,2.6622154778155274,0.07385428251006987,0.7399993669587954,1.401561343113908,2.1537129628794203,0.05203489508623527,-0.957708759083957,0.12173490199718584,1.465456934843363,False,c1,3,"The link inspector ignores the text entered when the user does not wait for the ""matching page"" results to appear (Chrome/Ubuntu) before pressing ""enter"". If the user is adding a completely new link, the selection appears offscreen and we get a JavaScript error:
Uncaught Error: No class registered by that name: undefined
This behavior is similar to earlier issues such as bug 42278 and bug 49941.
--------------------------
**Version**: unspecified
**Severity**: major",53415,2,High,True
-2.380444525359673,-5.564882657561965,-6.022548498574299,-6.421637478472744,0.2403123122230547,-3.573674531017252,-0.43251300657053626,5.429452854654664,0.1449640031698226,3.5508929421642073,-3.8034587206821486,0.5444051342313174,-1.7259212255474443,0.6476530317669145,-0.043229490778474045,-1.6702470506290599,-2.346159340552621,-1.334822583394117,True,c1,3,"Templates should not have identically named parameters (""url="", ""url="", for example). Can VisualEditor be configured to note when this happens, if not outright prevent it?
--------------------------
**Version**: unspecified
**Severity**: enhancement",53406,2,High,False
-2.0025322497645517,-0.9965877905922511,-4.066929264566324,3.62588854925413,2.3796732330184702,0.9544733871339803,0.08884301661309557,0.5727148980575952,-0.03329145077559442,-0.16984108460978486,0.8543407911922385,-0.647794971666487,1.5989373500321822,-1.256794221296928,-2.969336285046185,-0.8555487635731365,-0.29773366430726966,-0.1439367519830448,False,c1,3,"* Edit a page
* Put cursor at the end of a line
* Go to toolbar and Insert new link
* The input field is focussed, blur it by clicking somewhere inside the inspector outside the input field
* Click the trash can (since there is no ""x"" close button, that's the closest I can find in the top left or right corner)
* The inspector clears itself but stays behind (crashes half-way closing)
Uncaught Error: No class registered by that name: undefined ve.Factory.js:62
ve.Factory.create ve.Factory.js:62
ve.dm.SurfaceFragment.annotateContent ve.dm.SurfaceFragment.js:518
ve.ui.AnnotationInspector.onClose ve.ui.AnnotationInspector.js:162
ve.ui.Window.close ve.ui.Window.js:281
ve.ui.Inspector.onRemoveButtonClick ve.ui.Inspector.js:89
oo.EventEmitter.emit oo.js:421
ve.ui.IconButtonWidget.onClick ve.ui.IconButtonWidget.js:61
proxy load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130715T175253Z:775
jQuery.event.dispatch load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130715T175253Z:3058
elemData.handle.eventHandle
An empty inspector stays behind and the user can no longer interact with any links at this point. When doing anything (scrolling, typing) the inspector will hide. Except the bubble tip on top, that one stays behind...
--------------------------
**Version**: unspecified
**Severity**: critical",53404,2,High,True
-1.3920516810645316,-4.87381813605854,-5.43422833675873,1.1385162946726703,-1.7754443374144984,-4.200475672568185,-4.219760787713225,-1.050626624241798,0.07756702186856429,5.237454412855058,-2.1238127184269278,1.3303297916641645,-0.3362184148969867,-1.4195786869448415,0.14175183487971843,0.393257704018795,-0.8504515359275427,1.9030429806856322,False,c1,3,"Screenshot of problem in local VisualEditor dev
The code [1] is using $status->getHtml() but apparently it doesn't work as expected because I'm getting raw wikitext.
""edit"": {
""code"": ""abusefilter-warning"",
""info"": ""Hit AbuseFilter: Blanking articles"",
""warning"": ""'''Warning:''' This action has been automatically identified as harmful.\nUnconstructive edits will be quickly reverted,\nand egregious or repeated unconstructive editing will result in your account or IP address being blocked.\nIf you believe this action to be constructive, you may submit it again to confirm it.\nA brief description of the abuse rule which your action matched is: Blanking articles"",
""result"": ""Failure""
}
To import the filter, use ""Special:AbuseFilter/import"" on your localwiki with:
{""row"":{""af_id"":""1"",""af_pattern"":""!\""autoconfirmed\"" in user_groups\r\n& new_size < 50\r\n& old_size > 500\r\n& article_namespace == 0"",""af_user"":""1"",""af_user_text"":""Root"",""af_timestamp"":""20130715214820"",""af_enabled"":""1"",""af_comments"":"""",""af_public_comments"":""Blanking articles"",""af_hidden"":""0"",""af_hit_count"":""9"",""af_throttled"":""1"",""af_deleted"":""0"",""af_actions"":""warn,disallow,tag"",""af_global"":""0"",""af_group"":""default""},""actions"":{""disallow"":{""action"":""disallow"",""parameters"":[""""]},""tag"":{""action"":""tag"",""parameters"":[""blanking""]},""warn"":{""action"":""warn"",""parameters"":[""abusefilter-warning""]}}}
[1] https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/a6b1dade840841ff7adf2ff289b6428f930d6796/AbuseFilter.hooks.php#L22-L57
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11585}",53403,2,High,True
-15.75918397214606,15.368324634920217,3.0729232748135864,1.88580818306353,-1.5995059348089464,3.9578868155903875,2.77894451117007,1.5245836586051262,4.464110298658027,3.7251946313113464,5.729761919588219,-3.856673456099304,1.7232307050350588,0.6109417853095529,1.1289640927443347,0.9524387771492708,-3.111413609833591,0.08590349788873186,False,c1,3,"Sometimes for templates, you have a pre-defined set of values to use for a parameter. Perhaps it could be a nice thing to expose valid values to the user in a drop down or something.",53375,2,High,
12.59100537456176,4.7679728775483845,-3.2900841789733466,-4.423365382952182,0.2079859130319338,4.56073568225025,-3.7547211632726514,2.314607367816189,1.7381623349825983,-1.5645577528895842,0.014929447129440554,-0.5193697044262358,3.6078522854880983,-2.1120805340361795,1.8107987972286628,1.2101342676042237,0.5316381653800377,-1.0321669640794724,True,c1,3,"Forked from T53314#557160 (bug 51314 comment 2):
The following should be set to use B/I, rather than the generic:
* cs Czech
* he Hebrew
* pl Polish
The following should be set to use F/K, rather than the generic:
* da Danish
* no Norwegian (and nn?)
* sv Swedish
",53330,1,High,True
-6.186505611213196,1.5966340085899855,-2.9998288089614675,-3.378202011932432,1.7266541468709082,-1.8137056480512692,-0.153776903394796,1.6848300877518305,2.2403241040498862,-0.9276324080762683,-0.18319540820905011,-1.689229217677497,1.0381019890472674,0.009728522979446375,-0.7705792257242283,0.11038096820225765,-0.1978973436666671,-0.09717908272141385,False,c1,3,"Some templates are only used to include metadata, e.g. categories. In this example http://en.wikipedia.org/w/index.php?title=Ashton_Agar&oldid=564224425&veaction=edit the document starts with two such categories, producing linebreak characters, with templates spanning 0 characters in between (accessible still be cursoring). An uninitiated user may just decide to delete this whole line at the the top, thus removing the hidden templates.
Perhaps we need to detect if a template contains no meaningful content and then move it into the metadata so it can't be accidentally deleted. We'd also need a UI for editing them though.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51420",53322,1,High,True
0.7057842897432853,0.4736060933697601,0.10817036699649663,0.44562555636122525,2.6999625879256013,-4.152917432514575,-0.6937464187739302,-6.619845744621204,-1.7003504401733716,-0.03319375069107533,0.4609907834297471,-2.695226771843269,1.233746400035487,-1.2484041644016926,2.019037505866784,-1.5609796707338284,0.47666788088248446,0.8796645066823621,False,c1,3,"**Author:** `wmdv`
**Description:**
I changed the word ""you"" to ""your"" by inserting an ""r,"" in [[Gerrit/Tutorial]], but the edit summary said I inserted 10 characters, and the [https://www.mediawiki.org/w/index.php?title=Gerrit/Tutorial&diff=prev&oldid=732497 diff report] showed about 15 lines, with various things shifted around. I was using Chrom on Windows 8.
I reported this on the support page, and 88.130.86.21017:17, July 13, 2013 reverted my edit, and suggested I file a bug report. [https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report. Support desk resolution.]
I have also been noticing that when a change comes up on my Wikipedia watch list, I sometimes have difficulty telling what an editor did, because the diff report is full of unmodified content.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report%2E",53304,1,High,False
4.387016482292964,0.6324818340751559,-2.1871808713811625,-1.5795282375523443,0.48947405781045505,1.4147553842177698,-0.8285884183990628,3.3694468891959444,-0.4963132856586272,-1.926851603927552,-2.100217440784423,0.39053932598417496,1.6366880528453658,0.3112490218287416,3.0683262921465078,0.8958437452699414,1.8492133118007377,-0.9504253743048803,True,c1,3,"From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):
Inserted images are formatted as right-aligned, and they can't be move to the left side of the page. Similarly, existing images that are left-aligned can't be moved to the right side of the page.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53293,1,High,False
-0.3336848530352228,-3.223355312055606,-5.191318614546592,0.9059931039982121,4.192420934190238,1.0666864326859573,-3.3687874904409676,-0.4824272462650335,-0.6262081476195336,-0.7926167115027956,-2.492692423709004,-2.2786994510632836,0.5509800430476397,-2.9103203904507637,2.4657352666833576,-1.6409068754608773,0.6666657497063959,-0.8870761103466487,True,c1,3,"From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):
VE allows the image to be dropped into the middle of a word. I moved the test image perhaps a dozen times, and this happened twice - that shouldn't be possible, yes? [The words that were split were ""addition"" and ""Israel""; when I moved the image again, the words remained split (with an end-of-line inserted).]
--------------------------
**Version**: unspecified
**Severity**: enhancement",53292,1,High,False
-6.2367558947964525,3.2590968973185497,0.4871750430735915,5.031850445681852,0.34243829891495003,0.5931970830160751,-1.4374380712691543,-0.7524694551465569,0.25239311589419333,-1.5214293007067798,-2.0035284354924796,-1.8226866615556288,1.148101019286826,1.1198514904842254,-0.3929557314945127,-0.03895912205344865,-0.12999242566461078,-0.8573352194400703,False,c1,3,"On Google Chrome on Galaxy Note 2
1. open VE
2. 'click' on a link
Results:
The text cursor appears at the character of text selected.
The link editor icon appears below the character of text selected.
The text cursor makes it impossible? to click on the link editor icon.
One solution would be to place the link editor icon above the linked text, and ideally place it always at the end of the linked text instead of at the character where the text cursor.
--------------------------
**Version**: unspecified
**Severity**: normal",53270,1,High,False
6.433007206268954,-4.502737314632887,-7.594142242877986,5.809426779121747,-2.4670053565540044,-1.710100232183521,2.861996916841089,0.48744011571827084,-2.091327116551688,-0.7049884672374871,0.36621050569346547,-0.0009342920679666911,3.0086127416498596,0.6038100062451823,-1.3009674154244264,-0.9002574877691165,-0.3456119539243103,0.0073580072693004706,False,c1,3,"tag_summary duplicates data in change_tag, but is missing some records.
Eg:
select * from change_tag where ct_rev_id = 563615370;
+-----------+-----------+-----------+--------------+-----------+
| ct_rc_id | ct_log_id | ct_rev_id | ct_tag | ct_params |
+-----------+-----------+-----------+--------------+-----------+
| 589674173 | NULL | 563615370 | visualeditor | NULL |
+-----------+-----------+-----------+--------------+-----------+
select * from tag_summary where ts_rev_id = 563615370;
Empty set (0.01 sec)
Cause unknown at time of writing.
Relevant recent activity:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VisualEditor_tag_not_working_correctly
https://bugzilla.wikimedia.org/show_bug.cgi?id=40867
--------------------------
**Version**: unspecified
**Severity**: major",53254,1,High,False
-2.5495956790913303,2.3056474184903877,0.4043830059085778,-1.4815891583520227,3.004131779758235,-0.11136034100850278,3.2328946818391673,-1.0872501449222007,-4.285326233530969,0.10040872892052644,1.180533696471485,0.588504399174709,1.2661275008508261,-0.551808313779194,-0.8140372896290264,0.6682779616162484,0.8850527816272742,0.6994814818458297,False,c1,3,"I'm not entirely sure if this is a VE bug or a user bug, but it shows up under the needscheck tag, so presumably the VE knows something is wrong. We have several instances of categories being stripped from articles, including:
*https://en.wikipedia.org/w/index.php?title=2013%E2%80%9314_Juventus_F.C._season&curid=39905874&diff=563942424&oldid=563942210
*https://en.wikipedia.org/w/index.php?title=A._Dakshinamurthy&curid=16805989&diff=563911982&oldid=563853744
*https://en.wikipedia.org/w/index.php?title=Body_Party&curid=38681444&diff=563891098&oldid=563879499
In the last 12 hours or so.
--------------------------
**Version**: unspecified
**Severity**: normal",53235,1,High,True
2.0379319313992137,-10.11800951652879,10.302006738990173,2.147659555394934,-2.624361434057284,1.955770601538929,2.352320075763912,-0.7598033480377614,3.222895725522874,0.9078395122735019,0.5796018380154857,1.059389673491934,-0.2536026750264888,0.24444955602932517,-0.671844722850504,-0.1788634706849913,0.6393482810571383,-1.6439388500870598,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=Hungarian_algorithm&curid=2609001&diff=563951525&oldid=561480423 - another instance at https://en.wikipedia.org/w/index.php?title=Shannon_capacity_of_a_graph&curid=39932177&diff=563933550&oldid=563846095
--------------------------
**Version**: unspecified
**Severity**: normal",53234,1,High,True
-3.8956423074422375,-2.5918973254366993,2.9855523123669876,3.0211083739928384,2.320068314546448,4.081209809358097,0.8478401724454905,2.2125657542928603,2.113396037632211,0.8459619398799401,1.8516012270499949,-2.5086121155255903,1.7072981236425684,-0.11717553859429763,-1.1080254581763844,0.39201241989071156,1.8207758317453842,0.6267756451100295,False,c1,3,"Following on from bug 50415, the old warning/error messages included the most recent & relevant log entry, and a link to view the full log.
That functionality does not exist in the VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50415",53215,1,High,False
-6.791475280367674,-0.4865687293918963,-4.206318335102484,2.4994148484708454,3.524235226943549,2.3640002066391714,0.7405196143944375,1.2152092032513595,-1.3438602188246105,-0.5057207163073594,1.958565946003223,2.5710135147120994,0.14377304403970914,-0.7573322272528378,0.004438601908193007,-0.3507173583626174,-0.1217157873220227,0.29990947754773223,False,c1,3,"The source editor transcludes [[MediaWiki:Editpage-head-copy-warn]] above the edit window. But this does not appear anywhere when using the visual editor.
Note this is distinct from [[Mediawiki:Copyrightwarning]] which appears (in a tiny font) in the edit summary tool. The two messages are not the same and do different jobs - the first is a warning that copyrighted content is not acceptable and content must be verifiable, the second is a statement that by saving you release your contributions under cc-by-sa.
--------------------------
**Version**: unspecified
**Severity**: minor",53160,1,High,True
-2.745840907573146,2.2398227289119355,4.249001148694838,3.540633698853603,-1.2852275627659897,0.10080348201215839,-6.062893232403129,-0.49618602393097055,2.483896070255139,2.2515591089854343,2.003306411007023,-1.7254861883799262,-1.7434862947681218,-0.306116308931748,0.9954121623105721,3.6500480134837714,-0.6907468190470462,0.17968343698457923,False,c1,3,"1. Go to
https://pt.wikipedia.org/wiki/Associação_Médico-Espírita_do_Brasil?oldid=36199569&veaction=edit
2. Click in the box in the top of the page and delete it
3. Click on ""Save page"" and then ""Review your changes""
The editor will add the code
<div class=""reflist references-small"" style><references /></div>
in the bottom of the page, as in this diff:
https://pt.wikipedia.org/wiki/Associação_Médico-Espírita_do_Brasil?diff=36364362&uselang=en
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51260",53145,1,High,False
-4.671282002075278,6.518338256671878,-1.4595491336815218,0.6249160415051327,-2.0675340771786166,2.3766893300481016,-3.299385591997285,-2.8853469709618844,3.573862432337049,-1.9702122261575425,0.05528429321391659,-2.5118917031984065,3.4981873226277056,0.8419189762244432,1.1388569921434746,-0.024389137288409246,-0.2138588465191713,-1.5008594263617048,True,c1,3,"From English Wikipedia:
In the template dialog, in the add parameter view, I would expect double-clicking on a parameter would add it, instead of having to find the add parameter button at the end of the list (which should, by the way, not be at the end of a scrolling
list, but always visible in a fixed place). --WS (talk) 12:17, 9 July 2013 (UTC)
Agree with this - it took me a while to figure out that I had to scroll to the bottom of a long list of reference parameters to find the button. GoingBatty (talk) 04:58, 10 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: enhancement",53143,1,High,True
-3.506560283054153,-3.8769349447383217,-0.8518324112031159,-6.5955131901831505,-5.832787637507783,2.0831264188244063,1.5387443684339468,0.3344166066681292,2.311646564628865,1.0392318248650918,1.5933006790451318,0.6119359238891446,0.7987091508332265,0.727471420917368,-1.6134946761944664,1.6632009843979345,-1.546825699477774,-1.074033858495762,False,c1,3,"Seems to happen specifically in https://en.wikipedia.org/wiki/Jabhala?veaction=edit for no apparent reason; try it.
--------------------------
**Version**: unspecified
**Severity**: normal",53140,1,High,True
-0.7401091606867904,-5.860291001930218,0.7795008365147638,1.5639521006499262,5.028912764791576,3.4419673113297247,-0.7724219466156796,0.4611694736348586,1.4417872921189987,6.4863265362145714,-2.9601269984416354,-0.6903034361272982,-3.143096076790421,2.521945244361685,1.6564642627323645,0.7758654606815615,-2.669265354128119,-0.05915642752941963,True,c1,3,"An English Wikipedia editor suggests that the ""remove template"" button should be in a section labeled ""actions"", not options. A non-native speaker, he does not find the ""options"" label intuitive.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51672",53135,1,High,False
-1.6861366594860683,2.9364002507744473,-2.653616401261104,-0.553496830797985,1.854415204946036,-2.222534621814952,2.637878536533779,-2.4850833668303496,-1.088175881625089,-0.8217604999757655,0.6510061469076276,-1.2698784953474123,0.3813694830629939,-0.44334509488856977,-1.294872703108875,0.9765041595902517,-0.49346661454575447,0.21596698849413376,False,c1,3,"**Author:** `p.selitskas`
**Description:**
Page where issue occures: https://be-x-old.wikipedia.org/wiki/%D0%93%D1%80%D1%8D%D0%B3%D0%B0%D1%80%D1%8B%D1%8F%D0%BD%D1%81%D0%BA%D1%96_%D0%BA%D0%B0%D0%BB%D1%8F%D0%BD%D0%B4%D0%B0%D1%80
When I change the first character of the link text by selecting it first and then typing, chess symbol ♙ replaces the original character. Due to bug 50678 not being resolved yet, I tried this way and revealed such behaviour. For the point, it's no matter how many characters are selected, chess symbol arrives if the first character in the link text is included in the selection.
It seems to take place in the lead part of the article only. When I change links in the tables and other sections of the page, it all looks fine.
Worth noticing: after I enter the editing mode and change the link in the first table header (text: Апошні дзень Юліянскага календару), it works like a charm, but as I press Ctrl+Z, it turns to «Апошні дзень ♙ліянскага календару», and I have to press Ctrl+Z once again to fix it back to the original state.
--------------------------
**Version**: unspecified
**Severity**: normal",53112,1,High,True
-9.003419521417243,2.202180566924241,3.8221832366137143,8.172891104680367,3.289914646402178,4.658993743181745,0.4370803081350365,0.6533851306868226,1.212182106879709,-0.8062657074946822,-0.20986942583172885,-0.1294857285703459,-0.008016034307508413,-2.467506101311566,2.2527735005691785,3.7584125143759617,1.521675483045972,-0.3731258009697216,False,c1,3,"Create a link and hit return before the input field in the link inspector is focused and the text in the surface will be replaced with a new line. Not linked text.
--------------------------
**Version**: unspecified
**Severity**: normal",53075,1,High,True
-2.7566651612654107,-3.730181765555413,-0.07090299618417717,1.3536411850820702,-3.382586945846133,-1.2882547646596678,0.36499141506364374,3.2706305697677904,-3.1730039178672325,-2.33329884308688,0.9318835557251002,0.15847388432121146,-3.8148450657476927,0.3499956275715359,-0.26961837572477165,2.531961290942183,-1.5612141866887865,-1.1491575982289972,False,c1,3,"If an image is formatted as [[File:foo.jpg|thumb]] rather than |BARpx, image resizing does not work.
--------------------------
**Version**: unspecified
**Severity**: major",53026,1,High,True
2.0327798201448064,-16.94182306133483,-0.7956141031705659,-1.0271713766219952,-1.6599455870961306,4.209705275954915,2.9441729956144878,-1.171982093868063,0.3141731583616978,0.2515685488898818,0.2738390089443432,-1.0340057840470789,-0.0649286199448591,-1.2156017537508257,-0.9614745583455573,-2.235846721348495,-0.3803336015844665,2.6240059922726946,False,c1,3,"Attaching screenshot...
--------------------------
**Version**: unspecified
**Severity**: normal",53000,1,High,False
-3.438784936224079,2.7992171313278504,-2.5364530274914223,-5.732999752776092,6.996731815550202,4.495289491177547,3.860816730132277,-4.866093757912943,-1.5595609569209332,1.7274139928976409,3.5721512278720016,2.6841602322162377,-0.04011930912291284,2.580824561873011,-1.792381710567485,0.2174218326741914,-0.3998066987428739,0.0756619851246112,False,c1,3,"Not sure if this is TemplateData or VisualEditor, please move it if I’m wrong.
If I edit a page where a redirection to a template is used, I don’t see the available parameters and other data that TemplateData provides, but the redirection works like the real template, so it should use the same data.
--------------------------
**Version**: unspecified
**Severity**: normal",52964,1,High,False
2.279975715797779,-0.4615083347587827,2.9244752395807794,-1.0814281382544455,4.654465801106673,2.9431441782783594,-3.4227853389230956,4.118050247419963,5.668999516495896,-0.5082069652979273,0.08085937329948223,1.3469936129315798,1.5043843063437978,-1.0507464569369187,-1.125186364815475,0.6049486736507568,1.7478390030030273,-1.7179879333704648,False,c1,3,"To reproduce:
* Edit a page with some existing content in VisualEditor.
* Press Ctrl-A to select the whole text.
* Press the Delete key.
Observed: The page cannot be edited any more.
Expected: The page doesn't have any text, but text can be added.
--------------------------
**Version**: unspecified
**Severity**: major",52947,1,High,True
-1.8519590012455445,3.678678940817221,-4.426574293995962,-2.5591658152985657,-0.9344922679582334,0.13761328864800704,-4.575796992607861,0.6970637274095717,0.19260846029445955,-2.7129421352540946,1.1497211564878849,0.0981446538416968,-1.5390185252067266,0.45193376420287024,-0.7261597761690588,-0.18386539769558763,-0.6957044336668091,0.6480272757888146,True,c1,3,"From a conversation with an English Wikipedia editor user Thryduulf, he says that when it comes to editing existing links (as opposed to adding new one):
***
there are three things you could want to do:
(1) change the link without changing the text (e.g. [[Mercury]] → [[Mercury (planet)|Mercury]])
(2) change the text without changing the link (e.g. [[Mercury (element)]] → [[Mercury (element)|Mercury]])
(3) change both (e.g. [[Mercury]] → [[Freddie Mercury]])
At present it seems that the visual editor always assumes you want to do 1, and unless you delete the link completely there is no way of doing otherwise..., but for beginners I'd say that 3 should be the default. There needs to be some way to set the target of a link independently of what is displayed, and I'm not sure how best to do that but maybe an option on the link dialog called ""display as"" or something like that would be the way to go.
***
(Please see http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563383564#Changing_link_text_often_results_in_bad_code.2C_wrong_links_and_unmatched_.3C.2Fnowki.3Es
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52240
https://bugzilla.wikimedia.org/show_bug.cgi?id=50678
https://bugzilla.wikimedia.org/show_bug.cgi?id=33091
https://bugzilla.wikimedia.org/show_bug.cgi?id=50452
https://bugzilla.wikimedia.org/show_bug.cgi?id=53973",52945,1,High,False
8.492900707219619,-4.920500326804577,0.3253445239338717,1.1143302203328287,-7.635084484710578,0.15049578893800097,-6.05215517073611,0.38842923347014113,-4.539138247047482,-2.617263260794565,9.04609103772109,-1.9457513366417842,-4.206366606376149,0.300527649915594,0.6160172348465576,-1.1499304457655635,-0.00040317429958736106,0.8918902400560851,False,c1,3,"Typing certain tag based code into VE such as:
<math>1+2=3</math>
<ref>Hi</ref>
Bug reported by [[User:Dragons flight|Dragons flight]] at https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Some_tags_are_not_properly_escaped
Confirmed.
--------------------------
**Version**: unspecified
**Severity**: normal",52944,1,High,True
-2.997897250377171,4.364682581483592,-1.2626294107251415,-11.83458547554238,3.6975847225128295,-5.840984977798315,1.1209747465191429,-4.438702146918692,-0.3237378166267432,3.760290972281597,0.3023574638688151,-0.4067081485064078,-0.9495701852899918,0.5247589538413182,1.0752071304132862,-1.8649881393560421,-2.342018891007443,-0.7138863600443581,True,c1,3,"Copied from English Wikipedia, where it was added by TeamGale:
""when I add the reference/template, if I want to edit it again it's not easy to choose it since the ""blue line"" that has to be on the text appears completely elsewhere and I can't click it. I took a screenshot""
See:
http://en.wikipedia.org/wiki/File:Misplaced_edit_for_a_template.jpg
--------------------------
**Version**: unspecified
**Severity**: major",52913,0,High,True
-1.0234389152610008,3.972204843495362,0.5962840956716029,1.6306152233700302,4.729318524931216,5.525432965299767,-3.7404637145057533,-1.3128157221419259,-0.8961369334328553,2.2690296479068603,1.2804690243515773,-2.7781196746265158,-1.0747404734553667,1.8054724567375926,1.2291343118711717,2.2666766084309375,0.06990282470707743,-0.937148117517058,False,c1,3,"Replication steps:
1. go here: https://he.wikipedia.org/wiki/%D7%A8%D7%97%D7%95%D7%91_%D7%99%D7%A8%D7%95%D7%A9%D7%9C%D7%99%D7%9D?veaction=edit
2. Click the box on the left (a 'street' template in the hebrew wiki)
3. The ""Transclusion"" icon appears on the right edge instead of the left.
Happens in Chrome and Firefox 22.0 under Windows.
I suspect this is again a problem with the flipped position settings. I will take a look in the code.
--------------------------
**Version**: unspecified
**Severity**: normal",52905,0,High,True
-7.184970890238034,-3.318507963780533,4.524328075971095,12.274165903774227,6.7986819432552,2.9345056712687603,0.9990220081023553,-2.7668016589709015,2.83920540031468,-0.9684438434274041,-0.21183100596977722,0.21976994945185102,-0.6490045058930862,0.5329909943622386,-1.437504536658758,-1.3457613797833443,-1.0579206600195437,0.9280646162655473,False,c1,3,"The character counter of the save dialog should have a tooltip/title explaining what the counter refers entails.
--------------------------
**Version**: unspecified
**Severity**: trivial",52902,0,High,False
-2.085825645381971,5.849643103679501,1.4924943008400255,-5.4248893872459965,3.317542265103842,-2.85644047435977,0.5355947846761442,-0.8316173876394461,0.5286189220025385,-2.045702187415033,-0.7796415653854472,1.4813408513221773,-0.6664512585366582,0.042916462544992484,0.49894626534443454,-0.0769120819474397,0.46042606053891433,-1.2554773835716282,False,c1,3,"screenshot of the dialogue
I added TemplateData to Template:X1 (this is a sandbox)
Then, I go to my personal sandbox User:Waihorace/sandbox/VE to try adding Template X1 to that page.
I pressed the button that allow me to add template (don't know its exact English wording)
It prompt me to enter a template name, so I typed in X1
Then, it comes out that the description is not shown, parma names are not shown, but the list of parma is given for me to choose.
Why the description and the name and description of the parma is not shown, while https://zh.wikipedia.org/w/api.php?action=templatedata&titles=Template:X1&format=jsonfm works?
( X1 is a template which will be cleared by a bot automatically. To reproduce, check if the content is still there or otherwise revent back to oldid=27156695 )
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50431
**Attached**: {F11387}",52888,0,High,False
-5.947768294113823,5.231187604015076,-2.330974761174005,-0.8136931710079855,1.9073802950629584,-0.36655899959247185,1.5621650313021993,1.0034666477907512,1.2671112346282567,1.5338048965578208,1.7873656047875524,-1.2522501017001666,1.587878855346235,-0.436437693046539,0.3345179266315048,-0.7890963521829324,1.1121488957169638,-0.7191949535540556,False,c1,3,"I've noticed a couple of times that users on VE/Feedback have said that they 'couldn't change the block and that it became blue', which I think is an indication they were unable to spot the template edit button.
Now I noticed that the edit button anchor for templates is always at the top right. On 100% width block elements, the content can often be completely left aligned however, and the button is then to the FAR right of the page, making it easy to miss.
For instance, take the {{Refbegin}}-{{refend} block on this page https://en.wikipedia.org/wiki/Warehouse_control_system?veaction=edit on a fairly large monitor.
It might be nice if we could come up with some idea to more intelligently place the button. if( block && !width && computedWidth > 160em && text_align == left) then align button left
Point 2:
Also, the white button on the blue mask on top of the white page is not the highest contrasting style. Styling it stronger might also make it easier to discover for users.
Point 3:
The puzzle piece in that context doesn't give the user much info. Why not a simple Edit logo ? I think that would be way easier to understand.
--------------------------
**Version**: unspecified
**Severity**: normal",52854,0,High,False
-1.9292809567008211,-3.665088401665354,0.9085793905231441,0.30510443002985266,0.9417062064053889,-2.816548786920004,0.15485980440807534,1.4781134909140827,1.0640250099321626,-1.884375675685198,0.04396779027854025,0.5410840664919307,0.7577577170085341,-3.5552608029020987,0.8280009502233776,-0.659534312115924,-1.6202595891755451,-1.3113939132160075,False,c1,3,"I deliberately edited [[Roller coaster]], an article under Pending Changes that had an unreviewed change, using my administrator account, using VisualEditor. When editing source, there would be an edit notice advising of the pending change, which is not present with VisualEditor. Nonetheless, edits by an administrator account are supposed to be automatically accepted. Instead, my edit was made subject to review. See screenshot at http://commons.wikimedia.org/wiki/File:CoasterCrop.png.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49699",52852,0,High,True
-6.331744559484892,-3.5107714771720087,-6.213335398429297,0.23457712726198765,1.7522160446248374,3.4829933066609193,-2.7091469842587483,-0.663109969309381,-2.995530563976823,-3.0546535392329845,1.8168757186239213,-1.7146836479724903,0.6293846294598127,2.4906168935753215,-0.2760263036881492,0.35937832550436166,-0.480875741836843,-0.5634203462357956,False,c1,3,"1. Put the cursor in the middle of a paragraph
2. Insert an image
3. The inserted image is now selected, and displays an inspector button
4. Click the inspector button
5. You get an empty image dialog and an exception because getFocusableNode() returned null
It seems this happens because the post-insertion selection in step 3 covers something like </p><img></img><p> rather than just the image.
--------------------------
**Version**: unspecified
**Severity**: normal",52850,0,High,True
4.900318418573047,2.9549337311410504,-3.506285026366406,-6.857409159215685,-1.49436123267219,-5.201208035549039,-5.123561960211305,-4.515940666274045,-3.936945962286268,-3.242804767107037,9.874273178568027,-0.014791023691839822,-6.335400652277397,-0.014521133874354497,1.338184022985466,-0.06199856149846833,1.1380539792185107,1.3215322750948915,True,c1,3,"Right now the following HTML entered by a user:
<p>Hello my [[name]] is Julian and I live in the city of Rochester, New York with my friend Sandy; we write [[books]].</p>
… turns into:
<p>Hello my <nowiki>[[name]] is Julian and I live in the city of Rochester, New York with my friend Sandy; we write [[books]].</nowiki></p>
… whereas ideally it should be minimal rather than maximal:
<p>Hello my <nowiki>[[</nowiki>name<nowiki>]]</nowiki> is Julian and I live in the city of Rochester, New York with my friend Sandy; we write <nowiki>[[</nowiki>books<nowiki>]]</nowiki>.</p>
This would significantly reduce issues with users accidentally inputting wikitext. We're taking actions in VisualEditor-land to discourage such input, but if Parsoid could help it would be hugely useful.
--------------------------
**Version**: unspecified
**Severity**: normal",52841,0,High,True
-7.224348050063799,-0.3390577691029577,-3.756378465821621,1.8183070049934442,-1.5794827528922561,-4.917907901588927,-1.216210867216657,0.9586191141711885,0.34302416725668905,0.8638898132831088,0.9331217768756708,0.027047396830693682,-0.9410644442765195,0.11626702684046197,-0.7957981712667888,-0.5511820271452041,-0.4159132785388291,-0.3632159550134628,False,c1,3,"see report here:
[[en:Wikipedia:Village_pump_(technical)#Heavy_Javascript_load_after_loading_some_articles.]] (bottom of [[en:WP:VPT]] on July 5 2013. if you don't find it there, look in the archives).
Initial debugging of the issue points to the function injectCSS().
as it turns out, ULS calls injectCSS() once for each required font, which, on some pages (methinks pages with many interwiki links, mainly) can be dozens of times.
apparently, on some browsers injectCSS() can be expensive (maybe the browser re-renders the whole page, in light of the new stylesheet information?) and calling it dozens of times causes high CPU load.
clearly, the right thing to do here is to collect all the different CSS bits and pieces you want to inject, and call injectCSS() exactly once.
this piece of code demonstrate what some people already know: injecting stuff can be habit forming, and can be bad for your health, so you absolutely want to minimize it.
(btw: the function itself is somewhat disgusting. how is it better than
function injectCSS( css ) {
$( '<style>' , {type: 'text/css', rel: 'stylesheet' } )
.text( css )
.appendTo ('head' );
}
// really no need to return anything: the single callsite ignores
// the return value anyway. anywho, you can prepend ""return""
// to make it behave more like existing code if you really want to...
peace.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=563037747#Heavy_Javascript_load_after_loading_some_articles.
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49935
https://bugzilla.wikimedia.org/show_bug.cgi?id=51073",52836,0,High,True
-0.9157296851872032,-4.16175205238663,2.8287820570305797,-1.0295859216826801,4.744036227061306,0.14689942487797225,2.996320849147387,-2.008045026870582,-3.8911731803939125,3.6644769177638796,0.8364200139678277,0.5557409999696696,-0.35378524827750457,0.38341878247980343,-1.1489294308421751,-1.361448406466569,-1.6195104977473898,0.4895152561032654,False,c1,3,"If a user hits the spam blacklist they VE responds merely by informing them ""Error: Invalid error code"". This is...not helpful.
--------------------------
**Version**: unspecified
**Severity**: major",52826,0,High,True
10.781052867472335,-7.712830422041577,5.52813733346418,-0.21528927398294928,3.8167025223840514,-0.4853872605820214,-2.6811744270115927,1.1454400399078088,-0.3775650175995303,5.075213740384017,-2.458522523410271,1.1048136733484262,0.14322025302286523,-0.16376763751807033,-0.5719523727690667,-0.4805864583086049,-1.6522191572294285,1.9759143836062523,False,c1,3,"Quote: Using Firefox 19.0.2 on Windows Vista, editing Relativity Media. Find ""subsidairies"", right-click, select ""subsidiaries"". The word appears changed, but the ""Save"" button is not activated.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63462
https://bugzilla.wikimedia.org/show_bug.cgi?id=63395
https://bugzilla.wikimedia.org/show_bug.cgi?id=59748",52822,0,High,False
-2.856127421824014,-6.236588108361143,-0.36892535904241086,1.7211332459403113,-2.6117725829764824,-1.8929908518886451,-4.326846579673206,0.15437154842897477,0.33831485977660125,-3.268496318878328,0.955490393592004,0.6831025609468429,-0.4872271110978703,-1.2190450298647666,-2.518127561351295,0.5411282200966443,-0.1534542333152673,-0.3858187513497633,False,c1,3,"Template inspector before closing
Wikilinks like [[Foo|Bar]] are shown expanded in template inspector after closing it, see screenshots.
Steps to reproduce:
1. Edit a template which has wikilinks like [[Foo|Bar]] as a parameter value
2. Close the template inspector, with or w/o changes does not matter.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/VRB_H_2/3
**Attached**: {F11204}",52801,0,High,True
1.138567106087239,-0.14421531969395218,8.957451062582141,8.256679127714222,-2.1771642626709857,1.3463606767087144,1.1243280992361617,-2.124895203809336,1.3062783259527895,-0.8906541525983913,-1.0743711241971408,-0.9322322931097519,-0.24009765067979316,0.2653197102868585,-0.41431589907294253,1.7046837384448168,0.9613437200351609,-0.013260506206218992,False,c1,3,"Screenshot
The text of the TemplateData description should have an line break (wrap into span and style per CSS?) in the template inspector.
Longer descriptions flows out of the template inspector box, see screenshot.
Related: Bug 50656 - Parse wikicode and/or HTML in interface text
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11203}",52800,0,High,True
-10.120261793533647,2.7656210922313065,-2.0112188239561224,-1.7765943874096788,4.057198746181616,7.488103934655297,2.8007823483955887,-3.965541905273439,3.253422200034204,0.7413205539406915,1.9809229327977964,0.9551957624276286,-1.34620796414774,2.8399567552366873,0.8793659762887094,0.554579194641564,-1.8975644327189842,-1.9036067177957092,False,c1,3,"At the moment the only way to close a page notice is to click on the interface element that launches them - which feels somewhat counterintuitive. Could we have a little close button in the notices themselves?
--------------------------
**Version**: unspecified
**Severity**: enhancement",52799,0,High,False
-6.622826884569308,1.9115234676383182,-3.9382681669317297,2.8299890741264426,5.171474313224161,4.04341631847543,-1.2206104283232824,0.25004048253348654,-1.625397053894623,-1.525929331364246,-1.3376587356017728,0.4774704082401924,0.958315522753955,-1.3658137125101213,-0.8784706223015153,0.880504639423587,0.38472704582619355,-0.20489836445322585,False,c1,3,"This happened on MediaWiki, he.wiki and en.wiki on Chrome.
Open some article for editing (preferably a long one so the effect is seen)
add some text in the middle or end, mark it and make it a ""Heading"".
Observed result: The text turns into a heading, but the entire edit section scrolls up to the top of the page. This is especially annoying when the page is long and when the edit is done in the middle.
--------------------------
**Version**: unspecified
**Severity**: minor",52792,0,High,True
-7.411963215208024,5.010112863372683,0.06607852733730013,2.091422372839108,-0.6454759255111034,4.816103718212007,-0.3152327983872194,3.1005234455370565,-0.13703165162703143,0.009743586085234845,-0.6434198415750902,0.2874351302872953,0.4699050574721113,-0.9169729910215514,-0.26785622983059465,-0.006317051867597401,-0.4389646995051866,-1.2115689789206119,False,c1,3,"**Author:** `turingt`
**Description:**
At the Transclusion dialog, after a click or double-click on the chosen parameter, nothing happens. Is the user expected to click on the ""Add parameter"" label at the top? To press Enter? To read the user guide for instruction on how ? None of these steps help.
This is a usability bug - the actual button is hidden below the fold, at the end of a very long list that is not intended to be scrolled through, and thus hard to discover. The button should be always visible in the dialog - otherwise, the dialog becomes unusable with long lists of parameters.
--------------------------
**Version**: unspecified
**Severity**: normal",52774,0,High,True
-10.57730481841616,3.875607705939899,-4.5342792266788585,-1.626389299530857,-0.16999481287082624,-0.21499925735851222,0.6245504981938712,-2.1418977551346248,0.21162198084267503,-0.4155928252604335,1.0228674636233896,-0.6209361989690448,1.8630158490649853,-1.1808722180584095,-0.025213086377712024,-0.6031695670037541,-0.34027052795467094,0.059044001593484774,True,c1,3,"Especially when a template has many parameters;
scrolling until you find the actual button to add them,
having to add them one by one and having to do so by clicking each time on the name of the template itself to get to the list again, it's confusing users.
There's already a bug about mandatory parameters not being enforced; I am not sure of the behaviour related to the order of the parameters, but it would be great if the editor could keep them in the same order they're being chosen with. Thanks :)
--------------------------
**Version**: unspecified
**Severity**: critical",52773,0,High,True
-9.86873136895425,5.470178986539967,5.140651848074359,6.672739570573279,-1.606461144159625,1.3556762313782131,1.4735543814329919,-1.9280652791630017,-0.5259804259145914,-2.060083846850817,-2.5124403813753666,0.036064419699798345,-1.5102843478971542,-1.4262052438714923,1.046418538140344,1.165986996958864,1.9654839060041904,0.8423956825129906,False,c1,3,"The existing editing interface stores data on hidden categories, and on the templates in use. This is not displayed in the existing VE - it seems like the sort of thing the page settings page might be good for.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52763,0,High,False
0.2252711610575333,-10.137009743013717,3.8179647184314867,1.5239295225877196,-3.120741289886998,2.8465280624113625,1.2613956704623304,-1.3322326590293443,-0.6652236299970653,-0.7196619044806427,-0.6934743622189945,-1.4163982847659222,0.26447659239249166,-2.0527419931915576,-0.700133975461747,1.608295442815361,0.4835958967791072,-1.6368725932321893,False,c1,3,"In this case, https://en.wikipedia.org/w/index.php?title=Long_Island&diff=562848384&oldid=562113547 - oh dear.
--------------------------
**Version**: unspecified
**Severity**: major",52754,0,High,True
2.3514664927720603,-0.11050710755790227,1.6753199555132845,2.642361449305205,-0.4976081141302042,0.23012510254706697,-2.4919778412214644,0.8819872821927738,-1.3890553286897829,1.3469499930933635,-1.3081781662609573,-1.797036681733486,2.9010787361538615,-0.6201665338524842,1.0844784807136394,2.9143095247324116,-1.1858847588323327,0.10671700288398633,True,c1,3,"Copied from English Wikipedia:
A similar bug was reported as #49536 , but closed as fixed a while ago. Article Otto I has a reference (""ref"") to ""Thompson"" (numbered #11 in old edit mode) inside an explanatory footnote ""efn"". The notes are generated below the article using ""notelist"". Ref 11 Thompson is not included in the reflist of VE, but shown in regular read mode. Just compare the reference lists in read and in VE edit mode to see the difference. GermanJoe (talk) 13:03, 4 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51289
https://bugzilla.wikimedia.org/show_bug.cgi?id=52398",52749,0,High,False
-2.5149976116609682,-1.1032140462794118,-1.0191729362305662,-1.8580164977684388,1.6776673170137237,-2.424065785587353,-0.0875987236729392,1.2279646922131842,0.5515990848454846,2.309692227868445,-1.426439743885665,1.7469537101125605,-0.5183324640231284,0.28545017313496857,-1.1661579453037074,0.6649802536948224,0.8054502612847696,-0.5202818222078207,False,c1,3,"TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60358",52747,0,High,False
-5.309565326060795,1.7954349051250915,-3.8045544799465976,-3.069972907449266,0.2907887323563121,6.148554375425805,-1.6416473796139641,4.2503064799772705,-0.4575697726685724,1.2077717442132823,0.24620414808413082,0.9761962853548167,2.146335903797188,-2.3954042400972204,0.9374411108654463,-1.5493272277488601,1.7768398091276392,-2.324254746969898,False,c1,3,"http://en.wikipedia.org/wiki/File:VisualEditor_-_Cite_template_layout_issue_%28TemplateData%29.png
Tested on Firefox 22, Mono skin:
'''Steps to reproduce'''
* Open any random page in the visual editor.
* Add a new template - use Cite Web for this.
The output will be akin to the screenshot added. Some the template parameters end up next to each other, and are thus offscreen. Even if that is not the case the description will often be to long to be displayed. Would be nice if those ended up on a new line if that occurred.
--------------------------
**Version**: unspecified
**Severity**: major",52728,0,High,True
-4.61657397139147,-4.580569580711394,-0.8994715440819014,0.2176778132159456,1.4205429833735517,-1.1144527074562733,-1.1306044489838287,0.02812570052508534,0.3609590221842235,2.000775249757,-1.4629625670829978,-0.009849509218203378,0.3790209251882173,-2.0207467070821346,0.5377572690487309,-0.4904991573035069,-1.4203165495605594,-0.68887676101163,False,c1,3,"When your edit trips the blacklist or an editfilter, you get a very technical and uninformative message.
The edit filter causes: ""Error: The notification you tried to make was aborted by an extension hook"" to show in the 'save' dialog.
The URL blacklist: ""Invalid code error"" apparently.
https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562806113#Blocked_sites
Since this is quite common for newbs to trip, it should be handled better.
--------------------------
**Version**: unspecified
**Severity**: critical
**URL**: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562806113#Blocked_sites",52727,0,High,True
-1.804448680308833,-5.920328750364121,-1.1276893761989086,-1.6210500952345823,5.486990995633244,-5.356006329079318,2.3590118962934588,0.7836922936028029,-0.833090142169509,-2.3238467865012162,0.3939634743743592,1.2199035697576857,-1.2231344613335313,-2.599176796701368,1.3705220567934342,1.225874219781943,2.7589371545687493,-0.5824082564522055,False,c1,3,"This broke during yesterdays deploy. Now shows <accesskey-ca-editsource> and no key is set. I think Timo fixed it already, but the fix might not have been deployed yet.
--------------------------
**Version**: unspecified
**Severity**: major",52725,0,High,True
-5.55033587786774,2.336310997733932,1.323193562790678,-1.9641265467756148,2.0981662692030536,-2.5387062389902555,-3.4214193199438276,4.458389946931941,5.622340394372282,1.2253035219178061,-0.11520018681617339,-0.5645395257995102,0.14110405643316604,-0.1955836114657492,-0.7048033664397755,1.247806930188939,-0.5451910930975633,0.7460359542519883,False,c1,3,"Steps to reproduce:
* Navigate to [[Mariposa botnet]] and edit the page in the visual editor.
* Make any textual change - just add ""Test"" somewhere for example.
* click ""Save Page""
* Adding a reason doesn't matter. Just click to close the save page popup.
* Immediately open it again (Don't click anywhere else)
* Try to add a text as the reason, then press backspace or delete what you just added.
For some reason delete and backspace won't work anymore. My guess is that the backspace is send to the editing canvas instead of the textbox - try the following steps as well:
* (Do all the steps from the first section)
* Press ""Review Your changes"".
* Wait for the review to load, then press ""Return To Save"", and close the resulting form.
* Now click the search block (In mono) and enter a random search criteria.
* Once entered, try to remove it again.
What happens for me: Entering data in the search box works fine, but pressing backspace somehow causes text to be removed from the article, instead of the search box i was just typing in.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49569",52722,0,High,False
-3.69070012768952,1.0849864874271198,-0.8319290225774747,-1.3040859431589236,2.877307926771526,1.724195093799149,-2.2522795605036476,-1.2749248599983591,2.854142120654534,1.8739749862335158,-0.14488191166989095,0.2785324252241712,0.709752285292609,-0.5858264346332822,0.12727625723696967,1.1531312550223216,0.01586546047999504,0.49148979864797293,False,c1,3,"(Tested on Firefox 22, Monobook skin)
Steps to reproduce
- Go to the ""The Damned Thing (short story)"" page and edit it with the visual editor.
- Go to the ""Gothic elements"" selection, and select all the text from ""Gothic elements"" (Header) to ""inadequate."" (Last word of the section). This should also select the image.
- Click and drag the entire section, and drop it of before the ""Analysis"" section (Just drop it right before the A in that word, make sure the text entry | is displayed. The image itself will be gone. But for the fun part: Click anywhere on the editing canvas text.
Suddenly, your entire input screen will be white. What seems to happen is that the image is blanked (Replaced by a white square) and plastered full size all over the page. You can try to drag it away, but each time you try it will replace itself over the pages content.
https://en.wikipedia.org/wiki/File:Visual_Editor_-_Giant_White_Image.png contains a screenshot of the problem.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50643",52721,0,High,True
-2.137638463586944,1.8429317357356432,-0.3941309172915002,3.7244589635723253,0.6921169713719677,-1.086407686513188,-0.8341460028570902,1.3396960414603725,-3.74401021924755,4.132186266806679,-1.8406646151751533,-1.7089030581362157,1.6329525009642287,-0.173501125293412,1.13884433438555,-1.1543147273463326,-1.6470259077954528,1.8710294956314464,False,c1,3,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.
e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.
Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:
case {{Unsigned|Foo|April 1}}
case {{Unsigned|1=Foo|2=April 1}}
typing ""1""
> addParameterSearch-select null [""1"", ""2""]
> addParameterSearch-select ""user"" [""1"", ""2""]
> ""Add"" is enabled
typing ""user""
> addParameterSearch-select null [""1"", ""2""]
> addParameterSearch-select ""user"" [""1"", ""2""]
> ""Add"" is enabled
case {{Unsigned|user=Foo|timestamp=April 1}}
typing ""1""
> addParameterSearch-select null [""date"", ""user""]
> addParameterSearch-select 1 [""date"", ""user""]
> ""Add"" is enabled
typing ""user""
> addParameterSearch-select null [""date"", ""user""]
> addParameterSearch-select null [""date"", ""user""]
> ""Add"" is disabled
The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).
Also weird that the callback is constantly triggered twice, once for null and once for the actual value.
Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.
--------------------------
**Version**: unspecified
**Severity**: normal",52717,0,High,True
-1.84845294532074,-10.18223463132557,-3.753934348047869,-3.9171875237456977,-0.6748509306287933,4.381483016798898,3.139726890578646,3.1182879274484225,-4.578052724110544,-0.15741158729394655,0.8675294952537467,0.9423150730025858,2.8032765973867395,0.8967996098479736,1.72496370500704,-2.3360266362521926,-0.009323718463753794,-0.35587811688603743,True,c1,3,"Split from bug 50540 which is entirely different. :-)
--------------------------
**Version**: unspecified
**Severity**: normal",52692,0,High,True
0.9132890061971657,-1.0333677841617543,-4.266350583384408,-3.3559348348546667,4.749106315852373,-0.4309992408524582,-0.17049714929913495,0.4822794247091079,0.10640538547654427,-1.4789219200985628,0.4065914132240418,0.5361998461329405,2.307633347711034,0.9797223787497922,-0.8977355185563045,-0.06553325950675754,-1.3790673594427836,0.14244601542797608,True,c1,3,"Copying from English Wikipedia:
Okay, this one is probably quite tricky: When editing the source code, if an edit conflict arises, you can simply hit the back button, copy the code, and paste it into the updated version. However, with the Visual Editor, this is no longer possible. The content goes away, so you have to re-add it all, which is a huge pain if it involves references and other templates.--¿3family6 contribs 18:25, 3 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47779
https://bugzilla.wikimedia.org/show_bug.cgi?id=52519
https://bugzilla.wikimedia.org/show_bug.cgi?id=56465",52687,0,High,False
2.5372770978984653,2.9945273547748883,2.7873578316098246,0.14598842994210393,4.274998234149818,0.4351705189265982,-3.8446666629034483,0.9154198297247093,-0.8047807237416048,-0.8514739860058351,1.595325865730843,-2.6174690291514473,-0.3147747239711087,1.8701477975078058,0.7701119499342557,1.856443297345454,2.694698003078428,0.8076536488437143,True,c1,3,"From English Wikipedia:
'''Steps to reproduce:'''
* Edit the [[Vogrie House]] article in the visual editor.
* Resize the image. Larger or smaller doesn't matter.
* Press either CTRL + Z, or undo the edit using the undo button.
Instead of undoing the edit, it suddenly enlarges the image object. The image is placed in the center of the screen, and the object itself even overlaps the main navigation in the Mono interface. Of course as always: Firefox 22 used to test this. [[User:Excirial|<font color=""191970"">'''Excirial''']]</font><sup> ([[User talk:Excirial|<font color=""FF8C00"">Contact me</font>]],[[Special:Contributions/Excirial|<font color=""FF8C00"">Contribs</font>]])</sup> 18:03, 3 July 2013 (UTC)
See screenshot:
http://en.wikipedia.org/wiki/File:VisualEditor_-_Undoing_a_resize_issue.png
I tried on Chrome on a Mac, and it didn't work there, either, but instead shoved the image to the left of the screen
--------------------------
**Version**: unspecified
**Severity**: normal",52682,0,High,True
2.9851926531759623,-11.738627695392363,7.352976153352955,-1.434456732480278,-6.128090892314049,4.5280770359029985,3.49459774021589,-1.1033286733807772,-1.0679680789766142,0.9200567472766634,0.12075917652499557,-1.7673523882378634,-0.998188311529181,-0.7535463898322474,0.6887573927985535,2.502543457196308,-0.42270338084266124,-0.2446686378023215,False,c1,3,"In https://en.wikipedia.org/w/index.php?title=List_of_socialist_countries&curid=7252916&diff=562675715&oldid=562675131
--------------------------
**Version**: unspecified
**Severity**: normal",52659,0,High,True
4.326870216817907,-16.317490188340763,6.51701991193211,-0.9478483310339998,-1.347457850035386,2.604618282827408,2.9715858450485504,-0.04887905016881597,4.371777307550583,1.7521605310124642,1.472029850431714,1.7111768271131098,-0.18815446954747106,0.7477505718788793,-0.34536965921501483,0.5412928297846197,-0.4429915204200132,-1.160928575850554,False,c1,3,"See https://en.wikipedia.org/wiki/File:Visual_Editor_-_Overlapping_issue.png
--------------------------
**Version**: unspecified
**Severity**: normal",52652,0,High,True
-8.584158423789809,-0.0848054988871656,-5.141420220081921,-3.949157427006651,6.171085126304298,-3.7734122539048656,0.3632595219715906,-0.6959775212180808,-0.5109962318918734,3.682626355723169,-2.38698028967406,-0.07062808794530562,-2.412143752570593,2.689283798571214,-0.8943583821166357,1.2271608808473329,2.623561212431853,-0.5108859905989209,False,c1,3,"What it says on the tin; if you resize an image, it with reports ""this isn't a change, can't save"" or saves and silently doesn't do anything.
--------------------------
**Version**: unspecified
**Severity**: normal",52645,0,High,False
0.9946820802029062,0.6869625814052593,-1.1189078186496175,-1.173631896291111,-0.7373995472599546,-0.7696261858615586,-2.3705504094052814,-1.5575729589556615,-0.4909824905580305,-0.11777515452683751,3.165641861233176,-0.8594372430906554,0.8239662503198684,-1.1437604877931742,0.1891395613212712,-0.689836117970908,-0.5762702117300341,0.2294944245031505,False,c1,3,"From https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE_adding_spaces.2C_messing_with_citation_access-dates:
I noticed something odd when using VisualEditor. I decided to use it when snooping around for various ""it's"" typos, for removing apostrophes seemed/is faster with VE than the old fashioned way. However, some of my edits seem to have done more than take out apostrophes. Seven times today ([http://en.wikipedia.org/w/index.php?title=Highcroft_Racing&diff=prev&oldid=562630195] [http://en.wikipedia.org/w/index.php?title=So_Emotional&diff=prev&oldid=562630132] [http://en.wikipedia.org/w/index.php?title=1988_in_British_television&diff=prev&oldid=562629968] [http://en.wikipedia.org/w/index.php?title=Olmaliq_FK&diff=prev&oldid=562629768] [http://en.wikipedia.org/w/index.php?title=FC_Jazz&diff=prev&oldid=562629613] [http://en.wikipedia.org/w/index.php?title=Brian_McDaniel&diff=prev&oldid=562629235] [http://en.wikipedia.org/w/index.php?title=Highlights_(band)&diff=prev&oldid=562629182]), VE added an extra space in a random place in the article (if it's hard to tell, on the last one it added the space right after ""its""). And then it altered references on [http://en.wikipedia.org/w/index.php?title=God_of_War_(series)&diff=prev&oldid=562631132 another], including changing access-dates. I don't think that's supposed to happen... [[User:Greengreengreenred|<font color=""#014421"">Green</font>]][[User talk:Greengreengreenred|<font color=""#50C878"">green</font>]][[Special:Contribs/Greengreengreenred|<font color=""#66FF00"">green</font>]]<font color=""red"">red</font> 02:25, 3 July 2013 (UTC)
Might be a Parsoid bug based on selser tracing. There seems to be only a single space both in the original and the edited HTML.
--------------------------
**Version**: unspecified
**Severity**: normal",52636,0,High,True
-4.920090974221815,3.417650418796601,-3.396389296642081,-1.0621967167591908,-2.840035786776232,0.04408954314882818,-1.4963842979952808,-0.40368121030801424,3.370495638723008,-0.3463530148121663,-0.358432006505812,-0.4668753900325471,-0.6836501059037063,0.5283158389911202,1.2436714905149149,-0.7224824723280021,1.0871326053202928,-0.04544186629318414,False,c1,3,"This doesn't mean that all of the integration needs to be independent (save dialog etc.) just the initialisation.
It used to be that the integration was only initialisation (instantiate the editor with the html document to edit, basically only up to a dozen lines of code) but it has become much more than that.
We need to separate integration and initialisation (initialisation will be part of the platform specific integration, but code-wise it should be the tip of the pyramid, not the bottom), so that our MediaWiki initialisation should be completely isolated so we can load it from the <head> and it will do only 2 things:
1) Browser compatibility test (bug 50608)
- May depend on jQuery and a few plugins
- May not depend on any VE classes since those may break in our subset
of supported browsers (compared to MediaWiki/jQuery)
(if passed)
2) Perform our changes to the interface to avoid flash of ""pre-init"" state
- Edit tab (bug 50542)
- Edit section links (bug 50540)
- Handle setup/teardown of VE from either clicking an ""Edit"" link
or by url query.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50677",52612,0,High,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: normal",52608,0,High,True
-9.153531032543496,3.636782921397078,-0.2636652537378783,-3.3503782305313377,-7.485338305871114,-3.7896526942284483,2.263665956587187,-1.208065171255545,5.156157132291094,0.7737713893488216,-0.015569010224118163,2.808249059861029,-0.6688298132418833,1.0662287897020954,-0.2934550596555283,-2.2450296225037683,0.07827178868000972,2.048099888219215,False,c1,3,"Check page settings for https://en.wikipedia.org/wiki/User:John_of_Reading?veaction=edit - it's probably not necessary to have language linking for userspace, but if we're going to do it the ability to distinguish sandboxes from articles would be good.
--------------------------
**Version**: unspecified
**Severity**: minor",52565,0,High,False
-3.3843347061349336,1.6199123423900375,-0.8934501959445011,0.04386502366294254,1.5103482118949736,-1.2815364940498395,-1.0757505099335045,-1.7141071987165106,2.4640072128618193,0.24665716748345368,-0.3907909781056236,-0.807168787594799,1.1922299148995186,-1.0574169054083504,-1.1558551128757646,-0.9031193878122137,-0.3402728204570238,-1.3228973423423949,False,c1,3,"**Author:** `Thehelpfulonewiki`
**Description:**
Page notice overlaps the close button on page settings
I tried to edit Barack Obama using the Visual Editor. The page notice came up - which is fine - but then I clicked on the page settings without dimissing the page notice and wasn't able to dismiss the page notice. The page notice covers the close button so the only button I could press is ""apply changes"" to causes the page settings window to go away, allowing me to hide the page notice.
I was told in #-visualeditor that you can click anywhere in the notice itself to dismiss it - something I didn't even consider doing because that's not standard behaviour for notifications (considering Facebook and even Echo). Please can we make the page notice dismissable by clicking on the ""1 notice"" area, even if you've got the page settings window up?
See attached screenshot for an illustration of the problem.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49059
**Attached**: {F11576}",52545,0,High,True
0.5792829770553856,2.2723185248975675,0.34120548308514387,0.46766809986725155,2.920011085513575,0.2897246816573058,-0.1305712313962326,-3.9760606309244455,1.179113277557478,1.717055120659726,1.4245704487770463,0.5968956413761908,-1.7974475322346724,1.0168009800338051,0.2205313560916622,0.17304336621127617,-0.5208427227343099,-1.3317571233629468,False,c1,3,"Inside an RTL wiki, if you set your interface to English (or any other LTR language) you will see that the '[edit | edit source]' links are jumbled.
(Example: https://he.wikipedia.org/wiki/%D7%A4%D7%99%D7%96%D7%99%D7%A7%D7%94 - use English interface)
This is probably again a case of bidi isolation. I can take a look at the code.
--------------------------
**Version**: unspecified
**Severity**: normal",52543,0,High,True
-3.479938783274473,0.8327626837981921,-0.29188753073241536,1.6990887790943114,6.0739264522185366,-0.8703986316447649,0.5809655838703192,7.145710518771836,-1.3706972793538224,5.64757847188107,-1.543731645564286,-5.880508738554515,-1.0467488419608753,-0.571571667005264,1.33544799208516,-2.106237292678585,-3.1961858155275493,1.0273612647284642,False,c1,3,"The ""Edit source"" tab loads/renders a little bit after the ""Edit"" tab, sometimes more noticeably so, sometimes less. Relatedly, clicking the ""Edit"" tab very early on sometimes invokes the wikitext editor.
It would be preferable for both tabs to be rendered simultaneously with the correct default behavior.
--------------------------
**Version**: unspecified
**Severity**: normal",52542,0,High,True
-2.9317263682231807,-1.657560795294712,4.245750084374674,0.24186951310860105,1.0637995358950245,1.0034868653134723,-1.2424683581579368,0.8163714862151997,1.1339520880727225,2.755996788535665,-2.0381804351968063,1.769829246099767,-0.9129593165778811,1.538210680821427,-1.488041818674163,-0.5853035148604465,-2.5790837744910853,-0.31264739851774515,True,c1,3,"A long-standing editor feels that the delay before the ""edit source"" option in sections disadvantages those who wish to bypass VE. Is it possible to have the ""edit source"" link visible always?
See:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562471642#Very_slow_and_featureless
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56337",52540,0,High,True
-6.858346585109904,-0.06274735943229004,-4.9228424528941765,-1.6625344969623606,5.980377711064481,0.9593148875013655,-1.5277399278848263,-2.5194483535167222,-5.8864200836885,2.4067996693314253,-3.811212094358199,3.8147038139270206,-0.5643063536416966,-0.626091822328692,0.4026889767386832,-3.810513807887134,-0.6892450833857074,1.6304264654699236,False,c1,3,"A firefox 5.0 user is reporting that blacklisting simply isn't working - they're seeing the VE, broken. Their response to ""are you spoofing user headers"" was along the lines of ""what the heck is that?"" which answers that question.
--------------------------
**Version**: unspecified
**Severity**: normal",52534,0,High,True
5.847224496250536,-10.550823355618483,2.692531333792097,3.1677915962561363,-2.5030278632752627,-0.9061089075055939,0.9734582493428885,-1.052070040490463,1.7299593250067533,-0.7181875313824353,-0.6691258629662644,0.13561213173099107,0.6254049272802065,-1.8575181817807387,-1.6024499358655135,-0.8568260388276714,-0.3650407868776535,0.4322425372769467,False,c1,3,"**Author:** `rachelqa99`
**Description:**
enter erroneous text for existing reference
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:Rachel99/testing_070113?veaction=edit
**Attached**: {F11502}",52520,0,High,True
-8.087873685626189,6.49893093731426,3.5036518243566697,-5.08077017925625,1.6686552515964173,-1.2441738516742382,2.589949451718266,0.8241283816880857,-0.47749760690926857,-0.15485702788514466,0.01156852625837379,-1.555586221915477,-0.7434201982217994,0.0848172799185587,-0.1589961789811607,-1.3599098346674985,-0.06259866659806379,-1.6818284212135752,True,c1,3,"I suspect this may be related to an existing bug, but if so I can't figure out how to find it.
Looking at the very bottom change on http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562259398, we see the first in a series of edits where editing elsewhere adds duplicated characters to a template that I don't believe is being edited directly. (Further duplication occurred in these edits to the same page: http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562359846, http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562363670, http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562363840)
--------------------------
**Version**: unspecified
**Severity**: major",52502,0,High,False
-6.092451688962175,1.4998392000932217,-1.5805417951100331,2.7173665302082832,-1.285151789009735,1.622560699455106,-0.07117827304474833,-2.948892551288764,-0.8283573059449576,-0.9693734838773502,0.0543467194533398,-1.4503247743635743,1.483874333687838,-1.4143391489277657,-2.9465186675838484,1.3227053240574411,0.7316430373798679,1.0339838661694356,False,c1,3,"Screenshot of list indent problem
If I add indent to any list item, it breaks.
The indented line gets moved to the end of the previous line.
The live-changes looks as it is working properly, but the edit-diff (preview your changes) always shows it as broken. (See attachment)
Confirmed with:
* Firefox and Chrome,
* with ordered and un-ordered list items,
* with items added to the middle of a list, and to the end of a list,
* and with both new items added to a list, and existing items given increased indent.
--------------------------
**Version**: unspecified
**Severity**: major
**Attached**: {F11420}",52483,0,High,True
-2.9759129331068532,-2.50602336693086,-0.4291813360098722,-10.838290288012269,-7.4712030243885525,0.5744444789371681,3.447762655453329,-3.3832581682399128,-1.1314437068221883,1.3948051600848252,0.1550095424025386,-0.3478218951409997,-1.1119288716351488,-0.30606266011663585,2.083527761616029,0.18511522296477467,0.34604010609616087,-1.3996359239815503,True,c1,2,"As per http://www.mediawiki.org/wiki/Help_talk:VisualEditor/User_guide#Discoverability .
Might be handy, since we're pretty much beginners with it.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52476,-1,High,True
-1.0690303341656429,1.0818999372958764,-3.9492811378004617,-6.6466115560216075,6.192476741430706,1.0178432853270827,0.7044322427209604,3.085218219706744,0.294853432296299,-2.316265318789659,-0.14036043264597842,-0.4480877530195011,-0.5691467703523703,0.6807707428867023,3.255383531798576,-1.7496926140461557,-1.1850326122508432,-1.2614724624063482,True,c1,2,"[Forked from the more general 50350.]
Currently when AbuseFilter blocks an edit made with VE, the only response we can display is:
| The modification you tried to make was aborted by an extension hook
When bug 32216 is done - AbuseFilter is changed to use the APIEditBeforeSave hook - we can display this significantly more nicely.
--------------------------
**Version**: unspecified
**Severity**: major",52472,-1,High,True
3.8007350383815077,-2.5926867403907234,1.5733354574205407,-1.5519483665707878,-0.4938130337926293,-1.700205019541054,-0.6637535883010006,0.6380419787768179,-1.267223028624909,1.906798587768149,-1.505423423419534,-2.2328898676210396,0.8257485296491454,0.9119349573130986,-1.156200988832473,0.7783012470607681,-0.8582539076146672,0.3487302350962487,False,c1,2,"Screenshot
See screenshot. Firefox 21.0, Windows XP. As well as misplacing the toolbar it's also hiding the 'create new source' on articles with lots of sources.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11391}",52471,-1,High,True
-5.753688906932071,-0.9917447002781277,-3.1429621699749486,0.4829820682211865,2.5826025581097896,-0.09218647256681667,-0.5404447324182291,0.14889055328025602,-2.050258755257549,3.6217991581979803,-0.6862740217870535,0.7839785438828175,0.7134549924331037,-1.0691547069228804,-1.5742567544338737,1.5811029524835372,1.8634399507990735,2.1392585562761663,False,c1,2,"The formatting icons of the VisualEditor toolbar are currently ""B"" for bold, ""I"" for italics, the chain for links and the remove icon to clear formatting.
This series of icon seems to indicate that links are a kind of formatting. However; ""Clear formatting"" doesn't affect links; it only removes bold and italics.
Either links *are* a kind of formatting, and the ""Clear formatting"" action should remove them, or they aren't, and the Link icon shouldn't stand in the middle of icons that add and clear formatting. The current order and behavior are confusing.
--------------------------
**Version**: unspecified
**Severity**: normal",52461,-1,High,True
-1.8267615140366855,-3.358323279569877,1.119242020651761,-2.33428415985893,0.522353306578974,0.7194037215212623,1.2591447154608222,2.1082867577148785,4.399821131615694,-0.1766637224256229,0.0025523955505386553,-0.027199684493449672,-0.49927588054967664,0.5890099963007325,-0.12288515117466492,-0.3625202339294552,-1.2202966677148372,1.8343122296139198,False,c1,2,"It is currently not possible to add a reference to an image/media caption, nor to edit existing ones.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52427
https://bugzilla.wikimedia.org/show_bug.cgi?id=49657",52459,-1,High,False
-6.434956871623756,5.947568101363583,-2.3252727047937416,-4.968833711716035,2.472545847194812,-2.8330742872377526,-1.2793112793413126,-3.1890961431536122,0.730023136515102,1.7935705060792895,-0.7642120281066127,0.5947081288359375,0.0786326361620997,0.4976003224170853,-0.9376102011819736,-0.16401639860192896,-1.1776841279295904,1.0662672897177086,False,c1,2,"Screenshot1
There are, I think, some UI improvements to be made to the reference editor - User:Popcornduff gets credit for these :).
When you first open the reference editor, you're presented with something like screenshot 1, which asks you ""What do you want to reference?"" If the user is coming to try and add a new reference, this is highly confusing - the first UI element they're presented with prompts them to put time into a series of actions that cannot possibly end with them finding what they want. The cue also doesn't make clear to any user what the search bar is actually doing - filtering existing references. It seems like the blurb here might need changing to align it with what the search bar actually does; ""search existing references on this page""?
If you click ""create new source"", absolutely nothing happens - it's a highlightable element, and after a bit you can puzzle out that it unlocks ""create reference"", but it's not immediately clear. Still, you end up with it highlighted (see screenshot2). The blurb in ""insert reference"" is rather confusing; what am I inserting? I'm here to /add/ a new reference, I haven't written it out yet. My suggestion would be to have ""create new source"" take you straight to the source creation interface using a one-click mechanism, rather than having it free up ""insert no references"".
Still, you click it, and you get to screenshot3, of a window tagged ""reference content"". Quoth the user, ""Is it reference the verb - am I referencing content here? Or am I giving content to the reference?
What is the Options heading all about, and what does ""Use this group"" mean?
I have a little window here to type into. I'm not sure what to type. Do I just write out my reference in Wikimarkup and click ""Apply changes""? Or do I write them out as if I'm writing a list of references at the end of an essay?
At this point I'm really disappointed. I was hoping to be given a complete list of individual fields to fill out - a box for author, a box for date, a box for date accessed, a box for the title, a box for the URL, and so on - and have this generate the reference nicely for me. Instead, I seem to have the old system in a confusing UI.""
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51848
https://bugzilla.wikimedia.org/show_bug.cgi?id=53590
**Attached**: {F11364}",52458,-1,High,False
-4.0630000357809966,0.47813677959749157,-3.3720185078406093,-0.4896340243046293,4.0198131781230195,1.4346283104551267,-1.59513016920135,2.2467805120656643,0.7875074273865939,-1.6345853016252128,-2.0216908986285667,1.206704054481188,0.22453293072939573,-0.2499462177364178,-1.849853057564109,-1.4144943867892952,-0.2614151169130636,-2.795855110328909,False,c1,2,"When adding a new link to an existing page, the text is automatically capitalized, even if the user entered the text in lowercase. Many links don't need to be capitalized, so users shouldn't have to clean up after VisualEditor decides to capitalize them.
Note that when you're adding a new link to a page that doesn't exist, the inserted link preserves the capitalization that was entered by the user (which is the expected behavior)
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50945
https://bugzilla.wikimedia.org/show_bug.cgi?id=50678
https://bugzilla.wikimedia.org/show_bug.cgi?id=50745
https://bugzilla.wikimedia.org/show_bug.cgi?id=53566",52452,-1,High,True
-6.337716590512663,-1.47372248205148,-5.914936949156097,-1.162081405263078,0.7292233354141484,3.0638797504844355,-4.018876231571706,1.6621483751904038,0.9028030086225751,-0.30659184893106595,-0.3851819432940333,-1.3488398244070672,-1.54348324547842,0.35128918587553315,-1.5554539888032357,1.3972710749960378,0.8101939876778015,0.37118404446710707,True,c1,2,"If the cursor is in a slug and you press the link button, the selection jumps to the nearest content - which crosses out of the local <p> and into the <p> beforehand or afterwards (whoops).
Link inspector should detect that it is in a slug and not attempt to mangle the selection with nearestContentOffset, but just trigger with a 'blank' selection.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52256",52446,-1,High,True
3.142289321812702,-1.9317750407280094,-7.026059312073979,3.2966243466220293,1.1242696514527148,-2.534682050135774,-3.248134587864273,-2.28958856585312,-1.4723651363070998,-1.7570400088106712,6.676387766944163,-1.0838788635316843,-3.9314929590002388,-0.3378082568426768,0.47767494256228815,-0.5119738057283143,-0.17025465828700348,-0.8033196805552854,False,c1,2,"If you have a page like:
<ref name=""foo"">Foo</ref> ...... <ref name=""foo"">Foo</ref>
VE will normalize this to:
<ref name=""foo"">Foo</ref> ...... <ref name=""foo"" />
The contents of the second <ref> tag are obviously ignored, but we should round-trip their existence correctly.
http://tools.wmflabs.org/visualeditor/dirtydiffs/2013-06-30_00-52/Genetic_history_of_the_Iberian_Peninsula.png
--------------------------
**Version**: unspecified
**Severity**: normal",52444,-1,High,True
-9.024516539756814,2.1107452789061867,0.694507773622437,0.5216602515161144,2.9338350232299693,-5.613646816760902,4.336541157724457,-3.9803556656567127,-0.24368924656362395,-1.5746019364765842,0.03850414447865136,-3.083563023866331,-0.59139719468235,-2.9761135063678044,2.5445295903215266,-1.9492568060445024,0.34182977892190514,1.1985849362631111,False,c1,2,"After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template
test I made on beta was {{test|name = hello}}
--------------------------
**Version**: unspecified
**Severity**: normal",52440,-1,High,False
-2.89606213764449,0.49826677372701944,0.09942288864472815,2.540586894071819,3.462195244502341,0.579727613572069,-2.490169709657524,-2.73961728363917,-1.5435575480272115,-1.845299320093169,0.419201960893528,-2.2716340890397553,-1.1701524320589245,-1.4110628498789874,1.5151009819712193,0.1998786788973736,-0.014699975899717277,-0.4987506602419356,False,c1,2,"After I added the <templatedata> to [[pt:Template:Referências]], I opened a page in which it is used, setting ""uselang=pt"" and ""uselang=pt-br"" in the URL:
1) https://pt.wikipedia.org/wiki/Arte?veaction=edit&uselang=pt
2) https://pt.wikipedia.org/wiki/Arte?veaction=edit&uselang=pt-br
In the first case, when I opened the Transclusion dialog (by clicking in the references section, where the template is used) the template description was shown (as expected). Typing one of the template parameters, I also get its label normally.
On the other hand, for the second link the user language (pt-br) was different from the content language (pt) and the user see no description and no labels.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50888",52431,-1,High,False
-2.849344935222052,-4.507449572590081,1.833769520517265,0.690178204956432,-0.12026468389745215,-0.031415000290023976,0.17057574731146374,3.2181071394005776,-0.3007878496536707,5.076056501564649,-0.13433440942602104,-1.5002469366208797,0.7852653674654908,-1.8870081986358338,0.3357223460410932,0.22578048198860468,-2.277108876991634,-0.0380134753460184,False,c1,2,"VE is missing the red ""semi-protected page"" box seen at
http://en.wikipedia.org/w/index.php?title=Muscle&action=edit and probably also the equivalent one for administrators on fully protected pages.
They should be displayed as a ""notice"".
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51215",52415,-1,High,True
6.178568760427476,-9.311661668787734,2.6114073974919414,-1.1395969191483397,-1.9175182545777159,-0.3662796726805728,0.6726201584168514,2.365034650824825,-0.9857338307342917,-0.5199870824316681,2.60600735650469,1.8345234733044242,0.9655337899008867,0.8259213959031175,0.20102462556683776,-1.3792703834260254,-0.8750893590829573,1.0919388900315565,False,c1,2,"Possibly related to Bug 49892, VE is inserting random <span> parameters.
See:
https://en.wikipedia.org/w/index.php?title=Ruger_P_series&diff=next&oldid=560801075
--------------------------
**Version**: unspecified
**Severity**: normal",52392,-1,High,True
-2.006896758524791,4.31252740909418,2.911691732971395,1.8103648638347734,-5.321155209354368,1.0795638098673346,1.4823717498870677,2.7338060299723597,-0.48352405230371975,0.023966087844244477,0.32334439748156596,0.3602696866060793,1.560499740097761,-0.31875099449896194,-1.8062882807390968,-2.4644168729750837,-1.852756430513784,2.4078734773294563,False,c1,2,"On a CAPTCHA-triggering edit, VE does not display the CAPTCHA, instead showing an alert:
Error saving data to server: Failed request: error.
Marking critical, because VE is in use by 50% of new users at enwiki, none of whom are now able to add external links for sourcing purposes.
--------------------------
**Version**: unspecified
**Severity**: critical",52356,-1,High,True
-1.1423526794817058,0.23815271533043259,1.5227492092225816,-1.6753726464906107,2.8411202699902254,4.034839630569692,1.4680259296061964,-0.8971475213121396,2.1757887475745994,-1.0163184934435519,-0.4504427459719693,0.149482821006516,-1.301962312618829,-0.5118869872800067,2.3129175374057613,-1.5506463625700366,-2.6759547148703313,0.4549862940002296,False,c1,2,"When attempting an edit that is disallowed by AbuseFilter, you get a browser alert:
Error saving data to server: Unsuccessful request: The modification you tried to make was aborted by an extension hook.
Instead, VE should show a less cryptic message specific to AbuseFilter.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52350,-1,High,True
4.076213750913363,3.026810629531891,-2.7609697702495524,-6.693036515977511,0.11079512564505412,-0.20328330587973764,-0.3264818664733591,-1.4625787204390859,-2.018500070016821,-1.7478274024475215,0.05329050519464751,-3.0952478873719294,2.0329640633991892,-1.7459464413383063,-0.8817169983790691,1.8233610890080707,-0.21537044201015676,0.8327523404890746,False,c1,2,"VE's behaviour is not as expected when I invoke my own IME for entering Kannada text. If I press Enter after typing some text, it creates a blank line above the current line rather than below the line. Some conjuncts also get dissociated and show sthe constituent Unicode character instead of the conjuncts. I am using Windows 8 and Firefox (ver 21). I tried using the built-in IME as well as Baraa IME. in both cases I could not use the VE for typing in Kannada.
--------------------------
**Version**: unspecified
**Severity**: critical",52346,-1,High,True
-0.7151188151351526,-3.7218379902038947,-2.08935556050794,-2.331076655576939,-0.4226491204951456,4.6728833202233435,-0.8690869626350564,-3.8040719117104365,1.913871169273712,-0.8018662679539745,0.3203286275648196,-3.286508625340936,0.6013488000871456,-2.392846889343234,0.961543000899491,3.222545634930471,0.07136775887380198,-1.8058733973649648,True,c1,2,"As Rob spotted, we should (re-)place the cursor in the block.
--------------------------
**Version**: unspecified
**Severity**: normal",52338,-1,High,True
4.219653063584696,-8.540248646025596,6.331209456505043,8.34916221943942,-2.1282008077074694,-6.56117115959624,0.5903503978500337,-0.03097147626551572,2.1813949986086545,2.276137426672199,-2.2224097269530665,0.12683582086085043,-0.468072698581401,-1.2187268173252557,-0.7402573620901824,1.2292223327082583,-0.3867769507077268,-1.5441676596407552,False,c1,2,"Example diff:
https://en.wikipedia.org/w/index.php?title=FC_Dila_Gori&curid=6581323&diff=561887535&oldid=561367008
Works in Parsoid:
echo '{{commons category}}' | node parse --wt2wt
{{commons category}}
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50120",52332,-1,High,True
20.575841188430335,-9.91006881009918,1.4348506399112928,-2.4864283047866698,0.34577680400469957,2.1185769968125507,-0.9297064573789768,-0.8587861728189575,-0.7534375228328136,-1.3421266023325078,-0.20842813987185727,-0.8644729840375174,3.496794841661937,1.007521720090736,0.7195921169562123,-0.3072010832372981,0.13232897272938327,-0.09315036773445073,False,c1,2,"Screenshot
Screenshot - FireFox 21.0, Mac OS X 10.6.8
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11044}",52324,-1,High,True
-4.05883106154307,6.8433465041790775,2.705297623128704,-1.060817658837754,-0.6957650333873836,-1.0782644106874946,1.2742391029563835,4.572203763261663,0.7457996785209164,1.0208903773456566,0.734342320607384,-0.12639806885020488,1.2399896775500547,-0.7466288546868078,-0.8174154994210738,-0.989013867290649,0.0415111856711432,-0.2161259340554056,False,c1,2,"The VisualEditor doesn't currently have a mechanism for inserting special characters - while a lot of them are unnecessary (`~~~~` for example), things like en and emdashes can be quite important for content.
**See Also**: {T13130}",52296,-1,High,False
2.3602232400149705,-7.088953781021163,3.408387376283777,-1.4488645037884147,1.075189769259023,1.3983546671789104,-1.7787309968111638,2.0424691571457703,2.8942571896470026,-1.3992571275271763,-0.9831210956897873,-1.4927801112209917,1.1568636494992695,-0.9605800240173252,-2.59867806386215,0.8459633505677547,0.07587030239755,-0.7263639264962591,False,c1,2,"Screenshot
See the screenshot; before and after the backspace, respectively.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51624
**Attached**: {F11902}",52286,-1,High,False
2.244143097129697,-8.442125438814891,-2.703017107157585,-0.7308748993868857,6.937925532414964,2.4480872694716806,-0.5630375777612953,2.769664138748359,1.3057419776487538,-1.4352905779554304,-0.4029944404888579,1.987721460247114,1.816003975882674,0.9257797274517037,-0.8703967172136107,0.8092040969255634,0.7347612904197904,-0.6344363018080388,False,c1,2,"Screenshot
See screenshot. The template inspector overlaps not only the document (that would be good - see 50241) - but the toolbar.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11898}",52285,-1,High,True
-3.525315874982892,5.757920248084481,0.7133149978766653,-1.562034435478219,3.3536909919540117,1.722828914137432,-1.8113717203111692,0.7901001787067455,3.7582206166649774,1.179259256839675,-1.8495063277639712,0.32060851687776526,-1.1309188432442445,-0.31991185080295814,1.6559954584924492,-1.7195727651325363,0.04013397652006967,-0.06304179783099317,False,c1,2,"Not sure if this should be filed under VisualEditor or Translate.
When clicking the ""edit source"" button on a translation or a page that uses the Translate extension, it isn't possible to edit the wikitext directly; instead, the user is told to use the Translate extension to change the content.
When clicking the ""edit"" button on a translation of a page that uses the Translate extension, it's possible to edit the text with VisualEditor. At first, I thought this was a feature, and that changes would be propagated to the Translate extension, until I tried to save the page and got the following error:
Error saving data to server: Unsuccessful request: Unknown error: ""tpt-target-page"".
If VisualEditor can't be used to edit those pages, it probably shouldn't lead users to believe it can :)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48891
https://bugzilla.wikimedia.org/show_bug.cgi?id=61218",52284,-1,High,False
-6.372468519421936,4.16378608005758,-0.9932169687104615,-2.8916071448338716,2.322836393647254,2.6954274532185654,0.10533382940481939,-5.277436860000354,-1.5712621811572318,2.323156517040786,4.582629567609617,-1.8475108132476858,-0.5346778301884445,-0.1781645056742942,-0.7336094659039754,-0.7835918817685246,0.9838300303666665,-0.3316322530781324,False,c1,2,"It has happened to me several times that after a simple edition VisualEditor or Parsoid breaks the ""</ref>}}"" at the end of a reference template. I still don't know which is the pattern, but at least this time I realized it:
http://ca.wikipedia.org/w/index.php?title=El_Chornaler&diff=11962426&oldid=11962407
Other times a second editor had to come after me fixing the broken template. In the preview before saving everything looks fine.
--------------------------
**Version**: unspecified
**Severity**: normal",52271,-1,High,True
5.18515931034217,-1.4374329502044105,-2.822832543886687,-8.100486119732583,-8.563841469587919,6.011252187537957,3.094468252300346,3.747829906170981,-2.3651375815819637,1.2839532640382165,0.7686914421426314,0.13896289710975052,1.7874603863104577,0.7453344589187196,2.124580987348568,0.47177710287229574,1.2101641367542897,0.2527807316493911,False,c1,2,"http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version shows extension Campaigns not updated since 12 June, but should be current as of https://gerrit.wikimedia.org/r/#/c/69841/ at least.
--------------------------
**Version**: unspecified
**Severity**: normal",52261,-1,High,True
9.71936958019606,7.435223521020735,1.895996084374147,1.4641673072906483,-1.337970195544622,2.6724019411210618,3.1670536168472685,-4.554239483273188,0.15145157941356385,0.7596641739015828,1.1671925303218367,1.1368378118690774,-0.6437240337741255,0.13611337899573606,0.18072242256547266,-1.626956490723914,-1.3967990705175357,0.1702233177702508,False,c1,2,"if an article starts with
==Foo==
Bar Baz Fizz Buzz
It is impossible to remove ==Foo== without having the paragraph take on the h2 markup
--------------------------
**Version**: unspecified
**Severity**: normal",52254,-1,High,False
-2.7938734927783946,-6.781533824469247,-0.8518596980144899,2.5936474719336506,-0.9145100322328154,-0.7966320002582953,3.5038243320725977,3.8210595706733255,0.6269924105527662,1.0397040151753911,0.8140837301479786,1.7156874947500784,1.4241553810740166,-1.2501452085796974,3.372751270980756,-0.8943125030553853,0.46563302466906675,-2.4844697408622376,True,c1,2,"Link shows a diff made post-deploy doing (what happened to be white-space only) normalisation in two templates (that weren't touched). :-(
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/w/index.php?title=Pgeezy&curid=38061582&diff=561709972&oldid=561568473",52253,-1,High,True
-3.7639883003620933,2.8449567102776108,-4.219819809190996,-1.2230064883647755,2.775996423979647,0.03094790093691646,0.011590119624916184,-4.091696431916719,-0.12628634035374456,0.6876200590273784,-2.9674255502708613,1.8772009103835983,-2.251457255805952,0.9453495825879594,0.6274218198536605,-0.12349176918937971,1.9439069358171654,0.4827415757588869,False,c1,2,"I want to get rid of jobs on the master instance and have them all on slaves. Master is currently gallium.wikimedia.org which also have a slave installed on it and named 'gallium'.
This is a tracking bug.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",52228,-1,High,True
-4.5089069200695135,-9.150054474264271,-4.969965981810823,-2.7448960544266523,-7.594294047003485,2.0056510909049976,2.266124002464026,-3.1109918377064933,-1.0578450806916835,3.6908964333981835,-4.702980332663252,-4.532698270058033,-4.63074558289014,0.632552175936576,3.4746615962999803,3.264319774007438,-1.9126752829328992,0.9123403702257218,False,c1,2,"e.g. ""menuitem"" for options in our select widgets.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52203,-1,High,False
-1.2125160972205453,-1.789217691048158,4.783624287535989,4.027299084350046,-1.9901749926889414,-2.40916403875229,0.7663013106506398,0.29266831696146745,0.38052337865034414,0.28027100620562617,-1.5456158611915949,0.4060810128539718,0.023697236006602118,-1.8719183776402946,-0.5190486600127402,0.9721572758044446,-0.9757663337324054,-0.16043259814111255,False,c1,2,"**Author:** `swalling`
**Description:**
This tour step should only be shown in read mode.
When starting the guided tour via the ""Show help"" help button with GettingStarted, guided tours thinks I am in read mode and displays broken steps, rather than skipping to the appropriate editing steps.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11708}",52186,-1,High,True
0.528522294966967,-4.975318157770831,-5.303827615883929,1.4991546826125668,-1.9431471885398042,-2.1281684851572367,-0.3745563507128882,0.6336646876147732,-1.4413828236999888,-0.11084699072229665,-2.717674786844091,-0.07162684759946569,0.761421899214862,-0.5195093656186689,-0.7880323720118749,0.8541119267973168,0.02921635010266832,-0.06806069485906119,False,c1,2,"**Author:** `p.selitskas`
**Description:**
Dash-to-underscore conversion is frucked up yet again?
When ""Edit"" is clicked, an API request is issued with params:
action:visualeditor
paction:parse
page:Новая_зямля
oldid:1630719
token:[screened]
format:json
Response: {""servedby"":""mw1141"",""error"":{""code"":""parsoidserver-http-bad-status"",""info"":""404""}}
VE works at be.wikipedia.org, but it doesn't work at be-x-old.wikipedia.org, bat-smg.wikipedia.org, and maybe other sites with dash in the site ID.
--------------------------
**Version**: unspecified
**Severity**: major",52173,-1,High,True
0.7786877694961025,-4.7811221391335526,-5.283420493431253,-3.1348014705075964,1.3703495947534443,4.576890361313278,-1.5912588133653323,-0.6880544509498588,-2.9017126584761463,3.1465399060893056,4.405069995767789,0.4040678189998965,2.3417743341444552,-0.5511653876218814,-0.21600946005979704,0.9511105197017437,-1.056396516925437,-0.7479350265850144,False,c1,2,"1. Edit [[mw:VisualEditor:Sfioj]] in VE
2. Make a selection such as
These [words are] very bold
or
These wor[ds are ve]ry bold
3. Click the ""Bold"" button on the toolbar
The selected text goes extra-bold, in Firefox 21.
I should mention that in my case, the font is Arial, which has an extra bold ""Arial-Black"" variant.
--------------------------
**Version**: unspecified
**Severity**: normal",52170,-1,High,True
-1.7917730081751555,-5.195165150954935,-4.093646189109078,-0.46884939213074595,-0.6027710843354307,0.07407015532959083,-1.251061265816654,0.8347316367940191,-1.279055012698761,-1.4025029895432777,1.2556616127538232,-0.44524433279244313,3.1246959541554338,0.5108481219092971,0.058250821853446766,-0.3700029705701463,0.031805043635307007,-0.7089523786377605,False,c1,2,"Groups of consecutive images are alienated under certain circumstances.
It might have something to do with the wikilinks in the image caption, however I really just have to throw you some testcases:
---
(1) Works fine:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493135&veaction=edit
(2) Similar, but doesn't work:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493351&veaction=edit
(3) All three groups uneditable, even the group that is identical to (1) above:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493252&veaction=edit
(4) One group fine, the other alienated:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493194&veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal",52165,-1,High,True
-2.138396378788098,3.081649234805756,-5.496920025255115,-5.15069797714573,-0.41338296624654586,-0.9569178357732079,-0.7492343572681417,0.14063130919105804,2.459894796182817,0.045530583925144086,0.5352108407636846,0.011646704982548606,1.5120455281334504,-1.9369008951960325,-0.5959915902057098,0.10797965850669392,0.9753225052306214,0.9523198089114555,True,c1,2,"http://it.wikipedia.org/wiki/Utente:Syrio/Bozzoli, we tried changing the author's name in ref.6 to ""abbé Paul Guérin"". VE allows editing it, but after clicking twice on Apply Changes, the former name is still displayed and the page can not be saved as the button does not work. (Also, it does not allow us to re-try immediately or to edit other references, you need to reload the page for that). So I did a dummy edit to plain text, and I was allowed to save then, but the result http://it.wikipedia.org/w/index.php?title=Utente%3ASyrio%2FBozzoli&diff=59659908&oldid=59651683 has nothing to do with poor abbé Guérin.
--------------------------
**Version**: unspecified
**Severity**: major",52161,-1,High,True
1.0355017582313653,-6.216051168466064,1.7058577174321137,0.6015505967897834,-1.1452557756434927,0.77094964849776,1.973205432716247,2.3147030182120694,-1.6254271413092065,0.5531689918104625,1.8255369808157078,0.6982621355830658,3.6363126662886884,0.25635888022491926,-0.9887184767644674,-0.3328148791540011,0.23989908515427683,-0.23256066763604433,False,c1,2,"Screenshot
Image dialog shows thumbnails twice, see screenshots.
Maybe 1 from local wiki and 1 from Commons, which are most of the times identical?
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11660}",52158,-1,High,True
-0.15835998841826227,1.3517907871880315,0.41915809622980404,2.9706355289598756,-2.6173270968801443,4.733631716530311,-2.5908136492457756,-0.4350303448054731,-1.2299060829736663,5.076958674504974,-2.3995524528223138,-4.269676962811074,0.26455160135213696,0.8850839260596803,0.2279742192949703,-1.255834383098776,0.954100687649204,-0.020451006872490796,False,c1,2,"**Author:** `brassratgirl`
**Description:**
See this diff:
https://en.wikipedia.org/w/index.php?title=Uganda&diff=561452947&oldid=560332103
adding a sentence to the lede section saved properly, but also had unwanted behavior of cutting off the first letter of the first word of a random paragraph in a later section (removed 'l' from ""Lake Kyoga"" under 'geography').
Firefox 21.0 on Ubuntu 12.04.
--------------------------
**Version**: unspecified
**Severity**: normal",52149,-1,High,True
-5.326829315760563,-2.435227759569953,0.4658645022397181,-3.9449792396685237,6.79844841492149,-5.22055141255812,3.891490208547302,2.0860774354882423,0.8465554816269816,-0.29404078875502115,0.7712544511433843,-4.974631110104731,-0.78656126212804,0.49799194962945137,-1.079726039229282,2.354434333363291,-2.175710541141137,2.3578059815438897,False,c1,2,"They're currently enabled on page load. Even when dismissing the notice and clicking around in the first paragraph it stays.
It finally disables itself after a node change (e.g. click the second paragraph and then back).
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44083",52141,-1,High,True
0.978698389898994,-17.87030840447756,-5.219350553128887,-2.57528116654891,-2.0435789281839716,5.860753879418819,3.0268900872052873,-0.6512663811995079,0.16230830206961455,0.5663839272797055,0.45979096968325317,-1.299343307635873,-0.15673968058057675,-0.4254804839054538,-0.5862718735158783,-0.48794828011230706,0.0694679201695978,-0.29366603853991413,True,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: major",52132,-1,High,True
-0.002804348698020931,-7.5915522302094836,-3.7301465148568695,12.094416544175475,-3.9350608652620256,-5.2604081689836,3.78959546577292,0.9111149619536184,0.20444063245381994,2.382111598337757,2.5353165302834637,-1.1622490843775897,4.180733913954938,-0.34450121492926655,0.4806351914890996,0.5009126343639716,-1.2678432913985769,-0.7290694942755513,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Richard_Ned_Lebow&diff=561410032&oldid=545013166
Perhaps unrelated to VisualEditor?
<!-- /* Font Definitions */@font-face {font-family:""Courier New""; panose-1:2 7 3 9 2 2 5 2 4 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536859905 -1073711037 9 0 511 0;}@font-face {font-family:Times; panose-1:2 0 5 0 0 0 0 0 0 0; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;}@font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;}@font-face {font-family:""ＭＳ 明朝""; mso-font-charset:78; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1791491579 18 0 131231 0;}@font-face {font-family:""Cambria Math""; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1107305727 0 0 415 0;} /* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:""Times New Roman""; mso-fareast-font-family:""ＭＳ 明朝""; mso-fareast-theme-font:minor-fareast; mso-bidi-font-family:""Times New Roman""; mso-bidi-theme-font:minor-bidi;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; font-family:""Times New Roman""; mso-fareast-font-family:""ＭＳ 明朝""; mso-fareast-theme-font:minor-fareast; mso-bidi-font-family:""Times New Roman""; mso-bidi-theme-font:minor-bidi;}p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; font-family:""Times New Roman""; mso-fareast-font-family:""ＭＳ 明朝""; mso-fareast-theme-font:minor-fareast; mso-bidi-font-family:""Times New Roman""; mso-bidi-theme-font:minor-bidi;}p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; font-family:""Times New Roman""; mso-fareast-font-family:""ＭＳ 明朝""; mso-fareast-theme-font:minor-fareast; mso-bidi-font-family:""Times New Roman""; mso-bidi-theme-font:minor-bidi;}p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; font-family:""Times New Roman""; mso-fareast-font-family:""ＭＳ 明朝""; mso-fareast-theme-font:minor-fareast; mso-bidi-font-family:""Times New Roman""; mso-bidi-theme-font:minor-bidi;}.MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-fareast-font-family:""ＭＳ 明朝""; mso-fareast-theme-font:minor-fareast; mso-bidi-font-family:""Times New Roman""; mso-bidi-theme-font:minor-bidi;}@page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} /* List Definitions */@list l0 {mso-list-id:85738127; mso-list-type:hybrid; mso-list-template-ids:1894403420 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}@list l0:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;}@list l0:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:""Courier New""; mso-bidi-font-family:""Times New Roman"";}@list l0:level3 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;}@list l0:level4 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;}@list l0:level5 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:""Courier New""; mso-bidi-font-family:""Times New Roman"";}@list l0:level6 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;}@list l0:level7 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;}@list l0:level8 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:""Courier New""; mso-bidi-font-family:""Times New Roman"";}@list l0:level9 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;}ol {margin-bottom:0in;}ul {margin-bottom:0in;}-->
--------------------------
**Version**: unspecified
**Severity**: normal",52128,-1,High,False
-5.610309087996606,3.1784622840851533,4.14113847493838,5.327580638037184,6.071178355247076,2.5530281901985488,-1.4280928778551027,-0.28116999171551177,4.102202622887842,-0.9139723440008893,0.4195897625705589,-1.3892711253359937,0.5133420833240185,-0.02290261685053352,-0.9663263942857183,1.4656739451822682,-0.5274235914873129,-1.3459162632381796,False,c1,2,"* Go here http://en.wikipedia.org/w/index.php?title=User:ESanders_(WMF)/Sandbox&oldid=561403721&veaction=edit
* Select from the end of the image to inside the link
* Observe you now have a link inspector positioned over the image.
Bonus:
* Use the inspector to edit the link
* Review your changes, the image has been killed, and the link as gone a bit crazy
--------------------------
**Version**: unspecified
**Severity**: normal",52127,-1,High,True
4.478927150987431,3.678322277793516,2.474928624535565,2.8792490224648324,-0.9923745645594562,-2.0030756252891364,-3.525838162879687,-1.800512869621007,-0.6149699483981668,1.5487428545570978,-0.44462835481739127,-0.32847064354110656,-1.1218209575762312,0.6965817958311309,-0.22172628678593753,0.0035782148288178717,0.42830301310921604,0.2220604640206989,False,c1,2,"Screenshot of the problem in the serialization
I think this is caused by Parsoid trying to preserver/re-add whitespace when round-tripping.
Steps to reproduce issue:
* Create a page like the default MediaWiki main page:
<<<MW
'''MediaWiki has been successfully installed.'''
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki sandbox software. 12
== Getting started ==
* [//www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [//www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [//www.mediawiki.org/wiki/Localisation#Translation_resources Localise MediaWiki for your language]
MW;
* Edit it with VisualEditor
* Put the cursor before ""MediaWiki release mailing list"" and select back until before the first character of the heading ""Getting started"".
* Press backspace. You're now left with 2 of 4 items in the list and an empty heading.
* Again, out the cursor before ""MediaWiki release mailing list"" and delete until you're behind ""software. 12"". You're now left with ""MediaWiki release mailing list"" in the paragraph and a list with 1 item.
* Save page -> Review changes (Screenshot attached)
It inserts a lot of new lines.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11588}",52123,-1,High,True
-2.972392530904692,-1.5066640889618608,-2.100973857144524,-0.2607430875168639,3.423513479746267,-0.16423694346116346,-0.7303936624710836,-4.510753490707133,-2.0252362254480665,-0.3142754247246584,6.01449694605617,-3.525371436766327,0.39804007245752526,-0.7610831150416804,0.2736814283037088,-0.8762796360565024,1.3122082166834723,0.707497101139807,False,c1,2,"I edited a large page on meta (1.22wmf7) in VE. All seemed fine but review showed VE had removed the first character following several closing </pre> tags. It also removed a few characters within a <source> tag.
Here's the diff showing the removal, it's self-explanatory. <https://www.mediawiki.org/w/index.php?title=Extension%3AEventLogging%2FGuide&diff=716359&oldid=704840>. I will restore the characters by hand.
I'm using Firefox 21.0 on Kubuntu 13.04.
I tried editing the same document again and this time VE removed more characters from the source tag, added a space after a <pre>. Hmm. I'm setting to critical as it's recoverable data loss, but maybe it's intermittent.
--------------------------
**Version**: unspecified
**Severity**: critical",52118,-1,High,True
-2.811247410221672,-2.4688258272403747,-1.8272015531204922,-4.820485413997648,3.46968704634604,-3.2681630543985953,-0.08141150111622686,-1.8950739389077103,0.1371058982074883,-0.051447513655308086,1.3943570322880006,-0.8036816572183672,0.9486853537073867,-2.641213738618872,-0.43945716383994515,-0.2459670047285627,-0.42149655589321244,1.4333553510419141,True,c1,2,"From http://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Problem_with_using_shift%2B
""Hi. I have been using the visual editor for a while on ar Wikipedia, it is very nice and smooth for fast edits. However, I am facing a very strange problem when I need to add some Arabic diacritics known as tashkil; when I press shift+diacritic button (like x, e, or z) the letter I pressed starts to repeat itself endlessly, and it can only be stopped by refreshing the page and wasting the work I have did. Any thoughts?""
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50631",52105,-1,High,True
8.095489650332455,-14.82255163857039,3.179415833186571,0.9186130126790673,-1.4286234441968861,3.2781841825525317,4.450745788112099,-1.2930644330300787,0.573472784823962,1.1808525210849714,0.7222960696364913,-0.6508456717335851,-0.9534052924244074,-0.2571763815276453,0.2729436330465296,-0.449868668583171,0.2378745623533054,-0.10558934944149234,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Jason_Bateman&curid=685922&diff=561337061&oldid=559944750
https://en.wikipedia.org/w/index.php?title=David_Stewart_(photographer)&curid=24365669&diff=561336970&oldid=529664374
--------------------------
**Version**: unspecified
**Severity**: normal",52102,-1,High,True
-0.8695421522632403,1.934317720982481,2.5927675110874127,0.49038654984397767,0.010576395506864178,2.31597544596257,-3.630390329247845,1.5008821534116428,0.05756073700390185,1.0866623435057416,-2.284689837135514,1.7542780941471234,-0.6273495895356991,0.14754404095167306,-1.484679180025605,-0.7396622168050766,-0.04771923422512714,-1.6540140880269452,False,c1,2,"Screenshot
See screenshot; this is still happening as of [timestamp of this bug]. The VE interprets a click on 'save page' to be an attempt to interact with the infobox.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49059
**Attached**: {F11515}",52096,-1,High,True
0.6009037988033801,-8.281852883372402,9.042905969603453,2.269853366573211,-3.2143589596904314,0.2301598766236197,1.4193621374398875,0.25282514317627713,3.8273408067802324,-0.4958470885306294,-1.3408167729393257,-0.0712443994758638,-1.212842523289166,0.16344346883184446,-0.15690452284968615,2.025802401873873,0.6911321313554664,0.47387914536044273,False,c1,2,"Compare the references section of https://en.wikipedia.org/wiki/A_Slight_at_the_Opera in read and edit mode.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52371",52094,-1,High,True
-1.9526892892959706,3.1950060338607074,-5.689982230385381,-2.696855573829097,-3.4081511369266204,0.6526424601621434,-0.8938375362540372,3.3225476611657236,-2.0695805004308605,-2.734149147220129,-1.4346777140265197,1.2296502274736636,1.260816754733061,0.05774126994232365,-0.5375946382387111,0.6460970027977577,0.64826924492834,2.459369400185124,False,c1,2,"(from bug 49922 comment 1)
VE is slow at selecting templates and transclusions in big pages.
For example: [[World War II]]:
- attempt to select infobox by clicking on it: takes ~3 seconds in
Firefox 21 and Chrome 27, with no visual indication that anything
is happening during the wait
- attempt to select the reflist by clicking on it: just hangs in Firefox
and Chrome, never actually seems to happen
This either needs to be sped up, or fail more gracefully.
In IE10, this is not such a problem \o/ - lag is actually less, and the reflist can be selected (takes about 22 seconds).
--------------------------
**Version**: unspecified
**Severity**: normal",52084,-1,High,False
0.07288448758052368,-9.806766808880276,6.669725301002956,1.7599692686889972,-1.3892200139188289,5.224120977251676,3.1406292486029317,-0.2634274013633006,3.0370374220102887,2.604636081456759,2.846955167344514,-0.10799211176780643,0.5757923082536531,0.5169667987924349,-0.7084232553741492,-0.038458212759814814,0.05700364928420032,-1.6817340996147592,False,c1,2,"See the unexpected changes at https://en.wikipedia.org/w/index.php?title=Thomson_Airways&diff=561270595&oldid=561268927
--------------------------
**Version**: unspecified
**Severity**: major",52079,-1,High,True
6.681309335085235,-7.506841228355054,-0.8264737459960312,-8.899568198744031,-2.2214195149434115,2.6672610970804227,0.014687302447564221,-1.6865276678047296,-1.479175637001881,-1.6907857665348112,-1.543253537821122,4.64706044791168,0.532693014996497,-1.9914633895446716,-0.5327902239949278,-1.3999322024889846,-0.6839745126006697,-0.8570525003087914,False,c1,2,"Screenshot
See screenshot. What am I meant to be paying attention to?
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11451}",52077,-1,High,True
6.062554886758408,-5.396849332396634,3.728259780476481,-3.140177786976608,1.437088497717598,5.854426988241091,-2.697678639560789,-0.8457783056466804,-0.7153288527043442,2.1440368264138394,-3.2057464164986547,1.8450614672766397,-1.1005144119138413,-1.8770927173649272,1.5462544660073032,1.179936647563101,2.9957911856038217,2.4896568314627796,False,c1,2,"Click after the line ""Saptaitey Chiranjeevinaha[citation needed]"" on https://en.wikipedia.org/wiki/Chiranjivi and BANG! And the text is gone.
--------------------------
**Version**: unspecified
**Severity**: major",52076,-1,High,True
4.326870216817907,-16.317490188340763,6.51701991193211,-0.9478483310339998,-1.347457850035386,2.604618282827408,2.9715858450485504,-0.04887905016881597,4.371777307550583,1.7521605310124642,1.472029850431714,1.7111768271131098,-0.18815446954747106,0.7477505718788793,-0.34536965921501483,0.5412928297846197,-0.4429915204200132,-1.160928575850554,False,c1,2,"See https://en.wikipedia.org/w/index.php?title=Beautiful_%28Mariah_Carey_song%29&diff=561243294&oldid=561242578
--------------------------
**Version**: unspecified
**Severity**: normal",52071,-1,High,True
3.7812556618727666,-7.408464338508037,6.90128732927543,-3.006942135893657,5.10658160301495,0.3801879097362231,0.1323204950223955,1.031094461956116,3.1070685842802144,-0.6063725720777589,0.09176951057537908,0.3013846158623861,0.33844419062795383,-0.7051225725195502,0.019717477478282674,0.24777120169258265,-0.8954147342407422,-1.8067054879927462,False,c1,2,"See https://en.wikipedia.org/w/index.php?title=Riddler&diff=561149660&oldid=561096940
The user reports they were nowhere near the infobox.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50147
https://bugzilla.wikimedia.org/show_bug.cgi?id=50129",52070,-1,High,True
-4.259037809189914,-2.7258892325917277,1.426345538895788,-1.5695063408260264,-0.9679162880631142,4.150366595607382,0.2868446305208021,3.0228178170333915,2.5753788181957162,0.15843700440461106,0.6088680406448583,-1.694168318538229,0.7012928928434747,0.5938597242480848,-2.5850543380418745,-2.4422898787575913,-2.1400626521632358,1.7964389287046612,False,c1,2,"See https://en.wikipedia.org/w/index.php?title=Port_of_Hull&diff=561131671&oldid=561056099 - an attempt to enter a dash led to bolding vanishing. Not sure what's going on there.
--------------------------
**Version**: unspecified
**Severity**: normal",52068,-1,High,True
2.3052571948885956,-9.907010843695023,-3.2728665606692466,-7.443242075306054,-0.25035378634490724,-0.8123305932672948,4.132089147061628,1.9813236661960225,0.42682839021038876,2.2880299158446826,1.314485100968811,-2.388319116529039,-0.3886125734924839,0.9555338368053086,-1.5024243167116715,0.26794983091511804,2.9759556527320106,0.6407147931004233,True,c1,2,"Currently we don't and cause major headaches for Parsoid.
--------------------------
**Version**: unspecified
**Severity**: major",52066,-2,High,True
-0.6529999716417563,-2.831125441989238,-7.978148483402952,-3.8748418217874905,0.8140645728176419,-0.739054393439855,-4.892006201744774,0.7552968201653677,-6.890162760827573,11.012364487324122,-2.3990124672876085,3.8795684521398943,-1.1375525888579476,1.3661981771483669,-1.3831435146852469,-1.1540700548411003,5.973200799283578,-3.2674792363668095,False,c1,2,"Which causes this dirty diff:
'''Foo<!--bar-->baz'''
=>
'''Foo'''<!--bar-->'''baz'''
Of course annotating un-deletable metadata means if 'Foobaz' is erased you will be left with:
'''<!--bar-->'''
but that's less of a problem, and could be fixed by Parsoid.
--------------------------
**Version**: unspecified
**Severity**: normal",52060,-2,High,True
2.1237889421413114,-0.24643335674387679,-4.075195844697975,-0.2508018139651017,1.095288170785653,2.6812068235653506,0.004734274324398768,-1.7662950184288668,1.3005495889312404,-0.17757445681920192,1.084975255425619,-0.0299546321999844,1.1690301821801645,-0.8677119799425661,-1.4346168818838523,3.0920036208683848,-0.7693216505590859,-1.195968564931087,False,c1,2,"Screenshot
See the screenshot; it appears in Monobook on enwiki and mediawiki.org as of the latest release. Kiiinda a problem.
(the other interstitials there - review your changes/save page - are also shrunk).
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11418}",52058,-2,High,True
-4.2114435037673115,-1.7414002907777935,3.1843173683702055,3.077161411369164,3.6151203986186498,1.5933022474640006,-2.3967495972115738,1.1167637355692417,1.2861056327020988,1.924708080854887,-1.9775171107156675,-0.7913174216647868,-2.9631580295550553,0.6208896728608835,0.7953272773009692,-1.0612361145646896,0.6548571353079129,0.1674162735703313,False,c1,2,"You can't tab from the edit summary box to the ""Save page"" button, or the reference inspector to the ""Apply changes"" button, etc.
This is important for accessibility. Currently, there is no way to confirm the action using only the keyboard.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50897",52047,-2,High,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: normal",52045,-2,High,False
-2.0719312210427265,-6.941611896024594,3.0722859644462055,7.9716820173484795,-0.9287146350728293,-4.2410245951887235,-2.509378167304808,-1.4435350770930446,-3.86377742043864,-4.267567655496335,1.5655382245982206,2.8357338389018407,2.0425543036997906,2.1788697340152554,2.9859726213729525,-0.2104383003225494,0.7409153417256886,-0.6856199965449365,False,c1,2,"In IE10, any attempt to open the transclusion editor leads to a stack overflow.
In the dev console I get this:
---
SCRIPT28: Out of stack space
load.php, line 46 character 700 [this location is different every time]
SCRIPT5: Access is denied.
load.php, line 305 character 273
SCRIPT5: Access is denied.
load.php, line 305 character 273
SCRIPT5: Access is denied.
load.php, line 305 character 273
[... ad infinitum]
SCRIPT2343: Stack overflow at line: 46 [different every time]
SCRIPT5: Access is denied.
load.php, line 305 character 273
---
--------------------------
**Version**: unspecified
**Severity**: normal",52044,-2,High,False
6.392570781214646,-0.2904459140110873,3.699751956942414,-0.0766703972808096,-1.6266622882695752,2.316670153418012,-5.085288704158872,1.622377072473899,3.686076523105367,-1.1083352353800597,4.054394544271332,0.8564139253659853,0.5157564147286409,0.23675443160107346,-1.033567679826871,-0.9296877015635021,0.4776242369504733,0.8762311572212884,False,c1,2,"1. Use Chrome 27 to edit [[Pancytopenia#External links]] in VE
2. Try to cut the {{Commons category}} template (using Ctrl+X/Cmd+X or right click/Cut)
The browser tab crashes.
Seen on Windows and Mac.
No idea how to find any debugging info about the crash.
--------------------------
**Version**: unspecified
**Severity**: major",52043,-2,High,True
8.72848835237692,-8.01389365578406,8.453218879441604,3.1903129015131855,-1.471568122323201,-2.2269335796668575,-1.2764258060880058,-0.23565603826970374,-0.547419488983408,-1.2047092394514287,3.1721259601476492,-0.5202333690551907,-1.025555991404211,-1.5256424605500238,-0.6071519918619517,0.13279364219842138,1.6231224430039475,1.1936118191901073,False,c1,2,"Intended edit (ve-edit + fixup):
https://www.mediawiki.org/w/index.php?title=Wikimedia_technical_search&diff=715707&oldid=715705
- [https://github.com/search?l=&q=wgWellFormedXml+%40wikimedia Search]
+ [https://github.com/search?l=&q=ResourceLoader+%40wikimedia Search]
Actual edit saved by Parsoid/VisualEditor:
https://www.mediawiki.org/w/index.php?title=Wikimedia_technical_search&diff=715706&oldid=715705
- [https://github.com/search?l=&q=wgWellFormedXml+%40wikimedia Search]
+ [https://github.com/search?l=&q=ResourceLoader+%2540wikimedia Search]
Note how the % got encoded to %25.
--------------------------
**Version**: unspecified
**Severity**: major",52042,-2,High,True
4.09752217415933,-4.355562516474329,-0.12833572027358997,2.1130580878350194,2.8315094167012265,-0.44374122028679663,0.364657011808017,0.8144290761752905,-0.7325072537145,1.0238775288395185,0.4928014613031797,1.3716276088486976,2.5610588045727303,-1.1748374996984623,0.3444638348322462,0.19689606242868635,-0.0960574548539257,0.18382287553775023,False,c1,2,"Screenshot
I am unable to insert a media with a given file name from Commons.
Neither
File:Kölnisches Stadtmuseum - 125 x gekauft - geschenkt - gestiftet-1120.jpg
nor
Kölnisches Stadtmuseum - 125 x gekauft - geschenkt - gestiftet-1120.jpg
is accepted (and any other file name)
The ""insert media"" button is still inactive, see screenhot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11348}",52018,-2,High,False
1.4876765819732305,-11.628498647194485,6.251979920533781,0.9179747111679224,-4.708224276276054,1.2408781107843005,2.240945460058744,-0.4074093465236265,3.1219344564735243,0.7727107251521304,0.34192181201034133,0.8924172096868956,0.06293625429704619,0.08937649316783247,-1.0660095778879954,0.1172156403757646,-0.2562161093738824,-1.3129539921093496,False,c1,2,"See, for example, https://en.wikipedia.org/wiki/Kaveri_River
--------------------------
**Version**: unspecified
**Severity**: normal",52013,-2,High,True
4.0725876150477145,-10.997323712429981,11.205455343787584,-1.0480863252245587,-5.364863057149547,2.6409907479732126,2.447290758637835,-0.426033767002997,3.11014398199291,1.4900168943336967,0.6796601870373729,0.813384547498754,-0.6378320091102658,0.3650316640488267,0.17235970797472255,-0.39468687819409054,0.6286209258025857,-0.11826269960945335,False,c1,2,"Compare https://en.wikipedia.org/w/index.php?title=User:Edgepedia/sandbox3&diff=prev&oldid=560957268 to https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2Fsandbox3&diff=560957359&oldid=560957268
--------------------------
**Version**: unspecified
**Severity**: normal",52012,-2,High,True
1.6156649921648083,-3.1710804424697443,-4.516069873727169,-6.535953269783094,-0.09007522132209589,0.5202294982211728,-1.3419675276924101,1.9818536508451654,-2.983021527613749,-0.8530705097130986,5.685434652302879,3.8069832716149072,0.53994605113623,0.5639323366444238,1.333833082104242,0.011857371022012453,0.6819468008689198,0.8050597142903093,False,c1,2,"I hope this is a false alarm... but it seems to be real.
Compare [[Locomotive]] (images visible - en is currently on 1.22wmf7) with [[testwiki:VisualEditor:Locomotive]] (no images - test is on 1.22wmf8).
Seen on Firefox latest and Chrome latest.
--------------------------
**Version**: unspecified
**Severity**: critical",52008,-2,High,True
6.812555887679926,2.174931657875142,1.5016141528027056,-3.895126238272525,-4.2755584190039455,1.6627058614397223,1.1966870338856515,3.7157447159643175,0.5692202957571367,0.24013106558936492,0.485707821093849,-0.052207405837807475,1.6112892283877986,-1.0021395617860462,0.03171106706389448,-0.23878052746105605,0.20123721601912137,-1.7237871283167807,True,c1,2,"Currently scheduled for w/c 15 July. It's anticipated that this will not be possible for some wikis due to failings in VisualEditor and/or Parsoid; exact list to be determined closer to the time.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51792
https://bugzilla.wikimedia.org/show_bug.cgi?id=33126
https://bugzilla.wikimedia.org/show_bug.cgi?id=33077
https://bugzilla.wikimedia.org/show_bug.cgi?id=52202",51998,-2,High,True
7.11642094734419,-9.356424756318853,-3.3596752883874412,-3.064054419641767,-3.438111051769079,2.372972043050585,1.001361681097026,1.8169098696478834,-1.1782150878235724,-1.3668916302948562,-0.9373347164699646,-3.326279759740868,2.117725114636862,1.452683488324225,0.3867464752699421,-0.9811146015467911,-0.11358913354907374,-0.020244346169518534,True,c1,2,"Currently scheduled for w/c 1 July.
--------------------------
**Version**: unspecified
**Severity**: normal",51997,-2,High,True
-3.9419150207472486,1.7277659717613538,-4.921746595633078,-4.176380538701548,-3.7813511081267013,-0.8058647537017722,3.9265757936476993,2.595374616630654,-0.5942701106359487,0.011496822689530894,0.9986563618411624,0.30056414416543453,-0.9807675079624181,-0.9664283869854655,1.6479525630606577,0.6682465251649372,0.08587736972946969,0.222176385559133,False,c1,2,"After spending some time with VE in our various test environments, it would be convenient to have all features available in VE available in all of our test environments. Right now it is possible to create citations in mediawiki.org but not in test2wiki, and VE in beta labs is not usable at all.
test2wiki gives us a production wiki where it is possible to make destructive or nonsense edits that are not welcome on mediawiki.org
beta labs gives us an environment to test possibly risky merged changes that are not yet deployed
Enabling all of VE features in all test environments would be useful for testing.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49703",51963,-2,High,True
-4.958439433215475,-3.6355623360214473,-0.7873831658613497,0.6400671142024845,1.9144788078797612,-1.2172977283989073,-1.6001441258500329,1.4453031835960952,2.8169633751992667,-2.397942739675446,-1.9086346418700593,0.6052053688969279,0.41872600103748736,-1.0287910930879116,-1.5053489089771643,0.8758171253925847,-0.4088082960718189,-1.0202432082762767,False,c1,2,"When editing a page which has an image with table data in its caption, the table is dropped (only its closing tab is kept). The rest of the caption is dropped as well.
Test edit: https://hu.wikipedia.org/w/index.php?title=Vall%C3%A1s&diff=13696305&oldid=13696296
You don't need to interact with the image in any way for this to happen, just edit the page, change anything and save.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://hu.wikipedia.org/wiki/Vall%C3%A1s?oldid=13696307
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61064",51942,-2,High,False
-6.279030096664496,4.8865346971194406,2.362354741505211,6.274505282790805,1.1848548182244096,5.066566923326309,-2.246673739540351,1.5236208262682545,2.6472121082549807,-0.7305271115194216,2.392606934994331,-2.373820515985097,-0.9188278163368366,0.10944956410307327,-1.2516670926739444,2.162768389792465,2.204485440494622,-0.3199182522703139,False,c1,2,"1. In VE, highlight some text and open the link inspector
2. Type some characters into the textbox, but quickly click out of the link inspector before the autocomplete dropdown appears
The dropdown appears in the top-left corner of the page.
--------------------------
**Version**: unspecified
**Severity**: major",51941,-2,High,True
-1.9839459556929466,-0.6182463720743563,-1.0771199444562143,0.18956346541571167,-0.48430855324574384,1.418543380486797,-1.7246649424578697,-1.131880919699027,0.6974803032701613,0.9323895467545569,8.467739865301208,-1.5841869985143506,-1.084894016267258,0.223926190865809,0.2256268577241034,3.2258399312654054,-0.8867616529311841,0.25998551968848527,False,c1,2,"1. Go to [[mw:VisualEditor:TTO]] and edit in VE
2. Double-click on a link in order to select it, or drag-select the whole link
3. Type a new link text
Only the first character you type remains linked, instead of the whole text you type.
--------------------------
**Version**: unspecified
**Severity**: normal",51931,-2,High,True
2.8193511806948517,-6.184034135584531,-4.0569096174987145,-1.3432628939509028,1.4407986080771447,-1.7432775865818377,-4.981847534450182,0.7322134762957755,0.5553957813456244,0.8894135388453019,-1.9350506960412173,-1.1044514630107254,1.8364078482053894,-0.6401486414057214,-0.20111650722330765,-0.018672072245587534,-1.434052439035809,0.16871908027026472,False,c1,2,"Steps to replicate:
(1)Click ""Edit"" and make some change
(2)Click ""Save page"". The cursor is now blinking in the ""Describe what you changed"" box.
(3)Click on another dialogue box, such as the WP search box. The cursor now blinks there.
(4) Click back into ""Describe what you changed"". Bupkis.
Chrome 27.0.1453.116, Firefox 21.0, Windows 7.
--------------------------
**Version**: unspecified
**Severity**: normal",51927,-2,High,True
7.7475648843756275,-8.7085555745123,0.8673757542919489,-3.078313931477515,-0.5045097536268105,2.907738574046271,-0.6995409594548772,0.45851239261008914,-1.1967621199734415,-1.4885725988464955,-0.21841101873657465,3.522696989759477,4.093416072031144,2.241395400862661,1.7615040311137786,-0.9215300659344814,0.16092813197545253,-0.9928842160235697,False,c1,2,"See screenshot, which is of https://en.wikipedia.org/wiki/Craig_Short - Firefox 21.0, Windows 7.
--------------------------
**Version**: unspecified
**Severity**: normal",51925,-2,High,True
-2.925333236632201,2.2888409813796144,1.0799634609668374,5.0727921574676325,1.4400087589560462,2.3007739778285625,0.9029030039787083,-2.625390135410128,-3.332427619280913,2.415014770621754,-2.274943311552411,-0.27245344477522093,-1.9136359317845146,-0.14830865668578497,1.1123260199494363,2.349363735944646,-2.5791976492809168,-0.5280319997002039,False,c1,2,"In this call http://en.wikipedia.org/w/api.php?action=query&prop=imageinfo&titles=File%3APowderfinger-My_Happiness-23s.ogg&iiprop=size%7Curl&iiurlwidth=200 it returns thumbwidth=""1913"" thumbheight=""-1"" as a size of an thumb, which is completly wrong.
--------------------------
**Version**: master
**Severity**: normal",51921,-2,High,True
-3.3966846109544915,-3.5367177980725923,4.278501035868413,-2.176654997315338,1.1700745133414634,-2.2883132214585364,3.728966643929664,-5.315001729374586,1.651924778095616,-0.09539708505390454,0.9446154315302127,-0.6861825794351675,-0.9727554995570662,0.8795602463898922,-0.5420931402814011,-1.0274645091283292,-1.0990826596972592,-1.917567687979699,False,c1,2,"See https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FMet&diff=560772671&oldid=560563847 for example; I have no idea why (problem with the template itself?)
--------------------------
**Version**: unspecified
**Severity**: normal",51892,-2,High,True
3.093704149780226,-3.7657758740116005,4.727244091753292,-5.307263740488638,-0.37111217754136827,-2.79533083642511,0.4768984843228363,-0.8969101792808039,-0.037380429394442416,-1.027501175883585,-0.05196770448206367,3.531919593880467,1.7124663474319495,0.5012248405643147,-3.137618849877696,0.5207645603914617,0.9822514889049938,-0.79923687022569,True,c1,2,"Two users have reported on this.
See:
http://en.wikipedia.org/w/index.php?title=User:AussieLegend/Vandals_etc&diff=prev&oldid=560719781
And:
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Font_colors_in_signatures_changed
I realize that this is probably tied into other behavior, but I lack code-fu to determine what. :)
Maggie
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42803",51873,-2,High,True
-2.999500679297994,-2.8078631998747365,-6.3071923606755576,-2.194435199334966,3.099628680600195,-4.503512812775502,-1.424397383271363,0.644813957690798,1.9146217669371277,1.5121468982889912,-1.1272328223278751,1.955800187767322,0.039237697176565334,1.2018262037702172,-2.313344306703022,0.7017243069427578,0.88646138222197,-1.3832958155642623,True,c1,2,"Click ""add template"", then ""apply changes"" without adding a template (or add one, then remove it.
Expected wikitext: none
Actual wikitext: <span property=""mw:PageProp/noindex"" data-mw=""{"parts":[]}""></span>
We're clearly putting in a placeholder that we don't delete if the block is empty; because we don't display content blocks that don't render in read, you can't see these, which sucks and lets users do The Wrong Thing(tm).
--------------------------
**Version**: unspecified
**Severity**: normal",51855,-2,High,True
-2.033057069393355,2.8201521231957543,1.228822979964228,-2.3830750766378817,-8.798591411570598,-4.841079553353389,4.0949907259722655,-0.3619109217969592,3.8865765279672555,2.02066268522412,2.53313184996324,-0.3409533961797405,0.5162684630505159,0.5888707126198769,-0.8957444692954732,0.3952285608964687,-0.9898941471125253,-0.5050083445164733,True,c1,2,"Something's gone wrong with our PHP parser re-render call; on re-render of block templates only, you get {{template call|param}} rather than nice lovely HTML. Presumably something to do with our hack yesterday? Plzfixkthxbai.
--------------------------
**Version**: unspecified
**Severity**: major",51854,-2,High,True
-5.726402473452659,1.1003740084724303,3.7876489387548027,5.55410715602831,4.525507372438092,3.4690432129613367,-3.0908244359958736,2.158994143850141,1.1048966632639425,-1.371704246027503,3.7733590789402354,-0.9343334498452318,-1.109648151560922,0.4596411706207215,0.0015442902144187087,-0.5802754351914776,-0.2689003605808873,-1.386204327679114,False,c1,2,"Reproduce:
1. Open page with a protected node
2. Click edit (visual editor)
3. Quickly mouse over the protected node (while VE loads)
4. See that the editor has slid the content down but the phantom is rendered under the mouse
Perhaps the local overlay should be a peer of the documentNode.
--------------------------
**Version**: unspecified
**Severity**: normal",51853,-2,High,True
3.1605858742781776,-3.1858676622704802,-1.0242664279840525,0.4806401859877649,-1.6376705539520526,-0.35683480982909754,-0.3761801196233341,0.7891237826676408,-0.4410932173452766,4.8943493026343,-1.058538225123205,-0.4149995564378788,0.5084508196141608,0.7515987786378089,-1.2982119864478445,0.284918050477612,-0.11814347720337626,-0.6368211618308024,True,c1,2,"Reported initially in bug 49596:
ptwiki (""direita,right""): https://pt.wikipedia.org/w/index.php?&diff=36119075
plwiki (""prawo,right""): https://pl.wikipedia.org/w/index.php?diff=36790309
This feels like a Parsoid issue (VisualEditor doesn't know about localisations of these terms :-)) but Inez can tell us more details.
--------------------------
**Version**: unspecified
**Severity**: normal",51849,-2,High,True
7.4171591825493195,-1.494557303796686,-2.7876544228273996,-0.6288215788794822,0.7672094739952613,-1.4403788072617476,0.1850721801543127,-0.27166624364642694,-2.7149530767899517,-1.5624313517732853,-0.6850803288054261,-0.7403861007640495,4.401778497078322,4.628368714031463,2.1127226942967248,-1.26730594613763,-0.26229184611892387,-0.4112111653429529,True,c1,2,"Whenever you think that you've fixed that damn script, you suddenly realize there's something else that's still wrong.
Testing the fix for bug 49758, looking at its results:
Created reports per component:
VisualEditor General 33
MediaWiki extensions UniversalLanguageSelector 27
VisualEditor Editing Tools 25
VisualEditor MediaWiki integration 12
Wikimedia Bugzilla 11
Created reports per product:
MediaWiki 43
Wikimedia 45
MediaWiki extensions 104
Security 3
Tools 5
it is clear that the ""product"" list does not list those products with the **highest** number of new tickets in the last week.
This can be also seen on
https://bugzilla.wikimedia.org/report.cgi?x_axis_field=&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfield=[Bug+creation]&chfieldvalue=&chfieldfrom=-7d&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap
which right now lists these top 5 products:
MediaWiki extensions 104
VisualEditor 95
MediaWiki 48
Wikimedia 47
Parsoid 23
--------------------------
**Version**: wmf-deployment
**Severity**: normal",51845,-2,High,True
-4.222910553099579,0.83668236160951,-8.330686663226242,-3.9569588535719213,-1.0061767646445436,-1.7214043447640333,-4.168223960243405,-1.8308839055564925,-4.479921500230581,6.716809553836054,-4.698458145974139,-0.9438875763365749,0.48889400796786076,3.9781237187375993,-0.31305104539963136,2.519493083038523,-1.2500473285039324,2.2767784438076557,True,c1,2,"TemplateSpecModel currently doesn't expand aliases, so if it knows something as ""foo"" with an alias of ""1"" and the dialog asks about ""1"", it returns nothing.
--------------------------
**Version**: unspecified
**Severity**: normal",51838,-2,High,True
6.344554310691551,-1.1934114116340897,-1.5113716293787753,5.179917473599304,-0.41288896967521005,-0.6390654858174554,-4.690888614268481,-1.0666286258945363,0.5897308864217927,0.8034303358248218,0.013406413076626489,2.1936128983448944,-2.617053901329948,0.8108371251596145,-1.7782445590952962,-0.9865577189705277,0.021843778300225658,5.339237152945734,True,c1,2,"Using Chrome27.0.1453.110 m
Replicated on Firefox 21.0
Attempting to remove a template using the puzzle piece and ""remove"" function seems to succeed but leaves behind the following code:
<span data-mw=""{"parts":[]}"" class=""metadata plainlinks ambox ambox-style ambox-Orphan"" style></span>
See:
http://en.wikipedia.org/w/index.php?title=Cocking-cloth&diff=560630933&oldid=324780702
and
http://en.wikipedia.org/w/index.php?title=Cocking-cloth&diff=560631541&oldid=560631467
--------------------------
**Version**: unspecified
**Severity**: normal",51831,-2,High,True
-0.5810955841040721,-2.297582438330922,-2.5185914309329362,0.02679888790741991,-0.12087832776637575,-4.793334163781326,1.0607028605043407,0.47997515099293675,0.5603516314347327,-1.7356842270677424,0.7797154421589547,-0.1654315338274681,-1.2753110715257616,-0.2987458626030728,-1.4628339860586337,-0.8375381507764958,-1.6203867147217292,0.12526303194545352,False,c1,2,"When a user inserts [[links]] or {{templates}}, VisualEditor automatically wraps them into <nowiki> tags. Experienced contributors who are very used to using this syntax sometimes add it inadvertently.
It would be a nice touch to show an unobtrusive warning to remind users that they need to use VisualEditor's menu to insert links, templates & other wikisyntax. LiquidThreads does this well when users insert their signature manually with ~~~ into their post
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49686
https://bugzilla.wikimedia.org/show_bug.cgi?id=50527
https://bugzilla.wikimedia.org/show_bug.cgi?id=50601",51820,-2,High,True
0.08869404863072372,-1.7571958726575527,3.6236438393271833,3.072171079608804,1.190104135496191,0.7910144831975965,1.5420611672590532,1.9233703826793036,-1.6429800522895344,-0.1352968654930331,0.906452617680368,-0.28774406075512726,2.2392009431145867,0.416938260307413,-1.5598710579839041,0.17646322665805608,-1.1589739427514498,-0.2597387436843652,False,c1,2,"screenshot
When selecting some templates in VisualEditor, a blue rectangle appears in the top left corner of the browser's window, and disappears when the template is unselected.
Encountered on https://en.wikipedia.org/wiki/User:Jdforrester_%28WMF%29/Sandbox?veaction=edit (see screenshot)
Firefox 21.0 on openSUSE 12.3
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50074
**Attached**: {F11783}",51818,-2,High,True
-2.9367615095550152,-0.3907847121348702,2.5308787458104973,4.92372423729961,1.5779898508497125,0.6843431232653752,-1.0620543769138555,-1.0724696593103549,-1.5524199884434775,-0.22450368770810503,-1.5094405857506923,-1.266529675710407,0.4836827692859331,1.4220796899784958,-0.12846915990694452,-1.6941495700238938,-1.4439176388149384,0.26799516414761526,False,c1,2,"Encountered on: https://en.wikipedia.org/wiki/Westplex?veaction=edit
Firefox 21.0 on openSuse 12.3
When opening the ""Media settings"" overlay by clicking the icon on the image, the title shows <visualeditor-dialog-media-content-section> instead of what I assume should be the actual system message.
--------------------------
**Version**: unspecified
**Severity**: trivial",51817,-2,High,True
-2.096478725133496,-8.931220732686672,-0.4399435902478608,-1.9729213707665232,0.30178120758568616,2.483242786459523,2.5669784249215217,-7.127317764531107,0.20860476339044087,-2.383915458959576,-2.5643448789084973,-0.6122115536374312,-2.894665308474214,1.775716578280413,-0.27430584349105835,-0.13775939890579775,1.153677362973504,-0.6008626369659618,False,c1,2,"Like we do with the link inspector.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51809,-2,High,True
-6.9633777990443235,-3.7930082586454077,1.0145836607414225,7.925463033157083,4.65018156716166,-0.5270622003635884,-0.30600504893503544,-1.0658934980654804,-1.280925637172639,1.8294648130521827,-1.8269183877496065,-0.5064776621046213,1.0307837335954533,0.24034816450761198,1.7855878086246868,0.09963450341823804,0.09340556690489099,1.9064638340626383,False,c1,2,"See, for example, http://en.wikipedia.org/w/index.php?title=Audie_Murphy&diff=560382883&oldid=560374610 - the line ""ad a private-pilot license and"" (image description) is clearly being taken from the article text ""had a private-pilot license and a reported 8, 000 hours of flying time"", but I have no idea how.
--------------------------
**Version**: unspecified
**Severity**: normal",51807,-2,High,True
2.9076316995444214,-4.973953040544583,0.1642402202599733,0.408574538944646,-1.2315301228613904,0.03274382946882226,-2.3747760592378957,0.773616773095606,2.5558996788780206,0.8364929328118613,-1.2154209206459046,-0.2152540324029013,0.629976884127553,-0.5712200220062655,-1.4410361045108742,-0.8133265396618727,0.2844183820574797,-0.8346071387532508,False,c1,2,"Steps to reproduce:
1) Visit https://en.wikipedia.org/wiki/Deliciosamente_amoral?veaction=edit
2) Attempt to manipulate the contents of the infobox by clicking the puzzle piece icon associated with it.
Expected behavior:
Infobox parameters should be editable.
Actual behavior:
Template editor invocation fails with the following error on the console:
Uncaught TypeError: Cannot read property 'description' of undefined
Chrome/Ubuntu
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49493",51797,-2,High,True
1.0528637521582351,-2.5112992875805755,7.796225288743898,5.180533063390816,-4.778160598565414,-1.069869215880582,-0.04708660901402251,-0.5865473676570974,-1.2801896903517362,-2.0872737125183543,-1.9162347844995469,-3.0059242656834666,1.1904899449387023,-1.0999806607556586,-0.16357681951761371,2.507370681649821,-0.8337209735492477,-1.01548086913872,True,c1,2,"Example screenshot of the issue
In the given link, for reference 7's template; only in Firefox - works fine in Chrome.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/index.php?title=VisualEditor:TestReferenceContents&oldid=713075
**Attached**: {F11716}",51781,-2,High,True
-3.2755795357543773,0.9847551682693378,-6.153771372161071,-5.03344207115131,3.64221693337763,-2.4792109800906763,3.4044992700334236,-7.27718202744236,1.595470677877468,1.6317854532092824,3.4992362925583786,-3.319372545961083,0.6633826836969221,-2.8437544709785345,3.149692177157065,2.599420973298599,1.0418993613540783,-2.1277112402829577,False,c1,2,"https://en.wikipedia.org/wiki/List_of_highways_numbered_147?veaction=edit
I selected an inline image in the editor (in itself strange, because it doesn't seem you can edit it). I then hit cmd-c, and the inline image was replaced by the pawn char.
--------------------------
**Version**: unspecified
**Severity**: normal",51760,-2,High,True
2.756185388292413,-4.909558414100106,-4.518740364290792,0.4732627625813952,-0.5132416884699326,-4.887645859185703,-5.084912404617331,-0.19036459042757845,-5.734792136334167,-2.6127619032851084,15.26725238810318,-1.47861035250734,-10.12227268448818,0.7096883388615378,-0.17818394576845442,0.8056642585737243,1.3635631235236894,3.195562985556018,True,c1,2,"<b><b>Foo</b></b> == <b>Foo</b> so it's not /so/ bad if VE corrects it (but it's still a bit dirty, but <small><small>Foo</small></small> != <small>Foo</small> (and the same with <big> and <sup> and …)
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611",51755,-2,High,True
-9.379712367548478,0.7358436517272082,-1.0780011051858658,0.6948806123579598,0.13779113210501814,-0.842382318043942,4.618423034409486,-4.977877425768117,2.1000578166887873,2.1448352351037254,4.136663766245617,1.497602372639984,1.0836998764172958,0.56410691892202,-1.7228545598071676,-0.8896929711228769,1.9314503824792737,2.9538693579952477,False,c1,2,"The reference editor allows me to group references, and allows me to include a ref name parameter to make them reusable, but has no way of actually calling that ref name.
--------------------------
**Version**: unspecified
**Severity**: normal",51733,-2,High,True
-0.48574105878240337,-6.557884842972596,3.115227988032167,4.047185454926014,-0.6056990479031177,1.7702767036197462,0.5708941323738523,-0.46363631863331844,2.445974550809076,0.4874178505626032,1.177881471886629,1.0680125512615006,1.3136035888858113,-0.397596524148204,-1.9557519091364295,1.3357841876909657,-1.4113755813931437,-1.258964885455567,False,c1,2,"Screenshot
See associated character; italics in the reference editing interface causes a pawn to appear.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11627}",51732,-2,High,True
-5.455368348213606,-1.8486182884875806,6.1776285879798785,5.611692832322559,-3.4356294820892814,3.1300083633999094,-1.5007347776251292,-0.712931203631002,3.8591975682551842,8.045673375744546,-0.6634488959041573,-0.10574958617641017,-0.9404675674357756,1.9036891534373268,-0.08796536885754058,-1.1553672020373713,1.00361317690928,-2.2047799658324676,False,c1,2,"See associated screenshot; an attempt to add 'foo' to the infobox on https://www.mediawiki.org/wiki/VisualEditor:Template_test
--------------------------
**Version**: unspecified
**Severity**: normal",51731,-2,High,True
-3.036838250559935,-3.090820560157841,4.2003908467496345,12.015537807653452,-0.5917743939947839,-6.45260084051242,2.250683484804381,-3.1876417599457856,2.2109239619769987,-1.5156197219276444,-0.8794626639930665,0.5850292959797438,0.5004792860838037,-0.36377126104096913,-1.2925662061786678,0.2953819834948183,-0.36961119751085625,-0.5558387372771993,False,c1,2,"**Author:** `rachelqa99`
**Description:**
Make a reference, then type text into Name content, and change format to Heading 5 or Heading 3. When you save the file, you see the wikitext displayed for the heading format.
See page: https://www.mediawiki.org/wiki/User:Rachel99/testing_edit_source
On the bottom of the page, it looks like that.
↑ ===test===
↑ =====Book reference=====
↑ ===footnote text===
↑ =====test5=====
--------------------------
**Version**: unspecified
**Severity**: major",51715,-2,High,True
1.8248559272750708,4.415533410556996,9.796546266187008,0.28326408670726555,-1.5568815702914969,0.7905277560876427,-0.9873706598839673,1.0832807298992853,-0.9983265750827767,1.2618063950043972,-1.0932852436270564,-1.0343027166545817,-1.1892495651066977,0.5897978287761818,-1.0058493415756784,2.1086601724906573,-1.9806038824177872,-1.3068768589268922,False,c1,2,"on beta labs only, not seen in mediawiki.org:
On any article e.g. http://en.wikipedia.beta.wmflabs.org/wiki/0.0924627428112147
Click Edit to invoke VE
Page content is a different article. In the case of http://en.wikipedia.beta.wmflabs.org/wiki/0.0924627428112147 I see the content for an article on ""TAT-1""
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49963",51703,-2,High,True
-3.213524397940223,-2.0824309319487924,-0.2675948085204958,-0.04718489468642639,-3.5976475041606113,4.529662568159181,-4.047935639732464,0.48996189634863363,3.1418936290813138,6.034419896151743,-3.6849502491681356,-1.5925507815639686,-1.43260191643133,-0.019051203376995396,0.7985199651542194,0.5372451347454584,-0.915402180231211,2.937923018557381,True,c1,2,"Alongside the ""minor"" and ""watch"" checkboxes in the save dialog, for pages with FlaggedRevs switched on and outstanding unaccepted revisions, add a checkbox to ""accept pending revisions"".
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50852",51699,-2,High,True
9.954582800842712,7.497965036458577,4.962475679753247,-1.2617163001400558,-5.532975910707428,4.348871134893304,-2.9965917594824454,-3.0911063719402185,-5.243935446399077,0.2224668963057912,-0.6506294731626916,-3.2945784535145934,5.249928368419685,4.88894480268446,3.954958113887197,4.458023928858193,-1.5514637280281427,0.01897318930988634,False,c1,2,"https://en.wikipedia.org/wiki/Template:Contradictory, on https://en.wikipedia.org/wiki/Necessity - in the VisualEditor it displays as [<span title=""This text contradicts text in the article ""Necessity in English law"" (3 May 2011)"">contradictory]. Reproduced in Chrome 27/Safari 6.0.5 on a Mac, Firefox 21.0 on Windows 7.
--------------------------
**Version**: unspecified
**Severity**: major",51690,-2,High,True
4.680356654597258,0.35412655281783145,2.9544826740759405,-2.5575055994390157,-0.8007881104737279,1.4053699356922065,0.18410530108063305,2.5297806814278556,-3.4192040342024566,-1.466247692811847,0.029526659001773314,-2.7518703318358737,3.5972794499247476,2.933013258636934,1.0742821375890879,4.046256176975614,-2.1745816143213412,0.19559641353078994,False,c1,2,"See https://en.wikipedia.org/wiki/Hermann_M%C3%BCller_%28politician%29 for example; found in Chrome 27 on a Mac. In Safari 6.0.5 it displays differently (a large space appears, rather than a missing icon signifier) but is still broken. Not replicatable in Firefox 21.0/Windows 7.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid.wmflabs.org/en/Hermann%20M%C3%BCller%20(politician)",51689,-2,High,False
-4.250124923649411,0.7997058539661204,-3.5861653196419763,-2.934469638831673,0.5968386833905219,-1.1276838859850802,0.9632391671539873,-0.6766489390099004,-1.3351526523139787,-0.7544985442974963,0.664151433247933,0.3931141531848994,-0.5886350706581389,-0.47699386985632586,-0.7454818225165312,0.0988736384698109,-0.2751598983441159,-0.030106632274778278,False,c1,2,"Bug title may be a bit confusing; essentially, a user has suggested that the VE auto-convert wikimarkup entered ''into'' the VE, on save. The use case is users who keep typing [[link]], basically.
My feelings on this are mixed; I think it's perfectly possible that this would be useful, but it sounds like a ton of work and it's also perfectly possible that, once we go live, muscle memory will adapt and there'll be no point to this. For now, sticking it in as a potential future enhancement.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49820
https://bugzilla.wikimedia.org/show_bug.cgi?id=51899
https://bugzilla.wikimedia.org/show_bug.cgi?id=47779",51686,-2,High,True
-5.646352761216412,3.2190005277257185,3.304751111309269,1.8596180562476352,1.9869596526606998,0.5606843809993522,3.319892168130525,2.100343785593218,-1.6024557481221862,0.37185580972913623,1.387811961866746,-2.0790598929858826,0.7171741319167069,0.1555755369403924,-0.12741747438129902,-0.820436064436844,-1.0437271667504084,-0.8348225620817131,False,c1,2,"On Swedish Wikipedia, we have quite a few bot generated articles (some hundreds of thousands) like this one: https://sv.wikipedia.org/wiki/Macrothemis_ultima
When in editing mode, somehow the first line of text cannot be edited.
If an article has a second line, it is possible to edit that one (but still not the first line), e.g. https://sv.wikipedia.org/wiki/Lepidosaphes_lithocarpi
--------------------------
**Version**: unspecified
**Severity**: normal",51678,-2,High,True
-1.1843351483861309,-2.1681614987645155,-2.257572348208978,-0.4559580176207534,-3.0308016883192948,-3.829436770452988,0.2811673287787393,0.26002396199875955,1.177409865624423,-1.267885458756766,2.932970476589413,-0.7409775491274752,-1.4608572591877822,-0.9978304556170303,1.83570092582434,-0.7597947051076144,-0.5846067803617521,-0.16678712547058772,True,c1,2,"[From bug 48429 comment 18]
| It would be ideal to have section-edit links for [edit] and [edit source].
| ie.
| Sandbox [edit]
| replaced with:
| Sandbox [edit] [edit source]
|
| I believe this would prevent a LOT of complaints in the short term, and it
| would permit a lot of us to continue being active beta testers
| (section-editing is my most frequent type of edit), that it should be High
| priority, if at all possible. Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48429
https://bugzilla.wikimedia.org/show_bug.cgi?id=49621
https://bugzilla.wikimedia.org/show_bug.cgi?id=47779
https://bugzilla.wikimedia.org/show_bug.cgi?id=56337",51666,-2,High,True
-3.3271416894906904,-6.511109755716514,-2.9544879862923406,2.360926769100337,-4.185457900388952,0.1714532707219416,-2.46587429465211,0.22830181570020486,0.7132725068355443,-1.7720318969657987,-1.067161075275,-0.4208420935128353,0.2409932126534784,-0.9597861219678281,-1.2800218022687355,0.8538330841757236,0.11158664119803219,-0.4328184777021036,True,c1,2,"In general, ""everything"" is allowed (text; annotations; inline and block images; headings; lists; HTML blocks; entities; transclusions; references; etc.), except for:
Image captions
-> No lists
References
-> No references (but transclusions of {{#tag:ref|text}} get around this for one level as an out ref; eww)
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50459",51657,-3,High,True
-4.196687066519995,-0.5876638671439434,-5.885467317565189,-4.779970716719765,-0.4568742045859906,-1.9827882305789548,-1.8464334255056336,0.8657048296572315,1.7910896106400511,-1.872334189799493,-0.2562635257207777,0.43868576434130113,0.7748648485523497,-0.04529268924845553,1.096202000335592,0.14610224234402291,0.5316432141595664,-1.4979715312371724,True,c1,2,"From bug 49602 comment 0:
| The VisualEditor edit tag (Tag: VisualEditor) should show on diffs, too.
| This will probably require a core change. However, I'm filing it here, both
| so you're aware of it, and because it might need to be configurable (it might
| be we don't want all tags, such as AbuseFilter, etc. to show on diffs).
This is said request for a core change for this to be possible. :-)
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",51656,-3,High,True
1.7765145201294499,-3.8695806209021892,1.6651073570543495,-3.282301916589272,1.043992188828378,0.8666712586157432,1.8676736650573549,1.6307462217787183,0.04800370978855739,0.941064001141326,3.432945916425146,0.4144393539010649,-0.30372132348652325,0.8169786244083657,-2.2821822732912604,0.5335894528149511,-1.6605285328056008,1.3869510352645447,False,c1,2,"https://en.wikipedia.org/wiki/User:%C3%8F%C2%BF%C2%BD?veaction=edit
If a template has no output (such as <https://en.wikipedia.org/wiki/Template:Lowercase_title>), it has no visible output and becomes very easy to silently remove using VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49667",51633,-3,High,True
-4.363533538044532,3.2262784930715966,1.7085489955652058,-0.19883518691536195,3.632655419092425,-3.617288062006123,0.6523576378124414,-4.342724484337891,1.1274384609675088,0.4152393507218948,-0.9833961888245542,-3.507101751308282,-0.6290558262353159,-1.782532675150129,0.44295712735153625,-1.9345367410614789,1.4632439126367107,2.4160551462920052,False,c1,2,"https://en.wikipedia.org/wiki/Digital_Forensics_XML?veaction=edit
I went there, I changed a header from h3 to h2 by selecting the header and using the drop-down menu. When I click ""Page settings"" and then close the dialog box without making any changes, my change to the header is inexplicably lost.
--------------------------
**Version**: unspecified
**Severity**: normal",51630,-3,High,True
-3.8622112167770597,-7.158517408726826,3.048932703401885,2.5447717206064744,-0.07037369120228332,-2.585647652532872,5.853018486759814,5.888008192626432,-0.5886486809212454,1.8283962803335765,2.303554679426679,1.1555956932646054,1.6304588732902237,0.5725253990829637,1.0516865624610432,-0.7721540719225444,-0.7342567887094683,0.5752070937130507,False,c1,2,"If there are 2 blank lines (line breaks) then the paragraph immediately after is uneditable (green striped overlay).
Confirm here: http://en.wikipedia.org/w/index.php?title=User:Quiddity/sandbox&oldid=560048320
and see thread here: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Paragraph_editing_disabled.3F.3F.3F
--------------------------
**Version**: unspecified
**Severity**: major",51623,-3,High,True
4.511209107526071,-4.33315240585517,0.5970302848906499,-5.565232977702089,-0.6262089172343441,-1.1197705824321327,3.0126829339061567,2.0324179563670626,1.4669401340027501,-0.20215462453238153,-0.33540969215261596,2.609725474116451,-0.5889021561139183,-2.5832235694523376,3.525694012839131,0.9347970779240046,-0.37245877500674496,-0.7405271265976161,True,c1,2,"VisualEditor should display HTML comments, which are often used as notes or warnings to other editors. It would be nice if they were editable too.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49608
https://bugzilla.wikimedia.org/show_bug.cgi?id=46440
https://bugzilla.wikimedia.org/show_bug.cgi?id=49806
https://bugzilla.wikimedia.org/show_bug.cgi?id=53659",51603,-3,High,False
-4.39875962838996,-3.248178712158989,1.6218420483363047,6.526715841433651,6.046563778699948,7.13177560552383,2.0597455022274422,-0.43989548699026365,2.180604191572429,0.9445464522200053,2.002200545376857,-3.1796279900817277,0.3890006570247544,-0.6637554479173957,-0.5422380262274871,-1.6044631959751967,0.913074293213193,-0.125283525550699,True,c1,2,"VisualEditor caused this dirty diff (https://en.wikipedia.org/w/index.php?title=List_of_South_Korean_idol_groups_%282010s%29&diff=559356009&oldid=559228059) when editing a table. Note the removal of the empty small elements, and the change to the align syntax.
--------------------------
**Version**: unspecified
**Severity**: major",51601,-3,High,True
-7.843028570448659,4.599330656680557,-3.5529783159933395,-3.7337928406286127,-1.6518988857779189,3.513833035312203,1.0304658662797852,3.7767763423981418,1.1265669322394327,0.6219521544508995,-1.1939567873832841,-1.7537328116733653,-0.6704071645340104,-1.8134293617581205,2.5446470999909314,-1.4195754042972073,1.7964024503709395,1.4148059520513996,True,c1,2,"Per Roan - ""we were initially going to use this for references and captions, and then chose to use separate documents instead, but this is not compatible with the collaborative editing work; a VE instance should be able to collaborate with another instance on the same page, although I suppose there was some stuff about limiting the scope successfully as well"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",51565,-3,High,False
-11.567175112847115,8.389222133060393,-3.3622999632802006,-2.5510783102733035,1.9785093941299206,0.64966599431144,2.6542882411672233,3.20320995943425,-2.57275632987632,-1.751463894229515,-2.47893261867035,-1.5323884012210205,-2.176206000480035,2.6721474831804324,-0.9176389233084814,-0.09814734499396788,0.6267899871894616,-0.801629758951085,True,c1,2,"Clicking the section edit link into VE has three minor issues:
* The cursor is positioned at the start of the heading of that section; it should probably go to the start of the next element straight after the section (in most cases, a paragraph)
* The page doesn't actually scroll to the correct area; ideally the page should be deliberately scrolled to that section (as it happens, you normally end up on roughly the right part because the page is already scrolled, but there are cases where VE pages are lengthier or shorter than PHP pages and so this can't be relied upon).
* The toolbar only appears once you scroll (because it's triggered on page movement, and the page doesn't move at first to get to the section because it's already there) - this means that it suddenly pops into view a bit too late.
--------------------------
**Version**: unspecified
**Severity**: normal",51563,-3,High,True
0.18278838985709767,2.086464571927614,-0.6018175368046723,-5.130202669069514,-1.3942897344742222,-0.34682413256456857,-1.6052920149035952,-0.012407006447496871,-1.94852440854605,-2.6359470638436275,1.3536704974118847,-0.9390684724901655,0.807424143956927,2.6809508796590285,1.6979573489964617,4.9373793553866925,-0.8145486345318798,1.7545937877630522,True,c1,2,"We have plans to use ResourceLoader which will fix a lot of this, but noting it here.
Most obviously, the toolbar has two sections which in LRT appear as ABCDE 1234; in RTL they should be 4321 EDCBA, but instead appear as EDCBA 4321. Also issues in dialogs etc.
--------------------------
**Version**: unspecified
**Severity**: major",51546,-3,High,True
-7.1192347242777405,-2.511601509996755,-3.98205673173233,1.7250714276697536,0.04807671110606371,1.5765010485301911,-2.283252125842452,-2.5142213018122175,-1.2283019249467024,-0.14847879211390502,0.4239570563272972,-1.5595252898944008,-2.282306120947392,0.6442748746947542,0.07692613101048718,2.1473300089404717,-0.721902932150625,0.22171480430406443,False,c1,2,"This is a particular problem with 'note' sections, and references used as notes; they commonly include citations for their statements, and you end up with markup that looks like <ref> some text here <ref> a citation for that text</ref></ref>
The VE is for some reason displaying it as a citation template, ""some text here"", a second citation template and a random </ref> tag. See note 1 in https://en.wikipedia.org/wiki/Fomitiporia_ellipsoidea for example.
--------------------------
**Version**: unspecified
**Severity**: normal",51536,-3,High,True
4.326870216817907,-16.317490188340763,6.51701991193211,-0.9478483310339998,-1.347457850035386,2.604618282827408,2.9715858450485504,-0.04887905016881597,4.371777307550583,1.7521605310124642,1.472029850431714,1.7111768271131098,-0.18815446954747106,0.7477505718788793,-0.34536965921501483,0.5412928297846197,-0.4429915204200132,-1.160928575850554,False,c1,2,"See https://upload.wikimedia.org/wikipedia/en/8/8f/Visual_editor_pulldown_menu_problem.png
--------------------------
**Version**: unspecified
**Severity**: normal",51524,-3,High,True
-1.6104091752774987,-5.37042368224432,-3.4303480414605776,-1.3794787852512655,1.1088443832316883,-1.3610185867133582,-3.463614625206686,-0.4089585299293367,1.0366702706793174,-1.4584597132128603,1.4749278979449332,1.7423839020529253,-0.14237957153757907,-2.0944930121309344,-1.1672417190284632,-0.30696621560494963,-0.749820532917227,-0.18717755121731328,True,c1,2,"Have a link [[Foo]] which is a redirect to [[Foobar]].
Inspect link; it will suggest:
New pages
Foo
Existing pages
Foobar
This is because ""Foo"" does not come back in the list of pages you can link to - which is filtered to remove redirects - but we should special-case the existing link.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50240",51502,-3,High,False
-5.076907738075552,1.5313033883961378,0.6323972531442408,-1.8404837806557595,1.0114858178067179,2.98890819906962,3.387244798986683,-4.378219254224038,-0.3506246626321586,0.22364670580142043,0.6938169381989705,0.020416389321678885,-1.5955692313302379,3.1337949523169932,-1.6352118034708099,2.305457909181217,-1.2424428869412096,-0.25723815761828606,False,c1,2,"If someone capitalises a character(see https://en.wikipedia.org/w/index.php?title=Founder_effect&diff=559607253&oldid=558757694 for example) the VisualEditor does not recognise it as an alteration to page text and rejects their edit.
--------------------------
**Version**: unspecified
**Severity**: normal",51495,-3,High,True
-5.379559500194095,-0.9161484075138713,-3.145142400054823,-5.253549655555577,1.4005766050949435,-1.8670416494461384,-0.15274401172609853,2.6578213830278195,2.172173939400343,-1.5701909320852017,-0.5215074870386189,-2.6597930791001785,0.7253774090552314,-0.36980474598598967,-2.232479647841931,-0.01779376108994085,-0.1527606774364274,1.0763395838135692,False,c1,2,"Screenshot
See associated screenshot - this is for https://www.mediawiki.org/wiki/Template:Extension
When clicking the inspector icon, the window opens up but remains entirely blank and happily sits there like it for minutes* at a time. More worryingly, if I follow the normal workflow for a broken element (hit the X, make it go away, try and open it again) the inspector refuses to open at all, not just for that template but for other elements on the page.
*I gave up waiting; it may load, eventually, or never load.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49797
**Attached**: {F11051}",51493,-3,High,True
9.092342680091964,-10.55858399703587,2.6370243785459095,-1.533477039274458,-2.916721701897453,2.368237139480857,0.5018548028636989,-1.0583568785479494,-0.31520161900209454,-0.6580623933658627,-0.7361174943336728,-0.9726266181497841,0.592868235873588,-1.678883607125679,-1.608233592154983,-0.45220802107807745,0.03778778645102099,-0.6357096226281227,False,c1,2,"Screenshot
Screenshot attached - from https://www.mediawiki.org/wiki/Extension:Syntax_Highlighting
--------------------------
**Version**: unspecified
**Severity**: major
**Attached**: {F11040}",51488,-3,High,True
-3.872675479078179,-8.799046792587749,-0.5674274851429875,5.092752643084437,6.430361068587546,-1.4440491736362282,-3.3884934057661105,2.611953888387278,0.12655819309767657,-2.8388155177853935,5.657621134254372,2.3390065113954615,-3.3395564694902626,2.3306165732821107,-0.0529769195252916,0.6300575551531045,-0.44908316390466774,0.5806667910589456,False,c1,2,"1. Make a change and press save
2. close the save dialog (^)
3. Press save again
Note there is now a back button (<) which does nothing.
--------------------------
**Version**: unspecified
**Severity**: normal",51481,-3,High,True
2.0262495298663734,3.4292341431841713,3.729321790014378,8.797348587010138,-1.6416055939185104,2.4414178827013666,-1.860250020575994,-2.079986567515295,-1.71776576069224,3.385602975851892,-0.2990559528315089,-0.8448162880123307,-2.8916597417014804,0.5730531728441903,0.06763905411023519,0.8422816080796041,-1.7238134756234849,-0.15402697456721248,False,c1,2,"From a bug report in /mnt/bugs on parsoid.wmflabs.org.
The edited HTML snippet in question looks like this:
""<a href=""./Turkish_sparrow"" rel=""mw:WikiLink"" data-parsoid='{""a"":{""href"":""./Turkish_sparrow""},""sa"":{""href"":""Turkish sparrow""},""stx"":""simple"",""dsr"":[92,111,2,2]}'><a href=""American%20sparrow"" rel=""mw:WikiLink"">American sparrow</a></a>""
The editor may tried to edit a link from Turkish -> American sparrow
--------------------------
**Version**: unspecified
**Severity**: normal",51451,-3,High,True
-4.657182344579173,1.5199509578160715,1.241289505368215,-0.014287893043843924,-4.245311736364466,-2.174013269065674,-0.7798364015910186,2.0014823258893464,3.5836886497606812,0.3066787408596241,-1.1444960466286247,0.25368759608223446,0.960497861553073,-1.364468372155104,0.5864692276111017,-0.6937616464736029,0.6885993870514759,1.871965656647219,False,c1,2,"Right now, we have to do the following in ve.ui.MWReferenceDialog and ve.ui.MWMediaDialog to set up the sub-editor's surface correctly:
this.referenceSurface.addCommands( ve.init.mw.ViewPageTarget.static.surfaceCommands );
Instead of accessing ve.init.mw (and assuming all surfaces with MW*Dialogs will be instantiated by ve.init.mw.ViewPageTarget), we should just be able to say ""initialize this new surface based on this existing surface"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",51439,-3,High,False
-5.791286087332643,0.20910208616490422,-0.7608545663157162,1.9669531199267505,6.338459095980118,4.629495105787684,1.5475844634334122,-2.3619008542768696,1.1727717712456325,-0.7822983227080287,0.6407443356237446,-3.544164900391431,-0.19407910563092212,0.9869870825885494,-0.32933909953783846,-1.7540329110990802,0.35169018451345857,2.1002655714465055,False,c1,2,"**Author:** `swalling`
**Description:**
When attempting to remove an entire section with an h2 header, removing the text of the header does not remove the line separator underneath the header.
Additionally, one additional delete/backspace action deleted the entire preceding section, and it seems from the resulting content that I merely blanked the header but the wikitext for it remains.
--------------------------
**Version**: unspecified
**Severity**: normal",51424,-3,High,False
-5.5981017676745495,-2.8931990888800954,0.21852365350311942,-1.1455198224976755,3.7064266589560133,-2.3392696583371,2.153078133725594,-1.7037922809403292,2.2478254460917633,0.12972462277351493,-0.007147172890574094,-0.24341431021603843,-1.200400192139262,2.122255930542675,-1.6707510343833625,0.9959711911931294,1.4574694707527958,-0.8985765380402484,True,c1,2,"You can select it but the inspector menu doesn't trigger. Works fine if there's any content before the block.
--------------------------
**Version**: unspecified
**Severity**: normal",51421,-3,High,True
3.278269133652264,0.24247491037876046,-6.409984125374011,-0.5351443422334768,2.356933848655281,4.728912196240098,-0.9675884225610254,-0.31150192118725756,0.7677137911094414,-0.6520353890193453,0.7558195853691316,-2.786842658928591,2.1059088281003344,-0.8250554552894203,-2.101012785937082,1.777834248373787,1.2461133172932477,1.6814674312010227,False,c1,2,"Editing a page in a Hebrew wiki (possibly also in other RTL languages), adding a link does not show the popup. The word automatically becomes a wiki-link, no option to change the destination or make it an external link.
The link seems to work well in English wikis.
Tested on both my local install with the latest VE (VE-wmf6+) and on the hebrew wikipedia (VE-wmf5) and on both Firefox and Chrome.
--------------------------
**Version**: unspecified
**Severity**: critical",51416,-3,High,True
3.622944151077325,-1.8614398695412557,0.3403429488608687,-7.5915303921193695,4.811107433741768,-1.3034034471390916,-1.9480236509895779,-0.01787765317554793,-0.39133750628383557,1.2892697054084872,-0.868330280922069,-2.443815929116499,-0.6253109859118897,-1.5064018094645566,0.25725482291978796,-2.568110712765292,2.2661479426189217,-1.9194092390624786,False,c1,2,"Screenshot of VisualEditor on the English Wikipedia
I'm not even really sure how to explain this. I'll just include a screenshot.
I went to <https://en.wikipedia.org/wiki/Ready,_Willing_and_Able_(Daron_Norwood_song)> and clicked ""edit this page"". This is what appeared.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11769}",51411,-3,High,True
0.9000931125761729,-4.856035916269583,-3.9606672683956408,-3.13031262688874,-1.9450314825837831,-2.446186284625799,-6.5793924426234645,1.5716338671480492,0.8379983901258417,2.5513211572580667,1.537765623197577,0.6469699863011165,-1.6868802710553492,1.9016718757091757,-0.6247105278487197,0.07699079507813394,0.52100280881476,-0.8490504292242507,False,c1,2,"Create a document:
Foo <ref>Bar</ref> Baz
<references />
=>
Foo [1] Baz
1. Bar
==Test==
1. Select and copy from '[' to ']' (no whitespace)
2. Try to paste
3. Note you now just have plain text [1]
4. Note also if you make a larger selection (e.g. from 'o' to 'B'), copy/paste works fine.
This might be to do with whitespace truncation, and probably applies to other inline nodes.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52271
https://bugzilla.wikimedia.org/show_bug.cgi?id=54410",51396,-3,High,False
-4.20301737841233,-0.8819375189499681,-5.994667524772046,0.16433573094500198,-3.9912400845902765,3.4048381569112802,-1.1223273346223657,1.6014426045782102,-0.2950167414421878,3.4790624467575544,1.8277901342331275,3.320032672133795,-1.0237407676316463,1.8851136125037886,-3.1333838564385683,-0.8333431676357477,0.8546868602603117,0.6380922849440014,True,c1,2,"On attempting to edit and restore an oldid, everything works fine (oldid contents appear, diff shows correct wikitext change, etc.) but on save VE appears to send the wrong page version (presumably the 'newer' version that's meant to be replaced?) to MW so nothing gets saved.
--------------------------
**Version**: unspecified
**Severity**: critical",51390,-3,High,True
4.81946574344656,-8.650625330408772,3.6383597303410298,1.594716827035604,5.320822888327147,0.5318785283846832,-4.278567094680934,1.4045218052092299,4.28019644260778,-1.8387681318905504,2.9299425779712904,1.9232137568672385,0.9040507022665505,3.1389218191978223,0.4503338018805598,0.39761921302384956,-1.1964818410799356,-0.6818662143490091,False,c1,2,"1. Focus a node which triggers an inspector icon
2. Hit save
3. http://i.imgur.com/5YPyQL5.png
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49275
https://bugzilla.wikimedia.org/show_bug.cgi?id=49059",51361,-4,High,True
-4.110299184411862,-3.62456783393519,-5.86158712337334,-8.4166114255302,-7.308760895546756,2.0884958963629563,4.99591612432732,-0.952158388999183,-1.6393133733168126,11.556905506430802,6.07117937418306,1.2719081556421503,1.613953937480329,0.14327395800223997,1.0981520611503726,0.12048717728980299,-0.2745967846387085,-1.1802724456651044,False,c1,2,"Because we want to be able to make certain properties non-cloneable, e.g. in ve.dm.MWReferenceNode.prototype.getClonedElement we strip 'contentsUsed'.
--------------------------
**Version**: unspecified
**Severity**: normal",51307,-4,High,True
7.753788817880224,2.640607379975723,0.20220191067089743,-2.3638858668771805,3.0586083743203267,1.6665942413354913,-1.730147337485926,-0.09484470495730746,-0.8868218999102886,-1.6925237126186783,-1.1171162612810277,-1.3849929907848275,2.0038105884038253,0.8652265655760001,-0.5628691188573267,-1.483033535279135,0.9270097150122683,-1.2745613547984367,False,c1,2,"Screenshot of VisualEditor on the English Wikipedia using the Monobook skin, 2013-06-06
VisualEditor's review dialog box can be obfuscated by the green striped area from restricted areas of a page. This is when using Monobook, at least. Maybe Vector too, I don't know. I've attached a screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11508}",51284,-4,High,True
0.015439573800745343,3.3261635171225628,21.123906493272145,6.551984134204829,-2.7192391717711963,-4.472862489682279,2.6306160119136726,-3.180048924397595,-0.9919127166887396,-1.0378940121824676,-1.1256214415897845,0.29620891439807795,-0.7493423676880129,-1.9084398086660794,0.9391845237651575,-2.280539505021688,1.0432018922275332,-1.2756194634593856,False,c1,2,"https://en.wikipedia.org/wiki/Jeffrey_Chiesa?veaction=edit
When I go here currently, I get HTTPS warnings.
---
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/New_Jersey_Attorne…effrey_S_Chiesa.jpg/144px-New_Jersey_Attorney_General_Jeffrey_S_Chiesa.jpg.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/f/f0/Seal_of_the_United_States_Senate.svg/80px-Seal_of_the_United_States_Senate.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/Seal_of_New_Jersey.svg/90px-Seal_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Flag_of_New_Jersey.svg/75px-Flag_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/New_Jersey_Attorne…effrey_S_Chiesa.jpg/144px-New_Jersey_Attorney_General_Jeffrey_S_Chiesa.jpg.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/f/f0/Seal_of_the_United_States_Senate.svg/80px-Seal_of_the_United_States_Senate.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/Seal_of_New_Jersey.svg/90px-Seal_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Flag_of_New_Jersey.svg/75px-Flag_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
---
action=view is fine (no console warnings). When I go to veaction=edit, the console fills with warnings. It looks like VisualEditor is loading thumbnails unconditionally through HTTP. This should be changed to be protocol-relative.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/wiki/Jeffrey_Chiesa?veaction=edit",51283,-4,High,True
3.3092925530178463,-2.766646594101239,1.1092756910709198,-0.269228683561785,-1.306166967991479,1.3719606760356193,-0.5120865341112912,-2.358362933515653,2.8920974296369204,-1.1883941833355007,-0.6172590497135584,-0.8222589690489492,0.3498819837018474,-1.1769597756957704,-1.6455211147257849,-0.14071971382266985,-0.18644763210409065,1.804719179683149,False,c1,2,"**Author:** `swalling`
**Description:**
Screenshot
In attempting to test (as anon) on the MediaWiki.org sandbox, the page header template overlaps the diff and save functions, preventing me from saving my edit.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49361
**Attached**: {F11481}",51275,-4,High,True
-6.942763606544235,0.7242613955775212,-1.19391187436195,-5.776146102315725,-5.647553295067295,5.733612670255166,4.108605066457515,1.1899118283407772,-1.2175484748529202,1.8617915425018206,1.9016701233658986,5.588207857405297,0.12381977785111076,1.086521547902584,0.4263781883427544,-2.829485839610126,-1.7472885988115043,-1.4780000720223687,True,c1,2,"Necessary for beta rollout. Wording needs to be smithed carefully to ensure that it's clear that this is a temporary option.
--------------------------
**Version**: unspecified
**Severity**: minor",51260,-4,High,True
1.7121794354205018,2.5221651231897795,-1.0166664333946844,5.4382544164435735,-6.164597673770581,4.248087052535861,-4.377740540960302,-0.48952113801957686,-4.1592690645147945,3.217392546286016,5.097133670705134,-3.9953627047575067,-3.8711541775559857,1.262717940892248,1.1627308250911028,0.6139055616801724,1.405150144744186,-1.8273931429763386,False,c1,2,"For example in the second line of the multibyte.html test file in the standalone demo (after '<tt>香港</tt>' [Hong Kong])
--------------------------
**Version**: unspecified
**Severity**: normal",51246,-4,High,True
-3.4206585515518064,-4.42814679921004,-2.6310567254194943,3.4093386337514984,1.0783345457605473,-6.164145123409977,-1.0211249758132412,1.4521818654503122,-1.6360016434356832,3.3204400792968283,-3.6406707500586126,1.0167850746970581,-0.0844079476787769,-1.6186514002228565,-2.179677780540422,-1.7876178210713976,-1.5543974513832997,4.63175496604367,False,c1,2,"Visual Editor doesn't behave correctly when editing and adding text with combining diacritics.
For example insert the text ""ɛ́"" (ɛ is character U+025B, combining acute is U+0301).
When the cursor is behind ""ɛ́"":
- pushing the left arrow doesn't move the cursor
- adding text like ""ɛ́abcdef"" is fine but:
- pushing backspace gives ""ɛ́abcda"" instead of expected ""ɛ́abcde""
- pushing return ives ""ɛ́abcde\na""
Some languages require combining diacritics, many keyboard layouts allow their input or user can insert them by copying and pasting from somewhere else.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51472",51233,-4,High,True
8.570066602884506,-0.9733140666458109,1.8632302048896214,-1.9782427851095683,-0.8107514452909168,-0.3071889945165659,-0.2641082564279911,3.0904570678427676,0.2998524527854446,-0.030176157540043214,0.8577850486080907,3.313232308287942,0.745016932554659,-0.2931032454179858,-3.3363216322370013,3.706877987274946,2.2524080336673116,2.3428686425024416,False,c1,1,"grey text, no diff appears after Review and save
Seen in IE9 and below, works OK in FF and Chrome:
Make an edit with VE
Click Review and save
Page text is greyed out; no diff appears; Review and save button remains clickable; user cannot complete edit
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11329}",51187,-4,High,False
0.35905013119593665,-6.120737298895465,-2.400318019809724,-0.2642501684853157,-4.001229590975466,3.9662186388622596,0.7692804671986266,0.12705606903402777,3.6010715022183506,-0.7706739537253768,-1.391396406222219,2.6791827808961513,-0.8341014480682221,-0.21157439498758102,0.9280444933485521,-0.03600200801957104,1.037186778880385,0.4013636937994478,False,c1,1,"* Move cursor to start/end of document
* Press left (start) or right (end)
* An exception is thrown by handleLeftOrRightArrowKey
--------------------------
**Version**: unspecified
**Severity**: normal",51091,-4,High,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",50980,-5,High,True
-4.9617807798356015,-1.8197440577532884,1.8505480454090346,-4.121364550423494,-8.844775163096335,-2.3677706469167585,4.044834719267631,-1.3413629690764588,2.1947471235548255,0.29863586515984863,-0.1769605964642147,-2.8327144628037235,-1.1679314095871787,0.346525997778925,0.02718261833977742,0.006122020342323897,-1.0950838065264423,-3.150076915833394,False,c1,1,"So that we can correctly calculate boundaries in unicode.wordbreak.js
--------------------------
**Version**: unspecified
**Severity**: major",50975,-5,High,True
-0.9705346074008743,-9.18777917060098,1.7607068481877342,-0.7736511299362128,-2.7034294017252027,-5.270379349435674,-1.5218174232786374,1.9343390918198677,-1.6054453330827057,-1.2008131807609987,5.15899974323637,-2.196337140970047,-4.687414506903655,0.3249130090640264,-0.8899078868153412,0.4797634259395137,0.24767393414199934,-1.308145124550362,True,c1,1,"Currently we don't -> lots of broken imagery in /w/index.php etc. entry points.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59196",50915,-5,High,False
5.658003755247011,-1.3146545174663817,-3.8484353590829574,-3.899862682208734,6.6849872805417725,-2.5608695143228006,-2.3305977926513712,-4.149957600124179,-3.9413885361125827,3.4603497567725086,-2.4049062072545544,1.1134100443068673,-0.696330678437155,-0.7261706173642777,-0.48156207181748645,0.1426466714369355,0.7625940558221023,1.21945596990709,False,c1,1,"Pressing Ctrl-Backspace deletes a word in a <textarea> in Firefox. It works the same way in VisualEditor when the wiki's language is English, but if it's Hebrew, it only deletes one character.
A GWT testing scenario for this would be something like this:
Given $wgLanguageCode is 'he'
And I am editing an article
And I wrote 'אחת שתיים שלוש'
When I press Ctrl-Backspace
Then the remaining text is 'אחת שתיים '
--------------------------
**Version**: unspecified
**Severity**: normal",50912,-5,High,True
-7.875306308881774,2.7234877572768212,-0.10730706265032453,2.7004194925718994,1.5480375585438804,7.1294636723352935,0.5583723292417524,1.8299888106814652,-0.9855454493073927,-0.5905353525933013,-0.020405124477939296,-0.2755545305051993,0.6446318570600704,0.388790220594581,-0.4143215770465405,1.3841771750356102,2.352572412856256,-0.829694809672314,False,c1,1,"Place the cursor at the first position of some heading (before the heading's first character). Hit Enter. As expected, an empty line appears before the heading, but the cursor is unexpectedly advanced by one position and is now located *after* the heading's first character.
--------------------------
**Version**: unspecified
**Severity**: normal",50847,-6,High,True
-5.436430701835487,5.773379328840303,2.8278649581004274,2.331533255987935,3.7533202443058884,2.02311895943098,0.10261911052435124,0.06048988849803055,-0.7065869520450974,-2.320236092988486,-1.0213544264336933,-1.5154486881293012,0.8905798213827434,1.5290037674544088,1.4488742163162858,-0.07884522271732952,0.3425059453290591,-1.0967742602867554,False,c1,1,"Open the VisualEditor on the page https://en.wikipedia.org/wiki/Battle_of_Paris_(1814) . The two images are placed side by side between the lead paragraph and the infobox; they should be placed below the infobox.
It appears that the VisualEditor generally arranges two images horizontally rather than vertically, unlike the wikitext renderer.
--------------------------
**Version**: unspecified
**Severity**: normal",50845,-6,High,True
-5.1243980136889995,-0.875707378301664,-5.3637527529479865,-3.987300618434213,3.514512771337508,1.7840578969809473,-2.5580993960565244,2.682759221380147,3.189958027167431,2.156794523377962,-3.072938405432482,2.8245676771361055,-1.3617406616968077,0.5978986110744753,0.9094341946401574,-3.760645909284398,1.482707620666279,-0.4449932843256572,True,c1,1,"This is to make the categories pane less lonely; we will want to do this 'properly' (writable) later, though this is… challenging given the Wikidata complexities.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50814,-6,High,True
-1.70837077677074,0.9117296502137435,-2.661793533949874,1.4417845476899687,2.9463843451618272,-0.316886181281257,-1.9688540022513603,-1.3557670749767117,-0.17052538605960377,0.49338507936360987,-0.7866175433060301,-1.8640891659966385,0.34601871876644674,-2.3867200332387974,1.090159990988301,-0.7680534805348169,0.19823133892210998,-1.0522709969355204,False,c1,1,"This is using Firefox under Ubuntu 13.x:
The problem:
If the wiki is RTL (Hebrew, for instance), start editing an empty page. The caret appears on the left side and the typing is done LTR.
I did a quick check, and noticed that there is a class added to the content box - ""ve-ui-surface mw-content-ltr"" even when the page language is rtl (defined in the <html dir=""rtl""..>
I found this addition in the ve.init.mw.ViewPageTarget line 786:
this.surface.$.addClass( 'mw-content-' + mw.config.get( 'wgVisualEditor' ).pageLanguageDir );
In my system this produced ""mw-content-ltr"" despite the fact the page language was Hebrew and the html direction was defined as rtl.
However, I then tried to forcefully change it to rtl, just to test, and while the class appeared correctly (mw-content-rtl), the direction of the typed text was still LTR. It remained LTR when I changed the language to English.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux",50765,-6,High,True
-8.537392735232048,-2.940314681121409,-4.857006238535156,0.3484947470059556,2.7527391567534703,3.5445554299196766,2.3291950294820145,-1.6405763683512857,1.620774973776614,1.7510580967920077,5.168527159873429,0.9811858229076591,0.006419481852817377,-0.5783040476686363,1.300862817796692,2.684131184355321,-1.5767618011133564,1.897935903378808,False,c1,1,"Select an inline node (e.g. an inline image) on it's own (i.e. no whitespace either side of it), and trying to copy will throw an exception (ve.dm.Document.js:786 selection[0].range is undefined)
--------------------------
**Version**: unspecified
**Severity**: normal",50604,-7,High,True
-4.524407369991991,5.028272850607969,-0.6573465386319448,-0.2006924338557392,3.4387700365633562,0.9790526936547403,-1.5427995795531668,-3.4544301027680335,0.33364623002833216,-0.9342610338752602,3.2227456892238124,-1.8524059117502936,-0.3323186023157936,-0.4180659945429639,0.7975075241129392,-0.04078028841751874,1.30371259465298,-1.1355715106767132,False,c1,1,"I used VE in Firefox 21.0 on Ubuntu to edit https://www.mediawiki.org/wiki/Backporting_Fixes . I changed a few headings, then pressed Enter between a heading and a numbered list below it to insert a new line (not sure if the caret was on the end of the heading or the start of the first item, I'm not sure if I started typing.
VE began inserting the first sentence of the numbered list but with its link changed to two snowmen, about 15 times. Every time I clicked it would prepend some more. Even scrolling would trigger this.
Before, the document contained
== WMF Cluster Backports ==
# Make sure there is a bug registered in [[mw:Bugzilla|Bugzilla]] for the issue.
I couldn't edit the document, but VE's review and save button worked fine. The new document showed as
== ==
# Make sure there is a bug registered in ☃☃ for the issue.Make sure there is a bug registered in ☃☃ for the issue. <repeated 269 more times>Make sure there is a bug registered in [[mw:Bugzilla|Bugzilla]] for the issue.
I don't know what happened to the heading, I didn't blank it out. I might have attempted a cut and paste, maybe that's what's going haywire, though I'm pretty sure the last thing I did was pressed Enter to add a sentence after the heading.
I assume this is an Easter egg in the VE codebase: if you manipulate the document near an exhortation to file a bug, Parsoid detects it and repeats the phrase, with snow people 8-)
--------------------------
**Version**: unspecified
**Severity**: normal",50592,-7,High,True
3.7617637157373642,-4.350730346738882,6.289555086140613,1.3148564478236269,5.49575293657343,0.4593282268722967,-1.6398221472349706,-0.2662423304947396,2.746797078903996,-1.7882273699089617,-0.4932800440272991,-2.794852916984306,1.6511117823774448,-2.4340189603755884,0.7758408112452111,0.014904849604973569,1.333719697002502,-0.5441989088977313,False,c1,1,"See https://fr.wikipedia.org/w/index.php?title=COE&diff=prev&oldid=93166267 for example.
I only removed the link, but VisualEditor added a space before the colons.
Another example: https://fr.wikipedia.org/w/index.php?title=MSS&diff=prev&oldid=93166411
There was already two spaces, but VisualEditor added a third.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51024",50570,-7,High,False
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,True,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",50566,-7,High,False
-4.365582109625986,-4.492704437661265,-3.776319712488185,-6.296368215030495,0.29281016327637566,-1.427175301371706,-0.15238643533980412,1.3741566970804802,0.3804801465128199,1.767806746743295,-1.3212679382318484,-0.7317951116045542,0.700619552265576,2.8734890531810473,-0.7288464042067373,1.1850324371166523,3.143776672813372,4.16162253523139,True,c1,1,"Not sure how to reproduce, but I get two items in the ""Matching categories"" section; I can only move to the top one, and pressing down doesn't work (but pointer-highlighting and selection does).
--------------------------
**Version**: unspecified
**Severity**: major",50565,-7,High,True
0.9781801217537365,-17.869547122693323,-5.220286576535438,-2.574243610812264,-2.0450275013262447,5.861690617773853,3.0310100229115333,-0.6494408554847819,0.16082679462413457,0.5653550858005492,0.4597239704050242,-1.2990169873342783,-0.15710337680384345,-0.42180271184458995,-0.5825311518848411,-0.49268925925624174,0.0723332972457722,-0.28923892051716615,True,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: trivial",50561,-7,High,True
-2.2064505667120873,-2.6148245601768174,6.849816895599531,-1.0933345197526871,-0.9192636075562746,-2.1193123818911284,-0.042446930109831804,-3.4258726260754115,5.3051632984048895,-0.1712971175101652,0.8172316056858304,0.5366394453809915,0.5222352135484751,0.2446436412351023,-0.9982000632751964,-0.13110753089256283,-0.4724875031553559,-1.2844931632155658,True,c1,1,"Do we need to trigger a re-render of the catlinks div? Can we?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52403",50560,-7,High,False
-4.5254290021180665,-7.102116396482258,-3.7118012096676853,-2.4212506483362053,4.826251336143354,2.798384132678513,3.0434154454658993,6.481454395546693,-0.00210640019026892,0.047878951222235955,0.01204652310819565,-1.8203488525705045,-0.5489333093575537,0.2599517362568209,0.030851254120348948,-1.3555637547669108,-0.33739787058138293,-1.388924551249557,False,c1,1,"The button should probably not do anything if the inspector is already open.
--------------------------
**Version**: unspecified
**Severity**: normal",50549,-7,High,True
-5.25842733056243,1.3713405034325508,1.4510406109147382,3.620619313173142,5.529267269005379,0.25097907362336747,-1.4757696097195696,-2.033000967850347,-3.7534864906985126,1.9189387324849099,-5.02314905714733,-1.7110607566165341,-2.3495956567003073,4.632356614623328,-1.650991603294253,-1.9000612259188485,-0.38726740445676255,-2.0985822896575366,False,c1,1,"If the image has focus when you click back on the 'Read' tab, the four circles stay on the page.
--------------------------
**Version**: unspecified
**Severity**: minor",50530,-7,High,True
-2.812465659179634,-8.381519585856372,-4.045985927624656,-5.227000236603164,1.1172336022828786,4.86894877170391,3.722353190331215,-3.4917875288492057,-2.8846518193326975,1.0443685775093705,2.235063258706139,1.2825043533354423,0.5559035051299466,-1.259729216522742,1.0575574613339764,-1.1469170231888608,-1.5047795315777932,-1.146746902972988,True,c1,1,"Once it exists being the relevant part. :-)
--------------------------
**Version**: unspecified
**Severity**: normal",50524,-7,High,False
-0.810918449696743,-4.780135187066845,-0.9329371453213753,-1.0112804527366328,-1.340356049585234,2.6576724488893984,3.9086052853473676,1.996724181953415,-4.51954948735732,1.2989368295086035,-0.437197354605638,1.2360690984568177,-0.6930522234398016,0.11963048936422105,-1.0713455974239876,-0.7142084411573546,0.6872881704025493,-0.47622337289652994,False,c1,1,"In ve.init.mw.ViewPageTarget.prototype.tearDownToolbar, this.toolbar is undefined if the editor hasn't finished loading.
--------------------------
**Version**: unspecified
**Severity**: normal",50520,-7,High,True
2.104546390732588,2.0136399275194563,-1.5989000336575625,0.6153819700483238,-0.450524001558264,0.6841282549801933,-2.163868037295635,-0.5006729141726189,-4.176192999826063,3.508774194442397,-1.154122437999981,2.194773025449149,-0.6249790581465797,-0.37238118257099284,-0.5997138991181572,2.032567157603466,-1.6185197704943606,-0.5190609855103514,False,c1,1,"Screenshot of problem
Scenario:
* Document contains "" ... esams ... ""
* Wiki has a page called ""Esams"".
* Wiki does not have case-sensitive first character in the main namespace.
* Select ""esams"" and turn it into a link
* UI shows:
[ esams ]
New page:
<redlink> esams
Matching page:
Esams
Esams cluster
Esams patches
That first redlink is incorrect, it should show the same as when the input is ""Esams"" (with capital E), namely no ""redlink"" since the first match is in fact the input.
It needs to account for the $wgCapitalLinkOverrides and $wgCapitalLinkOverrides configuration etc. This is abstracted in PHP by MWNamespace::isCapitalized, which is exposed in javascript as 'wgCaseSensitiveNamespaces' in mw.config.
--------------------------
**Version**: unspecified
**Severity**: major
**Attached**: {F10838}",50476,-7,High,True
-1.8377080276977622,9.92182348535632,4.087834739807377,0.5592998176161248,-1.4579285457766367,4.5385637875911495,-3.464707133142284,-0.4636490072330872,0.005649879303589955,-0.28513333386783835,1.3731180003582035,-1.5799658508848986,2.3586992889538703,2.1091928207275368,-0.9383981660092164,-0.5568026233539184,-0.5412193040522938,0.9341268077834537,False,c1,1,"1 Go to a page with several paragraphs. Edit with VisualEditor.
2. Place cursor at the end of paragraph N and press Enter to create a new line. See the cursor blinking in a new line after paragraph N.
3. Select ""Heading 2"" in the dropdown menu.
EXPECTED
A Heading 2 line appears at the end of paragraph N.
ACTUAL OUTCOME
A Heading 2 line appears at the end of paragraph N-1.
As a matter of fact I find no way to place the header where I want, unless going to the end of paragraph N+1 only to trick the bug. Selecting an existing line and trying to make a header out of it doesn't seem to work either (but this is probably a different bug).
Happens at least in mediawiki.org with Firefox 22.0a2 (2013-05-07).
--------------------------
**Version**: unspecified
**Severity**: normal",50464,-7,High,True
-5.629273239070525,3.428400501749234,1.1582939116364344,2.6895057816055967,8.39395628207254,0.8547161805266483,-0.9013202411470962,-3.050470918163283,0.34088653719896933,0.6030262229947567,1.3377094715108186,1.2611938274315906,-3.148141722496449,3.4319347941952003,-1.5441081132965389,0.22606064034397377,-2.837215514943405,-0.5286509616965811,False,c1,1,"When I go to use the VisualEditor (e.g., <https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals> --> click ""edit""), there's a bothersome notice every time the VisualEditor form loads about how it's the alpha version of the tool. There's no way to dismiss the notice and it gets a bit grating after a while.
--------------------------
**Version**: unspecified
**Severity**: trivial",50428,-7,High,True
-4.625363991512749,-6.225175248013558,-1.4992443034051028,1.6888680742854443,-0.8802696341286098,6.380156367694295,0.27910762813658785,-0.4420904931623526,1.8153979179852653,-1.7784956740517446,-2.1027510012534454,0.6462266201955893,-1.1673646979687389,-1.1998629595686423,1.434203047192364,-0.7845879105599944,0.6688797744540393,-1.561685401322932,True,c1,1,"Tracker for the bugs/enhancements that should be done for the beta.
--------------------------
**Version**: unspecified
**Severity**: normal",50426,-7,High,False
8.012390782059706,-4.1334784742027235,-2.3127279795652385,4.374087523513576,0.47986208288822696,-2.2238652459944106,-5.852706617722178,-1.870430988219467,-2.6248019601746284,1.6358021139025167,4.382725002134322,0.901471025764123,-5.027690536239313,-2.2936774230320296,2.487262478902065,-0.4415977367129018,-1.832368395713122,-0.1786609688865517,True,c1,1,"[[:File:SpecialPage_Filter_JS.png]]
is being converted to:
<a rel=""mw:Image"" href=""../File:SpecialPage_Filter_JS.png"" data-parsoid=""{"tsr":[21446,21481],"src":"[[:File:SpecialPage Filter JS.png]]","dsr":[21446,21481,null,null]}""><img src=""../Special:FilePath/SpecialPage_Filter_JS.png?width=200"" alt=""SpecialPage_Filter_JS.png"" width=""200"" style=""vertical-align: middle;"" data-parsoid=""{}""></a>
It should be an <a> without the <img> inside it.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid.wmflabs.org/mw/User:Dantman/Code_Ideas",50387,-8,High,True
-2.9277898107964777,1.8792146352969716,2.333584997909284,1.284893295377465,-1.4821652522134565,3.024051567752136,0.661636210255443,-0.22309361769595326,-2.8093150725545204,-1.3912321197677233,-0.4255148260455939,-2.1612071686331227,1.4184549264893267,-1.4034911175336053,-1.0721020243543853,-0.19935986452672028,-0.20757701491039082,-2.421417183151228,True,c1,1,"Putting this in DM because it seems the most likely suspect.
Original bug occurred on enwiki (text in the test stolen from there). This feels like a bit of bug 43543 - which was fixed?
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/index.php?title=VisualEditor:TestAutolinks&diff=688670&oldid=688669",50367,-8,High,True
-2.9721665211195205,1.2117948145027615,-5.004486497052124,5.985154333970075,3.3478697626328238,0.5608960293888516,-3.35238552785385,-0.9163168029162654,-0.8917108795757872,-2.296009356939478,-0.2034492617932968,0.8293199087928687,-1.3361681521610729,-1.534595995574631,-1.1708471441309785,-0.5793459548713054,0.8419525775817933,-0.9452802885429776,True,c1,1,"This was happening with <ref>s, but it looks like it'll be an issue with an paragraph that ends with an inline alien:
| Foo.<ref>Ref</ref>
| Bar.
Backspace with the cursor to the left of the 'B', or delete with the cursor to the right of the <ref> block, has no effect.
The problem with <ref>s will go away(?) when that node handler code is enabled, but is this a wider issue?
--------------------------
**Version**: unspecified
**Severity**: minor",50366,-8,High,True
-7.091004067302148,7.764406973695259,-6.491338127191728,-10.666657664730739,-7.458479228701444,1.3001344722792652,0.5256113846984674,1.3034677213281833,2.732789701098553,-1.246437098791032,-0.8643763168068235,-0.16553844402886586,-0.22449317950741854,0.007998963873293796,-0.3584128657105188,-4.515638344806073,0.01837958589711919,-0.21255588463501485,True,c1,1,"Inez has some ideas about how to do this, so marking to him for now. Would be nice to document here /home/ we want to do this so someone can pick it up at some point. :-)
--------------------------
**Version**: unspecified
**Severity**: major",50335,-8,High,True
17.30024319793972,0.2684113220251465,6.726579453021685,-3.2215128642495907,0.6488717787520906,1.4447914115261555,-3.935905137296753,0.6266432050886196,2.297910148305185,1.7479445615160403,-2.921361166629649,-1.913916941689976,0.6921682920301606,2.5141965873122443,2.0026928771673065,0.9124908875769853,-1.0034189222813508,0.6944999540103398,False,c1,1,"Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type ""Enter"" 2 times.
Type ""Up"".
Type a
Type Enter
Type b
Type Up
Type Left
Press Shift and hold it
Type Down
Expected: selection of 1 line
Actually: selection of 2 lines
--------------------------
**Version**: unspecified
**Severity**: normal",50289,-8,High,True
8.315650642656514,-5.078859507577443,6.289366177205668,0.7293238011355943,0.9250282017090867,1.06180372570408,-4.4181434560417925,0.28898845574174137,-0.6399387528674879,7.856413431800101,-2.6358878617104127,-0.4424675516653903,0.3201465312292564,0.8135348876483643,1.0981904337252706,0.8061317666671395,-2.3878873544746524,0.9359684001245838,False,c1,1,"Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type ""Enter"" 2 times.
Type ""Up"".
Type ""Tab""
Wild pawn appears.
--------------------------
**Version**: unspecified
**Severity**: normal",50288,-8,High,True
-0.15724286542276777,-9.432149470968518,3.4794409897200502,1.8309659935140798,-5.548678043094981,-0.9904101709663635,-2.1209719333028767,-0.34650950195364216,1.3049242807778907,-1.8755819540703977,2.1268643623381114,0.8166382549621145,-1.8791540894198748,-1.3366428098259928,-1.3692304570926055,-2.7689642224121993,-0.7779401923651189,1.2054484596884902,True,c1,1,"Examining with user what browser/etc. to investigate.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://en.wikipedia.org/w/index.php?title=Indo-Pakistani_War_of_1965&diff=prev&oldid=552704403",50227,-8,High,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,True,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",50171,-8,High,False
-2.260555863044561,1.1772901144457517,-2.4659170827259906,-3.2933211717788415,-1.2844629480860215,0.2829240336142822,-1.143297973510582,2.5153077709349594,2.7634978180077665,0.9858422555095006,-0.7057411205029034,-2.015688034146132,0.6855738402105835,-0.8869657658039127,-1.6110652596353026,1.0209781428002307,1.597359056683221,1.2417971582643872,False,c1,1,"unexpected untyped characters
Upon loading page in VE:
Click CTRL-B and type some characters;
click CTRL-I and type some characters;
* often but not always reproducible, seen in Chrome/OSX, also reported in IE and FF: upon typing after ctrl-B or ctrl-I for ""bold"" or ""italic"", characters appear that have not been entered. see screen shot
* possibly related, seen but not reproducible: some combination of actions will cause VE to type a string into a page over and over and over without any action on the part of the user. I'll file a new bug if I can figure out how to repron that behavior.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11070}",50166,-8,High,True
11.214825141415782,1.192249747260858,-2.0227070524945443,5.667872965072695,0.925164105489648,-3.0498374803769845,-3.019035208519665,-1.6173457805317306,-0.7128921155991417,-2.100436227441501,1.6599041626046085,-0.5472216377626297,-1.827197998233114,-1.8497271644674238,0.0854976082612886,0.029589579643935437,1.216717737140547,-0.33765093857173745,False,c1,1,"From this bug report on parsoid.wmflabs.org: /mnt/bugs/2013-05-04T01:11:28.439Z-Style_guide%252FAssets_and_gallery
""I typed some text in this paragraph that is styled as a span italic, and VE decided to close and reopen the span on either side of the link. I think that happened before I made the text a link. (This is User:S Page (WMF) here.)""
Relevant diff line below:
−
:<span style=""font-style: italic;"">See Also: [[Commons:Category:MediaWiki style guide]]</span>
+
:<span style=""font-style: italic;"">See also: </span>[[Wikimedia Foundation Design/Agora Icon Set]] and<span style=""font-style: italic;""> [[Commons:Category:MediaWiki style guide]]</span>
--------------------------
**Version**: unspecified
**Severity**: minor",50159,-8,High,True
-3.2715152641342797,-2.6526161663784293,-4.423747321499988,-1.6868555417961915,-0.05305844842193619,0.7894786405282084,1.258171529264695,-1.8314226543182683,0.19502053360971938,-1.8133755088647483,-2.2393951122854894,0.9770301083315951,-1.3321257998045297,0.9542617929063715,-1.7086945243923668,0.6848170315932347,0.5484652928484501,-0.7385962501594336,False,c1,1,"If you add a link to the last word in your paragraph (quite common I'd imagine if you're in the middle of typing a sentence), the insertion annotation behaviour makes any text typed after the link part of that link - which in most cases is not what you meant to do.
Insertion annotations make sense for text style annotations, but not link annotations. This is what Google Docs & LibreOffice do aswell.
--------------------------
**Version**: unspecified
**Severity**: normal",50114,-9,High,True
-1.4598084042431598,3.358451816584573,1.2104388171047056,3.6513327918006198,0.7233049556745825,1.7570054824290031,1.2201238608805793,-3.028038802255118,-1.9081634296202024,-2.3350813199797336,-1.837151993170856,0.18837885729943893,-0.25689579879360913,2.1097415496139114,-0.9219746480868496,-0.7981162023301371,0.1660463037242681,-0.5258442261195948,True,c1,1,"Currently we steal all the things on action=edit for veaction=edit (so Ctrl-Option-e goes to VisualEditor, leaving nothing for the wikitext editor). We should add a new one - Ctrl-Option-s (for *s*ource) - though that's used for save in the wikitext editor, which is a bit odd. Ideas?
--------------------------
**Version**: unspecified
**Severity**: minor",50107,-9,High,True
0.8715597119216052,2.204927052859915,1.3972713722172756,1.3720752999312626,7.603548452922254,0.2542547835833002,1.6032766522401642,-4.510596713809107,-2.4956649407266562,1.1019589323704606,-0.1570883290946905,0.21251574640805404,-0.5276180771320362,-2.3454150175916486,1.9138260916227434,1.0420013286819845,-1.4756224991777123,0.7848669214070878,False,c1,1,"I changed a link here: http://sv.wikipedia.org/w/index.php?title=Intellektuell_s%C3%A4rbeg%C3%A5vning&diff=21539781&oldid=21539483
In the VisualEditor interface, the word ""Känsla"" is showed with a lower case k, but when you are looking at the article, or source it is K.
--------------------------
**Version**: unspecified
**Severity**: normal",50060,-9,High,True
-6.3626899907651815,1.3635565452572482,2.2958874174630495,2.870957525367856,4.2485883008763,2.0455306045531243,0.9634987880634593,0.7132906249286616,1.8308568422630704,0.10485506913628662,1.661451487484555,-1.5645541560560376,1.2072046411105268,-1.545436168472282,0.1986175690493086,-0.9934855326305696,-0.25563089241263426,-1.6686794310681992,False,c1,1,"All the pawns
See attached image, basically the idea is that indenting or de-indenting a list item will cause there to be a pawn in the list item. Also, when I used the arrow keys to navigate past some images, it put pawns next to the images.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10767}",50024,-9,High,True
7.48478154739111,7.4346733025478,4.6791100512075126,-4.212729362228989,12.659681425479071,0.3259203775723276,-1.7434444855546722,10.393670651806467,0.913364651659685,-3.3751842755430275,-3.1353669489549234,-1.9228225292404404,-1.2449631535069896,0.5802572487293638,0.8354231324088426,-0.12030903585559061,-3.1841766569874985,0.3313566300142672,True,c1,1,The order should be Edit then Edit tab. Looks like a hard-coded left somewhere?,50017,-9,High,False
-4.143122568835533,-8.432966646191439,-4.003757655058205,-2.9263326935586838,-4.086687134886914,-0.908971675784497,3.426036473600054,-0.12106717080588392,0.7959020885228656,-0.20592013097137052,0.2412637166599958,1.3229429608794192,0.8006552215109775,1.4837097319298982,2.3278116855146553,2.158798554068638,-0.5844130714926887,1.5187015766090164,False,c1,1,"There are probably two solutions - make it work - or disable list buttons while in block slug.
--------------------------
**Version**: unspecified
**Severity**: normal",49947,-9,High,True
-5.34122337194322,3.641586584153359,1.4529254357156205,-0.30124535203754965,4.758699227506227,5.910851817562297,-3.23849256230877,0.2966996514440118,7.916731480723259,0.48606727219373447,1.1631886758936187,0.3911346172228971,1.146343805137589,-2.3556361739631337,2.1786656496261436,-2.161287702073764,4.047008034188159,1.5423207531247114,False,c1,1,"The user was trying to edit http://de.wikipedia.org/w/index.php?title=Reiniger,_Gebbert_%26_Schall&direction=prev&oldid=117917379 to remove the first heading but keep the image. The result was http://de.wikipedia.org/w/index.php?title=Reiniger,_Gebbert_%26_Schall&direction=next&oldid=103767568 and the didn't manage to do it without adding the ♙.
--------------------------
**Version**: unspecified
**Severity**: normal",49943,-9,High,True
-8.380754151983544,0.2836320803241268,0.3425457807565486,0.26383457096887586,-1.468359442073964,-3.9696748382570064,2.5747838164017773,0.32779113250193126,7.1176236234627055,1.4941037287498622,2.68095398214007,1.5851824587493748,1.0150004903600092,-0.4411352215409785,0.49670381762281046,-0.7264904543632906,0.13176962523249403,1.0282018275898681,True,c1,1,"This just means supporting their use, not being able to set their parameters, but will de-alienate a large amount of content for trivial work at our end. The parameter setting/editing will need to come later.
--------------------------
**Version**: unspecified
**Severity**: minor",49907,-9,High,True
1.5383817208381987,-5.969922796106909,-2.5558750439949147,0.09584107694809618,-3.599771053097171,-1.6634886166050737,-1.5946281423929403,2.228260535581955,1.601080287635795,-1.2138968315337593,1.6374984573916707,-0.4626464735641862,0.17172020141253963,-2.1434446995329592,-1.7336552999021881,1.4476015253761882,-0.11334774948880577,0.5582996587907301,False,c1,1,"Screenshot of LQT thread with </div> in title
Should be treated the same as regular page titles: Escape everything.
Or, if we want to keep wikitext parsing (e.g. for wikilinks, sometimes done in section headings), then parse as inline block (not allowing any block level elements like <div> or <table>) and make sure open/close tags match (run Tidy).
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://www.mediawiki.org/wiki/Thread:Project:Support_desk/visible_html_on_pages%3A
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31244
https://bugzilla.wikimedia.org/show_bug.cgi?id=29564
**Attached**: {F10533}",49885,-9,High,False
8.81944177873594,1.950120644280247,3.2187994923862355,3.776474266013543,-0.7559354405529307,1.6520199407498135,-0.8087125796020951,-0.4508580917695213,-1.2718666918460242,-1.790263783567252,-0.9508143350807918,-0.21128416126784544,2.3293690122891757,-0.6222616001337578,0.44860267983750113,1.4241305849079051,-1.242474368842681,0.6504507559628563,False,c1,1,"VisualEditor (50e8693)
Parsoid (ba0b080)
MW: 1.22/wmf2 (814f75e)
While editing a page in Firefox 20.0, the existing page content is blank in the editor.
The issues seems to be an issue with Firefox only, as Chrome and Safari work as expected.
--------------------------
**Version**: unspecified
**Severity**: critical
**OS**: Mac OS X 10.7
**Platform**: Macintosh",49834,-9,High,True
1.4869428285268902,-4.999447996909332,1.779348987296082,0.47540060765190084,-1.2181588992567547,-1.7601536865760306,0.5189322581855462,2.528999170267058,2.330499857958068,2.7323638533379144,0.15647835588581094,-1.0046366815706795,0.7097021261327647,-0.7779417490189431,-1.2707185544561543,-1.1107929652386657,-1.0385021738942357,0.5634462920479122,False,c1,1,"VE error when not completely loaded
on any page editable by VE:
invoke VE
immediately click Preferences or other live link
an alert appears saying ""Error loading data from server: error. Would you like to retry?""
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10400}",49813,-9,High,True
0.8693302076166813,-1.543998903581059,-1.8908826706364508,-1.473690019731598,3.11879594733259,-0.8981167663925782,-1.1842917492151432,-1.353542755186535,-1.9967556088694267,-2.5882749096732187,-0.19405118063593685,1.3131433657007656,1.8711663214673058,0.04923625446616153,0.07549315763087883,-0.1368180814271041,-0.055514371681713914,-0.14574629308548936,False,c1,1,"Hi,
The problem is that when I have created a bullet list in Visual Editor and try to erase back the text using Backspaces, the numbers or bullet points don't delete even if I have deleted the whole text. Here is a trivial demonstration :
1. Hello1
2. Hello2
3. Hello3
Now when I try to delete it from the Hello3 using backspaces, all the text upto first bullet is deleted, but those bullet points are left as it is.
1.
2.
3.
Images:
https://docs.google.com/file/d/0B3eGCB261PalaDhqa1ZhcmFPUk0/edit?usp=sharing
https://docs.google.com/file/d/0B3eGCB261PalbndsZEFSdXpEZGM/edit?usp=sharing
Tested on Firefox 20.
--------------------------
**Version**: unspecified
**Severity**: normal",49795,-10,High,True
-1.1302711431731947,13.840362334536483,1.190319863076315,-10.699598612975038,-6.567174634885685,-4.226017387826857,-0.5448509833987858,1.0484017118244666,0.1914749771742117,-1.4240157041370227,-1.689010209835092,-1.5453852629779532,-0.041729538817818046,0.9476380928238131,-3.5757558149390536,1.8429888667290348,-0.3979671688156594,0.23934718621932505,True,c1,1,"Add button to WikiEditor and VisualEditor for switching back and forth.
* Only shown if in WE you have VE enabled (otherwise don't show)
* If no changes, switch immediately
* If there are changes, prompt the user (with the same OOUI message dialog we use in VE) whether to switch with or without their changes",49779,-10,High,False
-3.5246772795142904,0.29423752814588866,-0.8272030180548899,0.5293338577874638,3.0324740508235686,-5.386250597092111,5.269472865711108,2.178468498708256,-1.9929710021577056,-0.04126107958215908,0.38816442756397285,0.9956359035502922,-0.2994268108493614,-1.2615868611725398,-0.034789681435388076,-0.14804161520395642,1.2143704075369295,1.677377925018862,True,c1,1,"Right now you get | Edit | Edit source | on read and on VE edit (which are the same thing) but nowhere else, which is confusing.
(Whilst we're at it, logs, diff view pages, and probably a few dozen others have edit links which will need to be replaced or augmented.)
--------------------------
**Version**: unspecified
**Severity**: normal",49776,-10,High,True
2.977656129940977,6.607439169644405,0.0030057818486426413,-1.542104940739335,-6.411589370072184,-0.13377492377101263,-1.0499399092776267,-5.875905578936066,-2.849926876692069,-2.259485768213889,4.193588975911663,-1.4934960855825872,-5.276633568792346,-0.6855691743762566,1.5739675018658872,0.10609917963640689,1.490501438758497,-0.12215529176366369,False,c1,1,"In [[en:User:Yamaha5/sandbox]] I tested it for Farsi every thing was OK except <div dir=""rtl""><div> which cause the test disable. in fa.wiki because of mixture of farsi and english or LTR Math formulas we use direction inside the text so it will cause problem for RTL languages
--------------------------
**Version**: unspecified
**Severity**: enhancement",49759,-10,High,False
17.4040679506009,0.4941996822661334,0.9971195582444956,-0.1706681066136394,1.9633174427197284,1.584527861004694,-4.684537238869248,-0.12453281848222236,3.8387063230516887,-0.3131783348053778,1.7566068879354533,1.1132743494999258,-3.092740996606138,-0.22490047987272987,0.8207100347247893,1.3849402563167343,0.2869129929185166,0.7773549959464077,False,c1,1,"Ubuntu/Firefox
Go to http://en.wikipedia.org/wiki/Alfresco_%28software%29
At the end of a line, add a space and remove it
Click ""Save""
No changes should have happen, but there actually are changes, in the infobox:
| caption = Alfresco Share / Repository Browser <br/> (Community Edition)
became
| caption =Alfresco Share / Repository Browser <br></table> (Community Edition)
--------------------------
**Version**: unspecified
**Severity**: major",49712,-10,High,True
8.31249176342906,-1.154363917572411,9.700776678434668,-1.0614220918448194,2.1606535418495394,3.409620741994458,0.7893849880745947,-1.514044214720208,-3.436396013581609,-0.47449553550329693,0.21041421067686628,3.856309949954319,0.6903263265931505,-1.9278821586103048,-0.36458446109037634,0.0016468990150942386,-0.7289593346657204,-1.2476547184282407,False,c1,1,"Edit an article
Press down your keyboard's SHIFT key
While maintaining SHIFT pressed, press the RIGHT key a few times
EXPECTED: Characters are selected
ACTUALLY: Characters are deleted
Ubuntu/Firefox
Looks like https://bugzilla.wikimedia.org/show_bug.cgi?id=41062 which had been fixed in October.
--------------------------
**Version**: unspecified
**Severity**: normal",49711,-10,High,True
11.543203182115935,-6.4705081454106725,4.748024172094009,-2.8794110876605075,-2.6334402200703364,-0.9000042158191475,0.014343235947941402,-0.16890336964945296,0.4978346351803684,0.27522588535909076,3.5461810135679426,0.15190014293250798,3.3814201232964787,2.8018995707900762,1.9537914395816047,-0.8938259175306174,-0.11189672647763937,0.08426622794870187,False,c1,1,"Steps to reproduce:
1. Open http://en.wikipedia.org/wiki/CMIS
2. Press Edit
3. Press your keyboard's Down key
4. Wild pawn ♙ appears
Also reproduced on http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AB%E3%83%BC%E3%83%AB%E3%83%BB%E3%83%89%E3%83%BB%E3%82%BB%E3%83%AB
--------------------------
**Version**: unspecified
**Severity**: major",49710,-10,High,True
-3.005196777825095,-12.790938500295571,-2.3451374925056054,8.492109445198503,-0.8189986689909308,-9.50468155574739,-11.788331226399205,-2.1326124752695788,-5.388682290105576,27.476591798653324,-11.283343072932789,-1.6662426523026264,-4.217820863381603,1.3588926618937407,0.5414968836226857,-2.424032253876877,6.7671752726948,-4.754616921822684,False,c1,1,"From user report:
'externalLink', { '$$': menu$$, 'label': 'External link' }
'newPage', { '$$': menu$$, 'label': 'New page' }
'matchingPages', { '$$': menu$$, 'label': 'Matching page' }
--------------------------
**Version**: unspecified
**Severity**: major",49706,-10,High,True
5.056477436747684,-9.774199036117537,-3.8767196641164787,-6.595333904825363,4.656024802766856,-3.637731488244743,2.2011523371355137,-0.6026774814751934,-2.068782251957001,-1.8775456340045702,0.68140414067105,-1.1629903722549122,-1.5503567585914384,-0.16671062395321812,-2.0113392393004212,-0.8159823784929208,-1.0591971126397817,1.9679270683012724,True,c1,1,"https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Matanya/%D7%90%D7%A8%D7%92%D7%96_%D7%97%D7%95%D7%9C_2&diff=14076208&oldid=14076205
https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Matanya/%D7%90%D7%A8%D7%92%D7%96_%D7%97%D7%95%D7%9C_2&diff=14076218&oldid=14076208
(Others.)
User says they get this when switching he/en and back again.
--------------------------
**Version**: unspecified
**Severity**: normal",49687,-10,High,True
-1.8652635358704779,-5.227685347347087,-3.6986353545822332,1.9248191215517894,3.0586112530128426,6.8398514754441795,1.419026933282959,0.06979389501900146,-0.19893138139097405,3.0199467375513533,-0.9782216615534183,0.09042060489432635,-1.5841163743553697,1.5865119935944456,-0.08871292311572976,0.38646032598410324,-3.093416291537227,0.14577007653509688,True,c1,1,"EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49683,-10,High,True
-0.041983724013540336,-0.591598812271025,-0.6967164868264639,-5.058852368399908,6.882443157358001,-3.389778939119342,-0.8599375409512247,-4.008819279608348,3.234813131266143,-1.651247131924109,-0.5451709017646986,1.8238582183179404,-0.5544327078440974,1.5399656693639354,-2.1014260926682913,2.1747680661299658,-1.0933590523703625,-0.33080630800689836,True,c1,1,"Edit a page in VE, press save; enter VE again.
What should happen: You edit the newly-updated page.
What does happen: You edit the content of the page before you updated it (and VE doesn't know it's doing this).
--------------------------
**Version**: unspecified
**Severity**: minor",49682,-10,High,True
-0.523642482515561,0.966645046338769,2.47404391301059,3.732615943296489,-0.9363122726966704,0.05067585612379233,5.080825935061394,-0.2550936449592818,-2.547785965550104,0.5639223520681798,0.7297860663220321,-1.0010246278941048,-0.5216060353895999,-0.7997853114579812,-0.5254148677865418,-0.14624735453367788,0.3409212717433434,0.8243775903231032,False,c1,1,"The VE becomes active on .js and .css pages in the user namespace, even though it is not capable of handling this content type.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/wiki/User:TheDJ/common.js",49456,-11,High,True
-2.8346912709598793,2.4567377931400216,-1.6648357996486016,-2.122693530653195,0.3603091239295996,-0.08400896514880096,-3.1900508135999575,-2.4355375525239045,-3.4470544603323914,5.244553760841873,-4.150163121255561,1.3141775022788076,-0.8954031514334222,0.6672187270089376,2.682952904040241,1.5115046421051632,0.8161074347198214,-3.8176963871892635,False,c1,1,"If in a page you click 'Edit source', the tab does not receive the 'selected' styling/class as it is supposed to.
This was confirmed with Safari 6 mac.
--------------------------
**Version**: unspecified
**Severity**: trivial",49452,-11,High,True
4.916097542582174,0.3676468593279001,3.2947771190027026,3.557564366421059,-3.657000647444883,1.9688570381822703,-0.588417329772768,0.4316790436224077,-2.508346244142392,1.759138425539863,-0.07857771392185464,-2.7176998467761297,-3.689700638464741,1.2847689029164249,1.1735443323036154,-0.9800638118448597,0.3347342251885912,-1.1772197909068813,False,c1,1,"a </table> tag is sometimes inserted into data-parsoid when set on a table element, for example in the 'Infobox settlement' at http://en.wikipedia.org/wiki/Beale_Township,_Juniata_County,_Pennsylvania.
Original data-parsoid (part of):
Beale Township,<br/>Pennsylvania\n
VE output (editedHtml):
Beale Township,<br></table>Pennsylvania\n
--------------------------
**Version**: unspecified
**Severity**: normal",49430,-11,High,True
-2.0474255182694536,7.904505005967522,1.7079301638992206,-0.876914931242555,-8.06322782086301,3.2528048729424563,0.6095193980049194,0.8355185754364925,-1.0106474558274336,-1.0830687789705853,-1.5633710361251083,-2.2969034402135757,-0.08435005749463897,0.3125383861297344,-3.1663500496192483,0.31677702445936057,0.7044522628686012,0.4459387548892597,True,c1,1,"If you have lines like so:
| A
| B
|
| C
Deleting backwards from up-page of C, or from within the blank line above C, causes the cursor to move (as expected) but no deletion.
Deleting forwards from down-page of B, of from within the blank line below B, causes the cursor to stay (as expected) but no deletion.
--------------------------
**Version**: unspecified
**Severity**: normal",49424,-11,High,True
-0.7940246959411419,1.96478362231462,-5.093822420403777,-2.3390320015523067,-3.247604208831486,4.004358804897336,1.3285632996733305,0.07037334690937397,-0.4754286131489385,-1.9088942826137165,-1.530619015444079,-1.3563427887705937,-2.378390039594204,-0.5906385524693887,1.8874868041867519,3.1491685159017777,0.3042833146190391,0.07563897156414767,False,c1,1,"(a) open a page in VE and edit it
(b) save in VE
(c) reopen the same page right away in VE
The previous version (rather than saved version) is fetched. I looked at POST params in chrome and looks like revision id (oldid) being sent is of the older version rather than the saved version.
--------------------------
**Version**: unspecified
**Severity**: normal",49420,-11,High,True
4.241543626738057,-11.993342186795536,4.282077443976686,-7.321599801627908,-4.2218219390809475,4.5346433300790885,-1.4454786083115234,1.2995028046849404,5.964922811895028,0.8871193976160159,0.8756062918490639,2.6482676176842705,1.2093554111269826,0.3596099449685459,-1.505961709064489,-0.29831969851202034,-0.6845921975904252,-0.9287152607012026,True,c1,1,"See https://en.wikipedia.org/w/index.php?title=User:Fluffernutter/Kinne&diff=551148728&oldid=551148307
To investigate.
--------------------------
**Version**: unspecified
**Severity**: major",49417,-11,High,True
-5.928402098376557,-0.8672794448128389,-0.317016286942863,0.83332938077999,4.011490119448991,6.2239369469291335,-0.6166521663151672,-3.25103442858205,-1.7272551437378711,6.0282789719356025,-1.0129929371737822,-2.1729320528970564,-1.5300471210275823,0.12709853867203247,2.2288801073274254,1.3805810591648295,-3.1069438826587414,-1.0551257064862365,True,c1,1,"Screenshot of the problem
On the ""page"" view, when an outdated translation is opened, the editor shows a disabled ""save translation"" as the main action.
It should show an enabled ""Confirm translation"" button instead (as it is the case for the ""list"" view).
I found the bug on outdated translations at https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-visualeditor&language=ca&filter=&action=page
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10395}",49397,-11,High,False
-1.4868604041009006,-1.4328528471683324,-2.0464785346226275,5.442487157834741,0.6600135055359622,0.5216010297571347,-2.761572321201478,0.2024502728260864,-0.2653230138091507,3.0421955256689417,-2.379882117709558,-0.8981746152572601,0.6440830831375504,-1.8705350913708756,-1.6299576757574532,2.2029228740232396,0.38771312301459027,2.530528276941382,False,c1,1,"Ordinarily there's an accesskey (e.g. alt+shift+E in Firefox) on the ""Edit"" tab in Vector. The accesskey is made known to the user through a tooltip. VisualEditor eliminates this accesskey and tooltip, and adds a new ""Edit source"" tab without an accesskey or tooltip.
Ideally both the ""Edit"" and ""Edit source"" tab should have accesskeys and tooltips to allow quick switching between the modes for power users.
--------------------------
**Version**: unspecified
**Severity**: normal",49396,-11,High,True
-7.857959620342987,1.4111593193716772,-6.8024656487584245,-1.135774012700537,0.7571946954568998,0.026326506086329138,-2.343042762971309,-0.39882295507162574,-0.2342330009530889,-2.522431174819288,1.3335998142048582,1.7937495672332446,1.1520672813510004,-1.3183892119751035,-0.44123975638356594,2.1824828195155157,0.14429212581142337,-0.6258178718122536,False,c1,1,"1. Open http://ve-change-marking.instance-proxy.wmflabs.org/wiki/Test
2. Double-click a word and type a single-char
(you see that the selected word continues to show in the interface after the char you typed)
3. Look at review-and-save.
4. The word has actually been deleted => the interface is not updated as it should
(4) causes the user (=me in this case) to repeatedly try and delete that word and is instead deleting newer words which will all show up in the diff without realizing that they are being deleted.
--------------------------
**Version**: unspecified
**Severity**: major",49391,-11,High,True
-7.759776409335254,8.512735267743103,-0.45289528587479033,0.6212791377971534,3.5984942577891714,9.76824610198818,-0.018699271780842075,-0.49813955407834953,-1.2589336594966394,0.2777150289018788,1.8488873469401716,-3.1490700642573577,0.9537621939278402,-1.2696221785653314,-0.18602109941201306,3.2506868162024993,-2.0675597416016656,0.9593079974522623,False,c1,1,"When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext.
--------------------------
**Version**: unspecified
**Severity**: normal",49373,-11,High,True
-9.944422936399336,4.548096232064513,-2.1177342941190034,-0.6118420335555352,2.8006919944094055,-0.4645191694364935,2.567125762457951,-0.7771917397164245,-1.540620637238841,-1.6369307085695683,-1.085817686831269,1.1718204292372507,-1.6325885222870262,0.7286344251035901,-0.32403244660923214,0.20514557571851105,0.43992769580080493,-0.7338845417986914,False,c1,1,"For performance reasons, we should lazy-update SurfaceFragments rather than updating them through a transact event handler.
The performance problem occurs when you create a bunch of fragments, then throw them away. The fragments are never actually destroyed, if only because the surface still has references to them because of the event binding. The discarded fragments continue to receive events about transactions and update themselves in response, but no one is using them any more.
Instead, I propose the following:
* The surface should have an ordered array of [transaction, direction] pairs that tracks everything that has ever been applied. This is not the same as the undo/redo stacks: this particular array is append-only
* Every SurfaceFragment has a property indicating which transaction (by index in the big array) is the last one that it knows about
* SurfaceFragments do not listen for transact events
* Instead, every time getRange() is called, the fragment asks the surface whether there are new transactions (with indices greater than the stored index), and if so it translates its range for them
** For this to work, all internal uses of this.range need to be changed to this.getRange()
This'll make the fragment lazy-update its range, and we won't spend any time updating fragments that aren't being used.
--------------------------
**Version**: unspecified
**Severity**: normal",49343,-11,High,True
-2.8852863332511474,4.410455254936316,0.9980546999576525,-1.2206301723367647,-1.520246196181317,2.605744880984405,-0.9231077567960444,2.2816701279826903,0.22194597268651117,-2.0757131678027942,-1.206506484393251,0.6057152477873213,1.8964903826496342,2.136637635999306,1.6471393728026937,-0.34501362862907203,-1.1940118327866032,-0.22344851693741874,True,c1,1,"In advance of fixing bug 47328 (which will probably be after the July release), we need to prevent the broken behaviour outlined by C. Scott in bug 47328 comment 1 - so just refuse to load on a page which is a redirect?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47328",49329,-11,High,True
-4.588931923527802,5.715632781977668,-3.6614785378989527,-5.133895525579018,-3.7214447003544042,1.615690023526137,-0.46612100224473707,-3.2034333339541905,-2.0945607248270415,-0.43637828617585406,-2.0248767558175285,-2.4016673712375534,0.035925284601463936,1.252163244791772,-0.15170749240540538,0.478023825437761,-1.0868062697139682,2.0334541414931095,False,c1,1,"In ve.init.mw.Target.prototype.reportProblem, we pass an HTMLDocument to getDataFromDom(), but this function now takes two parameters, with the IVStore coming first, so it fatals with ""doc is undefined"".
In addition to passing in a store, we'll also need to expand the returned data before transmitting it, per bug 47318.
--------------------------
**Version**: unspecified
**Severity**: normal",49319,-11,High,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",49318,-11,High,True
2.036054367636066,-6.317501974710183,-0.09427129181969462,1.4339820516436652,0.21407653704871288,-3.946955854966337,6.668945859877062,-8.727594656647867,-0.6360412349752989,0.7068357946106127,-0.08649329231450453,1.2876433570251347,-2.779694190937554,1.6963893207615763,-0.6177955185309179,-2.059723420458594,2.073041573865316,0.44061721733052006,False,c1,1,"We're cloning html/data-parsoid which Subbu tells me messes with selser correctness
--------------------------
**Version**: unspecified
**Severity**: normal",49297,-11,High,True
-6.618422494182346,-1.5334727134607515,-5.69938363655938,1.1324338423887172,0.6699626841311503,0.3887298768651961,-2.4127456495184725,0.3700155390486467,-0.30301943920770996,-1.3367502637864113,-1.3525588157137307,0.9755273305703083,0.8464933743478871,0.333982183871834,0.5792742232441208,-0.7087311667998355,-0.8908096400498773,-0.21532611576747684,False,c1,1,"To give an example:
mediawiki.page.ready.js runs on mobile (it specifies targets=>mobile) however attempts to lazy load the tablesorter plugin which is not available on mobile (it specifies targets=>desktop)
This currently throws an exception.
Avoiding a bike shedding conversation about whether jquery.tablesorter should be available on mobile, it is wrong to make the assumption that a module will always be available.
Expected: Instead of seeing an exception I would like to allow the user to handle the error themselves - allowing optional modules to die silently.
e.g.
mw.loader.using( 'jquery.tablesorter', function () {
$sortableTables.tablesorter();
}, function( e ) {
throw e;
});
or
mw.loader.using( 'jquery.tablesorter' ).done( function () {
$sortableTables.tablesorter();
});
Another example of this being a problem is on the edit page which asumes mediawiki.action.edit is available:
mw.loader.using(""mediawiki.action.edit""
Currently there is a hack in MobileFrontend to get around this [1]
[1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend.git;a=blob;f=includes/skins/SkinMobile.php;h=27ab4ef44fc138566bbf3e1ab32cd5af20daf246;hb=HEAD#l241
--------------------------
**Version**: 1.22.0
**Severity**: normal",49296,-11,High,False
-3.423883978088675,-4.68501365930512,-9.578248501062276,-2.247346215684092,-0.5949457546263922,-3.6781051758049523,0.10786119143502759,0.8252259233789071,2.387860762217402,-1.3911222285304996,-0.7108852342384959,1.532196306973877,1.5712820148068132,-0.3391034754660218,-1.6178523171417756,0.11825190527294219,0.48876077144721464,0.4595905714297126,False,c1,1,"Our current setup for custom hashing objects to to give them a method .getHash() which looks like this:
T.prototype.getHash = function () {
var someSubsetOfT = // code here
return ve.getHash( someSubsetOfT );
}
and to invoke we use
ve.getHash( instanceOfT );
However ve.getHash( instanceOfT ) === ve.getHash( ve.getHash( someSubsetOfT ) )
which isn't really what we want.
One solution would be to rename getHash to getHashableObject (or something) and have it return just someSubsetOfT directly.
--------------------------
**Version**: unspecified
**Severity**: normal",48895,-13,High,True
-7.443383704036778,-0.7529871049604022,-8.716728761330508,0.1951232996573109,-3.592113525143582,0.7395333185078392,-6.289274719719875,1.1231715273223721,-2.04791604633356,-3.9051362345218408,5.899332329388514,-1.9906581764682838,-3.785277986268171,-0.18748915569693736,-1.085018626346213,0.4132484474550911,-0.4809493686050115,1.4682652179331688,False,c1,1,"e.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in
<p>a</p><p>c</p><p></p><p>d</p><p>b</p>
This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.
--------------------------
**Version**: unspecified
**Severity**: normal",48800,-13,High,True
2.6418308777194413,-3.260680722411916,-5.892961340172956,0.7343405846024706,0.39098799286590724,-0.4394001723791974,-12.629310230645567,3.450641787368378,-7.446443477888286,-0.8774008921391308,9.113613091814635,-0.20593078096958783,-11.304552617069678,1.0701306184962815,2.1532110901527384,0.15914776422231214,1.0517421526551096,-0.13422826120666764,False,c1,1,"e.g. inserting a <p>Bar</p> into <p>Foo</p> after the last 'o' results in:
<p>Foo</p><p>Bar</p><p></p>
The original paragraph is split, then the Bar is inserted, then the paragraph is reopened again.
Or in transaction terms:
insert: '<p>Bar</p>'
coverts to
insert: </p><p>Bar</p><p>'
--------------------------
**Version**: unspecified
**Severity**: normal",48799,-13,High,True
-6.259537914295439,-1.3219456629172495,-2.2973938028819525,-3.4780127678610064,-5.585279157480684,7.366722096647082,1.0810156212275261,1.3984486836813144,-0.06177415228300176,-2.135325872185631,-3.2448895334164085,0.7081457610496811,-1.9890531123577846,-0.30149194332983775,0.35995289803072783,-1.5658113042680628,1.3031530673310516,4.967622886697207,False,c1,1,"This is in preparation for performing transactions on templates and having to update the html asynchronously.
--------------------------
**Version**: unspecified
**Severity**: normal",48571,-14,High,True
0.17972963589626723,-3.4804076574081027,1.6260197619429348,0.6282442536305208,-1.0915424477456968,5.904082729767405,5.088856043971959,-0.7766519844195805,-4.457219403320012,1.3249750436090144,1.136572949195409,3.3024255009965957,-0.6472662818796877,1.0751114909553046,-1.0088336881997346,-2.1218354853789396,-2.105221341983718,-1.0472042657281861,False,c1,1,"If Parsoid has a meta thing for defaultsort that is
--------------------------
**Version**: unspecified
**Severity**: normal",48465,-15,High,True
8.58739382773293,-0.7704819804275616,-6.412035713263071,-9.44784336256835,0.034771936491282185,-4.704115094041489,-3.526210815937144,-4.7514786079875995,-3.5692452058472366,7.0156712605547895,-3.383440090506648,0.2216008654483952,-0.25191005925993526,-0.680910645773178,-0.6396332781959728,-1.0163059014914269,-2.9035405730296526,2.7705121914055324,False,c1,1,"I am just trying at w:en:Vojníkov hyperlink from ""Louka"" to ""Louka (village)"". The actual link is incorrect. Using VisualEditor and FF 19.0 or G Chrome 25.0.1364.152 m. If I start to type ""Louka"" it adds ""Loukas Vyntra"" automaticaly. If I use backspace it allows me to delete ""Vyntra"" and when I delete ""s"" of ""Loukas"", it adds again ""Loukas Vyntra"".
--------------------------
**Version**: unspecified
**Severity**: normal",47807,-17,High,True
-4.464512297849762,-1.1333568054760814,-6.344751698866498,-7.7503163595176225,1.8138675522322623,-2.9928944165021676,4.803509430139251,1.6692574796962791,-1.6430379297134976,0.6135979536913787,2.471611031098186,-1.3444592311321613,1.2310890483414,-2.9844385935097737,1.3150462562821756,0.20031527938517857,-0.02425629296756604,2.630417334708304,False,c1,1,"VisualEditor should be deployed to the Hebrew Wikipedia as soon as possible. I did some basic testing on my machine, and I see that it's more or less as functional as it is on the English - basic formatting works, and even basic RTL is correct.
Obviously, there are many RTL issues to test there. I am doing such testing myself every now and then, but letting more people test will be far more beneficial.
Of course, I am talking about a dark launch at this point - it should only be available to users who specifically request it.
--------------------------
**Version**: unspecified
**Severity**: enhancement",47749,-17,High,True
9.907416417360173,3.202483929244533,-1.0264499324165008,4.151207397819247,-4.072208401717302,-1.1629654597421089,-1.0382507090882385,-1.0473823476581496,-2.3177615305410235,-1.654025796358955,-1.5430908155370322,-1.0583819738514364,2.9273522684605267,0.8801884968650766,0.8380815870422547,1.3513218386259465,1.3071872087516174,0.5177437742776092,False,c1,1,"**Author:** `afeldman`
**Description:**
The FORCE INDEX provided in this query results in a /much/ slower query plan than without. This is the case with both MySQL 5.1-facebook, and MariaDB 5.5, so it should just be removed.
Query:
SELECT /* IndexPager::buildQueryInfo (contributions page unfiltered) user */ rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,user_name,page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,ts_tags FROM `revision` FORCE INDEX (user_timestamp) INNER JOIN `page` ON ((page_id = rev_page)) LEFT JOIN `user` ON ((rev_user != 0) AND (user_id = rev_user)) LEFT JOIN `user_groups` ON ((ug_user = rev_user) AND ug_group = 'bot') LEFT JOIN `tag_summary` ON ((ts_rev_id=rev_id)) WHERE (rev_user >18370655) AND (ug_group IS NULL) AND ((rev_deleted & 4) = 0) AND (rev_timestamp<'20130301192103') ORDER BY rev_timestamp DESC LIMIT 51;
Times of the query as above:
production enwiki master - mysql 5.1-facebook: 51 rows in set (7 min 23.03 sec)
mariadb 5.5.29: 51 rows in set (1.29 sec)
Times with the FORCE INDEX (user_timestamp) removed
production enwiki master - mysql 5.1-facebook: 51 rows in set (0.26 sec)
mariadb 5.5.29: 51 rows in set (0.20 sec)
The EXPLAIN without the FORCE INDEX looks worse on 5.1 without than with, based on number of rows examined, but it avoids a filesort. It looks better without the FORCE INDEX on mariadb than mysql 5.1 with or without. In both cases, rev_timestamp is used instead of user_timestamp.
--------------------------
**Version**: 1.21.x
**Severity**: normal",47619,-18,High,False
-2.506836677757099,-1.0859125992175258,-4.101027459830414,0.3750363355387971,2.418176408449273,-0.7037300804770283,-3.450333930277314,0.9610293186000348,-2.2474843756694485,6.116331745295122,-1.3768257584439318,-1.2407028896065335,1.68668184531833,1.0528774709900652,-1.2836916206271827,-0.27176877772656016,0.7251041676154417,-0.38444652435151183,False,c1,1,"When we unwrap lists, we currently preserve the internal 'generated' property on paragraphs inside those lists, but we really shouldn't. The fact that we don't currently clear this when unwrapping results in the following serious bug:
1. Create a page with the following content
Foo
Bar
* Baz
* Quux
* Whee
Yay
2. Open the page in VE
3. Select across the three list items and click the list button to unlist them
4. VE now shows five paragraphs
5. Click ""Review and save"" and observe the diff.
Expected diff: the asterisk and space before ""Baz"", ""Quux"" and ""Whee"" are removed.
Actual diff: the second line becomes ""BarBazQuuxWhee"", followed by three blank lines, then ""Yay"".
This happens because the converter unwraps paragraphs with the 'internal': { 'generated': 'wrapper' } property, even if these paragraphs now appear in a different context and even if there are multiple such paragraphs adjacent to each other.
--------------------------
**Version**: unspecified
**Severity**: normal",47590,-18,High,True
-3.8719546989044007,3.496509459377865,-0.2920040733255931,0.4606385158466486,-2.506995131585433,2.724682576263729,-5.254447191847191,-1.6404110551072804,0.5094269094480409,4.352331628443647,2.42071076550307,-1.704058543800595,-0.3022251097624702,-0.12575410958973876,-0.22793466148816144,-0.5111777091954081,0.10791546197940427,0.040032395474234095,True,c1,1,"1. Create a document ""First line.Second line""
2. Select this text and insert a newline between the '.' and the 'S' (currently, using the Enter key).
Expected result: a single <pre> block with a single newline after the full stop, converting to "" First line.\n Second line"" in wikitext. Note that this is trivially-obvious on MW Vector due to the ""border: 1px dashed #2f6fab;"".
Actual result: two separated <pre> blocks (with a slug between them), converting to "" First line.\n\n Second line"" in wikitext.
I presume that we'll want to retain Enter as a break-me-out-of-this-context newline, and use Shift-Enter to allow insertion of the above.
--------------------------
**Version**: unspecified
**Severity**: normal",47344,-18,High,True
9.238748507405024,-9.943938328294898,-6.904505775485642,-0.914439484553791,-4.046220790326311,3.0450703261905048,-2.1420409974672285,-1.1968931584529523,-0.3365423785148309,-3.79645201688507,-0.09539249543565242,-1.2072265200699794,-5.0079197351152525,0.38813964716320193,-0.15696384276101316,-0.770281667784461,0.44909665558217093,-0.11405607185820643,False,c1,1,"Stuff like ve.dm.MWInternalLinkAnnotation , ve.dm.modelRegistry.registerExtensionSpecificType( /^mw:/ ), etc.
--------------------------
**Version**: unspecified
**Severity**: enhancement",47295,-19,High,True
3.9859820508798847,0.5776402582782989,4.209340913051388,-0.8280980853110258,-5.727970935427317,0.9838442708674038,1.2710635576326963,2.304785063115263,1.3210984834468658,-0.977746662169698,-1.5216107554607088,-2.899075373054704,-0.6322704369394927,-0.9270237905821213,-0.6250115801344149,-1.7527158377173713,-2.5550609256565195,0.25550293829856696,True,c1,1,"Changes made in screen
Issues of editing when making changes in a section of https://en.wikipedia.org/wiki/William_Francis_Magie - probably Parsoid selser issue. JDF to re-check when new Parsoid deployed.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10305}",47245,-19,High,True
-10.191333925797974,3.2797128359128394,-0.7820329558862493,0.8100985843278079,-4.193533565925065,5.32375284901223,3.6734981286749298,-3.149392343536307,0.8626454668087387,1.5140948548969204,2.352766400560929,-4.157891728438143,0.008623353666109779,-0.1603140856588201,-0.17264679958445228,-1.5350287354679932,0.13949931666386095,0.5090327780496462,False,c1,1,"The method should isolate a selection of siblings from the siblings either side of it by creating close/open tags with either side of it where necessary.
--------------------------
**Version**: unspecified
**Severity**: normal",47243,-19,High,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",47061,-20,High,True
-5.62705998169721,2.809227658530176,-2.998151305898391,-3.7817507200538625,-9.596683415287815,4.25919846737198,0.3004108358486093,-0.8672673638840783,8.142278684172224,2.560756659582049,1.1129565834748392,3.2113636987589054,-0.33797382658653063,0.46638423915603777,3.450034855210757,-0.5035216455887722,0.3741659467588663,-0.8906966452396063,False,c1,1,"In order to implement a category editor, we'll need to be able to process transactions on metadata.
--------------------------
**Version**: unspecified
**Severity**: normal",47029,-20,High,True
-6.240222457778906,-1.3985645584826862,-4.074875649754068,-1.1832678553013856,3.1418911338690845,1.8090051192550491,-3.5361737664006636,-0.6955002213944997,0.4218389323121523,-0.8293673929154735,0.45061790596492957,-1.2107318373448475,1.8575367883929572,2.6402827124740753,0.14110324890577264,3.2271455906470456,-1.2121023489435676,0.7273007155968318,False,c1,1,"1. Load a new (i.e. not currently existing) page into VE
2. Type some text
3. Click ""Review and save"". The corresponding wikitext appears in a flyout
4. Close the flyout using the up arrow
5. Change the text in the editor
6. Click ""Review and save"" again.
The flyout that appears in #6 will display the same wikitext as in #3, even though you changed the document. The diff flyout handles this correctly (i.e. it caches the old diff until you change something), but the serialization flyout for new page creation never clears its cache.
--------------------------
**Version**: unspecified
**Severity**: normal",47021,-20,High,True
-3.087373220054738,-0.3717644692225175,-1.4806484171723842,2.337955000840996,0.4355998444958842,0.5926594673711671,-0.34421017509189333,0.4636977859240832,-2.624688560923839,1.4153765948954575,-1.3942796162360864,-0.9861903201391757,0.7757707549674584,-2.336273724681941,-0.643263487257097,0.12945366072644976,1.545996214850894,-1.1685408666389319,False,c1,1,"**Author:** `phil`
**Description:**
shows the result after a save with 'friend' being duplicated
Text was several lines long
Placed cursor at start of last line
Pressed delete to move the line up to the same line as the second to last
Saved
The last line has not been deleted and it also present on the second to last
Screenshot attached
This
is
the
end
my
friend
- put cursor at start of friend and pressed delete and then added a space
Screenshot shows the result, 'friend' is now in twice
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10875}",46702,-21,High,True
-2.7701709669434047,-5.331021323738328,-5.537066559194026,3.528585449645469,6.436572365955808,1.776279114248062,-7.7717144552122726,-2.6438708534082,-1.5802537886178922,6.206601613774422,-4.8496644595130585,-2.8345974268002925,-0.33746868338515945,-3.236530543557941,0.8571667031141539,-0.33208329551501203,3.6514551872088035,-1.9492083629556562,False,c1,1,"**Author:** `phil`
**Description:**
Page after cut and paste of 'a b c' only showing the 'a'
Created a simple file
a
b
c
Copied all the text, placed the cursor after the 'c' and pasted it
The 'a' from the copy was pasted, the 'b' and 'c' were lost
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10869}",46701,-21,High,True
2.7043543605348144,-8.589797776093063,-1.5989913284965063,1.5797078750526468,-0.7059764030191111,-1.5269428814902142,-1.8482535441728203,0.9185874187122242,1.5618657222914405,-0.9839404990167351,-1.1162711743104312,-0.4351450596141664,2.2522607456565353,-1.9278849796712003,-2.79103739269197,0.2830027857062335,-1.667232434665842,-1.0553912159599088,False,c1,1,"Screenshot
When edited in VisualEditor, the following table:
```
{| class=""wikitable""
|-
! Header
|-
| {{Yes}}
|}
```
... shows the following string in place of the {{Yes}} template:
style=""background: #90ff90; color: black; vertical-align: middle; text-align: center; "" class=""table-yes""|Yes
See screenshot.
Live at http://en.wikipedia.org/wiki/User:Nicolas1981/Sandbox
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50589
**Attached**: {F10493}",46498,-22,High,True
-5.601363276419995,-2.243234929992992,-3.6601171765666702,2.2784425947491282,5.453918762842914,1.7742252833475451,-2.2482408928592457,-0.003080757001115819,-0.7482469047851754,0.9405904128400184,-1.0665412422743223,2.8405050153626403,1.5391465211716135,-1.322094985294223,-0.8841428065274206,0.42800081833764414,0.4170316785930277,-0.02393118412646844,False,c1,1,"diff about to delete existing text
I've seen this a few times and I think this is the simplest reproduction.
Start with a page that has a line of text ""this text should be preserved but is not""
In VE, position the cursor at the front of the line and move it two spaces down.
Move the cursor back to the top of the page.
Type a new line ""totally different stuff""
Save. Note the incorrect diff. The string ""this text should be preserved but is not"" has been deleted erroneously upon save.
Repeat the operation but this time use strings that share words, like ""this text should be preserved"" and ""this text is new""
The behavior is the same, the old text is erroneously deleted, but the diff seems to have intertwined the two strings, keeping their common elements.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=User:Cmcmahon(WMF)&oldid=535559576
**Attached**: {F10454}",46479,-22,High,True
-1.453810189478423,-1.7993306613263211,5.718056149602663,6.765866299561832,6.137946345451221,2.22096043527762,-2.4055924059012934,0.005034926997413758,4.146203429573737,2.220809118048228,-1.187775189739502,0.2733455130037856,-0.24781453237725337,0.7924066553884064,-1.5694827704078564,1.2144958076577315,0.6241057126351628,-0.5477362037555971,True,c1,1,"Go to a new page. Enter some content. Press review-and-save. Observe diff. Press the ""leave this context"" button (""^""). Change the content. Press review-and-save again. Observe diff.
Expectation: The diff shows the changes against the new content.
Reality: The diff shows the changes against the original content (not re-done).
--------------------------
**Version**: unspecified
**Severity**: minor",46446,-22,High,True
-5.228304073745576,9.496518114767778,-1.4355939382343799,-2.3767739922611923,0.540886835015957,5.282411045504939,-2.86520980036479,-0.5850137815255572,3.7144638122780576,-0.23853973416698437,-2.42609900556842,1.9004842417068895,-1.2961044679844695,-0.08490094508869284,1.7500040219127726,-1.9544971331675618,-0.24359851688015266,0.008732845687585922,True,c1,1,"For the forthcoming Template Inspector to work, we will need a way to ""hint"" for the Inspector how the parameters of the VE should be used - we're intending for now for this to be a template-hinting extension that allows editors to specify in the wikitext source what the parameters are called and how they should be used, akin to the Template documentation template on Commons.
--------------------------
**Version**: unspecified
**Severity**: enhancement",46444,-22,High,True
2.2541365747122177,-2.6524874928893816,0.46122153852200753,0.6964153499919223,0.4092128735879019,0.8392865253070372,0.20785947450253772,2.393384126972441,-1.2183915329524257,6.229794367494247,1.895454047544035,1.087147517940654,2.400811527698382,-0.9820454158471263,-1.7145896605358746,0.40725380183546084,-1.3069848324992068,0.33292731260928954,False,c1,1,"empty review pane, should show heading markup for non-Latin string
Using a string like ""āæǣ"" or special characters like ""☺☻♥♦""
Highlight the string in VE
Choose ""Heading 1""
VE displays the string larger, as expected
Click ""Review and save""""
Note that review pane is empty, see screen shot.
Click ""Looks good to me"" and finish saving.
The non-Latin string has not been affected and the Heading not been applied.
Note that normal ASCII latin strings work fine.
Also note that the regular editor applies the Heading markup to non-latin strings correctly.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=User:Cmcmahon(WMF)&oldid=535414434
**Attached**: {F10377}",46442,-22,High,True
-5.683070532507273,5.648148616826742,-2.2702154724423274,-4.181635006810587,3.9009793918846474,-1.861646241264125,0.8997836579590999,-0.24510727621145142,1.096556502623617,0.5786351488507568,1.957507898353906,0.7373061248368353,1.4340740401003846,1.011541880512997,0.787258907311732,0.7226698897573314,0.9091741340449879,-0.862418559619373,False,c1,1,"VE gets some error codes and messages from Parsoid, but not a lot. I'm expanding that a little bit in a new patch [0], and it would be cool if VE could handle the errors I've added.
401: Unauthorized: Should be handled as a user-visible error. Usually this means that the API isn't readable by anonymous users, but could be later used for something else. The text of the HTTP response has details about the error, so showing that to the user might be an OK solution.
404: Not found: Usually means that we couldn't find anything for the article you're trying to parse or serialize. This shouldn't usually happen, but when it does, it *probably* means that the interwiki isn't set properly. Maybe hint that the user should compare their localsettings.js file to the example.
500: Server error: This is a catch-all, but we'll send as much information as we can in the text of the HTTP response. Showing the user the text would go a long way towards more useful bug reports (I currently see roughly 4 suggested duplicates that have roughly the same summary....differentiating them might be helpful)
These are all implemented in js/lib/mediawiki.ApiRequest.js in functions that inherit from the native Error object, so you can read it if you don't want to take my word for it.
We could implement other error codes as we see cases that require them, but these are the big three. And of course 200 is the main success code.
We might also be able to use some of the 3xx codes to represent redirects, but I'm not sure it would be totally useful. File a bug against Parsoid if it would be :)
[0] https://gerrit.wikimedia.org/r/45794
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43147",46354,-23,High,True
-1.5689857051575178,-5.787661811279488,4.832929841372639,0.31470788597411525,-4.121695942867982,4.206972694520305,0.2941387177056667,-0.1018461451493819,2.1454273662705434,-0.17109131480037298,-0.17127649330515915,-0.04838525062804866,0.36000134266767336,-0.7039386944131456,-1.2239838812691017,1.8339447170500265,1.1400765118866214,-2.5995116349389953,False,c1,1,"See http://inimino.org/~inimino/blog/javascript_cset for some work in this area.
--------------------------
**Version**: unspecified
**Severity**: major",46085,-24,High,True
-1.542414948664151,-1.9435007769039352,-5.29034429190188,-1.9159362405191298,-0.9615125932716934,1.6898968719877876,0.2266397428400948,2.7805353938919524,0.49801482930868135,-1.2412584664031292,-0.9481821309913108,-1.7616234331729408,1.0213086005920098,-0.5952560911810894,-0.5467307005422892,-0.7427555368684708,-1.5199400360606157,0.32840162011711693,False,c1,1,"Related to bug 44083
Because there is not yet a paragraph to insert content in, the link inspector won't be able to insert the new link text into a slug, even if bug 44083 is fixed.
The solution is probably to make the automatic paragraph insertion code in ve.ce.Surface.handleInsert more generic and moving it into ve.dm.SurfaceFragment.insertContent, triggered when inserting at a slug location.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44083",46084,-24,High,True
-5.637225436814115,0.21384981983065643,-1.1395656519718536,1.7681190394457849,1.884519079574908,2.8492412879617124,-3.8248114051548923,-1.7663107580476693,2.551733928841643,-2.3519687080320657,-0.048421326723768754,-1.7036608965671882,2.4985169037578436,0.1456584774061218,-1.5647913219121277,0.5305019204238062,-1.450954077123392,-1.1991590031485435,False,c1,1,"1. Make an article that begins with an alien followed by a paragraph with some text
2. Click on a word in the paragraph
3. Click on the slug
4. Press the link button
5. See that rather than the link inspector knowing to begin inserting a new link inside the slug, it inspects the word you clicked on in the paragraph.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44084
https://bugzilla.wikimedia.org/show_bug.cgi?id=50141",46083,-24,High,False
17.149272184779445,-6.3978632704719365,-3.831621414754025,-2.4241855782320636,-0.38474390862719693,-0.09855909951262387,-3.5673367574921695,1.1673077236637464,1.4924438209073507,-2.2280644552683158,0.525625316762997,0.6947331627924165,0.15120009704488435,-2.9494405248752735,-1.8065815024782457,1.6837632453215787,0.9554668831750381,1.6506353181079103,True,c1,1,"Key commands should be able to vary based on language/locale and platform. E.g. toggling something as Bold could be:
* Ctrl + b (Windows, English)
* Cmd + b (Mac OS X, English)
* Meta + b (Solaris, English)
* Ctrl + f (Windows, German)
* Cmd + f (Mac OS X, German)
* Meta + f (Solaris, German)
... etc.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42919",46012,-24,High,True
-9.126238358837032,-1.4423047061276044,-5.875997185363808,-1.0963201911300338,4.410290868586555,-2.1321674178227568,1.6158122146695462,2.8538035291575268,-1.6652646259467172,2.702511436303931,-0.06488340821766281,7.913005474708874,0.7030341551631394,-2.0358481554598287,1.9972289499725697,0.630871664413482,-2.3927025712609202,0.5027350950717129,False,c1,1,"""Can have grandchildren"" is a misnamed check that should be cleaned up. What it really appears to mean is ""is this a non-content-containing branch node"", given that it checks that the node can have children, is not content, and is not a content container.
canHaveGrandchildren seems to still be used in some places, it should be renamed and documented adequately.
--------------------------
**Version**: unspecified
**Severity**: normal",45893,-25,High,True
-2.5588002989320406,-1.2854143563767817,-0.8315357675280026,-3.202664951848344,-2.8979291689971367,-0.7904224274734117,2.9531615628570416,-3.036407046974281,3.0085318193490505,0.9695265417777685,1.9141612895658375,-0.3142290316671619,0.26981751310956525,0.25595886325912165,-1.4121187982465493,-3.2147218194089917,-1.6718460745070116,1.9620876052705591,False,c1,1,"We should use pushState such that pressing the back button after clicking VisualEditor takes you back to read mode.
--------------------------
**Version**: unspecified
**Severity**: minor",45844,-25,High,False
-8.897735893201542,0.42817445192788917,-0.7478362075928064,1.1167358679867538,3.721330527352382,0.05579566439312611,3.9520305058948226,3.3961517567888855,-4.192881980605924,4.450660255366737,0.5463554391845751,1.2113660283412184,-0.6218127785507077,0.3781455872656956,0.2009043419057388,0.2979836279885303,-0.4182291080906302,-1.8157961042438122,True,c1,1,"When the diff result is null (no changes), don't show a confusing blank diff but instead a message like ""There are no changes detected in your edit"" so that users aren't confused.
--------------------------
**Version**: unspecified
**Severity**: trivial",45754,-25,High,True
-5.909887886564068,5.591150048944332,1.3845395218923642,1.180916908773865,-0.2747799125288624,4.2236259178061974,-0.7784483612479676,2.4828156257182656,2.67950646915899,0.42227893427386576,-0.4047521806947896,-2.609941399686216,0.016996098162167073,-2.1822524019537455,2.227991064961965,4.634235718152304,3.406015591100335,-3.0280023354300547,False,c1,1,"For whatever reason (may be a bug in the DM, or in the seralizer, or in selser), whitespace preservation didn't work in this edit https://en.wikipedia.org/w/index.php?title=International_Air_Transport_Association_airport_code&diff=530666305&oldid=526301045 . The whitespace changes didn't show in the initial diff I was asked to verify, only in the final change.
--------------------------
**Version**: unspecified
**Severity**: normal",45543,-26,High,True
-1.0285189324273984,6.566989795843774,3.3263698005058657,4.147222696796491,-1.6404103359562316,-0.5312338329798293,-1.1050757839102694,1.7371250261761015,3.408638443256633,-0.6291651578109878,-2.1893315413339494,-1.6324085205589596,-0.7585435775993226,-0.21663329224800965,-0.16488155894755963,-0.30276936416325007,-1.0192561962208206,-1.97073922919274,False,c1,1,"Steps to reproduce issue:
* Load VisualEditor on a page where the server will return in error
(to simulate, call mw.loader.load('ext.visualEditor.viewPageTarget') from the console on a page where VE is not enabled, e.g. the Manual namespace on mw.org)
* Click Cancel on the server error alert()
* Witness said error on your console.
--------------------------
**Version**: unspecified
**Severity**: normal",45216,-28,High,True
-1.0121500333830915,3.9037612724915647,-0.5533062075667683,-1.2624142497463697,0.2971569602733959,-0.6344192963801193,0.6955714644828319,-2.4190577309122996,0.9000378775422797,-0.5761701716478553,1.8169059604886262,1.6931139174524417,-0.8609787255255528,-0.8135359102818738,0.2621647538201808,-0.14457724735678446,0.20159068282962944,0.06268460022350975,False,c1,1,"**Author:** `swalling`
**Description:**
On English Wikipedia, we should add a tag (https://www.mediawiki.org/wiki/Manual:Tags) to edits made to articles chosen from Special:GettingStarted by new editors.
We are logging actions anonymously with EventLogging, but providing a public tag of edits made through this interface has additional advantages:
* It will allow product managers and analysts the ability to see a real time stream of the edits
* It will help community members inspect the overall stream of edits, and assess them for quality
* It will explain to anyone who is watching a page how new editors found the article, and why they are editing it
* It will allow us to find and contact the new editors who use Special:GettingStarted (right now vandals are being warned, but good editors are being ignored for the most part)
If we're adding a tag, we should assume that most community members won't know what Special:GettingStarted is. With that in mind, I propose the following for the tag text: [[Special:Tags|Tag]]: new editor [[Wikipedia:GettingStarted|getting started]]
This is also appropriately agnostic to the task type (copyediting, wikifying, etc.), which is likely to change as the project evolves. You can see other tags in use on English Wikipedia at Special:Tags.
--------------------------
**Version**: unspecified
**Severity**: enhancement",45191,-28,High,True
0.5707028590289456,-8.454154140837897,7.1497452549991145,4.173067403080389,0.9570868791489953,-5.082768883902809,3.533264858378687,1.4785735950198169,-3.9837849582453355,-0.3062575680267994,2.0337232617536087,4.855924061238884,0.3746051079778643,-2.445760843975589,1.3746178313010642,2.098186281875961,0.08444734626134665,0.015013867961169547,False,c1,1,"Inline image (used as icon) is incorrectly alienated, sometimes (?).
Test case:
Open https://en.wikipedia.org/wiki/User:Raymond/inline_image in VisualEditor mode:
1. Thumbed image and inline image are alienated
2. Dismiss the notice bubble
3. Thumbed image is alienated, but inline image is NOT. It is clickable.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/User:Raymond/inline_image",45174,-29,High,True
-2.6409326962844695,-0.6154782927869213,-5.970349083631554,-3.57030487150585,1.6437717171972923,1.6480882902715874,-0.5016520107543947,3.0669475634279504,-0.19501882663761522,1.8793740192403634,0.9250259694639529,-3.265295082886997,2.260293449488492,-1.4543982285575625,-0.10141380833947533,-0.20965357554328434,-0.15937888278927903,-1.0161753869210464,True,c1,1,"* Click into VE on https://en.wikipedia.org/wiki/User:Thehelpfulone/test
* Click cursor into one of the many LI slugs of the multiply-indented list.
* Type some contents into the slug
* Press ""left""; suddenly, the cursor is back at 0,0
* Click into the ultimate LI with ""real"" content (not the one just created) and outdent repeatedly; you will over-write the new LI as if it wasn't there (indeed, it never reaches the DM).
This may be similar to other slug bugs, given the core issue. :-)
--------------------------
**Version**: unspecified
**Severity**: normal",45146,-29,High,True
-5.306485375400829,-1.836384055994822,-3.498809331297231,0.6879289143444838,3.8009104586331213,-0.052756789772320234,-4.134780151301108,1.5683432404217488,-2.245634304201717,1.950559557896013,-3.1344166428387408,-0.3300170170664306,0.0832926375386922,-2.149152596570273,-0.8702149743837317,0.5320224535212004,0.38185718260995816,-0.5808055679470248,False,c1,1,"Screenshot showing the diff and the editor
Steps to reproduce problem:
* Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport
* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)
* Type ""a""
Expected result:
The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before.
Actual result:
The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F9591}",45103,-29,High,True
1.3625999818189078,-5.338673949599327,-0.8527088742772868,1.7207511997388676,2.7853617573762257,3.9360073649387948,-3.415320089720148,-0.20172425815479983,0.9823306699180896,2.3840425733430024,-0.3220797311982815,-0.49273139944595257,1.8349155189457864,-1.984984206950669,-1.5721465925754559,1.0876855814533504,-1.9868514399656525,-0.0808178135471116,False,c1,1,"Screenshot
Steps to reproduce problem:
* Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport
* Put cursor in the placeholder slug in the second list item of the External links. There is an alien node here as the external link is generated with a template.
* Type ""a""
* Press ""Review and save""
Expected result:
A diff adding the letter ""a"".
Actual result:
Empty diff (see attachment)
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F9589}",45102,-29,High,True
5.2308861792723,-2.558754454632897,-3.9058438336786967,3.0963575904093465,5.961070698616714,6.938241743643274,-0.8134418301764708,-1.3034786594270926,-3.2858550812368863,3.4393590463672385,-0.06748493243212295,1.1910640428167938,1.8884783446923752,0.6596640293736291,1.1696344452195309,-0.3884617493809265,-0.6677122775308519,3.9401503470531196,False,c1,1,"Firefox 17.0.1 and Ubuntu 12.10; using the VE causes a failure with a ""localStorage is null"" error.
--------------------------
**Version**: unspecified
**Severity**: normal",45087,-29,High,True
-2.5909359979824584,4.884389956816168,2.2396144152754225,2.4466217890058486,3.1899677475537387,2.5673863214059587,-3.4298494489024867,-0.2615103752541605,-0.8708569125415385,-2.4193882690159425,2.3625753025234686,1.4172934764486287,-1.0543330014313312,-0.36025806702089014,0.43595307572427444,0.6694972706848946,0.8881186218482144,-1.0906075413340952,False,c1,1,"Here is normal behavior:
1. In VisualEditor, type a line of text.
2. Position your cursor at the beginning of that line.
3. Press the Home key on your keyboard, to move the cursor to the beginning of the line.
4. Wait a moment.
5. Press Enter, and the current text is pushed downward one line. This is correct and expected.
Here is the buggy behavior:
1. In VisualEditor, type a line of text.
2. Position your cursor at the beginning of that line.
3. VERY QUICKLY, press the Home key followed by the Enter key.
4. The cursor moves down one line, so it is positioned below the line of text. The text did not move. This is incorrect behavior. The line of text should have been pushed downward.
--------------------------
**Version**: unspecified
**Severity**: normal",45082,-29,High,True
2.3383068404271996,-0.44240362140891776,5.34928438516371,-1.3181779629820571,5.081824587355765,0.7128270619766008,-4.171386184177278,0.14015649615802278,-0.8843317339022281,-0.803152837677886,1.726525388621099,2.6294419226110266,-0.9485428136938872,0.4448428310619654,-0.7379181890849686,2.6764789845346444,-1.0041796569222865,-0.37104761404922426,False,c1,1,"1. Using VisualEditor, edit an article that already has some text in it.
2. Select all text with Ctrl-A.
3. Press the DELETE key. All text disappears as expected.
4. Click ""Review and Save"". The diff shows that text is STILL PRESENT in the article.
5. Finish saving. You will see that text is still in the article.
--------------------------
**Version**: unspecified
**Severity**: major",45081,-29,High,True
-1.0786015201695478,-8.190918867189103,-1.468301319860375,1.868500013448097,8.136678407206656,1.5291861796569142,6.581958487260965,5.742043369395657,-3.554909798539634,0.9332951547783699,1.205984245167389,1.519069894765621,-0.6466209066771018,-1.3628558841757363,1.4707354372047368,1.566029878816882,3.2640280854542842,2.0702377797964227,False,c1,1,"The coord template is not hatched but still visible and the links are still clickable.
https://en.wikipedia.org/wiki/User:Raymond/coords
--------------------------
**Version**: unspecified
**Severity**: major",45076,-29,High,True
11.473568970194147,-3.9290012492049993,3.7771960184222664,-1.7217414553863448,2.077864042728035,2.9983167681901124,-1.4391032280472427,3.663083817384224,0.650262950901375,10.532698578430567,2.3200812018752326,-3.0262887881038933,-1.5631120387194564,1.396055441564429,0.46969779452360516,-0.7735607706611249,2.557892051764801,-2.1492632361009245,False,c1,1,"A couple more uncaught TypeError, a la https://bugzilla.wikimedia.org/show_bug.cgi?id=43014:
Uncaught TypeError: Cannot read property 'left' of undefined
Uncaught TypeError: Cannot call method 'getOuterLength' of undefined
Reported http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Error_loading_data_from_server:_Server_error
--------------------------
**Version**: unspecified
**Severity**: normal",45041,-29,High,True
-7.635505656703836,6.895443634469018,1.3450545903311877,3.7748093171852446,1.847531979767095,2.941462365519344,-4.901187196778874,2.1680318191253782,1.0556691192850534,3.3663082224327656,-1.1220969599640531,-1.4666438049049992,0.0625955111797829,-0.9928285910892223,0.13839136921284378,-0.380558298595568,-0.572840769469477,0.2554111019807366,False,c1,1,"Example Page: http://en.wikipedia.org/wiki/Ansaldo_Poggi
1. Go to the top, click into the empty line above the ineditable image (the normally right floating image). This empty line should not exist. It can however, be deleted (press ""delete"" on the keyboard) which causes the start text to jump in front of the ""Modern Bolognese Violin-Making Table"" image.
2. Click somewhere inside ""References"". Move the cursor with the keyboard to the position after the ""s"". Press ""delete"" on the keyboard. The line starting with ""Tito Gotti"" will be merged with the heading (ignoring the uneditable ""references"" tag and ""cite"" template).
3. Similar to the above: Click somewhere inside ""References"". Move the cursor with the keyboard to the position after the ""s"". Move one more right into the (errorneously existing) empty line between the heading and the uneditable references tag. Press ""delete"" on the keyboard. The line starting with ""Tito Gotti"" will jump above the uneditable ""references"" tag and ""cite"" template.
4. Do the same as above, i.e. go to the empty line after the References-Heading. However, this time click with the mouse into the line. Press ""delete"" on the keyboard. This time the behavior is different, nothing is deleted and the cursor jumps to the start of the article. This in itself seems again to be an error in the ordering of page objects. Now try to repeat this with different browser windows screen or zoom sizes, so that the originally, the start of the article is not visible before clicking delete. It can be seen that the focus is not updated, the cursor is outside of the visible area. Press ""delete"" again and with seeing it, parts of the text can be deleted.
5. Do the same as above, click on line below reference with the mouse, delete once, cursor jumps to top. Do not delete again, but put the cursor again into the line below the reference heading with the mouse. This time the ineditable <references> tag is deleted.
--------------------------
**Version**: unspecified
**Severity**: normal",45026,-29,High,False
1.7425247541132802,-0.07826913433874871,-4.538973850237117,-4.349079663204677,0.37237260037859077,0.6671787967060572,-2.9758923368631414,-0.8605589636722791,0.6997417651505884,-4.285441801790403,-1.4949155533553167,4.811671170225943,-5.098839236351258,0.22627010064198227,1.5221945485588337,-0.02928722185724897,3.8712831300261303,-0.3948486636593067,False,c1,1,"According to <https://test.wikipedia.org/wiki/Special:Version>, the VisualEditor extension is installed, but it doesn't seem to be enabled. I think VisualEditor should be enabled for all namespaces, all skins, all users, etc. on test.wikipedia.org.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",45018,-29,High,True
0.20332052187209015,-1.3914810943985412,7.231966650561951,1.412321280366478,1.7682844738401378,-3.1294143239754595,1.409422388206722,-1.5157537458911943,-1.9271265500970505,1.9149684976660497,1.2209421204194686,-1.5662813962799376,-1.6900598221988066,-0.1821553765720596,-0.343445105583414,0.7584618334447586,-0.5491068252398528,0.4502043205128132,False,c1,1,"When I go to <https://en.wikipedia.org/wiki/User:Trevor_Parscal> and click the ""visualeditor"" tab, my browser console says:
---
The page at https://en.wikipedia.org/wiki/User:Trevor_Parscal displayed insecure content from http://en.wikipedia.org/w?title=Special:FilePath/California_Bay_Area_county_map.svg&width=.
---
Consequently, the pretty green lock icon in Google Chrome turns yellow.
--------------------------
**Version**: unspecified
**Severity**: major",45015,-29,High,True
7.940196824749929,2.104494594515362,-3.8028549707230788,-6.396829033773033,0.31622067336829873,-3.104275314374134,-1.311855263580501,-4.967078543235352,0.7665817953688263,1.8484391524844623,-0.10645365306461363,-1.030355469130652,-0.42216069837634684,0.49266941513674034,-0.09450397765418117,1.0125047372298597,-0.6935550902653461,0.6910398426510318,False,c1,1,"[Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia
I tried it on enwiki in my sandbox.
It does not work: when I want to ""Review and save"" a box pops up ""Review your changes"" --- but nothing happens.
* MediaWiki 1.21wmf5 (f4a44f9)
* VisualEditor (Version 0.1.0) (2e6425a)
--------------------------
**Version**: unspecified
**Severity**: normal",44988,-29,High,True
-4.885448194788518,-3.3293705448200885,3.847271439336037,6.515278854687178,6.4142416816560885,0.6149886992271203,-3.9133126211221803,1.5410900516558952,3.9168949572093865,-2.896026857159455,0.7949754109738763,1.6073785468341752,2.800936944849388,3.1935476074223246,1.986497043866299,-0.9676731009946082,-0.3472104850828892,-0.5635038579726999,False,c1,1,"1. Add a link to some text
2. Copy the text
3. Paste the text somewhere else
4. Remove the link using the link inspector's trash icon
5. See that both links are gone
--------------------------
**Version**: unspecified
**Severity**: major",44937,-29,High,True
-0.15831743013851085,-5.498335143198121,-3.62961176272351,4.098422326167565,0.26292406325248263,-0.9359552053928565,-6.878442820649761,-1.473504784839617,-2.0310617301252876,5.180629000492928,-3.6607054285967475,0.3986633009288614,0.4803537826123456,-2.177023956221939,0.5634359994787612,0.16689370166999523,-1.8345716001036658,2.087635320928431,False,c1,0,"**Author:** `orbit`
**Description:**
Steps to reproduce:
1. Copy part of a headline and part of a following paragraph
2. Paste into a paragrah
The linmod being inserted will look something like this:
[""s"", ""u"", ""m"", ""?"", Object, Object, ""C"", ""o"", ""n"", ""t""]
The objects are closing heading and opening paragraph.
The error is in ve.dm.Document.js on 1145.
--------------------------
**Version**: unspecified
**Severity**: normal",44806,-30,High,True
6.06032837969634,-5.912484536947003,-0.8166390269332506,3.690639169143589,-0.023927312409459,-0.6327490785232306,-0.6570570446507045,1.3660388147250848,-0.0349257901845475,5.90485893863738,0.9388107431151451,-0.32585587919235137,-2.2843213740780257,0.24496854884781882,-0.7475052707535728,-0.31912613501346865,2.762003481133715,2.1515953819952465,False,c1,0,"**Author:** `orbit`
**Description:**
Try creating ""some text <inlinealien>blah</inlinealien> more text"" and select across the inline alien and delete.
Uncaught TypeError: Cannot call method 'getDataFromNode' of undefined
--------------------------
**Version**: unspecified
**Severity**: normal",44707,-30,High,True
-5.546968206931593,4.666676420135786,2.454094793866613,6.337388470432358,2.154338331626651,7.28414512999588,-2.8639053190158568,-1.5794327479180734,-0.28674649964241467,0.5295503240669124,0.6465120163009632,-1.2441992596814695,1.3402731887202615,0.8345157305245179,-0.5206800587983889,0.9873159250761149,-0.3127533037541992,1.163007151768327,True,c1,0,"Pressing backspace in a slug at the end of the document throws an error:
* Create a new page (or go to an existing one), and enter ""ABCD\n"" at the end
* With the cursor in the new slug, press backspace; this throws an error:
Uncaught Error: ve.dm.Document.getNodeFromOffset(): offset 9 is out of bounds
--------------------------
**Version**: unspecified
**Severity**: major",44657,-30,High,True
-7.45749921777718,-3.805619272496246,-2.5138223543255496,2.817083054516913,4.771378354915804,9.037184151447285,2.152759335780263,0.6666491997949263,1.8143842988457821,2.012106345687763,2.9595411756535923,-0.17043226058754612,0.40059661119780765,2.538809255144999,-1.8565234238902604,0.872562345681903,-0.10694839365667108,0.4165158330131733,False,c1,0,"Inspect a link, then click on a different link, the inspector moves to the new cursor location and remains open.
--------------------------
**Version**: unspecified
**Severity**: normal",44552,-31,High,True
16.13192611768203,-4.330093891484811,-12.839116582696269,3.754928588175077,-0.11458004337271627,-0.07340421498614913,-0.5396674524740401,-0.315172560024819,1.8017866020792275,-1.4761662235805542,-2.614545565565465,-0.17675639762214557,-0.6355048186030174,-1.2519692366866324,-1.4842492467815864,-0.15711399284776945,-0.15598183888215456,-0.8728461816047042,True,c1,0,"On launching the save dialog, a console error is thrown:
Uncaught TypeError: Cannot read property 'nodeType' of null /w/extensions/VisualEditor/modules/ve/ce/ve.ce.js:117
ve.ce.getOffset /w/extensions/VisualEditor/modules/ve/ce/ve.ce.js:117
ve.ce.SurfaceObserver.poll /w/extensions/VisualEditor/modules/ve/ce/ve.ce.SurfaceObserver.js:136
ve.ce.SurfaceObserver.stop /w/extensions/VisualEditor/modules/ve/ce/ve.ce.SurfaceObserver.js:82
ve.ce.Surface.documentOnBlur /w/extensions/VisualEditor/modules/ve/ce/ve.ce.Surface.js:324
--------------------------
**Version**: unspecified
**Severity**: normal",44525,-31,High,True
-8.925773896176038,2.909029526608233,-0.607047971504759,-0.41223012698137007,4.844613762680103,2.2247988634232225,0.43526820721613824,0.1568700601703199,0.8784744708711143,-3.0169493371878,-2.0883182827003575,2.587528606204039,-0.33318168171439577,0.15167672784112618,3.273980887299488,0.34566191856644896,0.496557634796823,1.8839493848932276,False,c1,0,"As of I002c5aa23704c1c46ef46fa1970a4254614b9eb1 when saving and an edit conflict occurs the user is shown a browser-provided confirmation box which allows them to either cancel or resolve the conflict manually.
It would be much better if this was integrated into the save dialog.
--------------------------
**Version**: unspecified
**Severity**: enhancement",44522,-31,High,True
-0.817168546567336,4.199729992370578,-5.48969252514512,-3.2806047864157653,1.4562301343374306,0.9469467356758725,2.652302909228008,4.8641315987121025,-1.4835003564964462,-0.5781898168433486,-1.3263608149118526,-2.507504014392583,-0.8858326244015897,1.1317660176124784,0.32275998149025753,-1.810419995239882,-0.8073811792479253,-1.5056532617534355,False,c1,0,"It isn't just that this would throw an exception:
new mw.Uri('http://krinkle.dev/mediawiki/alpha/index.php?title=VisualEditor:S@box&action=edit');
Although that is also bad (when done on non-@ pages), it is especially bad that on pages containing an @ in the url, the module won't even finish loading because of this line:
defaultUri = new Uri( documentLocation );
So instead, mw.Uri stays undefined.
--------------------------
**Version**: 1.19
**Severity**: critical",44513,-31,High,True
-2.5279433075287456,-0.29174666937646876,1.0374475850351814,3.88632960837446,-2.6289189401001702,-1.7578180067059703,-0.9028345008254401,1.559339185449736,-0.015604643772224702,-0.676651550375424,4.553906500917073,1.4875811440255082,-3.5998780529971794,1.0744437661674269,-1.0299277556626043,-1.3773827273584565,0.7121784995431619,-0.8104443211631089,False,c1,0,"Wikitext to reproduce:
<span>
[bunch of newlines]
</span>
Parsoid generates <span><p></p></span> for this, but it doesn't mark the span.
Todo:
* Make the failure a bit more graceful
* Investigate whether p inside span is legal
* Investigate other cases where this breakage occurs
* File bug with Parsoid for proper protection of user-generated tags
--------------------------
**Version**: unspecified
**Severity**: normal",44487,-31,High,True
1.112039526908918,-5.421859372747123,-5.452705532219767,1.220936008954467,0.8829878206005151,-0.45249638277947346,-1.8920214320477982,1.0672564826544475,-1.7831891427818742,-0.33494521894884866,1.0512880293890192,-0.18161664046220438,1.394913128691997,-1.1832063272343265,-0.12684122602950065,1.1077070638218245,-0.7537339869142969,0.2746391796720047,True,c1,0,"Go to demos/ve/?page=aliens in Firefox; select all:
TypeError: end is undefined ve.ce.Surface.js (line 980)
Press ""a"" (or backspace and then ""a""):
TypeError: start is undefined ve.ce.Surface.js (line 995)
(And a pawn appears in its own <p> above the a.)
On any click thereafter,
TypeError: node is null ve.ce.Surface.js (line 1073)
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57355",44404,-32,High,True
3.089242255482944,1.0942339514697466,-3.4021500640440845,-9.193956810011095,-5.862441936426222,5.341457620731946,-0.15091552669474506,4.465578951307917,0.7560834261704761,-0.7501121586810271,-0.9498076288781636,5.060095889633965,0.8387212504673598,3.320352815350015,-1.4480427007915786,-2.6771125509452047,-0.28204320645645575,-0.7363077508369993,True,c1,0,"Due to gerrit 31118 being merged, Parsoid now has selective serialisation live. This means that VisualEditor needs to include Mark's patch to handle this.
--------------------------
**Version**: unspecified
**Severity**: critical",44403,-32,High,True
0.9282022995833619,-12.60719984627292,-4.709385603758344,5.864490491954177,-0.3757656648843011,-3.304089575013913,-1.759580811355855,-0.32356372162833824,-5.05590089104464,12.112907146409931,-0.9607629137121321,2.2183696964987583,-0.505160852935771,0.6476520576819977,1.2608409267365914,-0.815694350433851,1.819634999361311,0.3486912214094404,True,c1,0,"this.emit( 'saveError', null, 'Unsuccessful request: ' + data.result, null );
(ve.init.mw.Target.js line 131)
causes ""TypeError: data is undefined""
--------------------------
**Version**: unspecified
**Severity**: normal",44402,-32,High,True
3.592557017897509,0.46349241703849664,-5.430492191437153,0.33309178646688187,-5.291910619379539,-3.5054308567297783,-5.750772445408631,3.1360175969458313,-0.3331674166814613,13.028788108658212,-5.685060692046495,-1.0519349391101653,-1.847215335246215,1.983850776187011,-1.9085563051515546,-1.444865259793117,4.415913482058194,-2.8021099096547037,False,c1,0,"For after December:
* consolidate 'type': 'metaInline' / 'metaBlock' into 'type': 'meta'
* get rid of ve.{ce,dm}.Meta{Inline,Block}Node
* create ve.dm.MetaNode with converter stuff but don't inherit ve.dm.LeafNode
** eventually integrate that into the new node API
--------------------------
**Version**: unspecified
**Severity**: normal",44398,-32,High,True
-3.7820422289571254,0.5125735498638218,0.40756349587668694,1.140744022452846,9.411208687591172,-2.205404414093703,0.21014355083877323,-3.66709384032459,-0.669006854276083,2.4874049815108945,-0.797148010657815,-0.7318586398977474,-0.7900425294307434,2.0968106117692376,-1.1129160906139584,0.6080338207563237,-0.014382189124362954,1.6882003705940531,False,c1,0,"When I place the cursor before the template output, and press ""Delete"", it deletes the template and one more character after the template. When I place the cursor after the template output and press ""Backspace"", it does not delete the template (simply does nothing).
--------------------------
**Version**: unspecified
**Severity**: normal",44350,-32,High,True
-8.702497471714222,2.7715847614411935,0.5995218841200973,-2.3938024890209633,-0.363140442421066,-3.1194129992222734,3.651899034175634,1.3656158267543343,1.9607674249743947,-0.7294779856984652,-0.42001747765994324,-2.817673825833128,-1.8828660849616075,2.5579684881330103,-0.6673686356129842,1.6314803334118464,-3.2900650867445096,-0.5933724275251357,True,c1,0,"Right now the link inspector's suggestions box displays only after the ; instead, it should show instantly, then populate with more data as API returns with a spinner. Trevor has some ideas if you want to bug him. :-)
--------------------------
**Version**: unspecified
**Severity**: normal",44341,-32,High,True
-5.7898499434472,-5.61075206053818,-1.4006359651675915,1.1164328922990832,-0.8614490589832524,3.4277879813734966,3.475286941249686,1.5630600424716143,0.12418961219789598,-1.644267099786937,-2.995400510344955,3.2638358154717,-3.2418322717150536,2.2561330258175376,0.33635702040362236,-0.748680539078979,2.1427790855038857,-1.0239943418856026,True,c1,0,"Annotation of inline nodes fails - the data model is not updated to have any annotations added.
--------------------------
**Version**: unspecified
**Severity**: major",44340,-32,High,True
-8.255974184435003,1.821784887804732,-4.648818952956935,-0.8627473481717466,-3.6613316548049717,-6.110061831199332e-05,-1.0257994823020589,1.3883651904978334,3.4178634968152366,-0.4926170164781496,-0.986717196683085,-0.9042509348681163,0.6333302651344854,-0.2747054239631552,-2.113593538294969,-1.2650298827201043,1.734235439116141,-1.224726889521416,False,c1,0,"Per conversation with Gabriel, MWInternalLinkAnnotation needs to deal with percent-encoded hrefs. At least question marks (?) and percent signs (%) will be encoded. We need to decode these before presenting them to the user, encode the user input on the way out, and use href shadowing to make sure we don't change the href if the user didn't change the target (even if that would otherwise happen due to complete vs partial percent-encoding).
--------------------------
**Version**: unspecified
**Severity**: normal",44298,-32,High,True
-5.475240730584691,-8.136150258017954,-2.2649988279855684,4.262990864142228,3.2964718820367187,5.305387681866375,3.1501473773633277,-0.8348047555792851,-0.08976684390367767,-1.2144529338157488,-1.6288211925564675,-2.2149293523184816,-2.38279665634217,2.117325730276429,-0.758682497807782,-0.9682949327878019,-1.2279159282003866,-0.7284430639238024,False,c1,0,"...presumably because the link becomes a pre-annotation.
--------------------------
**Version**: unspecified
**Severity**: normal",44275,-32,High,True
6.488558573275984,-10.785793954661653,6.799675683581437,-1.121081484156739,-2.375572184193391,-0.4145270503301205,0.6296273939596189,1.301390383151109,1.5999556055653892,-0.6415512375179073,-0.3193872523920458,-0.76105963512732,1.898437354852927,1.1493333435577613,-0.04242029861075114,-0.13270231516172293,-0.4640950211227689,-0.72720656944892,True,c1,0,"From Max's bug 42142
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42142",44220,-33,High,True
3.631322527803721,-3.5846150272995914,-4.3402121591079315,2.7494715179978866,1.9547993851792635,-1.2628733014908675,-0.8357287479194717,-1.223390917472919,-0.9068312354305286,1.3316142374654314,0.7216818989470637,1.8482498959103248,1.9437242652407618,-0.10957170874777589,-0.045318436200203926,2.0735727786235425,-0.8281122623064929,2.2136645328913644,True,c1,0,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit
2. Select all using Ctrl-A (or Cmd-A) and press backspace
3. Press any content key (e.g. ""a"")
What should happen:
: You get a document with an ""a"" in its own paragraph.
What does happen:
: You get a document with an ""a"" in its own paragraph, and two console errors:
TypeError: this.data[offset] is undefined
...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...
load.p...4105Z&* (line 89)
TypeError: this.data[offset] is undefined
...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...
load.p...4105Z&* (line 89)
Thereafter, pressing return in the new context gives:
TypeError: node is null
...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent...
Etc.
--------------------------
**Version**: unspecified
**Severity**: critical",44219,-33,High,True
-2.9296253383394686,-5.182494261400501,-4.254702378646062,-0.7444420123039737,2.4102349285117253,0.7620904907960757,-3.9187736499257495,-3.517502980402639,0.6573881341401495,1.9923629021094973,-0.6123015487661188,-0.6304892293861555,0.6639622220219139,-0.544712722228053,-0.5274268795564003,2.9899271574415907,-2.0333511070662125,1.5867113276204823,True,c1,0,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit
2. Select all using Ctrl-A (or Cmd-A) and press backspace
3. Press any content key (e.g. ""a"")
What should happen:
: You get a document with an ""a"" in its own paragraph.
What does happen:
: You get a document with an ""a"" in its own paragraph, and a pawn.
--------------------------
**Version**: unspecified
**Severity**: critical",44218,-33,High,True
-2.4979998161034196,-5.765336076594565,-6.488283158740124,2.3000899964217254,-3.8899471346533163,-4.112440277817455,-1.674489695902694,-2.7568213220455666,-0.6132171910782572,0.9549736784655156,-0.5729244724933706,-2.210453670348288,0.7531171419350584,0.0550828282357827,-0.3900617586052464,-1.114052470484479,0.8032858984105931,-0.9327403525311768,False,c1,0,"Specifically it fails when trying to insert text content between two inline aliens or after last inline alien inside its parent.
Exception:
Uncaught TypeError: Cannot read property 'start' of undefined ve.dm.TransactionProcessor.js:259
ve.dm.TransactionProcessor.processors.replace
// Set change markers on the parents of the affected nodes
for ( i = 0; i < selection.length; i++ ) {
this.setChangeMarker(
selection[i].parentOuterRange.start + this.adjustment,
'content'
);
}
--------------------------
**Version**: unspecified
**Severity**: normal",44212,-33,High,True
-4.024585631568365,-1.7224965540944641,-2.947092514915127,1.7726947063716776,7.206669623132129,1.0559143336355692,-1.7529751397645459,1.5653413228447284,-2.085381858228833,1.3161647726954362,-1.8311007810433015,-0.016395217008378316,0.9468734390789986,0.5946998524067801,-1.160494776300827,-1.7656317390420297,-2.5882213668472724,0.4264899149217032,False,c1,0,"Currently when using VisualEditor to create a new page, the ""Save page"" dialog box offers two checkboxes below the edit summary field: ""This is a minor edit"" and ""Watch this page"".
When creating a page, ""This is a minor edit"" does not typically show up. It's a bug that the checkbox appears when creating a page with the VisualEditor interface.
This bug is closely related to bug 40774.
--------------------------
**Version**: unspecified
**Severity**: trivial",44137,-33,High,True
-4.295347914186639,7.081657629610856,-1.1373321571494177,-0.72441693726114,2.5094246321255693,2.3441679570231555,-0.35721269178513904,1.4706089330262158,-2.1183593672089778,0.3542672192407519,-0.1846179024296961,0.8319959106093358,-0.0026518447647987387,-0.31154208803150585,-0.6855178731313023,0.8953618979238559,0.9314931896560525,0.07035041916621299,False,c1,0,"If you have a floated table inside an alien, it gets a shield (and a phantom) in Firefox but not in Chrome. This is because the table is floated with external CSS triggered by class=""infobox"", rather than an inline style attribute. At the time when we check for $this.css('float'), $this hasn't been attached to the main DOM yet. Firefox computes styles on unattached nodes correctly, but Chrome doesn't.
The solution is to wait until after the entire CE rendering has been built and attached to the DOM before generating shields and phantoms. Possible implementations:
1. Add an onAttach function to ce.Node. After attaching, traverse the entire CE tree and invoke onAttach() on every node (bottom up). This is expensive, though, because you have to traverse the entire tree just to invoke onAttach on the few nodes that use it.
2. Make the ce.Surface throw an 'attached' event after attaching to the DOM, and make the ce.AlienBlockNode constructor listen for this event. This is not as clean, but more efficient, because only nodes that need processing are processed.
I have a slight preference for #2, but I can be convinced either way.
In both cases, the call to onUpdate() in the ce.AlienBlockNode constructor would be removed, otherwise the HTML would be set twice.
--------------------------
**Version**: unspecified
**Severity**: normal",44134,-33,High,True
-3.2410990543280156,4.958942299866489,-0.783709901606592,0.2551681325601034,0.3723955773106904,0.8500865698085165,0.21043504414624703,-2.117963320939014,-0.39443377184258865,-1.340109615700709,-1.1657161271987915,0.17613494443148903,-0.36848882299421337,0.8823915261338886,-3.015152224567047,2.103375468746119,-0.3092239526540195,1.783309425429062,False,c1,0,"If you try to save a page and it fails (e.g. because of an edit conflict, blocked user, Parsoid down, or whatever), then click Cancel, the spinner keeps spinning and the Save page button remains greyed out.
--------------------------
**Version**: unspecified
**Severity**: normal",44125,-33,High,True
-8.321654660407132,-0.8885868324936421,-6.868907393735988,-4.278803267534425,2.7387832887428125,-0.4976282745562298,1.9027218019131187,-0.5090235436010272,-1.8253457573578131,0.30838580347526534,1.1727261558182769,2.8442684669778258,1.258624424280097,-1.732443877319442,0.09046635022810445,-0.0004330419607736502,-0.9691338128854683,-0.7428646881900138,False,c1,0,"Currently, the DOM->data converter generates an empty paragraph if the input is an empty string. This paragraph is marked with .internal.generated=='wrapper', so it's unwrapped on the way out. This is bad because we lose change markers that way, and have no way to propagate them.
Instead, it should use another generated marker which causes the paragraph to be unwrapped only if it is empty, and be preserved if it's not empty.
--------------------------
**Version**: unspecified
**Severity**: normal",44121,-33,High,True
-9.887223011202915,4.694120003639977,0.9923233643665235,2.3013900670642546,-7.3562589979596495,-0.10933464791278469,2.9473742239205043,4.030151898137663,-4.715604911146624,-1.7593880975322453,-2.2627814032770335,1.7490374562211917,-0.237841140193507,-3.2135437981401163,0.17344614354857946,1.8002515210323917,0.5192157123974452,1.0364593701607492,False,c1,0,"Normally, unrecognized tags in wrapped blocks are alienated as inline or block depending on the tag name. This is broken for tags with unrecognized mw: types (and for about groups), which are always alienated as block when in wrapping mode.
--------------------------
**Version**: unspecified
**Severity**: normal",44119,-33,High,True
-3.1107298530881926,2.1347328819221474,-1.076601685292017,6.098353552611976,5.094571341801741,-0.595782699910553,0.41830487566130525,2.050345043071884,-2.0837329169192667,4.669139566919441,-2.135606796082965,-0.2654164800622212,-1.053035876281096,-1.1659751903003923,1.0690692518543745,-3.2549164708516045,-1.6026760259431507,-0.3849974053711971,False,c1,0,"When loading a page with VE enabled, the ""edit"" tab is changed from the ""vector-view-edit"" message to the ""edit"" message. This is apparent on enwiki, where these messages have different values. It's also apparent when using ?uselang=qqx
This shouldn't happen, the message for the edit tab should be consistent.
--------------------------
**Version**: unspecified
**Severity**: minor",44117,-33,High,True
0.8281748780639338,-5.915535388270424,-2.4781423731336556,0.30328695347222134,-2.154340379919187,3.2049383037987944,-6.366791406964938,0.592859979574019,-2.309940036721487,4.009333222193684,-0.5924382282302298,-2.1849580432027267,-3.034775899752992,2.103906872340402,4.588185868601136,-0.24844040249543253,0.3025612908290425,-1.0757780694885186,True,c1,0,"Possibly the wrong version of Parsoid updated? See https://www.mediawiki.org/w/index.php?title=VisualEditor:Test&diff=next&oldid=604180 as an example of '<p data-ve-changed=""[...]"">' elements being created.
--------------------------
**Version**: unspecified
**Severity**: normal",44092,-33,High,True
-0.4006098329138674,-5.614863945123,-3.649148785695397,-6.085745415525756,1.9545330197685828,-3.536760782996266,-2.7346480901115973,-1.7516080354406527,1.2885497656922507,0.28058797640813005,0.7335077557636276,-2.7513746690609686,1.8048917451620698,-1.1640276102174236,0.5204222583012088,-0.9816546437712574,0.21290799319791942,-1.5564103703511505,False,c1,0,"Roan told me that, if I ever saw one of your comical placeholder Unicode characters, that it was a pretty well-defined bug. So here:
1. Create an unordered list
2. Enter some items
3. Hit enter twice
4. Type something
Expected: Whatever I typed should appear on the screen.
Actual: Pawn character! It also prints my text, but only after '♙\n'.
--------------------------
**Version**: unspecified
**Severity**: normal",44091,-33,High,True
0.6871299829564164,1.2903830592254728,0.8257816550950103,-0.37687093925611415,-1.8379386476237034,-0.19304921766647787,1.170295912850671,2.2424600551745217,-1.8494744899329374,-0.09690059168680332,-0.4355301467446866,-0.029975883558518213,0.4262966462952713,0.8029750897583945,-1.7132774191627185,0.980854748869008,-0.5290403638843992,-0.2833145226037326,False,c1,3,"Best seen on a slow connection e.g at crossbrowsertesting.com; I used Chrome 29 on OSX 10.7
Seen on beta labs and test2wiki with a fresh browser instance:
* Click Edit/beta, invoke VE
** View of page appears, then disappears, refreshes and appears again before ""Welcome to..."" iframe appears
* Click X to dismiss iframe
** iframe disappears for a moment, then reappears, then disappears again
Given a slow enough connection, this behavior could be bothersome for regular users of VE.
It definitely causes constant failures in the browser tests for Chrome on both beta labs and test2wiki.
This is not seen in Firefox
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55756",56854,13,Medium,False
-5.12195495773966,1.342476943878804,5.4647789281045505,6.919888592159086,2.405573052982012,1.2901332762988964,0.3759884619170091,1.1501043530092017,3.8541022616352896,-1.8562486469264878,-1.942513378780998,2.6279294699041733,-1.3393685054593174,-0.30873458567717904,0.7862129249806706,-1.2055361101247883,-1.710126893479433,0.83277114681485,False,c1,3,"When a template is selected in the VE editing surface pressing enter should open the transclusion dialog.
When an image is selected in the VE editing surface pressing enter should open the media settings dialog.
These will be of benefit to people making textual changes to the surrounding context who want to make textual changes to the template output / image caption.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50996",56827,13,Medium,False
1.635005999672019,-0.27523810850250285,-0.5425015037730887,-5.869214184905342,-0.548934710295909,0.19612498273990897,0.15086831398457523,2.8156228508425287,-0.11509566898323018,-1.5162525501713198,-1.9373284307001755,0.8923062276579674,-0.39829796152312813,-0.8536405754657146,-0.3125832018462793,-0.5768897606253137,0.3468247484611999,-2.203694418761499,False,c1,3,"**Author:** `romaine.wiki`
**Description:**
The VisualEditor substitutes templates that shouldn't been substituted. The largethumb template got substituted on several occasions, like:
https://nl.wikipedia.org/w/index.php?title=Managua_%28stad%29&diff=38749742&oldid=38743043
If this continues to happen too long, we are forced to disable the VisualEditor for everyone as it changes things that absolutely should not be changed.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54315",56803,13,Medium,False
-4.412313932393909,-2.1113750687685755,0.05844850700954751,4.111725879988444,3.2396650341459505,0.2930227217064283,-0.5286017697147001,-0.08702517183238426,-1.7677896014423178,-1.1685436184430333,-1.142670536310128,2.7525357484879818,1.0034389557947732,-1.994599442701162,-1.3082720265961738,0.5111139365074835,-1.0747918925936346,-1.3401248996131265,False,c1,3,"Screenshot explaining issue with visualeditor
Hi
These are the steps:
*Create a preformatted multiline text, inserting a space before each line, in source mode.
*Open visualeditor, select the text inside the box (the preformatted text)
*Change text type to ""paragraph""
*The text is badly converted, return characters appear on the line. If the text is saved the return characters are lost.
*This happens in other cases too, tab symbols are displayed sometimes.
Thank you.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12384}",56794,13,Medium,
-4.798134403458851,-0.25065862587664256,-2.763812321910967,-2.0318328796458207,-1.142836084619979,-3.173728929790096,0.16453374995611636,-1.1481755164221976,0.9904431942595235,-0.5998896626927044,-1.5164475466640872,-0.3398190326496454,0.10889037453764683,-0.9225010290832669,-1.750015135110857,0.16010831460334546,0.2219844061948666,0.9447234686447443,False,c1,3,"I couldn't find a way to click the links while editing and go to the target page. It's not easily available in the source editor, so it's not really a regression, but I find myself needing this features every time I edit, because the links are blue and look like links.
GMail and Google have reasonably good ways of going to links' targets in editing mode, so hints can be taken from them.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50321",56759,12,Medium,False
-5.074714610391201,-2.9740786017985403,1.1314264731090873,4.590369695094822,2.0475748177817192,2.1416864731973027,-2.620216477596674,-2.0395842163048585,0.948335151068121,-0.003341358360929192,-0.5283020232866531,-0.19181724034494163,0.14414448719588613,-0.08352004745055819,2.0982006562018363,1.431661213052166,-0.29499951061594176,-1.9174027313314785,False,c1,3,"+++ This bug was initially created as a clone of Bug #50643 comment 6 +++
Steps to reproduce:
1. Edit a page in VE
2. Select a piece of textual content without any fancy stuff in it.
3. Drag it to another location in the page
Expected results:
The cursor should be a disabled-drop icon
Actual results:
The cursor is an 'image' icon
--------------------------
**Version**: unspecified
**Severity**: enhancement",56757,12,Medium,False
-6.351488829044316,4.724633464597311,-0.16903154686125887,-0.23491184704161883,5.413970770528838,1.678613182743795,0.4931972260426507,1.2561227164531896,-1.5123103084751393,-0.7543729501987992,0.6203713437507568,1.9760590578225397,0.1718903593774339,1.7871145903530543,-0.600246909467443,-0.8816938578480744,0.8809723237307099,-2.5857807667038655,False,c1,3,"Dropdown clipping
Referring to the attached screenshots there are two issues:
1. The width is not adjusted to account for the OS scrollbacks. I assume this is because has one of those fancy Macintosh computers that doesn't know how to draw a big chunky old-fashioned scroll bar.
2. The assumption is made the the height of the VE container is the maximum height the scrollbar expand to. Here that is clearly not the case. It may be the case that because we don't know what lies beyond the borders of VE (e.g. z-index 9999 banner), we can't do anything about this. Maybe we can make the assumption the page content is sane, and if the dropdown ends up obscured, leave that as an integration problem for the user?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69707
**Attached**: {F12176}",56705,12,Medium,False
-5.973319262435195,-1.9526231561680412,5.682872356571895,5.586150557584976,-7.216053892321558,-1.21130808705554,4.397605233842378,1.2607711328516609,-0.4894236246202812,1.6063275986631345,-0.12734056074678435,1.1128523377654191,-0.5471750717131476,0.2783300221962044,-0.5960056171599808,-0.02449160226790348,0.7595412852824384,-2.339131048113577,False,c1,3,"Screenshot of languages dialog tab with the new-category popup in front
Switching from categories to languages while suggestion popup is open doesn't close popup -- see screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12105}",56657,12,Medium,False
-8.335415701239313,0.009606974566764848,-1.240530516804112,5.036935334089254,2.323530973357478,1.9976228163773662,0.0803100827085581,0.03670396244018492,2.077843588491911,-0.952112439741299,-0.42742322138419864,1.003813515482945,0.5951090182087784,-0.5575087454718464,-1.4607745053906154,0.0273785474593502,0.7998224505078533,0.4285531760867498,False,c1,3,"Screenshot of category dialog, showing no apparent way to get at the listed categories
The category suggestion tool seems to provide a simple typeahead search, but provides no way to go and see if the categories you've found are relevant.
At a minimum, you should be able to open up the category page via a link from the search box and and the little tag display.
Better still might be a little preview that pulls the description text (if any) and some sample contents right within the dialog box.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F12103}",56656,12,Medium,
-3.6860361752778634,4.442884505164944,3.5137663863739412,-0.885125229574413,-1.8855874105884751,1.7312468944220132,0.8566905586815325,2.6268764158100812,1.135801458194909,0.03767623559949396,0.32433509215683154,-0.5740446969016353,1.0743675530838104,0.06303869831769227,-0.5868361012031542,-2.303246430929512,-0.2804769143605581,1.6964713039724086,False,c1,3,"This is kind of a meta bug and not an actual issue in BZ. Couldn't think of a better place to file it...
Filing bugs/enhancements is difficult for some people to figure out. We can lower the barrier pretty easily by making a 1 or 2 minute video showing you how. Upload to commons, link to from BZ main page.
Key components:
- Sign up
- Choosing the right product
- Giving clear description of the problem/request
-- Screenshots are fantastic
-- Providing links is great too
- Make sure to emphasize to not worry about filling all the fields out properly, the important step is opening the bug!
Major props to User:Biosthmors on enwiki for coming up with the idea.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**Whiteboard**: gci2013 https://www.mediawiki.org/wiki/Google_Code-In#Candidate_tasks
**URL**: https://commons.wikimedia.org/wiki/File:How_to_file_a_report_in_Bugzilla.webm
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52696",56606,12,Medium,False
-8.1084951697333,5.326834267491183,1.6791535534062554,3.120774856218137,-0.5693899396610776,-1.0714788786517369,2.264516709730308,-0.2628756288553301,0.8045164032215244,-0.5829668390411653,0.7135397348598693,1.6721407606843777,-0.12584138856867622,-1.4566846793249364,0.3326529380808658,-0.6234013942493954,0.1621172222067797,0.5791847808523747,False,c1,3,"Occasionally, pages have stray opening table tags which may end up screwing up DSR computations (which in turns messes up selser). It is possible that our latest foster parenting code implicitly handles this by wrapping the entire table as templated and protected a large body of code (which could then serve as a flag to the user to look for bugs in the wikitext souce). So, it might be worth verifying this and adding tests to spec this behavior.
See the bug report: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=574391235#Duplicated_content_when_deleting_apparently_blank_lines
See my response that fixed the problem in the wikitext source: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=574483272#References_and_tables
If this is not already handled by our handleUnbalancedTables and markFosteredContent DOM passes, we may need to tackle this -- by maybe adding a fixup in TokenStreamPatcher that enforces limited table scope (section boundaries is the obvious scope limiter => close unclosed tables whenever section heading tokens are encountered).
To be investigated and fixed.
--------------------------
**Version**: unspecified
**Severity**: normal",56605,12,Medium,False
-5.917300559578566,-0.7663906506200995,-3.001750320981449,1.3067596763484013,-2.2319023914903355,-2.977594048760146,0.02327890264592103,0.7639438131552126,-0.7568353918889512,-1.6238581657235756,1.0882785324089164,0.3117755807145748,2.142954990482045,0.10163831282319968,0.03287950211986512,-0.9874963457630122,-0.02890769265327453,-0.9728797336871438,False,c1,3,"Assigning to Parser as I suspect this is what would need to be fixed up to support this.
This patch [1] demonstrates the large number of rules exist for external links:
The browser matches styles from right to left, so the rightmost selector is really important.
We shouldn't need to have to resort to CSS rules in the form div#content a.external[href ^=""https://""] - a link with class external should also have a class describing what type of external link it is if it is necessary. These selectors are less efficient and are not supported by older browsers.
Ideally we should simply these rules to become something like:
.link-audio,
.link-video,
.link-document,
.link-irc,
.link-ftp,
.link-https,
.link-news,
.link-mailto {
padding-right: 13px;
background: transparent center right no-repeat;
}
with rules for each of them for their correct icon.
[1] https://gerrit.wikimedia.org/r/#/c/85920/2/skins/vector/externalLinks.less
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63725
https://bugzilla.wikimedia.org/show_bug.cgi?id=63521",56604,12,Medium,False
-1.953090198377542,1.026861381791285,-5.264811686733889,-4.083763036699745,0.5342262524219159,1.9397063730385382,-2.3003819814821043,-0.20580012535425754,1.4267545738665148,-0.43189012799658233,-1.3024529363772772,-1.3748464439001231,0.6373694301191755,-1.697282662424132,0.014108402749126725,0.9191299599516992,0.20257129676305485,-1.7153328059291635,False,c1,3,"In ve.ui.MWReferenceDialog, this.referenceSurface changed from being a Surface to a SurfaceWidget. I noticed this because I rebased some old code that used this.referenceSurface.getModel() and broke, but this seems to have happened a while ago with the introduction of SurfaceWidget.
When a variable name is 'fooSurface', it should be a Surface, not something else. In particular, you shouldn't have to do this.referenceSurface.getSurface() to get the surface.
The same applies to this.captionSurface in ve.ui.MWMediaEditDialog.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56588,12,Medium,False
-8.91446106475414,4.578645695378317,-1.3791497759039508,-0.6117816515108863,6.403833711403186,3.842150185527977,0.9118796996621992,-1.7240442024934008,-3.0170988416955193,3.864662563716589,-0.1403413541477021,-1.0507020607947353,-1.2796195249242537,2.4704728470621937,-1.515602177150785,-0.5913681135469699,0.5498802174392747,-0.5423332702397894,False,c1,3,"When you insert a reference in the middle of a bolded word, the reference itself doesn't receive a bold annotation, and so the resulting text is something like '''He'''<ref name=""hello"" />'''llo''', with the bold breaking around the reference.
When we insert inline nodes like references from the UI, they should take annotations. This is probably a wider problem beyond just references.
--------------------------
**Version**: unspecified
**Severity**: normal",56587,12,Medium,
-7.7772862608273154,5.31837558451446,-2.2185091754248223,-0.3774120032024305,3.241264936107374,-3.0005824485090953,-0.7371961973492089,1.2415959750830403,-2.652344812788102,0.8111602037237517,-2.2319717769170024,-1.775396583705465,-1.5366344975540516,1.3005337653120295,-0.1509115371513765,-1.7350621334990666,1.0492963115519764,-1.1081386360297814,False,c1,3,"ce.MWExtensionNode.onParseSuccess contains the following code:
// Rerender after images load
this.$.find( 'img' ).on( 'load', ve.bind( function () {
this.emit( 'rerender' );
}, this ) );
Problems:
* Why is this in MWExtensionNode? Shouldn't it just be in GCNode?
* This potentially emits multiple rerender events, one for each image
* The first rerender event has already been emitted because we've already resolved the promise and attached the nodes to the DOM
What we should really do is attach the nodes somewhere else (where?) so that the images load, then reattach them to a wrapper and resolve the promise with that. That way we only emit rerender once, and we correctly only resolve the promise once everything has actually loaded.
In practice, this means the math inspector moves around twice after typing LaTeX in certain cases: once because of the 'rerender' event caused by the <img> tag being put on the page (at which point it measures 0x0), and once because of the 'rerender' event caused by the image actually loading (at which point it measures correctly).
Open questions:
* How does this work for images with invalid/unavailable sources?
* Really what we care about here is the dimensions of the images. If those are known, we can render the node without its dimensions changing later
--------------------------
**Version**: unspecified
**Severity**: normal",56584,12,Medium,True
-8.450855281539893,2.6265300956432114,-2.888929492569984,5.657681952308301,5.307472821318148,0.2839956711033669,1.3392658106152657,0.15082775483960342,0.22719857855976955,-0.8159982707702218,-0.5369751560014744,-0.5204867426469637,-0.20008525429224733,-0.6359735590358664,-1.2706046372153565,0.9244117173816192,1.9566016483816433,0.9993210670783792,False,c1,3,"Right now, GCNode caching uses both the model hash and the hash of the config object. However, when properties in the config override properties in the model, the preview of a change and the new model node after the actual change will be the same but have different hashes (because the model is different, and because in the second case the config object is empty/undefined).
We should make generatedContents() static, so it can't inspect the model or any object state, and have a function that provides the default config that is then used to extend the provided config. That way we don't end up duplicating things in cache and rendering things twice.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56582,12,Medium,
2.6240232094683305,0.25426228424773534,3.3513490751231707,-0.9492074704941645,3.060580387806706,1.7122427015439203,0.8179528303620849,3.275312584272695,-0.15509009111706817,-0.45522053990230926,0.5065699138398223,2.3319549511184032,1.7374437328553363,-1.0219874762204237,2.1371529106447475,1.9306370326401432,0.6047004901224564,0.09455533932587623,False,c1,3,"Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects
Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",56469,12,Medium,False
15.520939742576118,3.635748798605672,-2.446719570512432,-2.979314294337368,-5.0176990046495575,0.20203275716720626,-1.4995799524536162,0.23702253706928578,-0.5627712432759268,-1.2573971379992805,-2.1879049441597096,-1.0273799279900495,0.8609088663293427,-1.010246992333573,-3.0684660208248973,0.41684564794167434,0.4506610112068219,-0.06974460313308173,False,c1,3,"**Author:** `jmichrina`
**Description:**
Example:
Line from ""International_Air_Transport_Association_airport_code""
DFW for Dallas–Fort Worth, DTW for Detroit–Wayne County, RDU for Raleigh–Durham, MSP for Minneapolis–St. Paul and LBA for Leeds Bradford (Airport).
Line appears correctly formatted in editor [caps represent bold]:
dfw for Dallas-Fort Worth, dtw for DetroiT-Wayne county, rdu for Raleigh-DUrham, msp for Minneapolis-St. Paul and lba for Leeds Bradford (Airport).
Line appears incorrect on page [caps represent bold]:
dfw for DALLAS-FORT WORTH, stw for dEtROIT-wAYNE COUNTY, rdu for RALEIGH-DURHAM, msp for mINNEAPOLIS-sT. pAUL and lba for LEEDS BRADFORD (AIRPORT).
Note that the correct version appears in the editor even after it's saved.
Possibly related to bug 53208, but I didn't have time to verify.
--------------------------
**Version**: unspecified
**Severity**: major",56454,11,Medium,False
9.628802450129118,-13.470653359648756,0.7550914024334787,-1.0396597356967514,-0.44002601685982,1.8599675667042777,0.48095765550869807,-1.021105306098213,0.12183016428093879,-0.7209760968085703,-0.49707946638939404,-0.640630924949833,0.7845467457687465,-1.9013381974180477,-1.561876326118898,-0.18788922744791725,-0.21754060747510517,-0.6028827838419968,False,c1,3,"Screenshot
https://en.wikipedia.org/w/index.php?title=Daniel_Rowe_%28footballer%29&oldid=570278760&veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11872}",56446,11,Medium,True
-3.2332525410421322,3.9424803984072767,1.5087143470397528,1.0404974247045793,3.05221349059374,2.0704140879210593,-0.8215987028257459,2.260123760287888,-3.724202550003982,-1.9297252797024922,1.214508980334792,0.05684213524711268,1.8510297621588174,0.6898113116568974,1.7282028956129984,0.7256770691107632,0.33035913849345255,-0.17004304912618085,False,c1,3,"This is a separate report for automatic caret movement from one place to another when using VE with ULS.
This problem has been seen with some other bugs, specifically, in the fourth[1], seventh[2] and tenth[3] comments of Bug 53708 and the original report of Bug 54421
I also suspect that the problem in Bug 53701 is a form of this bug only.
However, I am reporting this as a separate bug since I was able to reproduce it independent of these bugs.
System environment:
Win 7 X64 SP1
Google Chrome 29.0.1547.66 m
Test Url:
https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
Steps:
1 Enable ULS IME hindi transliteration
2 Take the caret to the end of the first paragraph using the mouse (i.e click at the end of the first paragraph to take the caret there)
3 Input [RETURN KEY][RETURN KEY]a
Expected output:
[NEWLINE][NEWLINE]अ
Actual Output:
[NEWLINE]अ[NEWLINE]
As long as the return keys have been pressed, everything is fine and the caret is in the second newline. However, as soon as a is pressed, the input is in the first new line and not the second. The caret has hence moved up one line before the input is placed into the output text. The caret does not move back and is after the output अ
This text is selectable, but can't be copy-pasted into an external text editor.
The text is removable, so this is not entirely Bug 53708 . However, pressing a backspace when the caret is after अ removes अ along with the newline that precedes it.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=53708#c4
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=53708#c7
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=53708#c10
--------------------------
**Version**: unspecified
**Severity**: normal",56424,11,Medium,False
-2.541648397849021,5.402334532211224,2.7735639407485877,3.546980418387845,1.9503023059455802,5.151884649438955,-0.7978719510459316,0.6120318702813797,-0.8299861085514565,-1.1431860352773362,-0.09923696528863335,0.369139819444368,1.6476654392272554,-1.222275510171834,-0.43806039518563367,0.047683261683631906,0.4108549750350534,-0.6739749999245133,False,c1,3,"Screenshot showing text duplication
This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3
The entire test procedure is as follows:
System Environment:
Windows7 X64 SP1
Google Chrome 29.0.1547.66 m
Test Url:
https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
Steps:
Enable ULS IME hindi transliteration
Take a caret to the end of the first paragraph using the mouse (i.e click at
the end of the first paragraph to take the caret there.)
Input ag
Output will be अग् as expected but with incorrect selection as reported in the comment linked above
Further input a
This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
What should have happened:
The original output अग् should have been changed to अग at the end of the first paragraph.
So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11824}",56421,11,Medium,False
-6.018482985876323,5.72015393628455,-1.7507773649363454,0.3182430283376736,1.6380997531446133,0.06624871532416887,-1.7832029390539663,0.6360386721530022,5.007941335595696,-2.410520957847331,-1.4216787043714396,1.058011214096928,0.17536962484196028,-1.295328362155336,1.1509441645687124,-0.2650014691369902,0.5624270410916361,0.4578361766663124,False,c1,3,"This is a sub project of bug 53697 https://www.mediawiki.org/wiki/Continuous_integration/Browser_tests
It covers setting up the Zuul configuration to trigger browser tests. From the wiki page:
The exact workflow would need to be figured out with the VisualEditor team. A first step would be to run the browser tests after a change has been merged and report back in Gerrit for their information.
At first we will only want to run browser tests after a change has been merged. This let us load the system progressively without disrupting the VisualEditor authors.
We can later on make Zuul report back in Gerrit a message stating the result of the tests, that will raise awareness among developers and they can work on fixing the unsuccessful tests. Additionally, we can have the browser tests to be triggered on every patchset, the labs instance load will have to be carefully monitored.
Once tests are properly passing and the setup has been proven useful, we can make Zuul to block patchsets not passing the browser tests. The developers would then be required to fix the code or the test to have their change merged in
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",56387,11,Medium,False
-3.7397903131673575,2.9922364348785955,-4.216011444253722,0.8750152330259959,-2.6448097697724804,0.5026938235875709,1.6885394326588479,-0.7064538211627032,0.2939388262436363,-0.18349964186476786,0.5592478376347785,0.638569070369023,1.0250286148594046,-0.6448305383541797,-1.9938336928075322,0.17676968180316377,-0.07173640439581286,-0.36079000876386624,False,c1,3,"For end users and VE folks the non-selser _rt end point is often confusing, as it shows diffs that are normally avoided by selser. It would be useful to add a _rtselser end-point that serializes to HTML, re-parses that HTML (to catch foster-parenting issues) and then serializes it back with selser enabled.
This will provide us with a quick sanity check for the selser code, and a better link for end users and VE to establish that something has indeed dirtied the DOM.
--------------------------
**Version**: unspecified
**Severity**: normal",56339,11,Medium,True
11.768258099096844,-1.479662909125853,-3.10284872727701,1.2582304274775313,1.14671265700882,1.3581915392290982,0.28336295961219005,1.4457832829133332,-2.0177684170111827,0.33536954473184455,-0.4149140377312226,0.5617134333908205,1.4532210376476646,-0.37105761202830223,-0.6411189192614124,-0.7952510183535155,0.7341594616356846,-0.0012127830823820407,False,c1,3,"Screenshot of Console Error and Blanked Page
This bug was found when testing per the sixth and seventh comment at Bug 53708
This is very similar to Bug 54331 , however, this one is reproducible.
System Environment:
Windows7 X64 SP1
Google Chrome 29.0.1547.66 m
Test Url:
https://www.mediawiki.org/wiki/Project:Sandbox?veaction=edit
Steps to reproduce:
Enable ULS IME hi transliteration
Input the following (below the 'Testing Area' heading):
agar[SPACE][SPACE][BACKSPACE][BACKSPACE]
What happens:
Apart from a bunch of buggy behaviour described in the seventh comment at Bug 53708 , the template is entirely removed and the following console error shows up once the second [BACKSPACE] is pressed:
Uncaught TypeError: Cannot call method 'getOffset' of null load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:231
ve.ce.Document.getNodeAndOffset load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:231
ve.ce.Surface.showSelection load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:287
ve.ce.Surface.onChange load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:274
oo.EventEmitter.emit load.php?debug=false&lang=hi&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…ck%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130919T025548Z&*:139
ve.dm.Surface.change load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…wPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:86
ve.ce.Surface.handleDelete load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:286
ve.ce.Surface.onDocumentKeyDown load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:267
proxy load.php?debug=false&lang=hi&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…l%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130912T173512Z:10
ve.EventSequencer.onEvent load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…wPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:19
(anonymous function) load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…wPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:18
jQuery.event.dispatch load.php?debug=false&lang=hi&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…l%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130912T173512Z:45
elemData.handle.eventHandle load.php?debug=false&lang=hi&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…l%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130912T173512Z:38
The file urls are:
https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperimental%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*
https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=hi&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130912T173512Z
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11639}",56334,11,Medium,False
7.439962303662163,2.1532340720826397,-2.9241882425677517,-0.6771579493939404,1.0636162798970743,0.47275593168634766,-0.24424340026939007,-0.26176775635324856,-2.1118624717924463,-1.7232727863820547,0.7360954655429812,-0.607322917546106,1.0102592550469338,-0.6171714047390653,0.03647568099712206,-1.0830305771312272,0.15750989520823477,-0.3006121389143117,False,c1,3,"This bug was found when testing per the sixth and seventh comment at Bug 53708
It seems somewhat heisenbuggy and I haven't been able to reproduce it yet. However, I'm sure of the steps which caused it.
Reporting this so that it's documented in case it is ever seen again.
System Environment:
Windows7 X64 SP1
Google Chrome 29.0.1547.66 m
Test Url:
https://www.mediawiki.org/wiki/Project:Sandbox?veaction=edit
Steps to reproduce:
Enable ULS IME hindi (hi) transliteration (labelled लिप्यंतरण)
Input the following:
agar[SPACE][SPACE][BACKSPACE]
What happens:
Apart from a bunch of buggy behaviour (described in the seventh comment at Bug 53708 ), the following console error shows up once the [BACKSPACE] is pressed:
Uncaught Error: ve.dm.Document.getNodeFromOffset(): offset 804 is out of bounds load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:106
ve.dm.Document.getNodeFromOffset load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:106
ve.dm.Surface.change load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…wPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:84
ve.ce.Surface.onSelectionChange load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:275
oo.EventEmitter.emit load.php?debug=false&lang=hi&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…ck%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130919T025548Z&*:139
ve.ce.SurfaceObserver.pollOnceInternal load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:292
ve.ce.SurfaceObserver.pollOnce load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:291
ve.ce.SurfaceObserver.timerLoop load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperim…PageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*:290
proxy load.php?debug=false&lang=hi&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…l%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130912T173512Z:10
The file urls are:
For the last line:
https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=hi&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130912T173512Z
For all other lines:
https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=hi&modules=ext.visualEditor.core%2Cdata%2Cexperimental%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T025548Z&*
Also, the template's formatting was gone with the input hindi text appearing alongside the template text.
--------------------------
**Version**: unspecified
**Severity**: normal",56331,11,Medium,False
-7.177755314280778,1.7979748875615336,-1.818798233047998,1.3224600719417117,3.769149639648236,0.9246497680333794,-1.4405461495599603,-0.48144658464879453,-1.9760109477574308,-0.9510181875741632,0.4769771956209219,-0.31824384964813357,0.1769649152492443,-0.2427970509132269,-2.1620247441802114,0.03264705315482341,-0.8377200012510728,-0.02275155819616792,True,c1,3,"I am trying to VEdit https://en.wikipedia.org/w/index.php?title=User:Elitre_%28WMF%29/Sandbox&oldid=573480590&veaction=edit , which is a blank version of my sandbox. There's a lot of white space between the title of the page and the point where I can start adding text, and although the source editor says the page is really empty, looks like there's still something there.
If I hover with the mouse right below the comma in the tagline ""Wikipedia, the free encyclopedia"", the cursor changes as if there's an invisible link.
1) Right under the comma, the ""link"" points to my userpage (it's clickable, and the page will open in the same tab);
2) some pixels below, the link will point to [[Help:Page History]];
3) going further down, it points to a diff of the sandbox.
There are other points in the page which trigger the links, but the page history one is not easy to spot.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52243
https://bugzilla.wikimedia.org/show_bug.cgi?id=58063",56325,11,Medium,False
5.9532412857886445,-8.463590073950467,-4.692091521631047,-9.461579866679765,-0.48475293140798414,2.3273313884556828,1.7920933232258944,7.711441453713811,1.4749385711189014,-1.3843404071558285,-2.3732459330636004,2.6923201222578124,-1.6394295174051452,-1.3365175033188597,3.893353190629882,0.772016346220444,-1.7298613321377359,0.48949342804242213,False,c1,3,"VisualEditor is installed already. Would be nice to have TemplateData as well.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56316,11,Medium,False
-7.159392725390989,4.337111936041413,-3.2959688791639845,0.9295485044469052,-2.7910675502595073,3.897946149812153,1.738758746309788,1.2638525551274307,-0.9162454560966703,-0.5046209100245465,0.7259456519691043,-2.5956637079167506,-1.081616948364264,-0.24352591444718996,-0.31545798207637166,0.5451718296584521,-0.5218302600370985,0.263818543339575,False,c1,3,"Because about half the code in the DM is solely there to keep this delicate data structure together, and now that we don't need ±1 cursoring it seems like a lot of effort for nothing.
The behaviour it provides (protecting metadata from deletion) can all be done in the transaction builders, and in fact we already do this for internal lists)
Going forward this will make multi user editing a lot easier to.
That said this is going to be a massive commit.
-----
Currently, MetaItems are stored outside the main linear data structure, in a separate meta linear data structure. This complicates the processing of linear data: transaction processing, rebasing, serialization/deserialization etc, and makes it harder to reason about document correctness. Instead:
* Store metadata as block nodes in the main data list
* On conversion from HTML, hoist metadata found in a content position to a legal structural position
* On conversion back to HTML, roundtrip metadata hoisted from unmodified content branch nodes back into the original content position
* When deleting across metadata (e.g. <p>foo[-</p><meta/><p>-]bar</p>), hoist metadata to a legal structural position as necessary",56299,11,Medium,False
-12.619722842147075,7.738064267054128,-0.2572460706013331,3.9714253799458623,3.1895565540842594,8.019563859529427,0.28485525963272984,-1.4163134246984632,1.160850506276585,-0.6722830963185302,0.14759626853371577,-0.17474934153934574,-0.47516088799119416,0.9066743677976303,-1.0344921857138756,-1.8657473421283135,1.0253841524684522,-0.8636056064697737,False,c1,3,"This would also solve the problem of the resize marker having to snap into the right position at the end of a drag if you use the wrong handle (or any handle if the image is centred)
--------------------------
**Version**: unspecified
**Severity**: normal",56298,11,Medium,False
1.2069225448841876,4.31369915133547,2.8066976527048197,5.924774116265614,-0.21720023858122306,0.39499468022107487,1.9935452218889678,0.33188046545816996,-2.008089839567211,-0.8088814823646562,-0.22706303210591905,0.15857194650535078,1.0844192796191505,-0.026722108690801605,-1.4938406112752087,0.7860031794930662,1.1508019464486565,1.7818939867597023,False,c1,3,"**Author:** `renukaalurkar`
**Description:**
1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page
2)Go to your user page.
3)Click on Languages/cog, select Input and click on Enable Input tools.
4)Click on Edit beta tab.
5)Click on More, and using Media, select a couple of pictures
6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu
7)Now start entering text in Hindi or Telugu.
Observations:
1)After typing a few letters, the cursor jumps back to the beginning of the sentence.
2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.
3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.
4)Click on Save page button
5)Now both the images are visible again.
Observed on Firefox 24.0 and Chrome 29.0.1547.66
--------------------------
**Version**: unspecified
**Severity**: normal",56283,11,Medium,False
6.1841826527202794,-4.595616387058616,3.9163460260834597,-1.2862683197107454,-2.5602547018794857,0.8726566036171597,-1.4917162966355564,1.913317778114799,1.4139008449212926,1.5980386704367424,-1.5268780089816745,-0.6954705133927496,0.461148024261969,-1.6032705038453359,-0.528174616820678,-0.08249042224456904,-0.4115055517010502,-0.8603049274649661,False,c1,3,"? should be ؟ icon
For Notification Tool for RTL languages Please change ""?"" icon in attached image to RTL icon
See @Amire80's comment. Not the same for all languages.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54252
**Attached**: {F11507}",56276,11,Medium,False
-4.338591655039776,0.5723118717164191,4.915356394217248,-2.4275674927243545,-1.3346206093172523,-1.2169146852024353,0.4288143810236713,-2.0318963658632407,2.168204318886631,-0.591089900566713,0.7260939323771689,-3.0777175427885712,1.277310754085724,-2.5863205832309384,-0.641945311925725,1.3792970332235996,-0.20806390370168226,0.3826551204433206,True,c1,3,"See
https://en.wikipedia.org/w/index.php?title=Fizeau_experiment&diff=573001070&oldid=572299847 - the user corrected a typo and this resulted in the references groups getting duplicated.
Reproduced in
https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=prev&oldid=573341379 and https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=next&oldid=573340833 while just testing wikilinks, as you can see. My first attempt to reproduce this actually resulted in more weird (although known, I think) behaviour: https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=prev&oldid=573176079 .
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",56265,11,Medium,False
2.598282921425326,4.501039535881478,9.768993351986154,-2.7777137680863833,-4.5964631891197065,3.295297739411671,-2.5218353615885225,1.7813155420466504,-3.387124850155103,-2.476320205045473,-1.3882948715015913,-2.1004044332490155,3.778717764129036,4.077541312958713,0.8638042954235088,2.360378158388183,-0.5826928959966647,-0.5128657432997676,False,c1,3,"Edit a page with One Two which displays as One Two. Select the entire text, copy, past at end of the string. Displays in VE fine at first. Saving however produces One TwoOneTwo which displays as One TwoOneTwo.
Originally from
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&curid=37904286&diff=573462315&oldid=573461696
--------------------------
**Version**: unspecified
**Severity**: normal",56262,11,Medium,False
-5.23126396319968,0.0708244944897718,-4.505810840662727,-0.9321102878292855,-0.48911349827671396,-1.2718077692192373,0.23789338220353518,1.7379278627271937,-2.8127197883201767,-1.3500008271534907,-1.4646794858310115,3.165631723839362,0.07145894429959299,-1.9039702622443313,0.5474788230590697,-1.3505236555648983,-1.7886944209765598,-0.7114263580671603,True,c1,3,"DKqwerty at en.wp reports: ""Article Futurama took 58 seconds to load into VE, with the loading bar running the entire time. I think this is unacceptable as it is probably off-putting to inexperienced users. Further, the bar just fills, empties, fills, empties, etc. rapidly and continuously until the page is loaded... Would it be possible to make this bar actually indicate what percentage has been loaded so editors have at least a hint that something is being processed?""
Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56225,11,Medium,False
4.647000318829523,0.9146493269526594,-2.217512708728149,-0.30064023478922564,-2.9389829161436403,0.8304851475677653,-0.6485644848794792,1.4728445151849239,-1.4478534335576325,-1.8735886781934226,1.351209034707257,0.5720886673377985,-1.5811627073024956,-0.6164829931199209,0.1788350142805477,-0.3327419965369556,1.1321740753587612,1.1836961725368387,False,c1,3,"Moving here the following proposals:
<https://strategy.wikimedia.org/wiki/Proposal:Text_or_Syntax_driven_Charts,_Diagrams,_Graphs_and_more>
<https://strategy.wikimedia.org/wiki/Proposal:Editable_Graphics>
<https://strategy.wikimedia.org/wiki/Proposal:Markup_for_charts_and_graphs>
(with some of the participants in cc).
* «By now Wikipedia has markup/code for everything—math (TeX), parser functions, location maps, and even SVG is supported. However, what is notably missing from many articles (other than high-quality portraits) are graphs and charts.»
* «There are many types of diagrams. The need for collaborative graphics is wide ranging, from map making to biochemical pathways to flow charts to genealogy to general charting. Each type of graphic has or could have a little language, XML or other representation to define graphics of that type succinctly. Whilst all can be presented as .pngs or .SVGs, the more succinct description is necessary for editability.»
This is distinct from bug 43616 (Provide a way to create interactive 2D/3D timelines and infographics e.g. Java applets, AJAX, Flash) in that it's not about *interactive* stuff and that there are some existing extensions which someone should assess and develop for Wikimedia purposes. I'd also leave maps out of it because that's being addressed (at last) elsewhere.
Part of it will be solved by bug 38271, but only to a degree.
Mentioned extensions: [[mw:Extension:Graph]], [[mw:Extension:GnuplotBasic]], [[mw:Extension:Plotters]], [[mw:Extension:WikiPlot]].
Keywords from the proposals: http://bloodgate.com/perl/graph/, Java .jar, Flash .swf, Silverlight .scr, ActiveX .ocx, Vector (.svg) .svg (XML), AnyWikiDraw, AnyWikiDraw, WikiPathways, WikiTex, Graph Plugin, DPL Bundle, TeX, gluplot, pgfplots.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56221,11,Medium,
-8.803996446407364,5.84849585533577,-0.8334095676530282,-4.293474350321431,-4.413721855219786,1.247669898744901,3.858293766852589,-0.8301726267437111,-1.8899139367284277,0.7165133047113201,1.3795794134651076,-1.0510145083703706,0.7313751725403108,1.935203755579253,0.23191939589427601,0.018285494483146647,-0.14230680862988376,1.7555045027801583,False,c1,3,"See https://github.com/mdevils/node-jscs
This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further.
I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",56218,11,Medium,False
18.388124372828806,-7.311157678154176,-9.924623522182099,1.326815048557242,-0.6246601608722199,1.8673300802491337,4.19750162607239,1.0016390605578112,1.437265685689071,-1.8123160447125937,-3.2968639670201156,-2.744678826652298,-3.6369524266580546,0.47841791554717705,1.3288725784685216,2.260971322522038,-1.1462129155474083,0.23425815347918744,False,c1,3,"e.g. fr -> Français, cy -> Cymraeg
--------------------------
**Version**: unspecified
**Severity**: enhancement",56086,10,Medium,False
-1.2276646720194169,2.7677281319956357,4.304432222213862,-0.2739334649693178,0.5685059572179629,2.007222252687896,0.09853276094384533,0.1814427957574783,3.684622070513935,-0.802752528091653,0.012807788175160706,-1.010999294229014,0.3373686391544206,-2.5129503609928405,1.6379182446736307,-3.7771944184955513,1.7644587612200107,0.051864415431482014,False,c1,3,"Around the time when VE started to support editing of pres we started to get dirty diffs like this:
http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387
This might either be a selser issue, or VE dirtying the DOM.
--------------------------
**Version**: unspecified
**Severity**: normal",56083,10,Medium,True
10.390587790560373,-1.7135600222608502,0.4713298203067424,-0.736227883500987,1.2138979641185625,1.7120242286600165,-1.5608413199401872,1.6651530115433832,-2.2186996642881756,-2.3089041771961014,0.2619551224791361,0.015958455937517657,-1.0716417018033022,-1.5314000387039743,-1.6934577215156277,0.8615562211995884,0.8797990094067016,-0.28955184852994065,True,c1,3,"For BLP's and disambiguation pages on the English Wikipedia, an extra edit notice is provided through the https://en.wikipedia.org/wiki/Wikipedia:EDITINTRO system using Extension:InputBox and some code in MediaWiki:Common.js. VisualEditor does not work with Extension:InputBox, so the edit notice is not displayed.
This hack is being used in several Wikimedia wikis besides the English Wikipedia:
* https://ja.wikipedia.org/wiki/MediaWiki:Common.js
* https://zh.wikipedia.org/wiki/MediaWiki:Common.js
* https://vi.wikipedia.org/wiki/MediaWiki:Common.js
See also [[https://www.wikidata.org/wiki/Q10566946| Template:BLP editintro (Q10566946)]] and [[https://www.wikidata.org/wiki/Q14400704| Template:Disambig editintro (Q14400704) ]] for more of the potentially affected wikis.
--------------------------
**Version**: unspecified
**Severity**: normal",56029,10,Medium,False
2.3769897222966994,-7.347989770663181,3.527470469479063,3.7592257489268075,-8.263296559433796,1.227943262682387,2.4026339416787286,-2.288854550535499,-0.45113959610750326,-2.4924644252622974,-3.566784491227054,-1.7829217949040506,-0.9173788756466505,2.5535000223615283,2.6538248502963073,1.7471728450543207,0.17451096839258362,0.16861347349342082,False,c1,3,"For example, onBeforePaste/onAfterPaste in ve.ce.Surface
--------------------------
**Version**: unspecified
**Severity**: enhancement",56000,10,Medium,
-8.783598133384885,6.062824825001474,-7.032971649960125,-3.5034319918371915,-2.4450422892696975,0.5521066502108387,0.463885905287559,7.341487518401226,-5.095062684853782,1.984988321909598,5.770342463309843,0.28118575867178164,-1.4868612207758103,-1.7667024735546648,1.0104373997135996,3.5962291855344053,1.7495667512659134,-1.565781122822413,True,c1,3,"<translate>…</translate> and the related <tvar>…</tvar> are currently un-parsed and shown as plain wikitext in VisualEditor because they're not recognised, per T50891; however, once that is fixed, the blocks won't be editable except as alien nodes (in wikitext), and won't be createable.
Making a proper VisualEditor plugin to translate these in-page as a rich editor shouldn't be particularly hard (he says…).",55974,10,Medium,
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c1,3,nan,55931,10,Medium,False
0.10810093286009481,-8.810266039032243,-2.6657361801047035,4.976094610213,-0.41176406251292036,-2.796194419289631,-5.01876185273129,-1.345301308118588,0.3977423726585936,0.7485405623539281,2.2798470843375926,0.692868559778635,-3.647213693333473,-0.1100766390590815,1.1050000448343003,-0.023344957186880677,-1.1311060911252437,-0.1255815636399551,False,c1,3,"== Steps ==
1) Go to
https://www.mediawiki.org/wiki/BUG?veaction=edit&uselang=en
2) Click on ""BETA""
== Actual result ==
There is the text ""Version false"" generated by the HTML:
<div>
<span class=""ve-init-mw-ViewPageTarget-version-label"">Version</span>
<a class=""ve-init-mw-ViewPageTarget-version-link""
target=""_blank""
href=""false"">false</a>
<span class=""ve-init-mw-ViewPageTarget-version-date""></span>
</div>
== Expected result ==
There should be some version number instead of the ""false"" text
--------------------------
**Version**: unspecified
**Severity**: normal",55917,9,Medium,False
-1.2860942223126006,-2.862342708735717,3.03383929785565,-1.1000983995819678,-0.0011718988919996454,-3.4258620965982027,0.5802207662140875,1.5965408137942645,0.10252326783015814,2.0613558962799496,-1.444478520496716,3.001517750413292,-0.09605334054355641,-1.101615003561312,-0.3839593713646572,-2.152530906034911,-0.9046839697800195,0.9037405147513244,False,c1,3,"Article tabs are wrong when page is protected via cascading from another page.
To reproduce: visit https://pl.wikipedia.org/wiki/Wikipedia:Strona_główna?uselang=en and behold the ""Edit source"" link, even if you're anonymus.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=11700",55893,9,Medium,False
9.577946808344905,-4.18014884388465,-1.8325601621180851,4.16156264584875,-1.9428603247960319,-5.06981181381747,-2.0989746568536396,-1.8806399612624713,-2.045662352798761,-2.332725199505598,-1.190937378845457,1.1294683873243805,7.054368298290893,6.353646125269233,2.9148609128131264,0.32707227381786425,-0.66692293908255,0.6732316170227233,False,c1,3,"I added role ""browsertests"", but every time I run `vagrant provision` it fails. It seems to be trying to install an ""ffi"" (foreign function interface) module.
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice): Using rake (10.1.0)
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice): Using builder (3.2.2)
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice): Installing ffi (1.9.0) with native extensions /usr/lib/ruby/1.9.1/rubygems/installer.rb:552:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice):
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice): /usr/bin/ruby1.9.1 extconf.rb
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice):
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice): Gem files will remain installed in /home/vagrant/.gem/ruby/1.9.1/gems/ffi-1.9.0 for inspection.
Fri Sep 06 20:26:53 +0000 2013 /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns (notice): Results logged to /home/vagrant/.gem/ruby/1.9.1/gems/ffi-1.9.0/ext/ffi_c/gem_make.out
gem_make.out has only:
/usr/bin/ruby1.9.1 extconf.rb
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69874",55864,9,Medium,False
4.050821328626352,-0.032315332945586306,1.730873451885806,2.980589425612899,0.5128101012594752,-1.5286244788346681,-1.4160297533499389,0.7671654711562811,-0.14421781661940664,-2.5966111630838884,-0.4307945177332213,0.6340864307786171,-0.30895537265067663,-1.8044298557143832,-0.43374771993769556,1.2563903314396994,-0.34756876147685833,-1.0298793314010528,False,c1,3,"System environment:
Win7 X64
Google Chrome 29.0.1547.62 m
Steps to reproduce:
Open a page
Edit it in VE
Copy-paste the following text:
a
b
c
d
e
Expected output:
a
b
c
d
e
Actual output:
abcde
The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases.
The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",55828,9,Medium,False
-0.5256345738320309,-0.1374625165966954,-4.450817284187842,-6.946313920963117,1.9592378089257059,5.194610723731401,4.609190249000165,0.679392160653727,2.3857675511263183,1.8032130924780603,1.3775315506223547,-0.7396718642722321,-2.181694718173497,0.9611177070207155,3.47211582589535,1.0671751844202366,2.056113337928223,0.9035653141075006,False,c1,3,"Extensions such as Math or SyntaxHighlight may require the inclusion of large(ish) JS libraries. It would be good if we didn't load these on every VE page load, but rather when these elements are present, or become present (e.g. I add a formula to a new document)
--------------------------
**Version**: unspecified
**Severity**: enhancement",55826,9,Medium,
-1.7983278406617431,-1.6061865867391507,0.23978830908344406,-5.042269188289751,-3.1490187624809134,-0.3318239756861727,0.8636810237808747,1.304204473552475,-1.8478251542472552,-2.760797533021304,-2.2415029761612164,4.957041331778434,1.3763064317598905,2.9815466561277146,0.42589988803534506,-0.699166746929907,-1.2956850158238475,-2.234175247423563,True,c1,3,"For special pages, no information about page existence is exposed to mw.config, which means that VisualEditor is forced to assume it exists regardless.
--------------------------
**Version**: 1.22.0
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66885",55774,9,Medium,False
-2.2844800888774293,0.7472411456791157,-3.0887825425467685,-1.0249799322205406,0.0873881195934676,-2.0816959810785347,-1.7123997155340511,-0.09530228411506284,1.7272521492109105,-2.004431312820317,0.26071760961866675,1.1822877494340196,-0.7665611197331286,-0.8758264052704794,-1.0186713458693832,-1.829370965263207,0.2699923444012853,-0.9453195798881924,False,c1,3,"**Author:** `kwwilliams`
**Description:**
When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.
VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",55767,9,Medium,False
11.130265845798345,-8.476893969311021,-7.900415752721283,0.015316119672942108,-0.1917653865554504,-2.6995369593752763,-11.51782598374674,3.1150816933892047,-7.1350184111244,-3.220994772104575,11.045253321763973,0.7407291227377251,-9.364687865327149,3.950536645365341,3.3714505193012725,-0.9623318328880524,0.7984037324798223,0.1941203589642322,False,c1,3,"1. Create '<p>Foo<cite>Bar</cite>Baz</p>'
2. Select Bar
3. Range is now [4,6] (correct as <cite/> becomes [<alien>,</alien>])
4. Bold the selection
5. Range is now [6,6] :(
--------------------------
**Version**: unspecified
**Severity**: normal",55766,9,Medium,True
-2.4521943363527487,-0.24548302399877642,-2.5208757599410205,-1.4203707226077238,0.9114020596949586,1.9427853096266932,-1.342276346656047,-0.577887286964843,-1.8267427513449086,3.411132382301922,-0.3159538993144957,-1.1379650438425202,0.29513925940163777,-1.3084487082063898,-0.8549844545696041,-0.5180561370450005,-0.6607469268469729,-0.0049916732395067775,False,c1,3,"[Please move this to a different component if applicable, I'm not sure where the editor comes from.]
It is impossible to insert the ""ę"" or ""Ę"" characters (latin letter ""e""/""E"" with ogonek) from keyboard when editing in Module: namespace with the code editor on the Polish Wikipedia.
""ę"" is inserted on the Polish keyboard using AltGr+e (aka Ctrl+Alt+e). If the editor uses this as a hotkey, it shouldn't (nor should it use any other Ctrl+Alt combinations).
(Reported at https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#VisualEditor_a_polskie_diakrytyki)
--------------------------
**Version**: unspecified
**Severity**: normal",55763,9,Medium,False
-2.381536956064908,3.9109390157348294,1.3713376045064543,3.327331493457109,-2.979890501061175,-1.3872323759930207,4.323667893027371,1.1050051480972871,-1.8049304787981517,1.533690291630096,2.4001203220973664,3.0189094745160263,1.8227748099139331,-1.532860857985861,-1.0299308340009299,-0.31345834505962045,0.7412375047449886,0.595288735922179,False,c1,3,"* This is language/script specific diacritic specific bug split from {T53472}
* For language Marathi Script Devanagari anuswara diacritic is ं
* If one types the anuswara diacritic ं after any devanagari script alphabet it is usually place above the concerned alphabet. For example क is a Marathi/Devanagari alphabet if I type क+ ं I get कं
* If I place cursor before the cluster कं and press delete then whole cluster gets deleted and that is right way to happen, and this behaviour needs to be retained (since if basic alphabet is not there then no need of anuswara diacritic ं) .
* Problem: In Visual Editor if I place cursor after the cluster e.g. after कं and press backspace current behaviour is the whole cluster gets deleted. Example कं + Backspace key = results in whole cluster getting deleted.
* Expected behaviour is: Cluster with anuswara diacritic (कं) + Backspace key = retain rest of cluster(retain क ) and only anuswara diacritic ं should get deleted.
* Reason: During spell correction many times we need to retain rest of the cluster and only change the diacritics. For anuswara ं diacritic spell change is required frequently for various reasons like change in singular-plural tense. Every time retyping the whole cluster is cumbersome. Traditional Source editing behaviour is proper and expected and problem is coming only with VisualEditor behaviour.
* For example please see this https://mr.wikipedia.org/w/index.php?title=कृष्ण_श्रीनिवास_अर्जुनवाडकर&diff=1198833&oldid=1198826 edit difference a user had to change this diacritic at several places.
Since users would be reluctant to use VE without correct behaviour, I would prefer this being treated as a bug not just enhancement and to have fair importance level.
--------------------------
**Version**: unspecified
**Severity**: normal",55754,9,Medium,False
-5.575011968934738,5.307190073115866,-1.7655566227039383,-5.371530727262451,-1.94097498966141,-5.554622693222043,0.4252642365009649,-3.15313890150614,2.043838344173989,1.0444481036042292,-0.3525275339401506,-0.3666415699781753,-0.4101204566114385,1.2518579979924773,-1.771144101649373,3.9592522533812544,-2.5532649858889815,0.013692516716433012,False,c1,3,"en.wp user Professor Hog reports:
""If you try and use beta to edit a page, but you've forgotten to log in, so you log in directly off the beta page, once you have successfully logged in it takes you back to the edit source page instead of the beta page. Minor, but thought you may want to correct it? ""
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52281",55746,9,Medium,False
-4.474552785942788,-3.2724411822570048,-3.7110441779487324,-3.686741092267543,1.11469251979419,-3.01993017113013,2.4780664136497608,-3.7086578029913473,-2.267597868488437,-1.0462951313116662,0.08186016500310345,0.9276659683713742,0.43423797125276664,-1.5306311247271998,-1.1207443397354524,-0.7182420075119158,-1.5002395119697838,-1.0915497779237409,False,c1,3,"**Author:** `rachelqa99`
**Description:**
shows error message
I got this message when running a test automation script, that puts in a line of code and tries to save it. It doesn't recognize the new line of code I put in, so it gives this error message upon save. Not sure if you are aware of this particular scenario, which is why I am submitting it.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11191}",55721,9,Medium,False
0.7775287320338911,2.8531529793287547,4.256609764253756,6.065292740572987,-1.350779552217233,-2.1447400052548558,0.6588792238837113,0.5469140243105145,-2.2123633129793294,-2.184270318267456,0.30491953419015116,-1.1367321159019415,1.018078703056036,0.9098755027329695,1.1076497404943844,-0.483692742304887,2.499629623141841,-0.46921974560479174,False,c1,3,"The ULS input methods (jquery.ime) currently do not work with the popup windows of VE. These include the template, reference, reflist, image, link and page settings popups.
The problem has been tested by me on Win7 X64 with Google Chrome 29.0.1547.62 m and possibly by others on other browsers. The problem was originally reported on [1] by mr-wp users.
[1]: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE_.2B_ULS_unicode_Devnagari_Script_input_issues
--------------------------
**Version**: unspecified
**Severity**: normal",55717,9,Medium,False
-2.6757789287382447,1.363227301368445,0.9403514250666944,5.468936185909675,0.3951997825294745,1.7036005192238683,-0.3421285441548312,1.1762825292231076,0.5820688179817958,-0.734955516241965,1.456548626495207,-0.8600918765866634,1.4168467114061603,-0.21189318158225134,-0.827045583340607,0.8226374059685488,-0.3018854294912159,0.4842244968089664,False,c1,3,"System environment:
Win 7 X64
Google Chrome 29.0.1547.62 m
Steps to reproduce:
Open a blank page
Edit it in VE
Either use google input tools for hindi or enable ULS hindi transliteration
Input:
Select bullet formatting from the VE toolbar
agar[SPACE]main[SPACE]
Expected output:
with ULS: अगर[SPACE]मैन[SPACE]
with Google input tools (depends on translation history, macros etc and may differ user-to-user): अगर[SPACE]मैं[SPACE]
Actual output:
Text output is same as expected. However, the text is partially non-navigable, ie pressing the left arrow key from the end of the text takes the caret to the beginning, and then left/right arrow key presses have no effect on the caret. Simultaneously, if the text is navigated by specifically placing the caret at a particular point using the mouse, the value shown for the formatting dropdown in the toolbar may go blank at one point in the text and become paragraph at the next.
The text is also irremovable ie bug 53708
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53708",55711,9,Medium,False
0.3341645155062656,1.2113094754397569,0.7063123015434272,1.5704573326271607,1.707258290433212,1.7469223015572213,-1.1634275066123942,-0.06079119630604485,-2.299048567335933,-1.4972921416764704,2.3519300858535703,0.6999623499847889,0.7672719328849475,0.4158370765637045,-0.6748977492043213,-0.6137462293745966,-0.49111543295113924,-0.47341880693786353,False,c1,3,"Screenshot of incorrect text placement
System environment:
Win 7 X64
Google Chrome 29.0.1547.62 m
Steps to reproduce:
Open a blank page
Edit it in VE
Enable ULS IME hindi transliteration
Input:
[ENTER/RETURN KEY]x2 (two newlines)
agar[SPACE]ma
Expected output:
[NEWLINE]x2 (two newlines)
अगर[SPACE]म
Actual output:
[NEWLINE]x2 (two newlines)
अग[NEWLINE]र[SPACE]म
Once [ENTER/RETURN KEY]x2 followed by agar[SPACE] has been pressed, Bug 53706 shows up. If one continues the input, this bug is what happens. The incorrect placement is accompanied by the following incorrect bahaviours:
The VE toolbar shows no format (while the editing had been begun with paragraph)
Cursor movement is incorrect. When the cursor is at the end, pressing up key takes it to the end of the first line, then pressing the down key takes it in the second line after the [SPACE] and before म It is here that the incorrect behaviour occurs. Pressing either the left or the right arrow keys takes it to the end of the line (ie after म) While this should happen on right arrow key press, the left arrow key press should take the cursor(caret) to before the space.
Also, when at the end of the second line, pressing backspace does nothing. Similarly pressing delete anywhere in the second line does nothing. The second line effectively becomes irremovable, while the first line can be removed.
Note: Page used for this test is [[:w:hi:सदस्य:Siddhartha Ghai/sandbox]]
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53711
**Attached**: {F11165}",55708,9,Medium,False
0.5262019414401498,-0.12144561570370271,-2.751755324282378,-3.023516162654368,0.5449141142419844,0.29131295428389525,-1.3706694957614554,0.16221265509748867,1.7388266781731592,-1.7852778435679322,-0.341878492762679,0.23384045202617743,2.4991515512543163,1.3667650765812756,0.19129319555211488,-0.20444666712911375,-0.31162485216384805,0.5233786501572701,False,c1,3,"System environment:
Win 7 X64
Google Chrome 29.0.1547.62 m
Steps to reproduce:
Open a blank page
Edit it in VE
Let the API call for the parsed json output fail
VE asks if you would like to retry, press Cancel
Expected behaviour:
VE should reset the opacity for the title and sitesub back to 1 from 0.6
Actual behaviour:
Opacity is not changed, leaving it 0.6 although the user is effectively reading the article, not editing it with VE
--------------------------
**Version**: unspecified
**Severity**: normal",55707,9,Medium,False
6.0396259507972125,-2.094906356716068,1.8590634145806462,-0.26445517967045373,2.4527034071709517,0.0534706072862392,-2.310635926553731,0.8425359467320016,0.17208753595492676,-1.9180028294787377,2.9735885798583435,0.5919772195076187,-0.12516850902942256,1.3378234912802585,0.6194569508586394,-0.19614641214397233,-0.19166936033173254,0.07038927487216395,False,c1,3,"Screenshot of selection error
System environment:
Win 7 X64
Google Chrome 29.0.1547.62 m
Steps to reproduce:
Open a blank page
Edit it in VE
Enable ULS IME hindi transliteration
Input:
[RETURN/ENTER KEY]x4 (four newlines)
agar[SPACE]
Expected output:
[NEWLINE]x4 (four newlines)
अगर[SPACE]
no text selection should be there
Actual output:
[NEWLINE]x4 (four newlines)
अगर[SPACE]
the ending [SPACE] is selected with a newline. Also, the toolbar shows that VE has somehow jumped to changing the formatting to bulleted and numbered list from the original paragraph formatting.
Further, pressing a backspace deletes not only the selected space/newline, but also the typed text अगर. I think this is Bug 53705 though I may be wrong.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53700
**Attached**: {F11150}",55706,9,Medium,False
2.9014297895871715,-1.8171973991763277,-2.771413739982231,0.09327183813069229,0.20205062102629234,1.0911727923406447,-1.5026428265229779,2.1247562726137716,-2.728144425821492,-1.3575717260343292,3.382718173350655,1.4265407242446664,0.7938831016931851,0.5209736858495582,0.3393959836634304,0.019081259648378757,-0.8367913657551018,-1.3396006040374124,False,c1,3,"System environment:
Win 7 X64
Google Chrome 29.0.1547.62 m
Steps to reproduce:
Open a blank page
Edit it in VE
Enable ULS IME hindi transliteration
Input 1:
agar[SPACE][ENTER/RETURN KEY]
Input 2:
kyaa[SPACE]
Expected output 1:
अगर[SPACE][NEWLINE]
Expected output 2:
क्या[SPACE]
Actual output 1:
[NEWLINE]
Actual output 2:
[SPACE]
For the first case, when the given characters are typed, everything is fine upto the pressing of the return key, ie agar[SPACE] gives अगर[SPACE] as expected. However, as soon as the return key is pressed the entire text disappears leaving only a newline.
For the second case, everything is fine till [SPACE] is pressed.
If the page is not blank, extreme weirdness occurs, which can only be explained with further bugs (which I'm about to file). In short though, the disappearances persist, along with other buggy effects.
Note: Page used for this test is [[:w:hi:सदस्य:Siddhartha Ghai/sandbox]]
--------------------------
**Version**: unspecified
**Severity**: normal",55705,9,Medium,False
6.800953230576228,5.133195049488439,1.3866046360203086,1.0470478243525485,-7.672267641600758,-2.275666482138681,3.4418672076410237,1.1180478367714652,-1.4299089236223919,-0.353450673386007,0.23376659732127347,1.203181312998873,-1.469188120096347,-0.7594544234784077,-0.3119790768074706,-0.03534199673182731,-0.6393238702464487,1.951942387794961,False,c1,3,"*VisualEditor+ULS Method of input = अक्षरांतरण language=Marathi
Script=Devanagari (Non-VE source edit environ,ULS Method of input = अक्षरांतरण
works normal
*Tested Browser and OS =Firefox+Win7
*Problem description =In normal speed typing,after we type first alphaabate cursor moves from right to left direction.Word marathi need to apear मराठी with VE+ULS instead is coming राठीम
**additional details = Marathi language devanagari is written in left to right direction.But when we use ULS Method of input = अक्षरांतरण with VE cursor is moving in opposite direction after typing first charecter as if we are typing a right to left script after typing first charecter and then again moves left to right
*Screenshot will be added
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49569",55701,9,Medium,False
7.5277366180211995,0.9300990332700749,3.2833504947507883,5.257860229057612,0.5975971528108874,-3.2214506988334897,2.628620148469646,-0.15597789397644315,0.9778696626275427,-0.032934434625293996,1.112815667817372,0.21876695899257337,-0.44686488255974943,-0.2542765525724153,-1.8283962249040142,0.6005894049853748,1.4598119292081642,0.7432006350224547,False,c1,3,"*VisualEditor+ULS Method of input = अक्षरांतरण language=Marathi Script=Devanagari (Non-VE source edit environ,ULS Method of input = अक्षरांतरण works normal
*Tested Browser and OS =Firefox+Win7
*Problem description = No other text on a page> Type a word + space bar = eliminates typed text imidiately
**additional details = If some text is already there on the page or we copy paste then we can give the space bar with less frequency of this problem.
*Screen shot or Difference of edit if available = Can not create the screen shot/or edit diff
Thanks and Regards
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49569
https://bugzilla.wikimedia.org/show_bug.cgi?id=53706",55700,9,Medium,False
2.4525752013282136,0.014485678497990762,0.16882473524332653,0.9280080878517531,2.939781708593147,-0.22702479622361826,-3.92646337032932,0.9331947288155532,-3.021325887110587,4.780736976144366,-2.5804733978738543,1.6977623427401614,2.316748726117231,-0.049876823314153995,0.5996046876517331,0.6561570915485728,0.5011778491241734,3.2005626588053966,False,c1,3,"A user reported a problem to use the ""clear formatting"" shortcut with a french AZERTY keyboard. The shortcut is ""Ctrl + \"", but ""\"" is only accessible as ""AltGr + 8"".
First, even with, ""Ctrl + AltGr + 8"", the shortcut doesn't work. I was unable to find a keyboard combination that triggers the ""clear formatting"" shortcut. When using a classic QWERTY keyboard, ""Ctrl + \"" works on the same computer/browser.
See https://bugzilla.wikimedia.org/show_bug.cgi?id=51507
But, when testing, I noticed an other problem, with a behaviour depending on OS/browser when using ""Ctrl + AltGr + 8"" with text selected:
* On W7 + Chrome 29, the selected text is replaced by ""\"", but VE doesn't see any modification: save is disabled, undo is disabled, ...
* On W7 + Firefox 23, the selected text is replaced by ""\"", and VE sees that text has been modified
* On Ubuntu 12.04 LTS + Firefox 20, a user report that all page is selected.
Same kind of problems happen with ""Ctrl + Alt + 8"", ""Alt + 8"", ... or other digits.
https://fr.wikipedia.org/w/index.php?title=Wikipédia:ÉditeurVisuel/Avis#Raccourci_clavier_pour_effacer_la_mise_en_forme
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51507",55682,9,Medium,False
-8.188627395127755,1.4718718946460712,-2.251091164558341,0.3998361271039641,1.9931337679164138,-1.4957366057850299,3.8978521351497255,1.4488603314064803,-4.188373471791438,-0.1934126547035513,-0.41392083034562965,0.7685688704644,-0.5115280290838102,-0.574274150171755,-0.19942026277358416,1.6402518505749368,-2.2808337313087623,-1.6726428646855607,False,c1,3,"At https://en.wikipedia.org/w/index.php?title=Flight_endurance_record&oldid=571122193#Free_Balloon.2C_Manned the table begins with an empty row where there would normally be a header:
{|class=""wikitable""
|-
|-
|content
In view mode this empty line is not shown, but it does appear in VE.
Testing at https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=571124234#Tables_with_empty_rows shows that the same thing happens, wherever the blank line is in the table. Oddly though the line is shown at full height when its in last position but ~half height elsewhere.
In itself this isn't a problem, it's just different to what happens in view mode where the second |- is ignored.
--------------------------
**Version**: unspecified
**Severity**: minor",55665,8,Medium,False
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",55612,8,Medium,False
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",55611,8,Medium,False
0.6885189412695016,-16.777936138457765,-2.4478311504948067,0.9043307314391582,-1.9012244827990963,2.513897894757428,2.1396736646625625,-1.7750720679462444,1.0172371401266918,-1.5751644097825235,-2.270828888045429,-0.7573643459537795,-1.4739151421606902,-0.25519456826633835,-0.3278118989675365,-0.25432301057242124,0.10100572752280246,-0.2052124178597725,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: minor",55610,8,Medium,True
6.719253215996485,-2.724496868760104,-3.9844142622020335,-4.671667444551518,-1.6336790635214573,1.0413025164995469,-1.9463164417100982,5.361472133647283,-1.4272010765045242,-2.57345292142292,-1.4482272753646388,-1.0961404967037272,0.17079135485623365,-2.283130667497251,2.4502936445574237,0.6002698476684205,1.293210012818357,-3.1910534270480095,True,c1,3,"[Now tracked as #VisualEditor-MediaWiki-Templates instead.]
Fork from bug 49833, which wasn't meant to be used this way.
--------------------------
**Version**: unspecified
**Severity**: normal",55604,8,Medium,False
-4.486448383728057,3.026267342788941,0.24972247326395092,2.00159589044342,-7.268630421819685,1.2642355741565166,-1.5422401129356578,-0.10693309250500113,-1.6364047595527857,-1.223228651694583,-1.0606237623325594,2.622111991810101,-1.2415922700752855,-1.3571954850704264,-0.1601782718624536,-1.0963103942587664,-0.6386995457765086,-0.80722790047923,False,c1,3,"Gadget checkboxes should be able to be grayed out (inaccessible) dependent on if another gadget is on or off, if other extensions exist that gadgets are unable to use, or if they require a specific skin to work. For example, on en.wikipedia the current ""Editing"" section of the gadget tab on the preferences page looks like:
[[ https://commons.wikimedia.org/wiki/File:Special_Preferences_mw-prefsection-gadgets_(current).png | commons:File:Special_Preferences_mw-prefsection-gadgets_(current).png ]]
There should be a way to gray out functions, like:
[[ https://commons.wikimedia.org/wiki/File:Special_Preferences_mw-prefsection-gadgets_(proposed).png | commons:File:Special_Preferences_mw-prefsection-gadgets_(proposed).png ]]
If (in this instance) VisualEditor is enabled.",55584,8,Medium,
1.8600563956616605,1.5421236430413945,-1.9814007127180258,-7.573175778126775,-2.4640874489657154,2.8914427995495293,1.3853693256960904,-2.2890566421414964,-2.485791369997817,0.061385723976863815,0.7760150537036155,2.981990819874107,0.8658105506154401,-0.20239806995364873,-2.0392405986139446,-0.12788449963140153,0.40852827080445286,-0.10841058990075036,True,c1,3,"https://fr.wikipedia.org/w/index.php?title=Polisy&veaction=edit
or
https://fr.wikipedia.org/w/index.php?title=Aix-en-Othe&veaction=edit
The demographic histogram gets duplicated while VEditing, although everything will be fine again once you save, but I see this can confuse users.
Looks like it is generated, like other parts of the Démographie section, by https://fr.wikipedia.org/wiki/Mod%C3%A8le:Section_d%C3%A9mographie_d%27article_de_commune_de_France .
--------------------------
**Version**: unspecified
**Severity**: normal",55583,8,Medium,False
6.965850553013201,-0.04498690344497369,0.5711340408472338,3.151656184844552,-0.6132253954152346,-1.0044462154896245,-1.920726973638721,-0.4899729529191481,-1.92605609245405,1.466738576003407,-2.6532341843885345,0.5680952357318485,0.8438931456689232,1.2229733908762945,-1.1278152611831596,0.47591405649073115,1.5393440725728318,0.9246646486566312,False,c1,3,"Have seen multiple instances of this one backing up on commonswiki slaves recently:
SELECT /* IndexPager::buildQueryInfo (LogPager) 148.160.132.46 */ log_id,log_type,log_action,log_timestamp,log_user,log_user_text,log_namespace,log_title,log_comment,log_params,log_deleted,user_id,user_name,user_editcount,ts_tags FROM `logging` FORCE INDEX (times) LEFT JOIN `user` ON ((log_user=user_id)) LEFT JOIN `tag_summary` ON ((ts_log_id=log_id)) WHERE (log_action != 'revision') AND (log_type != 'suppress') AND log_type IN ('delete','move') AND log_namespace = '0' AND log_title = '0' AND ((log_deleted & 1) = 0) ORDER BY log_timestamp DESC LIMIT 11
It runs in excess of 10 minutes.
EXPLAIN says the FORCE INDEX sends MySQL onto a very slow index scan over `times` (log_timestamp) which is hardly better than a table scan in this case.
Removing the FORCE allows `page_time` index be used which reduces execution time to a few seconds.
Suggest either filtering by a range on log_timestamp or removing the FORCE.
--------------------------
**Version**: 1.23.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54122",55577,8,Medium,False
3.4549178762336203,0.7859068473477784,4.516232284385222,-2.6832238016374506,1.6034516860380927,3.239351814682945,-3.580487426576998,-0.5995971930349444,1.3061747157077745,-0.15538122623993988,0.10749608540779798,-1.8123678581168463,2.416079484332073,0.5220375057185427,1.1815923772577959,-0.5466581605363615,-0.15241789220093405,2.1747385883364094,False,c1,3,"Attachment 1
Visual Editor became quite unusable (possibly) after a recent update in Malayalam Wikipedia. There are several selection, editing and linking problems started to appear recently. Two such problems are described here.
See the example below
1. Copy the following text and paste it in a test page at Malayalam Wikipedia using conventional editor and save it.
ഈ ദുരന്തം ഐറിഷ് രാജ്യാതിർത്തി
2. Edit the page using VE.
3. Change the third word ""ഐറിഷ്"" to ""അയർലൻഡ്"". To do that, select the word ""ഐറിഷ്"" by double clicking on it and type the word അയർലൻഡ്.
4. Now I want to create a wikilink for അയർലൻഡ്. For that, I used shift+ctrl+left arrow. Now, instead of selecting the entire word, A PORTION OF THE WORD WAS SELECTED. See the attachment 1.
5. Select the entire word അയർലൻഡ് using double clicking on it
6. Press ctrl+k. Now instead of popping up a linking suggestion for the word അയർലൻഡ്, THE WORD DISAPPEARED AND LINKING SUGGESTION FOR A PART OF NEXT WORD POPS UP. See the attachment 2
--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Linux
**Platform**: PC
**Attached**: {F11751}",55572,8,Medium,True
-3.8043576441877778,2.7560618686906864,-6.354736977823091,-1.5053644088139837,2.2573893269672887,-0.1142316501701447,-5.988625245062721,2.9253655614033813,-1.6352108152369444,-1.8494285370410224,3.607076942046549,-2.6402939143344346,-5.717403182806852,0.030410504478286526,0.8416685468065737,-1.8228491982875932,-1.947756090881148,1.6700240251043976,False,c1,3,"When editing a document that contains:
* Foo
* Bar
* Baz
Adding an attribute to one of the list items in VE doesn't roundtrip (they serialise back to * instead of forcing <ul><li>..</ul>, as it will have to).
Right now VisualEditor never does this, but earlier today I was experimenting with this (the language inspector might need to do this to properly flip the directionality of an individual list item, wrapping the inner content is not an option as then the number would be on the wrong side).
When trying to reproduce this I noticed that it also happens when creating a new document (e.g. there is no existing page, it has no reason to force ""*"" instead of ""<li>"" other than that being the preferred default for wikitext).
http://parsoid.wmflabs.org/_html/:
In:
<div dir=""ltr"">
<ul>
<li>a
<li lang=""he"" dir=""rtl"">b
<li>c
</ul>
</div>
Out:
<div dir=""ltr"">
* a
* b
* c
</div>
The only case where Parsoid kept the attributes is when not editing a document with wikitext, and not creating a new document, but when editing an existing document with ""<li>"" in wikitext already, it did roundtrip those.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68800",55568,8,Medium,
-0.49703457948162777,8.50183808201405,2.7847403929285086,-0.9096256126107719,0.9955087727314571,-1.1683114386758995,1.4355489413334643,-4.929285382570517,-2.0842345001111773,1.1534969656668421,1.8806604780882306,-1.0145460938961977,0.8898487401688171,0.2424879666436235,0.5424540267306828,1.892313411395577,2.3979299113574974,1.4434258507827142,True,c1,3,"MyOnlyEye says, ""When I write long articles in VisualEditor the whole screen scolls - and the VisualEditor toolbar is scrolling upward and out of the screen. If I want to make a headline or instert a picture I'll have to scroll up to the top to reach the toolbar. I've tried it in the lastest edition of Firefox and Chrome in Win8 - on my own mediawiki with visualeditor and Wikipedia and Mediawiki....On every page that is longer than the screen - e.g. http://en.wikipedia.org/wiki/Electron?veaction=edit
I've tested a bit (after I wrote the feedback) and it seems to be OK on my Win7 and Linux-box (chrome and firefox, both in 64-bit), but it's not working on Win8 (32-bit). Both the lastest 32-bit edition of Chrome and Firefox have the ""scrolling error"" on my Acer W510 Win8-laptop in desktop-mode (and in tile-mode :-)....I tried the electron-article and updated my own wiki (with git pull on mediawiki developer and visualeditor). I tried it in Firefox and Chrome (latest 32-bits editions)....I've installed a virtualbox with Win8 (32-bit, same as my Acer W510) and ran some wiki-pages with visualeditor in Chrome. No problem with the toolbar. So there seems to be two options left - 1) it's the intel screen driver (Intel HD 9.14.3.1102) or 2) it's how the browsers behave in a touch screen environment. My W510 has touch screen, the virtualbox Win8 hasn't....
I've tested it on another Win8-machine (ASUS VivoBook S400 14"" HD touch) with different hardware than Acer W510 _but_ with a touch screen - and... the toolbox/-bar scrolled out of the screen. So my guess is that this is something that happens when the browser knows that the user can scroll the webpage with the fingers.""
It is apparently not quite the same as https://bugzilla.wikimedia.org/show_bug.cgi?id=52504
--------------------------
**Version**: unspecified
**Severity**: normal",55550,8,Medium,False
-8.37787400186989,3.658062618840326,-2.107159875010616,0.3022177706440483,2.86940178651539,0.9826017996977361,1.5485027441338337,1.018708675197323,-1.0203054520654864,-1.1435121761406495,0.29547574598591897,-2.7356359608190433,0.8695195250661576,-2.7712401559748376,0.647236375431584,-0.38881896135942084,0.03186456895082457,-1.0867310461320026,True,c1,3,"I am filing a related common problem we meet at it.wp.
We had troubles with nowikis being thrown right after some templates when the
user did not add an extra space there, but simply edited something in that
page. See
https://it.wikipedia.org/w/index.php?title=Wikipedia&diff=61171396&oldid=61171228
.
We actually found a workaround for this:
https://it.wikipedia.org/w/index.php?title=Template:Quote&curid=224372&diff=61173726&oldid=60749506
but since this addition is apparently a nonsense, users demand that VE prevents
that behaviour instead.
They also think this is related to templates featuring some kind of table.
I did some tests as well.
I was able to reproduce an unwanted situation where the first line and the
table (which is actually a template) were mingled in a non-editable block
https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=61181542&oldid=61181524
.
But I was also able to avoid nowikis, even if the extra span tags were not
added to the template: as you can see here
https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Sandbox_VE&diff=prev&oldid=61181473,
if the first letter of the line is actually closer to the template's final
brace (with no space between), VEditing that page will result in the text
getting automatically placed in a better position, and no nowikis in sight,
even after multiple saves of the page.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",55548,8,Medium,
-3.8144817521644723,-2.6648116480226527,-7.584807187687337,-1.868623511489183,1.2121207285500475,0.6033939065723608,-1.719216940724741,0.6685772601387996,0.22852883262859836,-2.187700584536197,0.7880514835735513,1.9332901023875009,0.42965820620053297,-2.0046809140793935,-1.1676862766053429,1.2215726723290585,-0.6805061516518592,0.20899379286387076,False,c1,3,"Templates that are inserted to a page in RTL appear first floating on the right side, then only after save and re-edit they appear correctly.
Replicate:
1. Go to hewiki (or any other rtl wiki)
2. Add a template - for instance {{עליות}} which is supposed to be floated left - yet it is inserted floating right.
3. Save the page. Edit it again -- the template floats in the correct direction.
--------------------------
**Version**: unspecified
**Severity**: normal",55544,8,Medium,False
-0.3833720899927595,2.29655088634766,0.19896574792998578,0.12531344371356945,-6.467321601379789,-1.1410094216856541,-5.191783582217027,-1.451825599971094,-1.4777386750650323,0.7694345808382979,0.48868761698974117,-0.9795042371546698,-0.9100164207159596,0.3818647554286114,-1.4807170343857994,0.4151061999684647,-0.020823886597786334,-0.21458075955627764,False,c1,3,"**Author:** `p.selitskas`
**Description:**
Entries in Page settings / Languages don't have dir attributes for the link text. It leads to bidi issues for RTL languages.
Reproducing:
1. Go to an article with a langlink to Hebrew, for instance. Here's my favourite: [[en:August 3]].
2. Open the VisualEditor.
3. Go to Page settings / Languages and scroll down to 'he'.
4. Link text reads as ""3 באוגוסט"", but it should read with ""3"" after Hebrew characters (reading left-to-right, of course; in the beginning of the string, if right-to-left).
--------------------------
**Version**: unspecified
**Severity**: normal",55503,8,Medium,True
6.906936239504054,-9.528812905698508,9.925571261450628,-0.2295034092255105,-2.160522344416097,-2.3881272241162588,-0.11553991566014066,1.910468444618659,2.6046681378718084,-0.6621811329292528,0.09002319279650184,0.16150395070526846,3.3714748555508187,1.6788671406659859,0.791838258093386,4.0069379015617885,1.2389086821335151,2.033710653093377,False,c1,3,"See numbers 49 and 50 in https://pl.wikipedia.org/w/index.php?title=Biurokracja&oldid=37367869 and https://pl.wikipedia.org/w/index.php?title=Biurokracja&oldid=37367869&veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51289
https://bugzilla.wikimedia.org/show_bug.cgi?id=52300",55486,8,Medium,True
-6.979257439163489,1.6529004069449904,-3.623342023152766,1.5051388121883407,-5.022427662593945,-0.4290260300626857,-0.5628351079233207,2.247604632935489,-2.857414070073247,-2.8491812279160493,-0.8982602364370211,1.2070357231142184,0.4298609837245113,2.5202550190820423,0.18480523037186813,-0.6619705353500209,1.2714953341833135,-0.13928564320303782,False,c1,3,"The transclusion editor should not allow (or at least should warn about) template parameters with unmet dependencies.
For example in [[template:For]] parameter 4 has no effect unless parameter 3 is also specified, so the transclusion editor should not allow/warn about template 4 without an accompanying parameter 3. (parameter 3 is otherwise optional and can be present without parameter 4).
In at least some cite templates, parameter author2 requires the existence of author1, etc.
I'm fairly sure that this functionality depends on bug 50407, which requests that TemplateData allows dependency relationships like this to be defined.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55469,8,Medium,
0.0648876346281031,1.406662535739871,0.06827271071514218,-5.526266460948693,-0.017364598559118094,-8.033137696340141,2.3887490657644905,4.963025138931851,1.0729066780464578,-1.2923926925154632,-0.5437250171201384,-1.6200592269778222,0.49472747803085815,-1.2563441652437715,-0.4778284218192619,-0.7210215443750299,-2.86108954408754,-1.2781843772705739,True,c1,3,"Redlinks right now always take you into wikitext editor, regardless of what editor is primary on your wiki.
--------------------------
**See Also**:
{T54162}
{T54281}",55441,8,Medium,False
1.059378397320263,1.1389527052997828,-0.3179511505117212,1.3929636683072797,-2.074536839682482,2.273135915270787,-2.53232278293727,0.16460256309698018,0.3312597547148113,-0.7464580988117238,1.3129222924125021,-1.0502474057196847,1.0027725656415547,-0.3198987480662083,0.30950678540446663,2.412395450411585,1.481119653117778,1.1467938953738763,False,c1,3,"**Author:** `p.selitskas`
**Description:**
Reproducing:
1. Open the VisualEditor
2. Put the cursor in a place where ""Paragraph"" (or whatever else) disappears. (For example, into the ugly and unbearable empty line in pages with infobox at the very beginning.) The content editor must be kept active and cursor blinking.
3. Scroll it down a bit.
4. Press Ctrl, Alt, or Shift, or every possible combination of these
5. See the content editor scroll up step by step (or as many steps per time as many keys are in combination.
I can reproduce this in Chrome 29.0.1547.57 and Firefox 23.0.1 on Windows.
--------------------------
**Version**: unspecified
**Severity**: minor",55420,8,Medium,False
-6.0856597097183815,-3.5812295735781223,-4.989210878946439,-0.637653886133577,1.986633036732334,-0.6926121571345882,-1.7051269430665599,-1.2025553157971103,-0.13262638217609574,1.2050696668268897,-1.5320401834572057,-1.1681495570407878,1.78573533825777,-1.4014950919200126,0.3796094560845473,-1.4469025724421498,-1.8415107673458315,-2.1170818534192626,False,c1,3,"en.wp user Risker reports from an editathon that of the participants:
""not a one of them understood what the ""puzzle piece"" was supposed to represent, and when shown, all of them still thought it was a poorly chosen icon. Most had no suggestion as to an alternative, although two thought ""curly brackets"" would be a good idea. I suspect that's because they'd seen curly brackets for templates when using wikitext.""
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51372",55396,8,Medium,
-0.5973495601976606,-1.4614282980258064,3.659236707105677,2.630387408317308,5.948325602911446,-0.34599910977369874,2.1517680787229496,0.5617442909731815,0.41792536885280873,-0.5583551337335111,-0.414710733375645,-0.6452216863521899,-0.3557577911191503,-3.0445573954705427,2.5089915236896028,-0.4300772416401011,2.5590656623567245,-1.2814978042647427,False,c1,3,"This is probably an occurrence of an existing bug, but I couldn't find one that really fitted.
In these edits, the table header was duplicated several times:
https://fr.wikipedia.org/w/index.php?title=CM_Punk&diff=95906046&oldid=95898800
https://fr.wikipedia.org/w/index.php?title=CM_Punk&diff=95848040&oldid=95838194
https://fr.wikipedia.org/w/index.php?title=CM_Punk&diff=95778036&oldid=95766921
--------------------------
**Version**: unspecified
**Severity**: normal",55394,8,Medium,False
0.33397333084754033,3.6315992417214638,-3.8669939613630024,-1.599140863332077,3.3133135071459874,3.5103926857799426,-0.4077968981742517,4.767041183477935,-2.2865529960689184,-2.0944062554312124,1.6521600720753384,-3.5460409867274363,-2.566463092016769,0.9825282933938446,0.9550843898110113,2.8635883410908356,-1.9836427856148706,0.3958248416444896,True,c1,3,"Right now the CommandRegistry only takes a single command that can be used as a keybinding for a tool on a given platform (i.e. Mac, PC, etc.); it's thus not possible to have two keyboard shortcuts for the same tool, such as Undo (where both Ctrl+Y and Ctrl+Shift+Z are commonly used).
--------------------------
**Version**: unspecified
**Severity**: enhancement",55356,8,Medium,False
-5.325433655839535,-1.2560981832958173,-3.3763607596444825,1.2750258054291939,-3.9762853228587307,3.2455850308740484,0.024764059110533587,2.4186700804672934,-3.510735264751834,0.04186048147911414,4.762371310358507,1.4777040058808064,-0.6708235397536164,-1.2208218580313863,-1.5927141675505974,2.1716105279066165,1.6230073682097441,1.810275868897777,False,c1,3,"VE allows to mark text as both superscripted and subscripted (<sup><sub>text</sub></sup> or the other way). That sounds like a bad idea; such text simply ends up being displayed in smaller font.
--------------------------
**Version**: unspecified
**Severity**: normal",55330,7,Medium,False
-0.13854478683037064,-5.711117410170628,7.696995465729799,7.080648819819698,-5.634419848611726,-5.670830775363048,1.3990599708831368,-4.982322660087913,-0.90866494334998,-3.1835733543521583,-1.2861864967065622,-0.3248058719564719,-0.17470405652153076,0.4913345137291829,0.3780162603701802,-2.385451198624836,0.3149325906787672,6.919019508419669,False,c1,3,"We need ULS support in dialog boxes-
1) Template dialog boxes - adding existing template for setting paratmeters
2) Image dialog box
3) Adding or editing references
--------------------------
**Version**: unspecified
**Severity**: enhancement",55324,7,Medium,False
-7.402265571254313,5.09954047068301,-2.372647162288837,-3.6496840623854503,3.4008633681976947,-2.2515690864783897,-1.1642517994581594,-0.2976833635801895,0.8134650320363934,0.17362434614687494,-0.851892181456217,-2.449086256124909,0.15714529548137346,0.9427616862284296,-0.6969263400446337,0.051196397777140745,-0.9594148674324614,0.46928399503877904,False,c1,3,"reported on en.wp by Atethnekos:
""So I put a space and then a backspace. Go to save, review changes to check and make sure it is a null edit, then it goes to this ""processing"" dialogue but then it shows ""Could not start the review because your revision matches the latest version of this page."" So then I press the little back link on the dialogue, but it just goes back to the processing dialogue. If the page is small, the processing is really quick, so before I can even press back again, it goes back to the ""Could not start"" warning message. Even if I do manage to press the back a second time quickly, it will only stay at the save dialogue for a split second and then again bring me to the warning message, although then pressing back does take me to the save dialogue securely. FF 23.0.1 Win7""
I've confirmed this in Firefox 23.0 on Linux.
The issue is with the < link only. Clicking the ^ does return you to the editing screen as expected.
--------------------------
**Version**: unspecified
**Severity**: minor",55313,7,Medium,False
-8.75780764441902,-2.390590144169378,-6.835122920312127,-2.826038176679897,4.093455900310838,7.135931205846783,1.0084896966313384,0.5472828796145706,1.4259034712202168,1.4778373205927728,-3.0977974154160743,-4.3417870128363525,-3.943540679484255,3.399540961990825,0.27242280328490853,-1.5148894949689007,1.2655797212936848,2.508384013622882,False,c1,3,"Rather than passing around boolean parameters called 'reversed' all over the place, we should use each transaction only once, and implement a function that creates a new transaction that's the reverse of an existing transaction.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55225,7,Medium,False
-5.361075594181859,-0.7812344925881725,-7.213291030032984,-2.6498421212248484,-1.9005358381589585,-0.35739816430954163,2.4849037756999186,1.511653897656191,-0.9356552058290044,-0.12218143482731225,1.2906329233486287,-1.7444316189042084,2.3922758542068725,-0.9522629445680626,-0.05921603660513419,-0.6682449480372321,0.07832922617221327,1.9469530964393031,False,c1,3,"dm.Surface.undo() and .redo() just call documentModel.rollback() / .commit() directly, without going through all the other stuff in .change() . Presumably this other stuff is useful, so we should figure out if bypassing it causes bugs.
--------------------------
**Version**: unspecified
**Severity**: normal",55224,7,Medium,False
-7.2319179324415535,3.337437758843606,-4.146680538378895,-1.3100992532336613,1.3809747673610455,0.6914585427623889,-0.33588967658276303,2.251004581871303,-0.9695892513227331,-3.0645399355566285,-2.489849446932187,-2.202698985829734,-0.48907214036001445,0.8504389380113224,-2.0586634459429267,-0.3385064353181092,-0.8335403430437484,-0.4794947788330244,False,c1,3,"When loading VisualEditor from a section edit link, the editor opens at that position on the page. However, as the TOC is not displayed in edit mode (bug 49224) the content is effectively rendered higher up so a later section in the article moves into the view (from a users point of view this is perceived as scrolling to a random point).
The view point does move to the new location of the desired section as the final step of loading, but only if the user has not scrolled at any point while waiting.
If they have attempted to find the section themselves while VE is loading then either (a) the view point subsequently doesn't move when loading completes, or (b) moves by the amount it would have done if the user had not scrolled (meaning it now points at a different point to desired). I have not worked out how to specifically induce one behaviour or indeed what causes either.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T51224}
{T52206}
{T54577}",55217,7,Medium,False
-8.284495762129428,0.629049624123379,-3.752371703305652,-1.184160293174898,4.446761149025816,-0.3530588049399077,-1.2748723424362582,-2.551833599690692,2.5276749097134825,-2.6766339464667266,-1.6874213060219072,-4.031984428561799,0.21837453294939202,-3.687714045443486,2.1700048248071866,-2.7008373847922598,2.3704670131779793,-2.173827260196091,False,c1,3,"I clicked to edit a section of a long article, and when I tried to file a bug, it looked like the screen just went dark - I couldn't immediately see a dialog box. It turned out to be because the feedback dialog was overlayed above the section I was editing, which was way, way down the page, and the browser didn't scroll to that part of the page when I pressed the button.
--------------------------
**Version**: unspecified
**Severity**: minor",55173,7,Medium,False
4.396611740882525,-7.6673820166084425,-3.539030218012339,-2.401921679106118,1.3654086350889107,3.6640987641055007,-7.2524413214489485,0.8042542867410435,-3.4478247152008246,-0.029575885380309863,3.385683900195478,2.134051811652924,-0.9940325200508076,2.192463183008411,2.3957172351638265,-0.4816540691642951,1.9676285491634788,-0.2676490624632384,False,c1,3,"1. Create a document with:
Foo <cite>Alien</cite> Bar
2. Select all and bold
Results
3. 'Alien' is bolded, despite being protected (questionable)
4. The shield has disappeared.
--------------------------
**Version**: unspecified
**Severity**: normal",55149,7,Medium,False
-1.3988786666566337,-2.1429886469841772,1.2637190753302256,6.708197733479288,-4.1132200612660625,-2.1134363932515,2.8693589048042947,-3.380587290157047,1.2071507693129908,-2.2379330975537464,-2.861262506553194,1.6123143205424662,-1.9369031546081494,-1.2221362266973235,0.8115222655501979,0.7388543720454657,1.3264973526149768,1.472144095322698,False,c1,3,"Both ve.dm.ModelRegistry.js and its test file have references to /^mw:/ . Any code relating to mw should be in modules/ve-mw/
--------------------------
**Version**: unspecified
**Severity**: enhancement",55148,7,Medium,False
-6.245376457514874,-0.7300759860246746,-1.9951999857543772,0.7417900324767743,0.38554250486453456,-0.28861086063893016,-0.4531037422863555,-0.8462336662964965,1.8905975925700507,-0.4446842717806305,1.0713568046020918,-0.8441828148095034,0.8736434220848399,-0.7110498101572125,-1.9271142115255144,-0.305549935426063,0.4378854729703745,1.909261241917459,False,c1,3,"We currently use { target: {}, params: {} } for single-transclusion content, and {parts: [{template:{target: {}, params: {}, i: 0}}]} for multi-part transclusions and extensions. This creates special cases and makes it necessary to know all keys to convert the single-transclusion format into the parts bit.
The missing namespacing also makes it harder than necessary to add additional information to data-mw.
To clean this up, we should consider moving to always using an array format like this:
parts: [{""@type"":""mw:Transclusion"", target: {}, params: {}}]
The change to always use an array is already supported by VisualEditor. Flattening the nested object and using a JSON-LDish @type key makes the parts structure more regular and easier to extend. It also moves it closer to the RDFa names. Both us and VE can support both formats as an input for a while to avoid caching issues, but should start by only emitting the new format.
See also:
http://json-ld.org/playground/index.html -- some example JSON-LD
--------------------------
**Version**: unspecified
**Severity**: normal",55135,7,Medium,
0.027816040831186495,-6.135179284878223,-7.394650940008416,-1.6683772104033197,-0.29030996753920674,-0.32870609738718704,-5.441917525873035,1.6955343111831715,-1.3660886023945678,2.2791526676499556,-1.1843936350459785,0.6274542616210186,-0.492255810120362,-3.4295695067746723,0.4846937843810162,2.4999838171382462,-0.8627363596824945,0.808918279879103,False,c1,3,"**Author:** `p.selitskas`
**Description:**
Please create an icon with bold cyrillic ""Т"" for [be] and [be-tarask].
In Belarusian locales ([be] and [be-tarask]), the Bold icon is now read as ""Тл"" which may be interpreted as ""Тлусты"" (fat), but in fact it makes the selected text not fat, but bold (""Тоўсты""). :)
--------------------------
**Version**: unspecified
**Severity**: normal",55094,7,Medium,True
-1.9511782620544331,6.157962312823521,0.8633437933332146,-0.8232590935398482,1.636168844645979,-2.9609546360742334,-2.1654687257366505,-3.2775294547169214,-0.038346329556160574,-0.5972732537129684,0.33714775783981343,-3.8712092701376513,2.144008739262765,-0.5347987662806846,2.4865252512155687,-0.9526907384534034,0.32637237334623737,-0.48691663765030113,True,c1,3,"It first happened to the user who was trying to add a wikilink to a large page, https://en.wikipedia.org/wiki/List_of_Criterion_Collection_DVD_and_Blu-ray_releases; he got the error while in VE so he made that edit with the classic editor later.
He then copied the contents of the page to a sandbox - https://en.wikipedia.org/wiki/User:Marc_Kupper/sandbox2 - for further testing and these are his findings:
<< It took 74 seconds to load the page in VE, I made the change, save-page, give a reason (wikilink - testing VE), save-page again. After 1:45 (105 seconds) I got ""Error: Unknown error"" in the lower part of VE's edit-summary box. The save-page button is grayed out.
I don't think the actual edit I did matters. If someone wants to reproduce using my sandbox then the edit was in the last paragraph of the lead. Where it says ""...Essential Art House, Eclipse, and Merchant Ivory Collection..."" I changed ""Eclipse"" to [[Eclipse (DVD)|Eclipse]] by double-clicking on Eclipse to select, control-K to bring up the insert/edit link box, appending "" (d"" to the link-to value, click ""Eclipse (DVD)"" in the list of offerings, and then press <enter> a couple of times to close out the box. I suspect you can make any change you want. --Marc Kupper|talk 22:06, 19 August 2013 (UTC)
After documenting how I did the edit I tried the save again and again got the error. It happened 1:44 (104 seconds) after clicking save. I suspect the 105 seconds above is simply because I was a bit slow reacting as this time I was waiting for the error right around the 1:45 mark. --Marc Kupper|talk 22:06, 19 August 2013 (UTC)
I then did the following tests
I replaced all non-alphabetic characters with the letter ""x"" and can edit the page with VE. It appears the issue is with something in the page content, possibly combined with the page size.
I removed all 'ref' tags. Saving from VE still fails after 1:44
I removed most of the templates transcluded on the page. Saving with VE worked and took 1:17. However, I had intended to just add ""xxx"" in the middle of a word. VE also stripped a table in another part of the article of wikitext. (https://en.wikipedia.org/w/index.php?title=User%3AMarc_Kupper%2Fsandbox2&diff=569295763&oldid=569295507 ) --Marc Kupper|talk 23:16, 19 August 2013 (UTC)
I don't have time to debug this further at present - particularly as we now have two VE issues. The next step is to revert back to 22:48, 19 August 2013 and to then see if I can narrow it down from there. --Marc Kupper|talk 23:11, 19 August 2013 (UTC) >>
I tested on the first version of the sandbox as well, it took me almost 75 secs as well to load the page, I wikilinked a word and then hit Save - it took me 2min 15sec to get the error message while actually the edit was saved. Thanks.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70726
https://bugzilla.wikimedia.org/show_bug.cgi?id=51636",55093,7,Medium,
1.0639570754193746,-2.182826193214204,2.9336107299120613,0.7634373576267877,3.1280931540315624,-0.6150363950609097,0.34051480993042293,1.4652174209163427,-1.1297558272410129,-1.685866306378784,-0.8086824394390169,0.13596354589468684,1.2567899804959688,-0.9120822824428783,-1.629639907517178,-0.010091715731403161,-0.6394292438858854,0.7962849446131945,False,c1,3,"Screenshot
Blocked IP addresses can see the VisualEditor, use it, and are presented with the error in the screenshot when saving.
Reporting distinctly from bug 52004 because the error message and use case are both somewhat different.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52004
**Attached**: {F11450}",55009,6,Medium,False
-3.68666840624466,0.048899789240829605,-0.8303716749587,1.871897318181348,4.891032048489819,-2.8725143151368853,3.0923708104586014,-1.3807139010611187,-0.6475833795140011,1.550705518425814,-0.6505964205201229,0.9346641727832454,-1.263699941323468,-0.551529692656362,1.2843849494331154,-0.6065896689013391,-1.7315342720039082,3.3319431343201096,False,c1,3,"The thermometer is important, as it explains why a radically modified document would give me an empty ""review changes"" box.
Separate bugs: the thermometer never stops spinning, and my changes for review never appear--maybe Parsoid is gagging. And, is that UI javascript running without a setTimeout?
--------------------------
**Version**: unspecified
**Severity**: minor",54982,6,Medium,False
-1.5172871293543742,7.090358385609129,-0.11984083635915965,-1.2774426572890087,-0.5825298881465243,3.310586085316989,0.04724490121962077,-0.7645672200307265,2.829890343772284,0.8411749934994255,1.284952082747648,-0.5095121660651767,1.0797448653419388,-0.9480587267658453,1.135920087076686,-0.10404042755803244,0.5633520784101613,-0.4687956719912465,False,c1,3,"**Author:** `jamesjoshualim`
**Description:**
Hi, everyone. Yesterday, we had a meetup here in Manila, and I discussed with two Tagalog Wikipedia editors (including a fellow bureaucrat) about the creation of a new interface language for Tagalog in a bid to resolve long-standing differences over how the interface should be translated. We agreed on a compromise solution, where we would accommodate Taglish (code-switched Tagalog and English) as a new interface language called ""Tagalog (informal)"" for the Tagalog-language projects, similar to how there is an interface language for formal German (de-formal).
We decided that this new interface language will become the default interface language for all anonymous and new users on the Tagalog Wikipedia, in order to attract new editors who may be confused by the formal language used for the current Tagalog interface. The current interface will be opt-in for those who want to use the interface as it currently is, and users will have the ability to select their preferred language using the Universal Language Selector which will only have Tagalog, Tagalog (informal) and English as the options. All other languages may still be selected through the preferences.
If this is possible to do, I'd love to see this come to fruition, and I hope to hear from all of you soon. Thanks! :)
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",54957,6,Medium,
3.5285151453222166,-0.8401719842568305,0.45712311087621416,-3.230419438035407,-1.1873516956040095,4.158269947652874,2.8914015752054967,-4.467744255502456,-0.7543744790374796,0.474808412276599,0.9282042428906565,-1.3103218432558306,-0.7324643943923013,1.0923449539434564,-1.443291125706386,-0.8790159519029335,0.1204705011674072,-0.3862677996702366,False,c1,3,"**Author:** `swalling`
**Description:**
Hidden VE postedit confirmation
If you edit successfully via wikitext, we delay loading the GettingStarted toolbar until after the post-edit confirmation disappears. We should do the same for the new style of postedit confirmation from VE.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11351}",54955,6,Medium,False
-8.323591193790175,6.66398394560834,-0.5102969481482873,-2.530749017536553,0.5050312878095233,2.6030454515482893,0.041790472655010014,3.0887174438765923,3.2709667963173477,-0.5749694037102806,0.24461164058027052,-1.3839698789476096,0.3943948988881467,0.4205358686257865,-0.23243388536841536,-0.04432021594332558,1.3094540007535997,-0.10404639797388948,False,c1,3,"Currently we always serialize to wikitext and re-parse that to HTML, which runs the sanitizer on the token stream to ensure that our final HTML does not cause bad things to happen.
Soon both us and the Flow team want to store HTML from the VisualEditor directly without first serializing to wikitext. This means that we need to perform the sanitization on the HTML instead of the token stream. For performance, sanitizing on the way in would be preferable. We should however support re-sanitization when new issues were discovered. This could potentially be coupled with the versioning discussed in bug 52937. A new sanitizer could bump the version number, and the upgrade path would then run the new sanitizer on old HTML (and probably update the storage with the newly sanitized version).
--------------------------
**Version**: unspecified
**Severity**: normal",54941,6,Medium,
-6.70675210053852,4.998500263019675,-1.5954653621297457,-4.095421698745832,0.18011980142705442,-0.1618275902019558,2.161869484536724,-4.019689732851835,-2.1381909395438745,0.383114463190406,0.9953430205204143,0.7548621803911615,-0.669700445770256,0.8274308736409521,0.7860072171454888,-0.5613987847761291,-0.819526939742627,-0.2951867192415958,False,c1,3,"**Author:** `swalling`
**Description:**
Screenshot at 1024x768
Very happy to see that VE is now using the same post-edit styling as wikitext! This is a big win for usability, since it is fixed position and so on.
I did find one suboptimal fact though... Since the text of the message includes the page title, it is very variable width, depending on the page title length and the browser width.
One of the UX goals for this notification is to have new users notice it, but for it to eventually fade out of your attention as you become used to it. Since the page title produces very different widths as you edit different pages, this calls a lot more attention to the notification even if you've edit thousands of times.
My recommendation would be to match what's in the wikitext version, ""Your edit was saved."" since we A/B tested it and we know it meets the goals I mentioned above. Another good solution is simply removing the page title, so that the VE version says, ""Your changes have been saved."" That seems functionally the same, though I think using edit is good for consistency with the tab names etc.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11185}",54871,6,Medium,False
2.369429688424512,-10.307158950590809,7.263679088925979,5.180223972064285,-0.562610689866911,0.21915680353772427,3.9100818740129304,-1.0017766979877887,-2.276927390980153,0.8826596607600452,2.510292003732086,2.467432467020334,-0.9779017392554534,-0.7120082696880434,-0.01852623676280718,0.9891090302479556,-0.6836291467101684,-0.7704727640206959,False,c1,3,"The <references /> section is empty in edit mode, see URL.
Other examples:
https://de.wikipedia.org/wiki/Joachim_Wiesner
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Bahnhof_K%C3%B6ln_Eifeltor",54841,6,Medium,True
2.507266756290089,-3.945236713495751,4.210782099478845,1.670629029748664,0.2089172990850966,-4.0527766600293385,-4.508769981907297,0.38996531790908484,0.290815734902802,-1.5176630481802382,3.5381269780586533,1.1632327686727562,-3.8707254679976826,-0.705846758175209,-0.5187856729824949,-0.24358558247166417,0.5085324124790616,0.06391101569041946,False,c1,3,"https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-searchoptions
The ""Advanced options"" section of the ""Search"" tab in MediaWiki currently looks like this:
---
Advanced options
[ ] Search in all namespaces
Search in these namespaces by default:
[ ] (Main)
[ ] Talk
[ ] User
[ ] User talk
[ ] Project
[ ] Project talk
[ ] File
[ ] File talk
[ ] MediaWiki
[ ] MediaWiki talk
[ ] Template
[ ] Template talk
[ ] Help
[ ] Help talk
[ ] Category
[ ] Category talk
[ ] Thread
[ ] Thread talk
[ ] Summary
[ ] Summary talk
[ ] Manual
[ ] Manual talk
[ ] Extension
[ ] Extension talk
[ ] API
[ ] API talk
[ ] Skin
[ ] Skin talk
[ ] Module
[ ] Module talk
[ ] Translations
[ ] Translations talk
[ ] VisualEditor
[ ] VisualEditor talk
---
This list looks silly and excessive. While {T39878} has requested a layout change, I think we need to reconsider how this list is implemented.
What about adding a checkbox to [[Special:Search]]'s advanced search section that looks something like this:
[ ] Use these namespaces as my default
This would de-duplicate the namespace listing (between Special:Preferences and Special:Search) and would allow the search user preference to be set more easily from the search interface itself.
Rather than using Special:Preferences and having heavy user interface exposure, any custom search namespace preferences could be ""hidden"" user preferences. That is, they'll still be stored if they don't match the site-wide default, but they'll not clutter up Special:Preferences.
--------------------------
**See Also**:
{T50615}",54817,6,Medium,False
-0.8286056937577815,-0.540552681464515,0.45659357622922414,3.000549237436214,-2.7024845509870237,0.36183234511257756,-2.3805916971630023,0.6533251857589044,2.3965577732649397,-0.41772461625083945,-1.3751234486014732,0.11999519235828626,-2.4871695295965424,-0.7435766705536304,2.710374369928206,-0.9901517319287361,-0.4316212777057875,2.0410684333480864,False,c1,3,"The ""Enable section editing via [edit] links"" user preference should be removed from MediaWiki core.
Users interested in hiding section-edit links can use per-user (or site-wide) CSS.
This should be an easy bug to resolve; marking it with the Bugzilla keyword
accordingly.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",54811,6,Medium,False
-2.5122222509380965,-5.00562728262287,-4.2830989673663336,-2.5288171003099866,-3.5076633790200074,-0.8868621075599168,-4.207148379535912,4.605309886299062,-0.6103108434399365,-3.2445585236904915,3.6848019830055567,-2.870294538515188,-7.653754254486402,2.260047342026061,-0.1883660971950185,0.22299136414562862,1.395831075470914,0.3051438459176523,True,c1,3,"A user asks if VE shouldn't now get rid of apostrophes used for formatting and use common tags instead <b>, <i>...
--------------------------
**Version**: unspecified
**Severity**: enhancement",54796,6,Medium,False
-6.345255469649928,2.3650652223697186,-2.479637884874677,-2.695801872069311,1.3615034377152484,-2.3027749983332813,1.775679815573321,-2.3862061312200704,-3.1376003371988714,-3.1648821026199485,0.041778225664254265,-1.6503260579994785,-0.30543341575246874,3.962828543639745,2.1132214848785402,-1.0455772365246236,-2.2535383825745625,1.2678864453494751,True,c1,3,"<< When editing a reference, there is no indication at all if it is used multiple times throughout the article. This makes it very easy to screw up references, e.g. when you replace a ref for one sentence by changing it and it gets propagated throughout the article. WS (talk) 11:45, 13 August 2013 (UTC) >>
--------------------------
**Version**: unspecified
**Severity**: enhancement",54792,6,Medium,False
3.393360779622047,-14.918766722171346,4.63908137157302,-1.2733303609844584,0.08191762479179143,-0.6234517143724996,1.6819955289452535,2.2283944855421534,3.321319257945275,0.05162171214839617,0.014083020124046719,-0.28171762719715376,0.22822997248086452,-0.26619792593656744,-1.1822221053055149,0.30860404648413825,-1.0979215854214714,-1.0349363003624388,False,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52771",54770,6,Medium,False
-5.663598589062122,2.2819326160055766,-3.1755222096485944,4.413297301205041,1.602493660191354,2.4200259374640716,-2.43195355191604,-1.6965311722222096,-1.3292078161255232,1.600249617098469,-3.5164844069304553,-0.08743128289746238,-0.6164931117665171,-1.6047582195225472,-0.3782311077722378,-1.1430956861873076,-0.5525426544082312,1.0161454985828502,False,c1,3,"**Author:** `l736ewiki`
**Description:**
The data model for TemplateData allows the tag ""default"" to assign the default value for parameters which foresee it.
However, when adding a template to an article via VisualEditor, the default value is not presented inside the corresponding input field, which appears empty, nor there are automatic hints about the default value (unless who generated the TemplateData object inserted it into the textual ""description"" item).
I would have expected that:
* either the user is presented with the input field already pre-filled with the default value as specified inside the TemplateData description - this would improve usability
* or, if this pre-population of the input field is too complex/costly to achieve, at least the information about the ""default"" value is taken and highlighted using the corresponding ""default"" attribute from the parameter description.
You can test this on it.wiki, by trying editing a new article using VE and adding the template named ""Azienda"", whose ""logo_dimensioni"" parameter has been defined in JSON with ""default"":""200"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",54753,6,Medium,False
-4.2121110088930465,-2.4414376771799713,-0.5034095908270615,1.58969192051672,0.6215956188441611,-1.2230479035413184,0.0008824332726318218,0.8063031509551509,1.7547270646826874,-1.5645396326365089,-1.7451397769043229,1.5952175986286046,-0.07152327794878399,-1.012959769561061,-0.19442507057819025,-0.02158354811892088,-0.14711550879240476,-1.3270617962374978,False,c1,3,"Reports such as https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=568123469#I_can.27t_edit_the_references suggest that the references list being present but not editable is causing confusion for editors.
It would therefore be helpful for VE to display a message (popup? tooltip?) whne the reference list is selected that explains how to edit references. The text of this message should be set on a MediaWiki namespace page.
I don't have a suggested default wording at present.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52750",54736,5,Medium,False
-3.3550668882911165,-1.414213074754544,-1.515271764475445,-2.6571881850105212,0.06089628807835201,-2.8355827040305988,1.0482498232250101,3.371833534233804,-1.044003032867427,-2.1522833509311665,-2.040182005543838,-1.5186311954601637,-0.13882409830211184,-0.9334625335215487,-0.2127899497209258,2.5395894590818995,-1.0306888048152296,-1.2571072814299815,False,c1,3,"**Author:** `gitartha.bordoloi`
**Description:**
Hello,
Visual editor was deployed as an opt-in editing tool in Assamese wikipedia about 2 months ago. However it seems the tool doesn't support Assamese script well. While writing with some tools reproduces only vowels or consonants, the in-built keyboards do not work at all. Kindly look into this matter urgently before it is released as default editing tool. The discussions can be found here: http://as.wikipedia.org/wiki/%E0%A7%B1%E0%A6%BF%E0%A6%95%E0%A6%BF%E0%A6%AA%E0%A6%BF%E0%A6%A1%E0%A6%BF%E0%A6%AF%E0%A6%BC%E0%A6%BE_%E0%A6%AC%E0%A6%BE%E0%A7%B0%E0%A7%8D%E0%A6%A4%E0%A6%BE:%E0%A6%AD%E0%A6%BF%E0%A6%9C%E0%A7%81%E0%A7%B1%E0%A7%87%E0%A6%B2_%E0%A6%8F%E0%A6%A1%E0%A6%BF%E0%A6%9F%E0%A7%B0
Thank you.
--------------------------
**Version**: unspecified
**Severity**: major",54726,5,Medium,False
-2.5031456110839523,1.3320836171120352,2.8877623936808874,5.087328262783593,1.3481504182022561,3.859835792462956,-1.5605284979134408,-2.184363063890962,-1.3021011643724507,-2.423379730947253,2.324733784096837,2.9002780863336177,-4.3861368910342895,0.6515810810801534,1.531921615805679,0.02853249906180877,-0.1729742569607453,0.880108204401185,False,c1,3,"MassMessage is an extension that allows a user to send a message to a list of pages through a special page and the job queue. It is intended to replace [[m:Global message delivery]].
More details are available at [[mw:Extension:MassMessage]], and there is a test instance at http://legoktm.instance-proxy.wmflabs.org/wiki/Main_Page
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://www.mediawiki.org/wiki/Extension:MassMessage",54723,5,Medium,False
10.33404810102186,-0.25585366930010345,-0.2473506032402284,-1.373600319000769,-2.0877450865511915,3.275332828232103,0.09997940381669679,-1.983770996587026,4.4579331217246265,-2.116101588608405,-3.01297233987926,-1.5702128886801774,-2.551436518950636,0.6460936072675496,1.064316356721121,-0.8560858194105541,0.5854524327546591,-0.5696029931322797,False,c1,3,"The Swedish chapter would like to get the VisualEditor enabled on their wiki at se.wikimedia.org.
Poll here: http://se.wikimedia.org/wiki/Tråd:Wikimedia:Bybrunnen/VisualEditor_och_Notifications
/Jan
CEO
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",54713,5,Medium,False
9.886171049289487,-2.8840093059192906,-1.9528763296935185,-2.3935131907478913,0.00047475556214782166,0.9517140540419355,-0.39108156898494517,1.322680074669952,-2.325750322716626,2.0312938567963847,1.2274581972276644,0.5876035715155783,0.05500263927901461,-1.9924763473296587,-0.9857512226175507,-1.3621027945731201,-2.02438953707667,1.3730890297512979,False,c1,3,"en.wp user Cryptic C62 reports that using Firefox with Windows Vista ""high contrast"" mode renders VE entirely unusable:
""Using Windows Vista, press Shift + Alt + Print Screen to activate ""high contrast"" mode. Open VE in Firefox. Weep uncontrollably (see screenshot).""
Screenshot: [[File:VE High Contrast.jpg]]
It is worth noting that, when using the high contrast extension for Chrome, the interface is fully visible in every setting. Hooray!
--------------------------
**Version**: unspecified
**Severity**: major",54675,5,Medium,False
-1.5419053638332043,-4.384401182822,-0.8555799296139757,1.3345484668850602,2.97919174519885,0.10530882306501033,-1.3366647540222472,1.4175269150855008,0.5349803900952106,-0.614355402450447,1.6606330285550892,0.007585218316658482,1.0431594637554755,-0.5929678994468865,-1.4198248674555858,0.1279681600732844,1.716794327776703,-0.7662785214368519,False,c1,3,"When a user has a larger font size than defualt, or a non-default font then the welcome dialog (the one controlled by the ve-beta-welcome-dialog cookie) doesn't expand or scroll to accommodate the extended length of the message and the text is cropped.
Screenshot at [[File:WARNINGforVE.png]]
This might be another example of bug 52602 but I'm not certain.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52602
https://bugzilla.wikimedia.org/show_bug.cgi?id=51755
https://bugzilla.wikimedia.org/show_bug.cgi?id=50885",54667,5,Medium,True
-4.377142119563798,-3.594811471808507,-5.880966907130288,0.04773012538282395,1.4504397123607942,-0.22027535596069547,-4.983601811771367,-1.6182550539578826,-0.5637159322893585,0.8041713395010088,-1.597511750154904,-3.3136948543401887,1.2250560229556564,-1.9617074743122105,-0.831294718582984,-0.6787918846957566,0.2695117170144328,1.445085543336608,False,c1,3,"en.wp user Redrose64 reports:
With this edit: https://en.wikipedia.org/w/index.php?title=Paisley_Gilmour_Street_railway_station&diff=prev&oldid=567709873 ""the {{-}} was moved from the bottom of a section into a heading, effectively yielding the HTML <h3><span class=""mw-headline"" id=""2013"">2013<br style=""clear:both;"" /></span>[edit]</h3> ""
I can reproduce that on that article by:
1. Deleting with backspace the header ""Post-2008"" (and nothing else)
2. Typing ""2013""
I can't reproduce it in my sandbox with {{-}} (or {{clear}}) before a header and then changing the header.
--------------------------
**Version**: unspecified
**Severity**: normal",54658,5,Medium,True
5.8311333506812115,0.9402054420006731,-0.10682075165316363,-1.6697381914343286,-1.3249754831715441,1.2299674326643693,-1.028267195358345,0.8046001636826424,-0.8703528815714644,-1.6438498792649274,-1.0511354108671256,-1.3750362975711985,1.2615388840872739,-1.6398382066571404,-3.040844353521692,0.4327268276853462,-0.3625939585080462,-0.042473078106900264,True,c1,3,"During the edit
This has been noted on the Thai wikipedia.
See screenshots for how it looks.
Basically, in edit mode, the sixth column of this table, containing Goehack coordinate links, displays as an HTML string in edit mode. Not only very messy, but it pushes the following columns off the page.
Appears to save normally.
Replicated on current FF, Chrome, on Mac OS and Ubuntu
Page on Thai.wiki: https://th.wikipedia.org/wiki/%E0%B8%A3%E0%B8%B2%E0%B8%A2%E0%B8%8A%E0%B8%B7%E0%B9%88%E0%B8%AD%E0%B9%82%E0%B8%9A%E0%B8%A3%E0%B8%B2%E0%B8%93%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B9%83%E0%B8%99%E0%B8%81%E0%B8%A3%E0%B8%B8%E0%B8%87%E0%B9%80%E0%B8%97%E0%B8%9E%E0%B8%A1%E0%B8%AB%E0%B8%B2%E0%B8%99%E0%B8%84%E0%B8%A3_(%E0%B9%80%E0%B8%82%E0%B8%95%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B8%99%E0%B8%84%E0%B8%A3_%E0%B8%9B%E0%B9%89%E0%B8%AD%E0%B8%A1%E0%B8%9B%E0%B8%A3%E0%B8%B2%E0%B8%9A%E0%B8%A8%E0%B8%B1%E0%B8%95%E0%B8%A3%E0%B8%B9%E0%B8%9E%E0%B9%88%E0%B8%B2%E0%B8%A2_%E0%B9%81%E0%B8%A5%E0%B8%B0%E0%B8%AA%E0%B8%B1%E0%B8%A1%E0%B8%9E%E0%B8%B1%E0%B8%99%E0%B8%98%E0%B8%A7%E0%B8%87%E0%B8%A8%E0%B9%8C)
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11613}",54653,5,Medium,False
-6.268451797245353,0.07255197318125717,-1.7949677634100674,2.38736079956023,2.023543577438732,-0.8282164583660359,-3.2475350894817896,1.2088362622879756,2.780474983808582,2.1487906200123925,-3.2694464843771995,-1.4351098430211926,-0.613110429937155,-0.4735644921920166,-0.1294388141792231,-0.43790234671737893,-1.0892097558643714,-1.0510850249436774,False,c1,3,"If a parameter has '""type"": ""number""', VisualEditor should not allow the user to insert other kind of values. Alternativelly, it could just warn the user but still allow a value of the wrong type to be inserted.
This should not be restricted just to the ""number"" type. Other types would also benefity from some validation (e.g., if at some point we have a type ""string/image-name"", VE should check if the user provided the name of an existing image).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52652",54651,5,Medium,
-0.6666792224392042,2.2731969682489783,3.150544031605918,-0.47360627271942723,1.8683839582080446,-1.424966472281196,-5.893332222618687,0.7768808749773363,1.8025946073490393,6.853064422919452,-4.262761619737509,1.9378172341377187,-1.1771753814893593,0.2635374652226856,0.9432780751262548,0.3109994670600493,-3.2915241637843,1.054995910674214,False,c1,3,"If you want to add a ""template"" that is not in the template namespace, for example: ""User:UBX""; VE will make an API request like: ""GET https://en.wikipedia.org/w/api.php?format=json&action=templatedata&titles=Template%3AUser%3AUBX"".
It should automatically detect that ""User:"" is a valid namespace, and not add the ""Template:"" prefix.
--------------------------
**Version**: unspecified
**Severity**: minor",54609,5,Medium,False
-10.807880162095902,0.9195722872551926,-5.288187961084361,-1.3093932029878352,12.19194606499682,5.068607583666352,4.314444213794146,-2.0761081767113834,-3.0291521021676058,-0.19317303121750218,-2.369441305678741,3.3767083811433993,-4.0306952249706685,3.3833561510041896,0.23859703306886004,4.025203442460402,9.04671014250387,2.8501408618669677,False,c1,3,"Some toDomElements functions reach into the store, but they shouldn't and the check is redundant.
",54599,5,Medium,
-4.6890193791114445,-0.6764851260586031,0.3436850933811293,-6.2037505589568696,-8.373610874424728,3.358988501831174,-0.8014165083464109,1.0723721153437564,6.965108670468411,1.3598531941733967,0.27015546764934006,2.058295952128746,0.26717070837060497,0.4341746278882299,0.9560670837969436,-1.872883081152489,0.13969297323944319,-1.3319769048706998,True,c1,3,"A keyboard shortcut for code would be helpful, particularly for MediaWiki.org. We'll need to think of what to use.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54597,5,Medium,False
-3.868508101042179,0.09509728863074685,-1.9545988834656605,-0.6568988202199244,-1.1672137609228164,0.6507569626116698,0.48038372851321043,1.9860225182884204,3.0523267715769746,0.6410089765187532,1.9883257104534882,-0.251090329623898,2.3811527391425047,-0.9348684913811014,0.22715331979607267,1.340789955867171,-0.6679320839973701,-0.6285562481498219,False,c1,3,"Some templates use numbered arguments (see for example http://en.wikipedia.org/wiki/Module:Citation/CS1/Whitelist in the numbered_arguments list). For example, you can use author1, author2, ... (no limit).
Currently, there's no way to define such parameters in TemplateData, and the VE interface is not also optimal for them.
Would it be possible to handle numbered arguments in TemplateData: a parameter named author# would define a numbered parameter named author with a numerical suffix. It should be possible to define lower bound (1 by default) and upper bound (no limit by default).
Then VE should handle them accordingly: only propose the first parameter available in the list of parameters than can be added.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
{T53740}",54582,5,Medium,
-5.199003217182879,3.6180790758527444,-0.7616501436815994,-2.112801499494008,3.27247270700286,1.192036341980528,2.5810869418542923,0.3706433039360604,-1.5792286136492966,-0.9901698640564227,-1.3365580462437445,0.6631957774193622,-1.6294315335019567,1.5887909946798295,-1.0968872517154828,-0.4792442866713783,0.5950050924648125,-1.0830082344897716,False,c1,3,"I don't know if this is possible, or if it's been requested elsewhese, but a few users on the French-language Wikipedia have suggested that, when the user has scrolled through the page and invoked VisualEditor via the keyboard shortcut, VE should automatically scroll to that same position on the page when it opens (similarly to what the section edit link does).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53217",54577,5,Medium,
-2.0639305505485526,-4.705027611386496,-3.454751128907793,0.2838276332300147,0.020139959429291143,-0.8331378786920104,-2.495942907563796,1.9852216833784007,-0.9246038868172102,-2.3454784009293093,3.146700378016655,-1.5846091946105436,1.5810902461525242,0.16582147171565342,1.2377612636514899,-0.23503359277421654,-1.2221092307615802,0.07007969320730445,True,c1,3,"<< Icons can be useful to help a user navigate an interface, however in the transclusion dialog, the same box-shaped icon with the thick left border is shown so many times (when editing a template with more than a few parameters) that it is obnoxious. Almost every occurrence should be removed, keeping it displayed at at most one or two places.--[[User:Wouterstomp|WS]] ([[User talk:Wouterstomp|talk]]) 11:22, 6 August 2013 (UTC) >>
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49833",54576,5,Medium,False
-1.3685429384893846,3.0106908540850554,-3.794202307200493,-2.0098279397651533,0.24768265987436877,-2.8824929309201663,-5.52636097896271,-0.9601744385900821,-3.1805941309465737,-1.3721279271986329,4.540890937710886,0.5454223010937762,-4.274343870998831,2.89027718652048,1.069298102136365,-1.3652997666683089,2.333486171945631,-0.15396275463140907,False,c1,3,"[15:52] <T13> VE Question. How is VE currently set up to handle users that have opted-in to gadgets that modify the editing window such as wikEd?
...
[15:54] <T13> Do those gadgets still load even though the hooks they use don't exist? Shouldn't having VE enabled disable those gadgets and grey out the optiobs for them in the gadgets tab of preferences?
[15:56] <T13> I'm guessing some of the ""VE"" bugs are caused by these gadgets trying to do what they no longer can.
...
[16:06] <mooeypoo> T13: I think most of the edit-related gadgets work on the action=edit condition, and ve goes with action=vedit
[16:07] <mooeypoo> but I am not sure :) you'll be safer getting the answer from the VE team
[16:09] <MatmaRex> T13: i'm not on the team, but i'm pretty sure that's the reason
[16:10] <MatmaRex> T13: basically there are two ways to detect if we're inedit mode - either look if 'action' is 'edit' or 'submit', or look for some elements that are parts of theedit form, like #wpTextbox1 (the main textbox)
[16:10] <MatmaRex> VE avoids them both
[16:11] <T13> I've seen questions on WP:THQ with a link to a screenshot of wikEd and the user thinking they were using VE. So, I was curious how it was handled.
[16:11] <T13> I'll add the suggestion to gray out the unusable with VE gadgets
[16:11] <mooeypoo> Ah, *that* kind of user errors. Hm. Not sure how you can handle those other than politely correct the user's false assumption
[16:11] <T13> On Bugzilla...
--------------------------
**Version**: unspecified
**Severity**: enhancement",54562,5,Medium,
-5.4407499813949265,10.784029388519649,2.3918490425973467,3.6547466525581234,7.890408343960102,0.34809498481350554,1.4154499559088354,2.001503590838268,0.6863550406814243,-1.5958838961840662,-0.636776723530295,-1.2199860326862075,-0.8156620098701541,0.1781949054826919,-0.18320419374649077,-0.39854065052149745,0.4709654353801933,0.8453048768892446,False,c1,3,"**Author:** `mcdevitd`
**Description:**
Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",54557,5,Medium,
-6.329456023104527,1.1496317768423747,-2.4485041480226766,2.288817173847004,1.34743963627466,-1.5900888480478257,0.3969395818605026,2.871109544033224,2.650307037963378,-1.6136006577875146,-0.9114881744634471,-2.9171159947486403,0.7503085956028097,0.11679596815402693,-0.1189266691568287,-0.8254860455623405,-0.7361071663731626,-0.4861389932069844,False,c1,3,"**Author:** `mcdevitd`
**Description:**
The expected behavior in most word processors (Word and OpenOffice) is that the user can unindent (shift-tab) only to get to the initial list indent level but it should not actually delete the bulleting/numbering itself when you to the end. In VisualEditor, unindenting once too many times can remove the initial bullet/number entirely.
This becomes particularly annoying when (because of the behavior described in bug 48051) you accidentally split a list into two lists which can't be fixed clicking the list button again to re-add the bullet/number.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54554,5,Medium,
8.495930865137744,-3.279473742423825,4.307355849401311,0.994869122098315,-5.865919622706194,0.3273198565065789,0.9521451824119573,-0.6964337690451369,-0.09606637688863859,-2.5914234699241723,-3.787913368675451,3.504264053366251,-1.5521080768568698,-2.19480977534227,1.5697533632456064,-0.27773158366833195,-0.3604835677184255,0.7521036559667567,False,c1,3,"Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",54552,5,Medium,False
-4.75323027252087,0.7025468856552397,-3.6328755047611363,1.6352590216033054,0.3927610384216861,-0.8956108844874343,-0.042372720151804266,0.691049230075054,0.13269572754822656,-0.25252326000929504,-0.8721173350547766,0.5616094715238151,1.2198886511865639,-0.9958519441709224,-0.6160563881695191,-0.014788048565079426,0.9232717877404928,-0.4574548602304451,False,c1,3,"Slightly related to bug 51322
Take the Link FA templates on https://en.wikipedia.org/wiki/The_Adventures_of_Tintin?veaction=edit for instance.
These produce empty elements, and don't qualify under 'solely metadata' of bug 51322, even though they are somewhat similar to it.
The templates are represented with the char: ↵
Using the arrow keys to cursor trough this sequence will sometimes produce the template editor indicator. However their is little identifying these templates to the user and due to the interspersed ↵, users think they should be deleted.
--------------------------
**Version**: unspecified
**Severity**: normal",54551,5,Medium,False
-0.8002221514246037,3.5578163685941533,1.9087554567175538,0.823248013162319,2.3800905139436055,2.5919817906648888,2.1124865888326427,2.9131230658320564,-0.673952293459683,-1.621033159714563,-1.769237647189624,-3.093804638018404,-1.6661191393868977,0.48691617039714075,-0.11289944542796704,-1.0342268871549238,-0.6147603620075772,-1.8321839518904106,False,c1,3,"From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Quote_box
In the adventures of tintin
http://en.wikipedia.org/wiki/The_Adventures_of_Tintin?veaction=edit
the first {{quote box}} has been pushed down by the info box. The transclusion icon for this appears appear where the quote box was initially (just below the History section header on the right hand side) not where it actually appears.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51548",54547,5,Medium,False
-5.594465668443571,1.3334216693007477,-1.794414844849717,-0.6442886479674199,-2.3401632858028822,-4.88189998488298,-2.3624861863033155,1.9704894532858388,0.18018597353761678,-0.720445084771554,-2.0287827348419416,-3.521205173047151,2.821968553748655,-0.1755292754536626,-1.4272272705111613,0.05216529036950873,-0.14158385757761138,1.0194938443779364,False,c1,3,"Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
```
aftv5-last-filter: null
ccmeonemails: 0
cols: ""120""
date: ""mdy""
diffonly: ""1""
disablemail: 0
disablesuggest: 0
echo-email-format: ""html""
echo-email-frequency: 0
echo-notify-show-link: true
echo-show-alert: true
echo-subscriptions-email-article-linked: false
echo-subscriptions-email-edit-thank: false
echo-subscriptions-email-edit-user-talk: 1
echo-subscriptions-email-mention: false
echo-subscriptions-email-other: false
echo-subscriptions-email-page-review: false
echo-subscriptions-email-reverted: false
echo-subscriptions-email-system: true
echo-subscriptions-web-article-linked: ""1""
echo-subscriptions-web-edit-thank: true
echo-subscriptions-web-edit-user-talk: true
echo-subscriptions-web-mention: true
echo-subscriptions-web-other: true
echo-subscriptions-web-page-review: true
echo-subscriptions-web-reverted: true
echo-subscriptions-web-system: true
editfont: ""default""
editondblclick: 0
editsection: 1
editsectiononrightclick: 0
enotifminoredits: 0
enotifrevealaddr: 0
enotifusertalkpages: 1
enotifwatchlistpages: 0
ep_bulkdelcourses: true
ep_bulkdelorgs: false
ep_showdyk: true
ep_showtoplink: false
extendwatchlist: 0
fancysig: ""1""
flaggedrevseditdiffs: true
flaggedrevssimpleui: 1
flaggedrevsstable: 0
flaggedrevsviewdiffs: false
forceeditsummary: ""1""
gadget-BugStatusUpdate: ""1""
gadget-DRN-wizard: 1
gadget-HotCat: ""1""
gadget-Navigation_popups: ""1""
gadget-NoAnimations: ""1""
gadget-PrintOptions: ""1""
gadget-ReferenceTooltips: 1
gadget-UTCLiveClock: ""1""
gadget-addsection-plus: ""1""
gadget-charinsert: 1
gadget-contribsrange: ""1""
gadget-edittop: ""1""
gadget-exlinks: ""1""
gadget-metadata: ""1""
gadget-mySandbox: 1
gadget-purgetab: ""1""
gadget-teahouse: 1
gadget-widensearch: ""1""
gadget-wikEd: ""1""
gadget-wikEdDiff: ""1""
gender: ""male""
gettingstarted-task-toolbar-show-intro: """"
hideminor: 0
hidepatrolled: 0
imagesize: 2
justify: 0
language: ""en""
math: ""6""
mfWatchlistFilter: ""all""
mfWatchlistView: ""feed""
minordefault: 0
newpageshidepatrolled: 0
nocache: 0
noconvertlink: 0
norollbackdiff: 0
numberheadings: 0
previewonfirst: 0
previewontop: 1
rcdays: 7
rclimit: 50
rcshowwikidata: ""1""
rememberpassword: 0
rows: ""30""
searchNs0: true
searchNs1: false
searchNs2: false
searchNs3: false
searchNs4: false
searchNs5: false
searchNs6: false
searchNs7: false
searchNs8: false
searchNs9: false
searchNs10: false
searchNs11: false
searchNs12: false
searchNs13: false
searchNs14: ""1""
searchNs15: false
searchNs100: false
searchNs101: false
searchNs108: false
searchNs109: false
searchNs446: false
searchNs447: false
searchNs710: false
searchNs711: false
searchNs828: false
searchNs829: false
searchlimit: 20
showhiddencats: ""1""
showjumplinks: 1
shownumberswatching: 1
showtoc: 1
showtoolbar: 1
skin: ""vector""
stubthreshold: ""2000""
thumbsize: 4
timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
uls-preferences: """"
underline: 2
usebetatoolbar: 1
usebetatoolbar-cgd: 1
useeditwarning: 1
uselivepreview: 0
usenewrc: ""1""
userjs-curationtoolbar: ""hidden""
variant: ""en""
vector-collapsiblenav: 1
vector-simplesearch: 1
visualeditor-betatempdisable: 0
visualeditor-enable: 1
watchcreations: 1
watchdefault: 0
watchdeletion: 0
watchlistdays: 3
watchlisthideanons: 0
watchlisthidebots: 0
watchlisthideliu: 0
watchlisthideminor: 0
watchlisthideown: 0
watchlisthidepatrolled: 0
watchmoves: 0
wikilove-enabled: 1
wllimit: 250
wlshowwikibase: ""1""
```
--------------------------
**See Also**:
{T29471}",54542,5,Medium,
-0.48254298461242806,-7.42270576809229,-5.827477396919658,-8.231001860818711,-0.05072594643454731,0.7793788360468463,-1.4559154808513464,2.725160047878545,6.698403912627632,-2.8973498423561574,-3.288177432811824,2.131531964827305,-1.5663765337197653,1.5783386852581165,-0.34368127174273777,-1.3929206812681219,-2.6965702774601157,0.4231981329684158,False,c1,3,"when saving, there is possibility to check the result visually. allow to edit it.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T52687}",54519,4,Medium,
-3.2362127748589313,-4.70966705756684,-3.1142052052665523,-2.477282313184873,10.283613777771098,6.381035134873087,4.263664204112119,-2.6190405965564767,-2.2532438330959934,1.073443435262984,2.9162056771872495,-0.5857392458428653,-0.09747751558747897,0.9433682749281749,-0.22430966329752255,-0.1718142276606751,-0.09859539291612451,-0.5787322601749669,True,c1,3,"Greg also reproduced this. He sees a superscript, but I have an additional issue, that the beta is roughly the same horizontal position.
--------------------------
**Version**: unspecified
**Severity**: normal",54493,4,Medium,False
-6.749721308681779,6.248558571764956,-2.198780313863722,-2.809178791680646,-3.1313914874326794,-0.2280556382434319,2.2328746754094473,3.480344247179283,-0.08769851983419102,0.6773548900511317,1.3643427821927374,2.3119857479308017,0.45465985695519784,-1.4000770740051593,1.6186252245801507,0.915021516259124,-0.8131153595353223,-0.08767903665189691,False,c1,3,"en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
IF editor=""VisualEditor"" THEN do X ELSE do Y
--------------------------
**Version**: unspecified
**Severity**: enhancement",54471,4,Medium,
-3.982096048511962,-2.869321324805691,2.2238147825543066,-0.7992514483156961,4.841425971468064,0.934059794395645,-2.6071762913460685,-1.2568282304118892,2.8710832911209074,1.633509143004634,-2.781696719742644,0.32931618631374615,-1.1901870546526645,1.3872167502929376,1.238627135902994,0.10132285473872094,-1.6928970258259648,0.8386238559439765,False,c1,3,"What it says on the tin: The transclusion editor should have a ""cancel"" button next to ""Apply changes"". This would close the editor without saving any changes.
Possibly it should require a confirmation if one or more templates have been selected.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52386",54462,4,Medium,False
-8.602677182007161,8.418286314584417,-1.1030534180468603,-0.24182305133958293,-1.7773531203693047,5.063422453009769,2.1849216544164127,-0.15437540249267212,-1.0139910819733862,-1.246722656423331,-1.2237008980097481,0.2316205590107956,-1.4645211744087483,-0.10180635105716451,1.247619473899797,1.8792016357621846,-0.5734674276832019,-1.1295643821701735,False,c1,3,"User:Wouterstomp at en.wp suggests that in the media selection dialog, the full name of an image should be shown in a tooltip when you hover over it. Either for all images or only those whose name is too long to be shown in full beneath the image.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54459,4,Medium,False
-9.595645822740408,4.112351033061806,-1.7536005327314523,-1.417953698803011,-1.301372586452152,0.07824728686529125,2.3188091672157176,-2.5991888468601303,2.66383526605368,2.9678378334812345,0.06155535158185721,-0.7410063423992962,-1.8707254726884566,2.662319291964061,0.3769470694657784,1.512246855253046,-3.35346627695188,-1.394371300345982,False,c1,3,"en.wp editor GermanJoe suggests that if you try to add a template not in the transclusion editor's list of known templates that it should give a warning or ""are you sure?"" message.
Such a message would note that very new templates might not appear in he list.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54449,4,Medium,False
-6.2617747279048634,5.075537247833402,2.506090633707366,2.988491637909016,-0.7819508910150421,-0.7751667675576697,3.809255998952767,4.724163032272611,-1.9001799134894057,-0.36941254382323585,-0.14895055207961416,-2.7438852182990514,-0.013861255433417874,-1.66440590676451,-0.21096682065191885,0.0007003955093343173,1.7204608378178536,-0.6506589652297705,False,c1,3,"Currently the the transclusion editor's list of templates includes /Doc and other subpages of templates that are not themselves actual templates.
At https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_2#Removing_template_subpages_from_the_template_selection_list.3F there was a discussion about this which suggested possible ways forward:
* Exclude all subpages except those explicitly marked as templates, e.g by magic word or category
* Include all subpages except those explicitly marked as not being templates, e.g. by magic word or category
See also:
* {T52512}
* {T58516}",54448,4,Medium,False
-5.4635088789188595,-0.311029535222632,-6.581750037622529,-0.8624650898283654,2.3378951227073497,-0.15308139750010918,-5.468461107218757,-0.379156382560504,-4.191033704176825,0.1873335506007292,-0.15053520033833356,-0.12695814448131437,0.8186088416798945,0.5587960748417,0.033001652329874176,-0.3770524838633099,-1.166680262809721,-0.17127399591414316,False,c1,3,"I was able to produce a reference labelled ""0"" in the VisualEditor using the following steps:
1. Create a simple page with some text and a reference. (I've made an example at [[User:Mr. Stradivarius/ref0]].)
2. Copy and paste the reference to somewhere else in the page.
3. Delete the reference from the text that has just been copied and pasted.
4. The first reference is automatically renumbered to ""0"".
The numbering of the first is fixed (back to ""1"") if you delete the line of text that you were on, but if you add new lines of text the first reference remains laballed ""0"" even if the pasted line is subsequently removed. The numbering still starts at 0 if you add another reference, so you get ref ""0"", ref ""1"", etc.
This is on Firefox 22.
--------------------------
**Version**: unspecified
**Severity**: normal",54446,4,Medium,True
-5.888611519132857,6.572032276148011,3.3475553656455688,2.1289237347040104,-1.0274524931379618,2.819905943955571,-0.676009225630926,0.2977089546658991,-1.009043963152282,0.09958924777491873,3.914130114876808,-2.1413858803904837,1.3583282206058342,0.8757067446319304,-0.8935494047807255,0.21088135351524911,-0.9328749980692997,-0.811826141456303,False,c1,3,"When the first line of an article is a hatnote template that generates exactly 1 line of text in the visual editor, pressing down twice takes you to the end of the article. When the hatnote template generates more than one line then pressing down takes you to the end of the first line but no further.
I have been unable to reproduce this with templates other than hatnotes.
Steps to reproduce (short hatnote):
1. Load a page with a short hatnote in VE, e.g. [[Laurence of Canterbury]]
2. Press the down cursor twice
Expected behaviour: you end up on the third line of the page
Actual behaviour: you end up on the last line of the page
Steps to reproduce (long hatnote):
1. Load a page with a long hatnote in VE, e.g. [[An American in Paris]]
2. Press the down cursor three or more times.
Expected behaviour: you end up on the third or fourth etc. line of the page
Actual behaviour: you end up at the end of the first line of the hatnote.
Sandbox pages to test:
Long hatnote: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=566827194&veaction=edit
Short hatnote: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox2&oldid=566827110&veaction=edit
This might be related to bug 51708
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51708",54445,4,Medium,False
-2.5182408512956718,3.0787273396913513,3.2679599309489795,0.4453464121757731,4.13381497946496,-1.1449155080543454,1.5723011841599552,1.1783969668897423,0.0030018460686885295,-0.34851247225866633,-1.147685849423664,-0.2658742194264564,-0.9893350027717798,1.1909237336859055,-1.4038301290171447,0.6856117075028922,1.3592934264726104,-2.9119933060157313,True,c1,3,"Flagged Revisions provides a number of edit notices about the status of the page being edited, but this one (about the status of the transcluded components thereof) isn't. This feels wrong. It also means VisualEditor can't warn people about it.
--------------------------
**Version**: master
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52280",54440,4,Medium,False
-8.577001192189059,4.922397101542799,-1.192311057333276,1.6840601590853872,1.5003090530419572,2.5244970296060085,0.7396420380767008,2.0627721257207976,-0.8904391926643757,-1.166786060326897,-0.3595530589376046,-0.5523724542437942,0.8899744845559119,-0.9116862270284289,-0.2970724852090143,-1.0157988712990957,-0.8900378328705879,-1.3895361360141554,False,c1,3,"Screenshot of problem
When the link inspector is fairly tall and the space somewhat narrow (e.g. a red link, 10 suggestions in the inspector, and the link itself is towards the bottom of the screen), the box will expand further than the page goes (triggering a scrollbar if needed).
That's fine, except that it is hard to see for the user whether there is more or not. Especially with OSX hiding scroll bars by default.
There should be some bottom margin so that it can be clearly seen that the bottom of the list is the bottom, ans eparated from the bottom of the (now expanded) page.
See attached screenshot.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11124}",54436,4,Medium,False
0.3817663354833094,-1.100196501112352,-0.35528507306767665,-0.9600191451448554,-0.5866652634881381,1.0824007254369967,-3.7387433649584674,-0.03115687575733045,2.6020288623033085,-1.4851276739383956,3.0990935475634154,0.4917673319583977,-0.6945694505569806,-0.9292183767355988,-1.7846086810221533,0.43237050941102395,-0.016152955070676933,0.039780951325108616,False,c1,3,"Pressing enter at the end of a colon indented line and typing more text displays as an indented, but, on save, (and review changes) the colon has not been added to the new line.
Steps to reproduce:
0. Start with a simple colon indented section. (See here: http://en.wikipedia.org/w/index.php?title=User:Markhurd/Sandbox&oldid=566721115 )
1. Edit with VE.
2. Click at end of last indented line.
3. Press Enter. Note this displays as continuing the indentation.
4. Type some text.
5. Save. Note that the colon is not included. (You can see it missing with Show Changes.)
My diff: http://en.wikipedia.org/w/index.php?title=User:Markhurd/Sandbox&diff=566721183&oldid=566721115
--------------------------
**Version**: unspecified
**Severity**: normal",54399,4,Medium,
-5.5111458291476545,3.2458180650313686,-1.8964487161431869,-4.554320652160907,1.7267793163823106,-2.8997724383681502,-1.5162643758197678,-3.0839875404234136,2.3450517366184673,0.658964702928432,0.255337966695774,-1.862395761480425,0.7755812617309239,-2.9691018763134105,2.7050985207583986,-0.7496989124321927,2.2755935301605685,-1.4155060407668518,False,c1,3,"It isn't obvious to all users that clicking on the warning about Wikitext will make it disappear.
For example, PamD at en.wp said:
""I edited an article and found I'd got the popup saying I'd been using wiki markup, I should go into Edit Source, my edits wouldn't be saved, etc. I knew I'd input a pair of ''s at one time but had then remembered the error of my ways, removed them, and marked the title as italic in VE style, so was pretty confident I hadn't used any wiki markup and went ahead and saved the edit (difficult because the popup was sitting on top of the savepage box).""
The main issue there is Bug 52155, but after being pointed to that bug she replied:
""so if I'd clicked on the box it would have gone away... ? Not obvious!""
It would be good to add an X in the upper right corner to indicate that it can be closed. This wouldn't change the behaviour that clicking anywhere on the box dismisses it, just give a visual indication that it can be done.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51701
https://bugzilla.wikimedia.org/show_bug.cgi?id=52462",54386,4,Medium,False
-2.719941753712008,-1.9189654022435736,6.6752599967563775,0.014475697643951069,-2.2585022675949444,-4.1867534891122755,0.8807276529362067,0.6540780150510079,-2.1545379713381285,-2.0361673968800114,-0.8966954519538706,0.42295108314943985,-1.621191574257133,-0.0023938975659758555,-2.0292006164580405,-0.1968243536702141,-1.3763640193906952,-0.4201845978848935,False,c1,3,"In some cases it seems that <references /> is not fully populating the references list while {{reflist}} does.
Example at: At https://en.wikipedia.org/w/index.php?title=Christian_Scott&oldid=566681769
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50094",54371,4,Medium,False
-7.184376110754105,4.669174216848628,2.1912787680336123,4.500630308623684,1.4744062718214583,-0.40441887679111943,2.1382423442348744,6.2722800441983555,6.322279850962206,1.9639537022996176,2.973401955828851,0.08650935261967718,1.3703762708873808,-0.8945812864600331,0.39991836076412657,0.859996658349122,1.462379978215435,1.5825352000584043,False,c1,3,"Random idea that might improve load performance: initially alienate the entire document, then progressively convert and dealienate it. This should bring the editor into view quickly and allow the first paragraph to be edited quickly while the rest of the page is still processing.
Possible pitfall: reference numbering and other crazy stuff in MWReferenceNode
See {T76544} for the same idea, but for content blocks.",54365,4,Medium,
-3.148858395056696,-3.790164725555652,-6.194756533890235,-2.698293285773694,3.247271302827708,1.1219195610002533,-1.297607149019779,2.1603324677693365,-1.7536348413461924,-1.3600413070301265,-0.08785310472708074,2.9876893428464966,0.44082357226373947,-0.08706191073213532,1.084242102340621,-1.8202033540917726,-0.7489608877695083,-1.4491036074527446,False,c1,3,"en.wp user Cryptic C62 comments:
""Take a look at the text this page. The first two sentences may appear to be identical. If one activates VE, one will find that the first sentence (which employs <tt>) cannot be edited, but the second one (which employs <code>) can. My question is this: If the editor is supposed to be visually intuitive, why are two (almost) visually identical elements handled differently? ""
The page referred to is: https://en.wikipedia.org/w/index.php?title=User:Cryptic_C62/sandbox&oldid=566625027
--------------------------
**Version**: unspecified
**Severity**: enhancement",54352,4,Medium,True
-6.533072528875106,-1.2581866301528777,-0.7831486986975502,-0.8977851516265846,1.3330270220804834,1.4763315293998833,0.28511405799488276,0.41986988828033445,0.08337505247798827,2.476257222132193,0.8840047138424594,0.3082454704607369,1.0628825955791354,-1.724151919650808,0.42694343485412034,2.3111410353447384,-2.3103111051588123,-0.8076016457608293,False,c1,3,"It is possible to insert a substituted template (by just putting in ""subst:whatever"" as its name). This will be saved correctly (substituted), but the diff shown in the review dialog shows the non-substituted wikitext.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53201",54345,4,Medium,False
-3.97723470299463,3.049834643575057,-1.197778275729469,0.8202516046952766,3.3622968450085993,0.059914660170486966,-0.9599454945928194,-1.784883108772076,-1.6908275549914367,-0.08664581770858248,1.626649715570133,-1.999973478607537,-1.1246157902366871,-1.2208624205778396,-0.8068373056427065,-0.8015644379309452,3.1532567210304343,-0.6656519505788407,False,c1,3,"en.wp user User:Timwi reports
""On the page [[Earth]], we had the following markup code:
[[File:(filename)|thumb|700px|center| (caption here) |alt= (alt text here) ]]
The VisualEditor parsed this incorrectly and assumed that “alt= (alt text here)” was the ''caption''.
Changing the order of the items fixed this despite having no effect on the rendered page, which indicates that it’s a bug in VisualEditor and not incorrect MediaWiki markup."" http://en.wikipedia.org/w/index.php?title=Earth&diff=566614668&oldid=566595613
I've done some testing in my sandbox and it seems like the issue is somehow related to the presence of the {{val}} template. I wasn't able to replicate the bug with the {{small}} or {{convert}} templates for example, but I've not done extensive testing with the latter or with any other template.
https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=566618437&veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid-lb.eqiad.wikimedia.org/enwiki/User:Thryduulf/sandbox?oldid=566618437",54341,4,Medium,False
-0.02311284310964945,-16.118580996292284,0.8266417035311058,4.859425619474436,-2.183630774203194,0.4441113112187962,3.761360757755612,-2.225574147049964,1.4400011385557352,-1.1674328874179003,-2.0988797116544564,-0.4211600870772759,-2.0940317494500187,0.008465635534553151,0.28998346170740863,-0.2757699477945228,0.1724552305262388,-0.12875303171953867,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: minor",54327,4,Medium,False
1.8171920588180641,-4.629877740455399,4.620089568193727,4.501799494638282,-0.6112395813981332,1.5950807342186282,0.30289435604347936,-1.8880544319336057,1.1038530204597414,-1.1575880195975792,-1.1868979923665577,-0.024110452133664806,-0.1474619695439756,-0.2615416225641898,-1.8682743137193674,0.48096429031573684,-2.142922438207415,-0.15779551671990766,False,c1,3,"Screenshot
Adding an image with caption besides a list creates whitespace in edit mode, see screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/116._Panzer-Division_(Wehrmacht)
**Attached**: {F11788}",54320,4,Medium,False
2.717413043670875,-3.403908905500744,4.330383775763728,2.647032612634246,1.033769609348488,-0.38078032962768893,0.19693331692066263,1.3894989474869957,-2.658153044724413,0.609440007461389,-1.588827001757436,-0.16651274806841632,1.7109086937129638,2.0885069144918136,0.19794708434217956,2.0729389443243535,-1.9975065280316895,-0.6440308895096671,False,c1,3,"**Author:** `kwwilliams`
**Description:**
In http://en.wikipedia.org/w/index.php?title=List_of_record_charts&oldid=566209687, notice how Note 1 gets transformed in the string ""1.0.1.1"" and the actual contents of Note 1 becomes reference 19, which is completely unused in the article body.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53486",54300,4,Medium,
1.9778250611443142,-8.722025037044752,-1.636789119353388,0.7826063351699291,2.5416690757578912,-6.526995899011884,-3.3406735350322454,0.06739440884235293,0.05545692914069239,7.4932667033882865,-4.721685320331419,-0.3890170440525068,-1.0203700641976967,2.3769765879033837,-0.18269213691453867,-0.7529423073934611,0.9600746680307404,-1.569685606009354,False,c1,3,"When we edit using the visual editor, we still get
mw.config.get( 'wgAction' ) === 'view'
instead of
mw.config.get( 'wgAction' ) === 'edit'
See also
http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070603.html
which quotes
http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070601.html
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
* {T53421}
* {T55746}
* {T55441}",54281,4,Medium,False
-3.010400007819604,4.047852323099718,4.676376680536638,4.850678057857274,7.526811934943227,2.3138574526966327,0.18060082637393648,-0.5274922884159283,-1.0640871714292703,-2.5798823744826227,-1.9863193327834467,1.4561498583320807,-0.9989379635713815,0.7031430944486035,-1.7064211574892778,-0.10570506712618477,-1.7262466363832352,1.0812384773491879,False,c1,3,"When a page has pending edits and it is opened for editing using VisualEditor, there is a dropdown box with a notice about this. When a page has a template or a file with pending changes is opened for editing, the dropdown box does not appear.
An example on the Russian Wikipedia:
https://ru.wikipedia.org/wiki/%D0%98%D1%80%D0%B3%D0%B8%D1%88
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52440",54280,4,Medium,False
4.401102202855959,3.1034698617991907,1.5676079926115705,-0.8477716440655538,2.2605323644766737,5.483222366798154,1.5618029599458865,-0.5761626731578495,-2.8031049930288496,1.0289822767608348,2.579789280635962,-0.13163849055665966,2.0870270585311497,-1.217176121345691,0.27682741819331547,2.036431407965943,-1.117308867478487,-0.49882665807266613,False,c1,3,"When an unmatched literal square bracket is used in the title of a reference, Parsoid or VisualEditor encloses it in a nowiki tag.
Example on the live wiki: https://en.wikipedia.org/w/index.php?title=Wikipedia&diff=566045928&oldid=566042453#cite_ref-209 (line 360)
Examples in testing: https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=566402676&oldid=566401436
It is possible this is a reappearance of or related to T45067
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T45067}
{T52331}",54268,4,Medium,
-4.182026669205199,2.7427230591226923,0.5242334121362333,3.7344215846251085,1.5327985110153741,7.721841298161272,0.7167471210723377,-3.7703660440115585,-0.3790228040281325,-0.6592861906039387,0.13836959292444684,-1.911853746721963,-0.07661229264572711,2.748212347549794,-0.21616848899575558,2.0306327931569634,-0.6829760787166322,-0.8437021818605899,False,c1,3,"**Author:** `sandrobt.wiki`
**Description:**
The (visual)edit button in a diff (such as http://it.wikipedia.org/w/index.php?title=Kawakami_Gensai&diff=20609681&oldid=18301858) makes you edit the last version (in the example above the edit button gives the link http://it.wikipedia.org/wiki/Kawakami_Gensai?veaction=edit), whereas clicking on edit source makes you edit the old version (the newest of the two compared versions).
--------------------------
**Version**: unspecified
**Severity**: normal",54261,4,Medium,False
2.203290072235079,4.023146196473828,7.4566626945626915,1.842277168797669,-3.3662999346629334,1.6736255867966536,-2.1545484686456353,1.0604294958300975,1.03577565937208,0.7145701534406346,-0.8959506893807032,0.25056239652118717,1.9144051266316997,0.501393995948213,-0.9263113540584156,1.828299399608658,-0.8315293693711613,-0.56084449304873,False,c1,3,"Steps to reproduce:
Go to any page that is a subpage, such as a user sandbox. Observe the link to the parent page, located just under ""From Wikipedia..."". Activate VE. Observe that the aforementioned link disappears.
Found in firefox 22, chrome 28, in both monobook and vector. Screenshot at https://en.wikipedia.org/wiki/File:VE_Phantom_Link.png
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54325
https://bugzilla.wikimedia.org/show_bug.cgi?id=58063",54243,4,Medium,False
-5.231263831977694,3.4958516601542904,-1.6992806826798006,-7.340450933821567,1.915477519028888,-1.4570705574955358,0.8544517596948582,1.104424925273213,2.4091764311020336,0.3467402464570908,0.37387380829383776,1.6512476991352611,-0.3379259991117003,0.09054233427152525,1.2312665673118595,2.927245702026826,-1.9347438127467873,-0.9046722406204639,False,c1,3,"When you copy & paste a link into VisualEditor, it will not be recognized as a URL, but will appear as plaintext. The MediaWiki parser does render it as a clickable link, of course.
This is annoying especially for references, because you might be confused why your link you're adding as a citation doesn't appear to be clickable.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52204",54241,4,Medium,False
2.4649153137011726,1.8807196603326233,-2.853156605559775,-0.9449626474435837,4.21646387664569,1.6157031604339955,-4.461623237642429,5.426756530512793,-1.0566086263768164,2.2777933700625725,0.10359566718155921,-0.5629359194954796,6.071134340977882,3.5553254588461556,1.7362170857646362,1.9183434619744166,0.674139313003226,0.847913591027446,False,c1,3,"Adding ""ISBN 0-471-17864-0"" doesn't render the ISBN as a link. This is more important in the reference tool, but should work on all rich text surfaces.
See also:
* {T54241}
* {T63558}",54204,4,Medium,False
-3.067023636014984,2.5605913740823247,-0.347940478244146,0.9502654473643415,4.866182916559911,3.4883930064454267,-0.20785696261991493,2.5467341404102366,-2.3081727732877297,-2.606350885492676,-1.6683788438989882,1.3084860138279748,0.4287265891496328,-2.784847839064598,2.8415626177689175,3.2274245436583073,-0.9181200528005421,-0.6350178714319594,False,c1,3,"**Author:** `wikipedia`
**Description:**
When a file is deleted and still is being used in an article, this file is shown in the article as a box with a red link in it. Starting VE to remove the link, the link is no more visible and thus cannot be removed.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7",54186,3,Medium,False
3.345694463982405,-3.250338461544379,-1.3435997499356453,-1.8305862413137945,3.2112876124171006,1.082123430894961,-2.8141303899792716,2.591324441054122,2.065554338626126,-1.3472641915249008,-0.4847354194446569,-0.47976181156467446,1.229703632641589,1.1638203795032247,-0.17946730478317363,1.2934405752755864,-0.5473330886000028,-0.24385509561671537,False,c1,3,"**Author:** `jonathan_haas`
**Description:**
Steps to reproduce:
1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
2. Position the cursor at the start of the page directly before the bold ""T"".
3. Hit Backspace (to delete infobox)
4. Hit Ctrl+Z (undo)
5. Hit Backspace again
6. Hit Ctrl+Z again
Repeat as long as you want
Actual result:
On each Ctrl+Z a paragraph more is selected
Expected result:
Selection stays the same, undo should undo the action and not change the selection
--------------------------
**Version**: unspecified
**Severity**: normal",54184,3,Medium,False
-7.137890653623839,-0.36770288624822456,-2.631113912332255,-0.41627449748780365,1.1721357969025525,3.0951810876225485,-3.5838945196692378,0.5401403654627525,4.354350223967138,-1.7190459318220066,1.3548121752377589,1.2303974912110347,-0.15239376239216806,-0.9408179010914246,0.5039088457436876,-0.1501607754090311,-1.2626415982538604,-0.714860671244745,False,c1,3,"Removing the content from out of a <ref> .. </ref> should prompt the user that they need to delete the reference. Perhaps a tooltip, or this might be an opportunity to use a hover trick to give the user something to click to acknowledge they intended to delete the ref.
It shouldnt be possible to save with an empty ref, as that is an error condition.
https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&diff=566133128&oldid=566132993
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50609",54182,3,Medium,False
-4.9076833188153435,7.27346971124642,-1.9913216481695724,-2.226389879985798,1.1786805758465808,-3.5139122667662255,-0.523945214986651,-2.7535488340612537,-3.688415566056947,5.424076357242791,-2.498005132232551,-1.4377832999151428,-1.1829242844684398,1.1700242732985942,-0.4029045316217692,3.752917414030351,1.2887908483459867,2.9813727644347114,False,c1,3,"If VisualEditor is default, why after clicking on a red link there's 'action=edit' in url and the source editor runs instead of 'veaction' and VE? I've checked it out on the enwiki and plwiki, but it concerns the rest of phase 2 as well and creating a new page in general. Furthermore, it makes inputboxes ('type=create') incompatible with VE and it can be a bothering problem on some wikis.
**See Also**: {T55441}",54162,3,Medium,
-0.7872776260531951,3.278102287850448,-1.0310006315224403,-2.3937114791232825,-1.6808177292407516,2.4547419930112406,1.2029404771330343,-0.8729362572522134,-0.5132067811786958,-2.6016501529744427,-2.9082604415584346,2.3992393271540857,-1.6765421359009718,-0.3072179124892669,3.4949545814005107,0.5857094213908632,-0.8359036559813484,-1.7011390552088619,False,c1,3,"An editor on en.wp has requested that Ctrl+Y should initiate the redo action. Presently the shortcut is ctrl+shift+z.
In my experience both shortcuts are used in about 50% of applications (Xubuntu Linux) so it would be ideal if both shortcuts could be used.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54140,3,Medium,False
-6.126525124061521,-0.9514719035355395,-3.8676236698598725,-2.014658456275166,-3.3336095542293487,-1.611949935568406,-0.5045615742734313,-6.930246578780026,-2.1114387036217193,4.162649995489428,-0.5561675155974926,-1.5426418128326438,1.1052774259030893,-1.9945148550083576,0.22890155196653517,2.9895174048660134,2.4857498516683547,3.1185306643614927,False,c1,3,"We overuse both ""index"" and ""offset"" in our vocabulary, and one of the more cringe-worthy results is the rename of .indexOf() to .offsetOf() in AnnotationSet. We should refactor our vocabulary and rename this to something saner.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54130,3,Medium,
0.8913395653909686,-2.283053789558698,-4.838712114536319,-1.8647719579291961,-5.323047649388096,-2.395027857017487,-0.5977567474458816,-3.1595649612115566,-1.7990857049341813,-2.585855160163778,1.3675297551520615,0.39533761198931416,0.5536811756839919,0.32639364136615967,0.94671941520759,-1.34326401971783,-0.06392145812246919,1.2336679354258517,False,c1,3,"**Author:** `nzmoihue`
**Description:**
I think one nice/needed addition to Visual Editor would be supporting custom wiki defined scripts for fixing text [without interfering with wiki text]. For example on Persian Wikipedia we have an edit tool script [1] [2] that wiki users are very depends on it for fixing article texts and without it Visual Editor would be useless for them.
1. http://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%A9%DB%8C%E2%80%8C%D9%BE%D8%AF%DB%8C%D8%A7:%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C_%D9%88%DB%8C%D8%B1%D8%A7%DB%8C%D8%B4%DB%8C
2.http://fa.wikipedia.org/wiki/MediaWiki:Gadget-Extra-Editbuttons-Functions.js
--------------------------
**Version**: unspecified
**Severity**: enhancement",54122,3,Medium,
0.5755415634021039,7.463573955241831,4.830773505518781,-0.17125758848374673,-0.19943287005134414,1.5340175029642984,-1.0341018861258542,6.328299925884814,4.380170623227809,0.20814575317044337,0.7257383952693801,1.9738184956019198,1.4966953521422806,-1.7965321532855953,1.1575908092197826,-0.8887238142199074,-2.4804207327041503,-0.26078745731681474,False,c1,3,"People would like to be able to edit the language links that are coming from Wikidata in the page settings dialog. A link from there to Wikidata would probably also be a good first step.
**See Also**:
{T59929}
{T64005}
{T74178}",54105,3,Medium,
-4.649515271773141,-2.097659130059652,-5.735843364310176,-4.971816949701767,2.8711712021094096,0.490805849735211,-0.5511309154002708,-0.0749266237126004,1.0031421009722712,0.07881311526845725,-0.16476300797923615,-0.26318719436048577,0.8200349193576626,0.2788386023164193,-2.417575742110427,-0.5555235906672433,-0.4497478099268174,0.20195080215235195,False,c1,3,"**Author:** `molly.white5`
**Description:**
Twice now I've uploaded .ogv files (made with RecordMyDesktop, if that helps) and gotten a popup that very helpfully informs me, ""loadImages bad"". This appears directly after I choose the file to upload, and I'm guessing it has something to do with the inability to find a thumbnail image? Anyway, at the very least a more descriptive error message might be nice.
--------------------------
**Version**: unspecified
**Severity**: normal",54070,3,Medium,False
-2.5296674991417523,7.662946464703584,-0.7126922400374447,-3.323771090847415,-4.994783922380261,8.93656100879047,-0.3901442204478389,-2.792749517590184,1.3966453859222872,-2.349278222288062,-2.984985836523335,-0.8967802002718828,-2.174637468875501,0.6580047987307633,3.2263168037871486,0.016916086812820808,1.077176579186607,-1.0237542315920676,False,c1,3,"The rendering of a page can be affected by user extension options (e.g. their choice of renderer for the Math extension) so we should be able to pass through these options to the API.
This is blocking proper support of the Math extension in VisualEditor.
--------------------------
**Version**: 1.23.0
**Severity**: normal",54031,3,Medium,
-1.085343293771483,-2.9630589444398066,-7.621244172783493,-5.217193841079291,-0.7444656004367498,-3.7893469904713575,-0.17538674324974046,-0.1483403367612837,-0.09205661748238853,-1.428997234277377,0.9899309191565879,-1.2455182484143485,0.8110153125098338,-0.4735170433876883,-0.03326174574054441,0.033006784624274144,1.286808374645558,1.2171361602941533,False,c1,3,"Following the documentation[1] starting at ve.ui.Surface (from ve.instances[0]) one would go to #getContext and access .toolbar. But though that property is defined, it is set to null.
I'm not sure why, but apparently our MediaWiki's init is instantiating its own and is only accessible from ve.init.mw.ViewPageTarget#toolbar (ve.init.mw.targets[0].toolbar).
It probably shouldn't have to instantiate its own one, and certainly not make it inaccessible to the rest of VE.
[1] https://doc.wikimedia.org/VisualEditor/master/#!/api/ve.ui.Surface
--------------------------
**Version**: unspecified
**Severity**: enhancement",54011,3,Medium,False
3.4542742996992897,-3.421419738508936,0.20703036765007,0.8765131935761918,4.184115382777021,0.3674426704225924,-3.0715050791529497,1.3617089751569122,0.2335704879110212,2.8211824162489965,-1.083381393309485,2.7460815655290993,1.6709787944081476,-1.286230099010918,-0.5896490246089776,0.7786958680774262,0.4334447622439621,1.0052294995962028,False,c1,3,"It seems that Chrome 28 does not display the ""Minor Edit"" and ""Watch This Page"" checkboxes on the save page form. This does work in Firefox 22. Does not seem skin related - Vector and Monobook have the same problem in either browser
Steps to reproduce:
- Open any page in edit mode.
- Make a small change, press Save page.
- (Firefox): There will be checkboxes stating ""Watch this page"" and ""This is a minor edit""
- (Chrome): Those checkboxes are not present.
--------------------------
**Version**: unspecified
**Severity**: normal",53981,3,Medium,True
-2.308854366864956,-4.451714364567497,-1.0662965104419442,1.9375722135063107,3.867258129745007,-1.4791532443482018,-0.022906375204614804,0.7785508940529616,0.0290084557528964,0.23053490479961258,1.9728598035213172,3.3529566354962084,2.556955048481108,0.4516555380111438,-0.4327132540065497,0.5523685738426625,-1.0818344371492559,-0.8337071540608822,False,c1,3,"English Wikipedia user Atethnekos reports:
""If I make 2 changes, review changes, exit review/save dialog, undo last change, and then review changes again, the review shows both changes, though saving only saves the first.""
Steps to reproduce:
1. Make two changes to a page in VE
2. Undo one change
3. Click save and review your changes.
-Expected behaviour: Only the first change is shown
-Actual behaviour: Both changes are shown.
4. Save the page. Only the first change has been saved.
This means that the review your changes is incorrect.
--------------------------
**Version**: unspecified
**Severity**: normal",53947,3,Medium,False
3.6418936267050923,0.9869243060704562,-1.3429374849800588,-1.021084145169254,2.7178386321863788,2.884036338280156,-1.6450555808617953,-1.7938853392220167,-1.9850021277813448,-0.5894166132096172,-0.37331818808745965,-0.9582495237639115,2.2845680576337095,0.30357029331891283,-1.396116644437127,0.9397246157989473,0.4615803975322714,0.6251131731809194,False,c1,3,"Reported by Atethnekos on EnWiki, who also provided an image: https://en.wikipedia.org/wiki/File:Platovesample1.png
""When I edit a page with the pending changes revision dropdown, and I am scrolled to the very top, the dropdown and the VE page settings link become mangled. See highlight in included image. Firefox 22 on Win7 Pro SP1.""
I can reproduce this in both Firefox 22 and Chrome 28. The issue seems specific to the Monobook skin - Vector renders the pending changes dropdown somewhat lower in both browsers.
--------------------------
**Version**: unspecified
**Severity**: normal",53926,3,Medium,True
-1.6710125364885096,3.237566015758027,-0.4024796515674911,2.102442254576506,-1.9512107669484087,-1.0589183022556192,0.19708315134588794,-1.855282415925704,-2.759295540225671,-0.7189662538672392,0.6553428299596704,-0.5328365180999539,1.7109892609764894,0.6782083440449869,1.2909047694385443,1.444608978832739,0.9573193162741702,-0.5076733129535822,False,c1,3,"Wikitext appearing in transclusion dialog
The underlying cause of this might be covered in bug 48231 or bug 51217 or others ... I thought I saw a bug about this, but cant find it now.
[[template:multicol]] with wikisyntax inside it results in the attached screenshot, with wikitext visible in the transclusion dialog as 'Content' blocks.
https://nl.wikipedia.org/wiki/Gebruiker:John_Vandenberg/test?veaction=edit
Section headers & list items also cause this; see the last block here:
https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&oldid=565567699&veaction=edit
If it helps, this issue is present on one of the parsoid topfails:
https://nl.wikipedia.org/wiki/Eerste_divisie_1996/97?veaction=edit
BeginKolommen occurs on nlwp 3047 times. 11362 times in enwp. 8861 times in eswp. 40985 times on itwp!, which is roughly 4% of the content pages.
Confirmed this is happening on every itwp invocation that I edit
https://it.wikipedia.org/wiki/Speciale:PuntanoQui/Template:Colonne
e.g.
https://it.wikipedia.org/wiki/Aeroplano?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11763}",53922,3,Medium,
-11.691633781701656,8.632837492542599,-0.9980465137953818,0.1418384769981471,3.396166668042541,1.6841960299814625,0.19780639492754215,-0.27705971138888885,0.9507859223931776,-1.848236848334719,-1.0559061648425696,-0.5651834313840249,-0.37956382672977007,0.06666588745275792,0.5468857497972595,0.45279298476090835,0.26938104432352095,-1.2195715377753538,False,c1,3,"The bug 51905 made me realize of a potential problem. When a media, say an image, is inserted, sometimes it may be inserted outside the field of view of the user, and this may lead some users to think that it wasn't inserted at all, causing aborted edits, confusion, frustration, and even bad edits. For example if there is an infobox in the article, or a bunch of images aligned to the right, then if the user inserts an image, in many cases it will be inserted below all this, and the user will not see it without scrolling the screen.
The solution to this potential problem is, I think, fairly simple: make the VisualEditor detect if the image is in the field of view of the user, and if it's not, then scroll the screen so that it is!
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58091",53911,3,Medium,False
-5.980742632287781,2.0487965573313183,-1.2490131841641183,4.151900181171768,3.4323062593494327,3.3786908617093925,-2.4622044297918273,2.6588491735259927,1.3859878936345098,-1.0713742324445024,2.0195714136797647,-1.7947038748520014,-3.383255272042863,0.3850059489791473,0.8220242352115488,1.6710073761616524,0.23400023406735526,-0.10751130879441329,False,c1,3,"When an image file is included directly in an article (i.e not as a thumbnail and not in a frame) with an unclosed <center> tag in the caption causes Visual Editor to not render any page content after the image.
See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox2&oldid=565498603 for an example.
All the following conditions must be true to see this bug:
* Image must not be a thumbnail or in a frame
* The image caption must contain an unclosed html tag specifying text alignment in the caption. Tested with <center>, <p align=""center""> and <div align=""right"">
* The image placement (left, right or center) must be specified
The bug does not occur with an unclosed italic html tag. I haven't tested with other tags.
--------------------------
**Version**: unspecified
**Severity**: normal",53893,3,Medium,False
1.166875407435176,1.4018876833092033,1.7284514059794773,-0.9187495601582822,-3.1204651706617805,-1.8621392268536372,1.0930767001808377,0.3808179330891659,-1.1401622985858086,-0.38444141460013803,1.9457104931880695,-0.7387361150000366,0.0953543440447362,-0.22880646121070924,-0.6260339518927758,2.7953038894941833,-0.3763533714409004,-0.38847986484190944,False,c1,3,"first table at [[Comparison of container formats]] rendered in a 1024px wide window. Firefox 22 on Linux
In VisualEditor the editing window does not horizontally scroll to accommodate wide tables. Table cells and their contents render as if the window did scroll, but as it does not they are truncated.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51755
https://bugzilla.wikimedia.org/show_bug.cgi?id=51820
**Attached**: {F11662}",53867,3,Medium,False
-6.497481194075521,0.8818497274239192,-2.6322143823822586,0.9398507764332229,2.2565082996858137,0.1768981520257249,-0.8467514836182009,2.8116007168776265,-1.9273023270703498,0.1674683460529458,-1.9457445128017732,1.632029494789154,0.8039152712903341,-2.4507085162810376,1.0100623500011832,-0.21132511148136324,-1.0099861499620408,-1.5777159740673066,False,c1,3,"When VisualEditor inserts an image, the thumbnail keywords are written in English: ""File:"", ""thumb"", ""right"" (but see Bug 51851).
This should not, theoretically, be a problem, because the VisualEditor is supposed to make these keywords unimportant and hidden from the end-user. However, while the source editor is still being widely used, this is a problem, especially for right to left languages: it is very hard to edit these English keywords when they are mixed with right-to-left text.
These keywords should be inserted in the language of the wiki.
--------------------------
**Version**: unspecified
**Severity**: normal",53852,3,Medium,False
0.6795649727236679,-4.771258412980613,-1.2916017819155527,1.265861346082854,0.3040649712115149,0.39872272798982467,-6.524782988338049,1.98586882324711,4.506583471802581,1.1815190598927785,1.452526786377501,3.2345612166793334,0.7118333707544928,0.9965983385572024,1.3062875344027054,-0.4701177996372442,-1.2335398636491768,0.17865316463970982,False,c1,3,"Steps to reproduce
1. start an empty sandbox (https://en.wikipedia.org/wiki/User:John_Vandenberg/mtgg?veaction=edit)
2. insert reference
3. use an existing reference
Expected results:
'Use an existing reference' should be disabled, as there are none to select.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50458",53848,3,Medium,True
0.09499336328274754,2.181104444803065,1.4802549759940717,2.8674456667458874,4.309573782090386,-1.7255786114662346,1.1922704037581218,3.7901453885443477,-2.0725137449097866,-1.3662807360779539,-0.4650514218869062,2.864690119515285,1.2316829743702566,1.405012511072762,0.3827634786693652,0.6050329477097448,0.7595843581005186,0.7051815986804202,False,c1,3,"Steps to reproduce:
1. Download and install Google input tools for windows www.google.co.in/inputtools
2. Open any page in firefox
3. Open VE
4. Edit a reference
5. Type anything in the reference. The word is input by the tools when the word is complete and one presses space/enter
Expected Behaviour:
The word is input and if the spacebar has been pressed, a space is input too.
What happens instead:
The word is entered recursively over and over. The space isn't input at all.
System environment:
Win 7 X64 SP1
Firefox 15.0.1
Google input tools for languages hindi and punjabi(gurmukhi script)
The problem didn't seem to arise when using input tools for urdu, though its possible that's just coz the wiki is ltr and urdu is rtl.
--------------------------
**Version**: unspecified
**Severity**: normal",53847,3,Medium,True
0.17010066197652085,3.172007107955025,0.13039193957186157,2.1818481938751972,0.2565892545135733,-1.48691190243279,-1.2894985169182878,1.5722004376869965,1.9074581405764228,-1.0639166631531323,-0.32463411219667915,1.6183067042943209,1.6434452947946716,2.7499347330190664,-1.7422574774446518,0.6311197152384194,0.709080828942968,0.2531425780903682,False,c1,3,"Steps to reproduce:
1. Open any page
2. Open VE
3. Type (or copy-paste) ग्र
5. Press left arrow key
What should happen:
Cursor should move to the left of the glyph
What happens:
Cursor stays there
System environment:
Win 7 X64 SP1
Google Chrome 28.0.1500.72 m
The problem arises regardless of what follows ग्र . I've tried with space, tab, the letter a, devanagari characters that do not combine with the glyph, like क, and devanagari characters that do combine with the glyph, such as ि to produce ग्रि and ी to produce ग्री
The problem doesn't seem to affect firefox 15.0.1.
In chrome, the problem doesn't arise in the link editing window, or when editing parameter of a template. It does, however, arise when editing a reference.
--------------------------
**Version**: unspecified
**Severity**: normal",53846,3,Medium,False
-5.012584700799741,1.5433778020113653,-1.9012311029590148,-2.501287228358574,5.103965669647529,-4.9638863380256435,-0.7188058694084996,-0.37021951476354265,-5.233668887262412,3.401207856701804,-2.3622050868900044,2.5429394198180653,0.33533251465727254,-0.5335808550228274,0.36068593594411524,0.7222988036830161,-1.720907621797723,-0.7673605901082954,False,c1,3,"The re-use tab in the reference dialog allows searching for group names. This was always possible. However, it doesn't work when the group name is uppercase or contains an uppercase character. For example, it works when the group name is ""note"" but not when the group name is ""A"". It doesn't matter if I search for ""a"" or ""A"", it's not found.
Turns out the relevant code is incomplete ever since it was written in 2013, see https://gerrit.wikimedia.org/r/70364. The relevant ticket was {T51733}.",53838,3,Medium,False
-4.074560547010916,-1.807749704435171,-2.5140205804138223,-1.5181729411888762,1.3094882545151028,-1.4427668327404886,-0.488924931410593,1.2738971058437887,-0.9856446050665827,1.553767267527352,-2.175939522452802,0.1806803336282523,-0.6271857427580985,-0.8185993081715548,0.5371514707803362,-1.7101064954125533,-1.7529899487325418,0.9610109232868609,False,c1,3,"Split from bug 51436, Original comment was:
""Also typing a word only shows template names starting with that word, not
containing it, which is a weird search behaviour.
If I type ""book"", template ""Cite book"" is not shown, which limits the search
functionality to be useful only for people who already know template names
(i.e. those who don't need it).""
A further relevant comment was:
""This is asking for VisualEditor ... to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.""
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51670",53822,3,Medium,
-1.7489828920454364,1.6837640884487577,-1.5288290660624977,1.0512257573262422,4.199420697004355,6.050678816417719,0.053620062742771424,2.724286565536089,-1.9626906677980924,-1.033593889865478,-0.13822290042252305,-1.6372368298139883,0.6176971052540594,-1.535436244660941,-0.406292337445759,1.3577690394693835,-1.312929559680693,-0.9320149878838286,False,c1,3,"The VisualEditor's user manual is translatable in Meta, which is a Good Thing. Currently the help link uses Special:MyLanguage. This uses the user's UI language as defined on Meta, which is likely not to be the same as the user's UI language on a non-English site.
As much as possible, the link should point directly to the user manual in the language that the user is using currently for the UI.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53797,3,Medium,
6.108705791683466,1.0766280505168488,2.7170796677420164,-4.202181930580359,-4.59462216813384,2.1333415578496044,0.42474079952599464,0.008702768223132984,-2.2745646641431447,-0.7483138806666316,0.015422124317420405,1.0149773833533067,2.2344220902261185,-1.3428383713720047,0.3139040653105116,-0.41054778796141533,-1.6048217743467188,0.31894596066710235,False,c1,3,"Tracking for VE issues of problems that are specific to a Wikipedia other than English Wikipedia, excluding RTL issues as they are tracked by bug 33126.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T51998}
{T51999}",53792,3,Medium,False
-8.203472180185011,3.8972399694741746,-3.191485368897231,1.1348095769589248,2.8929197604433035,-1.9124368716251463,-3.7381762423471367,-0.7544519670987226,-0.8256413065532225,1.8104528269138003,1.7212840025922316,1.311025833587456,-1.2836540279367865,1.8574971759254257,-0.09215841210678377,-0.8537680566421546,-2.4768613976335345,-0.19128150311486314,False,c1,3,"When you type ""[["" in visual editor, there is a ""wiki markup text"" popu (nice touch - Thanks, devs).
However, this warning popup shows at top of page, so it's not visible when the page is scrolled even a few lines.
VE toolbar floats at the top of the browser's page even when we edit at the middle of the article. the warning popu should do the same.
REPRODUCTION INSTRUCTIONS
0) open [[en:The Rolling Stones]]
1) select one of the sections from the TOC
2) Click ""Edit""
3) wait, wait, wait, wait...
4) close the edit notice
5) type ""[[""
EXPECTED
1) during the wait (3 above) there is a nice image asking you to wait: this image is expected to be visible
2) when the ""edit notice"" shows up, you expect some clear way to close it.
3) when typing ""[["", you expect the ""wikitext warning"" popup to show up
WHAT ACTUALLY HAPPEN
1) the ""please wait"" image appears, but unfortunately it's outside the screen, so you do not know why the page appears milky, and have no indication that this would eventually end.
2) depending on your luck, clicking on various parts of the page *will* close the edit notice (if you're lucky), or will take you to [[en:Template:Editnotices/Page/The Rolling Stones]] (i.e., another page from the one you are trying to edit) if you're unlucky.
3) the warning popup appears, but it's at the top of the page, so unless you are editing the very first part of the page, you do not see it.
COMMENTS:
1) VE is clever enough to have its toolbar visible even when scrolling down, using ""position:fixed"". same should be done for the ""please wait"" image and for the warning popup(s).
2) the ""1 notice"" and the warning triangle on the toolbar should indicate that they are the gate to hiding the notice: e.g., change the ""1 Notice"" text to ""Hide notice"" when the notice is visible.
3) it seems that the wikitext notice is not yet translated to all languages.
peace.
--------------------------
**Version**: unspecified
**Severity**: normal",53785,2,Medium,True
-4.8506201889124725,4.825846086122326,4.983356886644671,4.887887877968915,1.3458873871056725,5.651191712534005,0.5912991285175284,-1.473616390408738,0.3610564527138118,0.2865687325050912,1.3571584545033475,-0.2436261618130382,0.9700802779154039,-1.3147969248738987,0.3261464591655132,0.8762590348066027,-2.519221345167362,-0.4815396092965536,False,c1,3,"In an (un)ordered list nested in a table I am unable to edit wikilinks. While hovering above a wikilink the wikilink is an active weblink, instead of showing the icon of the link inspector, see URL.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://test.wikipedia.org/wiki/User:Raymond/nested",53778,2,Medium,False
26.834180083514237,-2.8622333514532574,7.447411749272543,-2.005004679868227,2.118041501807231,1.3824892723498865,-0.6335861080137635,0.36461986475337926,1.7281746823101878,-0.5277218905610637,-0.5085653818638867,-0.6262084324395145,0.37695353875309845,-1.317351082717896,-1.500026911856355,0.12123075451434343,-0.40547263979367054,-1.0370004098332832,False,c1,3,"From the mailing list
> from: planetenxin <planetenxin@web.de> via gmail.com
> reply-to: Wikimedia developers <wikitech-l@lists.wikimedia.org>
> to: wikitech-l <wikitech-l@lists.wikimedia.org>
> date: Sun, Jul 21, 2013 at 10:15 PM
> subject: [Wikitech-l] Git Proxy Error
> Hi folks,
> I'm constantly getting the following error on https://git.wikimedia.org/:
> Proxy Error
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request GET /.
> Reason: Error reading from remote server
>/Alexander
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51656
https://bugzilla.wikimedia.org/show_bug.cgi?id=49371",53769,2,Medium,False
-5.129811219407356,-1.7422947492898295,-2.6690713570567333,0.3073169548730559,-1.777569454784629,0.46304819382304063,-1.2748486304509665,0.3319721676527142,3.8563550774792033,-0.9253474134251762,1.072993922123604,-0.4008941776808683,2.9131917458806558,1.4396765012340431,0.39970289090830846,-0.6035004007099624,0.24247473274518105,-0.19578206910167784,False,c1,3,"Could we have a way to bypass the browser blacklist. e.g.
1. a user preference to ignore the blacklist during initialisation, or
2. ?debug=true bypasses blacklist,
3. a test-wiki where the blacklist is empty/ignored, or
4. a simple way to re-run VE init from JS console
This will allow mere mortals to help identify bugs with unsupported browsers.
For option four, we can modify the blacklist, like so:
JS> delete mw.libs.ve.blacklist.opera;
But im not sure what to do after that.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",53765,2,Medium,False
-11.943535270992808,8.661793143161294,1.638787570694685,6.672221771858511,4.522039299360152,6.493162358441312,3.4984621867426915,1.932243870125486,-3.096036563729932,1.7758840296627323,3.2278384393323596,-0.4075350903516902,1.2785623608907128,-0.7018312432083649,-0.9657359424972256,-0.655706633390512,0.16353561017449403,-1.110118610698567,False,c1,3,"When a page with blocks of pre-formatted text that use the leading space in wikitaxt is edited in Visual Editor there are various issues trying to remove the pre-formatted blocks. https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=565085889 can be used for testing.
* It is not possible to delete a block on the first line of a page
* When the pre-formatted block follows a mutli-line template, that template is deleted and the contents of the pre-formatted block becomes normal text on the line above where the template as, appended to any text that was already there.
* When the pre-formatted block follows a normal line of text or a single line template the contents of the block are appended to the end of that line.
* When the block follows indented text, the contents are appended to the last line of the indented block, even if that is a line that doesn't exist in wikitext (see {T52995})
* When the block follows an ordered or unordered list, the text is appended to the last line of the last item in the list
*When the block follows an image, the contents are appended to the image caption. This is probably depends on {T53624} and so I would expect the same behaviour with tables, but I have not tested that.
*If the block follows another pre-formatted block, the contents gets appended to the end of that block.
In all cases this can be worked around by inserting and then backspacing a new line at the start of the block.
In cases when there is a line of normal text, a blank line or a single line template before the pre-formatted block then pressing delete at the end of that line appends the contents of the block at the cursor position as normal text.
The differing behaviour of single and multi-line templates may be related to {T53708}
--------------------------
**Version**: unspecified
**Severity**: normal",53758,2,Medium,False
-6.8219274537341414,1.7781442795957823,0.16858874594221973,-0.18068915524596418,4.435279493605217,-3.065963063475401,0.15880832805742084,-4.080931776177177,0.1005954933913259,2.1483385117245364,-0.13553690989750233,-4.190517775010996,0.5282776754371699,-5.079932643818108,3.3840347088641733,-0.019480837032923193,2.781007962596532,0.30171011652343815,True,c1,3,"In my volunteer mode, I was removing content that was copied from an external site. I didn't add any content at all, but simply deleted text (and a template) and merged the resultant material into a single paragraph.
VisualEditor flagged this as my adding wikimarkup and gave me the nowiki warning. :)
See http://en.wikipedia.org/wiki/File:Wikimarkup_warning_without_case.png which is confusingly titled, because I missed the ""u"" in ""cause.""
--------------------------
**Version**: unspecified
**Severity**: normal",53751,2,Medium,False
-4.83494792055352,1.680307931954129,2.729319677195214,2.391735490221288,-5.668475846602172,-2.855641781426755,0.6874026055539204,-0.5714861724183169,-2.0773471935509034,1.9558808341903013,-1.8995644519657005,0.8219508596416654,0.5921502861786028,0.6213331972996832,-0.2146969446694751,0.010994920394897967,-0.897649125472205,1.701008599494301,False,c1,3,"As a follow-up to bug 49428 and bug 50771, default whitespace for headings should includespaces before/after ==.
Or in other words: prefer ""== Heading =="" to ""==Heading=="".
(While this might seem minor, the first style was enforced at pl.wp with automated tools since ever and editors gets annoyed when VE changes it. Reported at https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#sprz.C4.85tanie_kodu )
--------------------------
**Version**: unspecified
**Severity**: enhancement",53744,2,Medium,False
13.05754694179534,-0.1302713892827665,12.13129345803987,2.937838449400661,-4.567319234135482,-0.5412294317499461,3.525675484433596,0.4403763146775487,-1.0552164909824737,-0.0168772602597711,-1.1420751619280054,-1.8434877435477697,-1.4588129823782596,-0.41136665097805114,-0.5437740472397579,1.060507138753635,0.7005190851149232,-1.1250857255740954,False,c1,3,"**Author:** `lunarjam.mcgahan`
**Description:**
Wikipedia VE bug Reference with no parameter tags not editable in Chrome on Win7
See attached Word document Wikipedia VE bug Reference with no parameter tags not editable in Chrome on Win7
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11354}",53725,2,Medium,False
2.2008324042214773,-4.361743571196856,-2.7761128497532965,-4.082200486936935,4.74534554127885,1.2018756154245718,-1.4214846093801574,0.13691399735592769,-0.5966965006875068,-2.4959153001386616,2.5240409045627428,-0.5533681442285001,-3.101447548330043,-1.2790520565768766,1.6284027184672762,-0.20368704689944672,-3.0915745061932602,0.8836421923461384,False,c1,3,"When MathJax is enabled we should render a <span> containing TeX, instead of an image.
--------------------------
**Version**: unspecified
**Severity**: normal",53698,2,Medium,False
2.7429078293427644,-0.04871459075063633,5.724749429407307,-1.2949250256687257,-2.78199780749568,0.10110621699662237,1.2960963875692633,-0.10063350703080898,0.27817560529557295,-1.0348869790568727,-0.8945430596136554,-1.992318559221999,-0.0746526709310027,-2.5282805903981003,0.8383297393856921,-2.177156769240825,1.5422028712920735,-2.5865036270536423,True,c1,3,"http://it.wikipedia.org/wiki/Utente:Elitre_%28WMF%29/Sandbox?veaction=edit
This was actually discussed on IRC by Inez, subbu, gwicke on July 3rd, I might provide that part of the log if useful.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid.wmflabs.org/it/Utente:Elitre_(WMF)/Sandbox",53680,2,Medium,False
3.871163952423022,1.3440001736429092,-2.0689182251044134,-1.1043894718207141,2.1236352981731774,-0.39969429176047644,-1.6754519362318812,-0.0867187841225352,2.0217672776264193,1.3149237523366262,-0.06745662211408021,-3.246576123399672,1.69514641854654,-0.5235370722301891,-0.34554667710571874,-0.20211787649585466,1.228094634615491,-0.32788173030213974,False,c1,3,"An IP user on the English Wikipedia reports the following slightly alarming bug:
""After I edited text near a link, ""♙♙♙♙♙♙♙"" characters started appearing around once a second, and I couldn't stop them or delete them.""
Based on another bug report left a few minutes later by the same user they were using MobileSafari on iPad 2 with iOS 6.1.3
I can't replicate this in Firefox on a Linux PC and don't have an iPad to test on.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: other
**Platform**: Tablet PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50465",53677,2,Medium,False
-5.414142167707134,-3.730126073329071,5.85067198063766,8.062702520953243,2.14872806930926,1.1264747675119657,3.352255405017311,0.060824389527025624,-2.4996794549977244,2.1090932417777424,-0.7046795503007037,-0.08455686898646042,-0.9848375040438633,-1.1528291143674334,0.8636503518551955,-2.093399176829771,-1.623134401909029,0.6543296446282747,False,c1,3,"The parameter search is case sensitive, requiring all lowercase input
When searching for parameters in the transclusion/template editor the search returns ""Unknown parameter"" unless the search term is entirely lowercase.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11271}",53673,2,Medium,False
-3.961453443749303,3.0012670561677375,-0.05632628001398032,1.4682436640280505,0.3436948998802868,-0.7639028917378312,-1.965054483189694,1.9609510913770554,1.9070003874745602,1.7530202362756953,-2.4643295059452757,-0.4644805466381602,-0.5699564351654276,0.5813065462505076,1.512938502528689,-1.167500094839799,-2.2233340357526092,-0.2285986562994824,False,c1,3,"Lack of ""remove template"" button in a 1366x480px Firefox 22 window on Xubuntu Linux
In the Visual Editor template/transclusion editor the list of parameters obscures the ""remove template"" button so that it can only be clicked if you enter the name of a non-existant parameter into the search box. See attachment to bug 51671
Even this does not help when the window is too small for it to be displayed (see attachment).
Both problems could be solved by either:
*making the window scroll (separately from making the parameter list scroll); and/or
*moving the ""Remove template"" button next to the ""save changes"" button (which would probably be more logical than placing it under ""options"" - see also bug 51135).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51739
https://bugzilla.wikimedia.org/show_bug.cgi?id=51135
**Attached**: {F11269}",53672,2,Medium,False
-3.0043093205899414,2.519731846370469,-1.3916241226927362,-6.75636954527035,7.019300052589841,-4.750918861471599,-1.6269065841232964,-3.466240557067862,3.352740125532981,0.39840645098826943,-0.15789739815099146,-1.3144901244088245,0.9905346695542581,3.2180715171458143,0.3981996355168764,0.2536692402939561,-0.21959060311737222,1.334017902914174,False,c1,3,"A user on the English Wikipedia reports two problems when attempting to drag and drop an image.
""Problem 1: Clicking on a media file and dragging the mouse causes the cursor to change to the ""I'm moving an image"" icon, but the image doesn't actually move. I can only move an image if I click it once to select it, then click and hold.
Problem 2: If I move an image a small enough distance across the screen that it doesn't actually move, I can't move it again unless I deselect it and then reselect it.""
They are using Firefox 21, I can confirm both problems in Firefox 22.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54472",53665,2,Medium,False
-6.03143714352804,-0.8940273050642258,-7.9984644899427195,-4.4568573162745215,1.6383523338630201,-1.7666977647055464,0.07105369789368687,1.5561011468572898,-0.7514518095705971,-1.0822244789219528,-3.221143195849464,0.13625515015457768,-1.1730129266214586,0.672739266033668,-1.6803167824120293,0.826421138818842,0.21279255956548737,1.1856847720370396,False,c1,3,"/**
* Creates an ve.Element object.
*
* @class
* @abstract
*
* @constructor
*/
ve.Element = function VeElement
These and everything like are useless (not really explaining anything) and annoying (gets you excited to see a line of text only to find out its nothing) and makes the jsduck --nodoc utility unusable since a lot of things without documentation aren't without documentation.
So, henceforth, it is ""okay"" for a doc block to be just tags with no description on top (or even just /** */ with nothing, which is all jsduck needs to include a property in its index).
I (or someone else) will be ridding these at some point, but lets try and not duplicate them more (I won't take ""consistency"" as an argument here when creating something that is like something else that has a useless description, fill it in or don't copy it, don't spread the virus).
Thanks
--------------------------
**Version**: unspecified
**Severity**: enhancement",53650,2,Medium,False
0.25590213936374573,-4.407525117762127,-0.7209195550605312,0.8167872883263723,1.2162029581656686,3.697969124992267,5.9731711586479515,-2.093316465216238,-2.9256792909611775,0.43509034173325123,0.15953680179895313,1.7597101397992263,-2.2109569791490697,2.037983185445979,-0.0354162331411354,-1.12348451684986,-0.9122628474314952,-0.26971393466323,True,c1,3,"mw.gettingStarted.logging.getPageSchemaAction returns the wrong values for VE. For instance, it returns page-impression when the VE edit screen is open.
--------------------------
**Version**: unspecified
**Severity**: normal",53634,2,Medium,False
0.0352551012765594,1.1303826620507387,-1.0807615108921187,0.888929608597347,-1.082585074666675,-2.3719056796175333,-1.6746181730296357,0.6969114255592117,-2.9902235063489444,-1.261254250122577,0.3362638726246123,0.015494275428866944,-1.2286296796813962,-1.6265807187685772,0.08440027416037221,-0.09032251706769784,-1.1550488363769515,-1.6562157286034005,False,c1,3,"If a stub template includes an image size declaration that includes ""px"" then that image is shown at native resolution in the editor.
This was observed with [[Template:Cornwall-stub]] which originally had the code:
{{asbox
| image = Flag of Cornwall.svg
| pix = 30px
| subject = [[Cornwall]]
| category = Cornwall stubs
| name = Template:Cornwall-stub
}}
When the ""pix"" parameter was changed to just ""30"" [https://en.wikipedia.org/w/index.php?title=Template:Cornwall-stub&diff=564819917&oldid=547286019] as was used by e.g. [[Template:Nigeria-stub]] the image size was displayed correctly. The icon has been rendering at correct size when rendered for reading, presumably since [https://en.wikipedia.org/w/index.php?title=Template:Cornwall-stub&diff=next&oldid=235904748 2009].
Interestingly it renders as intended in VE when the template is initially placed, but does on every subsequent time it's opened in VE.
Feel free to use [[User:Thryduulf/stubtemplate]] for testing (I'll leave it up at least until this bug is closed) as I have altered the actual Cornwall-stub template.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51826",53628,2,Medium,False
-8.938052301637947,7.652273791858331,1.6203357658035245,4.4921799548445485,4.157461840036127,7.844397630683377,0.27831212694699925,-1.1661799406360642,-1.9348150457102942,0.7647156243238378,4.129415630593973,-2.732777019265038,1.1955643707824382,-1.4953511027634057,-1.3397530376200857,-1.6491654085028529,1.4690820792284092,-0.1329300027409963,False,c1,3,"User:NicoV at the English Wikipedia reports:
*In [[The Drover's Boy]], if you put the cursor just before the table and hit Del, the first title (Song title) is put outside the table while Performes becomes the first title.
*I saw this because I tried to insert a template just before the table, then deleted it => an empty line was visible before the table. When trying to delete this empty line, the first title was put outside the table.
I did some more testing and can confirm that:
*Pressing delete after the last character before a table deletes the first cell and moves the contents out of the table, and moves the second cell (including formatting) to the former position of the first cell. The position of the second cell is replaced with a blank cell.
*The same happens when pressing backspace before the first character of the first cell
*After repeating this sufficient times the contents of the last cell on the first line is moved out of the table and the line deleted.
*Pressing delete after the last character in the last cell, or backspace before the first character after the last cell, moves the whole of the next line (or title) into the last cell of the table, preserving formatting and links, etc.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50286",53624,2,Medium,False
-6.770094707332634,-0.41116301273560474,-4.3082191768017015,-2.7820466509515738,-1.822407631885614,-2.440525775514452,-0.06774095328110441,-0.567417585941054,-1.2889503916633216,5.347664010198683,-0.8398186166593491,1.6213485856891496,0.32831422042985103,-0.32021706972070607,-1.0926591116649682,-1.2318686243898886,-1.0645702574449254,-0.40993289341418615,True,c1,3,"User:Hhhippo notes that the language ""VisualEditor is in 'beta' and so many not let you edit everything yet"" is likely to be very confusing to those who are not techie or wiki insiders. New users may understand better if ""VisualEditor"" was explained or replaced with more general language such as ""This editing software"".
While we're talking about clarifying language, I wonder if those same new editors would benefit from a note that they can use ""edit source"" if a feature they need does not work.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53620,2,Medium,True
-0.0340782437521403,1.6121942150375421,0.22571933026085134,-4.767742418253766,-5.282893935909486,-3.9457495878229034,4.264568596194986,1.9797537095880187,-5.577140420723209,-2.7554304062952473,-3.7091613030876696,0.6154275673177951,-2.301789479522501,0.05752947133657926,-1.1255469213142097,1.390523562123945,-1.0645180076141827,1.024390839264291,True,c1,3,"Right now lots of users try VE with MW 1.21.x and are confused as to why they get nothing.
--------------------------
**Version**: unspecified
**Severity**: minor",53606,2,Medium,True
-3.4321775885334014,-9.318068781386508,-5.242891832971056,6.391400806803207,0.798505596719598,-6.749071339462757,-8.199680261148522,-0.35804005962086244,-2.573809260206593,17.31044918631688,-10.795741130542991,0.2411419721930277,-4.821379456010072,2.2405307831176,0.5669354666391753,-1.7090375195096938,4.405909328898999,-4.197157830898093,True,c1,3,"'label': 'foo' should mean that the label is 'foo', not ve.msg( 'foo' );
--------------------------
**Version**: unspecified
**Severity**: minor",53592,2,Medium,True
3.3387771360243437,-11.220022356833356,-6.9396555872460155,2.6847876849702326,1.122846019543069,2.1603697779864293,-3.102861688435138,-1.0349644489203085,2.8627248659873556,-3.612373284869263,0.8551075571439903,-0.0561510881038394,-4.231871172799832,-0.6041522477386705,-0.6438101688372218,-1.1266109071837633,1.2551918934311466,5.1667999202507735,True,c1,3,"VisualEditor should support adding and editing the code tag (<code></code>).
--------------------------
**Version**: unspecified
**Severity**: enhancement",53590,2,Medium,True
-1.8069857022238838,0.20762931871713342,-3.36912153823355,0.2796204038306034,-5.349467901841752,-0.6294722380468405,-0.25049079593726464,-0.10137526346171855,-0.5581770470906574,-0.07376337114879128,0.34217266093673526,-2.545959465585492,0.006635630960425409,-1.7779232079325205,-1.5250398816293824,1.3956011164175701,0.12164240655565783,1.0458644489189541,False,c1,3,"T32713 added ""wikipage.content"" passing it #mw-content-text, and fired it on initial load and from live preview (and other code like VisualEditor and other extensions/gadgets should also fire it when they replace/update the content).
A few others we should add for things outside the content:
* [DONE in rMW125bfdfec63c3be1b7d94be2d03e21226fcf23f5] `wikipage.categories`
arguments: `.catlinks`
Fired initially and from live preview.
e.g. for things like HotCat to listen to
* `wikipage.langlinks`
arguments: `#p-lang`
Fire initially if `#p-lang` exists/non-empty, and from live preview.
* [DONE in rMW9cfb9cb9fba4dcfd25a0924237681b7cc86a20df] wikipage.diff
arguments: `#wikiDiff`
Fire initially if page has a diff on it, and from live preview if user
did ""show changes"".
e.g. for patrolling tools to hook into the diff and the [mark as patrolled] link.
* [DONE in rMW8d0dcb863701e78cb4b066f176da89091bba67b3] `wikipage.editform`
arguments: (common parent of `.mw-summary-preview`, `.templatesUsed`, `.hiddencats`)
e.g. for vector.footerCleanup and other things that hook into this.
--------------------------
**Version**: 1.21.x
**Severity**: normal",53583,2,Medium,False
-1.8353182042007108,1.5416920831655858,-1.0242263037656745,2.9466055375747677,5.132143820229398,1.9192543693118764,0.8343287269198427,2.171454232728014,0.8386143773148353,1.1026791596335936,-1.6559532943102022,-0.13691185196751743,-1.6233023572686758,1.442454825086867,-0.7707056562866637,0.5387902458083796,1.5117971382018995,0.1935735392922424,False,c1,3,"At the moment, the VE's refresh after save isn't a full refresh - it refreshes ""in place"", using the parsoid DOM. This isn't something things like gadgets or site JS recognise, and so the reloaded page lacks power user functionality. Save should simply refresh the page cleanly to avoid this issue.
--------------------------
**Version**: unspecified
**Severity**: normal",53565,2,Medium,False
-6.190079739414203,3.012226693691158,5.09290313574234,5.169324891105523,4.5298725619711995,0.8881397467430194,-0.608471924680404,-2.7906181901693676,1.490830996295318,-2.191938162219714,-0.5885019668090505,-6.154052495052265,0.41158340870935106,-2.2984178331375955,-0.1998094542869575,-0.6011340646040302,-0.706091191086928,-0.6913755522483509,False,c1,3,"screenshot of the template edit icon in the wrong place
I inserted an image into an article using the VE, then I selected the infobox on the article. Instead of appearing on the infobox like it usually would, the puzzle icon for editing the infobox template appeared on the newly-inserted image.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52547
**Attached**: {F11877}",53548,2,Medium,False
4.789127485515321,0.15768758680168204,-0.2983042216444485,-0.5787613749964435,-0.47346707925298354,-3.9515903735741364,-5.731686216045572,-2.119284371568534,4.789765564959795,7.941529284310384,-1.6747151162862577,3.0748120638115735,-0.06105174709173866,3.59203981391013,1.3502553220758697,1.7571342593535226,1.534423939075311,0.18855629903612692,False,c1,3,"1. Click 'Edit'
2. Click 'Edit source' quickly before VE has loaded
3. You are show an API error in a confirm box 'Error loading data from server: error. Would you like to retry?', both OK & cancel let you navigate to edit source.
--------------------------
**Version**: unspecified
**Severity**: normal",53546,2,Medium,False
-0.0363711343815214,-1.907581324450307,-3.5931391798994436,-3.0049354101211962,-1.4914357911495955,0.7935029166088203,-0.582224835147974,4.189402433337072,-0.859269379877329,-0.31724348289912996,-0.6895264588382544,1.1405595454503177,1.8526222887844357,-2.490293246826546,-0.33110807725213665,1.2510845349723636,-0.30261538315952996,-0.39760380953623287,False,c1,3,"Currently it is impossible to use Visual Editor in the pages of Portuguese Wikipedia which are on namespace 102 (""Anexo""), because the default value of $wgVisualEditorNamespaces is set to array( NS_MAIN ) instead of the $wgContentNamespaces (which usually, but not always is just array( NS_MAIN )). These pages are also articles, and as such should be editable by VisualEditor as any other article.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52188",53527,2,Medium,False
10.37709339882428,-0.5637300136781214,0.368560508872509,-0.2580695758269268,-3.489874904357063,1.186058068798135,1.1491372714396748,-3.787262665897172,-1.4444262928124008,1.7603085485938008,-0.702852412472704,-0.5170696553116827,0.6276512269555434,1.4379917228749424,0.614342301739204,1.0856112020370743,-0.9704614117946613,2.065952898920652,True,c1,3,"A community member marks his edits as ""minor edits"" (via preferences) by default. VE ignores un-marking it both in FF 20.0 and Chrome 27.0; see:
FF:
http://de.wikipedia.org/w/index.php?title=Benutzer:Thoken/test1&diff=prev&oldid=120588869
Chrome:
http://de.wikipedia.org/w/index.php?title=Benutzer:Thoken/test1&diff=prev&oldid=120590664
discussion on De.WP:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=120620759#Enthaken_von_.22Nur_Kleinigkeiten_wurden_ver.C3.A4ndert.22_ohne_Wirkung
--------------------------
**Version**: unspecified
**Severity**: normal",53515,2,Medium,True
-5.470579515329471,-5.077962928101243,-3.5123970677811567,6.486125042665215,1.6003142255222684,-2.5217760353646668,-1.3179292300609466,-0.5244183093778901,0.25910340859537007,-0.9600704074195452,-1.0685268916355701,0.8134259024273105,1.5143067795399534,-0.4849125589170171,0.17993625191995122,-0.7791223564144469,-0.5951635568287463,-0.40098903335335523,False,c1,3,"When hovering the notice (which users do by default as the cursor is there after clicking the ""Beta"" icon on the toolbar) we highlight the ""Leave feedback"" label.
If the entire container was clickable and bound to opening the Feedback dialog that would be appropriate, however that isn't the case. On click we close the notice.
.ve-init-mw-viewPageTarget-tool:hover .ve-init-mw-viewPageTarget-tool-label, .ve-init-mw-viewPageTarget-subtool-label:hover {
text-decoration: underline;
}
--------------------------
**Version**: unspecified
**Severity**: normal",53500,2,Medium,False
0.5106292639205265,-1.304102623597938,-0.9276361291383939,0.4021468898086211,-2.047823939345382,1.565727797053006,-3.1551522007942316,0.8668354674098416,3.8350014647215334,-0.858375402140469,1.9449127241305892,1.0420962010868002,1.7534175088612547,-1.925532794364269,0.07916704860316326,0.7428777821223669,-0.20665713127951202,-0.5448203799420976,False,c1,3,"In both named and unnamed parameters.
The unnamed one should be of course a bug.
Should we manage to protect named ones from being trimmed in PHP parser?
ie. generate ({{P1|1= hello <nowiki/>}}) to protect the trailing space?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61049",53484,2,Medium,False
3.417538630543643,-1.9399930306968933,-2.460478627526804,-5.08472797406144,-1.5957368448547309,5.664947894350222,-1.4176882804901592,1.5116151380143608,5.599083417976845,4.4606512451012055,0.7545231249065227,0.018634936358265852,-0.17421989395569426,0.6853653082674844,0.7799311403811373,0.6255595782908814,0.3991562589885529,-0.8383817091984971,True,c1,3,"Make a ""First Edit"" tour to help someone make their first edit, in general. This should not have any connection to GettingStarted.
--------------------------
**Version**: unspecified
**Severity**: normal",53483,2,Medium,False
-0.17336443067602225,-0.6669588436026093,8.523772738375193,3.620960337862023,3.3738268998819705,-0.5733512392552058,1.6490511753976937,0.8868661286390668,0.9700077414628305,-0.2922831237656762,-0.31513933040664144,-1.0222849205469613,-0.37034665533689903,0.7754480437319602,-2.6230756348896307,-2.126975757336167,-0.9031675339237372,-0.8571450408842232,False,c1,3,"When editing the user page of a blocked user, some messages appear at the top of the page, for example blocked-notice-logextract.
They don't appear when editing with the VisualEditor.
Compare:
Good: https://en.wikipedia.org/w/index.php?title=User:SEAROSE8&action=edit
Bad: https://en.wikipedia.org/wiki/User:SEAROSE8?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52004",53454,2,Medium,False
-2.377298727607901,2.391286915480478,7.952847847158829,5.949510721833479,-3.6058767356003605,1.5687139226468279,0.784424975103283,-0.5712991874381343,0.46232949716100835,-0.6431288267280992,-0.5935797472859532,-1.5508544914722144,0.4261603224529753,-0.05134215192648561,-2.907949796412325,-1.0913027164090996,-0.7547858951272556,-0.602644681321592,False,c1,3,"At unpredictable points, bits of the text from the underlying article sometimes show up on top of the Media search box. See attached video for an example.
--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Linux
**Platform**: PC",53450,2,Medium,False
-4.674962481457271,-3.903290212645061,-1.5230732062027545,1.4978050241469893,3.000963355967971,-0.4563248306329768,-0.2897615582225086,-0.05063681319826163,0.9151483314756754,0.1417324238123321,-1.8968812520253824,0.01963366530827826,-0.4306950232008262,0.55728751027742,-0.9196869064353663,0.16495721773168526,-0.22258330009972527,-1.0502996107360119,False,c1,3,"**Author:** `turingt`
**Description:**
See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
The search results for parameters include each parameter's description, making it easy to select the right one.
But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
So, add the template description to the search results list.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51774",53436,2,Medium,False
-10.115331444049987,4.3824146091523914,-2.7860951591546748,4.63760566930604,0.09389686390033491,2.11913991164079,-2.70713122811641,-0.07544763946933641,-0.11109579838499384,-0.4178382606808846,-3.830706519537311,1.733626862500617,-0.26031083209321526,-2.890542026836853,1.517498975785501,-0.9659484187255416,-0.9084698470863313,-1.211306985709554,False,c1,3,"In addition to the existing ""default"" attribute for each template parameter, that would be useful to have an ""autofill"" attribute for each template parameter:
* ""default"" is the value that will be used by the template if the parameter is not specified
* ""autofill"" could be used for indicating that when inserting a template in a article with VE (or other editor), some parameters should be created automatically with a given value.
I think for example of some templates that have a date parameter to be filled with the date at which the template was inserted.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53428,2,Medium,False
-5.751518401212299,0.401538373173981,-2.9234027244212246,0.38292829204926515,-1.0107289173495375,1.1084524378682465,-0.002707808290076663,2.0071623323696497,1.0999087684377222,-1.508436738064678,-1.1101611651910182,2.6416199494381916,0.7733219915772951,-2.0136666106663497,0.23529055513915598,-1.289715213837931,-1.006302978142933,-0.3443737104849076,False,c1,3,"I would like to request that some flag or other indicator be added such that abuse filter rules can tell whether the edit is coming from VE or from the source editor.
Because the abuse filter tends to encourage different sorts of editor errors, it would be useful to know which interface is being used when editing. For example, a nowiki tag added by the source editor is almost certainly intentional, while a nowiki added by VE is probably an accident and should be tagged for inspection.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T54281}",53421,2,Medium,
1.651264444462989,0.26079188117902596,-1.3363583758015043,0.5472787952486775,1.8373539305050826,-0.748576093683766,2.417047680980585,-3.6922098068641755,-0.10404564717159195,0.35660401785946494,0.4510727305769753,0.47541311873236825,-2.8683331430503856,-1.1421872716512866,4.2684845380461285,-1.5286293901725867,-2.4890084135573574,0.7489763665137648,False,c1,3,"The file VisualEditor/modules/ve-mw/init/styles/images/loading.gif is a ""progress bar""-like loading indicator. It is moving only left to right. It would be more natural for RTL environments if it had an RTL version.
--------------------------
**Version**: unspecified
**Severity**: normal",53401,2,Medium,True
-7.818977621633971,1.0655007336313869,-1.8560435930105257,0.5918973591676997,2.2838477579842555,1.984526571339382,-1.2248671427979323,2.3229369883021054,2.2103225953299015,0.827113526361976,-1.2011734052609324,-0.8197548103710521,-0.01950009626295568,-0.12076972547697373,-0.2011390814666747,0.067586827595839,-1.7618604988549347,-0.6103567039368012,False,c1,3,"I would want to propose to add a type to indicate the content is contained wikitext, instead of a arbitary string. This could help VE to display a visual editor for those fields instead of showing the wikicode directly. This can't be done on ""string"" types as it's not certain they contain real wikitext. If the parameter is only to contain a single template invocation of a specific type, then perhaps a type ""template"" and a pointer to which template.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52652",53374,2,Medium,False
-4.302119075810466,-2.736244036708097,-2.3298385474559993,0.7391873017724444,0.5878566116797461,2.1780647844073355,-0.3984011843024966,0.9590921417428312,-0.15143289535939797,1.1175145403587647,1.5789011900503325,-1.3450961612901926,1.6695790460340119,-0.7467172948863761,-0.5474347897556449,0.7382244888157894,1.0323134954308555,0.2163480006442684,False,c1,3,"Original icon, and 2 suggested alternatives
The ""Insert reference"" icon is not very intuitive. I've made a sketch of two alternatives.
See attachment, or on-wiki at http://commons.wikimedia.org/wiki/File:VisualEditor_-_Toolbar_-_Reference-edit1.png
That image includes the current icon, and two adaptations that consist of: a snippet of grey text, and a blue super-scripted number [1].
The grey text could be made into abstract letterforms - squiggles - (rather than the letters REF) in order to make it usable by all languages.
Or we could use a grey ""+"" sign with the blue [number].
(The only problem is RightToLeft languages. Not sure how to solve that.)
The blue super-scripted [number] is universally recognizable and intuitively understandable as denoting references, both in Wikimedia projects and even beyond. I'd suggest this element, at the least, should form the basis for any replacement icon.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53396
**Attached**: {F11513}",53372,2,Medium,False
-2.74842797787931,-6.3714987787824064,-0.09030321266038399,-4.569943574701378,2.150155447672275,1.0909161343348919,1.150398054533074,-0.3050536045416916,4.2291612464508,0.8539924319423289,1.0900060854220741,2.009208622698049,0.6503742077338441,1.212385658628092,3.823397979889786,0.2214833405689016,-1.4922770881703817,-0.608433449629121,True,c1,3,"Currently it's a hack; it'd be nice to be a bit less of one.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50423",53337,2,Medium,True
8.30480590350353,-8.042789895057286,4.488428766432861,-0.42739358831151086,1.1443942939575973,-0.5673087317099315,2.6203347958138226,-1.6565426585466345,1.5041079684696115,0.6804574297979009,1.3898722451770564,-0.003255793153324582,0.6315678607393949,-0.19426793483763305,-1.8706011870930577,0.38317395385815717,-0.6926629032618898,-1.7273930463855849,False,c1,3,"The Beta notice looks strange to me:
http://i.imgur.com/H5n3XdD.png
ff23 linux
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52176",53335,2,Medium,False
-0.24827652358121188,4.0182646867026826,2.029367170835613,-5.100343854316266,2.388816945662912,-6.080457318849273,-0.26569236186435763,1.5404716912552456,0.12849734843146543,-1.2501822116370254,2.1479205171047666,3.3020842012554388,-0.3213695117408122,0.17287877329119006,0.03209222801313416,-0.6098061043371336,0.9145780194455095,-0.8921023527522662,False,c1,3,"Since T40551 have been resolved, it is //possible// to have per-language bold/italic button variants. But the only two languages //using// this are currently English and German. Do we really need to ask language by language, when we've been through all this with the Vector edit toolbar (see e.g. {T25625}, {T25911}, {T26188} etc.).
We already have https://commons.wikimedia.org/wiki/WikiEditor_Toolbar_Icons#List_by_language -- cannot we use that?
----
See also: https://usability.wikimedia.org/wiki/Opinion_Icons",53314,1,Medium,False
-0.4422490764351661,-2.5399105767116463,1.527353241755936,1.8205583715765288,1.6420062547537193,0.5611666388744805,-5.665158542670814,0.44704036518989554,0.19648984772348788,2.0206455412970783,-0.27129231171090096,0.6033619146407414,1.3031617794628994,1.3246644679866488,1.7428992766065017,0.7366934555434705,1.8850068879208195,-1.394804981360644,False,c1,3,"Twice I have added a bare URL as a reference to [[Paul Robert Magocsi]], which results in the [4] and [5] being added to the right spot in the text,
but ..
The references section at the bottom did not display the reference.
Steps to reproduce:
1. Click add reference button
2. Paste in URL
3. Click 'Create new source'
4. Click 'Insert reference'
(Reference dialog appears)
5. Click 'Apply changes'
6. View the references list at bottom of article
Expected results:
the new reference is listed
Actual results:
The added reference was not visible.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53306,1,Medium,False
-1.2275598675690578,2.116754291717168,-1.7726998730713124,-5.801016735676193,-8.063021395738204,2.681857374354805,2.678221743929856,-0.8163438185167237,1.0848536377763556,1.2716758635409287,1.3482822001103973,2.961618440662142,0.04255442634215534,-0.8314174596897095,1.3757389927425532,1.5659919315391722,-1.7226406064633755,0.07450952933368016,True,c1,3,"An Arabic editor has reported that he/she is having difficulty with getting images to display left-justified (as they should be in RTL wikis). How does VE handle justification of elements in RTL? Can images be defaulted to left justify?
This issue might apply to other elements, such as infobox templates.
--------------------------
**Version**: unspecified
**Severity**: normal",53295,1,Medium,True
7.418106976719475,9.76902016637327,4.339547073596304,2.610901456862503,1.3781710696568135,3.1716033937135037,-4.427861496974473,1.680596014455213,-2.635151320645015,-3.5608848600173797,0.1873984225000176,-2.7437133801198437,-1.166493102390743,-1.6792193669472595,-0.6266062500037632,2.637749179717657,0.4909529932770773,0.5849530855235188,False,c1,3,"When viewed in edit mode, references included in an infobox are not included in the references list at the bottom of the article, and the first reference in the body of an article is numbered stating from 1, ignoring any in the infobox.
Example articles: [[https://en.wikipedia.org/wiki/Popocatépetl|w:en:Popocatépetl]] and [[East Toowoomba, Queensland]].
Possibly related to T52474 and/or T52479
**See Also**:
T54398
T52474
T52749
T54427
T55486
T52896",53289,1,Medium,False
-5.936027602237102,6.994522361472473,-2.6705347408004183,-0.7663329655715587,0.3235213410731752,4.020636215678832,-0.6597260900925619,2.2262909498027317,-2.9187046047331116,-0.8527257011375418,-0.48680950128816036,-2.364120737078133,2.4474128076090467,2.054304287224947,0.7612213153812419,-0.5130975835089223,-3.0497657618587573,-0.8542498143785016,True,c1,3,"From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):
When selecting an image to be inserted, the selected thumbnail has a black box around it. The lines of the box are so fine as to make them almost invisible. A much better feedback would be if, when a thumbnail is selected, it turns blue in exactly the same way as when an image in an article is selected. (A blue coloring behavior - not the same as within an article, though - does happen for some images, though not most. For example, if one searches for ""Sandbox"", four of the first twelve thumbnails do add some blue if selected, though in one case just a sliver.)
--------------------------
**Version**: unspecified
**Severity**: enhancement",53287,1,Medium,True
1.8297178038887618,12.046781668947489,-0.6875860195199728,9.12957222710311,4.435947925874336,4.533873349701671,2.5901286457192887,-0.6233290616765796,-6.341735778083813,-0.4559425407962623,0.3647575357643591,5.189153051373265,0.6764026244623209,-1.8303134579819522,-1.1016169547794883,2.9835643474808227,1.7216759027801454,0.7069242997180207,False,c1,3,"VisualEditor is disabled on the built-in & default browser, which has the user agent:
>Mozilla/5.0 (Linux; U; Android 4.0.4; en-gb; GT-N7000 Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
",53274,1,Medium,False
-5.365017078776407,2.0120340168984825,-0.5047577553612257,2.3669848018973556,-3.5002153480124645,-1.4441581464374662,-0.7084831410903698,1.424703351785169,-0.5898447052075343,-1.9398223931386074,0.7574674326438791,0.12905492233003835,-0.09319335208488333,-2.1802380350941046,-0.11922878038408324,-1.23691750809287,0.5613141343943837,0.301439513872783,True,c1,3,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769).
It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.
Points of agreement include:
* The main requirements are for <references /> to support multiple columns and different list styles
** T33597 discusses defaulting to multiple columns for all reference lists
* Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size.
This task is currently blocked, on the following issues:
* What the default settings/algorithms should be
* Whether column widths and list styles should be customizable per-page, or only per-wiki
* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.
This would involve adding:
* columns (default to 1; a number between 1 and … another number? - not allowing width, obviously)
* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)
Then we could just bot-substitute uses of the template, and everyone would be happy.
**See Also**: T53145, T8019",53260,1,Medium,False
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: normal",53253,1,Medium,True
-0.5704672800820068,-4.861527569604375,-5.747065503564761,-6.371632439759416,1.91224306202189,-1.417980961535518,-1.3755694376402952,-1.5254141731334618,2.3367000011500814,-1.9650601930491427,-1.3792003666384,1.459794613582966,0.6770587353800654,0.14631858853065882,-0.28284464507110396,1.0215150493385412,-0.09678598011168682,-2.012858799957778,False,c1,3,"Please install Notifications (Echo) on the Polish Wikipedia. I think the community supports this in general.
Is it even possible? It seems some similar requests were rejected (bug 50064?).
I'll start a straw poll to confirm this after it's made clear that the request will be fulfilled (I don't want to bother them otherwise).
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52510",53251,1,Medium,True
-5.997783097798785,-0.6432768756819609,-3.1419220636216725,-0.8800509500886976,-0.025143928615440903,-0.5404813171622733,1.332887589003482,-1.096655459071368,1.4831771752373146,-0.21192555667969426,0.8372977756095326,-1.5164930393042908,0.706225427059398,-0.8266346034361325,-0.6302209677059256,1.0264064670954494,-1.1216222121989174,-2.0523067434308246,False,c1,3,"So, for example, the template dialogue. Once you're in it, there's not really any guidance on what you should do: as intuitive as we can ultimately make it, there will always be some confusion. It would be good if the VisualEditor had space for some kind of help icon that would link, in a new tab/window, to a pertinent help page on the specific wiki: we could set up MediaWiki namespace pages that provide the wiki-specific link.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51798",53237,1,Medium,False
3.6399711825365384,-8.13288287458203,3.495975905128855,0.8279931150974611,3.72833706795381,-6.729347621879073,2.2445812661110844,5.417014781122542,-1.421699802755283,-1.1577181344752954,1.2167889731317953,-2.53378221530651,-1.6427486563966136,-0.7684584373959344,-1.2488242345870244,-0.5169442978907156,-0.0611907715337312,-0.19190823083755415,False,c1,3,"Simple example:
{|
foo
|}
This doesn't RT correctly.
Real world test case: [[All-Ireland_Senior_Camogie_Championship_1992]]
Related report: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#A_simple_table_gets_doubled_after_an_unrelated_edit_of_plain_text
Interestingly enough, we have more robust handling for templated content. The example below is handled properly and RTs correctly.
{|
{{echo|foo}}
|}
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53402",53217,1,Medium,True
-4.369028857897244,0.564912001538115,-1.8066667086474766,-0.8751122339460418,-0.4772148155187529,-2.0971802588915027,1.3436796476802293,-0.29299180353654836,1.2811232673165431,-2.0800888831938997,-0.7893513683293629,0.07056123133427827,-1.0344480036913604,-0.33191116656277764,-0.5648493449171452,-0.5242781154499013,0.9054068989152404,3.187705479303249,False,c1,3,"Shields/phantoms are currently recursively applying to protected elements and positioning additional elements inside them. This causes 2 major problems:
1. Very slow, the CSS selectors use * and adding and controlling all these elements takes a lot of time as well.
2. We are limited to a single rectangle per protected node, which for inline elements is especially problematic since they are meant to wrap.
Using getClientRect and getClientRects (for inline stuff) can give us bounding box information that we can then cache, and render polygon click blocks for using an SVG layer. SVG's pointer-events: none works across browsers (unlike using this property in HTML) so we can control which elements in the SVG rendering block or pass through.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64709",53202,1,Medium,
4.213935529691787,-6.97087166869157,-2.9366956531605464,-2.7105431492455203,0.995019465031491,2.2612135668428808,0.5660133158876564,-3.657229673476754,1.5808531615394048,-2.77311471422947,-2.7431332465568605,2.6377622131475817,-1.7790247979432667,-1.2085522734445622,0.9881072100825659,-1.166396459676106,-0.7354864633594373,2.751741306422784,False,c1,3,"The user preference for disabling VisualEditor has gone missing. It should be restored.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",53179,1,Medium,True
12.647097356480826,2.0184962364994483,-9.481492637483573,2.174302227370114,-1.0640875429260102,-2.5193279021893344,0.7806993353645515,-1.9850036577148473,0.23099444658221202,-1.8751387222693943,-2.003971272014824,-1.006372732348079,-0.11191260770226297,-1.6020491436084527,-0.9762864314468169,-0.5846592568795709,0.8117617348086907,-0.5893387864676343,False,c1,3,"**Author:** `stephdechine`
**Description:**
I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out.
TypeError: Cannot set property '0' of null
at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)
at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)
at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)
at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)
at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)
at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)
at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)
at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)
at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)
at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)
My OS is Gentoo Linux with everything up-to-date.
I fetched the Parsoid extension by using git.
I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that.
net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)
(masked by default, I unmasked that.)
And the remaining installation process are with no error.
I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same.
That is all I have done to the whole Parsoid.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC",53151,1,Medium,True
-6.4543233779127025,-0.26705359798418904,-5.461797449768362,-9.472210947166088,-6.505876755637834,0.49341165122340813,0.346436441483978,-4.021167523833149,0.32468496732178365,-0.9756482997191833,0.6931258586543891,4.142756533170111,2.44658416045985,1.4688255016780882,0.22849322585029697,4.259327466245642,-0.4385894504336132,-0.4760104139582222,True,c1,3,"As discovered in bug 50120, we need to find out what this is and fix it.
--------------------------
**Version**: unspecified
**Severity**: normal",53148,1,Medium,
-1.7569536541640223,5.357716656457644,0.32499791553669155,-2.820464467535702,1.5614274068679683,-1.5149803799991226,1.8999487632990828,-0.6471876887341967,-2.869498608302048,-1.0914421047283032,0.695139703552413,-1.4419184842149713,2.631327183932422,1.068950735284747,0.9382247899007341,-1.2356456565378169,0.3505260426024017,1.0284520881686008,True,c1,3,"From English Wikipedia:
I've not yet done a lot with refs and reflists (a lot of my work is stub-sorting where it rarely crops up) but....
Editing Howard Wilson Elementary School I changed the number of columns of {{reflist}} from 2 to 1 (there's only one ref and it looks daft over 2 cols). The whole reflist disappeared, while I stayed in VE - see edit summary. On saving the page, it was there all present and correct.
This is one of several instances where VE alarms the editor: if it's supposed to be a Visual Editor, it needs to reflect changes made and not give the impression that the template has been deleted. Worrying enough for an experienced editor - totally offputting for someone new.
Apologies if this exact problem, or a more generalised case, is already tracked. PamD 16:38, 9 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: normal",53146,1,Medium,
-2.141148268139017,-6.05859243748273,-6.033290733327222,-7.5160584999455216,-0.05527845044177959,2.6235739444744706,3.2938296233782767,3.932779330369158,0.43728915542856994,0.8630719711795471,1.3869351627632232,0.735602853135507,0.2252419731331745,0.19995033468526913,-0.4294644854669807,0.09146852727017596,0.9384406847360978,0.8636088488916507,True,c1,3,"Currently this is really ugly; Trevor's better class will help, but in general we want to do this better.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53141,1,Medium,False
-6.630623901413882,7.79355307610302,-3.4548227732532837,-5.647573052783137,0.029968725851934996,-0.7111663113092674,0.6390610979015694,-2.6399593373364274,2.900458309711839,2.1314542386563966,-0.11193576496484425,-0.531110449770481,-1.1219616228365759,0.8338456853617942,1.5448193205264253,0.4029346822201448,-2.7524173605533404,-0.5302917346946361,True,c1,3,"An English Wikipedia user writes to note that since red is the color of a missing link, it may not be an ideal choice for ""remove template""
I myself wonder if it might not show up as pale grey (hence suggesting it will not work) to the color blind.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53133,1,Medium,False
-7.994955702864241,3.6819334393157384,-4.550874385095607,-0.20313863524100806,-3.2299080329349663,9.346943793651192,-5.182844846654921,-0.5812400353685607,0.15664464769234493,5.546929314101991,-7.353775415097273,-1.3004457652201433,-4.340670233766866,2.1076572627200063,2.859478752743313,-0.8253390558838882,-2.902272158612867,0.8648072391725183,True,c1,3,"A user suggests that, in addition to the ""cancel"" option next to the ""save"" button, there should be an option to ""cancel"" from within the save box.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53116,1,Medium,False
-1.1894813249350031,-4.789159841423164,1.2593252441639393,-0.29508448208153304,-2.602362110595736,0.4683190978691716,0.8155904073701095,4.445553803547692,-4.232685134061983,0.05783212032023677,5.343336907300808,4.136387124557303,-1.6085377556863154,-2.7706770802688503,1.7329639494624134,3.8303174458646696,-0.6805780912321359,-0.8844837894753741,False,c1,3,"Links in the form [[./Bla]] are invalid markup, but are rendered as correct links in VisualEditor. There may be other types of invalid formats that are similarly accepted.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=33094",53090,1,Medium,False
-5.2293812637790245,-0.13280281317857323,4.1586861554131325,7.501328941377814,6.368415700644309,0.6961982004712532,-4.678035398297358,0.0015715022654002042,-0.756890182142294,1.8241010285951145,-0.9059594649311427,1.650471629446079,-1.6674077425272076,-0.9357524228258884,-0.9792252587900663,0.38616447920602237,0.9024756799124789,2.509549456507531,False,c1,3,"On any page, click Link icon
Enter text in text field
Click the ""<"" symbol
Check the diff or save the page.
The link is created but the text entered is not preserved.
Suggest either preserving the contents of the text field upon the user clicking ""<"" or (less nice) disabling clicking ""<"" until the user has hit ENTER
--------------------------
**Version**: unspecified
**Severity**: normal",53065,1,Medium,True
-0.5310879347197335,-2.7747474063228115,-0.5463738981074453,-6.903286917515005,1.655179694361657,-2.856591865096216,3.91252488722344,-1.794037909767904,-0.6899214799252527,0.7908317769317073,-0.0387470570565549,0.2988001668263758,-1.6300604818652955,1.2374457874867781,0.5413090907261449,-0.10825628713761049,2.1072504003768415,-1.485061097309917,False,c1,3,"Thread is at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563553593#Consecutive_spaces - I can't explain it any better than the user has :).
--------------------------
**Version**: unspecified
**Severity**: minor",53056,1,Medium,
-4.500848513325739,-6.962832716102555,-5.369984129565882,1.4148771795122554,-4.130497893640296,-1.7985918714188946,-5.750197393090563,-0.6260131799501889,-1.0507756924576666,11.356462770152074,-7.809890901498715,2.0357305950758526,-3.0417896036899883,-1.411912252556497,3.8407006721829644,-1.0890751683942834,-2.1892288057924656,1.402008704439002,False,c1,3,"From
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/About_TemplateData
'(...) would it be possible to add new parameter ""example"" (where is example text what should be added to the parameter) in addition ""label"", ""description"", ""type"" and ""required""?'
--------------------------
**Version**: unspecified
**Severity**: enhancement",53049,1,Medium,False
-1.3330280947040647,-1.1993680400485385,0.8344595133000894,-2.5872028292683087,-2.243794746366711,-1.7331063489679144,-2.024793036893177,2.9030215516801734,0.02060605881539801,-1.7790936822584968,3.39092048854805,0.03351837013354664,-3.7044465828917197,3.995767832767166,-0.37030121002135274,1.1169512972077429,-0.3301353823805997,-1.257008857786103,False,c1,3,"Unpopular pages with short titles, e.g. [[Sop]], [[Topo]], do not appear in the top 10 opensearch suggestions, so VE thinks the pages don't exist. However, they definitely do exist.
This, along with bug 50898, suggests that the VE team might need to implement its own wrapper web API for link suggestions.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54361",53013,1,Medium,False
-5.548792939556431,-2.2291613495289138,4.646569264518295,4.951327280516946,-8.006784713658961,0.2616766155578134,2.2245687024514202,0.22997646785561582,1.6961921224915992,0.21796186883336421,-0.14243261323598944,2.5760053841132073,0.15389685362275962,-1.0634090838556922,-0.06129137915713123,0.13342947749065714,-0.2906880180350644,-1.2224437092297515,False,c1,3,"To fit long page titles.
There's plenty of empty space in the dialog box that could be put to use.
--------------------------
**Version**: unspecified
**Severity**: minor",53012,1,Medium,False
-2.424178797387274,-4.786712521798043,-1.6975663628919015,4.961545875477355,4.476717042488557,-3.0872815094654724,-2.8282538900772063,1.8189254134371438,-0.6559127016458769,4.559587273297218,-4.434312381446571,-0.8444680687685272,-1.0992652942922785,-1.9126548004116168,0.342646799609728,-0.1476067873843741,-1.958893923918568,1.622183675302442,False,c1,3,"When inserting a new template, the template dialog button label ""Apply changes"" doesn't make sense, since we're not changing an existing element. In that case, the button should be labeled ""Insert template"".
Similarly, when inserting the list of references, the button should be labeled ""Insert references list"", not ""Apply changes"".
In contrast, when inserting a footnote or media file, the button is correctly labeled ""Insert reference"" or ""Insert media"".
--------------------------
**Version**: unspecified
**Severity**: minor",52998,1,Medium,False
0.45316659155307226,-14.268907567604918,-2.7256956944608692,-2.368414605226201,-5.7147213189469,5.230521157691467,0.08309132841316469,-2.694961815081792,-0.12224157725953913,-4.4754912274729515,-5.082849670936817,-1.8975280291950476,0.3605318307026901,5.961944740954603,3.8455331055527013,-2.363999609725272,0.9654078527051817,3.452021775392905,True,c1,3,"Splitting from bug 50475 comment 1.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52997,1,Medium,
-8.378055715449705,-0.7058269907753569,-2.972615514689611,1.1730923053251727,0.9731116207174215,1.686154701669092,0.7620627816010437,2.744138280195091,2.357694491558359,0.15662163753810088,1.3321207103382986,-0.9639825446947279,1.5889620788336387,-1.229367130214631,-1.0217414642707174,-0.4128176521213629,-0.4933755041374498,0.7301591776997973,False,c1,3,"Especially for templates, having a faster way to open the inspector would be very helpful. Right now in the case of a large template, you have to first select the template, then mouse over to the puzzle piece location and click it. Just double-clicking/tapping the template seems like a straightforward and discoverable gesture.
For links and other nodes it may be less important, but what would be the disadvantages for just making open-on-double-click the default behavior for all nodes that have a primary inspector of some kind?
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54827",52996,1,Medium,False
-7.074521229965645,0.9402969633691161,-2.182174556204604,1.2723685725973217,3.3134337889323398,1.562096371050164,-0.6214938683021201,1.3000001234319827,-0.9627352000045297,-1.0465881866978308,-1.4968950651575148,0.48903231054963614,0.3128278958662434,-0.6419013268510891,-1.3185454737866245,0.8761088744983826,-0.3217534120390948,-1.9860939950323009,False,c1,3,"If you backspace-delete the newline that appears immediately prior to the indented quote of this rev (the quote that begins with ""This was a kind of blank ..""), the entire quote is deleted. This may be related to the fact that the newline shouldn't be there in the first place; it does not exist in the wikitext version of the page, nor is the text indented by means of a template.
https://en.wikipedia.org/w/index.php?title=Ernestine_Eckstein&oldid=563439288&veaction=edit
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50418",52995,1,Medium,False
-1.5413435429338902,-4.421843281537669,-2.2346837358098277,0.7374498080252649,-6.830074863543164,-1.8891164051155425,-0.10433752805102436,2.9738826971064025,-4.579701852039155,-2.4850502806636374,1.7301047243415817,-2.1773737922571597,-0.6888168277919018,0.3159778677464393,0.25258486962972526,1.4965116219698729,-1.206414973534377,0.6422411131816788,False,c1,3,"Screenshot of odd rendering when using {{#tag:ref}}
https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet?veaction=edit
See attachment, [11] renders as span instead of as <sup> (like [10]) and as such isn'y styled correctly (text is too big).
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11600}",52978,1,Medium,True
-3.9812027988080567,3.835819768541583,1.1634082442993012,-4.466691837111343,4.686381211750577,-4.7872869493768695,1.0803555108371254,-3.072136687170246,-1.154432939160134,-1.2830817036171305,0.45808596510496935,-2.142753354537672,0.4540613832028715,1.7204747878283442,-1.0759645760016703,0.4323853879703069,1.2405918844388972,1.2341699754656286,True,c1,3,"From an editor on English Wikipedia:
On the whole, I really like it. It's basically intuitive and seems to have massively improved since I first tested it out. The main problem I'm having involves the amount of effort now required to open external links in references (especially those using {{cite web}} etc). As far as I can tell, I have to click on the footnote, then the icon, then the text of the reference, then another icon, then the url parameter, and once I'm done copy and pasting I have to close two pop-ups. Is there any way around this that I've missed? It's not an error or a bug, but it's the main barrier to efficient editing that I've encountered so far. – Arms & Hearts (talk) 16:03, 7 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: enhancement",52966,1,Medium,False
-2.2947489460745087,0.7493476446404888,-3.864162567588794,-2.8183157356765496,2.3219169995119646,2.0058915796840253,-4.539673253445987,-0.48949121369533544,-1.8277411371778005,4.8808693201020255,-3.9389519170186222,1.3681603005598462,-0.1086302403072148,1.3000033256047177,0.9516312554526696,0.19423404218714316,-1.557340075375901,1.1396881634854157,True,c1,3,"An English Wikipedia user requests clarification of the ""cancel"" process, saying:
""If you open a page in the VisualEditor, make a few changes, and then decide to hit the ""Cancel"" button, you get a message that says ""Are you sure you want to go back to view mode without saving first?"". The options are ""OK"" and ""Cancel"", which aren't really proper answers to this yes/no question. As such, I'd like to request that instead the buttons be replaced with ""Yes"" and ""No"", which are clear responses to the question. -Thunderforge (talk) 21:36, 6 July 2013 (UTC)""
--------------------------
**Version**: unspecified
**Severity**: enhancement",52955,1,Medium,False
-5.0053006182963,0.5806215823034222,-2.4669160872473093,-0.6026605941306702,1.24706940724995,1.9326572364985821,-1.1167358715392162,-2.427433210189085,0.5701470367993592,-2.5430891199888137,-1.5261046598291401,0.947289497234231,0.6604275903302055,1.4226368481057028,-1.5522097965734778,0.9289219333252053,-0.5717003749905968,0.12131313757892648,False,c1,3,"**Author:** `adaml`
**Description:**
When editing a table which includes a transclusion as seen on http://test.wikipedia.org/wiki/TableRowTest it seems to copy the row and paste it before the start of the table.
In the example above, edit the page and select one of the rows for transclusion and change parameter 1 to a different value, all seems to be good until you save the page which screws it up
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50589
https://bugzilla.wikimedia.org/show_bug.cgi?id=50607",52951,1,Medium,False
-6.9972430329265265,2.7550001837180957,-2.93436074417618,2.074756691068814,2.4993416147205516,2.1817969583393264,-0.22341898336995314,-1.2784564053368253,2.1183975430718,-1.4516773352672332,0.16632032542054098,-3.7624161046159124,1.2654085107635114,-3.2709018742138953,0.896990422989643,-1.9149084426382839,0.67095502546011,-1.6463691441287547,True,c1,3,"An editor had an issue on English Wikipedia with the hyperlink tool when used within the reference editor.
Specifically, he formatted a reference manually and then used the hyperlink tool within the reference editor to provide an external link to the work. He found that many options were offered, to the point that the reference box was obscured by the list of possible links and he had to just guess where to paste the actual url.
I reproduced this and took a screenshot.
http://en.wikipedia.org/wiki/File:VisualEditor_Reference_issue.jpg
--------------------------
**Version**: unspecified
**Severity**: normal",52943,1,Medium,False
-5.208712497316393,4.342850309914876,-1.7481329148777203,-3.9665373187372905,0.008903127212023354,-3.051553234406806,0.04144945918718168,2.477769313952871,-0.1792560533856848,-0.022072365861075305,-0.7708714141323014,-0.15489988768735463,-0.09030742457194751,0.49170964030138453,1.2188397090194671,-0.760858455794994,0.5405306036051387,-0.7998953214277778,False,c1,3,"It's strange that I can't find a bug for this. Lots of user on en.wiki complained loudly about this [1], but nobody succeded to write a bug report for it? Well, here it is:
Please provide an option in user preferences to turn VE off. Some users just don't like it and don't want to have an extra tab which they don't use anyway. The gadget isn't perfect, as the tab might appear for short time before it is removed again, and has to updated when VE integration changes. The only reason I found for why there is no such option is this:
""It was planned, but the code turned out to be seriously buggy at the last minute. Getting it really, truly off (rather than just covered up) is more complicated than expected."" Whatamidoing (WMF) (talk) 06:32, 2 July 2013 (UTC)
Now with the minimized amount of code that is loaded at startup, it is acceptable to load the code, but just not to execute it. Adding
if ( !mw.user.options.get( 'visualeditor-enable' ) ) {
return;
}
near to the end of modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js should be all that's really needed.
[1] https://en.wikipedia.org/wiki/Wikipedia:Vpt#.22Opt_out.22_of_VE_needed_under_preferences
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://en.wikipedia.org/wiki/Wikipedia:Vpt#.22Opt_out.22_of_VE_needed_under_preferences
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52086",52929,1,Medium,True
6.795213765534365,-13.623062525526398,9.425208969408068,4.037197034435885,-0.9385366726580916,-1.2688532270938018,3.009946850163744,-1.0660559548312771,3.129059199667905,0.7927079112227764,0.5656709654608623,1.321279104012117,-0.17109557030349976,-0.48589087985743795,-0.48496802925384674,0.3309867767126919,-0.38278351509674,-0.9800420836521606,False,c1,3,"See: https://en.wikipedia.org/w/index.php?title=New%20Zealand%20English&diff=0&oldid=123
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/w/index.php?title=New%20Zealand%20English&diff=0&oldid=123",52925,1,Medium,True
-5.554957046704862,1.2680275600074982,-3.118831259665619,2.664826827703138,-0.8473563244636035,-0.5058560162890828,-3.100067502732876,-0.1703025199589015,-1.3759417891822894,-4.193415155189206,-0.8219151303160808,-0.8722998992052182,4.2040205208011985,3.27352097896852,2.133166043764339,-0.8442422096247628,0.2920024362137166,0.07512180292101722,True,c1,3,"Taken from English Wikipedia
***
[[Template:Convert]] is actually a good example of where TemplateData falls over and hits the ground. The meaning of the numbered parameters changes depending on how many of them there are and whether the entry is text or a number. For example, each of the following are valid:
{{convert|3.21|kg|lb}}
3.21 kilograms (7.1 lb)
{{convert|3.21|mi|3}}
3.21 miles (5.166 km)
{{convert|60|to|170|kg|lb}}
60 to 170 kilograms (130 to 370 lb)
{{convert|60|+/-|10|kg|lb}}
60 ± 10 kilograms (130 ± 22 lb)
{{convert|6|ft|5|in|m}}
6 feet 5 inches (1.96 m)
In those examples, parameter 3 is variously 1) The output unit, 2) The number of significant figures, 3) The upper limit of a range, 4) The measurement uncertainty, 5) The number of inches in foot-inches measurement. Now write a TemplateData description for parameter 3 (or 2 or 4 or 5)? Convert is used on 500,000+ pages, so it is not like it can simply be redesigned at this point. That said, if someone can see the values of each parameter in the transclusion window then it would still be pretty easy to figure out which one they need to edit. I would suggest that the transclusion editor needs a way to preview the parameter contents (even if just a snippet) without having to click on each parameter. Dragons flight (talk) 17:57, 5 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: enhancement",52916,1,Medium,
-5.448284418842439,0.4569420866292422,-0.8799224611156635,-0.7256983772304486,3.665272153879989,-0.8985172663900605,-2.2417711846540533,-0.9186175525796347,1.4477221123648032,-1.1085640729964603,-0.36623641136730756,0.4428279823123933,0.2825607457167778,-1.6953337330898304,-0.29962952696317036,0.16374741843624363,-0.8983621648888325,-0.989699578077378,False,c1,3,"Reproduce:
1. Go to this page: https://he.wikipedia.org/wiki/%D7%A9%D7%9C%D7%9E%D7%94_%D7%A4%D7%99%D7%9C%D7%91%D7%A8 (Image is floating on the left)
2. Edit the page. The image is now stretched all across the content area, pushing the text down.
This is a 'no picture existing' template. In the Hebrew wiki: https://he.wikipedia.org/wiki/%D7%AA%D7%91%D7%A0%D7%99%D7%AA:%D7%90%D7%99%D7%9F_%D7%AA%D7%9E%D7%95%D7%A0%D7%94
It is probably an issue of the template code, but since it's used very often, it would be great if someone can help find the problem in this so we can fix the template itself.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50395",52910,0,Medium,False
-12.578445681407993,5.509642219477016,-0.4000091310174163,4.364120160521134,-0.5667627942027501,5.797313490668239,2.8459878819583713,-2.9192005586735297,2.8537941469917465,1.5225428888156962,1.6290219482963946,-0.3939633317775155,-1.0526287140296144,2.4096728466460187,-0.9166589709865329,0.9066171170741025,3.1452185652216267,0.9205468992358263,False,c1,3,"A user points out that much of our communication both external and internal of the wiki instruct people to leave an edit summary, but the save dialog doesn't name this field as such, which might make it difficult for people to make a match between the instructions and the actual save dialog.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52900,0,Medium,False
2.565498635161361,3.5587755510199983,2.9139251507619797,-6.748100024018335,-0.8443157928916353,-2.566919135221591,0.49712465640667425,-1.2027163728152082,-1.667569834120041,-0.7069821294436327,0.9429464782408519,1.3630868181693059,-1.272474965740729,1.219335947091845,-2.5270653647252384,-0.9002487600571014,-0.6291322880135121,-0.5330916851871941,False,c1,3,"If you have the [[Hands-on universe|Hands-On Universe]] link, it will report that Hands-On universe doesn't exist (which it does). This is probably because it matches on the different case: Hands-On Universe and then stops comparing.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52596",52898,0,Medium,True
-1.419870963119507,-1.3170595078089207,3.266322398879012,2.9213966688219,3.3371105830455647,1.5629529404680411,2.605284561084555,-0.5380154220416496,3.8868799943350956,1.1566077272628998,2.0734730549480873,-1.8820028891714515,-0.23600122166867088,-0.139323570557905,0.9476377228730248,1.4339720906475364,-0.561784737510981,-0.9825931770634115,False,c1,3,"In the old editor, you could hit ctrl-alt-s to save the page. In the new editor the save action is not reachable using the keyboard.
We could just add ctrl-s/cmd-s to the Save button ?
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38042
https://bugzilla.wikimedia.org/show_bug.cgi?id=50047",52897,0,Medium,False
-6.616708332472285,10.698421910431435,2.2222992507960555,-1.385051047012186,0.9806787039733478,-0.6422707349200794,-2.7955709048402433,2.3881910101634465,-4.3474698967548795,-2.9168313149127965,-1.8324362926946907,0.294141972509012,-1.6815608027672493,0.4510414565386762,1.198360306895581,2.1342148843042397,-0.6513446458228935,-0.5892936438065999,False,c1,3,"For example, look at https://en.wikipedia.org/w/index.php?title=Peach_Springs_Trading_Post&oldid=563257259&veaction=edit.
Citation [1] is defined inside the infobox template. It is then reused at the end of the first paragraph, but when you click the [1] there, you get an inspector with the message: ""This reference is defined in a template or generated block and for now can be only edited in source mode.""
This also comes up when citations are defined within a template like `{{reflist}}`, as at https://en.wikipedia.org/w/index.php?title=Helminthopsis&oldid=592365854.
**See Also**:
T53289",52896,0,Medium,
-7.1093856514283855,2.619656094211102,-3.687482945921708,-1.670137206134993,2.680695496897292,1.6720802280819294,-0.9360523738574384,-4.659134308729669,0.2799191373221491,-0.8114726102901195,0.5720855038274206,-0.8281818591388788,0.09521191719459665,-0.0535952681245222,-1.3004104360651665,0.48039050590457266,1.3233204691361673,-0.6970060159049447,False,c1,3,"This happens with the Link annotation, but also happened to me with my Language annotation prototype when I play with it.
Steps to view the problem:
1. Go to some link in the text, put the cursor on it.
2. The 'link' button pops up, recognizing the annotation, and if you click it, the full annotation fragment is selected (expected behavior) and the input widget appears.
3. Without closing the input widget, click on another link in the text. The widget moves to the new location with the proper data, but the text of that fragment isn't selected, and it's a bit odd to edit.
I think a better behavior may be to close the widget and have the icon pop up on the new location, as if I clicked an unrelated non-link text and then again selected a link.
(I hope this makes sense, I can post some screenshots if needed)
I use Firefox 22.0 under Ubuntu.
--------------------------
**Version**: unspecified
**Severity**: minor",52895,0,Medium,True
13.826756708549734,-11.00650704137711,2.5834321968444947,-0.33008197794722893,0.12447626921184896,-0.663668008437754,-1.4506950513141152,0.9237123858855009,0.9246703149979463,-1.3415660431278273,2.701255660953269,-0.2938979064283004,-2.1810387953307773,-0.8557588558225611,-0.9040314131608218,-0.12778774720179487,-0.5626489606795283,-0.7075210309922066,False,c1,3,"[[Jyllands-Posten Muhammad cartoons controversy]].
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51755
https://bugzilla.wikimedia.org/show_bug.cgi?id=52667",52885,0,Medium,False
2.647889591231553,-0.5578196670270277,2.5622521161783247,-2.891788284971115,-1.9935869307927392,0.876900672078754,-3.4966482694012204,-0.5207882712827079,0.5552337416960449,-2.1189055317505394,2.945794549147102,-1.428746109297204,-3.09806086300898,-0.8355350244011408,0.35351801596264654,2.6519069167432097,-0.639060325321129,-0.9626022465314199,False,c1,3,"If you click in the link
https://en.wikipedia.org/wiki/Math?veaction=edit
you will be redirected to [[Mathematics]] and the VisualEditor will load on that page instead of in the redirect page [[Math]].
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/wiki/Math?veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54921
https://bugzilla.wikimedia.org/show_bug.cgi?id=25470",52878,0,Medium,False
-2.3833000283846744,0.37416991685016754,2.3632178842322915,2.103572330931492,-5.217680097240553,-4.597573034051037,1.4995850438342657,-4.700347196833102,-1.3455972201970878,5.4916761510143814,-1.6231303533527968,-0.8711849564977789,-1.6082537541893567,-1.6732848489328047,2.6659838215669085,3.7045880819246357,-4.157720601661996,-0.7623439840146768,False,c1,3,"If you click in the link
https://en.wikipedia.org/wiki/Special:MyPage?veaction=edit
you will be redirected to your user page in ""view"" mode instead of ""vedit"" mode
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/wiki/Special:MyPage?veaction=edit",52877,0,Medium,False
-2.9813301889121635,-7.422798860649957,-2.4001386918995884,-4.561823576204281,-4.865616105018178,-1.1043953021733839,3.331428341616145,0.09387924959247185,-0.367749790290707,-1.0404540531777138,-0.8525511653305706,-5.329806703818292,-0.5212953568271255,-1.1350694668108252,-0.9081763476225841,-2.4151793785774376,-0.35928017448973315,1.3659012755919775,True,c1,3,"Lots of testing involved here; currently assigning to myself.
--------------------------
**Version**: unspecified
**Severity**: normal",52874,0,Medium,False
-5.979849904469171,3.18813616899088,1.3580439036364211,0.227100381959759,-0.5595375694563136,0.9484974161535742,-1.3464440023439401,0.407647721470906,0.37177445219115557,-0.2985286902431108,-1.7923907522472127,-1.226176220641001,-1.1415159069975038,-0.4990568814124794,-0.38779164210590267,-0.5849084928050858,-0.5577682518826589,-0.256632858795963,False,c1,3,"Even though section editing in VE is a long way off, it would be really helpful if the title of the section you click edit on was automatically included in the edit summary in the same way that the source editor does. For example, when making [https://en.wikipedia.org/w/index.php?title=Viareggio_train_derailment&diff=next&oldid=563164136 this edit] I launched the VE by clicking on the edit link for the ""See also"" section, so I was expecting the edit summary to begin with the usual ""-> See also"". This provides context for the edit summary and so helps give context at recent changes and on watchlists.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56891
https://bugzilla.wikimedia.org/show_bug.cgi?id=51903",52872,0,Medium,True
-7.022145593452029,2.0096019545338564,0.434822053080687,4.268774371546941,2.0815590478855834,4.790328914715348,0.4183403722305812,-0.2708423981246978,-2.240730238126145,-1.8103156260014108,-1.2644104691353872,-0.8985350584126706,-0.9511804466561333,0.5230707611772294,-0.35785517318059057,-0.871015237681448,0.3199309028476576,-0.001000087365776725,False,c1,3,"Original bug title:
mediawiki.notification should show the notification bubble relative to the screen, not to the document
Current behaviour:
Calling mw.notify(""abc"") in JavaScript creates a message-bubble somewhere below the first <h1> heading (the title) and the bubble disappears after about 5s.
Why this is an issue:
But if you have scrolled-down the page, the notification disappears without being read.
Where is this an issue:
For example, when marking large new pages as patrolled, the patrol link is at the bottom of the page and the message whether patrolling succeeded is not visible to the user. Or at custom gadgets/user scripts.
Expected behaviour:
Bubble shown, no matter of the current scroll position.
Possible implementation:
Fixed position.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",52870,0,Medium,True
-1.8682272270080569,1.7417551589076616,-5.013437979472238,-3.3327990383586026,0.1368572059963239,-2.9091775553651087,-0.699366909445196,-1.4667235955738729,1.2045136200411652,-2.730600361935711,-0.8653153834174829,-1.208548750921662,-1.632460287316432,0.14440821643088508,-1.6990515587248671,-1.4993959867780646,-0.6056789048647568,1.35007002165247,True,c1,3,"Allow launching a tour while limiting it to once per-user. The idea is that GuidedTour handles this, so the calling code (GettingStarted, VisualEditor, etc.) doesn't need to think about hidden user preferences, etc. I'll call it launchOnceForUser as illustration; better name suggestions welcome
Example use case: The VisualEditor edit screen calls launchOncePerUser, then GuidedTour decides internally whether to launch it based on whether the user has already seen it.
Ideally, it will allow launching immediately, and pre-launching by setting a cookie (we did this once with GettingStarted).
--------------------------
**Version**: master
**Severity**: enhancement",52847,0,Medium,
-5.165221742110924,-2.636591382066431,-6.589423325285807,-5.035064001758078,-2.5534804523855694,-1.1859273361079434,-2.601420434380994,-1.2255589485310034,-3.2211352183963147,4.714450142018206,-1.9036579743776214,-4.279097527277174,-0.9829257220313776,-0.7493238578453605,-0.5168379399482568,0.22112585890647607,2.6682708077751878,-0.047370454146197005,False,c1,3,"We have lots of occurrences of 'cache': 'false' in $.ajax invocations in our code, and only one occurrence of 'cache': true. Based on the documentation, it seems to me that 'cache' should pretty much never be set to false. But then again, we set it to the string 'false', not the boolean false.
This seems bad and in need of cleanup. Assigning to Timo.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52840,0,Medium,False
-1.8595822829390845,7.664937973383225,1.1997370021392229,-1.6164425977640682,1.162469387502769,6.6095481331724955,-6.690917230083567,2.6683372467393616,0.7657636295120704,-0.9345429291437917,-2.193318741360731,1.0500361538772645,3.6770160286123765,1.8633608182698156,0.8595043206220794,-0.6446889663277221,0.8563704956774723,-1.2566045132495631,False,c1,3,"Take for example this:
https://en.wikipedia.org/wiki/AMS-LaTeX?veaction=edit
The green alienation is only covering one line of the Math block after the sentence: ""causes the equals signs in the two lines to be aligned with one another, like this:""
{F11183}
**See Also**: {T66625}",52791,0,Medium,False
1.3765351577538048,3.453610217534468,2.1294594046909907,-0.2533825675331416,1.3237554031229737,0.43289514902094783,-1.5772286956357355,-2.6618726818554084,0.006783664896624408,-0.2709395705034563,1.8506910396438365,-1.072919397966428,-2.8021389670306904,-1.220807062800728,1.3554897722474042,1.640466944655486,-0.3503341109656246,2.396798216933595,False,c1,3,"Quote: ""I was editing this revision https://en.wikipedia.org/w/index.php?title=Chubby_bunny&oldid=562098358 of [[Chubby bunny]] to try to remove a thumbnail of a deleted image, the following wikitext:
[[Image:Sara_Jay_Chubby_Bunny_Challenge.png|thumbnail|Sara Jay playing Chubby Bunny]]
The red image link and/or its caption shown in the normal article view do not appear in the Visual Editor view and as far as I tell removing it in that view is impossible.""
--------------------------
**Version**: unspecified
**Severity**: minor",52788,0,Medium,False
2.529969219768778,-8.245262240655183,-7.572660114161403,-5.799541466789211,1.9894083659428041,-1.225980948851484,0.7631002154209252,6.785058216557933,-1.523820078623171,-0.41768442714626364,-3.159469588325784,7.012285680844896,-0.4107727578746365,-3.260464630203021,1.5091860059202178,0.03640305834087987,5.13069660880151,0.6365211646136932,False,c1,3,"Tracking bug for:
- Browsers that shouldn't be blacklisted but are;
- Browsers that should be blacklisted but aren't.
--------------------------
**Version**: unspecified
**Severity**: normal",52781,0,Medium,False
3.6799558669467376,4.128217336094323,-1.9426429983997355,-7.386867763291078,-7.3012202155791375,5.884663890230262,-0.7083290891552476,3.4313996074881854,-7.029764712593688,-1.977550725085468,0.141854711900383,-2.1070326056022566,2.4750698865299974,1.99329278629863,1.3985733860607281,-0.3061019860819718,1.5223252746369653,2.3146338076772315,False,c1,3,"Following up to T52534, at least currently, Firefox 11 and 12 are broken as well. The first version of Firefox that at least loads the editor is Firefox 13.
Reported by user for Firefox 12, and confirmed in crossbrowsertesting.com.
--------------------------
**Version**: unspecified
**Severity**: major",52780,0,Medium,True
1.23351094801068,5.39185690471508,-1.1922887359278853,-2.8711026786582057,3.637875945602311,0.8309921231821071,0.09032701874960036,-2.01179183295408,-0.8723606659002464,-1.1303108239544009,0.9639796317024776,-0.6211831247303349,2.1280671335480883,0.8664381106356744,-0.3425431333244715,0.8724406074686633,-0.4043847440852706,0.06755400299327552,True,c1,3,"May be dup of 50213?
User:Joe Decker reports:
The revision of an article here (http://en.wikipedia.org/w/index.php?title=David_Busic&oldid=562867623) has an interesting thing, a completely empty bulleted list item, which does not normally display when the article is read. It is just below the reflist, you can both confirm this in the old-style editor, and see it visually in VisualEditor. However, I have found myself unable to delete that from within Visual Editor without also deleting the preceding reference list, which is a little wacky from a UI point of view. E.g., I attempt to backspace over the bullet and I lose a reference list. Reproduced on Chrome and Safari. --j⚛e deckertalk 18:48, 4 July 2013 (UTC)
Replicated by me.
--------------------------
**Version**: unspecified
**Severity**: normal",52779,0,Medium,False
3.1978709591181897,8.700888785311285,-0.3378385898531526,-6.602189542281753,-2.4717256281447924,-2.8213323520990863,-1.5533973296952315,-4.485247033156719,1.0415971568799458,-1.671595849694922,-1.2321703890108062,-0.9164679034628391,0.9180866127285916,1.4352884975860913,-1.3188472723263276,-0.26406693033243867,0.5368872968813319,-0.8975190857912445,True,c1,3,"Copied from English Wikipedia:
When I try to use VisualEditor on my Kindle Fire, the article goes into edit mode, but clicking in the article doesn't bring up the keyboard like it does on an iPad. I'm presuming that aading support for the Kindle Fire's Amazon Silk browser isn't on your to do list now. Could you please add this browser to the blacklist? I would like to keep VE on in my preferences so it works when I'm on my PC but not have VE get in the way while on the Kindle. Thanks! GoingBatty (talk) 02:59, 4 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: minor",52777,0,Medium,False
-5.894892040255293,7.625130566155924,1.6651525448887803,1.4425628456143338,2.569240415778518,-0.1488685526214113,-1.2350802795956488,1.6405537574043088,-1.5717180807059226,-2.0864658572689807,0.2043681105778341,0.010353208837112993,-0.6862447283162076,0.438014434621091,0.4081395089340285,0.19096409295233244,0.36272555260761097,-2.0045770918685477,True,c1,3,"Copied from English Wikipedia:
Hovering over a displayed math formula in <math> tags is supposed to get a tooltip that explains that the formula can't be edited in the VisualEditor. It sort of works; but it has trouble with tall formulas. The tooltip doesn't show up unless the cursor is moved to the middle of the formula. For some formulas this is OK, as users can be reasonably expected to put their cursor in the middle. For other formulas it's not. [See the link for] the opening of [[Companion matrix]], which has both a formula that works and one that doesn't:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562893799#Math_tags
It would be more helpful if the tooltip appeared whenever the cursor was over any pixel of the formula, not just a middle pixel. Ozob (talk) 01:21, 4 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: minor",52776,0,Medium,False
-0.6853612555577331,2.0708136876369068,2.5296284613577065,-1.4387168218675708,-1.0101793607913714,-2.0898806149830995,-3.6493268801528043,3.87821955858805,4.119983156721884,-1.5994884610678408,-0.5831540445953065,-0.4800452310646319,2.708962041696317,3.7593659253223777,-0.7148502866246016,2.1309916512692366,2.414063832804918,-0.4019975701630534,False,c1,3,"Use Firefox 20 or 21.
Place the cursor in front of a [1] ref. Note how the cursor doesn't seem to jump to another line, but instead go to end of page or toolbar.
I don't see this on Safari 6.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53750",52726,0,Medium,False
-5.680846555285365,3.4884826607852553,0.2852126499318075,-2.174628329558111,9.401717758115918,-1.9747690047306405,0.4877229985385725,1.2194029104174557,-1.4121145972951823,0.45831254531481846,-0.9954024100072729,1.7748359182540312,-0.6237564641167026,0.7512073977988853,0.16067461241867864,-0.08487727456014643,-0.4968445653197311,-0.8009544392352894,False,c1,3,"It seems that the visual editor can glitch a bit when it initially renders a template. Yet when the template is altered without changes this is corrected. (Firefox 22, Mono skin)
'''Steps to reproduce:'''
* Navigate to https://en.wikipedia.org/w/index.php?title=User:Excirial/Playground/Content&oldid=562754871 (Historical revision of my sandbox)
* Edit the page in the Visual Editor. You will immediately notice that the template isn't correctly displayed.
* Enter the template setting screen and just select ""Apply Settings"".
Once that is done, the template is rendered correctly. Note that the same template was initially added trough the visual editor itself and displayed just fine. Only when you open an already saved page it seems to glitch a bit (Until the settings are applied without change - somehow that corrects it). The page reports no changes after applying, so it seems this is just a rendering issue.
--------------------------
**Version**: unspecified
**Severity**: normal",52723,0,Medium,False
-1.4125012845184521,3.3023795400920974,1.0917595091246532,0.28931880009964606,0.3750419355332746,-3.786754698462981,0.4798242839355229,-0.3623211145887735,1.7853186658810827,-0.7401805480919688,-0.14785562540664898,-0.3645102982662367,0.8376666506491341,0.3272601283875147,-0.8871302966664736,1.3072801980953845,0.8693996311618177,0.6163575734691509,False,c1,3,"Our ""init"" hasn't been init for a long time. We load a lot of classes (ext.visualEditor.base and ext.visualEditor.mediawiki) for the ViewPageTarget.
### Goal
Integration layers in MediaWiki and elsewhere would only need the `visualeditor.init` module at first. This should provide them with tools to determine whether the current environment supports VE (feature test / browser sniffing), and the ability to then (on demand) proceed and actually load the editor, with an edit surface.
The init module would provide only a lightweight `ve` and `ve.init` object with little to no dependencies. Only jquery and oojs as dependency. Not oojs-ui or anything else.
For MediaWiki this means the mw.ve.init module would also take care of checking user preferences and wiki configuration with regards to skin/namespace/contentmodel etc. And mw.ve.init would also continue to handle the various skin transformations and loading bars (which would be readily available).
### Thoughts
Do we need Platform to bootstrap Target? Right now in standalone we do, but in MediaWiki we don't. It's up to the Target implementation to decide this. So let's keep Platform shipped in init.
Class structure:
* ve.init.Platform
* ve.init.Target.
* ve.init.sa.Platform becomes ve.sa.init.Platform. `ve/sa` becomes a showcase for how to bootstrap VE. Assuming we keep this generic, we can keep it under `ve.*` and ship it by default. If it becomes a demo instead that people should not extend but instead copy from, we should move it to a global VEDemo javascript namespace or something like that.
* ve.init.sa.Target becomes ve.sa.init.Target.
* ve.init.mw.Target becomes mw.ve.init.Platform.
Also relevant are the feature tests. Currently only our MediaWiki platform has these feature tests, we should move these into the base hardcoded in the MediaWiki platform. These should be moved to `ve.support` and become part of the lightweight init module.
* Feature detection (ve.support)
* `support.es5`
* `support.contentEditable`
* (maybe) `support.svg`, since we're currently repeating` ( document.createElementNS && document.createElementNS( 'http://www.w3.org/2000/svg', 'svg' ).createSVGRect` in five places.
* Browser sniffing (ve.support.browsers.{whitelist,blacklist})
See also:
{T52612}
{T75593} (and its dependencies)",52707,0,Medium,
-0.9451264867870988,5.776140632542884,-0.3335114619104811,-0.4715639390688333,4.04329681376932,2.4815315205770467,-3.3848552976904855,-0.7743278431310711,-0.8913469587561222,0.5324109673396533,0.22525783834630353,0.44250022417387536,1.1784619494804587,0.7425060796165335,-0.7161689814212719,-1.4505405202162922,0.43608268877934275,-0.6849773331844824,True,c1,3,"I apologize for the lousy name this is starting off with - I have no idea what toc all this.
Taken from English Wikipedia:
Time for another ""Why did you even try this""? kind of bug. (Tested on Firefox 22, Mono)
'''Steps to Reproduct'''
* Edit the [[bugonia]] article using the visual editor.
* Click the ""Aristeas and bugonia. Virgil's Georgics. Lyon. 1517"" image, which is about halfway down the article.
* There is an uneditable section a bit higher. It starts with the text ""If any further evidence is necessary"". Click that one.
* Now click the hyperlink button. A slight white block will appear on the image.
* Select any other word in the image and click the hyperlink button.
For some reason the hyperlink dialog box will now show up on the image, no matter what word you select. After trying a few times it seems to tire of that and starts jumping over the screen at random when a word is selected. The added screenshot is an example of this - it tried to hide behind the search box. Excirial (Contact me,Contribs) 19:37, 3 July 2013 (UTC)
Link to screenshot:
http://en.wikipedia.org/wiki/File:VisualEditor_-_Hyperlink_Dialog_glitch.png
--------------------------
**Version**: unspecified
**Severity**: normal",52693,0,Medium,False
1.9537436898737606,-1.509911645658418,1.5063455880692729,-2.993605076485727,1.3221684837348362,-5.888072652483846,0.9245067381570786,3.538740923295605,-2.326321032362631,-0.38373792215264224,-3.641659838142157,0.7636657650180729,-0.6174493777876959,1.4147050541823276,-0.3459127643256146,-1.7750722719944418,0.9500440078388162,-0.8352471978385325,False,c1,3,"On every page I load on IE10, when switched into compatibility mode, I currently get the following error.
oo.js, line 97 character 2
Object doesn't support property or method 'create'
Also, if VE is not enabled on IE10, then why is this code being loaded ?
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50612",52677,0,Medium,True
0.5918876403599413,-5.707495322580474,7.835706102971955,0.43572547185631105,-2.4424247991485326,0.9640176034478427,1.7853386714715818,1.7957278299114856,0.7659682778713348,0.21021103341351122,0.7706975185458975,1.3456898623167215,-0.6030328029628595,0.10652805556813494,-0.6903001273821392,1.6361703772911844,-0.2681340640927006,-0.4173303668643389,False,c1,3,"Parse wikicode and/or HTML in interface text. This is useful to make longer descriptions, i.e. with some lists, more readable, see URL for a trial.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://de.wikipedia.org/w/index.php?title=Vorlage:Normdaten/Doku&diff=120168256&oldid=120165159
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49772
https://bugzilla.wikimedia.org/show_bug.cgi?id=48451",52656,0,Medium,
-2.1509681290072944,1.3554001717132813,-2.053761451827656,-8.747831523452577,1.525829911351289,-0.8602474423909043,-0.2517888136399611,-3.6955142663596985,3.7204659214427984,-0.8985253686310424,-0.10902468126537723,2.450649462911425,-0.8376949053731835,3.0418240537557564,-2.448198471497409,2.795077495973698,-2.183109065951117,-0.6647543189121738,False,c1,3,"What it says on the tin; if you do nothing but rearrange text, the VE does not recognise it as an alteration and refuses to let you save.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49981
https://bugzilla.wikimedia.org/show_bug.cgi?id=50721",52643,0,Medium,True
-8.517946804563106,3.8966111618339276,-1.7160855396995558,-0.1570828854510311,-0.08412113869416094,-0.9858360743636153,1.525988786054148,1.7814898919958102,-0.5622423918750542,0.8948232554950799,0.7498454108643622,-2.986096371796873,0.47975352855404907,-0.8634807231059751,0.7695606283361345,0.22113438181295172,1.3918942584632343,-1.74101873196663,True,c1,3,"Some pages use anchors in the headings - useful for redirected articles. Can VE display these and make them editable?
Original request:
I noticed that when editing (e.g.) [[ https://en.wikipedia.org/wiki/TRS-80#Compatible_successors | TRS-80 ]] that anchor templates, such as the ones I'd included within the section titles (e.g. [13])- for links that don't break when section titles change- don't show up in the visual editor... but they're still easily (inadvertantly) deletable, simply by backspacing over the hidden markup.
You couldn't blame a newbie- or even nontechnical editor- for deleting something that wasn't even shown to them(!), but this is the sort of thing that could be a major pain in the neck.
While I'm in favour of the visual editor in principle (the ability to contribute content shouldn't be reliant upon geekish markup skills), this *was* an issue that concerned me when I heard about the idea- namely that the large amounts of complicated templates and markup (which IMHO will never be entirely representable in the visual editor) would be inadvertantly messed up, either by users or by oversights within the design of a ""helpful"" visual editor itself.
Ubcule (talk) 22:28, 2 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: enhancement",52633,0,Medium,False
18.399230304602746,4.468594773195164,-3.1796835134809207,-7.822047227499367,0.9712091724024592,-0.5125363676089043,-1.3866601502274065,-3.1278453717259858,-1.9316203533519902,3.410974760644649,-0.24606730217768735,0.950827273909655,1.056325995435199,-2.2896999712123507,-1.0782075551094357,1.0528076987009496,1.9237263633536885,2.1038357659839715,False,c1,3,"**Author:** `ryuch`
**Description:**
Korean input is not complete.
I tried to input ""한글 시험 합니다."".
But it eats up some letters and produce ""글 험 다."".
I tested with Chrome and Safari on Mac OSX. And it is all the same with Chrome on Windows XP.
**See Also**: {T52105} {T72353}",52631,0,Medium,False
4.248460240035477,4.739887292589483,0.5204547840433946,-3.5944751010668092,1.9878017028149477,2.968905833779589,-2.7197784312465734,-1.6341018860389052,0.6463855906995942,1.248901336233172,-0.625499575658583,-1.5684409298048871,1.492049177731944,0.8407709062598245,0.46323125397463993,-1.258652279467912,-0.1204248300958286,0.4656316214835654,True,c1,3,"From En:Wikipedia
""Interesting one that i just wandered across while looking at an old Articles for creation backlog drive, that causes a very interesting error popup to appear (Tested in Firefox 22)
Navigate to http://en.wikipedia.org/w/index.php?title=Baylor_University_Institute_for_Oral_History&diff=555106174&oldid=prev
Try to edit the ""Mission"" section in the VE.
Result: An error popup stating Error loading data from server: parsoidserver: Error contacting the Parsoid server. Would you like to retry?
This seems to be caused by the ""oldid=prev"" part. Normally this loads the revision prior to the Diff part of the URL, but it seems the VE cannot handle that correctly. Excirial (Contact me,Contribs) 21:25, 2 July 2013 (UTC)""
I tried this and had the same experience on Chrome.
--------------------------
**Version**: unspecified
**Severity**: normal",52615,0,Medium,True
-2.2774264743010777,3.3554783613319294,2.649413690346762,-0.4163319131655475,-1.343998056018774,0.13432968050111405,-2.0725958372802884,4.697910240683369,4.402345761132456,-0.032348924221498265,3.497564347544389,-1.103640321026705,-1.1066033771910346,0.9776725113616047,-1.9849773236118136,1.0003450259352342,0.27042040868302175,1.7721842016475973,False,c1,3,"From David Gerard on the en.wp feedback page: if you go to add a reference and then choose not to continue and exit out of the template and save the page instead of going back, VisualEditor creates an empty closed reference tab </re>. See here:
https://en.wikipedia.org/w/index.php?title=User:David_Gerard&diff=562600190&oldid=545746964
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52182",52609,0,Medium,False
3.726712329068,0.14106201608621838,4.023752777672449,-0.67061189462088,0.9101388919878666,3.1961347706606995,-2.1965087957283265,1.9366964195110352,1.9315550194690416,-1.2243301670003053,-0.6697845482182241,0.760729829145947,1.1978519739025146,0.18583753091032396,-1.1891611709336605,1.65472521177796,-0.6987655016701376,-1.3928200427838866,False,c1,3,"Compare the charts table in
* http://en.wikipedia.org/wiki/2012_%28It_Ain%27t_the_End%29?oldid=561481881
* http://parsoid.wmflabs.org/en/2012_%28It_Ain%27t_the_End%29?oldid=561481881
* http://en.wikipedia.org/wiki/2012_%28It_Ain%27t_the_End%29?veaction=edit&oldid=561481881
In VE, the table cells seem to be squashed into one. The DOM looks like nested divs there, which would explain the different rendering.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50951",52607,0,Medium,False
0.9972080750951977,0.3474578313518464,-2.3583180660713303,1.3881229137531914,0.8336858483519791,-1.2651689633154426,-1.7864057435305432,-0.5736659590780959,-1.6140976555314956,-1.9016378735062318,-1.8239137006926203,1.1766318840916419,0.9396710263087624,-0.20395556012626326,-2.1234193931071554,0.15202031435894342,-0.8651466397752293,-0.7384716363539321,False,c1,3,"**Author:** `kwwilliams`
**Description:**
VE can't properly display any table using {{singlechart}} on English Wikipedia, which makes any editing of the fields pretty dicey.
Taking http://en.wikipedia.org/wiki/5_O%27Clock_%28T-Pain_song%29 as an example (it's actually one of thousands), http://en.wikipedia.org/wiki/File:Singlechart-Articleview.PNG shows what the table looks like when being displayed. http://en.wikipedia.org/wiki/File:Visual-editor-singlechart.png shows what it looks like after Visual editor has been engaged. Note that South Korea (GAON) rows and Romanian Top 100 rows are generated by manual table markup and the remainder are template calls.
This probably comes about from two factors:
1) Singlechart generates a ""|"" or ""!"" internally to start a table row, based on whether it has been called with the rowheader parameter.
2) Singlechart generates another | between the two data items it outputs to separate the fields in the table row.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50366
https://bugzilla.wikimedia.org/show_bug.cgi?id=44498
https://bugzilla.wikimedia.org/show_bug.cgi?id=50951
https://bugzilla.wikimedia.org/show_bug.cgi?id=52296",52589,0,Medium,True
-7.62911982191064,3.8884488024441133,0.39293428823498644,-4.533651684929427,-1.2564341220708528,1.5621913476754041,1.4464142308367443,-1.5349863327044266,-0.8485675048109024,-1.5380833997446368,-1.0643316001333436,-1.1016890110863822,-0.7392725656770329,1.1686361734812953,-1.950189495693607,-0.15419002706448526,-1.5261010119286842,-1.588091021296963,True,c1,3,"As per http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Coords_not_displayed_in_title_when_open_in_VE , the coordinates move at the bottom of the page, where one is not expecting to find them.
--------------------------
**Version**: unspecified
**Severity**: major",52577,0,Medium,False
-4.7950030381913615,-1.971430983449375,-3.7548802944737147,-5.374858648476625,-2.9397288732087357,3.503647687485878,6.163703744133106,3.8060239494475,-2.1427567987243203,1.9097530464388397,2.1526045849461393,-1.4808751902165043,0.1138188629649628,2.9703797979055535,0.13620125633075997,0.6782212654039697,-0.9217107964215957,3.0308300678702818,False,c1,3,"VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552).
Both will lead to a DOM diff and thus likely to a dirty wikitext diff.
Note that this only applies to existing content- merging identical annotations in new content is fine.
--------------------------
**Version**: unspecified
**Severity**: normal",52549,0,Medium,False
5.509197218756842,-14.57269622096931,10.04335707137853,-1.5512343780420559,0.20951639556058466,-1.0441472323891614,1.264416412398183,2.1539988321827246,5.756838021484565,0.884500077316976,0.8054773897340324,1.7530315592798587,0.4023475759716737,0.4567576793744035,-1.1547805669578732,0.960134370247661,-1.277260846461445,-1.6112913662056156,False,c1,3,"See https://en.wikipedia.org/w/index.php?title=Russkaya_Mysl&curid=38914039&diff=562427330&oldid=555891306
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50720",52539,0,Medium,True
-5.307625931852684,-2.8145408056462795,-3.6048362434492063,-1.1678878885673094,-0.3319730578423033,0.6852920620977909,-0.3699663939948552,1.5949750741785844,1.444360381351532,0.25177768937570466,-0.8893476934868398,1.3005368268890873,1.0583947356212877,-1.8728575953697133,0.8024046490928018,-0.831185508137565,-1.8207356424198191,0.9750304284336317,True,c1,3,"English Wikipedia editor notes that sometimes when parent templates are removed, a subtemplate (or two) should remain, such as with Template:Multiple issues (http://en.wikipedia.org/wiki/Template:Multiple_issues). It would be a nice feature to allow the parent cat to be removed without removing all parameter, or permitting them to be ""escalated"" into templates themselves.
Realizing this is not likely to be a high priority, given more urgent issues, just putting in the request. :)
See
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562454889#Can.27t_unwrap_template_within_template
--------------------------
**Version**: unspecified
**Severity**: enhancement",52526,0,Medium,
-2.56042822834582,-2.3327600644220183,2.6342643572509026,3.512263873907423,-2.001681248202699,-1.5948141694358873,1.6114522668987128,1.881538935207923,1.1134713901424702,2.8655627517671247,-2.966085825600571,-3.6769500146212035,-2.6551811878616327,0.11400789634880404,1.3827322075475355,3.7282825548717278,-0.6711077236665388,3.2520048619381354,True,c1,3,"We need an integration and plugin system for VisualEditor, both for extra tools (e.g. ""YouTube video node handler"") and tool over-rides (e.g. ""MediaWiki-specific H3 handler""), as well as a more generalised system to do init and integration.
Enjoy.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52514,0,Medium,
4.292648328444757,-14.321257183842798,0.44328760016275126,0.820616728986888,-0.8581595152294876,-0.6166480448058766,-1.248299739606355,-0.7432314617224316,0.9379619689002601,-1.855370010640057,-0.34698466577933473,-0.2542721982400785,4.274984864842617,0.5789657350927273,0.5846183853761522,-0.28813008884400737,-0.028358793750008937,-1.0027031346298543,False,c1,3,"Screenshot
See screenshot - monobook, windows 7, firefox 22.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11469}",52508,0,Medium,True
13.457183710479192,-9.452784805886155,12.985164035900283,-1.517266041628199,2.8722402026976206,-6.53834155390921,-2.5189652065663055,3.6250121607762376,4.586282492368346,-1.7905927722037545,-1.2920003269125904,0.6586759389182049,1.7680138859205181,-1.7938760562725125,-2.83334300980483,0.9649863903036179,-1.9930361374990526,-1.7244522171950674,False,c1,3,">>! In T52505#562403, @GWicke wrote:
> We have a relatively complete DOM-based references rendering implementation in Parsoid that could be reused by VisualEditor. This would avoid us implementing two versions of essentially the same code, and with combined effort should result in a better implementation.
--------------------------
**See Also**:
{T52474}",52505,0,Medium,False
-8.546061204463278,7.858171548184579,-0.41369046813035837,-1.654522419113047,0.17456904962482478,1.7106950569676254,1.2796111223080322,1.6345012004662136,-0.6761340636526797,-0.03873471486266311,1.2851216382824506,3.1992213783163086,1.676925168632815,-1.9437861387121447,1.8226988847948364,0.6834565084142491,-1.2933082777983602,-2.669036754270074,False,c1,3,"A very simple mockup that I made in GIMP to show how it is supposed to look
VisualEditor: Link inspector is not oriented for RTL.
The arrow icon is supposed to point to the right, and be placed in the right corner, separated by a vertical line.
The title is supposed to be aligned to the right.
The chain icon is supposed to be next to the title on its left side.
The trash bin is supposed to be in the left corner.
See the attached file for a very simple mock-up of how it is supposed to look (it is off by a few pixels here and there - I'm not much of a graphic designer).
This bug is similar to bug 49613.
--------------------------
**Version**: unspecified
**Severity**: normal
//attachment link-inspector-rtl.png ignored as obsolete//",52490,0,Medium,True
0.8109852336121448,-11.098603469332883,1.6405658144828976,-3.1962857355622023,-3.325850124669392,0.9467037694957197,0.8786110742619124,2.5241733993440785,2.722435086666014,-0.5205437523787637,-0.5808204735991711,-1.238533222881473,0.4727770573543131,-0.5700636558068624,-2.121751134282427,-1.4939310863977535,-1.2398971666413363,1.1079557265314894,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Bah%C3%A1%27u%27ll%C3%A1h&diff=562302216&oldid=561967071 - finding out browser/OS now.
--------------------------
**Version**: unspecified
**Severity**: normal",52481,-1,Medium,
-2.8210829443094383,-0.5784004512929641,9.039710079953654,2.561728790121015,-2.8491375274138795,-2.369309629078516,-3.74033868252806,0.08597857198164949,3.6962183336446497,2.2661365547021655,-4.194749582697902,-0.5959529636039055,-1.2869548343177106,-0.07660654400509515,-0.43708877010657066,-0.741594439482012,-2.509024257961395,2.5545086844156675,False,c1,2,"Trying to ""Edit"" on http://en.wikipedia.org/wiki/List_of_Advanced_Dungeons_%26_Dragons_2nd_edition_monsters after a minute or so results in a popup ""Error loading data from server: error. Would you like to retry?"". Trying again, repeats the issue
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39057",52475,-1,Medium,False
-3.7722098023930366,3.410529490967079,-0.8690063495507179,0.8840927688956446,-2.4573222372713532,-1.0783149522727191,-1.049174234082657,1.3914174169751141,-1.3390528738930674,-2.010950897495562,0.8096688010387001,-1.9868333371761122,1.5077027042362108,0.9824472502037338,0.05976413365908417,2.3111357786203293,-0.09847541723315234,-0.9281825853786554,False,c1,2,"References added by templates are currently not very well integrated into the #visualeditor UI. Their footnotes are visible as #parsoid parsed output on the surface, but:
1. the number in square brackets on the footnote does not necessarily fit with other numbers visible from other footnotes
2. they do not appear in the reference lists in the editor
3. they do not appear in the list of references to re-use
A simple demonstration of the first two issues can be seen here:
| Reading | VisualEditor |
| {F56437741} | {F56437750} |
-----------------------------------
For example, look at [[https://en.wikipedia.org/w/index.php?title=Popocatépetl&oldid=667057679|this old version of w:en:Popocatépetl]]. It has 21 references, 3 of them in the infobox only. When you [[https://en.wikipedia.org/w/index.php?title=Popocat%C3%A9petl&oldid=667057679&veaction=edit|open it in VE]], those first 3 cannot be accessed from the re-use menu. In addition, all 21 appear in the references list, but each reference x in the text corresponds to entry x + 3 in the references list.
**See Also**:
{T52505}
{T53289}
{T54398}
{T55777}
{T54262}
Possible duplicate but might have additional implications:
{T87134}",52474,-1,Medium,
-7.562573117839074,1.0069648445660775,0.1556410709861673,-2.0895766373227693,0.49639837067051995,0.1894566091173442,0.2791237179464998,2.1128752025724507,5.6861518646309595,-0.11710733690104558,-0.03675596756303312,-2.065760097522006,-1.5907949224734557,0.3414350530395094,1.741158357981348,-1.0959554072692885,2.243431294119688,-1.5833662071420325,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Edamattom&diff=562268939&oldid=562266260 <- this was from an attempt to swap a references section and an external links section. We cannot have this scale corruption on launch. I'd be most grateful if someone could find out what the heck happened, and also confirm with some degree of certainty that it won't happen again.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51677",52465,-1,Medium,True
-7.569815553500547,-1.7229496389847974,-1.543874474374947,0.6992262751847322,2.2899504980961494,1.8218139103176767,2.4538172994944683,0.27436009843056974,0.17572182948391085,-1.7554692847148288,-1.7318459839141949,0.3949784963859895,-1.600059171420643,1.6354294914092122,-1.3057791934488607,0.3460212014435923,-0.9889667060037726,-1.0133817665695424,False,c1,2,"When a notice is shown (on beta), it's not possible for the user to mark the text and copy.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52442,-1,Medium,False
-3.5832780488701745,-7.195029177669164,-3.248549196903218,2.1635245857712957,0.5216156430276109,-4.698485728522336,-1.6435267619593725,-0.15192323759367837,1.8978846359313553,1.6956994916791155,-1.7264249022976677,-2.237578408967512,1.0524771425640953,-1.728312394875951,-0.9186484924111467,0.39803495976921804,-2.1791568017504646,-0.29334797040414173,False,c1,2,"When adding/modifying a template, you can append a space to the parameter, and even if you have that parameter already used, you can add one more. As well you can add a (multiple) empty "" "" parameter.
Example template I made ended up as:
{{test|name = ""
|logo = '
""| = | = |logo = }}
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61049",52439,-1,Medium,False
-2.828497642687935,-3.1342219005386625,-5.194937072528406,1.7986572822325084,-3.28054279517827,-2.455278345018524,-3.991541568382213,0.3996307362494723,-1.7123138747654365,5.812603809121356,-1.2653217929567016,0.832276485874645,-2.7905292036330938,-0.4042957888981116,1.916552268365252,0.08525637456505364,-1.4265723277937994,1.0930495339880923,False,c1,2,"This is a bug/design issuse with TemplateData.
To use TemplateData in RTL wikis, the syntax mix English and Arabic/Hebrew (etc).
Editing mixed languages with different direction is hard and should be avoided as much as possible because of BiDi issues. (in some cases, such as Lua modules it isn't possible to completely avoid it).
Example :
<templatedata>
{
""description"": ""תבנית כלשהי."",
""params"": {
""שם"": {
""label"": ""שם"",
""type"": ""string/wiki-user-name"",
""required"": true,
""description"": ""שם של משתמש"",
""aliases"": [""1""]
}
},
""sets"": [
{
""label"": ""Date"",
""params"": [""שנה"", ""חודש"", ""יום""]
}
]
}
</templatedata>
It is very hard to edit such syntax as above. (<templatedata> is OK since it is in different line - but the JSON isn't [if we don't want to define special indentation convention due to direction issues])
The syntax for the JSON keywords (description, params, label etc) should be either translatable or should have some neutral direction alternative to defines it (JSON by itself is directionless - [{}:,] doesn't have direction information).
See also:
* bug 50169 - implementing this feature may reduce the severity of this bug (this solution will force template editors in RTL wiki to use visual editor at least for templatedata definitions).
* bug 50370 - translation of interface items
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50370",52436,-1,Medium,False
-6.710422461680473,3.1257420493306114,0.8250946386558624,-1.7216169959161718,1.0246045426150008,0.9213234773088612,1.177780716006371,-0.1484556746514399,1.4912985607296767,-0.2071706104912714,1.0027147134165122,-4.128797554917629,1.0419766437945763,-0.8742929529572008,0.7608920576536491,-1.986589027235838,1.7828600593448012,-2.6055414697024606,True,c1,2,"I did not add this to closed bug 50012 because while it may be related it's not exactly the same.
This edit to the text of the article added extraneous pipes throughout (http://en.wikipedia.org/w/index.php?title=List_of_male_kickboxers&diff=562103247&oldid=561869162) and also dropped some formatting on the end (|}|}|}|}|}|})
See http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Unwanted_format_changes_throughout_article
--------------------------
**Version**: unspecified
**Severity**: normal",52420,-1,Medium,True
-2.648676844904771,-2.706398881820096,-2.072330402166795,1.7522220123918228,-5.648197635430678,-0.404866362428003,-7.229311596230632,-0.6567125173887073,-3.5922329311100967,2.5680536373874983,-3.4912881510200764,-1.610044517062126,0.04102816419111566,0.4026861266536734,-0.6713361590173443,0.05957122566711304,-2.8464223716195667,0.9116820071709195,False,c1,2,"Screenshot, cut-off notes list
In some formatting, the ""Notes"" section of an article gets cut off in editing mode display. Additionally, ""a,"" ""b,"" ""c,"" etc. get turned into 1.0, 1.1, 1.2 while in editing mode.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11283}",52411,-1,Medium,True
-1.889383732740068,4.173566171557045,1.3405298285643852,2.631741804435421,-1.420535767475205,0.6375604954557244,1.1322037437557038,2.6672823533468484,-1.308633945670156,1.6464870449887234,-1.115144257006437,-1.1123269273458416,0.12028279978502443,-1.0798572659024859,1.3967317445766323,0.2635318856668878,-1.4786634171938364,2.246030403510992,False,c1,2,"Creating a template entry, marking it and click on ""Link"" button results in following error (twice in a row):
TypeError: focusedNode is null
https://bits.wikimedia.org/static-1.22wmf9/extensions/VisualEditor/modules/ve/ui/ve.ui.Context.js
Line 260
VE is in a bad state after this cannot access template edit at all after this.
--------------------------
**Version**: unspecified
**Severity**: normal",52406,-1,Medium,False
-4.327082260343139,-1.4591719757220218,-3.2618550012861167,1.6447937272009283,1.7717561425606783,-1.8103253059723727,-0.07040604309968312,2.8946539101515607,-0.43066703233080217,1.4758321798983376,-2.5888150458469164,-1.1103156049033043,-0.42959080888411094,-1.3599512179315902,-0.2582974447564226,-1.1342062858497268,-1.697479478156189,0.9456614747743533,False,c1,2,"When VE is active on a page it inserts its own ""edit"" tab (veaction=edit) and renames the legacy edit tab (action=edit) to ""Edit source"".
Since VE is not active on all pages though the ""edit"" tab's functionality is inconsistent across pages (sometimes opening VE, sometimes opening the Wikitext editor).
VE should rename the legacy edit tab to ""Edit source"" on *every* page (even if it is not active and therefore not inserting it's own ""edit"" link so the button's functionality keeps consistent across pages.
This was also discussed on http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Change_the_.22Edit.22_tab_to_.22Edit_source.22_in_all_namespaces.
Please note (as discussed in the linked section) that renaming the legacy edit tab globally by simply changing the existing interface message is *not* an option. People not using the visual editor should not see ""edit source"" by default but should continue to see the same text that was always there.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50424",52402,-1,Medium,True
7.552955751280901,-8.984086353068369,8.526216721010272,1.523531672793713,-0.15391187940590173,0.5339470584037909,1.7619282087791808,1.088393111046471,3.482185577938602,1.3295409908608624,1.6173363881673786,0.07016976244536388,0.7234026011738601,-0.9649704070975846,-0.6759844808485829,0.7145468243807505,-0.9646157882291511,0.1533374695941665,False,c1,2,"Try editing the professional ratings template in https://en.wikipedia.org/wiki/All_6%27s_and_7%27s?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50551
https://bugzilla.wikimedia.org/show_bug.cgi?id=50910
https://bugzilla.wikimedia.org/show_bug.cgi?id=51708",52395,-1,Medium,False
-3.1480362111011195,-3.56547755837736,1.0322558223764773,4.506555793031234,-0.23664849692329243,1.1760038366402632,-0.6622152528014658,-0.07387702043234548,-0.8874066636455338,-1.2947300854801287,0.339043444647797,-0.9945957397049998,1.1121452963640825,-1.8624254943182663,-2.7064355548772085,0.6801967081347107,0.03218735240987525,-0.3464734217960592,False,c1,2,"Wikicode for inserting animage in a standard ways into Wikipedia:
[[File:Name.jpg|thumb|Text]] without any size.
VE adds a fixed size of 225x225px (why these numbers?) to the wikicode which is wrong for most Wikipedias.
The size of a standard thumbnail depends on $wgThumbLimits and $wmgThumbsizeIndex or the size set in the user preference.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://fr.wikipedia.org/w/index.php?title=Yael_Bartana&diff=94503286&oldid=90892725
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47804",52379,-1,Medium,False
-8.07765566576467,11.086168543045563,0.6892958161286984,7.515994523728438,0.2986404470315349,4.800880616705624,-3.2401455963569603,0.9936641153181341,2.966331192960455,-2.046825923530633,1.0563790771252672,1.1287186503406639,-1.0757076866225121,-0.24982555059251066,-0.8327674886222045,-0.2536263460718453,-0.21081476910772845,1.0400261723865774,False,c1,2,"TemplateData from transcluded items (i.e. doc pages) takes a long time to show up in the API.
A temporary solution to this is to do a [[ https://www.mediawiki.org/wiki/Manual:Purge#Null_edits | null edit ]] (opening the page, and saving, without making any changes) which will cause the template data to propagate immediately.
",52372,-1,Medium,
-4.661019723581809,1.0679437496758855,2.796994974909932,-5.112289545042155,-0.9005161081819215,2.1648632222826683,0.0929178330836713,3.0506957997232296,-0.05346727045017158,-0.8838313754159155,-0.0332488643430775,1.9435012110511798,0.08731233589666232,-0.6907702527448611,1.7831056907955052,0.0879253699735183,1.2300593242238713,-0.5031033703154981,False,c1,2,"This was seen in revisions prior to https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=561926823&oldid=561926781 and fixed in that revision.
For a reduced testcase see <https://test.wikipedia.org/wiki/Section_edit_links_bug2>. The cause seems to be the unclosed `{{`. Of course, this is broken wikitext, but the parser seems to be able to handle it fine (other than leaving out section edit links).
Sorry I can't be more specific.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=73182",52369,-1,Medium,
12.70817708041306,-9.360404963447785,5.34235002594367,-2.4354027361791024,-0.5323200567217974,-0.6533586926071497,-1.0093539848083921,0.6327372152278866,-0.04025835723166998,-1.5459307380617804,-0.6632938698784945,0.522575431240512,3.179159476254514,1.5419392904066829,-1.1861603452060274,0.2907780831503309,-0.7797938131303509,-0.9497734089660501,False,c1,2,"Screenshot
See screenshot; Windows 7, Firefox 21.0, on https://en.wikipedia.org/wiki/Rage_Against_the_Machine?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50589
**Attached**: {F11166}",52366,-1,Medium,True
-6.815994630739226,4.080086705998731,-2.1401890560525594,-2.340479512707821,-0.5671091626436557,-1.4337907989537686,-2.5151937932640798,-0.9928721498127923,0.24624073055455786,0.4937049657736914,-1.8737333130806266,-0.960867332761488,-0.26420471389554834,-0.2977047719242636,-1.7810767698718708,0.13794133315901513,-1.1990311677551957,-0.14458326814314315,False,c1,2,"How the hatnote appears in the VE when it is added
This takes some effort to replicate, so bear with me; if you insert a hatnote at the beginning of a line, it renders improperly in the VisualEditor - despite rendering properly in the article text, /and/ in subsequent loads of the VE. Screenshots of each attached.
As User:PamD adeptly summarises, ""if VE doesn't display the result of a change, or displays it looking wrong, editors are going to assume that their edit didn't work and struggle to ""fix"" it""
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11145}",52363,-1,Medium,True
4.833447097403276,-9.294293785383378,7.421680073278992,1.457015656620467,-3.672901151872028,-0.06196714583206009,5.143192207325545,2.49056273303211,2.884420689529824,2.635813235460784,2.1508024259104936,-0.6828115752553539,-0.10080269720233481,0.46708978573993143,-0.4119993118993941,-0.4496861117023513,-0.6666729374490578,-0.831630927154895,False,c1,2,"See Kelvinsong's wonderfully detailed bug report at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=561944647#The_Chloroplast_Test.E2.80.94June_26_C
--------------------------
**Version**: unspecified
**Severity**: normal",52358,-1,Medium,False
-6.030981187115205,1.4494895022554726,5.466270557111095,8.972503772157033,-2.438246434374583,-2.8123719988809777,1.0307392458813975,-0.37765198675889056,-1.0653006118987804,1.1933176156591445,-0.6734246561835993,-0.3490936018831755,0.8523337925775487,-1.5210352596189685,-2.7689209650334714,-0.8290556931469042,-0.2825091637381101,1.472976416006224,False,c1,2,"Many templates serve merely as wrapper around free-form wikitext content. TemplateData specifies the parameter type ""content"" for this purpose.
This task tracks the implementation in VisualEditor to provide an edit surface for editing the values of these parameter. Similar to how we already support rich editing of the content inside References.
Use cases:
* Wrap-templates. Such as message boxes, and the parameter-consuming variants of the ""something-start""/""something-end"" templates.
* Nested infoboxes.
* Simple infobox fields that support text but allow/encourage use of inline templates for formatting. Currently these expose raw wikitext to end-users.
>>! @Ironholds wrote
> A lot of infoboxes et al - the one on https://en.wikipedia.org/wiki/Fulgencio_(Modern_Family) comes to mind - have infoboxes /within/ the infoboxes that need editing. I'm not sure what the answer is here - it feels wrong, somehow, to offer an infinitely deep template inspector inside a template inspector inside...etc, but I can't think of another solution short of manually going around making the template namespace make sense or accepting that users will always have to learn markup, just not immediately.
",52355,-1,Medium,
-7.392414329006531,0.5343117925816845,-3.618187392388675,-1.2181548108583118,2.2353818005017727,-3.17159165664995,0.8722362959030754,-1.0508411256908727,0.44413466969662885,-0.8694167049414401,0.36955052708174474,-0.43690491693494193,1.810491605060117,1.3925096116178857,-0.6058377427935095,-0.589986212017994,-1.1376507477674112,0.6796881497291134,False,c1,2,"The current workflow for adding a new template; you add the template, you add parameter 1, you go to add parameter 2...only you can't, because adding parameter 1 jumped you to an entirely new tab that doesn't contain a mechanism for adding parameter 2.
It'd be good to have some mechanism to add additional parameters that is more intuitive - something as simple as not jumping a user to the parameter page, even. I appreciate bug 49778 partially solves for this but it's going to be a looong time before all our templates have templatedata.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51774
https://bugzilla.wikimedia.org/show_bug.cgi?id=49772",52354,-1,Medium,True
-7.524695143077354,-0.5751209476820431,-3.0721231932828506,-0.47174168887023915,1.7655404413997071,2.6586257680621026,-0.15890239593086886,0.3185139040029089,0.37175180839285105,-0.36452978980581463,-0.4202453290171526,2.294089225377868,0.547386383891554,-1.1214007288450412,0.22727920512452915,-0.6339434124117541,0.13156806573399504,-1.0382525311881001,False,c1,2,"The cursor cannot be placed below the last line. This sounds trivial, but there are a lot of situations - adding stub templates, or defaultsort data, for example - where being able to trivially flip to the end of an article and have space to write is A Good Thing (tm). It'd be good to have a temporary line at the end of an article that isn't saved unless it contains anything.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52353,-1,Medium,False
2.047873811103757,-4.82537946464554,0.49382624950966303,-0.33636503456161326,3.601671522963413,-0.7486579602722275,-6.532352401309404,-0.508140915392197,-0.24617467791605618,2.1634238850609186,1.956177485334805,1.8144707137485099,-1.8195398070369961,1.5312619502913423,-0.4147826500718601,-0.23591628476567672,-2.618163883086182,0.5098613145428168,False,c1,2,"1. Edit [[testwiki:Displaytitle]] using VE
2. Using the transclusion dialog box, add the following ""template"":
DISPLAYTITLE:''displaytitle''
3. Save the page
The page title remains ""Displaytitle"" in roman type.
Expected to see ""displaytitle"" in italics. This is what you see when you refresh the page.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49667",52341,-1,Medium,False
-0.4534814479208058,0.7603735176129387,-3.618831314639735,-1.3761284813376458,-2.8348613968944147,-1.7143329088441757,-0.5933329261435842,3.3394771097622935,-0.11744361477034507,1.313503101818081,-0.5367749637330257,0.1201219532925033,2.144550174870903,-0.8809084494181612,-2.4038492384677785,-0.12733871301309468,0.022477978471993287,0.9942242562416397,False,c1,2,"Using ctrl-click (but not middle-click) on a ""content editable"" link, does not currently work with Chromium37, but does work with Firefox39.
Using Middle-mouse-click on links does not work in either browser
Using Right-mouse-click to show the context menu with ""Open link in new tab/window"" does work in both browsers.
(Prior description had different results for Firefox 22.
Ed notes below, that this is all browser-specific behaviour, and rather than overriding that, we should just solve {T56759} (Done))
See also: {T52741}",52321,-1,Medium,False
5.5312277904652,6.0764916538198825,-1.4886609087055156,-9.57655557713775,-4.466729938246191,4.727101438371236,-0.15356888804954671,1.4227629855613775,0.39895847632977144,0.6932996236084872,-0.4522635710916276,1.8953921547513766,0.026714500989594825,0.6886087636897953,-2.087914624492024,-1.2755109187874993,3.8280511142588516,2.3987929993194843,True,c1,2,"Try and edit this version of my sandbox http://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Sandbox&oldid=59706098 which is empty except for a __NOINDEX__ ; VE just keeps loading and won't allow to edit. Happens at least with Vector on Chrome and Monobook on FF.
--------------------------
**Version**: unspecified
**Severity**: normal",52289,-1,Medium,True
-8.423812758311334,-1.2787108215162188,-7.9069578385148205,-2.3983509717299407,-2.0474527003457723,1.6960553004704366,-3.7643785425864906,-0.4620668729884051,0.8891268274822994,-2.3001602236837257,-0.4892907718686721,1.8328233581333635,-1.2903882023236788,0.4828560924224661,0.5713186378020838,-1.3340769338669707,-0.5745547958659345,-0.008413468990977835,False,c1,2,"When the transclusion editor is emptied out (e.g. by removing all the items), it should not just be blank. This looks broken and is confusing to the user (should I wait for something to appear? is it stuffed/errored out?)
There needs to be some kind of textual label in the empty transclusion editor, that makes two points:
1. that the user can click [+] to add something to the transclusion
2. that by clicking ""apply changes"", it will remove the transclusion
--------------------------
**Version**: unspecified
**Severity**: enhancement",52281,-1,Medium,False
-5.834463171170713,-1.8250887732175194,-2.086418520854357,2.7979232183475022,-0.16020933789649533,-0.2703850536271283,-2.199021463882803,1.387206304339148,-1.6755965767288403,2.6266658502343265,-1.6147002177271739,-0.759358390213238,0.9582745808165489,-1.6300871330407247,-1.9988807025199198,-0.9669107133560222,-2.2057524093883685,2.0870340698869088,False,c1,2,"1. Go to some page and edit in VE
2. Click the ""Link"" toolbar button, type ""Category:"" and click a category that appears
The leading colon is correctly added, but the category now appears in red in the dropdown as if non-existent (although it shows up under ""matching pages"", not ""new pages"").
Probably, the link inspector should be ignoring/stripping the preceding colon when checking whether the page exists.
Same thing for links to File: pages.
--------------------------
**Version**: unspecified
**Severity**: normal",52279,-1,Medium,False
8.351526760084223,-2.5782647439716175,0.4740458748568628,-3.3689606376423455,1.9332720600207876,2.788198211580003,-1.7032247127020401,-4.522145581989172,0.6110231534933881,-2.0253242489560312,-0.5698772428429568,-0.3748624495386207,1.8583597365369742,1.993299446384941,-0.8719080876781709,0.6812324534821735,-0.6404921548336928,-1.3380018285244755,False,c1,2,"Screenshot
See the screenshot (provided by a contributor). I suspect it's down to the screen resolution. Firefox 21.0, Mac OS X 10.6.8.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11863}",52269,-1,Medium,False
0.4621565334979074,-10.06114210135215,6.644166688972216,1.6842930947071437,-1.343824278079443,4.450016652012037,1.0346563536893614,-2.23334899742883,4.689245458342716,-1.6680469556774726,-3.25928261418199,0.3117328107150481,-3.2882484710647306,2.2730324853507318,0.4579245550101403,0.19349039798724194,0.48000520212903797,-0.9138589888621951,False,c1,2,"See the report at https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Failed_attempt_to_use_VE_to_remove_a_template_parameter
--------------------------
**Version**: unspecified
**Severity**: enhancement",52268,-1,Medium,
9.365128147267422,-4.063500626425602,7.468370477316981,6.113703458729688,-0.9114827077920703,-1.278915761797484,2.240176836622031,-4.229766952877531,0.9064568342036134,-1.0995711187804904,0.3235540101593384,-1.0233183501854644,-2.53531322212421,-0.8198068991793015,0.3616567411826699,-1.1746150860650408,0.444874678085468,0.28926195407160615,False,c1,2,"**Author:** `rachelqa99`
**Description:**
This it the top level links English, Talk, Preferences, Watchlist etc appearing on top of references window
--------------------------
**Version**: unspecified
**Severity**: minor",52247,-1,Medium,True
0.8463795715554769,0.44621611993091825,0.6499053209008245,-4.097490644871904,-0.35178034617201104,2.105032996291471,-0.6112704617269822,-0.48405477303803673,4.2392955780043415,0.8888322894990459,-0.22648511231053048,1.096475401711669,-0.28742757880772984,0.6010321924591606,0.14858715221334418,-1.4200947206095056,-1.2594383339100266,-0.8944325993350777,False,c1,2,"Totally a nice-to-have; it'd be good if the link inspector could inform users that they're linking through to a DAB page.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50160
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208
https://bugzilla.wikimedia.org/show_bug.cgi?id=49502",52240,-1,Medium,False
0.6823420078313336,-0.4668539847576785,-4.50393650927715,-1.3673176624252352,-0.5839752237739436,2.6453584540590596,-0.18082082462499205,-1.0942173060742169,2.918708299986963,-4.162475453697325,-5.221265725924117,4.537711385713108,-3.4441987843909523,1.1836029347715362,1.4792613355120983,-1.2047625360655176,0.060769340670665084,0.7002393163529781,False,c1,2,"The Qunit jobs are currently running on the master, they need to be moved to
gallium slave nodes.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",52231,-1,Medium,True
-6.217822554268706,1.6130873968811041,-4.065813108283692,-3.6106507148561606,-0.15700209385042474,-1.1282654680589823,-0.3738736166252412,1.9661653245719148,-0.6721467496387953,3.488294619886638,-0.6180765841708897,1.8643676441257184,-1.0221348953982563,0.6890049274916414,-0.39091723453010907,-1.0890370343634297,-1.6783492369912403,-0.91508614582351,False,c1,2,"Screenshot: Narrow window
When space is scarce (for example at high zoom, or when the window is very narrow), the ""View history"" tab is moved to the drop-down menu (that also includes ""Delete"", ""Move"", etc.) so that the action remains accessible.
The ""Edit"" and ""Edit source"" tabs don't seem to do the same; they stay where they are, which prevents them from being used in similar situations (see attached screenshots).
It would imho make sense to migrate both tabs to the drop-down menu as well when there isn't enough space to display them at their usual location, so that users can still access the edit modes.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11766}",52225,-1,Medium,False
5.2969845245653,-2.872854884126422,-1.7013449220859496,-2.7580069960009066,-0.1087834041511434,-1.0762031059888169,-0.7575598344200207,2.879962070800373,0.699710982371391,-0.8087700789007686,2.7524477477238887,-1.5565607110143898,0.7449498121647111,1.722649795393246,-0.04311093135263189,2.6116655433785434,-0.759497373254393,1.1125618155804935,False,c1,2,"1. Go to http://en.wikipedia.org/w/index.php?title=Black&veaction=edit
2. Middle-click or ctrl+click on any wikilink
You get a 404 page, e.g. http://en.wikipedia.org/w/Outer_space
VE should use fully qualified hrefs (/wiki/foo), just as MW always does.
--------------------------
**Version**: unspecified
**Severity**: normal",52216,-1,Medium,True
-0.36528470556663883,1.8806958882240856,-0.42862259557118243,0.8267894925106865,1.13629834277018,-0.7691233406990314,-4.723978112176493,-1.5185215566223031,-0.4442960528450143,-0.8358415313628531,2.371070519097556,0.3436908704215287,-0.234903799067113,1.284075653376112,0.40771370266988693,0.12247039705228516,-1.2146710878678042,1.0430589115591926,False,c1,2,"(Sorry for carelessly filing a dupe before (bug 50207) - I have checked this one, but if it is a dupe, you are most welcome to trout me for wasting your time!)
1. Edit [[testwiki:VisualEditor:Links]] in VE
2. Make a selection like
Golden Gate National Recreation [Area is the] best
(partly inside the link, partly outside it)
3. Click the ""Link"" toolbar button and make a link to any page
4. Click in the word ""Area"" to move the cursor there
Two link icons appear in the floating toolbar.
5. Save page > Review changes
Wikitext output has two links side-by-side, pointing to the same target.
--------------------------
**Version**: unspecified
**Severity**: normal",52208,-1,Medium,True
-1.5182333790474518,-12.42361887425794,-6.857457217918956,7.11473602152976,0.016127908496877952,1.3579425559099605,5.13685758375808,-1.3568253274987803,-1.382262341085094,-1.4310839361945282,-1.513508490394291,3.161712821380255,-0.1145014389503416,2.3233454364579433,3.7725999895328846,-0.6656401054517127,0.21563676145871113,0.33490210238295837,False,c1,2,"3 parameters is the limit, 6 is crazy.
ve.ui.PopupWidget.prototype.display = function ( x, y, width, height, transition, embedded ) {
--------------------------
**Version**: unspecified
**Severity**: enhancement",52197,-1,Medium,False
-2.9741841289216078,2.676866080228855,2.9453139936630848,2.7538465659053197,-2.50357194582205,-2.4093409780333834,1.1845297735710716,0.21458679782424994,-1.1416513457103696,-1.2959315303893963,0.10635571490820972,1.2127931237439953,-1.1589550952593708,2.019495178765265,-1.9406537048275396,0.4083860521679792,0.12202037141617694,-2.1492738146171804,False,c1,2,"screenshot of nested templates in VisualEditor
Templates are sometimes nested into one another. For example, https://en.wikipedia.org/wiki/Template:Chembox relies on sub-templates like https://en.wikipedia.org/wiki/Template:Chembox_Properties , which itself relies on other templates etc.
VisualEditor currently doesn't seem to handle these sub-templates. It shows a nice interface for the top-level template, then shows wikitext for the others (see screenshot).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F11704}",52182,-1,Medium,
-5.4794979021771715,-0.9608301588408334,4.780839762828144,0.6210322540458013,0.8332861278656274,-3.381238798813394,4.533322355031747,-2.6628034228977424,-1.242326838729587,-0.7616937226825389,-0.4659287185991934,-0.06180360620012193,-1.8735935263296968,0.26099369278419626,1.1275647888047686,2.555326989581527,-3.5926503278974034,-1.1336897162908568,False,c1,2,"See https://en.wikipedia.org/wiki/Template:Userspace draft - when rendered in the VE it displays the mainspace appropriate text regardless of what namespace it is in.
--------------------------
**Version**: unspecified
**Severity**: minor",52172,-1,Medium,False
-3.734150271229265,-0.9252094045120582,-2.483621719850566,0.6623327554667902,-1.0129258423885092,-1.8198167079739611,-2.3381147554055497,1.3006045397756183,-1.841489265972177,6.971737780956701,-1.884307632817114,1.249516204880061,0.2753877447395596,-1.82813589593936,0.8558696822886853,-0.6843727322523547,-1.2236567776909464,1.4795884527147745,False,c1,2,"In the Reference editor we have two fields:
""Re-use by this name""
""Use this group""
These names are useless for new editors (too cryptic and unclear - what is ""re-use""? a verb? referring to what?) and also unhelpful for established users (they need to know that these are totally identical to the name="""" and group="""" attributes). It is also not clear that they are only occasionally needed.
Something simpler, like ""Reference name (optional)"" and ""Reference group (optional)"" could be better.
Same in the Reference list editor:
""Use this group"" -> ""Display references belonging to this group (optional)""
--------------------------
**Version**: unspecified
**Severity**: enhancement",52171,-1,Medium,
-4.4762081394726785,1.6410655057419739,-4.131444939542474,-2.9689795166041946,-4.103585504433972,-1.6111393354800607,-4.237169235099972,-1.4798614982889688,2.0560025782356774,4.8714045140803925,-1.919258547705231,1.013014491184934,-0.6945254761175583,-0.19738550887588868,-0.47930717736959405,-0.1046559264793076,0.9169495105379626,0.4699535220092643,False,c1,2,"Planned features, such as searching for an existing reference by content, will require us to implement some http://en.wikipedia.org/wiki/Unicode_equivalence .
We will probably want to use NFKD (""Characters are decomposed by compatibility, and multiple combining characters are arranged in a specific order."") to catch cases such as 'ff' === 'ff', and we will probably want to strip combining characters (i.e. all accents), so that 'Amelie' === 'Amélie'.
https://github.com/walling/unorm looks like a good library for the job. We may want to fork it into UnicodeJS.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52167,-1,Medium,
-2.5861500522261602,-11.82789296057361,-1.762328719390041,1.1454505071024759,5.123735693499796,7.878856833909457,4.397289517292626,0.9161343142676895,0.36229555208339115,4.643672686493522,6.367324006717103,1.6147839914450024,3.028392427609142,-1.9876030054287006,0.539766711335071,0.6428566765251353,0.9835185004635225,0.3546139590946311,False,c1,2,"See https://en.wikipedia.org/w/index.php?title=User:JohnCD/VEtest&diff=prev&oldid=561397375 - the header is de-headered, and a spurious nowiki tag added.
--------------------------
**Version**: unspecified
**Severity**: normal",52126,-1,Medium,False
1.8872954884906226,-12.409504624530147,4.038514770939706,-1.8264006453161117,-4.719210791060695,3.3143805663861023,1.9232503118027466,-0.0984691624446459,2.897051097818557,0.9218855317775407,0.510185267845046,0.6108086649822304,0.12707573245163228,0.29302917921227056,-1.10860205551052,0.0685953486095347,-0.20158352902850396,-1.2507849160040405,False,c1,2,"See https://en.wikipedia.org/wiki/Chloroplast?veaction=edit for example.
--------------------------
**Version**: unspecified
**Severity**: normal",52113,-1,Medium,True
7.303017361155707,-13.948787030170077,3.328941766776719,-2.766555834847524,0.37219983512354904,0.3463577111290004,0.3343184199073228,1.552157350388728,2.34306108591882,-0.46193029679977915,-0.30297520746780693,-0.4078289814944075,0.7372462743364752,-0.9908246920575308,-1.6558354459492435,0.24598514142014272,-0.9441864963766572,-0.9984975440201721,False,c1,2,"https://en.wikipedia.org/w/index.php?title=AES11&diff=prev&oldid=561340674
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T57769}
{T61647}",52100,-1,Medium,False
-8.6494375107732,7.231405083314463,-0.5163409614373986,-2.8825376759774946,3.9302036166849557,-0.16600186613341916,1.051565053311311,1.0388386111353731,0.6048077603519472,-1.157444781586383,0.22799236266113532,0.47771616907650416,-0.4798601946411223,0.22293690443074166,-0.7390711240773591,-0.8868241469373213,0.15297082486539892,1.2244391088065465,False,c1,2,"Some experienced editors are complaining that writing in VE is slower for them now, because they have to use the toolbar. They are requesting to be able to use wikicode from within the VE.
Instead of fully introducing wikicode into the edit mode as some people have requested, I have a different idea. What if we use [[ and {{ as hotkeys to open the insert link and insert template dialogs ? When detecting this combination, the editor could automatically remove this characters from the editsurface and present the dialog to the user. Then the user can keep typing, greatly speeding up the time to author a sentence.
These are by far the most used insertions I presume. File and external links are much less common, and I don't see how you could easily have a hotkey like supo
I think that would solve much of the concerns that have been mentioned.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52093,-1,Medium,False
-0.08162271569906032,-0.7348183178722127,9.217751417517388,5.691122676764168,-7.311452827334236,0.3640117006194026,0.7641984399716577,-1.5639775105052642,1.4490937226879832,-1.3331263737554826,-2.371565868963625,-1.156901081533771,-1.224171086298182,-1.1383113775801053,-0.005379815993610926,4.360800825385187,0.9444022255003766,0.7183609741265411,False,c1,2,"Compare the number of columns in https://en.wikipedia.org/wiki/Kartik_Poornima in read and VEdit mode.
--------------------------
**Version**: unspecified
**Severity**: minor",52075,-1,Medium,True
9.657169083612775,-12.990262270861562,2.2761496096203437,-3.8501517801024474,0.996829451715673,0.5658145841447808,-0.43180986258217313,0.8651072501897105,0.8725895676420425,-0.9424524635044391,-0.5679188931576702,0.8588125285688444,1.2563566237855133,-0.7577731579147109,-3.188799318741727,0.6660630615798584,-1.3211105141632962,-1.4990205666184107,False,c1,2,"Screenshot
See screenshot.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49818
**Attached**: {F11448}",52074,-1,Medium,True
-6.233511699614905,-1.7896073683236313,1.1847189271089782,2.0948825902105694,-2.81891083833925,2.6420786931962317,0.8275167241561867,-3.8616519384945645,2.7279867554297903,-0.4011848221601211,0.14480018959349694,-1.7516875508318248,0.17303152304816294,-0.33227513171328127,-1.1323074369807316,1.1443161882411168,1.0699204030467253,-0.3775457603486474,False,c1,2,"See screenshot; problem with the template or with the parsing of it?
--------------------------
**Version**: unspecified
**Severity**: normal",52069,-1,Medium,True
2.694422818226099,-7.627799958645084,1.4868901811636306,-2.5255726766629896,2.2597362998022708,0.28588024936273393,-0.07339661595860836,4.825772323196934,3.7753647995409514,-0.8197884008492027,-0.776811188733046,-2.7897023694407466,0.2913851334820885,-0.3097092816404734,-1.5432576403870515,1.397287805828344,-0.2719363382064337,1.254555266289587,False,c1,2,"...and quite dramatically - take a look at https://en.wikipedia.org/w/index.php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
T50830",52052,-2,Medium,False
-5.116811991984998,2.4667797101457474,-7.4994096527529255,-2.5985992805644473,-1.5404194846950505,0.17523340838943535,-0.6197040634388893,-0.04478057613598602,-2.4789372779783196,-1.149370376353061,-1.8403953970809828,-1.9995113500308712,1.4969061356478823,-1.2098020045103244,-0.8848490657405357,-0.4263758095645843,-0.06687303505623787,-0.2609090108601433,False,c1,2,"The main reason for this still being true was screen-scraping bots (together with $wgHtml5).
For some reason when $wgHtml5 was finally enabled we forgot to also get rid of wgWellFormedXml=true.
We should disable it by default for the same reason we now enable wgHtml5 by default.
This is mainly bugging because of the ""&&"" sign we have as of recently in the default html output, which, due to wgWellFormedXml, causes an ugly CDATA section.
--------------------------
**Version**: 1.22.0
**Severity**: normal",52040,-2,Medium,True
-10.933531918971532,6.307724231316566,1.1802762977974375,1.6267335837100725,-5.81374246553175,1.5586620534640894,2.499307682201178,-0.05207763974216589,0.1166644348272165,0.022471567068883758,0.18785927761363386,-0.5824060438141286,-0.2932288830344145,-0.7174038013533535,0.6624107593431967,1.7884603184204093,-1.932964894459594,-0.3909200874172103,False,c1,2,"Self-explanatory, albeit poorly worded; if you type something out in the edit summary box, and then click on a point in that text to move your typing cursor....no luck. This is going to be a total pain for things as simple as tyop corrections.
--------------------------
**Version**: unspecified
**Severity**: normal",52014,-2,Medium,True
34.989321792109095,-0.40808038561669413,12.460187845194174,-5.708524485753924,-2.0111667581187938,0.05432141959534653,-9.0373891286588,-0.41381872970350336,-3.86819580957037,-4.114594388135794,4.775964445900252,-0.8474499343530073,-1.1254806517546587,0.8140110819652628,0.7637239460644025,-0.9784970259976435,0.7291502476088423,0.01658823905182194,False,c1,2,"From [[Wikipedia:VisualEditor/Feedback#Editing_Defaultsort]]:
> The Page Settings box displays the article title as a default ""Defaultsort"". But it doesn't seem possible to edit it: typing any letters removes the whole existing text, while trying to delete a few characters has no effect. Where the sort key is not identical to the article title it's usually a variation of it - delete a leading ""The "", or move the given name from start to end. It's a waste to have to retype it all: we ought to be able to edit that box.
>
> This is because the default defaultsort value (article title) is implemented as ""placeholder"" text. Instead, it should be normal editable text.
>
> Upon closing the page settings dialog, the logic should be, ""if defaultsort != article title, add a {{DEFAULTSORT:}} magic word, else remove existing {{DEFAULTSORT:}} if present"".",52002,-2,Medium,False
-3.5551273615192036,-6.299770996771738,2.6307689825704443,1.9070817790234775,-6.566200668264273,1.4447451196223804,3.481051790406643,0.7661362913595388,-0.5567139839448294,-0.3043958454145139,-0.6810611262948356,0.6596920599696303,0.5077875086807788,0.7622892207001533,0.47554405097927255,-2.0505049318579545,0.34276552594298737,0.3536516058104946,True,c1,2,"More general bug, following on from bug 41150 - this is for text selections, for other generated content blocks, ? others.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50643",51981,-2,Medium,False
0.6885189412695016,-16.777936138457765,-2.4478311504948067,0.9043307314391582,-1.9012244827990963,2.513897894757428,2.1396736646625625,-1.7750720679462444,1.0172371401266918,-1.5751644097825235,-2.270828888045429,-0.7573643459537795,-1.4739151421606902,-0.25519456826633835,-0.3278118989675365,-0.25432301057242124,0.10100572752280246,-0.2052124178597725,True,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: minor",51977,-2,Medium,True
-3.0851286300959955,-2.2637500823832486,7.045597821536244,2.49209457528138,-3.168211661030171,4.238036153623134,-0.7039753439776044,-0.5798976213199362,4.2366620183725745,0.022977879324677986,-0.09485150701843814,-0.12329601033823123,0.4149607852713233,0.15029046164334492,-1.6716621174759014,0.8424810182213706,1.8068936460338423,-0.27019024870676667,False,c1,2,"See https://en.wikipedia.org/wiki/Virivilai for example - bug with the VE or bug with the template?
--------------------------
**Version**: unspecified
**Severity**: normal",51968,-2,Medium,True
-6.904128649184533,4.326580333728437,-3.0444323829374245,-1.1659664397112546,3.4216244737781145,-0.19194094080059,3.4109179728764127,2.2489305611775574,-3.3890303077432,0.257098168897107,0.1947506185621135,0.3458804876898418,-0.2203985361547467,0.5128313172850607,-1.8092555814834208,-1.504827646881167,-0.37640779605968255,0.49362042406520357,False,c1,2,"The VisualEditor isn't perfectly rendering markup yet (which is understandable), and even when it does it'll look slightly different from read mode in a lot of ways. The problem is that cancelling the VE editing interface, or saving, loads a VE-rendered article view rather than what the article actually looks like.
(sorry if this sounds nonsensical; it's difficult to explain at this end).
--------------------------
**Version**: unspecified
**Severity**: normal",51964,-2,Medium,False
-9.945510019780603,12.04729686095422,0.9186760240292813,1.3406231810884184,2.017913687621041,1.0239584359228309,-7.9143693509812,-4.253649240768051,1.9082223852947056,7.3603196208715005,-4.444446756811245,0.025926820656742233,-1.4805223834392525,2.1696186459759454,-1.4581065707514371,-2.057061573646363,1.6938989179256938,-0.5271239847028704,False,c1,2,"If I try to edit a number in a {{formatnum:…}}, the VisualEditor displays the template’s edition window, saying it is (for example) the 'formatnum:959719' template, without any parameter. So if I want to change the number, I need to remove the 'template' and then to add a new one, for example 'formatnum:958719'.
The editor should allow changing the number without having to remove the 'template'.
",51954,-2,Medium,
0.756486094738102,6.490344153909849,-0.4646392310961662,3.5812998598678396,-5.703748119349823,2.2150023483090537,-2.2401397586236977,0.3413632802857537,-4.6160902180107986,3.5962133177179343,-3.2771859457140398,-2.1431245387365436,0.9406936730776754,-1.5525226388539726,0.35437699449332616,1.2694811349251092,-0.8307066244782321,2.640515824275713,False,c1,2,"The browser window title is changed to ""Parse error at position 0 in input {{""}}{{{1|$1}}}{{""}}"" when editing an article with the VisualEditor on dewp. Reproducible in many articles and at least Firefox and Chromium.
",51951,-2,Medium,False
-1.330820090774788,-4.384254642930289,-4.901785684893353,0.2582285197860863,-1.491977586801219,-0.5183381457305086,-1.1683760035752364,1.796385588115196,-0.2924350420222495,-1.6675642103756965,2.261030520168133,-0.4491795737808223,-0.5313381649726745,0.5062443077565053,-2.2737636251175566,1.409984474693982,0.23240461338771023,0.6315638162741075,False,c1,2,"Steps to reproduce:
1. open article in browser window
2. open same article in another browser window, edit, save changes
3. edit with VE in first window
Expected result: VE show some sort of warning, and loads the newest version of the article (or maybe refuses to edit it at all).
Actual result: VE happily edits the old revision, and shows [[MediaWiki:Editingold]].
--------------------------
**Version**: unspecified
**Severity**: minor",51943,-2,Medium,True
0.21483795678056827,-0.8780039249422753,4.2077569103252515,-0.3073385323111737,-4.140195201033529,6.715434084222312,-1.3055759166711036,-0.8376242319501424,1.340221404598606,-0.6622108566868583,-0.7390875284866993,-1.9716116263434575,0.38337173909848765,-0.3698417007937138,-1.604796254233789,1.650041142627759,-0.15999216787361026,-2.0903294711146776,False,c1,2,"See, for example, the lead of https://en.wikipedia.org/wiki/Flaming_Pie in the VisualEditor.
--------------------------
**Version**: unspecified
**Severity**: normal",51926,-2,Medium,True
-6.843958141784271,-4.429334216047135,-3.9619831068835794,0.3057524266253917,-0.41127319111046495,-4.953171296346981,0.1970326405939833,1.8612848426668074,3.368465974752513,-1.5241251439099646,-2.4262520733180866,2.3540776758235644,0.042596026471371395,2.8831060090832397,-1.9406747988653872,0.8502242778234502,3.2777770331879967,-1.5052080309823481,False,c1,2,"e.g. I don't want to see this:
.ve-ui-mwReferenceDialog-body {
padding: 2em;
}
and have to apply that to each dialog that doesn't have panels.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51924,-2,Medium,False
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,False,c1,2,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",51923,-2,Medium,False
-3.6973487306857837,0.5126941817979187,-4.556661025305036,0.39336443989668113,3.457949543266109,8.462094121610066,0.8450068528724586,1.3577309111559672,3.915324978682472,-1.039216035096497,-0.16694823108742618,0.3279859399533145,-2.2924208793997503,1.888732787263673,3.940947708871769,-1.2269115545972917,-0.4512388987632404,-0.6956280065947686,False,c1,2,"The beta cluster rely on the super project mediawiki/extensions.git to deploy extensions automatically. Sometime an extension would be misconfigured, a recent example is VisualEditor which got stuck for a few weeks to an old version (bug 49846).
It would be nice to run a SQL query daily that would mail gerritadmin about any misconfiguration.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",51906,-2,Medium,False
-8.109784169521578,6.243273119947716,3.8951465786298947,6.754745082292138,2.191248988695135,6.078525909669642,1.1373526919783217,0.18964490077087853,-1.4464649377021923,0.06876784983030859,-0.45651666367920773,-0.7635517583442673,-0.5632532239815919,-0.1961734464879381,-0.6282104318078892,-0.26230417368323156,4.022163501662784,-2.9945015276709572,False,c1,2,"In edits like https://fr.wikipedia.org/w/index.php?diff=94100781 , the whitespaces between the equal sign of a template parameter and the value of that parameter are removed. This causes confusing diffs since the user didn't make that change.
--------------------------
**Version**: unspecified
**Severity**: normal",51901,-2,Medium,True
-4.453913650717813,-2.5214814970009023,-5.571881953854174,-2.04628318831218,-3.2627848023063235,5.5636903461739475,-1.3311823252513655,2.2799473904296623,-0.8627708324900677,-0.01651163897340524,1.5415771338453,2.2935597271805968,-0.48450198612979367,-0.7122448275644961,0.1653596450255952,0.6465470849720727,1.537725828291954,0.8922812165529133,False,c1,2,"1. Go to [[Ahab]] and edit in VE
2. Select the succession box at the bottom and edit with transclusion editor
3. Observe that ""content"" sections are present that look blank, but on closer inspection, contain only a newline
Some templates (like succession boxes) unfortunately need to be on separate lines in the wikitext :( But the current UI for this is non-obvious and could be made better.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51866,-2,Medium,False
-4.3699539227232815,0.9226816960317681,0.552997648334479,0.4671105700989999,-3.3511921091742005,-0.855963294779834,-1.2003945272816159,0.439489339602281,-3.798327249314589,-3.6935813953918717,0.33415435150571815,-1.7262194854405446,-2.5148084495622127,1.5622457767665416,1.768599674283342,2.2419577783447435,-0.4037798630294309,-0.20022063994510542,True,c1,2,"Follow-on from bug 49596.
The insertion of a new image adds link=… whether or not it's been actively set away from the default.
Thus (in the example in bug 49596 comment 0) we get:
[[File:CV.03326.jpg|link=https://commons.wikimedia.org/wiki/File:CV.03326.jpg|right|framed|424x275px]]
… instead of:
[[File:CV.03326.jpg|right|framed|424x275px]]
… which is bad in terms of wikitext-user utility.
--------------------------
**Version**: unspecified
**Severity**: minor",51844,-2,Medium,False
-1.0636930971288128,-1.1859213478063477,0.9027527221694314,5.5601036619437565,0.318744911662166,-0.30113946237444167,-0.6626455849546709,-0.5647699736921017,2.044926971095671,2.2104979044738355,-0.2916295113398206,1.4648793428277969,0.3490460558568249,-0.8157292047115137,-0.5553151111943988,-0.03286490304660694,-1.9749723462151922,-0.7230626956469972,True,c1,2,"Template overall:
* Template panel should have a link to the template's definition page (if it's a real template)
* Template panel should have a link to the relevant MW Manual page (if it's a parser function)
Parameters:
* Label for parameter should use the ""label"" from TemplateData, not the wt name
* Label panel should use the ""description"" from TemplateData above the content box
* Label panel should indicate if a parameter is ""mandatory"" from TemplateData
* Label panel should show the ""default"" from TemplateData
* Label panel should indicate if a parameter is ""deprecated"" from TemplateData
Adding parameters:
* Template panel should show available unused parameters and way to add them
* Template panel should highlight available unused parameters that are mandatory
* Template panel should highlight available unused parameters that are in sets
* Insertion of a template with TemplateData should auto-insert the mandatory parameters
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52576",51833,-2,Medium,True
-6.842561082376694,7.614012512674993,0.8408062422569031,5.243739826828606,0.30402415873544686,6.465292572094539,0.7139887761820072,0.11377048552762964,-2.4034824400799364,-0.597228108545087,0.8596786924700774,-1.6631910236200211,1.96838816901885,-4.913162026653614,4.246686096750662,0.7740783946149374,1.7411335774529448,-2.269199235492489,False,c1,2,"In these two edits made with VisualEditor, the infobox was duplicated on save and the duplicate was actually subst'd into the infobox's table:
https://fr.wikipedia.org/w/index.php?diff=94112508
https://fr.wikipedia.org/w/index.php?diff=94163787
The behavior seems to be inconsistent since in the first case, the duplicate was inserted right after the infobox, and in the second case, it was inserted after the first paragraph
--------------------------
**Version**: unspecified
**Severity**: major",51823,-2,Medium,True
-1.13684281979388,0.8577535259614137,4.418981360537078,3.0525972034765028,-0.22466309010195357,1.549838591716832,0.03599075114531036,0.40018345198870575,-0.5306779860422972,1.4090159454484947,1.747711561530744,-0.2406729635715842,-0.4039491828921218,-1.3500319399821112,-0.5093370207901344,0.7920240618739021,-0.14241487939429764,2.668596019430823,False,c1,2,"Hidden templates, like Template:Use British English, are displaying as carriage returns. These are pretty easy to mistakenly identify as typos or errors and delete. We need a better way of displaying those within the VE, or (as a long-term goal) a better way of surfacing metadata, a la the ""page settings"" page.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49603
https://bugzilla.wikimedia.org/show_bug.cgi?id=53659",51806,-2,Medium,False
-7.487998652034795,-0.7399420077276524,-4.849963801857093,-8.26288636161753,-1.037220227222408,-2.6664734579194085,4.756805834142516,-1.8415621849709671,-1.2576071181516444,-2.601114829250229,-2.4811392235544756,-0.6235900587044034,-3.128163230524554,1.5296119139883384,0.6352293215360758,-0.5848485020056651,-1.2832415479130415,0.7318661357885612,False,c1,2,"Especially important for newly inserted ones, as at the moment we have no idea what they are going to be so we just assume inline.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51784,-2,Medium,False
-4.971295261884837,-0.1615234332163542,-4.115083947748223,-6.177395032752994,-0.663236153568477,0.4656694146793048,3.8420489058571023,-1.9903750034240986,-1.8636300410277826,0.35541781179661225,-0.525118822881895,-1.3518515135349065,-2.0697784589899344,2.373077541949838,-1.383403248144134,1.6790654785616836,0.464809641367371,0.5651596311630558,True,c1,2,"Currently in the template dialog when you insert a new template (or other transclusion) it doesn't look up TemplateData for said template (but re-uses if available). It should.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51778,-2,Medium,True
9.171403436170403,-13.858078247247649,-2.0332930515540877,-3.932898738445399,-0.5475775938479867,3.7480456714917,0.35459523196543685,0.5540155044992019,2.0252751170793397,0.9143610379079661,1.5897360719579932,0.35217073792045483,1.9721045691765609,-1.309499316099029,-2.1129343062129804,0.24970749241493823,-0.6897635361980718,-1.318241024216383,False,c1,2,"Screenshot
See associated screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11694}",51767,-2,Medium,True
-1.360794330073411,6.478311607179876,-0.3268213398596931,-3.0761512963215543,-2.1410365897556947,3.7393003979097186,0.6990455242965599,-0.09116612591492335,2.3235181335108015,0.6455560581095101,1.6223793909816169,-1.9767230846925397,0.837070842747055,-0.1729218655447271,0.21139607955785777,0.8144068492236924,-0.14602618274329116,-0.45716298794517396,False,c1,2,"In the investigation of most round-tripping bugs we need to figure out if VE modified the DOM in unexpected ways or Parsoid had issues in handling an unmodified DOM.
We need an easy way to display both the original HTML string retrieved by VE and a serialization of the modified HTML the VE sends out, possibly popped up in two textareas on some keybinding for easy copying.
This would at least allow basic manual debugging.
Optionally, as a time saver, it would be nice if you could also output a DOM diff that makes it easy to spot DOM differences. You could probably base this on the Parsoid DOMDiff module. This DOM diff can also be used in sanity checks to automatically detect VE round-trip issues.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51761,-2,Medium,
-2.1178477383505903,-9.900590930740998,-4.08364610716146,-6.3337747271597244,-0.06787805264969238,2.2110197950166732,4.049168531749149,-1.8287923061940297,-1.2722455185167578,-1.2758768166568872,-1.6944898087962317,-1.3765635565936556,-2.5504795703831853,1.8588268746018457,-0.9593485769062067,-0.8947009638566006,0.6904989066980771,-0.7313859096619904,False,c1,2,"To something which describes their function, not form.
--------------------------
**Version**: unspecified
**Severity**: normal",51754,-2,Medium,False
-3.0974526593047367,-3.354309872914035,-3.0335244941668567,-4.528832950074849,6.008748298186253,-6.410556153618901,2.9200211808942873,-2.281853172329283,-0.6340015571017028,-0.8813335386960275,-0.39052825727824736,1.700080941185041,-0.3732018755471955,-0.5012386541880529,-0.853696598031096,0.16353016329877712,0.35383323110279385,1.4070113951507206,True,c1,2,"You really should be able to. I mean, the cursor pointer triggers and everything. Tsk.
(Actually, it's ignoring all clicks that aren't on the buttons, or so it seems.)
--------------------------
**Version**: unspecified
**Severity**: minor",51725,-2,Medium,True
13.53617848941514,-5.686012556401209,2.475508459702258,-2.8975753045785217,-1.2700919971783493,3.829082063742705,-0.9648786573549346,-0.26404465334382937,0.7876105723006297,-0.10136166557719317,0.39783727213607056,-1.0566456683518188,1.7101934319258407,-2.5249141571684306,-1.6007478739571437,1.6049216628801257,0.7738964886313042,-0.3831189049947219,False,c1,2,"Screenshot
See associated screenshot, from the page https://en.wikipedia.org/wiki/Henkle_v._Gregory
Reproduced in Chrome, Safari and Firefox.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11483}",51682,-2,Medium,True
-1.9886131996404806,-8.489844580187343,-1.8150356029080648,1.645059495008066,-0.025079319458648275,-1.0891127252831705,-3.6221340303390814,-0.22525652190323564,-1.7704881523359497,-3.1028277645077553,3.378902598783568,1.9009386057829707,-0.9624842559057223,-0.424859744447728,-0.30230740554928826,-0.6617148859163531,-0.8980869157664778,0.22272901962491765,False,c1,2,"Deleting leading newline destroys [[File:....]]
Steps to reproduce:
1. Open a page with [[File:...]] as first line
2. VE adds a leading newline into the edit window
3. Delete this leading newline because for experienced editor it looks superfluous
4. Save
Result: [[File:...]] syntax is destroyed, only the caption is left.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174494&oldid=174493",51645,-3,Medium,False
2.6637518968125673,3.96756242514763,-2.5812955200326257,6.682990525197488,2.876828590193265,-2.9123603062578356,2.2668909998046685,5.127216022663628,-2.7306913594145845,0.0869171632443475,1.6697178451217876,2.1548555450564457,-1.7741592856466228,-0.5319298437248952,-0.9418021967953862,0.2715575131635801,1.7998493486145006,-3.6996347175977915,False,c1,2,"In VE, new users may use tutorials/wizards which use [[ https://en.wikinews.org/wiki/Help:Creating_and_using_editintro_and_preload_templates | editintro/preload ]] features, which aren't supported by the visual editor yet.
",51622,-3,Medium,False
-2.145331750190757,-0.7511445454620134,4.9030232810721195,4.156633089137794,6.807279415645029,5.902326628627965,-5.322868148339244,-0.4737089125014674,2.6754004401216926,1.8268332749745753,1.2609434972015383,0.09356493755808115,-1.3957444141973934,1.261118731883812,-1.3384873210684685,1.4865596053878218,-0.19018021686245068,-0.09220017844455408,False,c1,2,"To reproduce:
1. Open a page with several sections.
2. Scroll to the second section and press the ""edit"" link near the heading. The Visual Editor opens. Make a change in the text and save the edit.
3. Press the same ""edit"" link again.
Observed: The source editor opens.
Expected: The visual editor opens.
--------------------------
**Version**: unspecified
**Severity**: minor",51620,-3,Medium,True
0.43603869252066385,-1.6394308006766156,3.546665227924379,4.21222971271661,-1.1809545881086447,0.35197207901890404,-5.599782509982296,0.37708327235281647,-0.6679472931141828,-1.2003019005739453,1.9208674609684029,0.929362023234922,-2.735406467372832,-1.2323075351502841,0.980743397632148,-0.9639422165478024,-0.25341454012696785,-1.2458685767986197,False,c1,2,"As indicated on
[[mw:Thread:VisualEditor/Feedback/source code?]]
the page
https://www.mediawiki.org/wiki/VisualEditor/Feedback
which was protected recently has no ""View source"" link to see the content of the header. There should be one, pointing to
https://www.mediawiki.org/wiki/VisualEditor/Feedback?action=edit
--------------------------
**Version**: unspecified
**Severity**: normal",51618,-3,Medium,True
-2.2001981474131185,1.3046609184362765,2.7323702416592965,2.875256031738754,2.184004679418259,5.6705887170196085,0.3624399260238578,-0.8388229216913818,-1.124182768806981,2.70146878944019,-1.086782266069203,0.11824893021185234,-1.010881287397548,-0.5781448931320448,1.4507153728288777,0.4116401486176872,-0.3024118081603948,0.9666860140781546,False,c1,2,"In VE, click the ""Reference"" toolbar icon. According to the toolbar icons in the ""Content"" section, it is possible to insert lists, headings and images within the text of a reference.
This is a nonsensical capability. The only required formatting here is bold, italic and wikilink, if that.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52646",51617,-3,Medium,
0.47117025411380054,-1.5115903545988374,4.006549464965897,-3.1480699844613964,-2.31058786085481,-2.6455218137576093,0.40423566070644856,0.24144942361805044,1.8500936896973312,-0.9253821446469486,-1.7140501425980024,0.7760156456347984,0.21900508953282838,1.566866014632609,0.37304947134029476,-0.9362892249106649,1.4440378255952828,-1.4594379985080508,True,c1,2,"This is to run from 19 June (end on with the Notifications split test, so we don't much their data up).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/70737
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49727",51604,-3,Medium,True
-2.6772734295630087,2.9007645769018744,-2.922841270724522,-7.607450681401031,-0.8373941790341904,-4.7302926658935265,-0.5248119855361075,-2.4525703732670694,4.068199529103984,0.41643378244824714,2.2686380772770005,0.6280634702029915,-0.6218443090438299,-0.09975569991120992,0.4083849893451772,1.0997290123497363,0.28699500382706056,-1.4490041896747945,True,c1,2,"The VisualEditor edit tag (Tag: VisualEditor) should show on diffs, too. This will probably require a core change. However, I'm filing it here, both so you're aware of it, and because it might need to be configurable (it might be we don't want all tags, such as AbuseFilter, etc. to show on diffs).
--------------------------
**Version**: unspecified
**Severity**: minor",51602,-3,Medium,True
23.295556616484504,-4.288150033876368,6.1407666865854935,-1.0235643460613433,0.5203879150884825,-1.813497406460479,1.3310305110819982,2.040275482733187,2.161768716691621,-1.3260682253069183,-2.202388363336582,-1.4496761870773152,-1.314017611319385,-0.5610155018635368,-0.984401861831282,-0.7232649787516685,-0.49054086858809076,0.4923806125765673,False,c1,2,"ULS IME not working with Visual Editor fields
--------------------------
**Version**: master
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50722
https://bugzilla.wikimedia.org/show_bug.cgi?id=53700
https://bugzilla.wikimedia.org/show_bug.cgi?id=53701
https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/3493",51569,-3,Medium,False
2.2633516755092216,1.2085429316103404,-9.307931658629983,-7.216559480320927,-6.970345118907662,-0.15197435006326732,-5.298782565496163,-0.051444838691978856,11.2018878436128,-1.8779531092095625,0.6764589082437578,5.361272022095519,1.638335990155022,2.019047320193936,3.1016866772614824,0.3932648759405921,0.8524355536666424,1.6218146528486426,True,c1,2,"Need to review and get working so we can ask Parsoid to re-enable these (stop them being wrapped as <mw:Placeholder>s) - bug 47403 comment 3.
--------------------------
**Version**: unspecified
**Severity**: minor",51564,-3,Medium,
5.205226306498837,4.837488176149424,-1.3481634713934678,-3.6291416358683786,-3.109835400039394,0.5910996524826098,-0.06374826719801074,-4.4055742374236955,3.3524771279922785,0.35380231317892985,1.0803732398957702,1.4897581770997517,1.1494612664493569,-0.960366897071828,-2.2245611512058296,-3.3693364771139844,-0.47531497223528374,2.710838600907004,False,c1,2,"I'm thinking something like:
start loading VE
done loading VE UI
start rendering VE content
done rendering VE content
done loading VE
These would make it easier for other scripts to hook into what is going on. We could use it for instance to add the BLP/disambig editnotice to the actual edit notices on the english wikipedia. https://en.wikipedia.org/wiki/Wikipedia:Editnotice#Edit_intros
--------------------------
**Version**: unspecified
**Severity**: enhancement",51552,-3,Medium,
-2.095696741357342,-0.32196018461342923,-1.0749056098039187,1.6676393972200985,-5.277467168754171,3.9478392462981455,-1.9214622257344756,-1.0975945466083226,-1.2388272187451133,-2.7600123919337394,0.8610489091158091,-2.1356474389322484,-0.811127519467437,2.1762718727438877,2.2418587371599736,1.5958192706297976,0.25986134006665607,-0.7947182402261044,False,c1,2,"1. Copy some plain text
2. Make a selection in the document up to the end of it (e.g. select all)
3. Paste
4. Exception time!
Problem is in ve.dm.Surface line 376:
rightAnnotations = dataModelData.getAnnotationsFromOffset( right );
with right = -1 (out of bounds)
--------------------------
**Version**: unspecified
**Severity**: normal",51551,-3,Medium,True
-0.03454381969366871,-4.2377753367998725,5.008279364244846,0.8891743262382097,3.4110738404513916,1.8439404544468478,-1.6211944273508454,-1.8372484451041209,7.191149386417812,-1.8823481275007317,-1.6902781907130429,0.25697497941133807,-1.1628151958928905,1.0942651505715917,-0.1858184463926582,-0.5478773635115306,-1.9933101025749838,-0.2583975417871991,False,c1,2,"It should allow the editor to see the page content while specifying a reference.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49969
https://bugzilla.wikimedia.org/show_bug.cgi?id=51755",51549,-3,Medium,False
-4.011298279225946,1.310442314680822,-5.420971803366648,-0.9597437161951624,-0.8024113264631061,2.062393977653045,-0.5501539118256691,0.4512500817918882,-3.649865441532566,-2.392030370641992,0.0737473910347175,0.19357565800470966,0.7198554514038138,0.9829578884519998,0.5410689337006076,-0.3077116234080496,-0.3950459227744614,-1.5508015456246516,False,c1,2,"Right now the z-index for .ve-ui-surface-overlay is set to 1000, which is way higher than pretty much anything else in MediaWiki. This makes it float above lots of things it shouldn't float above, like the header drop-down menu in the visual editor, the Echo notifications dropdown, etc. The z-index for the Echo notifications dropdown is 100 (so that it is higher than the close buttons in SiteNotices which are 99).
--------------------------
**Version**: unspecified
**Severity**: enhancement",51514,-3,Medium,False
-4.410339547197668,-3.5976118703579374,-3.981314143621624,-0.6181681319374366,1.6275447629186277,1.1400491186926074,-1.5574897235735676,-1.2584136043303848,-1.2491665905023694,-0.4722474664636147,-1.7010374813226332,0.45567043500762927,0.8219744768325077,-1.6692588484937483,-1.6652357330077443,-0.7806756781856989,-1.3716998546868535,-0.8544196804439854,False,c1,2,"Screenshot
An example is https://www.mediawiki.org/wiki/Template:Extension_code_in_wiki which can be seen at https://www.mediawiki.org/wiki/Extension:Syntax_Highlighting
If opened in the inspector menu it displays pretty much nothing (screenshot attached) because there aren't any modifiable parameters. It comes off looking like it broke ;p.
It would be good if, instead of displaying the title, the inspector menu could display a slug that reads something like ""This template has no editable elements"".
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11046}",51491,-3,Medium,True
-4.044540936623464,-0.12508473769604223,0.7296309649662973,8.746348790253485,-0.570658877416042,-1.5688443027741963,-0.2244483870518934,-1.7448819517288099,1.002522988973462,-3.03126170674331,-0.9470824522507635,-0.6853096390313469,-0.7609050380843918,0.3617691916019963,0.6813875142721022,-1.4104543751976486,-0.2101709986559479,0.003003130545975452,False,c1,2,"When an editor tried to remove a heading, the following empty h3 tag seems to have been left behind: <h3 data-parsoid='{""dsr"":[4514,4534,3,3]}'></h3>
Serializes to ===<nowiki/>=== and the user complained about it.
From the bug report: /mng/bugs/en.2013-06-10T16:41:02.032Z-Lightning_(software) on parsoid.wmflabs.org
--------------------------
**Version**: unspecified
**Severity**: enhancement",51452,-3,Medium,False
-3.7989239489559545,-6.54391950123397,-2.6669353008560392,7.69483807679668,0.6157170065939475,-2.8040728366393175,4.481040079179931,1.1124898493724005,-2.1626379581239843,-1.5818071147378534,-2.0578033496455452,1.9480945628774327,-1.2831107497566867,-0.3905537505208656,-0.8675014913255126,-0.5802630827484229,-0.0023059276299657316,-2.21825957534616,False,c1,2,"modules/ve/test/index-phantomjs-tmp.html is not deleted if the tests fail.
--------------------------
**Version**: unspecified
**Severity**: trivial",51431,-3,Medium,True
-1.3071130190947902,1.0761234363619234,1.5389846794527102,-4.578162450343562,2.2369397833653353,3.058812833504909,0.8703122619784676,-1.3048963789442074,-2.0276133172710544,-1.1919939702414943,-0.6815704495802617,2.3944030748029155,-0.3444129117234702,-0.1329193020517776,-0.5752433386224309,0.9606850932613312,-0.5912737846325237,-0.8217374119781085,False,c1,2,"I think it is standard in in (all?) Wikipedias to add a newline before adding a new heading.
This is currently not done by the VisualEditor, see URL.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://de.wikipedia.org/w/index.php?title=Benutzer:Raymond/heading&diff=119444892&oldid=119444326",51429,-3,Medium,
-4.683045935728616,0.6280333738613351,6.23918075408465,3.322162649879373,-2.5786384578162895,0.2880168909530647,-2.732117257879409,1.582747104724667,0.324310031120309,-3.5338967462758006,-1.5848590022045002,-0.49937399473227995,0.6252176783239718,1.6959318967485242,1.2405036154781763,-0.06833381952759643,0.20510421684930247,0.19824383489262165,False,c1,2,"Steps to reproduce:
1. Go into a heading
2. Change heading level from 2 to 3 (i.e.)
Expected output: Only the number of = should change
Actual output: Number of = is changed correctly but the newline before the heading is moved under the heading now.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://de.wikipedia.org/w/index.php?title=Benutzer:Raymond/heading&diff=119444161&oldid=119444142",51428,-3,Medium,True
-1.5072546713999844,2.536374107624063,0.6156849046677877,-3.460474080106536,-6.3781278811026265,-0.7907255104732337,-0.23433333398468648,-3.1342216087841273,-7.082224132027473,6.081253226591166,-3.2809605545605187,0.8752617018678543,-1.4903124895242126,-0.03295889302297894,-0.5763348814260354,2.108181171274592,-3.1828924096511066,0.9578773128605269,True,c1,2,"Instead of ""Foo v"" you get ""Foo
v"" - dialog contents render before they're styled because the CSS is slow in coming in (per Roan).
--------------------------
**Version**: unspecified
**Severity**: normal",51420,-3,Medium,False
-6.405564547664232,5.318783611015821,-1.6415040251399837,1.234697702575101,-3.2237837376339025,1.7168733070904445,-0.26311031805607676,-0.909165465086074,0.22437724702413453,-0.2778942270876641,1.2117305038691488,-2.1973244255423516,-0.6105077531229144,-1.3993603283674751,-0.1527761864295174,-1.01795494961526,-0.6795002682802804,0.37439015031746004,False,c1,2,"Some perverse templates such as {{Largethumb}} return a string with several options separated by pipes (""thumb|<number>px""). In the PHP parser those pipes are then picked up by the link regexp, so result in the regular image options.
In our attribute handling we expand attributes separately, so can end up with strings like the above in a single attribute value. In [[:de:Portal:Thüringen]] for example that is the case for the href attribute, which then caused a crash after retrieving image properties.
We will likely need to handle expanded attributes containing a pipe properly by re-parsing their string representation. This will be difficult to map onto our current template-affected attribute handling.
--------------------------
**Version**: unspecified
**Severity**: normal",51400,-3,Medium,False
-6.51929557613955,-0.7804383334729703,-3.970015035661893,1.6421686885031348,1.0771169368236275,-0.8282961477689321,-0.1964992503150631,1.5910331950089018,-1.2779501520471226,-1.921631331558466,-1.0677719932612217,-0.7309023736153623,0.3846200687688852,-1.5957728731222112,-0.49297675916499006,-0.9959016185339267,1.9248668213774363,-0.03005419786798913,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Mavericks_(location)&diff=559262706&oldid=559261658
There are a few issues here:
* the diff presented to the user prior to save didn't include any of these extraneous changes (or I obviously wouldn't have saved the edit);
* there's <nowiki> markup being inserted throughout the page, breaking a number of links; and
* there's spacing normalization being done to template parameters, resulting in an even dirtier diff.
I'm not sure how these issues should be split out or if there are existing bug reports for all three of these issues.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&tagfilter=visualeditor",51394,-3,Medium,True
-13.191691000669726,20.53922829495236,4.276394300266414,2.710370997497151,-8.279686057078012,1.01212582947534,0.18132466709063788,-0.2142384760312035,1.000572663479904,-0.7003843603062023,-0.607355673803649,3.5500434324224335,-0.013755683074661462,-0.810069721321824,1.3653365951368333,-0.2986687189719739,-1.7263644062780927,-2.3194405945402883,False,c1,2,"There are a couple of ways to configure references to display differently:
http://www.mediawiki.org/wiki/Extension:Cite/Cite.php#Set_references_to_use_.5E_and_letters_like_Wikipedia
we should access these so the rendering in edit mode is consistent with the that in read mode.
",51346,-4,Medium,
19.146002568200124,-5.321810330874147,-3.821443675347016,1.8410330794872092,1.3769716121249125,-0.9355814309347681,-0.16035649314285472,-2.6660802913091435,0.567562413039924,-2.828789447221671,-2.9159606311803152,0.4590772953196416,-0.5574938164350822,-1.0923362205747917,-2.06105493149003,0.544558077904004,-0.29142164264449644,-0.405228218885499,False,c1,2,"The language committee and WMF Board have approved the creation of Wikipedia Tuvan.
Language code: tyv
Site URL: tyv.wikipedia.org
Project name: Википедия
Project namespace: Википедия
Project talk namespace: Википедия дугайында сүмелел
Project logo: http://commons.wikimedia.org/wiki/File:Wikipedia-logo-v2-tyv.png
Timezone: Asia/Krasnoyarsk
Language name: Тыва дыл
Enable uploads: yes
Thank you.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: //meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Tuvan",51328,-4,Medium,True
2.9935451295317246,-0.44318450263173936,-0.1723620948401159,-4.285767491072372,2.2192072735240234,-1.959699497761258,-1.980754123705121,-2.503472166997406,0.2567153647417124,-3.0746881459009217,0.46476099172571317,-1.7789176202723702,-1.4637759602133187,-1.8377424448571489,0.2748042513815774,0.19408175846071796,-0.26233034406827715,-1.0992869786285762,False,c1,2,"**Author:** `the.anonymouse.wikimedia`
**Description:**
I created a wikilink [https://en.wikipedia.org/w/index.php?title=User:The_Anonymouse/sandbox2&diff=558776770&oldid=548109401] as [[United_States]]. I then tried to use VisualEditor to change the underscore to a space ([[United States]]), but it said that my edit was ignored due to no changes. However, if I actually click the link button and click the United States link suggestion, it works as expected. That is how I eventually accomplished the edit with VisualEditor [https://en.wikipedia.org/w/index.php?title=User:The_Anonymouse/sandbox2&diff=558777422&oldid=558776770].
--------------------------
**Version**: unspecified
**Severity**: trivial
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42140",51310,-4,Medium,False
-4.302785346441992,-1.4557617736758939,2.806785446117509,-0.8855472258468533,3.95189837029864,0.5080905225886423,0.8579006335003596,-3.8775472474545474,-1.5374020836223188,-1.6411699510068263,-0.5710599992104068,1.443770937103077,-0.28783476828478793,-0.6509632034839834,-0.8027146611099445,1.5357711052498433,-0.03324328046454017,-0.2169516560255662,False,c1,2,"exemple in video
When I add a picture and it gets behind the toolbar,
This prevents the toolbar from be clicked
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11568}",51308,-4,Medium,True
7.595849533857114,-11.082278684872914,-0.7125715315702319,-6.289973350912578,-5.208195455366484,7.593948409893398,1.747457052613922,-0.5507672432651514,-0.8181600314529823,0.5201025529498242,-0.01928823414687386,-1.8286178622287208,-0.1776393255300368,-0.364367366417345,-0.9505308980575187,-0.8319733824347741,0.4860089402740271,-0.3547338086153784,True,c1,2,"Per Ed.
--------------------------
**Version**: unspecified
**Severity**: normal",51257,-4,Medium,True
0.3768170755625584,-1.6047496825732743,1.7008383281959887,3.4482213775549786,1.5303641495692966,1.7417705119565265,-0.40044905359329785,-2.758782400371915,-1.253103130702986,3.860966841891017,-0.09766728705643812,-1.1735261446971792,0.4299945748195477,-0.5363651371273628,-1.5293277973267285,0.4583634014810256,-0.993502396422479,-0.4339897484490596,False,c1,1,"Arrow shown in top-right, under search bar
The Up-Arrow icon, at the top-right of the ""Review your changes"" dialog (which cancels the review window) needs a tooltip.
I suggest: ""Cancel review, go back to current edit"" or similar.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F11244}",51147,-4,Medium,False
-1.5389767814756978,2.7237526801327476,-3.5053040762321377,-4.0010105273082015,-0.17010188897946588,-0.0809868726401719,-0.2184482023883474,5.012248386487672,-0.7696598587682455,-1.2266644436448466,-1.4815134741985703,0.9451675451279662,0.6345276794780186,-0.29061498448981826,-0.5908960417580769,-0.3635227145250731,0.5658931617328122,-1.4893735180428382,True,c1,1,"Since MediaWiki allows images that are clearly separated out, we should see if we can use `<figure>` and `<figcaption>`. These tags are intended for ""//some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.//""
This would particularly make sense for thumb and frame where a caption is already shown. However, figure can also be used without figcaption, which should simplify implementation.
The main concern is backwards-compatibility with browsers that don't know about these tags. They're new to HTML5 (which is now always on in MediaWiki), but
1. Older IE will not be able to style these elements from CSS
2. Older IE will not be able to select these elements from JavaScript. This can be worked around by calling `createElement(tagName)` once for each of the relevant tag names.
For issue number 2, I think jQuery's internal `createSafeFragment` already takes care of old IE. So only the styling issue remains.
--------------------------
See also: {T25932}",51097,-4,Medium,False
-10.944244880482387,10.8453925797637,4.595539106529653,4.996699973144541,3.5145892808708123,0.9217169138433479,-0.8069805681158959,3.952034495006579,-0.3856749218711633,-2.7746558987359626,-1.477751096090994,-2.199799906271492,-2.158993667036878,1.253447300249527,0.8302363971637998,-0.6062703896586691,1.2986713207652565,-2.3488328432358174,False,c1,1,"Currently a reference list (<references /> in wikitext) complete redraws every time an InternalItemNode is touched by a transaction. This is inefficient because:
* Reference lists can be grouped, so a change to one InternalItemNode may not affect that reference list at all.
* Changes to IternalItemNodes shouldn't change the ordering of the list, or any items not touched by the transaction, so we only need to selectively update the items in the list which have changed.",51092,-4,Medium,
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",51089,-4,Medium,True
3.6620564874744814,-2.0083367538911467,4.6309070799196945,-1.0880600977185628,-0.690830888975347,-4.391551230935782,2.222120569966614,2.964650878381522,2.5007561471928055,0.2110279885050259,-1.08330807397151,-0.033107452231404544,-1.1879842468772148,2.1137597150197296,-2.205814498839834,1.6103752408951921,-0.577270393888978,-2.21855738281953,False,c1,1,"Even though the edit notices appear above text, they don't appear above overlays, e.g. block phantoms.
http://i.imgur.com/RAOdlIZ.png
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49361
https://bugzilla.wikimedia.org/show_bug.cgi?id=50096
https://bugzilla.wikimedia.org/show_bug.cgi?id=50545",51059,-5,Medium,True
9.152559885248245,-2.0639627386371053,-3.8408055779176884,-2.8678145215194117,1.1460962963069203,0.31466116667620914,-2.709498789414202,-0.7821198232981111,-1.1358476312981924,-0.6755123226458819,1.7266277376587893,-1.109094406412906,-1.3261599545801444,-1.9402705064239956,0.030144506648769998,0.4802637585093647,0.09157660834224268,-1.9160960456937801,True,c1,1,"I edited https://en.wikipedia.org/w/index.php?title=Eagle_Lake_%28Florida%29&oldid=557775556 which contained a piped link:
[[Eagle Lake, Florida|Eagle Lake]]
I used VisualEditor to change the anchor text to Eagle Lake, Florida. That means piping is no longer necessary. However, on the review changes screen, it showed:
'''Eagle Lake''' is an elongated lake in shape located in the northern portion of [[Eagle Lake, Florida|Eagle Lake, Florida]].
(irrelevant parts after omitted).
It should just be:
[[Eagle Lake, Florida]]
--------------------------
**Version**: unspecified
**Severity**: normal",51034,-5,Medium,True
0.5790153308725956,-3.273854683097616,4.365405483873779,1.3073028147130756,5.561580340888607,-0.7463623217370984,-3.284217960715795,3.955753747262328,3.789043981453288,2.8629527701891275,-2.752928246800958,2.0655485037081043,-0.7071625446742233,-0.9174667127455991,1.8851311808653808,-0.532334186712331,-5.081338235382821,0.8663054151760925,False,c1,1,"When attempting to move a page where VisualEditor is enabled (take https://www.mediawiki.org/wiki/Special:MovePage/VisualEditor:Sandbox for an example), the tab ""Create source"" should be an ""Edit source"" tab instead.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66885",51000,-5,Medium,False
-7.06511423290104,2.9150138717570755,7.73065391556786,5.246890369887323,-2.4625761228086924,3.6356879663175787,3.588717834217456,1.199813860353672,-2.198714432249768,-0.1667396018312166,-0.5159167134820448,-3.0238381077747007,-0.9235017393304776,-0.26536024936064706,-0.4191333247871665,-3.173495030450351,-0.3207513737896164,-0.2967115059334946,False,c1,1,"On http://www.mediawiki.org/wiki/VisualEditor:Test when clicking on the drop down menu for styles, the title of the page is still visible
http://i.imgur.com/O3OvK3w.png
--------------------------
**Version**: unspecified
**Severity**: normal",50993,-5,Medium,True
2.4150717129737713,-8.922385496314677,2.4776369283516324,2.5887440836144213,-5.322145475460065,0.1269126682396413,1.3210231296022608,-2.263043977461995,0.30500726276702617,-2.438716983859602,-3.4832673387314226,-0.8740082451860428,-1.4014558833361264,-0.8821066844149348,-1.293428156129675,-2.491880046611314,-0.6882164462269347,0.8834285210819919,False,c1,1,"Screenshot while editing template with wikitext-generated target
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F11029}",50974,-5,Medium,False
5.555345499963737,-2.1085030481256215,0.41084306023611816,-1.434086925108733,-0.2048223577607402,1.1774696163572578,-4.6542071079321765,2.2569846413999484,-2.600339561273776,-2.3541026397718974,3.1935577174507803,1.9750450695834683,3.4269285740431905,2.320245427294184,1.0028240656097358,-0.38356620113118023,0.9398383883681876,0.242802530888915,False,c1,1,"Problem 1:
1. Open [[User:Ssastry]]
2. Select Paragraph 3 completely.
3. Ctrl-X
4. Move to beginning of Paragraph 2. Hit Enter.
5. Ctrl-V on empty line
The paragraph gets pasted on the same line as Paragraph 3.
Problem 2:
Steps 1-3 and 5. are identical. Step 4 is different:
4. Move to end of Paragraph 1, hit enter key,
The paragraph gets pasted *before* paragraph 1. Additionally, on review-and-save, paragraph 1 is lost. This is not a Parsoid issue -- the edited HTML is missing the paragraph.
This problem seems specific to Firefox. Cannot reproduce on Chrome.
--------------------------
**Version**: unspecified
**Severity**: normal",50960,-5,Medium,True
0.12290447290083284,-13.795569166845134,-3.3231178890527016,7.2016089706829245,-2.949182274750601,-2.409293018309068,-0.731407257098307,-1.2504726203523735,3.382069763231133,-3.2542919924020426,1.323474326908498,1.338581334720623,-5.9684354632257515,0.9467160334313958,1.0285587548553545,-0.8291474347791878,-0.10778229529999539,0.22223325040292496,False,c1,1,"tx push
tx push
tx push
tx push
--------------------------
**Version**: unspecified
**Severity**: enhancement",50913,-5,Medium,False
-7.349635593680711,5.665914942010048,2.2870843228853666,2.5451073017566137,0.5597245771783632,-1.5269821732732372,0.25807375136097477,1.6021615181877342,1.8213257594839807,-1.324093736325778,-0.05477463066838428,1.0982610095339231,0.13103965254369676,-0.24340071172791689,-0.0052609912627943345,-0.6368619111571016,-1.8318677113492454,0.17706714126321166,False,c1,1,"Image patch (https://gerrit.wikimedia.org/r/#/c/57817/) is missing error handling when the mw API is queried to get information about an image.
Two kind of errors that handleResponse in LinkHandler.js has to deal with:
(1) API error: Given that ApiRequest retries, an api error is an indication that the api may be temporarily down or that something else is wrong. So, rather than continue, it is better to abort processing and return an error code to the clients so they can handle it however they want (ex: ve might tell the user that the page cannot be edited right now because of api/server issues). This will require calling the error callback found in env.
(2) Image missing: If the api comes back and tells us that the image is missing, we should handle this similar to how the PHP parser does it for missing images.
- Maybe link to a special page/url that will let VE present an upload handler (check with VE folks as to what this url could be. PHP parser behavior can be found by editing a page on wikipedia sandbox with a non-existent image)
- Dont add a thumb.
- Add a special rdf type on the image/wrapper tag: mw:Image/Missing maybe?
EDIT: These properties should apply to missing templates as well.
--------------------------
**Version**: unspecified
**Severity**: normal",50900,-5,Medium,False
10.33819519583824,-11.758421205680682,6.414482468577038,1.122622645887652,0.4836240146739246,-2.136078389798616,0.3886859250006367,0.26778056359290814,1.8699897766178062,-0.8537558985285751,-0.6738633995214074,-0.02817357835436063,0.7685590761250491,-1.739720483460815,-1.6716048342189986,0.21361328556791534,-0.7952194795143448,-0.9696759018091874,False,c1,1,"screenshot
Example: https://www.mediawiki.org/wiki/Communication
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50284
**Attached**: {F10855}",50891,-5,Medium,False
-7.965649401374144,-0.7244026790439229,-2.9489390441292276,-2.209350719580806,-0.7565799321903653,4.395496827631041,2.3191786042659173,0.4198136549633692,2.0806045203212493,-0.36710221904612617,-0.4840780603046664,-0.83414083846311,-1.6707266312127045,2.478440301096893,-0.9382128125897138,2.1028824151218206,1.3122224265960358,2.681463282075695,False,c1,1,"This may introduce a really large number of scopes and have undesirable performance effects, but we need to come up with a solution nonetheless.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50885,-5,Medium,False
-5.469860530443141,3.769439640519632,-1.801231885607045,-3.5564448553142007,-3.8960023480975554,7.996471661026759,3.5680554003760365,1.1341095087255728,-0.8774126378412487,3.3098339116583038,4.16966137966015,0.9078604190757835,1.3723302724147204,0.0031052489920586623,-0.6464718659244388,0.9699012297799748,-0.3564357518831305,0.830192238751619,False,c1,1,"If wikitext contains several empty lines in a row, hovering over those lines in the VisualEditor will present them as uneditable elements. Since the VisualEditor is perfectly able to create and remove empty lines, this seems unnecessary.
--------------------------
**Version**: unspecified
**Severity**: normal",50844,-6,Medium,True
5.078253919780526,-2.3517704482280717,0.694369504798388,-0.22987700081138518,2.7116857533657774,4.1975451594137025,-6.687068283017078,1.371215948429025,-0.21850666824212023,-1.6146187192248664,1.308517473869872,-2.054189012070151,-4.094399505144822,-1.8932511865938393,2.055025335554089,0.7778743104618429,-0.09731877706750636,-1.9930381884089192,False,c1,1,"In this edit the user only made the ""die -> der"" change. In addition the </small> was removed by the VisualEditor.
http://de.wikipedia.org/w/index.php?title=Fu%C3%9Fball-Bremen-Liga_2012%2F13&diff=118880158&oldid=118873211
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
T52052
T52050",50830,-6,Medium,False
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",50829,-6,Medium,
-4.993815138362388,2.273960026008371,1.5160971271317756,2.0309801201456548,3.9546672088282393,4.361984485186309,-2.505692577356009,3.4433608404372213,1.732032341668636,-0.6884378475694142,3.046041863382752,-2.3463297314910716,0.4019682673524514,0.9581645692948335,-2.1536804849078073,-1.3362594552400422,0.48274087423994994,1.0298050352204198,False,c1,1,"Steps to Reproduce:
1. Go to https://www.mediawiki.org/wiki/API:Alltransclusions
2. Insert a blank line after the first paragraph.
3. Use the Del key (not backspace) to delete that line.
Rather than deleting the line, the first keypress (sometimes) does nothing. And then the second keypress finally gets rid of the newline, but attempting to save the page shows a diff with the newline still added.
--------------------------
**Version**: unspecified
**Severity**: normal",50796,-6,Medium,True
-9.63701427396188,6.441446155681703,-0.7616684299284096,4.104593923867413,5.340267951261735,1.5252641063730994,0.7658652711917036,0.978258450865337,0.09392621287912478,-1.0483720219326296,0.4555625167175261,0.6735134866612358,0.7186111837056699,-0.050037815676609476,-0.6874276106200146,-0.2142605114918258,1.1318584732225185,1.4139072383428333,False,c1,1,"There are essentially two ways to create a link:
#1 You enter the link's text, select it, click the link button (or CTRL-K), and choose the link target.
#2 You click the link button first, enter the target and get out of the dialog, at which point the link text (identical to chosen link target) will be entered.
I'm not sure which method users prefer, but it's clear that both methods should work seamlessly. However, with the current setup both methods are problematic:
#1 Once the correct target has been picked (either by entering it, or by selecting from the list), it is not quite clear what the user should do next. Is the back arrow the right thing to do, or does that cancel the selection? Should I simply click outside of the dialog, or does that cancel? It turns out: if the target was selected from the list, both these actions are correct and do not cancel the choice, but if the link target was entered by hand (and not followed by Enter!), both actions do cancel the choice. The fastest way is to enter the link target and hit Enter twice. This is all fairly unintuitive.
#2 With this method, the user will often have to adjust the link's text afterwards, for instance in the case of plurals or if the target article is disambiguated with parentheses. But it is not clear to the user that adjusting the link text is safe and won't create a broken link; indeed the crucial distinction between link text and link target remains obscure. (Changing a singular to a plural is especially difficult since editing links at the end is not allowed.)
I have checked the workflow of entering links in LibreOffice, Gmail and Word; they are all basically the same as in the Visual Editor, with two major differences:
a) the dialog popup window has a clear OK button, and
b) the dialog popup window contains separate clearly labeled boxes for the link text and the link target.
I believe both of these changes make a lot of sense.
When entering the dialog from an existing link or from highlighted text, that text should automatically be entered into the link text's box, with a corresponding suggestion for the link target preselected, but both boxes should be editable independently. The link target box should have a list of further suggestions underneath. Once everything is OK, clicking the OK button or hitting Enter should create the link; clicking outside of the dialog box or hitting the back arrow should cancel the action.
There is another minor issue: right now, when hovering over an existing link, the link target is displayed in a popup; when clicking on the link, a separate link symbol popup occurs which does not show the link target. The meaning of that symbol is not clear; it turns out that clicking on it will open the dialog popup, allowing to change or remove the link. Gmail solves this issue as follows: hovering over a link will not display anything, but when clicking on a link, a tiny popup appears giving the link's target and options to change or remove the link. I find that completely self-explanatory.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50789,-6,Medium,False
1.937980730808706,0.19184947831306154,-1.1478132127480674,1.9108893165199965,-2.1316220930062353,-4.5043110111424625,0.82718326792331,1.5396541164042796,2.10927623263673,-0.16087661645340567,1.1067212927397914,1.4754410182277062,-0.4866826951187102,0.10653069976374763,-2.9271702282000343,1.8985620910174303,3.5534362329102533,2.424604535783775,False,c1,1,"User can enter html tags or provide tag attributes or attribute values that Parsoid (and downstream clients) treat specially.
Ex: #mwt3 for about-ids, or mw:Object/* for typeofs or <template> tags or any of the special attributes/types found on http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec
If Parsoid doesn't detect these and escape/handle them somehow, Parsoid will mislead clients like VisualEditor and/or incorrectly serialize them.
--------------------------
**Version**: unspecified
**Severity**: normal",50772,-6,Medium,
-2.5525312317438953,2.607235748643266,-0.12383536360415093,-1.0207359937131186,-1.1799536709927452,0.3647929318612564,-0.7527222370769726,-2.0303336267644836,-0.7609206027233276,0.1688259524868112,0.9394579833082388,-0.6002879101143281,0.8550052235743468,0.053756521043081484,-0.4773589862280039,0.19415341912658934,1.1376610499257465,0.9399371589674608,False,c1,1,"On my user page https://www.mediawiki.org/wiki/User:S_Page_%28WMF%29 and now on a test page https://www.mediawiki.org/wiki/User:S_Page_%28WMF%29/VE_bugs every time I try to add a new section VE goes haywire
1. Edit (with VE)
2. Click at start of first heading (""welcomecreation..."")
3. Press Enter, it prepends new heading (good)
4. Press up arrow to move up to this new blank heading.
5. Start typing the heading, e.g. press 'X'
6. That was wrong, so press Backspace (or left arrow)
Result:
The text of the heading underneath leaps above the new heading, joining text above it.
I can edit other parts of the document, but whenever I return to my new heading to add or backspace, the caret jumps elsewhere.
If I undo enough times, VE undoes to a state where the new header displays below the existing header. The document looks different to what it did before, but [Review and save] is grayed out.
I created a new document https://www.mediawiki.org/wiki/User:S_Page_%28WMF%29/VE_bugs and similar stuff happens in that.
This is in Firefox 21 on Ubuntu, and mediawiki.org's VE as of today.
--------------------------
**Version**: unspecified
**Severity**: minor",50735,-6,Medium,True
-5.9674212785485405,-0.6918655026661433,-2.552213102863199,8.61044525147159,-1.0233044373256244,-0.6844890735877267,-0.3864755479868167,-1.4232650821823611,-0.41694291410965945,2.9805888822373916,-1.1983099506042836,-0.20839939946078,0.27051766523833454,-0.3079595255719614,-0.6521627373954928,-0.1403029782452842,0.5990390428576442,0.7690053717661443,False,c1,1,"On wikis where certain ""topicons"" are moved out of the mw-content-text wrapper into the root of #content the VisualEditor toolbar shows a weird blank space.
The icons in question are invisible due to float overlap, but they do push down the toolbar and occupying space to the right of the ""Save and review"" button thus pushing it and the rest of ve-ui-toolbar-actions to the left.
To reproduce this situation, run the following one or more times:
$('#content').prepend(
'<div class=""mw-topicon"" style=""display: block; width: 20px; height: 20px; background: pink; float: right; margin-left: 3px;"">x</div>'
);
--------------------------
**Version**: unspecified
**Severity**: normal",50734,-6,Medium,True
-10.007014835227467,1.805134401748802,-3.188985921237853,0.7056222428163941,-1.0034129764566782,4.39417682168739,0.18363975541948552,-0.6733063272596653,-1.905813356119108,3.112430033247864,-2.005040678239215,2.032615455786936,-1.39325851848763,-0.21121343256146297,1.3563974984531644,4.914063388141395,-0.10386841674761738,1.1742062021828146,True,c1,1,"If you have some text with an annotation (e.g. bold, italics or a link) and copy in some text, the annotation is closed off, the text is insert as plain text, and then the annotation is restarted.
I think users will expect ""paste as current style"" over ""paste as plain text"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",50720,-6,Medium,False
-9.615364408882083,8.992589779260072,-1.6505004661150782,-2.3998468315437966,1.6112444155781493,2.32302579339835,1.9471406320275504,-1.6121758067140903,-2.356410520935029,-1.2352753803934302,-0.9294785923448363,0.5253151471416535,-1.1969411490724848,1.2988914364432924,-1.6509052301567029,1.3944579918772966,-0.21900669639573822,-0.4081998493904091,False,c1,1,"Whenever you're scrolled down in a document and close or re-open the Notices flyout, the user is brought back to the top of the page (instead of staying where they are, like any other toolbar button would).
The toolbar floats and follows the user as they view the document, it is expected that interacting with it does not change the scroll offset. Most buttons abide by this except for Notices.
--------------------------
**Version**: unspecified
**Severity**: minor",50681,-6,Medium,True
0.8715616331276412,1.5178996494096335,-3.713639596454705,-2.134307046105305,3.3686557563955724,0.7211936669653232,-1.0202164325624228,-0.5847037812900316,-2.0130134316977966,-0.9853392734616717,0.018003167524511365,1.131758406597058,0.09320853109159,-1.0237536947775352,-1.35032613286889,0.10068796451493167,1.5443912104508717,1.3346304551186015,False,c1,1,"The newsletter update states that Visual Editor is now functioning in the content namespaces at MW, which includes the extension: and manual: namespaces (and it does). That said, the default text for ""MediaWiki:Visualeditor-preference-enable"" just states user and main at that wiki. I am presuming that this is a WikimediaMessages update somewhere
As a temporary measure I have created [[mw:MediaWiki:Visualeditor-preference-enable]] that mentions the extra two namespace.
As a note the mention of {{MediaWiki:Visualeditor-extensionnamespacepagelink}} and {{MediaWiki:Visualeditor-manualnamespacepagelink}} failed, so I didn't link, and we will need to look to how these extra namespaces are going to be linked, and documented.
--------------------------
**Version**: unspecified
**Severity**: minor",50666,-6,Medium,True
0.8451753441050038,-0.33841746391135175,-4.943404630031335,-1.6613378299673998,1.0780490263284594,0.07942448791582435,-0.4992231500145907,-0.9655360292367072,-1.1849060628921295,-1.9465066228993861,1.4818559303084897,-1.073621139809004,-1.7943936757238506,-0.46793417607935783,-0.7310869078218838,-0.12237406905001791,-0.7939281370206845,-1.5368066762379204,False,c1,1,"{{foo}} -> Template:Foo
{{:foo}} -> foo
{{:user:Foo}} -> User:Krinkle
{{Template:foo}} -> Template:Foo
etc.
VisualEditor needs the name of the page that ends up being transcluded by the template invocation.
From conversation with Gabriel I gather that currently the entire tranclusion system (at least in production) is deferred to the PHP parser (including the invocation itself). Which means Parsoid is unable to determine it itself right now.
Gabriel suggested Parsoid will provide the name the best it can for simple cases that don't dynamically construct the page name (e.g. not something like:
{{ {{getTemplateName|x=foo}} | bar }}
).
--------------------------
**Version**: unspecified
**Severity**: normal",50663,-6,Medium,True
1.9835241639697236,0.7534468743060856,-2.4965486940217723,-1.205026470806475,-4.281109996556827,5.775252071474181,1.6414841287021815,2.24119516635661,1.0759429190643452,-1.6520545175841588,-3.1622397915797653,-4.667568272929899,-2.825411249191421,0.5068447918364178,0.4067589254159856,3.985917585400756,2.2475419114922426,2.1490587288973435,True,c1,1,"Toolbar in VE floats to position of last BranchNode but should instead just use the bottom of the document or something.
--------------------------
**Version**: unspecified
**Severity**: minor",50662,-6,Medium,True
-1.955077065301743,2.3308453691558277,-0.9960858171738884,-3.5447799118472094,-5.239365028839506,1.4912326664614446,3.5270688082700614,2.679110918634706,0.49064300694217067,-2.0194827921433514,-3.131289226387861,-3.774432580766174,-3.0493814921514595,0.9088807847401705,0.23037966192129122,-2.674643320699751,-0.08731971101026681,3.8391766697532343,False,c1,1,"Complete with its own sub-store and everything, for consumption by a subsurface.
Right now Trevor is committing crimes against humanity to make this work (converting to DOM then back to linmod again)
--------------------------
**Version**: unspecified
**Severity**: enhancement",50651,-6,Medium,False
-6.078397889356445,3.763670574548037,-1.4963404624985763,3.303277128973413,-0.02444540937150519,1.1023010207688226,-1.1999432745274303,1.3253997074606745,-1.0120207112023807,3.389017545412244,-0.6875729907509691,-1.1430942238058424,0.21331566936975577,0.5456920974061026,-0.4363474867810835,0.14516292289944302,0.05173319344910876,-0.06350577879701258,False,c1,1,"At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
ve.splitCharacters = function ( value ) {
return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
};
The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
--------------------------
**Version**: unspecified
**Severity**: normal",50630,-6,Medium,True
-3.6670896208772796,5.136763685605612,-1.9469148212107932,0.8733062169303645,5.284324921391388,1.52051108015211,2.0415775177819393,2.0905227541593434,-0.757930425414782,0.023013099109087776,-0.07003615363966009,3.66455858613668,-0.23617584460004437,0.44932278529097136,-1.297141462938014,-0.5626438318398846,2.702102226564876,-1.239450666870145,False,c1,1,"Toolserver has the local table toolserver.wiki on all databases that provides metadata about the wikis including the server the wiki's database is kept on:
```
| mysql> SELECT * FROM toolserver.wiki LIMIT 5;
| +----------------+------+------------+------------------+------+---------+-----------+--------------+--------------+---------------+--------+-------------+
| | dbname | lang | family | domain | size | is_meta | is_closed | is_multilang | is_sensitive | root_category | server | script_path |
| +----------------+------+------------+------------------+------+---------+-----------+--------------+--------------+---------------+--------+-------------+
| | aawikibooks_p | aa | wikibooks | NULL | 3 | 0 | 1 | 0 | 0 | NULL | 3 | /w/ |
| | aawiki_p | aa | wikipedia | NULL | 6 | 0 | 1 | 0 | 0 | NULL | 3 | /w/ |
| | aawiktionary_p | aa | wiktionary | NULL | 1 | 0 | 1 | 0 | 1 | NULL | 3 | /w/ |
| | abwiki_p | ab | wikipedia | ab.wikipedia.org | 807 | 0 | 0 | 0 | 0 | NULL | 3 | /w/ |
| | abwiktionary_p | ab | wiktionary | NULL | 0 | 0 | 1 | 0 | 1 | NULL | 3 | /w/ |
| +----------------+------+------------+------------------+------+---------+-----------+--------------+--------------+---------------+--------+-------------+
| 5 rows in set (0.00 sec)
| mysql>
```
Most of the information can probably be extracted from operations/mediawiki-config, but I don't know which sources there are authoritative.
See also: {T50625}",50626,-6,Medium,True
-4.054699685769539,5.506011175061854,2.298450263409837,3.476576264474608,2.1474524216764435,-0.08311524108014723,-0.294691221561342,0.8063116971722685,-1.1400238018258484,-0.547563030950398,-0.2499156270528009,-3.289985703515609,-0.9202385683601326,0.3001194109115808,-0.26015433345448624,1.1956081822992952,-0.3283409855713135,-0.029351696687112128,False,c1,1,"There are now at least three ways to edit a page via index.php (not including other crazy things like Wikidata). I couldn't find a bug tracking this user experience issue, so I'm filing this one.
The three ways I'm initially focused on are:
* directly editing the wikitext (which can appear as an ""edit source"" page tab when VisualEditor is enabled);
* VisualEditor [https://www.mediawiki.org/wiki/VisualEditor]; and
* CodeEditor [https://www.mediawiki.org/wiki/Extension:CodeEditor] (automatic for pages in the Module namespace and soon the CSS/JS pages as well; has a toggle in the edit toolbar).
In particular to switch to editing the source, I'm worried about divergent approaches in the user interface. For example, a page tab v. a toggle in the edit toolbar.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",50610,-7,Medium,False
-4.086960334133379,2.3651902783114878,-2.866344359662694,-0.8545919428544305,-0.317204128997551,4.389761912032418,-1.4137190794998702,-0.1655636763024621,0.5841863964661902,-0.6946691981186346,4.178399736429913,1.8777124542668988,-2.3004183287951587,0.8091299250201178,-0.06279576051524849,1.677919779526646,-0.6142167848337298,-0.20212159043333489,False,c1,1,"VE drops things like <i></i>, which Parsoid sometimes uses to preserve strange things.
I think a solution might be to store this as an inline node or as a meta item.
--------------------------
**Version**: unspecified
**Severity**: normal",50605,-7,Medium,True
0.6885189412695016,-16.777936138457765,-2.4478311504948067,0.9043307314391582,-1.9012244827990963,2.513897894757428,2.1396736646625625,-1.7750720679462444,1.0172371401266918,-1.5751644097825235,-2.270828888045429,-0.7573643459537795,-1.4739151421606902,-0.25519456826633835,-0.3278118989675365,-0.25432301057242124,0.10100572752280246,-0.2052124178597725,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: minor",50603,-7,Medium,True
5.0444589366224015,-4.665696421578183,-6.33649424696608,-2.0421814865252146,-2.068274325919918,7.592556462031939,2.8214789378098084,-0.5387616605577805,-3.7286050974454463,-0.20884746338327087,-0.10778264988097819,2.153123962904975,0.883390153434159,2.519702904291436,0.9598816706978655,-0.6832394459036373,-0.35840957464582623,0.24521542285411946,False,c1,1,"Throws an exception on line 564 of ve.ce.Surface, ve.getWindow is undefined.
--------------------------
**Version**: unspecified
**Severity**: normal",50602,-7,Medium,True
-9.981762284104073,2.446681886167571,-6.483004767768415,-4.163004611601158,0.13144010558530872,6.247194417023463,0.10479834330309057,-0.9549311793483811,-2.6778349059015607,2.4550133729799066,-1.510444732605235,0.5607203994852206,-1.3544942781602574,1.0289267412851908,-0.6350066363742561,2.3229521740811814,1.3389024241475032,2.560978981814256,False,c1,1,"'Review and save' is enabled on loading an old version of a page (as it should) but becomes disabled briefly after the first transaction is committed, and again if you undo to the top of the stack.
--------------------------
**Version**: unspecified
**Severity**: normal",50584,-7,Medium,True
-10.263786729084407,4.799435145531493,0.304817514874685,0.3555799705542688,-2.3161383764746146,-2.5914144110410047,2.2438396324244083,5.642250839387697,0.12175803310608774,0.9297128248926558,-0.3087700788483496,-3.331973573651071,0.6509541418505567,1.902955668574256,-0.21887871816922377,-2.8209356309917935,-2.744283457176296,1.3525802007626584,False,c1,1,"When ""deselecting"" the text field of the visual editor (e.g. by clicking into the summary field) it seems to somehow loose focus.
It's then not possible to directly select text (with the mouse) anymore. One needs to first click one time into the text field to be able to normally select text again.
--------------------------
**Version**: unspecified
**Severity**: minor",50576,-7,Medium,False
-8.995348133020155,-0.3995918062867183,-7.33520105375262,-6.695884339549688,3.648836213566947,-1.8426025426158659,4.596716299609002,-0.37958978106940944,-2.7230534987592687,1.9940832144518499,2.795216689591012,0.35063700490024163,1.3052271696702902,2.544363223921253,-0.8919487323282844,-0.971836137049622,-0.34525508764321433,0.17244316763450285,True,c1,1,"It should only appear when you're matching to a single, extant category - it doesn't appear for a new category, but appears (with no content) where you match more than one, which is confusing.
--------------------------
**Version**: unspecified
**Severity**: minor",50564,-7,Medium,True
-3.4481229931733446,-8.686471850362333,-5.382069103867654,-7.650293652965078,3.6226917838009833,-1.4079270656159621,5.428444933075784,-5.877509332946412,-1.1657826501156396,0.5069632589285415,1.879095416948886,4.411027930902754,-0.8476878104077761,-0.21751999970661462,1.9905229984851758,2.7716579315037397,-0.3008866392814875,3.7832296310780533,True,c1,1,"It's a no-op, and is confusing. (But is it more confusing to list it?)
--------------------------
**Version**: unspecified
**Severity**: enhancement",50556,-7,Medium,True
-4.772081321643123,3.9539279063043793,2.1751131613874506,0.7340669392074299,-3.3538899752847353,-2.960395107953924,1.2285543537551398,-0.5824062086947293,2.0810808655854602,-1.480814538201634,-1.0361896864514235,1.8669247621562792,0.38213363447552373,0.4618126461996983,-1.1359088685444005,-2.882501325632731,-0.6521741628614802,0.3641785616825042,True,c1,1,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.
If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).
--------------------------
**Version**: master
**Severity**: enhancement",50507,-7,Medium,False
13.141635137844684,2.6226486532966646,-12.548095879031173,2.3045233227012303,1.4603987089321828,-2.0720151354652154,-1.029192259635475,-0.4564297355889788,0.3499774217972472,-1.1680270315373322,-0.8276073484602366,-0.19825060988240772,1.5303967233539586,-1.1507178697027962,-2.2055020043798432,0.1475497658247776,0.03265925874235465,-0.8344623515511624,False,c1,1,"We now have nginx SSL proxies in front of the beta caches (Bug T38648). We still have to fix the certificate (that is *.wmflabs.org for now).
We need certificates generated by 'Labs CA' for the entries listed in role::protoproxy::ssl::beta and some more. I guess the easiest would be to create *.beta.wmflabs.org cert that will also contains the following DNS entries:
*.wikimedia.beta.wmflabs.org
*.wikibooks.beta.wmflabs.org
*.wikinews.beta.wmflabs.org
*.wikipedia.beta.wmflabs.org
*.wikiquote.beta.wmflabs.org
*.wikisource.beta.wmflabs.org
*.wikiversity.beta.wmflabs.org
*.wikivoyage.beta.wmflabs.org
*.wiktionary.beta.wmflabs.org
And the mobile ones:
*.m.wikimedia.beta.wmflabs.org
*.m.wikibooks.beta.wmflabs.org
*.m.wikinews.beta.wmflabs.org
*.m.wikipedia.beta.wmflabs.org
*.m.wikiquote.beta.wmflabs.org
*.m.wikisource.beta.wmflabs.org
*.m.wikiversity.beta.wmflabs.org
*.m.wikivoyage.beta.wmflabs.org
*.m.wiktionary.beta.wmflabs.org
*.zero.wikipedia.beta.wmflabs.org
**See Also**:
{T56065}
{T70387}
{T71269}",50501,-7,Medium,False
-2.0824299704570004,-0.45553420532533373,-0.7341080943997245,-0.2412826174444297,2.888733216081481,4.799452322894231,-0.22604821273183529,-0.6767395478278266,2.859204011200582,0.06033345921447886,1.5233191847109233,-0.45639314524811925,0.4547574699620416,-0.18447441715518753,-0.6181543800657607,1.151772915263875,-0.07599207300085231,0.9160940667293531,False,c1,1,"We need a public API end point integrating with the general MediaWiki API that provides at least the following functionality:
* HTML DOM retrieval per page and revision. Basically the /en/Foo?oldid=<n> end point.
* HTML DOM expansion: POST a DOM (or fragment), return re-expanded DOM
* HTML DOM saving: POST a modified DOM and a summary, and save it as a new revision.
As long as we are using Wikitext as our storage format, saving requires a conversion to HTML and a separate save step. The individual steps should *internally* be exposed to other users including the VisualEditor extension. There is probably no need to expose the HTML2WT conversion. We should instead aim to provide an HTML-only public interface.
The integration should use an URL schema that makes it easy to map some or all of the functionality to a stand-alone (non-PHP) backend to avoid PHP startup costs in the future.
--------------------------
**Version**: unspecified
**Severity**: normal",50483,-7,Medium,False
10.471429245922634,-6.434764249134477,6.757658597510314,-2.0409932439636966,4.682761899894228,1.7882336971782322,-5.431281850151034,2.800724610605108,-1.6419865910509521,-2.855212643728265,6.357173544076021,-1.1755051405476467,-5.547359832128582,0.6333405832507077,-0.7883734640897675,-1.1766418366207614,0.5406498812152201,-1.0543483691919797,False,c1,1,"Currently the VisualEditor linkes like this: [[Glas|Glases]]
The German-language Wikipedia prefers this though: [[Glas]]es
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51438
https://bugzilla.wikimedia.org/show_bug.cgi?id=49940
https://bugzilla.wikimedia.org/show_bug.cgi?id=52240",50463,-7,Medium,
0.692345873112044,1.9927176487591467,1.2614065593519719,-3.447382860145635,3.4253628563598926,0.20176268787399376,2.9747931442589346,0.4773756314276296,0.34227770170742133,1.2810666768277263,1.0670288626652966,-1.6738369951236813,-1.4168469713588383,2.660986116171312,-0.7278885039579706,2.4119236208472294,-2.8680144199691293,-0.902727335865779,False,c1,1,"When VisualEditor comes across a part of a page it can't edit, it adds a green striped area. However, VisualEditor seems to have very bad aim in Monobook. Screenshots forthcoming.
--------------------------
**Version**: unspecified
**Severity**: minor",50432,-7,Medium,True
-1.0706340703354806,0.42956877572900964,-3.8281270615403784,-6.073092318296409,-1.8170786927556963,-1.2964378999674624,1.338140508233102,2.613420079822799,-1.8909296016760722,-2.5480303352235114,-0.6927101625784262,-1.7855363340743948,-4.748557386711387,-1.5716543029840309,4.637274599575226,0.3332477577499665,1.1902127307379098,-0.7985899437726511,False,c1,1,"Currently VisualEditor is only enabled on the user/main namespaces on mediawiki.org. It'd be nice if it were enabled on all namespaces on mediawiki.org.
Perhaps test.wikipedia.org and test2.wikipedia.org as well.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",50430,-7,Medium,True
-2.1229505126790875,-5.584487612369882,-1.5244612126554316,2.1772522616757928,0.8869295958948444,1.3807389750261063,-4.111868965766133,0.25973408804266174,1.2899935499899289,0.09471862416152455,-1.093648493938629,0.003823465417660543,2.7511566234289235,-1.4307070043250083,-0.9055919778358774,-0.2675073554447345,0.35245258475314434,-0.24299290474360435,False,c1,1,"Bad diff from VisualEditor on mediawiki.org, 2013-05-13
Go to <https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals>. Click ""edit"". VisualEditor form loads. Add a space after the sentence ""that drive editor engagement;"". Remove the space. Click ""Review and save"".
Expected behavior: a diff showing no changes at all (space was added to the end of the line and then removed).
Current behavior: see attached screenshot.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10742}",50427,-7,Medium,True
2.016790672677795,-5.2506096607654875,1.5903157686780425,-4.85076813494863,6.4797366816493795,-3.7600426604592645,-1.6615190990319295,-5.762617271235292,1.3789502226561863,1.873256448341464,2.7969521117071827,-2.24882068837484,-0.9500044793129874,-2.395408134361609,1.838465775084889,-1.6006288228253336,1.0200148776456037,-0.7952889243294825,False,c1,1,"VisualEditor added ""../"" inside [[Category:QA]], breaking the link. I swear I didn't touch the category itself. I was just editing an unrelated paragraph.
See https://www.mediawiki.org/w/index.php?title=Groups%2FProposals%2FFeatures_testing&diff=689563&oldid=689504
--------------------------
**Version**: unspecified
**Severity**: normal",50408,-7,Medium,True
4.060791771483117,-5.319175099271559,0.7750064396756677,2.146040101431495,-4.71131077171759,-2.511651849155144,-2.644740034772635,1.6397008070470327,-3.5391564603830403,-5.626894656939788,-0.14992048420090542,-0.8320127856573474,-2.4019445891465327,1.805028762807381,4.278984005194629,1.0052851425471732,1.5870446642709612,2.6253110021235404,False,c1,1,"Any plans of having JSCover (JavaScript code coverage analysis) being integrated and run by Jenkins (in away that is usable for core and extensions as well)?
[1] http://tntim96.github.io/JSCover/
[2] http://tntim96.github.io/JSCover/example-qunit/out/jscoverage.html?test/index.html
[3] http://tntim96.github.io/JSCover/manual/manual.xml#automatingPhantomJS
[4] http://tntim96.github.io/JSCover/manual/manual.xml#automatingAnt
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",50365,-8,Medium,False
-5.130562581049762,5.2805417899874705,15.568712445756027,6.180518844243746,5.053744893262234,1.3503522178972165,3.3939254103021765,-0.7862479851525395,-2.3264077459991785,1.4911230664059287,3.1867223537973284,3.0923327163976895,0.8771065268067408,-2.4947438931003214,2.6675805325712476,2.66752995364003,-1.3188601498085888,-2.1794275966459247,False,c1,1,"Single newlines have no effect on the way a wiki page is displayed.
So they should be ignored in a WYSIWYG editor.
Example: Third line at http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services#Specification_progress_.26_TC_members",50290,-8,Medium,
7.225048265362261,-3.135236506566187,5.58484287370133,-0.17805417294124248,1.1566543479407299,1.4032792216704328,-3.707703967376032,1.6885877070547788,-0.41450425572147764,3.9361974542156997,-2.1952808573725644,-1.6691865722784458,1.5550241533819116,2.194756581208222,1.3916721620822319,2.261805507528055,-2.306356030659495,0.11112223862040493,False,c1,1,"Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type ""Enter"" 2 times.
Type ""Backspace"" 2 times.
Expected: as original
Actually: The newlines remain
--------------------------
**Version**: unspecified
**Severity**: normal",50284,-8,Medium,True
2.797084675098359,4.395956374802541,0.2575675632318095,-6.017113860956107,-4.6011721933184955,-2.716745447774577,-0.8598707931143599,3.9534784342940137,7.628253715723011,-0.46160053564115877,-0.4525798514659116,-1.6676301565320881,0.07553579233510721,0.2497816076225865,-0.4699287947393307,1.4202587375036824,0.26988078574202934,-0.067049005827992,True,c1,1,"As discussed with Steven W. just now, we should move this into MW core (so, amongst other things, VisualEditor can depend on it and not have to re-invent the wheel).
--------------------------
**Version**: master
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=16066",50276,-8,Medium,True
3.654317188288266,-0.39091249891478874,2.8247951059180174,-4.464955168923612,1.421801888409969,-7.084369251758519,1.1320621010287812,1.679687395782413,0.04954300491083358,0.3296025618057783,-0.4282272365918738,3.7620071404273396,0.6107018428386106,2.579396832547398,-5.659761300115288,-0.6086224426288485,0.24549865713927632,-3.6833347911586687,True,c1,1,"We use textarea which means that browsers don't suggest text from previous uses.
**See Also**:
{T53903}
{T54859}
{T54085}",50274,-8,Medium,False
-1.3079726116470103,-9.216578520115203,3.4602511330140544,1.963779618161185,0.6934326659193242,2.4560561342490743,4.112024076568338,1.7239731643375253,-2.7766910701465957,1.2567701243144969,1.8986888605886985,0.18500167861130534,0.8970459250830358,-2.417648874304684,0.4750759884572142,2.716580469138409,-0.1739512309843716,0.7271585909846021,False,c1,1,"Images in a table are incompleted alienated and still clickable.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Liste_der_Hochh%C3%A4user_in_Deutschland",50254,-8,Medium,True
3.81547857832645,-1.9550973651074504,-6.372113078929386,0.042477754297922,-2.1941870810545696,0.22691705874539814,0.26103856751059507,3.578968955725763,-0.5214792647550478,2.0325615942318693,2.614020893960561,-1.7775244872654978,0.7064993259974024,-1.9621180943909162,-0.44335708427677023,-0.10103940258753175,-0.029139508720670504,-0.5870377340395978,False,c1,1,"Not sure whether this is ContentEditable, DataModel or LinearModel.
When pasting italicised text (from elsewhere on the same page) into an already italicised sentence we currently close, re-open, close, re-open that annotation.
Steps to reproduce problem:
* start with:
<p><i>Original text here.</i></p><p><i>Something else there.</i></p>
* select ""else""
* copy
* select ""text""
* paste to replace
* end state:
<p class=""ve-ce-branchNode""><i class=""ve-ce-TextStyleAnnotation ve-ce-TextStyleItalicAnnotation"">Original </i><i class=""ve-ce-TextStyleAnnotation ve-ce-TextStyleItalicAnnotation"">else</i><i class=""ve-ce-TextStyleAnnotation ve-ce-TextStyleItalicAnnotation""> here.</i></p>
Now this wouldn't be a major issue (merely inefficient) if it weren't for bug 48194 in Parsoid.
Real example:
* Intended edit: https://www.mediawiki.org/w/index.php?title=Watchlist_wishlist&diff=686477&oldid=686247
* Actual edit as seen in the Review and save dialog of VisualEditor (and saved as-is): https://www.mediawiki.org/w/index.php?title=Watchlist_wishlist&diff=686475&oldid=686247
--------------------------
**Version**: unspecified
**Severity**: critical",50195,-8,Medium,True
-4.209744302328798,-2.8338201768017424,-3.8811527870842397,-1.0240408845191866,5.156709674688157,0.684953319101741,-0.9927047661987469,-0.41753268589867476,1.0266937469830466,0.9054098650892488,3.007396434978475,-0.2637479914303158,-0.21840925432987124,0.15215370469687972,-1.228071589600514,1.038608472381591,-0.9177376037747433,-1.4897333592096809,False,c1,1,"* Create an English article with a <ref> tag at the end of a paragraph
* Set $wgLanguageCode = 'en-rtl';
* View the article. You'll see something like ]My text[1 (this rendering seems wrong)
* Edit the article in VE. The non-contiguous reference causes problems:
** The phantom is rendered wrongly so it's not visible
** When you select the reference, the selection looks really strange
Should we wrap things in a <bidi> tag or whatever to ensure better rendering?
--------------------------
**Version**: unspecified
**Severity**: normal",50185,-8,Medium,True
-0.9737157577092859,0.7945648576590614,3.380059792421825,3.1288965932663713,1.48676518092757,1.4627751871437755,2.5182595789194915,3.213949645098881,1.8009101328396249,-0.14555510135405747,-0.2511819944614526,0.20139403662954902,-0.9709172283507375,0.39800630005449644,0.15065699904791785,-0.15798916202977248,-0.8977928716025412,1.9158671731984669,True,c1,1,"Make a null edit (space and backspace), then trigger a diff. JS error thrown in Firefox but not Chrome:
Error: toDomElements() failed to return an array when converting element of type alienBlock @ http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-raster%7Cext.visualEditor.viewPageTarget.icons-raster%7Crangy%7Cunicodejs.wordbreak&skin=vector&version=20130506T190432Z&*:130
However, for debug=true, no such error occurs. Is this just going to be a transient RL issue?
--------------------------
**Version**: unspecified
**Severity**: minor",50181,-8,Medium,True
-0.25414004485611663,-2.6548163626881074,-0.08113097916335832,2.252735202130076,2.4191628230952427,4.72928141427266,2.442583472531763,-1.9490963729054482,1.2599232561711495,1.3504546255425671,3.5192144376145094,-4.5865644512198545,2.5301454278359237,-1.9659172124556923,2.3615448014364384,-1.210912902317231,2.1138894780002024,0.11849943888346481,False,c1,1,"I watched a user using Chrome paste a 32400-character buffer of special characters into VE. Chrome became unresponsive.
This user then did that in multiple tabs and the entire computer became unresponsive.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50172,-8,Medium,
5.9524588797816484,-2.6581419112621685,-5.770837732392671,-3.9661789082056487,0.5761661916640373,-2.1711949840249174,-0.8474010001225833,-0.7146672464393338,-2.4942501828242154,2.480327770586042,-3.1984787389603144,0.6970623758635359,-2.915205798701469,2.1065225540367125,1.6975458669849077,-1.8911209721070912,1.9436545570404264,2.248262748224315,False,c1,1,"(Provided we are happy with the rendering quality)
Currently we only serve SVGs when window.devicePixelRatio > 1.
On suggested test for SVG support is:
document.createElementNS && document.createElementNS( 'http://www.w3.org/2000/svg', 'svg' ).createSVGRect
--------------------------
**Version**: unspecified
**Severity**: enhancement",50148,-8,Medium,True
-5.4793229700085835,12.812344988542836,3.82860645823288,3.445760797440669,-0.8002821171279357,4.944340110618991,1.3056564660773953,-0.6984924010254426,-1.616397536042242,-0.10098646199769501,0.22736369093272035,2.970705180455413,-0.015219537170672481,-1.1815127850248839,1.4738051236266037,-1.1677291960933334,-1.6054650768747507,-0.6245887341084584,False,c1,1,"As the title says: when the VisualEditor is active, the drop down menu (p-caction) under Vector skin is dropped down behind the VE toolbar, making it impossible to click on. May be a simple z-index issue.",50078,-9,Medium,True
10.541378495836456,-10.054913828938185,5.950050273026264,1.4627478916801442,2.329717934734185,-1.6749570385689299,-0.16179323350040686,-4.000554128834841,0.42506672006470625,-1.6245965208524455,0.20488195215478688,-1.3768981748799247,3.2170337553123907,-0.5094529254433882,0.8032420971234924,-1.182035514869052,0.14607232085986266,0.0685555735342136,False,c1,1,"Expected layout
I included two screenshots, illustrating the problem.
Apple Safari 6, Mountain Lion
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Meurchin
**Attached**: {F10895}",50070,-9,Medium,True
-5.0080056623347575,2.453841433287163,-0.33679595202059076,2.8384009833787944,5.4569790766841475,3.1933281988679365,-1.7317963125006273,-2.0105934292250005,-1.3096599939179554,1.631218871868886,1.8983027734771176,-1.7734729618347078,-0.3632799333931791,0.8423654635862947,-1.3666418718355526,2.0598346006702046,-1.8325441810356073,-0.3125081998921102,False,c1,1,"In Firefox 20.0.1:
1. Edit a page that has a bulleted list.
2. Place the cursor on the first bullet item.
3. Click the ""Bullet List"" button. The first bullet item loses its bullet. (Correct.)
4. Click the ""Bullet List"" button a second time. The first bullet comes back (correct), but there is now a blank line displayed below it.
Similarly, if you remove & add a bullet in the middle of the list, you get blank lines above AND below the item.
Similarly, if you do this with a numbered list, the blank line breaks the numbering: the list items below the blank line start over from ""1"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",50051,-9,Medium,
-2.800915201777436,-7.1117344747405165,1.8943689331171178,1.0210634763333455,-2.113198663304977,2.407187126947906,2.8799345932000593,0.7921220821959513,-1.9097074381515076,-1.5468357413017797,-2.8876295397475493,0.3819613537767925,-1.9969271656283434,-0.5651252838331313,0.4054483045472219,0.49559805144488567,2.2655731334831692,0.6824653248452435,False,c1,1,"The indent and outdent buttons are always grayed out.
(reported at http://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/Alpha2013-04#Link_einbinden_.2F_Einzug)
--------------------------
**Version**: unspecified
**Severity**: enhancement",50010,-9,Medium,
2.171543138318184,-5.0238531920645535,-4.39733379441056,-0.5658416971127432,2.8240390487086873,1.699889438691354,-1.4785152861356137,1.0284904708618314,1.7831943764940508,-4.227572231150457,-3.47648981424628,0.10538925409768352,-1.882418059003026,-1.9490555854754996,0.6055082128216416,0.7524806096944145,-0.9691998457302105,0.7575480965406645,False,c1,1,"Conversion labels shown
The conversion labels (i.e. { } ) for wikis like zhwiki is shown when editing using the VisualEditor.
Those labels should be hidden, or otherwise newbies using the editor will break them easily.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F10580}",49913,-9,Medium,False
-2.313016888281421,5.129198464291836,-1.764389955931783,-2.1233731375150793,0.6450151106674256,-1.4851551620315104,0.28527410204349923,-0.024440961436456132,-1.791262966422403,-1.5746421038462217,-0.10691237023545552,-1.0189012964607373,0.9630196060793232,-0.26254434203378985,-0.14207408839417646,-0.04428532403634505,0.22611979005918426,-0.7104944034077441,False,c1,1,"From the fall out of bug 47457's resolution:
(bug 47457 comment #63 by Liangent)
> (bug 47457 comment #54 by Krinkle)
> > Change-Id: Ic3d0c937268d0943d2f770f3ca18bcf4e1eed346
>
> This fix causes breakage of any user of site scripts which assume that
> they're
> loaded before $(document).ready(). Maybe someone can move jQuery.ready() call
> to a position just before </body> and after all other script references?
(bug 47457 comment #64 by matma.rex)
> And it also breaks the old 'mwCustomEditButtons' interface to add custom
> buttons to the old edit toolbar, which apparently everyone and their dog are
> using across the wikis. (Since the user JS is loaded from the bottom queue,
> but
> the toolbar script either from the top or using inline <script> tags with
> $.ready inside.)
>
> Reopening. Moving the jQuery.ready() call after the bottom queue seems like a
> good idea.
(bug 47457 comment #66 by Brad Jorsch)
> (bug 47457 comment #63 by Liangent)
> > Maybe someone can move jQuery.ready() call to a position just before
> > </body> and after all other script references?
>
> (bug 47457 comment #64 by matma.rex)
> > Moving the jQuery.ready() call after the bottom queue seems like a good idea.
>
> We tried that, see patchset 5 in https://gerrit.wikimedia.org/r/#/c/61057/5.
> It didn't work.
>
> But unless the browsers were delaying the DOMContentLoaded event until after
> the async-loaded scripts in the bottom queue were loaded, I don't know how
> this wasn't already a problem. Krinkle, any ideas?
A few important questions I'd like answered:
@Liangent: Can you given an example where it matters for a user script whether the document becomes ready before or after they are loaded? The user scripts are loaded from the bottom of the <body> before </body>. Practically the document is already ready at this point, just $(document).ready() hasn't fired yet. Any user script code that isn't wrapped in $(document).ready() will still execute at exactly the same time. Any user script code that *is* wrapped in $(document).ready() will now execute immediately after loading instead of... immediately after loading. Exactly the same, not?
@Matma.rex: You mean the fact that the deprecated mwCustomEditButtons global (unlike the mw.toolbar interface) is inspected only once by mediawiki.action.edit.js, namely at the domready event. And if it is triggered before the user script, adding to that array will become a no-op.
Though there is a lot of usage of this feature, lets not forget the context:
* The mwCustomEditButtons interface is for the classic toolbar (aka ""Monobook editor"", though Vector users can also disable WikiEditor to get to it). This is already a large minority of users.
* The mwCustomEditButtons interace has been deprecated in favour of mw.toolbar.addButton, which I created especially for the legacy toolbar users last year to address the many declined bug reports for mwCustomEditButtons which could not be otherwise addressed because mwCustomEditButtons is beyond repair, it is a flawed concept and it keeps breaking for many reasons.
I don't think anything related to mwCustomEditButtons can justify a change of any kind unless it comes at absolutely no overhead and downside.
@Brad Jorsch: It seems that the Firefox bug with document.write being disabled before DOMContentReady is worse than we thought. It is disabled even before the end of the </body> has been reached. We found through trial-and-error that placing it after the main content but before the bottom queue worked.
As Brad pointed out, $.ready being triggered earlier makes no difference for the bottom queue because they are loaded asynchronously, they always execute without blocking the parser or the DOM ready event. In fact (while designing this) Roan and I made very sure to test this across the entire board of browsers we even remotely support (IE6-10, FF2-17, Chrome10-23, Opera9-11.x). And in any browser that we couldn't load it async, we scheduled the addScript to after dom-ready manually (only in Opera).
However note that the user scripts (like the site scripts) are *not* loaded through mw.loader because we still support legacy global scope for them. They are loaded by a hardcoded script tag in the DOM. Which means they are blocking and used to block dom-ready, and now they run after dom-ready (well, they still block dom-ready, but we trigger that callback queue earlier).
--------------------------
**Version**: 1.22.0
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50310",49872,-9,Medium,True
-0.923364244850716,-6.535649213657176,6.027221239740705,6.088352633272812,-0.1412215699526163,-1.8038423451181147,-0.6768607540255749,-0.5403143796807557,-3.265638636447494,-0.22522340650749761,-0.7441343219900132,2.329192865928988,-2.0177321273060222,-1.7891825839382833,0.02185425294599952,1.6706573810329508,-1.230789627579301,-1.1400332893110487,False,c1,1,"Screenshot in edit mode
Images on pages are normally included using the ""thumb"" syntax:
[[File:Foo.jpg|thumb|description]]
In the edit mode no thumb frame is shown, see screenhots.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/thumb
**Attached**: {F10382}",49803,-10,Medium,True
-0.24540509875124883,-3.860989338730427,6.418712826230841,6.716941762865772,1.696662312759837,-1.7333244522974267,1.4010415576133965,0.6617384531919398,0.9252927998435858,-1.1000110666099827,-0.8029147391124134,0.8476778413032571,0.038413826452603494,-0.8280540512944841,-1.4922867059724743,1.393880871822852,-1.561800554188869,-1.4649723038657756,False,c1,1,"Simple test case, see URL:
* foo
: bar
adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/Finissage
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60535",49790,-10,Medium,False
0.22885817524734442,-5.588363266368464,6.530273091199188,4.167459134837956,-4.909081225070018,0.18362033087504304,2.77863017571853,0.04281552896039931,-0.47902248297236416,0.06156506090131675,-0.2791039894668459,-2.421451956010471,0.10197899860019444,-1.109728048633075,-1.304019697413028,0.6723190779840811,-0.09487799007124642,-1.5842813147939077,False,c1,1,"Coordinate template on dewiki not alienated. Shown as active hyperlink to the toolserver.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Breslauer_Platz_%28K%C3%B6ln%29",49788,-10,Medium,True
2.1374222761750086,-3.863973501889543,-2.718913309438907,-1.3773954733522424,-6.656554896774315,7.487608508465718,-0.4161484401302067,-2.694342349083154,3.626714634591287,-4.448285847598695,-7.328377458876254,-1.4884549964526266,-5.628871867643482,2.837112211192844,1.9718131240658971,1.6924102505979823,-0.0787863232475372,0.2283576316782685,True,c1,1,"Per community request; will throw in a change on Monday.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",49784,-10,Medium,True
-11.240566687208693,4.687285358920374,1.1813819705796647,5.45827384141818,-1.355052649605918,0.9555088480254061,0.25951042296621285,-2.5580415726186154,-0.5220019988390862,5.854649430388513,-0.42394830758742286,-2.882173504687585,-0.5063474090849267,1.4600014729563187,-2.0000088216411656,-0.9866264650594077,0.9152578891444862,-1.8442133923946866,False,c1,1,"If you scroll down from the top of the page with the edit notice open and then scroll back up, the text content of the notice 'throbs' a little. I think it has to do with the dynamic addition / removal of the 've-ui-toolbar-wrapper-floating' class on ve-ui-toolbar-wrapper.
--------------------------
**Version**: unspecified
**Severity**: trivial",49766,-10,Medium,False
-3.6966351169422706,-1.6439789145471941,-2.3725448109220135,-1.4569347129068988,3.069554508780591,-1.7530058074644153,-3.6600427601848757,-5.21709455450003,-0.5385100164494185,0.07661941202524325,3.002207838946602,-2.869888283479202,-2.6715621422363807,1.1361920398376046,1.1939423045792568,-0.044516834891824786,3.783150908936296,-1.3674272719923322,False,c1,1,"I tested it on the [[Bayes' theorem]] which has <Math></Math> inside the article with chrome 28 and it couldn't load the page!.
--------------------------
**Version**: unspecified
**Severity**: normal",49760,-10,Medium,True
-7.024974200917176,-3.1379032341457513,0.7863217609266009,3.386440459832297,11.483046149220895,0.9920244663141273,3.5663740451426333,1.968926656050125,-2.698365342345122,2.487388020893004,-0.03449911104758785,-1.786823878938777,-1.2517972713811298,-0.9536056099646961,1.6053619660352565,-4.068504806945798,-4.884175460147952,0.3271832991457402,False,c1,1,"No warning is shown when saving a page without an edit summary even when the ""Prompt me when entering a blank edit summary"" preference is enabled.
--------------------------
**Version**: unspecified
**Severity**: normal",49752,-10,Medium,True
-0.8001832102065705,4.43932993626246,4.0102551310289485,-1.4983255243887514,5.427901910492897,2.1467509323162233,0.8179252534548169,-1.476256871414142,1.022124946773429,1.2075806758671366,1.024943337312687,-1.463002432556815,-0.4927191852749315,1.261219242311415,-1.1044340501497647,2.835195842554654,0.7711778172361694,-1.4709879146903224,False,c1,1,"When I edit an article in the English Wikipedia and hover over a template or an image, green diagonal stripes appear over it, meaning that it can't be edited.
These green stripes don't appear in the Hebrew Wikipedia.
See the URL for a demo.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/ASCII",49746,-10,Medium,True
-3.752966215078208,-3.6592723733704933,-2.5183515405556633,-0.21718351089068266,4.59438337639283,-0.9208155437469718,-4.2272079588343345,-0.33249888611571926,1.3056012793092386,-0.5444746232180666,1.0400354917695247,-1.3708156973708356,0.17274194727242698,-0.08479558387574482,-1.9471038635711357,-0.4108273157323695,-0.927419267936735,0.6001817275057031,False,c1,1,"Steps:
1. Go to the URL.
2. Start editing the page using the VisualEditor.
3. Move the cursor using the keyboard arrow keys forward (right).
Observed:
When you get to the ""Done"" template and go on moving the cursor, the whole template disappears.
The same happens when you get to the reference number on the second line (""[1]"").
The cursor must probably skip over them and definitely not make them disappear.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/VisualEditor:Disappearing_template",49745,-10,Medium,True
-7.362234555879526,-1.6045883082410075,1.3050321702221872,1.9376429249022227,-6.951666481945132,1.8162335537144811,4.687382650366524,-2.330436904337265,2.6091670714050723,3.3062411994787286,4.381848506790915,1.2510042769515624,1.3850980321604967,0.11228975693051435,-1.5148040086340382,-3.0433427015593946,-1.2277533779600822,2.513424118555701,False,c1,1,"Having users using different languages to post feedback on different pages on the same site makes it difficult to manage.
--------------------------
**Version**: unspecified
**Severity**: minor",49730,-10,Medium,True
-5.351710986604973,5.142263400163856,0.34131297436887564,0.660521568050042,3.1399304436320907,-2.3126829217068607,2.329069368547441,0.34722871044524806,1.4833622422612782,-1.517419267408636,-1.412121154884859,-0.7649884143065679,-1.6509036973366413,0.3377325359615613,0.27905630132897397,-0.755681918882523,2.7400070736111193,0.39780929124745446,False,c1,1,"I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change?
I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49729,-10,Medium,False
-0.28070592416625795,5.240462286915289,4.6228124791009115,-1.1882602615102107,-3.8463201793482638,2.111998928201718,-2.072164655083507,1.4555875119451214,2.581119064384671,0.00947567391358195,1.5839649050811349,-1.3562194866153998,2.3973049455911406,-0.11159489987732574,1.0483919592841762,2.084424567690178,2.211978897694655,1.5819169058321785,False,c1,1,"Try typing non-ASCII characters in the VisualEditor edit summary field. For example, just type the Russian letter ж continuously. Towards the end it won't stop at 0, but at -1. Example screenshot from the Hebrew Wikipedia: http://j.mp/ZoQKX6 .
This should be handled in a cleaner way. Either disallow typing anything that would go beyond zero, or allow all text to go beyond zero, as in Twitter or MoodBar.
--------------------------
**Version**: unspecified
**Severity**: minor",49718,-10,Medium,True
-3.727989838469024,0.9031962921796133,0.8432352335741413,0.8701147948451116,-0.5635325802856991,6.417893493015334,-2.697214630750285,-0.7128842475850241,1.8159730653945758,-1.5309413042770617,1.8376694984331885,1.8641096284213086,-2.40349546578266,0.25073237997051034,0.9039039202734109,1.1194365200699243,0.0493281849387357,-1.8459647453131824,False,c1,1,"Steps:
1. Write some text in VisualEditor in the Hebrew Wikipedia.
2. Select a word.
3. Press the link button in the toolbar. A small link insertion panel appears.
Observed: The direction of the <input> element for the link is ltr.
Expected: The direction of the <input> element for the link is supposed to be rtl.
Comment: It does make sense to set ltr direction by default for external links (http://www.example.com). For internal links the default direction should be the same as that of that Wikipedia's content language.
--------------------------
**Version**: unspecified
**Severity**: normal",49717,-10,Medium,True
0.9781801217537365,-17.869547122693323,-5.220286576535438,-2.574243610812264,-2.0450275013262447,5.861690617773853,3.0310100229115333,-0.6494408554847819,0.16082679462413457,0.5653550858005492,0.4597239704050242,-1.2990169873342783,-0.15710337680384345,-0.42180271184458995,-0.5825311518848411,-0.49268925925624174,0.0723332972457722,-0.28923892051716615,True,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: trivial",49684,-10,Medium,True
-6.780154017066637,-3.791008933768392,-2.822018058478948,-3.503700980065875,-8.019420405910846,-1.0180010901919407,4.357081219655446,1.8327004452215512,5.27477389857621,3.386575037678078,2.3445779638366386,0.18745031470859708,-0.2892283176105872,-0.048365657690562,2.1603213238708907,2.1652369735948858,0.791808021132314,-0.4362109639556706,True,c1,1,"If users can't edit in nowiki blocks, they will make accidental wikitext-like items and be forever unable to edit them in future.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49678,-10,Medium,True
-6.390917531307288,3.2252660330117138,-1.0872637529207339,-2.000625892645372,-0.12631268901331272,-1.5499904395144608,-2.3336664331510564,1.0246073943383833,-1.701084424521043,2.736556978835681,-2.2646840694921027,-1.4490150437326896,-0.7954399486513157,-1.3367460210576363,2.2711446628471066,2.2100291725096586,-1.5451056843078783,0.3904050689808243,False,c1,1,"The 'cancel' message is used confusingly.
I only noticed it recently. I know of two places where it is used, though there may be more:
1. As a link near the ""Show changes"" button when editing a page.
2. As a button near the ""Review and save"" button in the VisualEditor.
In both cases it's better to say something like ""Exit without saving"". The ""Cancel"" button is usually used in dialog boxes and not in editors' user interfaces.
The message may be used in other places and in extensions, so it's probably better not to change it. For these actions a new message should be created, or maybe even two messages.
--------------------------
**Version**: unspecified
**Severity**: trivial",49676,-10,Medium,True
-0.38692912123595136,2.0308647564486826,-1.1984809595134003,-1.789956455843113,1.8640592851762414,-0.5066483379058032,-1.1519800331437793,-5.135385513336247,1.2425244293475024,-1.0347845307814616,0.17965650647848408,-0.9665344866030281,1.5728201457197644,0.8013822766769341,-1.4982971231292241,0.882866422385421,-1.3406259257679314,-2.7436980352275073,False,c1,1,"Take a look at the URL.
When you see the output page, the list has three items. If you edit it in the source editor, you'll see that there's an extra empty item in the end of the list. If you edit it in the VisualEditor, you'll see it rendered.
The VisualEditor behavior actually makes more sense to me. Gabriel Wicke suggested on IRC to open this issue at the PHP parser.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/VisualEditor:Empty_list_item",49673,-10,Medium,False
11.385629843261139,0.7261065467606738,-0.8081313356472783,-2.0120611265326382,-0.32960809544237635,1.2000140901853678,-3.1196594070133874,-1.3897037917594264,-3.000043195447682,-2.6038111456735686,-1.8326811164686094,-0.09146145903290925,1.9748472135267905,0.2174623610935278,0.1494247379988165,0.14404002309536032,-0.5870779990274604,1.185665592622869,False,c1,1,"**Author:** `owen`
**Description:**
Looking at [[Principality of Stavelot-Malmedy]] in the Visual Editor, immediately after the heading ""Development and the High Middle Ages"" there are two images floated right.
In Read mode, these images are given `float: right; clear: right;`. In VE mode, however, the `clear: right;` appears to be missing, so the images are stacking up.
In case it makes a difference, I'm running Chrome 26.0.1410.64 m, on 64-bit Windows 7 Home Premium (Build 7601, Service Pack 1).
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.org/wiki/Principality_of_Stavelot-Malmedy",49672,-10,Medium,True
3.3927031795904505,-8.191371138100521,6.166785921831032,1.6773172269122334,1.9010788011198145,-1.4812945410316187,2.6315444437285977,-0.8334594548899761,1.32391693339567,1.3912606637778717,2.5550038378793514,0.9098575847120796,1.59398563649078,-0.5994395386433009,-2.3804100151959,1.4006713571661877,-0.13965704880059837,-0.06444888391202386,False,c1,1,"A long title all mixed
Long titles get compressed until they become unreadable, see URL and screenshot.
--------------------------
**Version**: master
**Severity**: minor
**URL**: https://meta.wikimedia.org/w/index.php?title=Special:Translate&language=de&group=page-Wikimedia+Blog%2FDrafts%2FTry+out+the+alpha+version+of+the+VisualEditor%2C+now+in+15+languages&filter=&action=page
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45924
**Attached**: {F10857}",49642,-10,Medium,False
0.16514223716555287,-6.7966329582622595,-5.33332662614359,-1.1868461249314877,0.5959534234655632,-1.441878835510348,-3.67329664356863,1.9414462067544664,1.3816407115467515,0.30089310533085634,-0.9744958467984195,0.4271879720735112,2.460483548573629,-0.573963522765176,0.0692445001457127,-0.9193134457075265,-1.4615849466158644,2.0903888741252468,False,c1,1,"1. Parsoid not running, VisualEditor enabled on to-be-created page X
2. Enter a few words
3. ""Review and Save""
4. Loader keeps spinning indefinitely
Request:
action=visualeditor&paction=serialize&html=%3Cp+data-ve-changed%3D%22%7B%26quot%3Bcontent%26quot%3B%3A7%7D%22%3Edfgdg%3C%2Fp%3E&page=Sandbox%2F1&oldid=0&token=%2B%5C&format=json
Response:
{""visualeditor"":{""result"":""success"",""content"":false}}
No errors.
Note this bug could also be reported as ""Loader keeps spinning forever when creating a new page and trying to review/save it""
--------------------------
**Version**: unspecified
**Severity**: normal",49581,-10,Medium,True
-3.0024012617963844,-0.2708849379958238,-3.73722057753114,0.3347211849529437,1.6985363604785597,4.214934118202992,-0.5600746906046243,3.768181282133183,1.9932069917262616,-0.6349720942996804,0.1734555855395472,-2.3451133633491406,1.3067596776907977,-1.8409904617662418,-0.47132547332578767,-0.03616520622534314,-0.9991378853124706,0.022246322574887012,True,c1,1,"As a VisualEditor plugin inside the extension, provide a visual way for users to create and edit musical scores.
This would be a (very) major undertaking, even if there is an existing JavaScript-based visual Lilypond score editor, or failing that, a visual score editor with a different output format which would need to be converted to Lilypond. A brief search found a few promising leads for ABC editors, but mostly based in Flash.
Still, hopefully not just a pipedream. :-)
--------------------------
**Version**: unspecified
**Severity**: enhancement",49528,-10,Medium,
-6.588313913036835,5.233281932006054,-3.3842399533627834,-0.37219064822582937,-3.53129958227386,5.799188781374598,-3.2608391189963983,2.2548192614766247,1.4680547354133366,1.8036399576849034,0.2291051024726194,-0.520759629896992,1.229795905999183,1.2483737172690814,-2.5173442755836515,-1.3872610645385353,0.06200385380542284,1.1594600784448363,True,c1,1,"On VE load, do an ""originalHtml == serialise(linmod(originalHtml)"" or whatever and fail out of the VE if false; ideally, also allow the user to submit a failure report for debugging purposes (this will need to get checked through with legal).
--------------------------
**Version**: unspecified
**Severity**: major",49521,-10,Medium,True
-5.444243702196998,3.9186045296581504,-4.878915742383361,0.16365928556987286,1.395738104354214,-2.3688443745268697,-0.47327846573876187,3.780032438716457,0.9824896818875033,-1.5741783360319532,-1.452605405725425,2.7710175414924665,0.38194015399136827,0.6559966122255734,-1.248549657170381,0.2564968202646037,-0.4331894350160759,0.3032694352357954,True,c1,1,"The ""language conversion blocks"" are a wikitext feature that allow users to define text content in parallel scripts. The most high profile is in Chinese, which has two major writing systems and automated conversion between them, but there are 28 others, some of which are not automated conversion (so VE will need to not just mark the text with an appropriate <span>, but allow the user to understand when they have edited text that needs editing twice or thrice (possibly in scripts they cannot/do not want to use?) - see https://meta.wikimedia.org/wiki/Wikipedias_in_multiple_writing_systems
Documentation of the feature (focussed on the syntax) is here: https://www.mediawiki.org/wiki/Writing_systems/Syntax
Parsoid will need to add support for this first, which is {T43716}.",49411,-11,Medium,False
-4.39421286114401,1.1279428199012074,-9.344844681566519,-5.48732303668476,3.3214233690286177,-0.6922865402027123,0.9086079543541317,-3.1295716755572407,0.8800772183881369,-1.0463318299909385,1.0023054412822296,-2.936545090220128,0.34385835842995416,-1.6933214456666055,-0.09831953333824561,-0.5772013640645629,-0.8999679672147763,-0.3698845235813575,False,c1,1,"If we get an MWTemplateNode and the user doesn't change it, then in the data->DOM conversion we should serialize it back out the way it came in, including all the other nodes (the template contents) that we normally discard.
Discarding these nodes when the user did change the template (i.e. the attributes changed) is fine and encouraged, but if we also do it when nothing changed, Parsoid's DOM diff algorithm will notice that we changed something in the DOM, causing selective serialization not to skip the template while it should.
--------------------------
**Version**: unspecified
**Severity**: normal",49394,-11,Medium,True
-2.0869883254998065,-6.733763631460342,-4.9130023153466755,2.5858928936844774,-0.3494331685925687,0.11783739672975435,-4.532509095402997,0.3915411684084783,-3.5532169098618143,-2.7314979225857177,4.79436163904081,0.5950217968819411,-3.226952000574153,0.7269144582390039,-1.0661244974231323,-0.2778320187461307,-0.6068039910281817,-0.4228232258097224,False,c1,1,"1. Go to: http://ve-change-marking.instance-proxy.wmflabs.org/wiki/Test2
2. Open page in VisualEditor
3. Open browser console.
4. Run ve.dm.converter.getDomFromData( ve.instances[0].documentModel.store, ve.instances[0].documentModel.data.data ).body.outerHTML
5. You get the following output:
--------------
<body><table data-parsoid=""{"tsr":[0,3],"dsr":[0,49,3,2]}"">
This is a caption
<tbody data-parsoid=""{"dsr":[24,47,0,0]}""><tr data-parsoid=""{"tsr":[24,26],"startTagSrc":"|-","autoInsertedEnd":true,"dsr":[24,46,2,0]}"">
<td data-parsoid=""{"tsr":[27,28],"autoInsertedEnd":true,"dsr":[27,46,1,0]}"">Table cell content</td></tr>
</tbody></table></body>
----------------
Notice the missing <caption> .. </caption> tags.
So, when Parsoid gets this, the caption is fostered out and shows up as a diff.
--------------------------
**Version**: unspecified
**Severity**: major",49349,-11,Medium,True
-1.1901364444421048,2.601675825656624,1.7858064409260628,3.320312969140458,0.023286041009230596,3.404276137089094,-4.418902977857318,1.0779736295543647,-0.0015069636024753197,0.8736355970193328,1.9468849651119853,-0.0721288341342532,-0.21508514899595976,0.29261502618357316,-0.5265482040553495,-0.4091634744480912,-0.47870435844310677,0.47810003958567227,False,c1,1,"See bug 45808 for the corresponding Parsoid bug.
Currently editing a redirected page (say ""OLPC"") causes the following Bad Things to happen.
a) the edited page content is saved back to ""OLPC"", overwriting the original #REDIRECT
b) the page content is from ""One Laptop Per Child"", but with an added {{Redirect:OLPC}} template at the top; this extra template gets saved back with the rest of the edits.
In bug 45808, Parsoid will return a special <meta> or <link> tag in the body for redirected pages. This bug is for the corresponding VE support to recognize that tag and provide a user-friendly interface for editing redirects.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47329",49328,-11,Medium,False
3.665787739408127,2.5088478126357856,-0.29988235373639327,4.024353227357952,1.5221994756038817,0.6583064124124858,-2.0845632461616592,-2.3830853895384534,-3.552758045245773,-2.2299730362814967,-0.6864118770049159,-0.10046788022589581,2.4640214303555448,1.2070231358205339,1.6419969396205802,-0.4125080974194685,0.44118340120847876,0.6090824459184907,False,c1,1,"Since at 2013-04-05 04:29:46 UTC, Zuul no more receives events from Gerrit. It uses a CLI command such as:
ssh -p 29418 jenkins-bot@manganese.wikimedia.org gerrit stream-events
I did stream-events using both the jenkins-bot user and my own account 'hashar'. While submitting a new patchset or posting a comment: nothing is reported.
The end effect is that no jobs are triggered in Jenkins.
--------------------------
Summary (13/12/2017)
The sshd daemon (Mina) would lost connection on one way connections and hitting some kind of timeout. That affected Zuul which idles with a `gerrit stream-events`.
Gerrit sshd.idleTimeout got set to 10 days as a workaround https://gerrit.wikimedia.org/r/#/c/58126/
Gerrit patch:
https://gerrit-review.googlesource.com/c/gerrit/+/44472 ([[ https://gerrit.googlesource.com/gerrit/+/79b91bfe746121a81a785bdd3b24df2096410c55 | 79b91bfe ]]) is the Gerrit patch.
",48917,-13,Medium,True
-3.603088799838025,-0.9860087610053103,0.7000066969146523,2.453255306844579,3.0893415413415872,6.169550790056724,1.153806007954163,-2.375703670260352,3.202784360409775,0.0032915141189118202,1.2108478390218882,1.0102252656249602,0.7844627411778013,0.06387374232256793,2.1807877256837074,1.4433749077292757,4.149485974933152,2.175877555145255,False,c1,1,"All HTML preservation should be changed to store the full HTML of the node/annotation and use the HTML store. This means removing the html/* attributes from nodes, and the strange things (original tag name and attributes) we put in annotations.
--------------------------
**Version**: unspecified
**Severity**: normal",48618,-14,Medium,True
-3.894456197398463,4.714453097087887,-2.983760296717696,0.0674207568238232,-5.335680786048254,-0.1367741795225884,-2.3491441694400876,4.006606947274579,4.052904204390729,-0.3714255231086172,1.4984679978395987,0.5740113985290172,1.7439148057522798,-3.129521602406582,0.04845996596850721,1.5416932655031776,0.25289458420667765,-0.15123120749237007,True,c1,1,"Though T41598 will mean that VisualEditor will be able to edit infoboxes as they are now (alongside other templates), in the near-future Wikidata will replace a great many of the entries in these infoboxes with Wikidata queries (syntax still to be locked down).
For the VisualEditor to be truly useful for users in this context, users should be able to:
* add, review, modify and remove references to existing Wikidata queries;
* add or amend arbitrary Wikidata queries for the above; and
* do so in both VisualEditor-mode contexts (paragraphs of text etc.) and wikitext-mode contexts (like the template dialog as it will initially be).
--------------------------
**See Also**:
{T41598}",48521,-15,Medium,
-5.025431859380632,1.6080464777780286,-3.1707557937286683,-5.190183308855466,-0.7663654581608969,-0.7778989047404363,2.210458139302557,-0.10605747796127313,2.5271577147553144,4.069276119376029,0.4026679045046251,-0.05162195711735729,-1.7752639114665376,3.5948494580717263,-0.4457241058071393,0.3627240936164957,-0.7938549050818199,-0.9497303434662221,False,c1,1,"* Make toHTML() return real DOM nodes, we don't need the weird construction for CE any more
* Pass in the content so it's possible to have rules like ""if the annotation only covers whitespace, strip it""
--------------------------
**Version**: unspecified
**Severity**: normal",48464,-15,Medium,False
8.051639881539824,-4.696994447607647,2.062874386627602,2.540565438377059,-0.909213602785979,-0.47890683099272924,0.6300500409512182,-0.6020535805067981,-0.4070155008064166,-1.0620045516026062,-0.8801272351680463,0.7141343639300328,0.8544907547456195,-1.3204965671458435,-2.967627231449767,-0.8892794650703411,0.04161964818311126,-0.17343138166991312,False,c1,1,"Steps to reproduce issue:
* MediaWiki + VisualEditor (no Parsoid)
* Edit page (dims the page while loading)
* Error pops up (parsoidserver-http-curl-error)
* Cancel
Expected:
Page undims.
Actual:
Page still dimmed.
--------------------------
**Version**: unspecified
**Severity**: normal",48456,-15,Medium,True
-2.7469952001999136,-4.969938326021396,0.3804007336444464,5.006594960110049,3.0762890465794466,3.852755487059923,-7.472439350392982,-0.7742934663165132,2.3482579766391734,5.774501815208136,1.5152328753721034,-1.2378256025826015,-5.370406905208768,1.5004784063016823,1.4562334719712737,1.161558341440188,3.6111607942396198,-1.3885973401239564,False,c1,1,"1. Load the 'aliens' example document.
2. Place the cursor in front of the first 'Lorem' and hit the link button.
3. Observe the exception
--------------------------
**Version**: unspecified
**Severity**: normal",48246,-16,Medium,True
0.39804463859155437,-0.8420388955860094,0.9986726982233733,-1.4228915874200974,2.2332303068689168,-0.8917227571635896,-0.9557476934754847,-1.41223826114117,3.025992184641062,-0.5199724922108331,1.8243381369654288,3.1101569416074852,0.5980353374968823,-0.894214563924554,-1.7713726751415746,-0.4772321855123366,1.5537627747560394,0.5851049917283901,False,c1,1,"**Author:** `lukebenes`
**Description:**
I see from [http://en.wikivoyage.org/wiki/Wikivoyage:Accommodation_listings The Accomodations Listing suggested style you want people to continue to use the wikitravel tags. But I do not see any tools to automate the process.
If you look at the Add and Edit Listing Feature listing like those that can be found [http://wikitravel.org/en/Wikitravel:Small_city_article_template#Sleep here] and [http://wikitravel.org/en/Trat#Sleep here]? You'll see there is a tool to edit these tag.
This tags is extremely useful to organize data and make quick edits. For example, I have fixed many incorrect phone numbers and addresses using this helpful tool. Please consider adding this feature the MediaWiki.
--------------------------
**Version**: unspecified
**Severity**: enhancement",48225,-16,Medium,False
-5.427559003122356,-4.099400417273298,-6.516106284059342,-1.2421650687521588,4.949696375557851,-5.895239176670881,3.3211480989970736,0.9733639076989987,-2.720492520536564,0.9746650507098922,-1.0188601599490643,-0.10312829268713997,-0.6872542903504879,-0.1908907114508107,-1.2824764965032527,2.315175830903164,2.390960391268397,0.9091856560825977,False,c1,1,"Some events are undocumented (like ve.dm.Surface.prototype.change, which emits multiple events but documents none), most have the event name without quotes, but some have single quotes (ve.dm.Surface.addInsertionAnnotation) or double quotes (ve.ui.Toolbar.prototype.onContextChange). Parameters sometimes are documented and sometimes aren't, there's no clear distinction between ""parameters aren't documented"" and ""there aren't any"", and in no case do we document the types and descriptions of event parameters, we only ever document their names.
We probably also don't document events with @event nearly as often as we should. It's a huge mess.
--------------------------
**Version**: unspecified
**Severity**: normal",47872,-17,Medium,True
-5.4123299916425776,-0.8232079957552969,-3.782009307050677,-0.7082980447597595,-2.8447193130120545,-0.5116687801682819,-1.1618797735366337,1.5430140986622933,-0.3119101803717206,1.3705689953896698,-0.40277572064908096,-0.7780726936099849,-2.227293275169173,-1.2575202978831639,1.4407607817377777,-0.2733088354341192,3.0229193076847825,1.7607298420586035,True,c1,1,"Right now VE is either 'default' for some given namespaces, or enabled but only exposed by user preference for some namespaces; it should be possible to have a mixed-installation for testing/etc.
--------------------------
**Version**: unspecified
**Severity**: normal",47871,-17,Medium,True
-4.394536028203541,-4.332918515509773,-1.8022443605110787,4.293990037105493,2.5253567628859086,-1.9313223016463845,-1.5913031798485937,1.311907572987609,-1.64966593168566,0.5067938187922563,1.551568233439101,-0.1571392547993542,0.7349669863921067,0.7210527806091811,-0.34517684424010486,0.09798110810453994,-0.28314151124973974,-0.7375416876997365,False,c1,1,"Start a list item and type 'a', now hit shift-enter and type b.
Expected diff:
*a<p>b</p>
Actual diff:
*ab
The paragraph created when you create the list has internal.generated = 'wrapper'. This property gets copied when you split the list. Two wrapper paragraphs next to each other apparently get merged into one.
The only way wikitext can have two paragraphs in a list is with HTML so extra paragraphs must be full HTML paragraphs.
--------------------------
**Version**: unspecified
**Severity**: normal",47710,-17,Medium,True
1.2190759799254143,-2.959639813274201,3.8080365472225672,0.7005340421948207,-0.4348625481010468,-1.9786661643070098,1.4275764087558889,-0.9080722333648877,1.7591621054600297,-1.9677082702687176,-2.465518935710417,0.40984038261741973,-1.849894705943984,1.3226508964415924,-1.4303778859381397,0.3143490831193542,-0.11475391439712146,0.6289002295192267,False,c1,1,"Create a list of supported browsers and document it.
Also make sure that TUX actually works with those browsers.
--------------------------
**Version**: master
**Severity**: enhancement
**URL**: http://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix",47602,-18,Medium,False
-3.6383851081156746,-13.015162022955732,-7.377125468641751,-2.6223756528147404,2.8324212035226113,-3.427342095234957,4.53177524293701,7.197776480923099,-0.3497047900080416,-0.5689338814403202,-3.1579056750805625,1.702423558482914,-2.5420149012139257,1.5866013605886442,-1.2613951329797413,2.971057491641804,5.3518668720396585,1.2176969984112944,False,c1,1,"unwrapNodes & rewrapNodes are not implemented, and wrapNodes doesn't calculate selections correctly.
--------------------------
**Version**: unspecified
**Severity**: normal",47445,-18,Medium,True
8.339089713268601,-7.865556464694053,-5.590441902539201,-8.908823879287187,5.3737032878057445,-3.5585273050709842,4.356542146844261,1.7983569052584998,0.019734553049234438,-1.3699666244103401,-0.8732051587905167,-2.783193724042687,-2.168096194145633,0.9696306856316621,-0.4829440821756368,1.7009972992271556,-1.6361617630912617,3.1612379815726896,False,c1,1,"e.g. https://integration.mediawiki.org/ci/job/mwext-Scribunto-jslint/233/checkstyleResult/file.984307183/type.1174449419/
It does that almost everywhere (including VisualEditor and MediaWiki core). Sometimes it does work though, weird.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",47395,-18,Medium,True
5.118004169836357,-6.985885743869238,-2.97748187281209,-4.046740702794108,-1.2899809155459927,4.093331701543215,3.2726335268182067,1.6733175847206323,1.4796480795896239,2.724821914474526,4.479064209711545,1.4144464294625998,1.2857057916022305,-1.1534357059152094,2.675273673266381,-0.2346150819286923,-0.09684404375884248,-0.4814694643985775,True,c1,1,"MW-specific code should be split from the VisualEditor itself; mediawiki/extensions/VisualEditor.git should only be the MW-specific items (integration; MW-specific plugins; MW-specific plugin overloading).
Target repository for VE itself already exists: VisualEditor/core.git
(Future plugins should be under VisualEditor/plugin/….git.)
--------------------------
**Version**: unspecified
**Severity**: enhancement",47342,-18,Medium,False
0.07061181791344984,3.0607965578570777,1.1806125330870287,-0.9520621401367124,-4.448796377016905,-1.2625333566055652,1.4723613227983074,0.13448854544154076,-3.948708416207265,0.24079937686179065,-3.93276158019607,3.381211402718134,-2.0696633057035143,0.18919277703185777,-0.524788285057527,2.329114202266646,1.087780734129215,1.1538725697329386,False,c1,1,"* Rules for ""heading should not be in list"" in CE rather than DM
* Function that isolates and unwraps things until they conform to the CE rules
** FormatAction does these things, but is hardcoded for lists
--------------------------
**Version**: unspecified
**Severity**: normal",47247,-19,Medium,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",47246,-19,Medium,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c1,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",47242,-19,Medium,True
2.022044506473518,-5.154688869325316,-0.5273035505890764,-0.01997549107553165,-1.2043854498428201,0.6021876289349513,1.8120503202013287,-1.1349606113121007,0.1549861011058381,-0.8168356685884763,-0.2864604602759404,-0.8050165894217438,0.6605077986303898,0.4039539209614178,0.8454613907290796,0.9682357426018262,0.822407415414274,-1.1989000510188659,False,c1,1,"**Author:** `visionary.incident`
**Description:**
I cannot input japanese consecutive characters in the beginning of the line.
Firefox version is 18.0.2 .
For example
inputed
あああああ
outputed
ああ
--------------------------
**Version**: unspecified
**Severity**: normal",47240,-19,Medium,False
6.309813455093673,-9.070258234852911,-4.6592692608331205,-4.543711339913302,-1.515118821365254,0.1211567007999872,2.6092052961625685,-2.107615572937417,-1.5145169878283384,-0.8494110462446187,0.13548714541625229,-1.765562602910562,1.3990235780031939,1.597865553118524,-0.19319632358871264,-0.6096972221943225,0.05749450375108012,-0.06516275424732143,False,c1,1,"We currently have 0 tests for ve.FormatAction.*
--------------------------
**Version**: unspecified
**Severity**: normal",47216,-19,Medium,True
4.398439414592131,4.463823939519433,-3.2054172941621477,-3.8516990925872214,-5.026687158924782,-0.5855744348506582,-0.06976873056714261,1.7818255583199512,0.575298140467347,1.7174196638407064,-3.0313451189725207,-1.6479041858745473,-1.232111323454391,0.8534764286374861,0.27360340967894636,-0.06305571749427935,2.3607069923411546,-2.580041384434822,False,c1,1,"In ve.js, function ve.msg:
// TODO: Fix dependency issues between ve.js and ve.init.platform
I don't know how this should be fixed exactly, Timo put this comment in in 407de829dd8f2e51c22a8378dc70c79fc6645d1e . I did notice that running the VE tests from Special:JavaScriptTest doesn't work because ve.msg() errors out with 've.init.platform' undefined.
--------------------------
**Version**: unspecified
**Severity**: normal",47175,-19,Medium,True
-1.840746352875021,-0.8237052805945737,-3.6646344227963326,4.0620818451108445,0.9594306960033954,-2.1149380231814723,-1.9878258481636637,-2.6899683999600144,-2.75086697708445,1.318988870948128,-2.680081331990934,-0.05920537326595965,2.0436474049854407,0.05174376608215159,1.1311680293605715,-0.22595332356206266,0.023969693128005787,0.002260808873213005,False,c1,1,"**Author:** `kevinrose`
**Description:**
I am running under IIS with the files stored on network storage.
I get an error from line 1142 in includes\AutoLoader.php when the $filename being passed is already a network share. Specifically in my case it then adds $IP a second time.
Here are the variables from my situation:
From debugging we know that:
$IP is set to ""\\server\share\mediawiki""
The offending class being loaded in LocalSettings.php:
require_once(""$IP/extensions/WikiEditor/WikiEditor.php"" );
After line 1142 $filename = ""\\server\share\mediawiki\\server\share\mediawiki\extensions\WikiEditor\WikiEditor.php""
Line 1140 checks if the first character is a / (root), or the second character is a : (windows local drive).
To work around the problem I added a third check, that the second character is a slash (windows network share):
if ( substr( $filename, 0, 1 ) != '/' && substr( $filename, 1, 1 ) != ':' && substr( $filename, 1, 1 ) != '\\') {
--------------------------
**Version**: 1.20.x
**Severity**: normal",46953,-20,Medium,False
-5.169785071691339,-2.172625028200324,-2.777659690073765,-0.43230768881690185,5.922660347536102,0.16384398267466338,1.948224734680812,7.840782565394453,0.6717177272570264,-1.51830308662952,-1.958089656574505,-5.956199441512061,-4.461205643809223,3.3750370532078033,-1.254395260594933,-3.0373104508020345,0.2745940503007531,-0.026705460242029355,True,c1,1,"[Very much a longer-term enhancement.]
Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).
--------------------------
**Version**: unspecified
**Severity**: enhancement",46483,-22,Medium,False
-0.45134366705082263,-2.920958940562585,-0.7994770324178333,-1.3103384039492871,1.7719902279220667,0.32037059663043466,-0.3338440301519441,1.8902029791431216,-1.6834919224970937,0.52506898280265,1.2520551008117473,-1.3156391895769524,0.3315840895147768,-0.6968950222136163,-0.9490677563687546,-2.3553294163789817,-2.038100438589804,1.0341480487104204,False,c1,1,"Deleting multiple lines of selected text
When trying to delete a line of added text, the editor failed. See screenshot.
When reviewing the changes I get an empty ""Latest revision"" and empty ""Your text"". Tried with Chrome and Firefox. When saving, the changes are not committed either.
When trying to delete two lines (see screenshot on the right side), only one line is marked for deletion:
- Mostly active on [[:bs:Korisnik:Edinwiki|bs-wiki]].
When selecting multiple lines in the same way, it seems that each time only the first line is selected.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/wiki/User:Edinwiki
**Attached**: {F10938}",46340,-23,Medium,True
-5.007369416325637,-1.8910448235920878,2.58312195113513,6.107466856788648,-1.3167434915471206,-2.7013637274825992,-1.8644057387263784,0.4065709005730882,1.0540475074542839,-2.7934317397333883,0.6457935126590146,-1.0126880633300794,1.3441966628523163,1.8524507975815414,1.6129809741561498,1.0118763119763847,1.5085938676387134,0.6323407176512232,False,c1,1,"1. Type 2 spaces
2. Move the cursor between the two spaces
3. Press link button or (command|control)+k
4. Type text for target (if in mw integration you can also choose a suggested target)
5. Press enter (or click outside the inspector, or press esc)
6. See that the target text was inserted, but not annotated
--------------------------
**Version**: unspecified
**Severity**: normal",46086,-24,Medium,True
-7.547593970291132,-3.118342562405738,-4.01663468428452,4.307618794257566,1.979617138548131,1.827089310696665,-2.541332914469123,0.588201379007883,1.180937395856868,-2.3373380772661663,0.43649316916238234,-1.1943704004743947,2.1242297511984822,-0.026993885035829557,-1.1820637131801703,-0.4141219390657549,0.3767296711858774,0.7524327441890246,False,c1,1,"Steps to reproduce:
1. Find a paragraph that has an inline node (alien or entity) in it, but not at the end
2. Move the cursor to the end of the paragraph
3. Repeatedly press backspace
4. When there is only one remaining character after the inline node, pressing backspace will remove that character (correct) and move the cursor to the beginning of the line (bad)
--------------------------
**Version**: unspecified
**Severity**: normal",46078,-24,Medium,True
1.1973270348356428,-1.63526769064433,2.6481864841604192,-0.09326866161069403,-0.4665092177808904,2.872808582995588,2.2809236415424463,-1.891310969555947,0.9309271226012745,-2.3013446860427327,-3.3166463166704463,-0.8343980265328912,-3.3616803597590144,0.1398331572935918,2.740452365257851,1.0650683015764666,0.7557426070660604,0.18365055584159173,True,c1,1,"Some extensions, such as Extension:GuidedTour, require git submodules.
It would be a very useful enhancement if ExtensionDistributor included these in the download, by default or optionally.
--------------------------
**Version**: master
**Severity**: enhancement
**URL**: https://www.mediawiki.org/wiki/Extension_talk:ExtensionDistributor#Doesn.27t_do_submodules",46022,-24,Medium,False
-3.1376701597827776,-1.5804175105411336,-2.590652387927289,-2.0486973950736997,0.7895935004520678,-1.437077426765084,-4.71533353467579,0.45183784087330536,2.4062438381038334,1.8928549362881721,-0.579962772944481,1.301845654841771,2.1191731023973857,-0.8230546104536849,-0.09269329455999475,0.009077131890711188,0.48270165435031,2.009587915554169,False,c1,1,"Steps to reproduce:
1. Open VE on a page
2. Make changes
3. Stop Parsoid
4. Click ""Review and save""
5. Get an error dialog about Parsoid being down. Click ""Cancel"".
The box that's supposed to show the diff is left empty, but the ""Something's wrong"" and ""Looks good to me"" buttons are still there. I can dismiss the box with the up arrow to go back to editing, but we should be doing this (or at least *something*) automatically on failure.
--------------------------
**Version**: unspecified
**Severity**: minor",45753,-25,Medium,False
-5.391988786178536,-0.804998868377675,-3.990501596840435,-1.7226201668561405,-2.388083327892602,0.10853997401022042,-0.6682078114799719,3.455034298973637,0.4477162578569578,-3.271364861576306,-3.233552323948065,2.9424432413890633,0.0994490226784901,-3.127976100666131,1.064496067200852,1.0730332463973087,-0.00998251797871541,-1.3207983896082616,False,c1,1,"Editnotices for pages are not currently exposed in the API, but are expected to be used by any interface of a Wikipedia editor. This implies that the information should be easily retrievable.
It should be noted that the VisualEditor api has it's own private implementation of listing all edit notices that should be presented to users: https://en.wikipedia.org/w/api.php?action=visualeditor&format=json&paction=metadata&page=List_of_emoticons&uselang=en&oldid=846338965
This should probably be moved to core as well as be exposed via restbase or something similar.
--------------------------
**Version**: 1.21.x
**Severity**: enhancement",45683,-26,Medium,False
-4.976798424962956,3.201676684626925,3.313799202154925,3.458973451146683,-0.30157802436175557,-0.8329876254805415,0.5644337359509777,0.8078148029577427,-0.49595021446978704,-0.5954020897561385,1.432508563367049,0.7186678777186841,0.538087785194362,-0.9470977441068511,-1.0446210574586257,0.62468485295686,0.7526117837273751,-0.9149402664790591,False,c1,1,"The Translate extension has very nice info icons which bring users from the interface/feature they're seeing to the relevant (translatable) help page on mediawiki.org (all components are documented). See for instance [[ https://meta.wikimedia.org/wiki/Special:PageTranslation | m:Special:PageTranslation ]].
This is a huge task, but it should be done for core as well.
The problem is of course that there's no real(istic) plan to get such help pages done in the next few decades, as they continue to live either on Meta for copyright reasons or even on local wikis for the same + [[ https://meta.wikimedia.org/wiki/Not_my_wiki | m:Not my wiki]] syndrome. This part of the problem should be discussed on wiki, probably the talk of the project.
--------------------------
**URL**: https://www.mediawiki.org/wiki/Project:PD_help
**See Also**:
{T19557}
{T14306}
{T46286}",45591,-26,Medium,False
3.935528883448572,-8.21341455179445,-2.1045318653233753,4.4860834078306375,0.05848312201622996,-0.9666421147553665,-1.8209442920830936,-0.25618470426278667,-0.4879681861262147,-1.061635993972144,0.9894039128457766,-1.21031531022502,1.0110933685630004,-1.7134344722567718,-2.000946561751296,-0.37663822872518227,-0.434887350407668,-0.4864395824799468,False,c1,1,"Screenshot of bug and edit screens
Native parser rendering:
the Netherlands
Parsoid/VisualEditor rendering:
style=""font-size: larger; font-weight: bold"" | the Netherlands
[[Flag of the Kingdom of the Netherlands]]:
{{Infobox flag
| Name = the Netherlands
...
[[Template:Infobox flag]]:
> {| class=""infobox"" style=""width: 22em; font-size:88%; text-align:left; line-height: 1.5em""
|+ style=""font-size: larger; font-weight: bold"" | <br>{{{Name|{{PAGENAME}}}}}
|-
...
See attachment for rendering.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10351}",45582,-26,Medium,True
-9.992271596595685,5.420396978966611,-1.2169606566121445,2.816628807835658,3.374891274091889,6.909647419117781,1.4887594225293412,2.4331720137142923,-3.9185275042199725,-2.4546619292601664,-2.3830648345201695,-0.09819310192017139,-1.0823983911853823,1.1884433861035104,-0.059118229969651104,0.055221871433320524,1.4157532377580007,0.44532752367396244,False,c1,1,"Hovering over an uneditable element in VisualEditor makes the element be covered by green stripes until the mouse is moved away, but when the cursor moves directly to the sidebar or the right margin, the stripes stay there until some part of the .ve-surface is hovered over.
--------------------------
**Version**: unspecified
**Severity**: minor",45461,-27,Medium,True
-2.9518539440124063,3.196534912450911,-2.1079846675935876,-3.3188763000640322,2.6501059056191822,-1.1499463243797474,1.351809368841077,0.317786155189124,-1.933490639091883,-0.33093458674081067,0.9174691958202112,-2.1302740566272615,-1.0289758440288743,0.09489690202518641,-1.3494277581454934,1.3651072619454907,2.3330955512722564,-0.3317253929187989,True,c1,1,"From user report (but I've had this myself):
| HotCat is a popular gadget and any conflict with it should be avoided. For
| example, use VisualEditor on [[User:This, that and the other/sandbox/Schfoof]]
| with HotCat enabled. The HotCat bar appears in the wrong place. (It probably
| shouldn't appear at all.)
|
| …
|
| The conflict now appears to be fixed... very strange.
Given that it appears and also doesn't appear between refreshes - i.e., on the same page with the same version of the VE and HC code bases in the same accounts in the same browsers - I'm assuming it's some sort of race-condition, but I'm not sure.
--------------------------
**Version**: unspecified
**Severity**: minor",45335,-28,Medium,False
-10.253274078945092,4.937646159287716,1.0008423374687254,7.119300060892234,3.2900991642586943,1.808627045660548,2.772952161122052,2.4679126222497887,-0.17128842362931906,1.03467637505722,0.2735743063713807,-2.3048303516535023,-0.4596499536300733,0.29385658928481373,-0.8126416048142655,0.2743574767369935,1.3159744936399147,1.0493900982962983,True,c1,1,"From a user suggestion:
| Normally word processors and text editors have a left margin, allowing
| whole lines to be selected. There would normally be a small gap of a few
| pixels between the left column of text and the left margin, allowing a
| ""margin of error"" for regular text selection. To the left of this gap,
| any clicks select entire lines, and any drags up or down select many
| lines at once.
|
| I don't know if there is a need for the complete left margin
| functionality in VisualEditor, but certainly, the editing area shouldn't
| stop at the exact edge of the letters. Perhaps the padding on the VE
| container needs to be increased with a compensating decrease in the
| margin - or maybe that's totally wrong, but you get the idea.
--------------------------
**Version**: unspecified
**Severity**: enhancement",45333,-28,Medium,True
-3.5639737525464668,-1.6727820661195842,-4.448979877755038,1.8091441337924907,2.0395356312205095,3.198815179603036,-2.1706398457679827,-0.18110026810351226,-2.5787578917238605,-0.5197655983197489,-2.371077739243365,3.2478282672709042,0.9870311452525669,-1.7610517688521545,-2.4531945669873645,0.6647836958067668,0.8026018331289515,1.2987902691378583,True,c1,1,"In https://en.wikipedia.org/w/index.php?title=Lynn_Hill&oldid=528045441 (and other versions), go into VE, go to the bottom, delete the list item (and so the list) from the External links section.
ve.instances[0].documentModel.data confirms that the model has this removed - ""/heading"" object followed by the alienated table from the ""{{Authority control}}"" template - but on diff Parsoid thinks that there is no change in this area. Is this is a Parsoid, or is change marking broken (or both)?
--------------------------
**Version**: unspecified
**Severity**: normal",45135,-29,Medium,True
1.1628959498904572,-11.809106207659742,1.1375678687544237,4.517520108366222,-2.9410273924581416,-1.5224231392512306,0.5108005203543344,-0.8022382408261886,-1.7115201202977237,-2.2944300496378855,1.2765447537307346,1.7537821814674281,-3.20742679009816,-1.4029078240552786,0.2296658135338685,1.8234364169869817,0.3720720877851378,0.030165927599272502,False,c1,1,"<imagemap>....</imagemap> is unparsed but shown as plain wikitext:
https://en.wikipedia.org/wiki/User:Raymond/imagemap
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/wiki/User:Raymond/imagemap",45127,-29,Medium,
0.9743376383895952,-2.1791486467323526,6.629934855875206,4.682259405173348,3.153292527314643,-2.2112047227845926,-0.5767772564650686,-1.503974722567074,-2.6236251140967806,-3.542406802967393,1.9846042820953902,0.5964890275604366,-5.657581373669493,1.1534325817813222,0.290942132205795,-0.5030467646953445,-1.0054495463348965,-0.7697333504779746,False,c1,1,"Support <syntaxhighlight> tag too. It is a synonym to <source> which works already
https://en.wikipedia.org/wiki/User:Raymond/source
See https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SyntaxHighlight_GeSHi.git;a=blob;f=SyntaxHighlight_GeSHi.php#l67 for the definiton of the parser hooks.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/wiki/User:Raymond/source",45126,-29,Medium,False
3.650086414838668,-5.868611493409608,7.551515455151847,3.9839608794016224,-2.3211549466980754,-0.017769679707737573,2.586396999437336,-0.7873904337354846,-0.7612682061606667,0.893040635353338,1.4915676756653098,1.774558808831315,1.6816619981503562,-1.5616597041396556,-2.9243736837890983,-1.1817998296074932,0.021214584333449693,0.7751329881731126,False,c1,1,"Screenshot showing the regular view, visualeditor view and wikitext
Steps to reproduce problem:
* Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport
Expected result:
Table has header on both columns.
Actual result:
Header of second column is missing.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F9595}",45104,-29,Medium,True
-5.139255833287204,0.9949214467840815,-4.065567775324222,-2.8356026372105925,2.7243708997840255,-0.5851585880441458,-0.9243121085737283,-1.7476036800082002,2.577411571930451,-0.6163916356161803,2.6257588734614834,0.9588317703818963,0.32678379441393623,-0.8801350756817197,-0.4605220477116383,0.3765867806144713,-0.0473158992802889,-0.5556319507051093,False,c1,1,"Try editing the page [[:en:Buri_Ram_Airport]] with VisualEditor. Mouse over the infobox. There's an element that sticks above the alien marking, because it has a z-index attribute.
I don't know how best to fix this, I assume it would be bad to simply set z-index=1000 and be on your way, but it's an inconsistent appearance and something to be fixed eventually.
I suspect this may also be a good beginner bug, so if someone from the VE team can mark this as easy, then we can leave it for a newcomer.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.org/wiki/Buri_Ram_Airport",45098,-29,Medium,True
14.241534888606914,1.058352906622316,-0.1674705503717675,-1.6544928944520993,-2.7888965448913363,6.866501874404837,7.013767174933315,4.72264388073516,-6.02291181762232,7.120160218569408,9.52903865345794,-1.3565321186668515,6.286576875778405,-2.2628586796767736,1.650951115992786,3.777070925530598,-0.30881906527511993,0.6560295561121945,False,c1,1,"Math is editable, but only as plain LaTeX like in the wikitext editor: https://en.wikipedia.org/wiki/User:Raymond/Math
{F199473}
Figure 1: Current non visual visual editor",45058,-29,Medium,
-8.490809080660334,2.2513283484797917,0.4174222492811914,6.099468665359258,3.6919221423554487,-0.4144013049744695,-1.0063442907740159,-2.5254928986997194,2.2159393166309966,0.1609365333300561,-0.44918773003770207,-1.8690983537630135,0.94797075976948,0.19802640678330974,-1.3392067679773598,1.2723345549594018,1.8853934224531772,-1.2495350854589076,False,c1,1,"**Author:** `jnichols`
**Description:**
I can only see the very top few lines of the review-and-save window, the notices window, and the edit summary window. The rest of them seem to be behind the article window. I can scroll down the review window, looking at it three lines at a time in the little area between the top of the article and the tabs. The notices window and the edit summary windows don't scroll, which means I can't get down to the final ""save"" button.
--------------------------
**Version**: unspecified
**Severity**: minor",45054,-29,Medium,True
-1.6835283029665464,-3.9666925313062364,7.682243208989721,2.137617183096785,-0.3364047654589566,6.416227423245032,-0.17831420327089553,-1.3949551784675798,2.250092153045941,0.1283780832789967,0.1565119309194185,-1.6494245910453942,-0.010531075318063188,-0.1916026910717612,-0.7915337338319315,3.097274521212004,0.6560026350576884,0.3100323140610912,False,c1,1,"See http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Marking_edits_as_minor for the report and http://en.wikipedia.org/w/index.php?title=Ginger_nut&diff=527654509&oldid=526997552 as an example.
--------------------------
**Version**: unspecified
**Severity**: normal",45040,-29,Medium,True
3.485951776295719,-10.141392935121342,1.9826378957053024,-2.8594800541649565,4.899687302895014,-3.8584209714038655,-0.27904857609370914,1.1122212856993006,-0.18009123906744576,-2.2273211490049287,-0.7272978229054523,2.4586153130808848,2.616318928083329,0.7323062797900279,-1.019541059315495,2.0354912478360996,-0.6650680616584165,0.5903627309084827,False,c1,1,"There is only one notice, but it says there are 2!
See the screenshot and also
https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=527687053&oldid=527683727
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61335
**Attached**: {F10115}",45013,-29,Medium,False
1.5652237015215635,-10.83976823373765,5.498329476198453,-0.9297875799160786,-3.3048584149600337,6.14701024448128,1.9777556829252196,-2.498219044581561,0.5814843887535052,-2.2482496491960755,-3.943359536011524,-0.6288658444203593,-3.5504885328417464,1.028396995497297,0.8698646671153663,-1.4858819122120008,2.3562271038948195,-0.5695806692596546,False,c1,1,"Like this: https://www.mediawiki.org/w/index.php?title=VisualEditor:Test&diff=615802&oldid=615801
--------------------------
**Version**: unspecified
**Severity**: enhancement",44986,-29,Medium,
0.6560337403787093,-0.5806749208129514,-4.149727094131459,-10.364296692385095,2.5855490986245186,0.0792485788966617,2.350254480009558,-1.2250425052081764,-3.2872277315335445,3.9741008805237517,0.44399371795076004,-0.6948475822122522,-0.5591316196821365,1.6608033867810539,-2.862081880435652,-2.872756354164956,-0.35166302348293654,4.063745675324611,False,c1,1,"When I'm using VisualEditor, session failed for unknown reason. The VisualEditor then keep asking whether I want to try again but it always tries with the old token and error ""badtoken"" keeps coming.
--------------------------
**Version**: unspecified
**Severity**: normal",44984,-29,Medium,True
-3.9190952987647005,-0.9172890210898803,-3.1474901702652964,-1.3068548775763729,3.903265534387279,1.7394115581523535,2.371235615973915,3.4207471782437,-2.130648631196833,0.6795245419422358,0.11815918977545925,0.24766847199412068,0.31746060249933317,-0.6156763541883903,0.6465692550523583,-1.1071255173154049,-1.1063873127817136,-1.5264586103114701,True,c1,1,"Right now, the Save button starts disabled, but when the transaction depth is non-zero it's enabled. This means that two actions that reverse each other (rather than being formally undone) let the user make a 'null edit', which MW then silently accepts.
Ideally, the Save/Create button should be disabled if dm state is identical to page when it was loaded (except for the special-case of oldid pages, where it should always be enabled). Roan suggests a string comparison of the current and original HTML is the least-bad option, given the lack of hash functions in JavaScript.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43270",44939,-29,Medium,True
8.873202390030155,-8.144807742129348,9.397378482281699,2.2970540730926787,-1.7792529013059928,0.7685559611664203,1.410587762800903,-0.9553999184124172,2.9034589090138683,0.31288525023776437,0.12340591218532282,1.1577768009860183,-0.12838709017043293,-0.8699857261349182,-0.45448289800064146,-1.2259907378488257,0.772034639573506,-0.6629666105233187,False,c1,0,"Try to VE-edit this page: http://www.mediawiki.org/wiki/VisualEditor:Extension:ConfirmAccount
Compare: http://parsoid.wmflabs.org/mw/VisualEditor:Extension:ConfirmAccount
--------------------------
**Version**: unspecified
**Severity**: normal",44897,-30,Medium,True
0.44806706072611524,3.369828586171625,3.216812655753575,4.86454820913712,-3.4746320836556124,3.5561438189112,0.28397845503184804,-0.20345210845211426,1.546407978352595,0.6078629612208788,1.39966045521432,0.5873960249541386,2.0815549007116823,1.1691745185491254,-1.1177541294225115,1.7664088318651747,0.6569394918854663,0.022681493954627596,False,c1,0,"Steps to reproduce:
Edit a page with VisualEditor.
Press return key a few times.
Select those empty lines with mouse or shift+arrows.
Watch in awe as the selected lines decrease one per polling interval.
--------------------------
**Version**: unspecified
**Severity**: normal",44801,-30,Medium,True
-2.6074633660482345,-3.9550810380054706,5.69390967021787,3.2278244391615436,0.7334820455242339,4.03297338364357,-2.831489353357201,0.4263044737284948,1.0950877029528903,-0.5194371409984466,4.244789287007261,1.7101693512491398,1.4918486241998012,1.639706824697357,1.5709218510710867,0.34785491513325023,1.6627778685864738,-0.09561556680122374,False,c1,0,"Reproduce:
1. Make a link to http://www.google.com
2. Click out of the link
3. Inspect the link
4. Both new page and external link are selected
--------------------------
**Version**: unspecified
**Severity**: normal",44665,-30,Medium,True
-8.101470044400056,-0.7964624060154115,-2.170289860669179,0.5081148654657255,3.5228768809578788,12.83988779306422,0.574608730245691,-0.15662092003207306,3.5167292658596034,-0.5515536969898163,-1.0222517382293765,-0.8312344270163574,-2.655522247687273,2.895013711781421,1.7501772152848405,-1.5013834149790972,-0.9205308363858364,-0.7164958292997121,False,c1,0,"When a document starts with a link, the animation on the page cause the context's location to be incorrect.
--------------------------
**Version**: unspecified
**Severity**: normal",44661,-30,Medium,True
2.412128624925366,-16.959765250364036,3.8734178164902353,2.0645510978340043,-2.0320540649073333,3.0306175551290853,5.235389208997927,-1.4391340410100049,0.6232125295312069,1.3830397040905495,0.85978318546299,-0.6635763096340714,-1.1633477032329944,-0.011350188389093852,0.5331305553380874,-0.5160785717085714,0.2982228827735709,-0.05478655315618952,False,c1,0,"https://www.mediawiki.org/w/index.php?title=VisualEditor%3APre&diff=609875&oldid=609874
--------------------------
**Version**: unspecified
**Severity**: normal",44469,-31,Medium,True
-2.3186672312642136,1.0730641572961055,3.14187164257995,5.173370871516105,2.2253919181963537,0.305097084069077,-2.417892973514291,-0.9325470933397236,-2.3127696462349134,2.567487693772298,-1.5193496125072758,3.4578158190361385,0.18509434951255788,3.027489786862165,1.7231287054034938,1.9281711975031717,-0.6194607875421113,0.9378382754538477,False,c1,0,"1. Type the text ""Foo bar baz""
2. Select ""bar""
3. Click the link toolbar button
4. Click between the a and the z (""ba|z"") to cause the inspector to close
5. Press enter
Expected result: paragraph is split with ""z"" in a new paragraph
Actual result: ""bar"" is removed, paragraph is split with ""baz"" in a new paragraph
Occurs in both Firefox and Chrome. Isn't reproducible 100% of the time.
Theory:
1. User changes selection to ba|z
2. SurfaceObserver notices and adjusts its selection
3. Link inspector notices and triggers annotation on a fragment with a different range (the link)
4. Some bug in SurfaceObserver or SurfaceFragment causes SO to believe the current selection is now the link
5. User presses enter, SO removes what it believes is the selection
--------------------------
**Version**: unspecified
**Severity**: normal",44278,-32,Medium,True
-7.418725799513393,-1.6436929975199224,-4.174001367738557,-3.0273394265698412,-2.2751221649955,-1.704662594382766,1.5246393793984172,2.1119942837821117,0.2620634581673901,-3.2698258833767766,-3.386914750306133,-3.61433805467406,0.10557362060364639,4.608690478357561,0.6552084333723007,0.36394274616923594,2.4917882577801134,2.5555190673410424,False,c1,0,"This currently works for selections within links, but not for zero-length selections. Except if you hit bug 42275, then the inspector icon will appear on every zero-length selection, anywhere, and will chase you forever and ever.
--------------------------
**Version**: unspecified
**Severity**: normal",44276,-32,Medium,True
-6.118454591853126,1.6840931524714051,-2.3641235650015293,1.6745172355278335,7.415067058351951,0.770127908761872,-0.9545082560905236,2.202921457682647,1.9862569194186495,0.29104182279476376,-0.8789737030145277,0.6124036069823835,-0.07750656197090233,0.5533589189735384,-1.252902077206972,-0.6036666571445375,-1.2766550722956174,-0.48207017728233903,False,c1,0,"The VisualEditor interface does not currently recognize page protection. If a user visits a protected page (a page to which he or she does not have access to edit), VisualEditor will still display a working edit form and the first click of the ""Save page"" button will work. It will produce a dialog box that will present a second ""Save page"" button that does not work. Ideally, VisualEditor would not let a user get this far without indicating that the page is uneditable.
Related to this, there's no warning for administrators that a page is protected when they're editing the page. This may be a separate bug, however.
--------------------------
**Version**: unspecified
**Severity**: normal",44142,-33,Medium,True
-2.720786849577425,4.988472546440846,4.359171337958195,1.885668794048593,2.7584803939746214,-3.6707860594892425,0.37282163397545354,-4.648639291633523,-0.1685393398316452,1.6809638585487905,1.45997787227618,-0.18675002066701307,-0.7540218686797875,-0.2445855688850882,-0.585398457808413,0.5561505072712841,-0.4275257247709485,0.07235699758940783,False,c1,0,"Currently when a user uses the link dialog box tool thing in VisualEditor to specify where certain text should link to, if the user specifies an internal page as the target, the wikitext for the link will use underscores.
For example, I highlight some text in VisualEditor with my mouse and then click the link icon. A ""Hyperlink"" dialog box appears and I enter ""MediaWiki on IRC"" into the text input area. I hit the ""return"" key on my keyboard to make the dialog box disappear and now I have a blue link in my VisualEditor interface. If I then save this page and look at its wikitext source, I see:
[[MediaWiki_on_IRC|fffffffff]]
Internal links are using underscores. This is wrong.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49310",44140,-33,Medium,True
-4.9362926703535255,4.539494266687928,8.80255974639347,13.693975877015644,5.0416747967561175,0.14951296458361885,1.39897878866614,-0.6789183136118648,0.5211120162743675,1.487006046947208,0.28283741954904107,0.9408607958291892,0.11882523782914944,-0.7676133966976444,-0.48286481635393397,1.317919980308012,0.3141741948573613,-0.529936853497883,False,c1,0,"The current VisualEditor interface has a ""Save page"" dialog box with an edit summary input field. However, this edit summary input field accepts wikitext, but has no preview feature for what the rendered wikitext will look like. This is a regression from the standard (non-VisualEditor) interface.
Roan said that there be a mini-editor or mini-parser or something stuck in the edit summary area at some point.
**See Also**: {T62535}",44139,-33,Medium,False
-2.390822422848623,-3.4173518038044186,-1.9989275979470165,8.15549685788159,0.5873248547789709,-1.9971440677330148,1.672915686050164,-0.6109382836755023,-1.443629790687661,1.607059627349119,0.260613478055022,-0.5192140741035712,0.22993637593911131,-0.4749110273200614,-0.5185674878573776,-0.42789680250446815,-0.2801838874216298,-0.5716164221867222,False,c1,3,"this is like bug 46893.
$ cd extensions/VisualEditor/modules/ve-mw/test/browser
$ bundle exec cucumber features/visual_editor_bullets.feature
If the tests progress, eventually they print out a lot of
*** DEPRECATION WARNING
*** You are calling a method named class_name at /home/spage/projects/core/extensions/VisualEditor/modules/ve-mw/test/browser/features/step_definitions/visual_editor_bullets_steps.rb:81:in `block in <top (required)>'.
*** This method does not exist in page-object so it is being passed to the driver.
*** This feature will be removed in the near future.
*** Please change your code to call the correct page-object method.
*** If you are using functionality that does not exist in page-object please request it be added.
*** DEPRECATION WARNING
*** You are calling a method named select_text at /home/spage/projects/core/extensions/VisualEditor/modules/ve-mw/test/browser/features/step_definitions/visual_editor_bullets_steps.rb:14:in `block in <top (required)>'.
*** [same last 4 lines]
The lines deprecated by the former are all of the form
SOME_element.class_name.{should, should_not} match /disabled/
where the HTML has CSS class=""ve-ui-widget ve-ui-tool ve-ui-tool-outdent ve-ui-widget-disabled"". I don't know the page-object equivalent to retrieving the CSS class (attribute( 'class' ), but maybe instead the code could use page-object's disabled? and enabled? methods.
The latter deprecation is odd since the test specifically requires ""watir-webdriver/extensions/select_text""
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: gci2013 https://www.mediawiki.org/wiki/Google_Code-In#Candidate_tasks",56590,12,Low,False
-7.087066708090225,-1.065576027975153,-2.7191841835500714,2.4473723571443458,1.5937471414217805,2.540179694423723,0.8891282121305517,0.6039581840292886,0.9055599027733927,-0.5350955327004927,-0.13014552421600456,-2.637323216104029,0.2150759036355261,-0.11175177922098811,-1.571204085936591,-1.0077750672840537,-0.3813518367193318,-1.5122948395253197,False,c1,3,"Non-embedded inspectors are generally positioned to the bottom right of the node they're inspecting. In cases where we're dynamically altering the node, however (like the live preview feature for math), it probably makes more sense to position that kind of inspector at the bottom left. Then if the dimensions of the node change, the inspector will move around a bit less.
Thoughts? Other ideas to tackle this issue?
--------------------------
**Version**: unspecified
**Severity**: enhancement",56586,12,Low,False
0.36687163941342726,0.6092109271686237,-4.85530064442761,-3.3627213846561523,1.5885474000146593,-0.7336648528760329,0.6183328679895874,0.26238809681244946,-2.5874830997184137,2.356793338788262,-1.6353723596566505,1.393896623479084,-1.8895045830412673,1.6786408106483455,-0.784912051747594,-0.7768911195151349,0.907176178168595,1.865813018784343,False,c1,3,"If the parsoid service is down (`sudo service parsoid stop`, or update extension/Parsoid and forget/fail `npm install`), then viewing flow pages fails with exception
Parser only supports wikitext to HTML conversion
Backtrace:
#0 /srv/mediawiki/extensions/Flow/includes/ParsoidUtils.php(24): Flow\ParsoidUtils::parser('html', 'wikitext', '<p>It's a long ...')
This is true, but it masks the real problem that parsoid has to work, and didn't. ParsoidUtils::convert has a try-catch block around using parsoid, and if that fails it will fall back to using parser. It would be helpful for wiki operators if the exception message included the parsoid failure, e.g.
Parser only supports wikitext to HTML conversion (and parsoid earlier failed with exception ""VisualEditor is unavailable"")
Now that I've figured out what's going on, this has become a low-priority bug :-)
--------------------------
**Version**: master
**Severity**: minor",56490,12,Low,False
-4.325674954725027,-2.5264776695930227,-3.608674725438215,-1.5382551130767332,-2.9130124891936906,-1.5544383228192278,1.2164776137012518,-0.2622764726786482,1.8789316455944063,-0.2905738885794431,0.5127026293669976,-0.21921351776571496,1.7961363643674262,-1.0770724818453847,0.8604991645278153,0.015448590589109579,0.2611156163219397,-0.5153237101070032,False,c1,3,"When an image is selected it should be possible to position it using the cursor keys.
up/down should move it one line up/down. Whether left/right should move it one character or one word at a time I'm not sure about. Possibly shift/ctrl should modify this?
This would be useful for fine control and for systems with laggy mouse behaviour (not uncommon on slow connections in my experience).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51665",56472,12,Low,
-2.0416973381961823,0.35086559847568033,-2.418632093082172,-3.432971401559216,-2.475651277580324,-0.8130622842810311,2.067795007918483,1.7108084728389317,-1.5481665648622953,0.7641502486009237,1.8096150065454792,1.272543157333535,2.56987851730774,-0.9643544802736823,-0.4529544608351799,1.4639924530948458,-1.6277124212303036,1.17321005301968,False,c1,3,"When a pre-formatted paragraph with long lines is displayed in VE it word wraps. However it doesn't word-wrap in display mode (T2260), meaning that you have no idea that you need to add manual line breaks until after you have saved.
See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&oldid=573792519#Section_number_three (rendered) and https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&oldid=573792519&veaction=edit§ion=2 (in VE)
The word wrapping in VE is actually better than what happens in read mode, but the two should not be different. Fixing T2260 would be better, but as it's been open since 2004 adjusting VE to match the current behaviour seems more realistic :/
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=260",56381,11,Low,False
5.1417404899434,-9.20098000453656,2.3741346248247055,-4.165200960068939,-4.102174384524664,0.6745177604725678,0.09838219574053486,4.160410861279176,1.486215972995966,-2.652014478352787,-1.1157684457711117,-3.1279032025567886,-5.3822962068785385,0.8865066255609699,2.208493516629436,7.054070494503019,-2.9584717446220026,-0.3174851030053223,True,c1,3,"See e.g. http://www.impressivewebs.com/demo-files/question-mark-js/ - similarly used in Reddit etc.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56365,11,Low,False
10.768163404073052,-0.8574440951745661,2.6715573035040805,0.02610523389331587,1.6271660641215018,0.24538385687833464,-3.3496354114432716,1.6575183340812063,0.2652488349919223,-1.925430201833442,2.5744675352807733,-1.0402973207957882,-0.15065398890693427,0.1985072342829053,-1.067074228162797,-0.01573052596167951,0.6919028611094562,1.1366268389454877,False,c1,3,"Screenshot of link inspector not listing a matching page
When opening the link inspector on a link to dab page [[Department of Foreign Affairs and Trade]], the link inspector shows two items: the dab page, and the page [[Department of Foreign Affairs and Trade (Ireland)]]. It does not list [[Department of Foreign Affairs and Trade (Australia)]]. The unlisted page is not a new page.
Steps to reproduce:
1. https://en.wikipedia.org/w/index.php?title=Heidi_Bootle&oldid=573475141
2. Open Visual Editor
3. Click on Department of Foreign Affairs and Trade
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51013
**Attached**: {F11697}",56361,11,Low,False
-4.054282434869495,1.0500292006510819,2.0407063806128214,-5.072782953941502,-1.1567035703569866,-3.3124028354069557,1.143775813548256,-0.18851832108401656,0.26816179376905824,-0.9254874555497201,-2.1251198528947137,2.465002528060041,-1.2705885700182442,-1.0141428638258319,1.627569585167766,2.3667227617537363,-0.9352448028683235,-3.0029748758970563,True,c1,3,"Although it can't be used in articles, it is widely used elsewhere, including userpages.
If you try and VEdit https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&oldid=573626556 you'll notice that this reflects in reference numbering being incorrect, since the ones in the divbox will be ignored.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54803",56315,11,Low,
0.4878832999979137,1.492509539914348,1.9999965006604796,-1.9553013489292068,-2.4665325538369585,0.641312010030398,-0.40781526082695585,-0.453781474791926,0.15305468227075691,-0.15099579472098057,1.1172345880667476,-0.15253806389483437,2.7098140880591255,-2.194138650433203,-1.8060151427583784,-0.0563191922094774,0.43917110097209666,0.5259304992291611,False,c1,3,"Incorrect reversed display of non Latin characters
Please see the attached image and Bugs #54308 & #54309.
By this time I resigned to utilize the advanced toolbar and after making an attempt, I feel very cynical because this effort is totally useless. There is a lot to be said for programmers and developers learning to proofread a chapter or so of text, to see how their ideas are working in the real world.
In the first place, It takes several steps to hide the header to gain additional viewing space or access various features.
Finally, The non-Latin characters, like Hebrew and Arabic were inserted from left to right. For those who don't understand, that's the equivalent of displaying Latin characters from right to left, as in: . . . . L K J I H G F E D C B A
In view of my previous posts, please consider correcting this ASAP.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11606}",56310,11,Low,False
-7.092357139722559,0.6533904178881986,4.5675726699147425,5.991531500435181,-0.5185723619574749,6.8676954833648,0.5367072118852017,-1.8253668285189297,0.8201766357338178,-3.00479117849216,-4.093632737548245,-5.167212435767231,-3.4811316902085627,1.3688036082439154,0.7355711646603051,1.2749211953804467,-0.24724166769053668,-0.962405615637677,False,c1,3,"In a status bar/next to the cursor/on the image
--------------------------
**Version**: unspecified
**Severity**: enhancement",56297,11,Low,False
-0.3852416756894943,-1.0278376967415443,9.242883834240995,2.4224770470970234,-2.801943471409037,-7.594140728241839,-2.7137573215326487,0.08682823949884538,1.6287031322709034,4.441165361589066,-2.2921455546954084,0.25414421582464164,-2.444903602052806,0.0834321090760426,0.21943276696534486,0.12939104491752038,-0.7521547516363664,-0.34976962159649294,False,c1,3,"Example image: https://www.mediawiki.org/wiki/File:MassMessage_submitted.png
Clicking on ""edit"" takes you to <https://www.mediawiki.org/wiki/File:MassMessage_submitted.png?veaction=edit&vesection=1>
Clicking on ""edit source"" tags you to <https://commons.wikimedia.org/w/index.php?title=File:MassMessage_submitted.png&action=edit§ion=1>
The 'edit' link should take you to commons and somehow gracefully fallback on the wikitext editor since VE is not enabled.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://www.mediawiki.org/wiki/File:MassMessage_submitted.png
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62071",56259,11,Low,False
-1.451465149376059,-3.1295578723319863,-2.550705948079889,0.8393389052831379,2.1918429608319747,-0.9641803700543661,0.6716103364950801,1.3120328198292177,-0.3906515329672014,-0.3734430400799944,-0.943018696535789,1.3772791355317808,-0.37782801552230794,-0.35450298740973096,-1.1813965227315757,0.08963910073164752,-0.727364145213929,-0.7051902345835974,False,c1,3,"**Author:** `swalling`
**Description:**
Screenshot
If you start ?tour=firstedit and then click veaction=edit, you get the wikitext-related Preview step unattached (see screenshot).
This is a low priority issue, because users should only be getting the wikitext 'firstedit' tour if VE is not available. I am filing just in case the opposite situation might happen, i.e. users start a ?tour=vefirstedit, click Edit source, then get the VE tour step. If that's impossible, then this can be ignored for now.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11439}",56248,11,Low,
0.4466549043416719,1.2668327117590312,3.443114478961167,2.3025729201516834,-4.064498881412688,-3.2123449026966195,2.9119234019071536,5.65134970034594,-1.0915289883825312,-2.059523572259763,-2.615947468705812,2.028501328653377,-0.3864916460858234,-0.5979107442276987,3.5580521706257064,1.4437222531464944,-1.3690721779648434,-0.18926112959430452,False,c1,3,"Currently there are only 4 IRC channels being scanned at
http://korma.wmflabs.org/browser/irc-repos.html
https://meta.wikimedia.org/wiki/IRC/Channels#MediaWiki_and_technical contains the list of tech channels
#pywikipediabot should be added as well in order to keep consistency with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects
--------------------------
**Version**: unspecified
**Severity**: normal",56230,11,Low,False
-0.7972776296865387,7.831796240210817,0.9160553741681063,-0.7427526326722136,1.1694682699231693,0.5685710358336324,-0.16565937760959581,-0.05235073194110401,-2.4546351054617697,-1.5238773129435499,-0.23553080635371115,3.2264025889329453,1.5899916278690713,-0.847810093005906,-1.8450541261997784,0.541212376550382,0.9818273009656304,1.4333580212148258,True,c1,3,"InstantCommons does not work on Vagrant if you enable the 404 handler for images (the `thumb_on_404` role does that and most multimedia roles include it). The problem is related to thumbnail caching; similar to T101565, but the default wiki (`127.0.0.1`) is also affected.
As a workaround, caching can be disabled by creating `/vagrant/settings.d/10-DisableThumbnailCaching.php` with
```
<?php
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'wikimediacommons',
'apibase' => 'http://commons.wikimedia.org/w/api.php',
'fetchDescription' => true,
'descriptionCacheExpiry' => 0,
'apiThumbCacheExpiry' => 0,
);
```
",56202,11,Low,False
-6.881549654483354,3.6859009575167683,2.1517441562485615,4.049433073365843,3.169752520490878,2.407498194006676,0.7550559518080409,0.8067130470003449,-0.46245083282458355,-0.4847701982630426,-2.5730949738844275,0.18506203423780887,-1.7424815110417375,1.160816401656584,-0.9480216851219572,-0.6214760279268822,-0.2008962648008843,-0.40323195527127065,True,c1,3,"(Hopefully other reporters will improve the title and description if necessary!)
The French Wikipedia has a number of templates which usually ask for some kind of clarification about a whole passage of text (see https://fr.wikipedia.org/wiki/Mod%C3%A8le:Refnec#Exemples ).
So users are asking that, when they select that text and launch the template inspector, the text is already recognized as a ""parameter"" for that template.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56186,11,Low,
2.4541633944612866,-2.177078991797215,-3.4567484422573695,-4.927815612928396,3.4468161515669657,-3.063958648521862,-0.35301938406621236,-1.1636869810645165,1.0474197792692501,-1.3378625548876517,-0.6211496997981065,-1.6264353987807483,0.931359453709991,-0.3843312752214709,-2.205127955241177,0.32892135245023907,0.3015163689810716,-0.14435359954400573,True,c1,3,"NicoV reports this diff,
https://fr.wikipedia.org/w/index.php?title=Blood_Lad&diff=96657484&oldid=96506947 .
Assuming the user deleted the infobox without realizing it, I did not manage to reproduce the duplication of categories inside a reference tag (line 38); if I just copy/paste them they get nowikied, so it shouldn't be a vandalism.
CCing subbu and gwicke here. T52120 and T54238 come to mind, but I'm not sure if it's really a dupe.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
T54238
T52120
T76715
T89618",56169,11,Low,False
-2.0973368835851227,-0.07840453668372938,0.9196321410791057,-1.3091286685228152,-1.6620051085333656,-1.50787853726733,-1.0827460165896516,0.1240970406733018,1.369465383414128,-2.186426696058639,-0.8519085289970092,-0.6877163711648389,0.9843539005145798,-1.7474709772069206,0.19606559419686942,0.23764665517382166,0.42539469463639934,-0.8137105658307504,False,c1,3,"Change in MediaWiki:Editing notice to a links does not parse
Hi,
When I tried to add a internal link (related to [[Special:Preferences#mw-prefsection-editing]]) to MediaWiki:Editing, it did not parse as shown in attachment.
*Exact edit difference which I tried https://mr.wikipedia.org/w/index.php?title=मिडियाविकी%3AEditing&diff=1200554&oldid=44085 the result is shown in the attachment.
*The purpose of edit was to request users to give a try to VisualEditor and report input issues . (Issues related to usability of Marathi Devnagari script are very crucial to us )
I am not sure whether this a normal limitation of MediaWiki messages and so not sure whether this will be accepted as a bug.
But still prefered to report this bug since it is simmiller problem of parsing which I observed in Bug no 45195 also and just prefered to keep developers informed.
Thanks and regards
--------------------------
**Version**: 1.22.0
**Severity**: normal
**Whiteboard**: aklapper-moreinfo
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45195
**Attached**: {F11186}",56127,10,Low,True
-1.0593698214385765,-1.5115290895119404,3.0785416000102543,2.439402615322213,-7.054833360352529,-1.6555593623527105,4.21271532758908,2.092345580730189,0.5770806091081948,1.835578019708831,1.8700216641212468,1.1168360416322247,1.273527473863643,-2.8398296068793587,0.8374537582282953,0.7933645647936787,-0.08728493121598224,1.1662376782250565,False,c1,3,"If adding w:cs:template:commonscat, it might be confusing for newbies even for older wikipadians to set parameters. As in this case parameters or numbers, but VE sais that such parameters are unknown.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50735",56094,10,Low,False
-7.315609689188227,9.603493670176672,2.5322883306829347,2.4443326522108118,3.671469595702851,4.0934947927643295,-0.8267102748452801,-3.860799357597754,-1.9379315177536618,-3.6876406297929076,-3.0265409882662544,4.378073459975413,-1.4993821539571321,0.2185516685535731,-0.673158857047139,-1.8476981102545582,-0.39585225530937307,-0.4632079858864253,False,c1,3,"I am trying to run the test at https://gerrit.wikimedia.org/r/#/c/83966/
In the end it is trying to compare the text that was typed with the text that actually appears on the screen. The test fails, because the Zero width no-break space (U+FEFF) character is added to the string that appears on the screen.
--------------------------
**Version**: unspecified
**Severity**: enhancement",56051,10,Low,
-0.9982319122915904,-2.5353069660272514,-0.08203296538555094,1.3500842518204457,-4.389113197424203,3.1796824538394572,5.220694940411177,-2.9687461139008158,1.6717445295814664,3.368493839160543,2.050244276052885,-0.3016037353712877,-0.890091253014516,-0.9464479262404764,3.9713205341473445,-1.961478502875869,0.38081634952043064,-2.048682836304599,False,c1,3,"It'd be nice if WikiLove had a javascripty autocomplete for image names (at least local ones)
--------------------------
**Version**: master
**Severity**: enhancement",55976,10,Low,
-6.98300918574612,5.276743105083877,-1.4049549304334121,1.4903617351195315,-3.2323071351213932,2.171403334803797,1.6393104264480867,2.608265726653937,-0.036380051138755254,-0.09816377738915438,1.1094982588545768,-1.3634897822516605,0.3727285792278212,-0.30641329333081835,0.5208058104239912,-0.7208313547494967,0.6507542051778523,-0.4112106546176155,False,c1,3,"Editing of large pages can use a significant amount of memory; a spotcheck that Max did on [[United States]] showed an increase of 121MB usage in Chrome while editing the page.
This is a concern for us for mobile in particular, as today's mobile devices have the amount of memory of computers from several years ago -- most have 1GB or 512MB (or even less), which has to house the operating system, background apps, the web browser, and the *entire* article with a richly annotated DOM.
Possible techniques for reducing memory usage were proposed at the VE mobile meeting yesterday:
* Section editing -- if we only have to load up a single section at a time, large pages won't use up nearly as much memory. Note that on mobile we already divide the page up into sections surrounded by <div>s that can be replaced with the editable surface; the other sections on page might not even be open.
* Limit full annotation processing to areas under active editing -- apparently it should be possible to delay some of the HTML processing on sections or even paragraphs that have not yet been edited. This might also save memory, but needs to be looked into.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55825,9,Low,
-9.686214431989628,2.4780079478577406,-0.8372938991475785,0.9846102223498803,2.0218358893237363,-0.04667080645918231,-0.3289961991010024,-1.650823238003953,5.305079462251894,-2.841666621949847,-4.6238472235457495,-1.6106512152160366,-3.515130116589778,3.517446111559254,0.8526292032919356,-1.2331569109693188,1.966244870997943,0.3688190424532103,True,c1,3,"Users seem to expect that the feedback link will automatically supply information, especially the title of the article they're working on. I'd also like to have the version number they were actually using (cacheing issues) and a link to the user's contibutions.
--------------------------
**Version**: 1.23.0
**Severity**: enhancement",55801,9,Low,
3.716469569428973,3.740000202378212,0.6002333101167068,-5.474291702084577,-0.6110533345112801,2.894746233554863,-0.1735106881404258,2.400298126296151,-1.0521264921617766,1.6680390136627876,-0.05601107440555575,-3.0288495119085903,0.7319094559371107,0.2528318803328329,-0.4534434273629975,-0.31283745127252327,-1.1152979955834121,-0.6363765853436063,True,c1,3,"Right now external paste always writes the clipboard as formatted; in some cases, users will want to ""Paste Unformatted"".
On Mac, there's a standard shortcut for this of Cmd+Shift+V - I'm assuming that Ctrl+Shift+V would be sensible as well.
Would we also need a button? What about for the other standard 3 (Cut/Copy/Paste)?
--------------------------
**Version**: unspecified
**Severity**: enhancement",55781,9,Low,False
-9.80533962559443,9.697083242978199,-0.3155628663284613,-5.86817605296238,-1.4771668230720176,-4.209773906398161,1.3303715464234163,-1.8072744781523036,1.7791205539464336,-2.130045389171713,-1.2086819374896598,-1.3398363826709285,-1.0305603803809325,1.8728207188876977,-0.457906457708285,-0.2287681686987566,-2.0164224852818142,2.0152207126093264,False,c1,3,"When you open an existing reference in VE that only consists of one template the main use case should be that you want to edit that template. But now you need to first select it and then klick on the puzzle piece.
Instead I suggest that in that case, you get forwarded to the template editor directly after choosing to open the reference editor without having to do it manually.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55713,9,Low,False
4.80605817459095,5.863198839781113,0.9180462933105105,-1.061922184737977,1.0119231028652316,2.8379406976701373,0.10792083039650624,0.7304647116884637,1.779209931112698,-2.77267571624111,-3.5589885441447535,-0.24583496618730993,-2.970884909965651,-0.2364682283119306,2.3854876302116708,4.837337588741336,0.509021523761704,0.8177206937901322,False,c1,3,"The VisualEditor and ULS MediaWiki extensions have recently been blessed with QA browser tests. We would need them to be in the Contint Jenkins and triggered by Zuul whenever a patchset is submitted as well as in the gate-and-submit pipeline.
That needs several step:
- describe the jobs in Jenkins
- add the triggers in Zuul configuration
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",55697,9,Low,False
0.4531397784348359,-7.903353287170556,-2.7340909218010037,-1.3189720260895692,1.1230458480769128,5.196320827989724,0.1272790479992878,-0.36806802375050046,2.858220524133004,-0.6981485653683919,-0.8761298581257959,4.068226845296461,-0.9001559358347659,2.603805620712291,-2.395636373001267,-0.3785221484038277,0.6288821252884131,-0.11779517032344189,False,c1,3,"Need some UI to add/remove/edit the key value pairs.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55614,8,Low,
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",55609,8,Low,
-6.0112032350121964,2.3343175162973786,-2.0529331656412158,-2.06088100546017,-1.2451097193313672,-2.22876812365324,-1.5075471954542268,-0.44975626521519385,3.6713074832797705,0.5159156023059213,-0.314668234200731,-0.11881165985235875,-0.1685099234076013,0.10645037942225954,-0.041074094436776676,-0.5101786430226114,-0.7856704678849427,0.43845680739448434,True,c1,3,"Adam Cuerden says, ""I believe the VE team intends to have a some one click solutions in the near future, including adding templates of your choice to a bar? Although I'd hope there'd also be a few automatic lists you could choose to pull up - cleanup templates, etc.""
So, it would be really comfy for users if the template editor, beyond being able to let them select what they need by typing the name, asked ""Which kind of template do you want to add?"" and provided lists of the most used/popular ones, divided per set (cleanup templates, citation templates and so on).
Or just a way to store one's most used choices.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T52458}",55590,8,Low,
-0.7394141348994321,0.04074565114587969,-1.5472606010780137,2.7935247326832986,0.1171745560581684,-1.5289705297428082,-3.183156665344536,2.0726094878022656,0.11287649703629993,-1.9242264677815588,5.595912783148908,0.9424829771889247,-1.9937614357176638,-0.8967294969729069,1.2652183785142945,-0.209949523367724,0.6411056214250717,0.10455463631368578,False,c1,3,"As discussed at bug 50452 comment 9 it would be very useful for a page to have associated metadata about its title.
For most pages and by default* this would be identical to the all-lowercase rendering of its stored title, but where pages correctly start with a lowercase letter (on wikis where the first character is case insensitive), contain special characters or conflict with interwikis/namespaces, etc. the metadata would record the correct page title. It could also be used for titles that should be italicised.
e.g. on en.wp:
Page Title - Correct Title
[[IPad]] - iPad
[[Benzo(a)pyrene]] - Benzo[a]pyrene
[[Pilot No. 5]] - Pilot #5
[[D Ream]] - D:Ream
[[Computer]] - computer [indicating a common noun]
[[Amy Studt]] - Amy Studt [indicating the title is proper noun]
[[Animal Farm]] - <i>Animal Farm</i> [italicised proper noun, the tags are not literal]
The displayed title would be taken from this metadata and as such would effectively supercede the DISPLAYTITLE magic word and the [[template:correct title]] family of templates (and the equivalents on other wikis).
VisualEditor and any other tools that aid linking would be able to read the metadata and use it to determine what the default displayed name should be when linking to that article.
*Actually the default should be configurable as I guess languages like German that capitalise common nouns may want the default to be capitalised and the upper/lower case distinction probably doesn't make sense in all scripts.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50452
https://bugzilla.wikimedia.org/show_bug.cgi?id=56868
https://bugzilla.wikimedia.org/show_bug.cgi?id=49076",55566,8,Low,
-5.821010498885649,3.9160210268102347,-0.5959248446210754,2.34762061834427,1.0884085538155561,-1.8746172398266987,-3.9345357762962916,0.5254740858032045,4.126224560961791,-0.012554194578269673,2.8163131452899877,1.3747360902021868,-0.41192326151694925,-1.3234903011759909,-0.5635982387580292,-1.2526023789896554,-0.14737134282078768,0.8374649303428237,True,c1,3,"If you start to add a link, and change your mind (e.g., you realized that you have the wrong word selected), there is no way to simply cancel adding a link. You have to remove the link with the trashcan icon.
Steps to reproduce:
1. Select any word.
2. Press ctrl-K to enter link tool.
3. Attempt to cancel the link by closing the unwanted link tool dialog box using Esc key or the < button.
4. Discover that VisualEditor linked the word anyway.
If the Escape key and ""Cancel"" button are worthless for escaping/going back/cancelling, then they shouldn't be present or have any effect.
({T93749} altered this to re-add the cancel/close button.)",55546,8,Low,False
-6.187433391262299,2.915618668399148,0.8875549174333166,1.590836515741441,-1.2506902017480797,2.1243441107007657,1.8486917612958438,-0.4927897096197404,-0.9882002260446032,-0.4362647152418555,0.8211323354735249,-1.2172703781474765,0.3205357803883939,-0.7573804903667183,0.0392378703962768,-0.42197537105240124,-0.09822741165429072,-1.0171392487299618,False,c1,3,"The Parsoid team is considering a simplification of the different mw:ExtLink/* variants to just a single mw:ExtLink type.
For most types this should not make much of a difference to VE, but for auto-numbered external links ([http://example.com]) it might, so I am looking for your input. I did some testing on https://www.mediawiki.org/wiki/User:GWicke/TestNumberedLinks. Changes to the text lead to corruption as in this diff:
https://www.mediawiki.org/w/index.php?title=User%3AGWicke%2FTestNumberedLinks&diff=772988&oldid=772987
There also does not seem to be any automatic re-numbering when a numbered link is changed into a plain external link.
What are you plans for the handling of numbered links?
--------------------------
**Version**: unspecified
**Severity**: enhancement",55505,8,Low,False
-5.280173571835876,5.712079435615998,-1.187202842461696,-0.1489089428364424,1.5096500115953635,0.9810629233463202,-2.1343851858774374,-1.9680861784023742,0.9348829759619834,-2.3166895781055925,0.16773994080263988,-1.8582387885955935,-0.3756708838067455,-0.38247331224376513,0.7552980095588664,1.296779842361693,1.7279955477946596,-0.9504421702860504,True,c1,3,"Reporting user comment, some formatting is mine:
<<I made this http://en.wikipedia.org/wiki/User:Atethnekos/sandbox4 as a demonstration.
1) If the hlist template is used in an infobox or a table like on the page, when I go to VE, the list will end up be extended far into the page.
2) If it's used with [[File:Image]] as on the page, the list will end up being cut off, and then some weird things will happen if I try to click on the hlist template (e.g., the page will be extended to right and my browser will give a horizontal scroll bar). FF 23.0.1 Win7--Atethnekos 19:33, 25 August 2013 (UTC) >>
I edited his sandbox a couple of times. In this version http://en.wikipedia.org/w/index.php?title=User:Atethnekos/sandbox4&oldid=570256245&veaction=edit the pics of the masks are moved to the left: the caption of the first one is not cut out, but you can't edit the pics at all since VE will consider them as a non editable block.
I can't reproduce the horizontal bar and I can correctly edit the hlist template inside the mask pic caption with both FF and Chrome.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",55340,8,Low,False
-0.5969731466210484,-6.3801071625634975,3.2931765947973695,1.2599012674780208,-1.6739066929830826,-1.7874788877047374,-0.5791242165837325,0.6592309176272251,-3.1820648489678236,-1.724389788722171,3.0446758383269343,0.3068950907952235,-1.2038497078191144,-0.5444046802109925,-1.0505032614434926,1.3976687241384913,-0.8047812569362657,0.18777258119084217,False,c1,3,"Same as #51959, but it keeps hapenning on frwiki: some texts that look like telephone numbers are changed in <a href=""tel:..."">...</a>.
http://fr.wikipedia.org/w/index.php?title=Les_Visiteurs_(film,_1993)&diff=95954243&oldid=95559259
http://fr.wikipedia.org/w/index.php?title=Transformers_3_:_La_Face_cach%C3%A9e_de_la_Lune&diff=96093057&oldid=95089445
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: other
**Platform**: Other
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51959",55315,7,Low,False
3.143824611752493,-7.899577094743457,-0.8888403398571221,11.334663792870867,0.07620180814007849,-1.8117535936415963,1.5995906734866514,-1.0456320818588836,0.1443266359867385,0.7334172084628756,4.47387477713341,-0.2323597343895648,-1.6169035678068289,-0.17782098192279427,-0.11892864419651783,-0.5677739246897627,-0.016968392991474346,0.7122977551842864,False,c1,3,"EverNote Web Clipper has a problem with the editable area and inserts:
<style id=""_clearly_component__css"" type=""text/css"">#next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; } </style><div id=""_clearly_component__next_pages_container""></div>
Triggering: https://en.wikipedia.org/wiki/Special:AbuseFilter/345
--------------------------
**Version**: unspecified
**Severity**: minor",55252,7,Low,False
-0.9478665582872865,-5.526469885759656,-0.24205066986822388,3.47992256409871,5.773198155703637,-0.3364574404167813,-0.47274305343830214,-1.7495030325139829,2.1271945343452003,-0.6880649316040639,0.5048186447593941,-4.558139769349983,2.2884708332899253,-2.041965621461094,1.4526422742585572,-0.8612999926843499,3.6875766199764994,-1.8650792952901791,False,c1,3,"Screeshot of post hiero editor
Safari 6
I opened the editor inline, didn't do anything, pressed the back arrow, the editor closed and inserted a newline.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11956}",55250,7,Low,
-3.625176048252383,0.5094648160674708,-1.3009176786440477,0.39659530407536336,0.8056717603582655,-1.3114269095920104,0.34287974418044875,-0.5934605518327911,4.265953952411354,-1.2232218056794615,-0.4295039490147712,-1.5942630056219795,-0.18053329444267163,-0.87440671069435,0.36526648908739023,1.0107934676077233,-1.237152127409368,-0.5482907907414656,False,c1,3,"**Author:** `lucashokanson`
**Description:**
It would be extraordinarily useful to mimic Imgur.com's clipboard based uploader. Upon visiting the upload page, you would simply Paste - command/control v or click a button to use your clipboard's contents. This would then upload the file and return to you the standard file:____ page.
In addition to this, if this functionality is built it, it would even more useful to streamline this into the page editor as well. A simple button click could pop up a prompt and upon upload return the proper image reference in your article.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37932
https://bugzilla.wikimedia.org/show_bug.cgi?id=65670",55235,7,Low,False
3.0446445657940164,-1.8640409238831932,0.8484597893172996,-1.792108919731339,-2.674858846851032,0.6054530218678571,-2.3656696026667685,1.4129997008894684,-3.6195815040381607,3.024471020064838,-4.470303414520285,0.7714411626820288,-0.5115882308571678,0.04870759785230394,-0.4145602721614736,0.3253828786998188,-1.0530416280600299,0.9254781560517265,False,c1,3,"In Chrome, edit any page in https://test2.wikipedia.org
Click Transclusion, type 's' into input box.
Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
In Firefox, edit any page in https://test2.wikipedia.org
Click Transclusion, type 's' into input box.
Result is a list of suggestions that begin with ""Succession box"" and ""South America""
This suggests that at least one list of Template suggestions is absolutely incorrect.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",55231,7,Low,False
-2.068591944031959,-1.7307112991054439,1.498971892057714,1.8080457461488666,1.6595857544725234,2.9407557119918053,0.9454027889998322,-1.518578620489774,1.0333127195884504,-0.37367370941551936,0.44898474437507163,-1.0972618223392918,0.03961950231189082,0.08981912783461876,-1.275223189997834,4.505747659167838,-0.7726174749782371,-0.673901116614612,False,c1,3,"https://he.wikipedia.org/wiki/%D7%A8%D7%90%D7%A9%D7%95%D7%9F_%D7%9C%D7%A6%D7%99%D7%95%D7%9F?veaction=edit
The template on the left has a pie chart (see in view mode in the extendable green section) -- but in edit mode it's all jumbled.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
{T53932}
{T53166}",55226,7,Low,False
-2.094848776020644,2.2187540224633366,1.748679802312651,-0.09098295213886365,1.3198232886169372,-2.690000025046151,-2.913587011565635,1.0903881582435884,-0.40431083937024725,-1.038009464432807,-0.6003726122709789,-0.5473404748415506,0.6582028557808313,0.2342810631344463,0.17610870958643599,1.033043440921233,-0.3069641798946505,-0.5027161258759407,False,c1,3,"Testing the hieroglyphics feature on MW.org just now:
1. Open VE and select some text
2. Click ""Hieroglyphics"" button
Why can I ""apply"" hieroglyphics to a run of text, as if it was a kind of formatting? Doesn't make any sense.
3. Type some hiero codes (e.g. G26-t:Z4-A40) in the box
4. Leave the popup (by clicking away/clicking the < button)
The popup goes blank and can't be dismissed (Firefox 23).
Also notice that no hieroglyphics are seen.
5. Review changes.
The hiero tag successfully appears in the wikitext, even though it is invisible in VE.
Sorry for three issues in one bug, but I guess you guys can figure this out.
--------------------------
**Version**: unspecified
**Severity**: minor",55090,7,Low,False
-3.2729440812326054,5.945715585072119,-2.993550975914177,-3.4012167060991656,3.198657773727705,2.4963577102435988,1.641891923547436,-6.591715589657627,-2.1562421713918436,0.5891785375086096,-1.8921932417708967,-0.7056370310335094,-3.027778324314597,3.4808607457443816,-1.1988863765394582,2.3460019849898717,-3.332474896936623,-0.7506089205501516,True,c1,3,"Some users on en.wp consider it a bug that VE shows the top of the page after you edit a ""section"", and demand instead that, as VE auto-scrolls to the relevant section when you click Edit, it does the same after you save. Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement",55089,7,Low,False
-5.357077164413083,5.397613516626205,0.5003481627469135,-2.846789229490705,-5.653527044174702,-1.8632699688628696,0.3627825675200498,-3.1449797973842313,2.6616048265364345,3.283677029741872,0.360979557240912,0.16334891182796674,-0.34497871188826856,1.674618075738934,-1.2156281237302196,-0.4914645865346925,-2.7338624478046296,-1.17183145406934,True,c1,3,"If you have the preference set to ""Edit pages on double click"", then double-clicking on a word while you're already in VisualEditor tries to re-open the page so you can edit it.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Double-click_asks_if_you_want_to_leave_page",55058,7,Low,False
-5.161608142905548,-3.768763596430361,-6.265060665261119,-1.7882720946625907,-3.2668015470890737,-0.18383801606534933,-5.0620064248792875,-0.43833358071447104,0.7268896786339749,3.7072524196259913,-2.292539847559481,-0.0222662687493278,-1.0539434286428655,-0.6918589643222859,-0.6911762080275095,-0.7301337712870635,-2.526376951163252,1.3526412564561412,False,c1,3,"I am editing a page and something untoward happens. To review changes, I now have to click ""Save page"", which is sort of like a sign above a circular saw saying, ""To unplug, please saw through wall. Thank you for your cooperation.""
:p
Perhaps hovering over the ""save page"" button could drop down alternative actions, such as ""save draft of changes"", ""review..."" etc.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54980,6,Low,
8.542293976412248,7.405922466229416,-0.05568458765115025,0.23356490085559956,-1.5196842120594996,6.148789203220405,2.422015596836922,0.23523445911776647,-3.6163052077647606,0.9847235881193379,1.0787458179412943,4.54232226684602,0.9480187788697618,-0.11171821304038954,-2.2803076730673,-0.7508517336447549,0.38464077880179026,1.290727318653609,False,c1,3,"See reported diff on fr.wp
https://fr.wikipedia.org/w/index.php?title=Debra_Winger&action=historysubmit&diff=95823433&oldid=94552186
The js is from Foxlingo but the liberal sprinkling of nowikis is from VE or Parsoid.
PrimeHunter at en.wp reports that a Google search for FoxlingoJS reveals several other internet forums are suffering the same problems.
--------------------------
**Version**: unspecified
**Severity**: minor",54884,6,Low,False
18.341681150914614,-9.00062059460491,8.056021321258367,-4.7630382977837975,-0.28997736645278777,1.318904574508973,-1.0550244438642027,-0.2461506918298906,1.825382891469738,-1.9827969309353226,-2.7310212727440555,-0.6462896614939185,-0.8554218372608684,-1.0713374640615352,-0.5145544285082808,-0.31287927096645296,0.06819044033672927,-0.6637143869042492,True,c1,3,"At T53903, Elitre said:
> A user at it.wp wonders: if VE could pre-populate the summary box, could it
> also auto-add the text that was added, in case of very short additions? i.e.,
> if someone added a parameter to a template, could it automatically detect
> what was added and write it in the edit summary? Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**: T53903, T50274",54859,6,Low,
6.145003524855765,-9.927231065974727,-1.4956547439027474,-0.529541810985888,-0.8766871207126925,-1.0768326152890995,-0.8708931365178483,0.690941566403049,-0.8248112354617267,2.29758242350996,-3.902680378056907,1.396942839216459,-1.3524219803648485,-0.7773772404438013,-0.18386844901161847,-1.241375757132497,0.06651072972667382,-1.4700758001430865,False,c1,3,"GMail's keyboard shortcuts help page
Similar to GMail's modal when '?' is pressed.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F11100}",54844,6,Low,False
0.650734858496083,-2.5164610008169372,-0.6459931661977514,6.8069622922225115,0.3051591615986201,0.3495369035104148,-0.44592847324367924,0.2294913824210758,-1.2499473085487807,5.582239380811943,-0.7970407088725802,1.1291986379463375,-1.9386872514521523,-1.7030144724342762,2.5404961136504474,-2.3465859907581543,-0.48138469988126475,2.6562904451386364,False,c1,3,"At https://en.wikipedia.org/w/index.php?title=Judi_Dench&curid=85432&diff=568314406&oldid=568147939 the article was top and tailed with
<embed type=""application/x-datavault"" width=""0"" height=""0"" />
Searching seems to suggest the most likely cause is the ""DataVault"" password manager browser plugin
--------------------------
**Version**: unspecified
**Severity**: minor",54791,6,Low,False
-9.468004744292672,4.194832783104541,0.06857384911227982,0.9723506360802068,-5.3452386366548215,4.539469168074917,-0.40471442362499754,-1.526327778500077,-0.5807535796680017,-2.0719291732756915,-0.6368014928050623,-1.5402151231711583,-1.407697398146686,0.20574857786522305,3.755659588304309,1.5822121344098312,-2.6106764052674087,-0.01278644829342257,True,c1,3,"A user at it.wp asks if, in the long term, it will be possible to edit templates directly (i.e., infoboxes), without the transclusion dialog, as if one was changing something in a table. Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54786,6,Low,False
7.515786857727463,-5.020867883172791,0.5043417588164907,0.27191222115851055,2.09467058044515,-7.106157297394667,-1.0717082342970796,2.778961664944396,2.744780729101344,-0.8469383837827253,0.011267170311877628,1.5338861018570291,1.0520761675301853,2.1342485756445226,0.9762125846452143,0.9018035865589453,2.1072531625686066,-2.781153259144924,True,c1,3,"<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >>
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37578",54782,6,Low,False
-9.596563351706491,9.078899817430887,-0.7551787138095225,-1.5709225743262152,-0.22048661950717924,-0.8691347966103588,1.657866260739616,1.6075468726539128,-2.3484166276534806,2.5658124848726347,1.3715142546020966,-1.3529227231322125,1.8654194141835059,-0.48357910234629475,1.9954767567020637,1.4327123056968538,-2.8239105520355006,0.7936353170206971,False,c1,3,"At https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=568194420#I_can.27t_edit_the_references it has been proposed that it would be helpful to editors if they could edit references in the reference list, as well as where they appear inline.
""As just about every object you see on a page is directly editable with the VE, of course having the reflist not editable is counter-intuitive. ""
This proposal would make T54736 either unnecessary or just a ""workaround""/interim measure, depending on the timescale to implement.
--------------------------
#2 in the 2023 wishlist: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Citations/Allow_citations_to_be_edited_in_the_references_section_with_VisualEditor
",54750,6,Low,False
7.278762331715312,9.569396754811546,-1.549296520993746,-1.939504714735683,5.357247184184542,1.2062644375219247,-9.02006838133388,1.848894423521417,-2.8765219153968555,0.09274298790822044,3.0284995874074823,-1.010067544866746,-3.192376027186321,1.2880891248325899,1.7040768085536655,-1.542827039906762,-1.6437965227531188,-1.0676861437993375,False,c1,3,"en.wp user JmCor reports that in Firefox on Windows 7 the shortcut ""<shift><alt>V (show the changes), which stopped working when the Visual Editor was introduced: currently, <shift><alt>V simply positions the cursor on the ""Show the changes"" button.""
I can confirm this also occurs in Firefox 23 on Linux.",54701,5,Low,
-2.6385206619264165,-2.7467146241728884,7.686105416109541,8.32050935067002,-0.8112110017130931,-2.662820644295534,3.0188417509068293,-3.444845317249405,-3.4706898633739094,-2.097205105600811,0.704895415940765,4.426950758586661,-4.14922477370959,-0.8925923026003177,2.614386573632456,2.1769767744391197,0.609010923144089,0.8227258403053945,False,c1,3,"The <var> tag is used in many articles for variables, and there are css styling rules for it. An example article is Shading
http://en.wikipedia.org/w/index.php?title=Shading
--------------------------
**Version**: unspecified
**Severity**: enhancement",54664,5,Low,
-0.4157968711799249,-9.245691032009372,-1.6268119604854743,3.2105372181097103,-1.1154967323611489,3.8328943870404837,2.667677595161938,-1.4125353377699108,2.6484325140757816,-0.25254833428782764,-0.7690752283362978,1.4307435408602747,-1.6421858997687018,1.8818582840294535,-0.6034339390760453,-0.3942406768538598,-0.7747526086659081,0.13695078092398494,False,c1,3,"VisualEditor needs a tool to set/unset font colour.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54645,5,Low,
1.7436900333348544,3.259692107098253,-4.49425034316233,-2.7649773820053136,0.08884038874109956,1.8049281427575192,-4.174900022822273,-0.8052454492540205,-2.1742463366839164,0.5912213394441919,-2.1047775926566445,0.27330472042808074,0.29144606586352273,0.07722688726187155,-0.6426964910451538,-1.2508497683432005,-1.3586156429320961,-0.1177273804570611,False,c1,3,"**Author:** `sandrobt.wiki`
**Description:**
Here is how to reproduce it, when trying to add a link to the page ""Maria"" on en.wiki.
1) Select the add link icon and type ""maria""
2) Select ""Maria"", which is at the end of the suggested list
3) Press Enter or the ""<"" button
4) Save
The link is added to Mariah Carey (which was on the top of the suggested list).
Cf. https://en.wikipedia.org/w/index.php?title=User:Sandrobt/prova&diff=prev&oldid=567641122
Note that this doesn't happen if in 2) you had typed ""Maria"" (which is the exact title of the page you want to link to).
Cf. https://en.wikipedia.org/w/index.php?title=User:Sandrobt/prova&diff=next&oldid=567641169
The same problem appears in similar situations in it.wiki (for example when adding a link to ""Sega"" you need to type it exactly like that, since the first option is always SEGA)
I'm using Firefox 22.0 on Mac OS X 10.6.8.
--------------------------
**Version**: unspecified
**Severity**: normal",54634,5,Low,False
-6.317764256817176,0.8757585956722433,-3.919728453535381,4.174611075468814,0.48843820880951405,-4.277517679090977,-0.9382237937887954,1.7947630794509735,2.9103502396973653,1.8143851357563987,-0.6443303974133889,-1.6991501880242459,0.12329690631861023,-0.36911707039490516,0.38937122409308245,-0.994228151926877,-0.4740625891971425,0.08022313795846414,False,c1,3,"if the template does not contain explicit ""templatedata"", the API call should return auto-generated ""templatedata"" structure, distilled from the template itself.
it's trivial to do - basically parse the template, extract parameter names (including order based, aka 1,2,3), and return ""default"" templatedata where every param is of type string, without any special attributes (default, required, etc.)
this 15-line enhancement will make VE suddenly useful for templates, without detracting anything from current functionality.
we did this in hewiki with ""template param wizard"" (the equivalent of VE template editor, for the old wikitext editor), and it enhanced the wizard's functionality tenfold.
regretfully i can't submit a patch - hopefully someone else will be able to do so.
peace.
--------------------------
**See Also**:
{T54135} / https://bugzilla.wikimedia.org/show_bug.cgi?id=52135",54581,5,Low,False
-8.35633184393136,0.8944706490290297,-2.8773121410020153,-3.589749402168698,2.4360390576098285,5.280479006715254,-0.0353077107196782,1.6786936012285114,6.811132123072917,0.00596148419784992,0.9129184687722129,2.4496051948290507,0.18504527606701782,2.6432899902581104,3.1844475622423074,-0.5723787869372529,0.565864325670496,2.072571963776448,False,c1,3,"To replace a file it is currently neccessary to delete the file from the page and insert the new one.
It would be easier to replace the filename only. This avoids to add caption and file options again.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54580,5,Low,False
-11.907376164441628,10.016608912938384,4.07899887337209,7.920052675517065,-0.9707154632490869,6.310050833012445,1.5074871471375078,-1.1953811719318455,-1.9726152752194104,-2.979005352895428,-4.00172169964162,-1.0832005832800395,-3.3024608834610927,1.6827376018955285,0.3470617618923688,-1.2801332643892018,-0.9143977568523493,-2.42497964579376,False,c1,3,"When VisEd is activated from a section edit link, the focus of the display normally stays on that section. However, if the user activates from a section edit link while on a diff link (has to be diff of current version), the focus shifts to the top of the page as if the whole page edit link had been pressed.
--------------------------
**Version**: unspecified
**Severity**: minor",54566,5,Low,False
-2.953917896741152,7.665399996779993,-2.564588243353514,-4.672433699422562,-3.5800959721162138,4.076358233342393,-2.6356164117397474,2.359528793170044,0.4250392141519945,3.0690714366431067,-1.0689434921496361,-0.004959917347385323,-1.7007983515937974,0.5039843309903196,2.2895327458238244,-2.770314130153163,0.38331564804563234,-0.06468834777669374,False,c1,3,"Wikis use lots of shortcuts on the talk pages, and it can be quite frustrating for the uninitiated to figure out what WP:MOS, WP:N etc. mean, especially when several are used at once.
Having to click on the link to see that its about the 'Manual of Style' or 'Notability' would be unnecessary, if the same information was available in the tooltip when hovering the link.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",54558,5,Low,
-8.610438076145254,6.247376545139961,-2.654632028811699,-2.1041588299948035,-0.5707693806619806,-3.7083580135118206,2.668563479435581,1.0255992967147511,-1.6788101791033196,-0.03379386428554554,1.663191365263327,-1.8459218349250262,-1.0055240180338734,-0.8591562232214747,0.9052557022394989,2.5110803189348334,-1.3662530380823863,0.7995123595997395,False,c1,3,"Screenshot where it works (VE copied it from <style>)
When VE copies styles into the frame, in the case of copying from a friendly <link> tag (e.g. one that is readable, we inspect it and copy the contents over, as opposed to a foreign one we have to fetch again from the iframe).
In that case, the css we manage to extract from the remote <link> appears to be dirty and neither strictly or effectively roundtrips. Both the actual css it copied and the effective values are different.
For example, in the case of ""background: none;"" it gets dirtied to ""background-image: none; background-position: initial initial; background-repeat: initial initial;"". Which means it no longer overrides background-color.
Now, in some browsers background: none (old IE iirc) is indeed interpreted as the above, and it would be reasonable behaviour of it expands it to what it interprets it as.
However in the case of Chrome, it does't just normalise but actually gives us values that don't match. See attached screenshots.
The side effects (e.g. broken styles) are currently (e.g. MediaWiki context) most visible in debug mode because then almost everything is loaded through <link> and as such subject to this bug. In production mode most things are loaded by ResourceLoader and thus evaluated inline. However it is a bug both in production as well, it is just a matter of time before we find random broken styles.
- Figure out if we can get the contents without normalisation
- Perhaps fallback indefinitely to always using <link href> for remote stylesheets, thus costing a few extra http requests inside the dialog, but that might be the only way we can for now.
- Figure out how many things are affected and in which browsers. Maybe we can get it fixed upstream reasonably fast (these seem to be genuine bugs in the browser).
- If there's only a few properties subject to dirty normalisation, we could consider changing our stylesheets to avoid those properties. E.g. instead of background: none; use background-color: none; (something less ambiguous, and probably correct in this case, though it is a bug still because it works in Chrome normally, but not after roundtripping to an iframe).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F11259}",54486,4,Low,False
-3.809731254365076,-2.508670461105707,1.0043099712768644,1.795637326453638,0.04655704219106971,0.4391103606230451,2.9498577310058005,3.9387447628335543,0.6470952340822425,-1.655705218838591,-2.7524298170972274,-0.6671393525642708,-2.2511025987791236,1.1946812620039688,-0.13197228705150899,-1.2424380388484788,-0.3256440019905742,-1.6070621006481653,False,c1,3,"en.wp user Wouterstomp suggests that the media selector should also suggest images that are used on other language versions of the article, not just based on the page title.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T53031}",54464,4,Low,
-5.937906630393036,8.335348434856172,-1.5590598590676557,3.9532391567166014,-2.556844145619852,2.7495685068426985,0.35873648542867276,-5.871031833819477,2.7287239944111397,-2.7277519133975177,-3.1786914532575206,-0.46938168654595114,-2.678470948193527,1.962477050057979,-0.8569845316031044,-1.3433918961847668,0.08100797905128299,-1.881424385806491,False,c1,3,"Wouterstomp at en.wp has requested that the media settings dialog shows a tumbnail/preview of the image so you can refer to it while writing the caption.
I would add to this that ctrl+click on this preview image should load the media description page in another tab/window.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54461,4,Low,
-2.9994388438571122,-1.4574822570416117,-4.646239639529375,-1.1284284277065968,2.6391784901213438,-1.4859802121225116,0.11674130804756366,4.091232394903627,-2.410462923319768,-3.574713845502542,-2.1161406632222564,0.05697889744506979,0.21518559455295527,-0.7288920977633211,1.879343143882453,2.436560484903713,-0.003942689934911314,1.1156241210482525,True,c1,3,"<<This is not really a VE bug (it is possible in the standard editing mode as well), but it is something that happens more often in VE, and that perhaps can be automatically disabled in VE as well; inserting references inside section headers. This is never needed or wanted (it is ugly, and the thing that needs to be referenced should be in the text of the section, not only in the title anyway). Example (spam, but the principle applies): http://en.wikipedia.org/w/index.php?title=Miniature_pig&diff=prev&oldid=566703074 . Fram (talk) 07:31, 2 August 2013 (UTC) >>
--------------------------
**Version**: unspecified
**Severity**: enhancement",54450,4,Low,
-6.93636102224084,0.8923540060980919,-1.8838155060390278,-2.644180335104512,-0.5372045158163007,-0.5622022806144789,2.1304456106401064,2.0643811513762524,0.6833748030409775,1.0460884493917932,-0.8608100645133714,3.003403441746224,-0.7477259605400981,-0.4851370073204446,1.6808255443971092,0.36443530494462467,-0.5640838786597449,0.674057959948094,False,c1,3,"A user at en.wp asks:
""Why hide the puzzle and content icons until mouse-over? In general, if a function is active, it should be always shown - no idea, what hiding tries to achieve here.""
Personally I think this could be very confusing for links, but it should be ok for templates and media.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54447,4,Low,False
-0.8420461018867944,-2.25838214727578,9.854458573864381,3.184218136857588,-4.594001506834795,-7.769485260852345,5.38891768349487,-3.0369641517412456,-0.16280590643141132,-1.7395853324991832,-2.8591214646143515,1.6847597281150268,-3.2793993251361355,0.428848103415274,1.3048173909569938,-0.9779633557488379,-1.9939637479828063,-0.5346277251082274,False,c1,3,"If category:A is redirected to category:B
when user adds category:A it should switch it automatically to category:B like mediawiki:gadget-Hotcat.js
--------------------------
**Version**: unspecified
**Severity**: enhancement",54414,4,Low,False
-2.128510512460748,-5.705003152314287,3.9214092778472995,1.3945237654591107,3.4445498602909663,-0.6989110625920149,-1.0227974191750668,3.4876986673683827,-0.8859274412978433,0.6703813028491128,-3.4005699636615816,-0.23796284380253996,-0.7074825773258846,-2.4042909315950394,1.4312332630283064,-0.3888983585423442,0.16345002567673506,-2.3647521515378944,False,c1,3,"The sentence ""This page was last modified on … "" (message lastmodifiedat) is not updated after an edit.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48560",54403,4,Low,False
1.0863547740447195,4.849650993656741,2.851264323131705,3.8088074016081013,0.25931443237014284,0.652989232679964,-3.028996127651694,0.24823451331338664,-1.343899977120984,1.5069962560850954,-1.79917624604996,-0.938019565745961,-1.0878910805601407,-1.298870778244194,0.5957461695259516,-0.47259149002088396,-0.050602246529790174,0.7355677047502749,False,c1,3,"The cog to the side of the ""Languages"" sidebar section does, in fact, not let you change anything about that section.
### Concerns
* The ULS ""cog"" is visually associated with the ""Languages"" sidebar section, despite being unrelated, other than (confusingly) relating to the word ""Language"" in some way. The placement of this cog should be reconsidered.
* The ""Language"" sidebar does not currently have a way to quickly edit its contents. (Unlike HotCat for categories). It can be changed by performing a full page edit (via the main ""Edit"" button on top). Alternatively, the links can (sometimes) be edited using the ""Edit links"" placed at the end of the link, which relates to Wikidata.
### Background
There are three things related here:
1. Edit language links on current page: This is part of the content for the current page, and can be edited by clicking ""Edit"" and changing them in VisualEditor (under ""Page Settings > Languages""), or by using the source editor.
2. Edit language links associated with current page's Wikidata item: These are stored on Wikidata and can be edited by using the ""Edit links"" button at the bottom of ""Languages"" sidebar section.
{F11931}
3. User interface language: This is the language used for the interface of the software, names of input fields, sections, buttons, etc. This can be changed in three ways currently:
| Preferences | ""Preferences"" among the personal tools. Available on all pages, all wikis. leading to Special:Preferences. {F14222596} {F14222603}
|--
| ULS (personal)| The ULS link (language name) among the person tools. Available on all pages, but only certain wikis have it enabled. Leading to a ULS dialog dedicated to language selection. {F14222782} {F14222792}
|--
| ULS (cog)| The ULS cog, aside the ""Languages"" section in the sidebar. Available only on content pages, all wikis. Leads to a different ULS dialog, one that also has other features, but among them language selection. {F11929} {F14223046}
|--
### Original task description
>>! this-does-not-edit-languages wrote:
>
> languages should be editable out of a link besides languages. see attachment for a wheel which opens something else, on top of languages. clicking below drops you into wikidata. to really edit the languages one has to go to page settings! very confusing.
>
>
> **Attached**: {F11929}",54383,4,Low,
-1.6347238873036136,6.150072163977573,3.902632425064091,-1.6550923295383284,-1.1548810437571069,3.0286309678298204,2.469653830742888,1.5172712282495433,-3.359150385223627,0.6838604319518291,0.17256305511318581,-1.3540995339265454,-0.5334017774561648,-0.8442407440770037,0.4304509898265172,1.2027499867879186,-0.3616385308983534,-1.8679740759255996,False,c1,3,"On Unix systems with an X-Windows desktop middle-clicking usually pastes text that was last selected with the mouse.
It doesn't work in the VisualEditor in Firefox if automatic scrolling is enabled in the preferences.
--------------------------
**Version**: unspecified
**Severity**: minor",54336,4,Low,
-2.713445093448924,0.8886146936128014,8.80228750913503,10.663917124887005,11.568227006055674,4.86462390302748,0.9872663666480461,-0.18326050253630677,-0.6541060816887635,0.9453523899561747,3.3587632450627996,2.629844972484091,2.485106446454683,-1.4041472451674668,0.2588033397372591,0.10078577252833218,0.6569714389551005,-1.4683574590777773,False,c1,3,"Go to https://www.mediawiki.org/wiki/User:Amire80/be-bullet-heading?veaction=edit, which contains the wikitext:
```
* list item 1
* list item 2
* list item 3
==Heading==
paragraph text
```
Press Shift-↓ (down arrow) three times.
The first time, the first list item is selected.
The second time, the second list item is selected.
The third time, the third list item AND the heading are selected.
Selecting the heading should require a forth press of Shift-↓.",54332,4,Low,False
1.6722889352448251,1.3852673996696776,4.9484433736435065,2.8096466572366476,-4.784802341613908,0.6865520284078872,0.5939881706998547,1.4175020830996,1.141402562172382,-1.1661690634175481,-1.6291625730774115,-2.2857493497937096,-0.39005806004962107,-0.4542088764892176,-1.4723628890027314,0.726642891419079,-0.7416202581641091,-0.49133310106276573,True,c1,3,"Screenshot of the bug as provided by user
Depending on the display format, VE fails to get the display of several tables properly in line. See also attachment; test page here:
http://de.wikipedia.org/wiki/Benutzer:Stefan_Knauf/Dateidurchsuchungsprogramm.cpp
Report:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121040382#VisualEditor_ist_nicht_WYSIWYG
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11761}",54304,4,Low,
-4.726061300512332,-6.138934527809408,-1.2849743825686808,3.8362875689688627,-1.2946172022982498,0.687651575335793,5.945641320858367,4.886823641968399,3.9807703071120706,2.544000890382401,2.4041308629485845,-2.3779130835736737,-0.19183402649171466,0.1016564169910481,-0.4096064655503113,0.5548849799802141,1.6931873699907667,4.4700996351822,False,c1,3,"Rather than simply quietly inserting pawns and other placeholder characters into the page text, VisualEditor should do a sanity-check pre-save and either outright reject or loudly warn about edits that will insert such characters.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54231,4,Low,False
-5.208583221536584,3.3654442490671883,0.2816355101740484,-4.394720617532892,-7.048104565814382,2.2322574342343646,2.161515092423392,-5.467975795569995,0.09128762489343711,-0.4801894650910512,-0.27308365583454064,0.8565167548265131,-0.4246461634225245,0.9752583913418116,2.7127389670925774,3.32364830268475,-0.9420831923980219,2.065418320186768,False,c1,3,"What it says on the in. Like in most desktop applications, it should be possible for users to customise the keyboard shortcuts to their liking. Including in VisualEditor and source editor.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",54143,3,Low,
-2.4468836679950488,0.833932623554416,-1.6563945086319194,6.2727719365590895,5.931670353809686,1.7142270975471547,1.1331650683611327,2.857905772107688,0.9545460930012057,-0.6101197832871366,0.4009282730629824,0.6762262706343924,0.9074959804722411,-0.8285897106139473,-0.064504873758775,1.4210151824663095,-1.1511762567640669,0.438085121951145,False,c1,3,"**Author:** `KilliondudeWP`
**Description:**
The edit summary box currently uses a textarea input box. Current functionality has the return key starting a new line in the textarea, but upon save the edit summary is truncated into one line in the page history (line breaks are turned into spaces). Thus, the textarea box is misleading.
A more sane option would be to use a single line text input box, where the enter key processes the edit rather than starts a new line.
See T40042 and T42034, and specifically T42034#467450.
",54133,3,Low,False
0.9245257508674904,0.4818125063112717,6.517242530957958,2.0620786181925324,4.79705511369013,5.442500023386814,-1.6305484515888393,0.007686536914552511,1.7235939827281592,0.4393095004325964,2.876109193969595,-1.0526755198387454,3.999151575435375,1.595944069472372,0.8594523615864214,1.8693770739252151,-1.7976958177469338,-0.8618665776410432,False,c1,3,"Steps to reproduce
1. Create a page with a linefeed
2. Edit it in VE
3. Copy the block containing the ↵
4. In a new VE window, paste
Expected results:
VE smartly removes the ↵
Actual results:
The ↵ is pasted into the second VE as a literal character
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53828",54096,3,Low,True
-3.777420951569778,3.8781752556964513,0.2119241984705198,3.1964603679615626,0.2483785046827397,2.3139320973578794,-1.9042948324720932,1.320269638767559,2.104267253007637,0.6943896806792083,-1.78375248146567,-1.6050009332983708,-0.11837173000103096,-1.6303895847352794,0.7869324486578453,1.6061442755984068,0.6129982664138154,-0.7623200389172438,False,c1,3,"As perhaps a simpler case of copy and paste from 'external sources', pasting richtext that copied from the same wiki should work seamlessly.
In many cases, the 'html' already has the metadata needed. e.g. the image, or text-with-wikilinks, even the categories, should be paste-able
https://en.wikipedia.org/wiki/Pelham_Parkway
With a tiny bit of additional html attributes, the navbox templates ({{Parkways in New York City}} & {{Bronx streets}}) could be copied as they are self-contained units - no parameter were used to invoke them.
Again with a bit of markup, the Infobox pasted into a VE session, but only the shell transclusion could set up - the parameters would need to be entered by the user in the VE.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51547",54091,3,Low,
-4.3703469494052305,2.338643908347091,-3.6659379478879064,1.240420637929124,1.5415735635580865,4.02745314887324,0.19280231905262912,1.9162830354901912,-3.2354392858093908,-1.973384503042566,-1.487634925935939,-0.7827726812280654,0.2034886841801935,-0.39572269961149154,-2.884186871520095,1.136758393481808,-1.0338877258815107,0.34522364564746044,False,c1,3,"The paste operation on Firefox behaves strangely when dom.event.clipboardevents.enabled = false
(which is exposed in the UI of several extensions)
When disabled, rich text appears to have been pasted into VE, with links in blue (but the link isnt editable), but in reality the paste has failed to change the underlying data in VE.
If the user starts typing, the pasted richtext disappears.
If the user saves immediately after the paste, the richtext remains visible in the VE, but the save only adds blank lines instead.
--------------------------
**Version**: unspecified
**Severity**: minor",54089,3,Low,
-10.071314270811474,0.6928684467107864,-4.513610337207368,2.1152618819704427,7.605904361955108,3.303527480999155,0.31763208234177664,-1.4011386249005788,0.6770847781901798,-0.45380510260494855,0.9245526513281148,0.5427062789602446,0.7162775170631721,0.0483035060233723,-1.3568211615735057,2.3816657505674024,-0.4879808516844377,-1.8525615117620198,False,c1,3,"When you start a new transclusion dialog for a template which has the templatedata specified it shows a list of the parameters with the label on the left and the actual parameters in grey on the right. This is good for power users who know the parameters.
When you choose a parameter which has a value specified you can see the label, but you can't see what the actual parameter is. This would be quite handy and could use the same grey style as in the list.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54087,3,Low,
-4.855082167642876,7.821231805912756,2.814834831068943,3.223201138682323,2.424982888472477,3.582296050662311,0.0705129679330927,-1.9309659050804804,-0.06483919628985155,-0.2774893147872062,0.26859176521460704,-0.49645852544881386,0.3968226999822395,-1.42731484675362,0.10729765596539842,1.0744582086543053,0.41538132417057794,-0.4027655923542728,False,c1,3,"Wikipedias in some languages, among them Polish, Russian, Ukrainian and Hebrew, have a gadget that shows a list of frequent edit summaries near the edit summary field in source editing mode.
Here are the source samples:
Polish: https://pl.wikipedia.org/wiki/MediaWiki:Gadget-edit-summaries.js
Hebrew: https://he.wikipedia.org/wiki/MediaWiki:Gadget-Summarieslist.js
Many users in the Hebrew Wikipedia complained about the lack of this gadget in the VisualEditor. This could be an enhancement request, but given that for several languages it's an integral part of the editing interface for these languages, it's a regression for them.
Adding this as a feature should be very easy, given that it's quite simple and the existing gadgets' code can be reused. Localization and customization for every project can be done on a MediaWiki page with a list of summaries for that project.
--------------------------
**See Also**:
{T50274}",54085,3,Low,False
-4.060947891084328,1.2555461347714516,-1.515917551562156,1.5552259223161542,0.7502108954027096,2.0877109550717012,-3.073758830315418,-1.8982133937071444,1.1203990501099352,-1.2077540203534674,-0.8249393190721284,0.5679281828306677,0.817699481073479,-0.8515099068043899,-0.6609287662245391,0.2062261981944626,-0.3018469931114045,-0.560816490802337,False,c1,3,"Steps to reproduce:
1. Open VE on a sandbox
2. In a different window, delete the sandbox
3. In the VE window, change the text in the sandbox and save the page
Expected results:
Something similar to the SE, which asks ""
User xxx (talk) deleted this article after you started editing it, with a reason of:
blah
Please confirm that you really want to recreate this article."" with a checkbox
Actual results:
Backend error message is displayed, and there is no option to ignore this error.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54073,3,Low,False
-8.547188077313109,4.836728686337285,2.467173110714466,-1.1862943968970658,-4.691460885143567,-5.120262234490276,-2.122937709637227,-1.9072794716340957,2.2114843151868078,4.61771759856561,-3.2757836031031133,-5.001229045454021,-0.7895095922975646,2.240366372667318,3.021892541084383,1.8067099264726836,1.9252249999731308,-1.0440240059416475,False,c1,3,"It should look at the attributes directly rather than take them as parameters. We should move the folding of all sorts of types into 'default' or 'none' in there. We should set the CSS class in one place rather than two different ones.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54065,3,Low,
0.7157292341319317,-3.6966299504802684,-0.4061691823868401,-3.3863869031536584,-1.6334597409239788,-1.2859406672556486,5.1918630005685005,-2.5688636019751256,1.0234497392544726,-2.653919148136726,-3.682504094047709,1.5701720035736153,-4.492151308633072,3.1484554976452035,5.1366506512942935,1.5294311155646156,-1.0833953953262687,2.0077211122891105,False,c1,3,"The Poem extension has almost as much extension setup as it has functionality. Bundling it with MediaWiki is silly, it should simply be merged into core.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**Whiteboard**: migrate Poem extension bugs to core post-resolution",54061,3,Low,
10.538975771799489,-4.112350007477136,3.9282852664361165,-1.4679117079235682,-2.5590658931421575,-1.0590628330366885,0.47009696665690015,-0.003682225731645672,1.3501777210523451,-0.7952087231754636,1.1903642574608697,-1.4418570399146193,-0.1882843553333915,0.14483881479159244,0.9497375408353808,2.533851392431792,0.22658830018285125,0.4142831230998214,False,c1,3,"VE should work as expected without clipboard access. Currently it only half initalises.
1. Install Kill Evil in Chrome or similar
2. Edit any page
(https://chrome.google.com/webstore/detail/kill-evil/epieehnpcepgfiildhdklacomihpoldk)
Result:
https://en.wikipedia.org/wiki/File:Missing-ui-ve.png
--------------------------
**Version**: unspecified
**Severity**: enhancement",54008,3,Low,False
10.170830635472546,4.3958979057319105,5.854638740337045,3.6300167643568955,0.6276996529062799,3.0033258602785375,0.2848000026631752,0.29404876714165074,-1.6580654057273356,2.9977282071734663,0.8895435547845127,1.100049938472978,1.3446556385707513,-1.218335238124737,-0.8833573054305832,-0.20425963571658967,1.5639960886893187,-0.3542796582409651,False,c1,3,"A very common chess template on many Wikipedias recommends using '|=' , and most instances of chess boards use this syntax
https://en.wikipedia.org/wiki/Template:Chess_diagram#Standard_diagram
https://de.wikipedia.org/wiki/Vorlage:Schachbrett#Standarddiagramm
On German Wikipedia, editing the template strips the '=' signs. This article is on the parsoid topfails
https://de.wikipedia.org/wiki/Edward_Lasker?veaction=edit
http://parsoid.wmflabs.org:8001/topfails/1
There are 900 uses of these chess templates on German Wikipedia.
https://de.wikipedia.org/w/index.php?title=Spezial:Linkliste/Vorlage:Schachbrett&limit=750
https://de.wikipedia.org/w/index.php?title=Spezial:Linkliste/Vorlage:Schachbrett-klein&limit=115
A few more of
https://de.wikipedia.org/wiki/Vorlage:Schachbrett-10x10
https://de.wikipedia.org/wiki/Vorlage:Schachbrett-8x10
https://de.wikipedia.org/wiki/Vorlage:Schachbrett-Chaturanga
The syntax is used on many other WPs, incl. eswp, frwp, plwp and ruwp
https://es.wikipedia.org/wiki/Plantilla:Diagrama_de_ajedrez#Diagrama_est.C3.A1ndar
https://fr.wikipedia.org/wiki/Mod%C3%A8le:Diagramme_d%27%C3%A9checs
https://fr.wikipedia.org/wiki/Alexandre_Alekhine
https://pl.wikipedia.org/wiki/Szablon:SzachyDiagram
https://ru.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%A8%D0%B0%D1%85%D0%BC%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0
On English, the VE UI can go into massive layout problems, but the UI issues may all be due to the Parsoid issue.
https://en.wikipedia.org/wiki/French_Defence?veaction=edit
The number of uses on enwp appears to be in the same ballpark as dewp
https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Chess_diagram&limit=900
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
{T55226}
{T53166}
{T73404}",53932,3,Low,False
0.3699467309064164,1.5638531248236234,-0.9088958313391693,-1.6593372869052763,-2.7326006732194523,2.798731986524854,-2.0333950865141825,1.98159026449907,-2.8834967770978714,7.072596166509447,-3.544355676477714,-2.478853910185254,-1.4771850823324764,-1.0095135494712353,2.0838847143224974,1.661813313160577,-1.720597432818595,1.9829951322333306,False,c1,3,"Several users on the English Wikipedia, most recently Salix, have requested that the parameters for templates should be in the recommended order not alphabetical order.
For example in {{tracklist}} it lists ""Track10"" before ""Track2"", and in the various citation templates, ""First"" and ""Last"" should be adjacent.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53930,3,Low,False
-6.631081964892317,0.6417792504461239,2.1341278170215965,4.628638313562664,2.90709790528361,5.184980771601984,-4.197026272176436,-1.3499380066051505,-2.6997321146213187,-1.6296813264231624,-1.4785599005969001,2.924218699803836,-1.1698126492107956,0.37762092886219367,0.7243392327037856,-2.028073694947497,1.4598668820663578,-0.2960577624869396,False,c1,3,"Removing the last reference on a page, with <references/> present, causes the waring:
There are no references with the group """" on this page.
That should be
There are no references on this page.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53873,3,Low,False
-8.255512722914512,2.1334607765457996,-4.250085005575363,-2.3594244893895926,-3.472614492805593,1.973241617244937,1.332529860736381,0.5256992367218558,1.3440893521469943,-0.7606837878540915,-0.41546597134693375,0.8795268562573881,-0.019922942597651705,-0.6916751890867276,0.8912264140817632,-0.22220989349324105,-0.7222197221323686,-0.978791481457654,False,c1,3,"On the English Wikipedia the page title formatting level is never used in article space, although I understand it is used on some other wikis. It might be that other wikis do not use a dfferent page style.
Accordingly it would be nice to be able to remove/suppress/disable this item from the list on a per namespace (or, less ideally, per wiki) to avoid confusion to new editors.
Unless this is absolutely trivial to implement, please regard it as a low priority enhancement request.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53864,3,Low,
-2.0001786046217003,-0.8566894544188255,-0.08598637412952925,4.907639221738286,1.9839292061125406,1.2202836211410564,-4.133294277639992,-0.19926284541630718,1.8685182337546966,0.4669347793921421,-0.5458819654067182,-0.8150170977463168,-0.9389575095723641,-0.9241392746284425,-0.95740797306589,-1.6172963620357208,-0.9611383404061961,-0.12012508375136677,False,c1,3,"At en.wp a user comments:
""The tooltip with a ""puzzle"" icon that appears when clicking on a template should contain the name of the template used. This would allow readers to be aware of which template they're about to change and would make the Templates interface [[self-documenting]], teaching by example the existence of the most common templates.
For example, the next screenshot would contain the word ""Chembox"" besides the puzzle icon:""
Screenshot: [[File:VisualEditor - Template editing 1.png]]
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51827",53824,3,Low,False
-0.8619312791150837,1.2308161571731322,-2.960016013644001,2.167153306417299,4.8991493675732585,-1.6947950006493069,1.4884796838563101,-4.438197771879977,1.0990752323807438,-1.80193468749746,-0.9642267673615228,2.76901349339206,-1.125717836414772,0.9423993642669055,-1.21017917019815,2.457545985932617,-0.3726962960988982,0.8575196465056825,False,c1,3,"If you open up the image finder, identify an image you want and /double/ click on it, the image finder closes and the selected image is inserted twice.
Debian/Iceweasel 17.0.7.
--------------------------
**Version**: unspecified
**Severity**: minor",53823,3,Low,False
-6.907362290126821,4.273582847612662,2.6359684357244006,2.530027847690343,1.9749461348576087,4.837788779879324,2.1582113136616714,3.506289025121661,1.1481311731109405,0.5475832442773401,1.1967773089140805,-0.811175447648791,0.0962376246079959,-1.171782431040163,1.7246744730526355,0.23194096938077308,-0.020550688840538456,-1.0723661811368783,False,c1,3,"In the site settings dialog you can see a list of language/interwiki links for the current article. There is a explanation text saying those can only be edited in the wikitext editor. Because of Wikidata this is now no longer true for most articles. The text should be adapted and maybe link to the corresponding Wikidata item?
--------------------------
**Version**: unspecified
**Severity**: trivial",53816,3,Low,False
-3.383972319768948,-5.314210909080172,1.2927812994160668,3.6493556800967433,1.2769794723967487,-1.767126314171544,-1.2754843262267688,1.5484299281726495,3.6521537763351724,-1.8108549144670785,1.3213864768812313,-0.02944916249807772,-0.7450928552555807,0.41825684579092304,-0.2958000169732262,0.5030309811809429,-0.1639402728141126,-1.81535938923049,False,c1,3,"I could only find one major button that leads to the help pages - the one at the top toolbar. Ideally, there should be help buttons in every context - dialog boxes, inspector, plugins, etc.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T53237}",53798,3,Low,
-5.418563929970571,0.650911445060423,-2.4347935372334586,1.1197111417731027,-0.912836806489276,1.3010309703545857,0.5712881853352689,3.702890456050478,0.004322646210491998,-3.0832607850913387,-3.7555230237994452,-1.9908195843474772,-1.4240310045845481,-0.5731947043698824,-0.45190920820333247,1.152030358588524,-0.8513722882939451,-0.15970736847094846,False,c1,3,"The description of a parameter in the list of parameters does not always fit in the width of the editing add-parameter box, particularly in firefox (where the font size is apparently larger in than chrome) and when users are using large fonts for accessibility reasons. Where this is the case (or always) the description should be shown in a tooltip on hover or when selected by up/down keyboard prior to insertion.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50354
https://bugzilla.wikimedia.org/show_bug.cgi?id=51436
https://bugzilla.wikimedia.org/show_bug.cgi?id=62142",53774,2,Low,
-5.635824553250545,0.8363376069756647,-2.6962369344880575,-1.9810610915024485,4.609755323859746,2.2476708882202425,-1.0202780580772286,-1.2260550729847561,0.3236869151351607,0.054856997349522096,1.3713562170434073,-2.5702084454289924,-1.883398794001832,-2.4895997738110287,3.454254610685619,-1.635745715189578,0.3725951411742845,0.1141739011296441,False,c1,3,"I recently ran across [https://en.wikipedia.org/w/index.php?title=Polycarbonate&diff=prev&oldid=564618311 this edit]. It seems as though they were trying to fix a spelling correction and inadvertently destroyed a table and had an entire section get repeated.
There was a little [https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Strange_Diff discussion about the diff on the Visual Editor feedback page], where it was mentioned that the diff ""is very strange and [the commenter didn't] recall seeing anything similar"".
--------------------------
**Version**: unspecified
**Severity**: normal",53772,2,Low,False
-8.27333758999942,4.874378311241337,0.884055885342498,4.754008238172443,5.996936925831692,8.025942239870815,-0.7666983806583314,-0.49880414281817564,3.9925718536923647,-1.8561860074819725,-2.099095177619959,-3.673884922218651,-2.1435947866207083,0.9569368735322046,-0.12844571471093325,-0.5113422694409616,2.7714918441648724,3.451493709570527,False,c1,3,"An English Wikipedia user familiar with the transclusion dialog expected thatthe way to remove an image from the article was using a remove option in the media dialog. Such an option does not exist, and they couldn't work out another way of removing the image other than selecting and deleting the characters around and including the slug.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53764,2,Low,False
-2.2197556324460956,1.553771227092831,-0.9854083700037766,1.3504819677079274,-2.9141736026237455,2.632203960722305,1.3706191052194834,0.5131015396333961,-3.86746569758785,-1.358841906885961,1.7097051768165952,-0.24861806326246771,-2.4932533784854023,-0.8092976198819244,-0.4670972816514096,-0.8951428171398619,1.6446793284247871,0.3464762290697656,False,c1,3,"After https://pl.wikipedia.org/w/index.php?title=Pomoc:VisualEditor/Skr%C3%B3ty_klawiszowe&oldid=37098556&diff=cur this edit it sees unreviewed pages and distinguishes between stable and unreviewed versions despite a) on this page, both versions are autoreviewed b) even if points [[Wikipedia:VisualEditor/Nawigacja]] (transcluded) out as pending rewiev - the project namespace is not reviewable.
--------------------------
**Version**: unspecified
**Severity**: minor",53747,2,Low,
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53713,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53712,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53711,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53710,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53709,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53707,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53706,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53705,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53704,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53703,2,Low,True
0.8313950082172439,-8.499857832508795,-5.271594485713118,-6.915181847391822,0.7804979118351385,1.8804394278499708,2.7032228225346957,-0.9083301680335338,-1.1526727849005785,-3.6205097297935076,-4.673758844662217,5.111338587659241,-3.966703030994654,0.25266633313614584,3.542666762170481,0.880289131244081,-1.392835413388393,-0.6780564362831358,True,c1,3,"This is how it is configured in WikiEditor; will require icon creation.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53702,2,Low,True
-3.1644928373853034,-1.798267095452898,-3.8425993163960843,-2.935999493879847,1.3399521191750132,3.006273065214411,-1.2296092016820968,-1.0753707387149363,1.9460567161654285,-1.277760606462155,-1.3901258174437878,0.4712720630184266,-0.18301796286215222,0.19576735857461092,-1.321326773728293,0.5208181148013952,-0.3566315855259865,-1.4927222736441088,False,c1,3,"At the moment wikimarkup being entered into the VE triggers a notice warning the user that it won't work - this notice then has to be actively dismissed. It'd be nice if, should the user remove the problematic markup, the notice would vanish.
I'm popping this in as a low-priority enhancement: I appreciate the VE team has active breakage to focus on.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52386
https://bugzilla.wikimedia.org/show_bug.cgi?id=70168",53701,2,Low,False
-2.8504964755713185,-2.1932000713874675,1.779851362273586,-7.880041452963942,6.331800663827286,-6.06021088542357,1.1174649276105555,-5.995356502639896,-2.961811562313869,1.6880796396483655,-2.9864094838339064,-2.510991667402795,-2.7046107495424057,2.4535368381520124,-1.3952838091971378,-2.218911971405186,-1.8286683370683348,-0.09426232876319873,False,c1,3,"If I move an image around, I see the ""copy"" cursor, even though I'm just moving.
--------------------------
**Version**: unspecified
**Severity**: minor",53696,2,Low,False
4.150872377001564,3.1288142195808533,-1.2192170343501871,-1.5314635075833842,5.460542674104021,3.2748803605271046,1.6502712450360972,-0.4395096750297873,-1.0235070289473094,-0.10074004763625588,0.30085754025787015,1.0255333960987005,-0.7960970719970231,1.095713140254702,-1.2287829993680175,1.7766287289132074,-0.16069403631643353,-0.5154061197264763,True,c1,3,"http://it.wikipedia.org/wiki/Template:Cassetto is AFAIK the Italian version of Hidden (it shouldn't be used in articles).
http://it.wikipedia.org/wiki/Utente:Superchilum features a cassetto named Tudù which transcludes the subpage Utente:Superchilum/do.
If you try and edit the first section in that cassetto, Varie, with the classic editor, you correctly manage to edit the /do subpage; VE instead only allows editing the main userpage.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",53675,2,Low,False
-6.268306081149673,-0.5412838254101722,-2.9574949996247923,-0.09288150065994316,1.1374323198340912,-0.9280596299363206,-1.088348633636783,0.19725473217933953,1.0178489280138625,-2.1443008963981316,0.03039387032858709,0.9612985068454838,1.316893740142636,0.5052985308854598,-0.4058331489550753,1.2007340208524737,-0.6469364152472475,-0.12786841906474633,False,c1,3,"When dragging an item in the visual editor (tested with image and text), the editing window does not scroll up or down when you reach the top or bottom of the window. This means you have to make several consecutive drag and drop actions to move an item within a long article/section. Per Bug 51665 the image must be separately selected before you are able to drag it (i.e. each movement requires two mouse clicks).
**See Also**:
{T36307}
{T75240}",53669,2,Low,
-5.01573326039643,3.5310287918882217,-2.4521070403530274,-2.3266139650919353,-1.1073616979129368,4.39011840694561,-0.6384888374736528,-0.4143332235453535,1.1149251647965268,-1.4422472009448808,-0.7831444249121398,-1.8476413449332258,0.2974822068927079,1.6688410085748178,-1.3773268807697185,-0.005072916946981032,-0.9914872299274425,-0.6906737339398532,False,c1,3,"If you want to move an image to the start of a section in Visual Editor the logical course of action is to drag it to before the first character of the first word of the section.
A user of Firefox 21 reports this does not work at all, in my testing in Firefox 22 it appears to work only occasionally.
The counter-intuitive dragging the image to after the last character of the section title does work.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54756
https://bugzilla.wikimedia.org/show_bug.cgi?id=65883",53666,2,Low,False
-4.514091269048384,-0.42997291939725635,-4.427447807324095,-3.261118984355828,-0.39482886976272735,-0.7902367069180019,-1.8921060520448334,2.1305399965472036,-0.5027194980902555,0.13876922565672967,-3.4122543676040795,-1.0855022531183662,-0.2875215751052522,-1.8277398931720494,-0.27850571905716226,-1.6248555820428354,-3.1283153029784723,0.6646982429128949,False,c1,3,"A user on English Wikipedia requests that templates such as navigation boxes that display as collapsed by default when viewing should display as collapsed by default when editing.
""Currently, navigation boxes are always uncollapsed when editing. This can be quite annoying when having to deal with big ones like {{The Beatles}}, e.g. on ""I'm a Loser"", also it might be confusing editors into believing that this part of a page can easily be edited.""
--------------------------
**Version**: unspecified
**Severity**: minor",53664,2,Low,
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,True,c1,3,nan,53613,2,Low,False
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",53612,2,Low,True
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",53611,2,Low,True
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",53610,2,Low,True
1.1973935327835625,-18.726601876177895,-5.305850752077262,-2.8193819740770367,-2.4048219479570645,6.451993417398817,2.6725199311327374,-2.2505950795105734,1.6133146886903509,-2.364097745345876,-4.165317184670486,-1.0690586111259428,-4.012354447799598,1.7336401440817815,1.0564196676656392,-0.30078938155158197,0.6145104988648555,0.4289200192180671,True,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: enhancement",53609,2,Low,True
-6.5013710997426175,1.9273735398858065,-3.8335953591373695,-1.400702611486817,0.8993740911883119,-1.9936724642606796,-0.4664591622551679,2.373544015535815,0.47232969115808765,2.76919587776061,-1.5797841350837816,1.4976138983060994,-0.40348189711615756,2.1747540410061967,-0.27423016802717104,-1.3155403145963924,-2.0355869463614105,1.233303879069824,False,c1,3,"When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"".
This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547.
If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).
--------------------------
**Version**: unspecified
**Severity**: enhancement",53549,2,Low,False
-5.1625951197054745,3.6306840595705943,-6.450677820272164,-4.85369400459609,0.039751655364822835,-2.2121030492349454,-2.6103806582088804,-1.0478547062788892,4.721283761234926,-1.7319305874061035,-0.0028881357650840656,2.550006951636721,2.0912418458766333,-1.5155532458499321,-2.0177569864338434,-0.24148088079720453,-1.271923658266721,-1.0465149732992796,False,c1,3,"There should be a view-source equivalent for the visual editor so that people can see the page in VE as if the could edit it. It should allow them to interrogate things like template, so they can find out which template is producing what they see and how it does that. ~~When VE can cope with copy+paste, then~~ this will also allow them to copy and paste the relevant image/template/whatever to whatever article they are working on.
**See Also**:
* T54004
* T54091",53547,2,Low,False
0.07998775894167531,1.1390952266081484,2.954709362081882,0.6944304336314517,-0.08482170538103229,-0.3088975338747224,1.0776663805103146,1.0334113294073473,0.7315962328896572,-0.023911108041480666,0.5848974134061979,-2.6329186240071607,1.0416880156006663,-2.4222643278050984,-0.6699340104168892,0.1393419976405048,2.8286025810760025,-1.1285902005768782,False,c1,3,"I had OpenODBC's iODBC plugin installed in Safari (latest release, always). After any edit, EMBED tags would be inserted at the top and bottom of the article. This did not occur with the source editor, or any other editable widget, like this one I'm typing in now.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51423",53521,2,Low,False
-6.287387664652703,2.368286619504243,-2.4913439254726253,-3.2278113215600244,-2.272141919347101,-1.9096820873329203,1.4737380834321172,-1.1667760139896386,3.289660433802335,-0.674758135256865,0.07828016884042999,-1.0418405591545101,-0.0755417011638535,-0.6804448008492203,0.07317661922004692,-0.2175812892977329,-0.08623842156543726,0.9615660381191049,False,c1,3,"The data->DOM converter should construct its DOM bottom-up, the way https://gerrit.wikimedia.org/r/74058 already does for annotations. This would enable us to do some cool things like:
* Pass childDomElements to nodes and meta items (already done for annotations)
* Pass data content in addition to DOM content?
* Allow nodes and meta items to unwrap themselves by returning an empty array (already done for annotations)
** We could implement unwrapping of generated wrapper paragraphs using this feature
* Possibly change the API so that instead of returning an array of DOM elements, the toDomElements function is responsible for appending its children.
** This could replace handlesOwnChildren, and enable model types with complex output
For DOM->data it's not as straightforward. We could experiment with bottom-up (outside-in, really) building there too, but it would be a bit less clear how things would work, and whether the copying involved would affect performance (although I believe we may already do a fair bit of copying around as it is).
This may be my pet project for my flight to Wikimania, or I may end up doing this sooner if there's time.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53501,2,Low,
-1.0026613273864502,-0.6857198480074942,-3.0498536060574377,-7.781379445445712,-0.8426560305554861,5.734984819914787,2.6972043377520185,2.4653343481944106,0.2609977935551989,0.7247991913754586,-0.6334991307486759,-0.7524270193200951,-2.0969735334556328,2.2200206280229127,0.21717950385099627,-2.3733575181487083,1.3124973037812062,-2.03334557098302,False,c1,3,"Right now, ce.MWInternalLinkAnnotation obtains a DM rendering to get the computed href. We should factor out href computation so that this isn't needed.
--------------------------
**Version**: unspecified
**Severity**: normal",53487,2,Low,False
2.286281237325474,1.0300496028123742,-0.8665022203120945,-0.1910725642439084,-0.08903988739785906,0.10739371822095256,-0.48565528450700324,4.118450170649064,-2.5260418789214487,3.833659340506941,-5.516020523476554,-0.18797620901410317,-2.7904005308704347,-0.3112141891269795,0.9881234105886172,-1.6547537078618553,-1.2293347935434624,2.1542288124254654,False,c1,3,"If someone is clicking on ""Mobile View"" and then back to ""Desktop"", a stopMobileRedirect cookie is left behind. This cookie will disable central notices on all wikimedia sites perpetually
--------------------------
**Version**: unspecified
**Severity**: enhancement",53465,2,Low,True
-1.452644195527703,-3.163414240837767,-1.4195691965361856,-1.1755601400716023,0.21239290936931343,1.339746948355666,-2.0384230394355107,0.15099648229249962,2.2371955480273353,3.9476727311890762,-1.7609800963127424,0.4565963030531499,-0.4308312141717554,-0.810599606330662,1.5548888972463288,-0.4410013922642565,-2.2319616562272926,0.5125770777573397,True,c1,3,"There is consensus for a change to this element here: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Dustbin_icon_not_intuitive_for_.22unlink.22
To summarize - the garbage can icon to remove a link is not intuitive. Users may be unsure of its function, or believe it will remove the highlighted text, rather than just the link. Most other editing UI's employ a broken link for this function, so it will be more familiar.
Suggested improvement:
*Replace ""Garbage Can/Dustbin"" with a ""broken link"" icon (example:http://us.fotolia.com/id/49483380)
*Replace current rollover text ""Remove"" with ""Unlink""
--------------------------
**Version**: unspecified
**Severity**: enhancement",53464,2,Low,False
-5.797893394206659,2.902566653721806,-0.2638309398416627,1.0007626761349222,4.740889619350385,5.002875675197762,-3.718694395924352,-5.088237188762309,2.340939319416009,-1.2804488161936778,3.6048869102171515,-1.05813514452552,-0.5947632833926741,-0.279573135696082,0.6897025364086273,-0.49785329964757163,1.9760777224436177,0.4750225825687229,False,c1,3,"See:
http://en.wikipedia.org/w/index.php?title=User%3ACananian&diff=564446937&oldid=564446873
I was adding a heading (after a <!-- ... --> comment) and the diff stuck a <br> inside the ==heading==.
I'm assigning this bug to VE for the moment, but it could be a parsoid bug. I need to see the intermediate parsoid HTML generated for the change to tell one way or the other.
--------------------------
**Version**: unspecified
**Severity**: minor",53444,2,Low,False
4.863169045107426,-12.927921783796853,9.312774066277111,4.310912976583843,0.3759474399554057,-5.495519209854509,-2.533477930167448,-1.8897944267464797,0.10285248645763562,-2.8525600651607266,-2.0462235367669326,0.24790889433554741,2.292168471265775,-4.078068617985466,-3.0954235032892576,0.23212211313224715,-0.7308760088513965,-1.219934679652385,True,c1,3,"```
[subbu@earth:~/work/wmf/parsoid] echo '<a rel=""mw:WikiLink"" href=""./Foobar"">:foobar</a>' | php bin/parse.php --html2wt
[[:foobar]]
[subbu@earth:~/work/wmf/parsoid] echo '<a rel=""mw:WikiLink"" href=""./Foobar"">:foobar</a>' | php bin/parse.php --html2html --body_only
<p data-parsoid='{""dsr"":[0,11,0,0]}'><a rel=""mw:WikiLink"" href=""./Foobar"" title=""Foobar"" data-parsoid='{""stx"":""simple"",""a"":{""href"":""./Foobar""},""sa"":{""href"":"":foobar""},""dsr"":[0,11,2,2]}'>foobar</a></p>
```",53442,2,Low,
-4.103552596081864,2.0675302743438237,-3.5605577186712623,-2.0703867109254115,1.2862929084683605,0.2789339406582134,-0.47690243709637237,-0.13145285633203874,-0.33335884727714377,0.051175214364231,-0.7077313598091379,-1.2979849810115354,0.7629997320844737,-1.313041117448266,-1.3191994274425891,-0.9156256502047864,-1.5573068797161178,0.6952802086966929,False,c1,3,"Currently, if you use TemplateData for a template without any parameters, you still have to create an empty ""params"" in the JSON (not really important), but you also end up with a ""Template parameters"" table with just the title line (Parameter Description Type Default Status).
Rather than displaying an empty table, I think it would be better to display no table at all, or a simple message saying that no parameters are defined for this template.
--------------------------
**Version**: unspecified
**Severity**: minor",53429,2,Low,False
-4.631154814319361,2.564753017833276,-4.324830763819108,-4.947630311771627,1.5560345221676264,-3.1687768133011094,0.4673941256135681,-1.2137845090407295,0.13931250998448158,-1.193026468177659,-0.13557000599923041,2.382441441656061,-0.3609481674320927,-1.7977227985774,0.9662990453513407,0.5545776728703733,-0.06406895065565599,-0.07624928807708375,False,c1,3,"Seeing this more often now with VE and think it may be a couple different issues (not all on our side) but want to see what we can do to stop it and or lessen impact. This is currently being added to the security queue because I'm a bit concerned about some of the symptoms and worry it could be an injection vulnerability (see below). If we rule out a security concern I'm obviously happy with it being moved.
Editors are making a normal edit and div's are being inserted like
<div id=""myEventWatcherDiv"" style=""display:none;""></div>
often at the start and end of the page.
Googling around it seems they may be inserted by a common 3rd party plugin (divX?) but it is in no way clear. It also seems to be interacting weirdly with VE because it isn't only being inserted it's inserting WITHOUT <nowiki> tags which is what you'd expect if someone put a div in (see https://en.wikipedia.org/w/index.php?title=User:Jalexander/sandbox&diff=564465081&oldid=553572859 ). Could it be being injected somehow around VE and/or parser?
Examples:
https://en.wikipedia.org/w/index.php?title=Spank!_The_Fifty_Shades_Parody&diff=prev&oldid=564448990
http://en.wikipedia.org/w/index.php?title=Kendra_Morris&diff=prev&oldid=564426900
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51521",53423,2,Low,False
-0.38705432068022017,-2.04448029928783,0.46687013309081493,1.4275415524270612,2.3963325572255463,-0.1108155072142617,-1.6296605381510023,2.0945956220223105,-1.376673285203032,1.531140372358239,0.6625522891305637,0.06900304747427888,-0.6893259950570245,-0.47658678306819,-1.8057693597210154,-0.1453491357270817,0.9105467839393395,0.21067263591868213,False,c1,3,"In view mode, [[Template:Top icon]] places the featured star or good article at the top right hand corner.
After loading a FA or GA or English Wikipedia, the featured star or good article icon appears where the template is, which is often down the bottom. This is perfectly acceptable except for the 'where did it go?' feeling, but maybe a plugin could come up with a better UI design for topicons, geocoords, etc.
Also templates without any real estate (like {{Use dmy dates}} and {{Use Australian English}}) 'disappear' entirely.
https://en.wikipedia.org/wiki/Angels_Brought_Me_Here?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51322",53420,2,Low,
-6.598272101079449,-0.7617012628225766,-1.615587030756954,0.8067624400444069,-4.730677665151472,7.478812514861516,-1.1971896174776733,-1.3221040482723083,-2.2817500443855354,-3.6653028879176905,-3.3415128375208285,-1.8643371176814916,0.9407964773387265,-1.3841896450519195,3.0393702289804745,-1.562980828852301,1.0754591599902683,-0.570476165240696,True,c1,3,"Forked from the original request at bug 48666 which was solved by making the preference hidden, as intended.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53411,2,Low,False
8.147683220252743,12.563261063315384,0.34896946382157523,-3.785482658797154,-7.563062492924018,1.4217471012460863,-14.524112670733267,-1.8206693155328781,-0.37534155778361566,15.07614270418113,-8.363914436428555,-0.3185417879677529,-0.9815495106074223,-3.133143947679467,3.4551088032881205,2.9550888167061107,-4.883159234805968,3.1530253928016396,False,c1,3,"As in Bug T53330, I would like to request the icon for ""Bold"" to be an ""N"" (from ""Negrito"") in Portuguese (""pt"" and ""pt-br"").
",53392,2,Low,True
-3.1215058928784156,2.2063172893382124,-2.285818088729938,0.21855007590187037,2.3165044998297293,2.2840802141975347,-1.7867035717970694,0.04703181536645923,-0.24375315372639922,-2.485874628419257,-2.077079116178213,3.090902904113081,0.5592191653126122,0.4702214585818165,-2.7214278736215163,0.054643598624915635,1.267140743272768,0.48953402380088584,False,c1,3,"Use case:
* The user opens VisualEditor
* The user types something that looks like wikitext
* VE notices and displays an mw.notify bubble with autoHide:false
* The user leaves VE by clicking on the Read tab
* The editor is torn down and we go back to view mode, but the bubble persists
I would like to be able to remove this bubble when the editor is torn down, but mw.notification doesn't expose an API for this. There is a .close() method on Notification, but there's no way to get the Notification object created by mw.notify().
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",53338,2,Low,False
-2.5662526490121254,-0.6796668378826585,0.7790041055173624,4.887262799099276,0.8835426847285255,-0.21678025649277122,1.1870630979617838,0.7067270986707513,-4.31772464634247,-1.0201741333266736,2.811297023680272,3.1511284781274966,-1.4747039981011696,-2.418994923917818,0.4775392329509742,1.9006815859656792,-0.46011999587320684,0.4026915445512278,False,c1,3,"If an article has
[external link]
[external link]
It is rendered in VE as:
[external link]↵[external link]
Selecting the ↵ and pressing delete causes the ↵ to be removed, however the link break is not removed, and saving says that there are no changes.
Example:
https://en.wikipedia.org/wiki/Otis_%28album%29?veaction=edit
--------------------------
**Version**: unspecified
**Severity**: normal",53336,2,Low,False
-6.697288413124369,2.5516802919409933,-3.035937724648061,-1.713049266351542,5.245879193065937,-1.69444751633801,-0.03810507062008117,1.3992688003665879,0.06967936319420082,-0.2607283235794151,0.4147956328764266,0.3451680643602315,-0.04362158570105379,1.4237782773467043,-1.1184699754537295,0.06777593166151591,-1.1863342685012306,-0.044582569813613526,True,c1,3,"The way VisualEditor handles links with square brackets, but no explicit anchor, can be confusing. These links are generally discouraged on English Wikipedia, but still occasionally used.
An example is https://en.wikipedia.org/w/index.php?title=User:Superm401/Sandbox&veaction=edit&oldid=564175896 . The wikitext for this is just [http://example.com], which renders as a linked [1] (or whatever number it is in the page)
However, you should edit the latest version of a page for testing this. When you edit an oldid page, you won't be able to reproduce the ""Save page"" disable behavior I mention below.
VisualEditor lets you backspace to remove the characters one by one, which does not really reflect the model of how the link works. After one or more is removed, ""Save page"" un-greys. However, when you go to review the changes, it says, ""Could not start the review because your revision matches the latest version of this page.""
It does let you remove the link entirely, but to do so you need to explicitly remove each character (not just backspace once to delete the whole thing).
Do a fresh load of the edit page (separate test). Then, click the chain icon next to the link. Then, press enter twice to exit the link dialog. This time, review changes works. The wikitext becomes:
[http://example.com <nowiki>[1]</nowiki>]
It probably should not change the link if you simply enter the link dialog and press enter without changing anything. Also, forcing it to text like this is inconsistent with what happens if you delete the right bracket (see above).
--------------------------
**Version**: unspecified
**Severity**: enhancement",53309,1,Low,False
-0.0191900672627785,0.18777195778929112,-0.500470523590824,4.875581155755425,3.080582098751297,0.17032784031695414,-0.9324778936267659,-2.7447503677616423,0.3627185599910764,0.2962264316663932,-1.5684226711236071,-0.16865550848483468,0.5624690935310714,-0.8645605206460667,1.4093245324024632,0.0983911032699174,-0.8907771695883379,-0.40637386955821264,True,c1,3,"From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):
It's not a high priority, but still, a suggestion: the default search text, for an image search, is the complete page name. So, for example, if someone is editing a draft article, at User:WhateverEditorName/Article name, the default search text is ""WhateverEditorName/Article name"". It would be better if the default ignored the final slash and all text to the left of it; in this case, it would mean the default search would be ""Article name"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",53290,1,Low,False
-6.816423055597154,4.439047943284141,0.7084034333487459,5.66614550712847,5.237799330643268,5.186722956179751,0.20251006792108495,1.127831811410155,0.13063552425992125,-1.1620543015326583,-0.19485218791577985,2.3926125278109787,0.22655291974259484,-0.18753432190508512,-1.6071818438459275,-1.8644751235549704,-0.7160204199513543,0.7084271687801615,False,c1,3,"When using the Maxthon browser, clicking on a link (wiki or external) opens the link instead of allow ther to alter the link object.
After the linked page is opened, returning to the VE shows the link object icon which alllows the link to be altered.
--------------------------
**Version**: unspecified
**Severity**: normal",53269,1,Low,False
3.842642819261797,-3.830707366307845,-2.09558381438279,-0.6907033118009629,0.6309360893167328,-0.3069896239980274,-1.1170001156210452,-1.8219049968400367,-0.6592834432544661,-1.6892509600666292,0.3843760582265685,-1.3008189741708776,4.132331237527817,-0.4366534545098748,-0.728616171276756,0.6773919652748226,1.5045656192067323,1.909872857982892,True,c1,3,"Copied from English Wikipedia:
Editing Gol Transportes Aéreos Flight 1907#Criminal proceedings I added two cleanup templates, {{update}} and {{prose}}. In the visual editor the two templates were differently left-aligned and different lengths, despite saving and displaying correctly. Reopening the page in the visual editor, the templates appear at their correct size and alignment, but do appear with an apparent blank line between them. Thryduulf (talk) 14:04, 12 July 2013 (UTC)
See screenshot:
http://en.wikipedia.org/wiki/File:Visual_Editor_screenshot_-_templates_not_aligned.png
****
I could replicate this on Firefox (Windows 7) but not Chrome.
--------------------------
**Version**: unspecified
**Severity**: minor",53252,1,Low,False
0.1150279609551732,0.9351367464247708,0.5702941421493364,0.5338414051401807,2.142917704722626,-3.6188048817041647,-1.8852090006285342,-4.4487199270735625,0.2952117879219447,0.8859673131122907,-0.9600307306555225,-2.701637709187583,-0.04923397889288683,-1.9402756710464275,1.5962270074407998,1.1276545433857565,-0.40904845696118963,-0.34108749673924077,True,c1,3,"I was following Sherry's kind advices in my sandbox at enwp http://en.wikipedia.org/wiki/User:Elitre_(WMF)/Sandbox:
<<you can create an {{Infobox person}}, with parameters like ""name"" and ""occupation"". Within those parameters, you can type the wikicode for any templates you want. For example, you can give it a name parameter of ""Alice Expert((citation needed|date=July 2013}}"", which later gets processed properly as a template. >>
An infobox appeared (well, a box with my sandbox title, actually), I saved, ""your edit was saved"" message appeared, the box isn't in the page anymore.
Tried again, same thing. No trace of my activity in the history. Win 7, Vector, both Chrome and FF.
Thanks,
E.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52640",53243,1,Low,False
-4.727160503428593,-0.5578630287587973,-0.3056791265484655,0.9737634774735979,7.191420296095362,2.2218063219761914,1.267456668275261,-2.110074073028006,1.5711646377952677,-0.8347833399308624,0.9183567078437069,-4.00877934894623,-0.014074204468000673,-0.9165142027910274,0.902623238399813,-0.5860964883609994,-1.0981212156016291,-1.7979066993810298,False,c1,3,"Screenshot
Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11227}",53236,1,Low,False
-10.211714507330033,7.771342581280294,2.9514629364594853,3.459813870753454,-4.052859720498258,1.713653693367849,2.1941742932132966,-1.4476193356275284,0.4672896895174693,-0.7777023575416857,-0.8513014154884866,-2.5670935878432415,-1.6016620881704968,1.1498161416562978,-0.042868536319288886,3.5839038860999675,-1.500269084924267,-0.8478847221078485,True,c1,3,"A few users at itwp requested that the list of articles you can choose as a wikilink target supports right-click on each title to view the page in another tab; and that disambiguation pages in the same list appear differently (maybe italicized as it currently happens in MediaWiki special pages?) Thanks!
--------------------------
**Version**: unspecified
**Severity**: enhancement",53205,1,Low,False
-8.894217566276001,2.153380293671262,1.2795277527304343,3.4930367303012533,5.359534752309884,4.3197013460129146,1.616436689627485,4.712215078315096,-2.303700261362346,0.5587349415457528,-0.6569671002534667,-5.6879527527189815,-0.5369626834088841,1.1250185584979215,-0.017290372432360535,0.27043778161363086,-1.9800696637884703,-1.2438816017435803,False,c1,3,"Screenshot of problem
When a page contains multiple floated blocks after one another that each have a context menu (e.g. both transclusion) the ones after the first get the context menu in the wrong place. Namely on the second ""line"" of the article instead of where the element actually is (much further down).
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11059}",53167,1,Low,False
2.3222383178204775,-6.017800408551791,0.7486778341184248,-4.543859572491748,3.050251150765394,-3.8540798521686375,-1.6822350734263356,0.7636005984610855,2.4668061076647465,1.3793008538527705,-1.6793454485133812,1.1300880626642,0.08048077813142385,-0.7658168843550346,-1.2423816798378118,0.1851331905637532,0.7430566712392983,0.5738010775695879,False,c1,3,"Go to https://en.wikipedia.org/wiki/Mohammad_Azharuddin - look at the infobox image. Then hit ""edit"". I have no idea what's happening, but it shouldn't be.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
{T53932}
{T55226}",53166,1,Low,False
-10.770558732224458,5.080276862656628,-1.1428726036079286,-1.2490986234782313,-2.379008883651841,2.2955919495632315,1.7265359047689257,-2.271930847853993,3.9417742655550843,-1.1966148758053485,-1.6603908429798004,5.2678739066229365,-2.5005178627427345,2.5676705101506982,0.9129068622280299,-3.9933836188411838,-2.7212511163131485,0.016274127368207436,False,c1,3,"If would be nice for power users to have an option to disable the popup warning that occurs when you are trying to leave the edit mode while you have done some editing.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53057,1,Low,False
7.158301135198789,4.278428189499504,6.769986521647617,3.8565004171142894,3.326162153535808,1.6628898417323013,0.356420505633964,-1.8144664774047556,1.3946772311474018,1.2482096243481848,3.3871046768763207,-0.10357455313606057,3.8537019913662944,-0.03885882797807838,0.008337705982957466,0.06030647452995608,1.607551776617681,1.2402122461006584,True,c1,3,"Editor requests support for adding non-breaking spaces ( ), keyboard shortcut?
From MediaWiki Feedback:
How do I enter a no-break space (& nbsp;) into the source text via the keyboard? Something like Ctrl+Space would be nice … And, BTW, can I see the difference between a regular space and a no-break space?
Troubled @sset Work • Talk • Mail18:03, 8 July 2013
--------------------------
Alternative: {T70429}",53045,1,Low,False
-0.3715454717218307,-10.764977878962576,0.28783295517740015,-4.811944123403039,0.4315610652492714,-1.3809448025785998,1.3450553199474626,3.9456266400691886,7.274809735357198,-0.5835283324473508,-1.1939157112073404,1.0400804712174618,-1.4708352527062996,0.5695072505678409,1.5996957122020197,0.6440805602551318,0.2873499788651135,0.7599012053428214,False,c1,3,"You should be able not only to change image caption, but select another image.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54285",53033,1,Low,False
0.9051803148519695,4.2807303375416765,4.473483989236438,-1.0886943792822446,-5.407100022510662,-7.6125969552542685,-0.6024623822779702,-4.179497274696354,2.3192786160708865,2.5803005496845106,-0.7802095025996465,2.256640634434783,0.49037275450490103,-0.36921010707841617,-1.8991046688718343,1.041462594616743,-1.0603036639672472,1.4077522582413236,False,c1,3,"Try to add image to http://uk.wikipedia.org/wiki/29er_(%D0%B2%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4)
It suggests no images for article ""29er (велосипед)"", but it will if you search by Commonscat template parameter or english interwiki
--------------------------
**See Also**:
{T54464}",53031,1,Low,
-4.647581935184476,8.715466189417587,-0.9858437311135955,-4.875432467853344,-5.71839050063388,-0.514351760009939,3.2570293791838223,-6.059341145879263,-2.8124134626853943,-1.1176471440580373,-0.44529406885910694,-1.5374487916612158,-0.7235577459170743,2.933075635925234,-0.5870908851652574,1.1383370251749525,-2.678589175398251,-0.1172029261380807,True,c1,3,"Two editors have commented independent in different place over the weekend on English Wikipedia about how they wish they could access the edit summary while using the VE instead of on save, because they track their changes as they go.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52961,1,Low,
-3.139271486465629,1.8985686826693389,1.4744579317702282,7.849206473796171,-0.9971453118838971,3.9030931296431532,0.7393133409948973,-1.1968478549668506,-1.3843402383361256,-0.7702903933436653,1.109402398577474,-2.1237368399660657,1.7354673816439266,2.8696476514977034,-0.19694494639295002,-0.6168557267112955,-0.5670483427679686,-0.35002207238897265,True,c1,3,"An editor from pt.wikipedia writes:
[E]ditnotices seems strange inside the flyout because there's a weird padding inside the popup, without the padding the templates would look nicer (there´s already padding in most edinotices templates by default). Dianakc (talk) 23:56, 6 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: enhancement",52956,1,Low,
-1.3079191150330145,4.180215016391209,0.0687823881505949,-1.119412580926184,0.9073041975513043,1.7512863727400914,2.6655599340509406,4.290473504081864,-1.9047749762032102,-0.4250117133560005,-0.5199074835850594,-3.540294381651538,-0.2609484734343823,-0.7669733608454816,-1.0930996574725143,-3.5102378567883714,-0.0026796977613645634,0.5707277001480147,True,c1,3,"Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.
https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441
https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206
https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797
I'm not sure if this is related to an existing bug or a different kind of thing.
--------------------------
**Version**: unspecified
**Severity**: normal",52938,1,Low,True
-7.154392422681727,3.721117975701926,-1.21281793085293,-1.7507984761612763,4.777275640044483,1.7716823951753715,1.4302133596509572,0.448244024342063,-1.835308970068114,6.745441549278018,1.0992831854851342,-2.4029911934828423,-0.7438305346261416,2.451405872434136,-1.116098115190285,0.07420337560072754,1.8864409895639735,-2.212333898928678,False,c1,3,"The save dialog uses a gray color on a very small text. This isn't good for contrast, and gives it rather 'light' color which might communicate a 'disabled' state to some users, which you don't want with a license text.
Just as with Special:UserLogin, I think we should switch to a slightly darker gray on small text.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52904,0,Low,False
0.6651062563055894,1.9915349624894354,-5.07212696234844,-4.456531580256479,-1.2306723536027908,-1.326214065178301,-2.402195623219956,1.4040276469835247,2.624658412566437,-2.149747618502142,0.60936619361072,-0.48788588810946765,-1.3390850138984298,-0.6564542844203594,-0.1459904597355317,0.010066561760839476,-0.4325680875326252,-0.9576768434314185,False,c1,3,"Perhaps when the [[WP:Tutorial]] on enwiki is updated for VE, we will want to enable VE on the tutorial sandboxes.
Also, when VE is enabled for anonymous editors, we might want to turn on VE in the enwiki [[WP:Sandbox]], because otherwise anons won't have anywhere to play with VE (they cannot create user pages).
Perhaps a category (similar to the way AFTv5 does it) or MediaWiki page (like Echo blacklist) would be the way to do it.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52883,0,Low,
-1.106931233506327,1.6523637850089408,0.3869963071216098,0.17916194244454764,-2.965998484827538,-0.668832029274562,-1.482995606159557,-0.18678900388294706,0.26201323535462195,-2.677436109276112,-1.7104452017083756,-0.15897798540984387,1.1743497871206485,-0.8613907802060856,-0.7658438285626623,-1.2020773650008971,-0.055929042620252556,-1.0922000464681294,False,c1,3,"**Author:** `KilliondudeWP`
**Description:**
1) Have categories on a page with a stub tag underneath - https://en.wikipedia.org/w/index.php?title=Rosebud_Ranch&oldid=563208475 (note that this is SOP on enwiki per https://en.wikipedia.org/wiki/Wikipedia:ORDER#ORDER )
2) Edit the categories using VE to deleted one and modify another - https://en.wikipedia.org/w/index.php?title=Rosebud_Ranch&diff=563208669&oldid=563208475
3) End up with newly formed category underneath the stub template as well as some line breaks taken out.
I reported this in #mediawiki-visualeditor while everyone was sleeping. This is something that might just need an enwiki fix since we like to put stub tags under categories.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
* {T51143}
* {T55508}
* {T74048}",52882,0,Low,
-8.730133511779151,3.876564442547796,-0.009495441209672606,-0.44916733921417595,5.443827734621099,0.3304664088273854,3.6446854472217227,-3.0647518587501157,0.12845579882791908,-0.037297990323930996,1.34573268422464,-3.9886692100423327,-0.4718663031035222,-3.0877149765102185,4.933380032151139,-0.895480334944013,-0.9826957235098207,-2.545229592550821,False,c1,3,"When I edited an internal link and pasted in Work_breakdown_structure#Terminal_element as the new link target, the link editor widget thought that it was a new page, because it didn't understand that the # referenced an anchor within that page.
However, that was just a harmless warning - it did work. So I am classifying this as minor severity, because it is merely an incorrect warning message that could confuse editors.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52881,0,Low,False
0.4466106422122933,1.646814473212391,-2.33923274428531,-4.847984320273305,-6.286883594700393,2.0352845490598437,-0.4333954961841675,0.10249117684482106,-2.7487402268980237,-2.593815795382994,-1.815388439002092,1.2029031807548527,0.648851610330444,0.07898935658150208,-0.5986471450828015,-1.2483886025469608,1.2568766040596147,3.1999644095145507,False,c1,3,"This bug was cloned from bug 50120.
(In reply to bug 50120 comment #5)
> We believe that this is now fixed (due to fixes in Parsoid). Please re-open
> if it recurs.
How do you know what version of VisualEditor or Parsoid is running? Looking at Erik's comment (bug 50120 comment 6), I try to go to [[Special:Version]] to figure out what exact versions of Parsoid and VisualEditor are running (for debugging purposes and to figure out if this problem is still present in the latest bleeding edge code) and I find that Parsoid and VisualEditor are both marked as version 0.1.0. Not quite helpful for debugging. Splitting this issue out.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52879,0,Low,False
-0.6475616176740733,-5.341090660841113,-0.3133333877106761,3.1408270340640803,5.844904755645539,0.7201359982962849,2.5964446675579564,-2.4843643871660603,0.7527087449638443,-2.784429106448914,-3.1954242408119096,3.4361941998836807,-3.0384801366794827,0.5663524800990487,1.6375654303606302,0.42364753854108717,0.16490073211804912,-0.38655122771631345,False,c1,3,"**Author:** `gigs`
**Description:**
I see that a cancel button has been added, which is an improvement, but the escape key should also cancel edit mode.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52868,0,Low,False
-3.4242792850212904,0.6969893512289556,-5.823793753474506,0.13130456917811584,-0.5678213462980818,-1.8598766079507032,-1.4328278450026088,-0.6607285413963869,1.6081130421673737,0.5559484599928055,-0.19420269397541068,-0.2641551238215477,1.2201063088509465,-0.03865317612822139,0.08064517539885419,-0.4867227528562883,-1.108792906200875,1.3005274504832458,False,c1,3,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}
Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE.
Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one.
**See also:**
{T54607}",52855,0,Low,
3.748610784188356,2.8842060865543893,1.2010821244971552,0.5635966023206895,0.3214764651739138,-0.19794816711887875,-0.7824243212928357,2.5502289584439906,0.38168021855564715,-0.23322295025030115,0.4339738201678949,1.2375276188126236,-1.3249729855933863,-0.9811398497180428,0.04930346029958077,-0.4010623452559873,-0.18015365270520078,2.310325991419081,False,c1,3,"Original Bug title:
Provide an API to activate VE on arbitrary textareas for Gadgets and user scripts and document it at [[:mw:VisualEditor/API]]
Please also create a mailing-list for those API updates.
Issue:
Since users will not be able to understand Wiki-Markup, please provide and API for turning-on VisualEditor on <textarea>s. Example use case would be the Translate Extension where translators still have to enter wiki-markup or LiquidThreads or whatever is adding Wiki-Markup to a page.
Providing an API to Gadget authors and other tools is an important matter; nearly all edits are made through gadgets at certain pages; thus it is not just an ""enhancement"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",52827,0,Low,
-4.4011946152437025,-4.423004291485517,-0.5301152377072693,7.014656731333421,-2.165215329464068,-0.8247480215749634,1.3688381434877064,0.48261507286410277,1.2405446427085842,-0.21069299254531426,0.3391436395819345,-0.2863538853386606,1.4339468543977834,-1.9182566965594923,-1.3287290123157414,1.2975267380519393,-0.998817917661881,-1.086448772208764,False,c1,3,"narrow display
Seen in Chrome at least
* click Transclusion
* add a Template; add-parameter display is fine
* add a parameter to the template
* click Remove parameter
resulting display is too narrow and does not display fully
* add a new parameter in the garbled display
display of parameter value show echoed/ghost characters as user types into parameter input
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11254}",52814,0,Low,True
-5.016945990816552,0.16675539496723069,2.9930989857070287,5.155799956317001,3.5483329832688413,-0.759908315735111,-0.0025864607411518747,1.903543868344732,1.2635216119773722,-1.625778598063329,-2.9342425269454537,3.5743483591488294,-2.7114897711104042,-1.0542750666014098,3.3056880595440097,-0.4021950966390726,-1.838014611250193,-0.6766074926734249,False,c1,3,"The wikitext editor <textarea> element has a CSS class ""mw-textarea-protected"" when a protected page is being edited. This can be used to provide custom styling for this textarea, mainly in order to alert sysops that they are editing a fully protected page.
A similar CSS class name should somehow be provided for VE.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52783,0,Low,False
-4.912360817534493,4.9759212405545625,1.9499703729293323,0.3850762242743644,1.3825488956081404,0.5063134389323634,0.5178991874534242,-0.47039863982300667,0.02403696610375,-1.1282908684295454,-1.6826755181704534,-0.831397591395077,-0.7942049368594573,-0.8267610950985622,0.15244011223123088,0.011695806429341149,-1.8667406382390883,0.3302517722557352,False,c1,3,"If you Ctrl+Click a link in the VE, it'll open (discovered through trial and error). Presumably the cursor when hovering over links while Ctrl is depressed should be the hand icon, rather than the typing icon.
--------------------------
**Version**: unspecified
**Severity**: minor",52741,0,Low,False
-4.637109273299596,-1.8083217340144522,-2.8189129852462056,-6.0267887705260135,2.706071804710962,-2.24790122215528,3.330397813447447,-0.10226716547034465,-1.6573654147067656,-0.09858467720013131,1.2086361143494622,2.9328575138411708,0.35090463116732806,1.3451710032065574,-2.9655794957508097,-0.09701204490833937,-2.383499623049693,-0.6827430253430882,False,c1,3,"Screenshot
See screenshot; not sure this is how it's meant to look, but it's how it looks. If there are no unused parameters it seems like the box notifying you of such should overwrite, rather than sit under, the search box - that's unnecessary functionality if all available parameters exist.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54094
**Attached**: {F11039}",52735,0,Low,False
2.0567483392852624,-4.847874025631256,0.6488239954735775,-3.983643058554682,-6.709092291428135,0.8907267700943446,3.793120449062326,-4.7411230864285026,-3.332315340806594,-0.27568196041625725,0.24462582432766977,-0.5948283235924726,0.8541066820770373,2.937829377152638,1.3570105917398356,1.3881749432978288,-1.973831789646209,-0.34205280763652834,False,c1,3,"Since Parsoid has dropped it in bug 46027
--------------------------
**Version**: unspecified
**Severity**: normal",52734,0,Low,True
11.202828387420862,-11.130700754506707,-0.20760464392467703,-0.7629912452815242,1.061839122922236,2.316931309212463,1.3434958851206655,-0.30822718300734286,0.7434754762310034,-0.7316589701420693,-0.6738875591802804,0.26611225750740064,0.06454668365660154,-1.5590775192669422,-1.1637535043364764,-0.9419463391911631,-0.19351064458987088,2.0655963907269026,False,c1,3,"**Author:** `lunarjam.mcgahan`
**Description:**
MS Word document describing and illustrating the bug
See attached document. O/S is iOS 6.1.3
--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: other
**Attached**: {F11914}",52714,0,Low,False
-7.166012545162955,7.107661268319763,-3.614979659625247,-2.5854209410320776,-0.5034624411226748,3.3403376148331745,-0.5130877862220746,0.6359380088637874,3.8705990791270297,0.2233051699162898,1.3835751511146888,-0.6771480583728561,1.3628666656516035,-1.1520308128411418,-0.32434263189800383,-0.23876508824970621,0.8489180560052134,-0.3013583539348683,False,c1,3,"Very often I find that there are some tools that both these editors (VE and the old editor) that I would want to use on the same article. But there is no way to do so.
It would be a very useful feature of the VE if there was some way (direct, or indirect; like through the show preview button) for editors opening an article in VE to be able to edit the same article in the old editor without having to save it or discard the changes made.
Such a feature could also come in handy for other editors who have started editing through VE but couldn't understand the interface/needed to switch because they realised VE could not do an action they wanted
--------------------------
**Version**: unspecified
**Severity**: enhancement",52698,0,Low,True
4.605192389161214,-2.2008031516014483,0.8656509562258101,2.444382549659254,-2.885186636277827,-3.2765417960898597,-2.7158762525972593,-1.1337030435066053,0.8197112497346393,-1.585157282978063,0.3826636768801217,0.4064905242400687,-0.5211964148311337,2.0253495896707605,1.4074867404914473,0.19020062047545921,-1.948128984484739,0.8014922256997099,True,c1,3,"Copied:
For logged in user, can there be a formatting preference to display [edit | edit source] as [edit source | edit]? --J. D. Redding 18:47, 3 July 2013 (UTC)
The user finds it frustrating that he keeps inadvertently selecting ""edit""
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56337",52688,0,Low,True
-5.663633313557051,6.121353832989158,-5.666604672963572,-9.615445404979447,-5.150720639882596,-3.5177747202951357,-9.587076668658845,-2.0137932730421695,-3.636556790844355,-5.189402074043494,9.320318584062619,1.6479290976296548,-6.043076418714761,2.9696390132520563,-1.1874239898770576,-1.6699528739887284,-2.9745042489827833,-1.1114942068224267,False,c1,3,"what it says on the tin; if you remove the first character from [[foo]] to change it to [[moo]], what you actually end up with is m[[oo]].
See also:
* T52745
* T52945
* T55495
* T52452",52678,0,Low,False
2.85073948285512,1.9019625172161092,-5.35211591671062,-2.6447626149308627,-1.2940553039732745,-2.5094899183013606,2.1644587629342498,4.493103142341954,1.4899558379808469,-0.8732270979214367,-2.030020784103833,-4.105575533514057,-1.4347929470296084,0.6432291611315879,-1.4765117863646369,-1.0318886813702675,0.4620489433598103,-0.5651701780479252,True,c1,3,"ve.init.mw.Platform.js currently hard-codes searching from Commons, even if the wiki doesn't actually load images from Commons. We should do this based on wiki config instead.
--------------------------
**Version**: unspecified
**Severity**: minor",52673,0,Low,False
-7.350824759190839,-0.20613669950370017,-6.375759821890778,-2.643061563440944,-0.9775527753869762,1.324643496560092,-0.09041914787845595,1.963975395334431,-0.7443513524032944,-0.40851125947088196,-1.3000933637571446,-1.0421368997578875,0.8156678785917322,-0.5162678607485409,-0.7150730451714606,-0.6222582559673678,0.06140813316678484,0.9727898756503135,False,c1,3,"Not sure the technical term, but: if I hover over, for example, the bugzilla ""search bugs"" link, it shows as a URL in the bottom left of firefox, allowing me to identify the destination. The same is true in articles in read mode. It'd be good to have this functionality in the VisualEditor, or some other way of more prominently identifying where links are going to: hovering over every. single. one. doesn't really work.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52646,0,Low,False
10.793270014112165,-1.0974443496884394,2.3630292372722366,9.292598180659837,1.243571756863592,-8.44961775734228,2.449340718727499,1.7814119863458981,-1.356065642140451,0.1420246793074087,-0.16406154563755804,-1.8082036165513242,4.056209733860177,3.2481240578357404,2.179027246716445,-0.4307743844639088,-0.7524937633938498,0.7450020547170759,False,c1,3,"I imagine this is mostly due to Firefox's JS engine, but I commonly run across articles that take an extremely long time to load the new VisualEditor interface. For example, ""Domestic violence"" and ""Feminism"" take about 30 seconds. Really long articles like ""World War II"" take over a minute. The interface loads in about half that time in Safari. I'm using Firefox 21.
Comparative loading figures:
| Article | FF 32, 2014-09 | Cr 37, 2014-09
|--|--|--|--|--
| Barack Obama | 17.6s | 17.2s
|--
| Cat | 16.4s | 16.0s
|--
| Beyoncé Knowles | 25.4s | 7.5s
|--
| India | 26.8s | 5.6s
|--
| Richard Nixon | 9.9s | 5.6s
|--
| Europe | 28.3s | 7.1s
|--
| English language | 18.2 | 8.0s
|--
| Article | FF 34.05 2014-12 |Cr 39 2014-12
|--|--|--|--|--
| Barack Obama | 13.23s | 10.61s
|--
| Cat | 11.59s |5.82s
|--
| Beyoncé Knowles | 8.01s|5.13s
|--
| India | 8.90s |5.64s
|--
| Richard Nixon | 8.85s|6.36s
|--
| Europe | 10.31s|6.52s
|--
| English language |6.98s|5.45s
|--
",52616,0,Low,False
-6.4538907952476805,-0.1060571847925793,-0.9309969587255296,2.153113400029386,-0.9207778948408774,-2.175707433129965,2.7296214028656935,-3.3283985079207943,-2.265167021679571,-0.35421365719401,0.5809354717041288,1.5752121209004188,2.1546109267575706,1.9475155174111487,-0.3315033659206268,0.01215683092453873,1.2830709629747654,1.0734868690613129,True,c1,3,"A contributor requests the following:
I'm sure this is far down the list of problems, but I think the transclusion editor (and other bits with similar display) have way too much white space. For each parameter one gets two blank lines for every one line with parameter name. That is annoying and when templates have dozens of parameters, as many infoboxes and citation templates do, it creates a lot of extra scrolling to find what one is looking for. I'd suggest reducing the whitespace between parameter names by half. Dragons flight (talk) 18:18, 2 July 2013 (UTC)
--------------------------
**Version**: unspecified
**Severity**: enhancement",52598,0,Low,False
-3.7094772279310684,-3.592931277829779,-2.524597911844685,0.46343079114997354,-2.047593837765829,-0.7117981331494483,1.004106485775858,1.9780154946334978,1.78184792864528,-1.008418752792386,-0.8353199058153007,0.60437693517544,0.47334341510944,-0.871409341848314,-1.5494717680748797,-0.8918979014690998,-1.2606783889239448,0.5530270060999205,False,c1,3,"Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.
Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",52593,0,Low,False
-7.105280651279372,0.3462672019256736,5.771668208132084,7.378500984342825,5.0940521512649575,-1.220373138223408,2.2196596204804715,0.9079878191018579,-0.5711234802967763,-1.1433863857483924,0.006116472089426672,-1.0053741784988293,0.41824823752130547,1.1156451209652607,-2.1388218472135945,-0.6095359294587762,-0.8404570641970276,-0.32218109556796115,False,c1,3,"The template inspector's parameters contain the contents of each parameter, and also a line break, which represents, well, the break between two parameters. When modifying a param, it's all too easy to remove the line break, which results in user-unfriendly things like https://en.wikipedia.org/w/index.php?title=Kidz_Bop_20&diff=prev&oldid=562494239
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69682",52584,0,Low,False
-12.035630078144418,13.296742672746173,3.020750998571579,-3.1308964483457453,5.869348810672429,2.5945812087510873,-1.153078578815773,-9.316603570181451,5.442727758132771,1.988847015312273,4.9326391698168575,3.6353205881974677,1.223517854358708,4.422472413604222,-3.092261913838062,-0.2974378669753044,-7.187019865868861,0.08313047411943697,False,c1,3,"If you create a new reference, you can specify a name - great! If you try to modify an existing reference to add a name... https://en.wikipedia.org/wiki/File:VEReferenceEdit.jpg oops.",52568,0,Low,
5.204510178000374,-7.486924478149754,5.973292773265811,-1.024896358827693,-0.4611702172469485,0.013408034434767568,0.17798418304452657,2.6053567615691833,0.6621248594088146,5.731822661600781,0.29718398936964174,-0.4334766343183061,0.43685211073073127,0.6678257607538916,-2.0068789345311746,-0.3099197523544074,0.12637562437571082,-1.8707214057450676,False,c1,3,"See http://en.wikipedia.org/wiki/United_States_v._Windsor right above the 'Dissents' heading. Clear template covers most of quote box.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50395",52551,0,Low,False
-1.1988091769202067,-1.0826743366565914,-1.4172940452494966,-7.591324241149661,4.44319235312676,-0.19902701189328287,0.6061684629718274,-5.666722378852239,1.713227246531188,0.12882575209762326,-1.8497700976939109,-0.4206466233549374,-2.377528649168891,0.1676260814662891,2.0847591895733286,-0.7784241845062314,3.0714495872214584,-0.1005533028886818,False,c1,3,"https://en.wikipedia.org/w/index.php?title=Colorado_River&diff=562465192&oldid=562442392
When I go here, I have several options for what I can do with the edit:
> Revision as of 19:24, 1 July 2013 (edit) (undo) (thank)
I'd like another option that says ""(this edit was made with VisualEditor and introduced a problem; report it here)"" or something like that. A JavaScript gadget would be dandy, but I'm not picky about the implementation details.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",52548,0,Low,False
-7.250276799264718,1.0813338895093842,-4.840707208213351,-2.1623851106822833,4.0084021905190035,-2.0559058128412384,0.4505773751036628,1.418485975096977,-0.6584244679850132,1.457258056946273,-0.5408617470821016,-1.07084115017555,0.4326024321327968,0.016671146155222694,-0.7948086556476968,-0.6019235615104371,-2.3901092630115612,1.624745498094417,False,c1,3,"Screenshot of oddly collapsed resizable area
Not sure whether it is specific to Safari 6 but it seems a bit buggy.
Sometimes when holding down the mouse button the cursor won't change from a ""move"" cursor to a ""drag/add"" cursor (as if it is a regular hover, ""move"" until it hits the edge of the image and then becomes a regular pointer).
Also when dragging and dropping sometimes it seems to separate the image itself and the thumb container is left behind (!).
When resizing it seems to sometimes (sorry, can't be move specific yet) collapse into a single dot (see screenshot).
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11549}",52537,0,Low,False
16.537027141224527,-3.950672169697784,-7.453968042204391,3.736977913236723,0.6123890707350554,-4.109717218979346,-4.483481907714819,1.3741861973898688,-1.1443509181455507,-2.688666446917724,5.619806329371697,-1.256378079905593,-3.391641260815618,-0.13637849751317166,0.02279346708031227,-0.6721271406427842,-0.006329974358854518,-0.5522045544877978,False,c1,3,"http://parsoid.wmflabs.org/en/User:Adjwilley/sandbox10?oldid=562331693
Relevant wikitext:
*{{Cite book| last=Fádil-i-Mázindarání | first= Asadu'lláh | authorlink = Mírzá Asadu’llah Fádil Mázandarání | year=1967 | title=Asráu'l-Á<u>th<u>ár, Vol.I| pages= 453 | publisher=Bahá'í Publishing Trust, Tehran | url = http://www.h-net.org/~bahai/areprint/authors/mazandarani/asrar.htm | ref=harv}}
(note the <u> isn't opened then closed, but double-opened)
Output HTML (with data-*, about and a few others stripped):
<li><span typeof=""mw:Transclusion""><a rel=""mw:WikiLink"" href=""..."">Fádil-i-Mázindarání, Asadu'lláh</a> (1967). <a rel=""mw:ExtLink"" href=""...""><i>Asráu'l-Á<u>th<u>ár, Vol.I</u></u></i></a><u><u>. Bahá'í Publishing Trust, Tehran. p.<span typeof=""mw:Entity""> </span>453.</u></u></span><u><u><span class=""Z3988""><span style=""display:none;""><span typeof=""mw:Entity""> </span></span></span></u></u></li><u><u>
<li>(next item here, note how we're still inside of <u><u>)
--------------------------
**Version**: unspecified
**Severity**: normal",52536,0,Low,False
-3.9991057017219416,-2.2675815228754423,-3.078184871848725,-3.635279091289021,-0.6016660993122608,-2.533822138789882,1.8416338647214099,0.34257566608711953,2.6735555882670186,2.1454323873940018,1.7826437737155882,0.6591112736283689,1.2072084098861562,-0.8145769998729682,-0.8638331688444802,0.14408611307156877,0.5368574447809833,1.736273630114234,False,c1,3,"There should be an edit notice whenever someone tries to use VE which says something like ""Slower computers or users trying to use older markup should try editing in the older Editor."" and link to the older editor. Otherwise we're directly cutting off plenty of editors who can't figure it out, and would have relatively slow internet.
P.S. My internet is slow enough to not give a satisfactory VE experience, and I consider myself to have decent Indian speed internets
--------------------------
**Version**: unspecified
**Severity**: enhancement",52518,0,Low,
-14.009692241145887,13.953415998863857,2.1448877310031556,1.5523670430631236,6.950754471966862,4.082651282524886,-2.801044596795293,-1.4313269488036169,-2.561280928226351,3.917439281039263,2.1792726003113407,-4.217346932828565,-2.0749314402135752,0.4674060169555121,1.6232890501339368,1.1546605512789214,-3.9683707686797085,-1.2826705773468288,False,c1,3,"When I add a link to the title of the page, it is displayed as a normal link instead of a <strong class=""selflink"">.
Same problem while editing a page with a 'selflink' already present.
The contributor doesn’t see the article as it will be after saving.",52497,0,Low,False
-0.31942884196118326,2.492402821120418,1.5650388175904872,1.460134869521387,1.9030745155532593,2.2342476050325972,1.233703951172818,1.8194457516958376,0.005019805803816391,-0.13200724981724754,0.9867928576426714,-0.5273475858994515,1.6735497502717354,1.3621308670017847,-1.6360338805838461,0.2793821733038667,0.9934259204341822,2.2928872086342826,False,c1,2,"Suppose an article contains two lines in Paragraph formatting, and we want to turn the first one into Heading formatting. Select the entire first line (Cursor at beginning of line, Shift-CursorDown) then choose Heading formatting from the selection box at the top. Result: both lines are turned into Headings, not just the first. (Bold and italics formatting changes work correctly and affect only the current line.)
--------------------------
**Version**: unspecified
**Severity**: normal",52419,-1,Low,False
-5.714741362331872,-4.566755652655258,-7.448904340350655,0.19274438926423487,-1.1462516370738667,-4.65532413605076,-2.42179434415015,3.3537005479664717,1.1886831553205048,1.6898047756370378,-4.532496124506615,2.022184761777284,-0.5361752798021744,-2.7669771919996045,2.134515781401727,0.4788124087297033,-2.080772383744154,-0.0025965385498749605,False,c1,2,"Add a way to mark a parameter to be dependent on an other paramter. For example :
We have following parameters:
""foo1_bar"", ""foo1_baz"", ""foo1_quux""
...
""fooN_bar"", ""fooN_baz"", ""fooN_quux""
fooX_bar required fooX_baz to be used as well, it doesn't require fooX_quux to be used, but if fooX_quux is used, then fooX_bar must have been defined as well
--------------------------
**Version**: unspecified
**Severity**: enhancement",52407,-1,Low,
5.7771935453940895,-9.136523292985345,3.8437303809276138,1.2149069309988851,0.738855370546748,1.3892204959711905,2.45864276664354,0.8613660550916619,0.37703267327898005,0.7595545352434243,1.0841621617433792,1.0344126515778111,0.791685708270494,-1.1250217364845176,-0.533916920932791,-0.04848981746532072,-1.0899406065144728,-0.8824502448962501,False,c1,2,"https://en.wikipedia.org/w/index.php?title=Stand-your-ground_law&diff=562005779&oldid=561464750 is a good example (hat-tip to MatMaRex)
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50120",52385,-1,Low,True
11.614281568877932,-11.60439599915714,0.9631268361549026,-1.441771329656842,0.466287863565922,-0.7432941037673979,-1.4020523604510702,0.8438516512901982,1.1705908460931695,-1.776240168902123,-0.5833235380240334,-0.43821423450082175,3.5885690466208224,0.6631497561022526,-0.7301594072518984,0.2988635328499173,-0.9311670196088682,-1.1801537895543044,False,c1,2,"Screenshot
Firefox 21.0, Windows 7 - see screenshot.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49896
**Attached**: {F11161}",52365,-1,Low,False
-8.594911469753786,3.314109391420711,-1.6386185911269866,-0.06019039720804065,0.9445885540439556,1.825598930984299,-1.4732436516622114,4.114372302781188,-1.5202851290223385,1.3887402196435845,-2.390822558414709,0.9565206650435456,-0.5996159081600556,-1.9980651248332681,2.0997496707534893,0.14576380459367358,-1.6689130927740272,-0.5896020800835482,False,c1,2,"This is a legacy of wiki-syntax, where all external links have to begin with the protocol. It would be nice to make the VE link inspector smarter than this.
""www.google.com"" is almost certainly meant to be an external link - if there is an article by this name, then it could be shown in the link inspector dropdown as well, but the option for ""External link"" definitely needs to be there. Even something like ""royal.gov.uk"" should be recognised as a URL.
Requiring ""http://"" or some other protocol at the start is confusing for the newbie, as the protocol component of URLs is generally ignored nowadays.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52360,-1,Low,
3.4039633239407983,-3.5364736976803695,1.1815066752251369,-0.8309719772975867,-3.0544925110553467,3.0791479746437487,-3.9884420660836044,-0.457217990850844,0.5040106043607572,-0.9639031508556575,4.490154982439867,-1.2392192127666541,1.145878880360058,0.4506857134429225,-0.3331656967212302,0.17001510881277007,0.40853297218272555,-0.10938407722515775,False,c1,2,"Screenshot of bug
1. Go to [[de:Special:PendingChanges]]
2. Visit one of the linked articles and edit it in VE
Notice the wide right margin, caused by the floating FlaggedRevs status box.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11085}",52340,-1,Low,False
-3.2104724413965604,-0.5323191705366046,-0.7275191581335854,3.2895023114319795,-0.24322514427267233,2.081250184471439,-3.118345411147392,1.5456984745904472,-1.7930433653188877,-1.2633841031302628,2.3115095930437852,-0.21371668771569075,-0.05979862071670272,-1.141740070827014,-0.3324791980767987,0.09098436346375241,0.2554312985401268,0.5277375865005844,False,c1,2,"At the moment adding categories (through ""page settings"") involves turning away from the actual content. This is a problem because a lot of categories are dependent on the actual content, which needs to be referred back to - birth or death years, college, etc, etc.
Suggestion is:
* Show the existing categories in the standard skin location (at the bottom of the page, in Vector)
* Make the categories editable there, in some way.
----
Original onwiki comments were [[https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_6#Categories_-_display_them.2C_please |archive 6]]
> I can see categories when I read an article. I can see them below the editing paraphernalia when I'm in Edit Source. But in VE I can only see them by clicking ""Page Settings"", which (a) takes a click and (b) means I can't see any of the article content (eg the hard-to-remember-the-spelling district name, the birth date, etc which I might want to use in creating categories, having seen that they aren't already there). Please display the categories in or around the article, not just as ""Page settings"".
and [[https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_7#Categories:_please_display_them_in_VE_-_not_the_right_bug |archive 7]]:
> I want to be able to see the categories when I've got an article open in VE: just as I can see them when reading the article, or when editing it in Edit Source. I don't want to have to click on ""Page Data"" to find out whether or not it's already got categories.
--------------------------
See also: {T67518}
merged duplicates: {T53153} and {T71506}
",52239,-1,Low,
-7.750309653202459,1.332968093302929,-7.993903135823572,-5.5132918290385,-1.371728701739578,0.5067928876606733,0.7914661760928459,-1.326741701228502,0.367444922448144,-0.2008095780482444,0.659409435160403,0.6280318319409552,0.3401126113378048,0.434902746998322,-0.5945873312386967,0.42490091835725746,-0.42731481726737464,-0.3445744950584546,False,c1,2,"See the screenshot. I get that it's sort of a one-sided diff in a <poem> box, but it isn't particularly useful to review since no tweaks made by the VE that are problematic could be picked out; one would have to review the entire article, in markup.
I'm not sure if there's a better way to work it or if the answer is just to kill it for new page creations, but.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52180,-1,Low,False
0.2410651696796693,1.047033974350228,3.4005716467225255,0.9174005933597758,4.7933322389103825,-1.7473979698118134,-0.4245188414712464,-2.349083297137731,-0.7887107587018618,0.3798352000014491,-1.4967328563435622,0.5148879999231017,1.41259343811657,2.949305659956061,2.0216646504511315,-0.07908721785342243,1.2284779019380234,3.07543112694597,False,c1,2,"See https://en.wikipedia.org/wiki/Joe_Flacco?veaction=edit - for example, references 24 and 25 under the section ""2012 season: Super Bowl MVP"". It looks like one of them is using Template:R, which may explain the problem, but I'm not sure if the icon not rendering properly is a template problem or a VE problem.
--------------------------
**Version**: unspecified
**Severity**: minor",52095,-1,Low,False
1.2746214920602479,-1.8693793839586004,-1.213007715085622,-2.4411340555612355,1.930409900486132,1.6094819774915516,-3.5755187082736,2.094063708918034,3.0336637816677676,1.265992273083576,3.9632121191264296,2.7207621057426916,0.0069743354795051005,-2.351789705299042,0.44391764395538313,-1.1697661462380338,-0.011206655185169057,2.581480344956131,False,c1,2,"Edit [[User:This, that and the other/sandbox/VE6]] in VE using IE10:
1. Try modifying the heading text. You have to double-click on the heading to be able to modify it. Hopefully this stupid IE behavior can be worked around.
2. Double-click, and modify the heading text. ""Save page"" button is still disabled.
--------------------------
**Version**: unspecified
**Severity**: normal",52088,-1,Low,False
7.270476767311029,-7.193560602655355,-3.545237988841688,-4.802611210397817,-1.092227032258119,4.06147326100207,2.4262923766688838,-0.6665984946800433,-0.43548044588024387,1.3295050867016025,2.0432357742359772,-3.2256688337032386,1.3252603029060435,-1.885335210270728,-1.485680229288647,2.3435439866267704,2.1343668030076666,1.102360897720316,True,c1,2,"link icon not square
See attachments. Reproduced in Chrome and Firefox by the original reporter, and me.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11416}",52057,-2,Low,False
-0.08828452833273692,-3.7246479105578896,-11.048686346820139,1.3183718392232837,-2.1726387948798163,-1.2473101671496325,-6.6413187922812265,0.4080335839417323,-4.507024090444843,0.8490720603361384,5.00969831279428,-0.7477482927268344,-3.2840635639192346,-0.428780820649715,-0.297459252789233,-1.0326266698075872,-0.7674680720415757,0.6142357421080782,False,c1,2,"It looks like we currently output both for some modules.
Current output on a wiki with user and site css/js enabled[1] but empty:
<script>if(window.mw){
mw.loader.state({""site"":""loading"",""user"":""loading"",""user.groups"":""loading""});
}</script>
<script>if(window.mw){
mw.loader.load([""mediawiki.action.view.postEdit"",""mediawiki.user"",""mediawiki.hidpi"",""mediawiki.page.ready"",""mediawiki.searchSuggest"",""mediawiki.page.watch.ajax"",""ext.vector.collapsibleNav"",""ext.visualEditor.viewPageTarget"",""skins.vector.js""],null,true);
}</script>
<script>if(window.mw){
mw.loader.state({""site"":""ready""});
}</script>
<script>if(window.mw){
mw.loader.state({""user"":""ready""});
}</script>
<script>if(window.mw){
mw.loader.state({""user.groups"":""ready""});
}</script>
The first one with ""loading"" is always output. The last 3 with ""ready"" are output by OutputPage::makeResourceLoaderLink if $module->isKnownEmpty is true.
We should probably optimise this to just output ""ready"" in the first place.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52038,-2,Low,False
-0.02635858157187787,-5.53820894876185,-2.4800839644783608,-2.4037331994828888,0.6328960354686826,2.244675197151273,-1.2717889941165623,-0.2573301915594596,1.122685909420312,-1.743672712626343,1.094719888679331,-1.1461381813708755,-1.5138793407081073,0.32403533382010696,-1.692372057208961,0.5928700412049416,0.19885645526436324,0.2705797070265732,True,c1,2,"https://www.mediawiki.org/wiki/Help:Magic_words#Variables
{{CURRENTYEAR}}, {{CURRENTMONTH}], etc. - possibly a pop-up inserter with a brief description of what each do (and their current value?)
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62740",51996,-2,Low,
-4.416801030850809,0.517850875534819,-5.248343878321402,-4.1582381046763075,0.9054533716436115,1.9965782911540193,-1.212011997684601,-0.11111914231320669,4.736180323042215,-2.124796673918396,-1.4972315818947157,0.29100649976219395,-0.008086806440736893,-0.1875016893556669,1.4478845624870296,1.6117486122339277,0.37747827469794615,0.5085718037745706,True,c1,2,"It should be possible for users to modify the location of the TOC (see bug 49224 for getting it shown and updated as they edit), and the system should insert a __TOC__ identifier (that should be silently dropped by Parsoid when not needed?).
--------------------------
**Version**: unspecified
**Severity**: enhancement",51994,-2,Low,
-8.290384984512828,7.4747595944417675,-0.6259658125376983,-1.9814062521061704,-1.8407897154918789,3.445845022524436,1.3076620337930027,1.9762394486936858,-0.6852606616308959,-2.3245012118476596,-2.803633974550629,-0.5170407349763931,-1.9763595249422297,0.763149608421263,0.35066116090997657,-1.6799291027628223,-0.019029206065033888,-0.27424809341949885,False,c1,2,"Because the VE splits up the destination of a link and the text displayed for it (quite rightly) it's impossible, in VE mode, to identify where links point to without source editing. This is kind of a problem for disambiguation issues, for example. Is there any way that this could somehow be hunt-down-able?
--------------------------
**Version**: unspecified
**Severity**: enhancement",51928,-2,Low,False
-3.0962180467693194,1.1391786862191804,-0.190421814900553,1.4920754323997767,-2.5567762379062797,-0.5582924926843199,-3.5080899798606504,-1.8627264982815057,0.39555013762303926,3.2019752020903685,-1.7998195904646879,1.832550982118468,-0.9012783488562972,-1.0924608587755578,0.43365493052129356,-0.1173247711833712,-2.9244999014482698,0.16544141256079814,True,c1,2,"User:JohnCD at English Wikipedia writes the following:
""If you enter, for instance, ""Welcome"" in the new template box, on clicking ""Apply changes"" you see the result; but if you enter ""subst:welcome"" you see only {{subst:welcome}}, though after clicking ""Save page"" the result is correct. Should there be a check-box for ""subst"" in the New template dialogue, (a) to save typing it out, (b) to arrange the correct display?""
James F. suggested this would be good to enter as an enhancement request, since template substitution should be supported.
Maggie
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66281",51904,-2,Low,
-5.422971043389506,4.012807965588578,4.155336341711056,4.444829327623011,-1.3584272586517352,-2.4337000782239615,4.398576675447921,2.787550481721011,-3.394638775146138,-0.49675801729268354,-0.45524963689492637,5.168762924424275,0.16039033811671644,-0.3284211895227429,0.8999232458953337,-1.434766840207208,0.12850857738052768,-0.9879693895323988,True,c1,2,"It seems that the server part of this is already correct. The client just needs to add printable=1 to requests for JS-wrapped CSS should include printable=1, when the page is in print mode (printabable=yes).
This is necessary to make sure that screen CSS is omitted and print CSS is not wrapped in @media print for this use case.
--------------------------
**Version**: 1.22.0
**Severity**: normal",51722,-2,Low,False
-10.237839359598642,3.228757413940425,-4.256594900244796,-6.1336507985182624,6.161241265297255,6.030776427548359,3.2127726137446926,-9.179420397160413,2.6868116363660777,-1.3286262158940958,-0.02253436138565945,-1.9059126057467557,-3.237932569594957,1.530006009395139,3.05378746337128,-0.42897873252241114,1.4209640568497737,2.910622426486505,False,c1,2,"When I am editing an old revision of a page and then view the diff before saving it is the diff between the current version of the page and my edited version it seems. I was expecting to see the diff between the old revision and my edited version.
--------------------------
**Version**: unspecified
**Severity**: enhancement",51692,-2,Low,True
11.135773532186374,-2.4443550182521925,2.3770861123334015,-4.385815174809845,-4.770735125660748,5.118726519087152,-1.4955131264194508,0.006581494480559724,0.08414007344703345,-0.21649134945267523,-0.0821001804700745,-1.360784158034162,1.6581525694073402,-1.8643976250257719,-2.545541216669844,1.6530057450285947,0.7011961261644382,-0.3083325713194851,False,c1,2,"Screenshot
See on https://en.wikipedia.org/wiki/Brainbuster for example, at the bottom - screenshot attached. Reproduced in Chrome, Firefox and Safari.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F11473}",51680,-2,Low,False
33.73060194131731,-5.306010989939308,14.92770793408323,-22.526669842345775,7.873021914377709,-4.308367804714623,-10.005439712227702,14.774646431617663,8.69756642790241,-3.186038196019723,0.5580079886362856,-0.41009810135763547,11.75037972983592,11.727817460998834,3.769673772407459,1.9547531953219364,-3.4152049109317923,-1.390251804254155,True,c1,2,"See also: T51633, T52341",51667,-2,Low,
-5.981018494209959,-1.1357229942797584,-1.5623268311024443,6.0614869636444295,0.19196661523914094,-1.0287427291648128,0.7869011853604126,1.230317922087087,1.64830270693024,-1.713194923276406,-0.9075824548912057,-1.3083285547989332,0.33054341417440414,-0.589370728427844,-1.8314339040252174,-1.0773868623702523,-0.20426770002551708,0.4396058955934443,True,c1,2,"Some suggestions of improvements to the media insertion dialog; this is mostly a brain-dump which we might turn into a tracker later:
- a way of accessing the file page, on Commons or elsewhere
- a more clear highlighting
- maybe slightly enlarging the image
- double-click to insert
- filter by: …
-* media type
-* language (mostly specific to audio/video but also maps/diagrams)
-* length (audio/video)
-* resolution (image/video)
-* video bit-depth (image/video)
-* audio bit-depth (video/audio)
-* sample rate (audio)
-* format
-* licence
-* local vs. Commons
Notes:
The image size is based on the largest default thumbnail (the dialog asks for the 300x300px image and then shows it at 150x*px size). Changing this would need to have discussions with Ops about load on the image renderers and possibly changing the default sizes globally.
The filtering will have to wait for Solr faceted search, if that's indeed coing.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51032",51662,-3,Low,False
11.075317554847773,5.550200621193095,8.94205423655723,-4.873817073482899,1.125323272806236,10.710860735975915,-0.0881537718573231,-0.6494408351074572,-5.14108698829677,-0.7589941403720428,-1.2832362949273828,4.069058000073434,-0.5410918972867007,-1.2212361535010108,0.9403655697726787,-2.3657566817761086,2.470989054930528,-1.311699614050868,True,c1,2,"Per Ed's comment on T50605:
> Above change fixes issue with annotations being dropped, but we still need to fix empty annotations not rendering (e.g. `<span style=""display: block; background: red; width: 100px; height: 100px;""></span>`), either here or in a new bug.
This is the new bug. :-)
",51497,-3,Low,
5.170763031235186,0.34004644031741726,2.7369819521393914,1.0930170037903393,-4.351185769172968,2.053601859986573,-0.3122004427279368,1.641138325885727,-0.3632932022333977,0.43138400882502026,1.2681001619825083,-3.623693951325407,0.20938812906198745,-1.518808467594102,0.24220605286059893,0.38482789787810917,1.2147434536629318,-0.26442582305456863,False,c1,2,"**Author:** `and.radiate`
**Description:**
Using alpha version as of 11JUN13. Did a small edit on Wikipedia English article ""Nagato-class battleship"" (deleting 3 letters from [Japanese] to form [Japan] in second sentence under section 5.1 World War II. Then scrolled down; after originally displayed area scrolled off screen, the screen went black in the TAB. Other TABs in IE remained operative. Back arrow did not produce any results on black screen or URL showing for the Wikipedia TAB. Reloaded http://en.wikipedia.org in TAB with black screen; successfull load and correct operation thereafter. Could not reproduce the error.
--------------------------
**Version**: unspecified
**Severity**: normal",51464,-3,Low,False
0.959015308703568,-1.6963155332992113,0.02130610351413864,0.3869374456353598,3.764689498495294,2.390327962234461,-5.549024314539457,-0.26312356556672384,1.9044313316896668,5.782683948387348,-3.062193032859689,1.6210254010511245,-1.9655428802844037,0.9769270805938195,-0.42770585928636073,-2.057428495009085,-2.0574962425200782,2.3960021541251386,False,c1,2,"VisualEditor is removing the font weight from the ""article"" tab when using Monobook on the English Wikipedia.
Steps to reproduce:
* Go to <https://en.wikipedia.org/wiki/Canada_Goose_(clothing)>
* Click ""edit this page"".
* The ""article"" tab loses its boldness.
* Clicking the ""cancel"" button does not restore the boldness.
--------------------------
**Version**: unspecified
**Severity**: normal",51407,-3,Low,False
10.285974849508454,-13.467286231584497,-8.491738496176813,-1.9970585314162395,-2.258256524291337,1.6499781903954578,-9.602669501295477,0.17397258545760785,-3.311221460097795,-6.204011689124019,9.134345658431402,-1.1715603944864148,-11.60701732178611,0.25374919310493915,1.2248781295976459,1.9116012988384956,1.2767564741138775,1.8702693140905045,True,c1,2,"E.g. [[:fr:Foo]] or [[m:Foo]].
--------------------------
**Version**: unspecified
**Severity**: enhancement",51316,-4,Low,False
4.326870216817907,-16.317490188340763,6.51701991193211,-0.9478483310339998,-1.347457850035386,2.604618282827408,2.9715858450485504,-0.04887905016881597,4.371777307550583,1.7521605310124642,1.472029850431714,1.7111768271131098,-0.18815446954747106,0.7477505718788793,-0.34536965921501483,0.5412928297846197,-0.4429915204200132,-1.160928575850554,False,c1,2,"See http://imgur.com/wmAeHRD
--------------------------
**Version**: unspecified
**Severity**: normal",51249,-4,Low,False
-7.6844594410382605,0.9562485162200023,0.8300174514457126,1.221312379200238,-2.3972946563267197,7.9968677769424135,3.420737104995438,1.4017323597064695,-3.665161251084264,0.9336706872117801,1.0250579680554615,-1.4307491460354287,0.1279619292992491,-0.8646060744922988,0.6224909581124232,-0.6931707494680179,-0.8093097550779439,-1.5844894257717441,True,c1,2,"This is bad, though in a relatively edge case of lanklinks outside the main namespace.
--------------------------
**Version**: unspecified
**Severity**: normal",51226,-4,Low,False
-6.872125972718903,-2.3676057427627377,2.6432876667023457,7.545722408266689,-0.8351747383379171,-3.414897692519597,2.401747367624698,2.2868973010308045,1.7345948639672486,0.43822454797866595,-1.2740743643870762,-1.2052416914679545,-0.531470305700573,-1.1321467471773548,-0.41827286632267935,-0.014023290738516547,1.3560383989400486,1.624087713985342,False,c1,1,"Users and categories should not be auto-completed based on page names (API action=opensearch) but instead based on their own respective query modules (list=allusers, list=allcategories) because the existence of a description page is optional and neither a subset nor superset of the database tables.
* Pages can exist for inexistent objects.
* Objects often don't have an associated page.
718db58f introduced category editing with autocompletion from opensearch (with hardcoded 'Category:' prefix). This should be switched to using list=allcategories instead.
That way the input field will no longer include results for inexistent categories, and no longer omit results for existing categories lacking a description page.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65517",51044,-5,Low,False
-6.005257233203862,1.6394713852099656,-1.280349299649453,-3.419391448337995,-0.5559363370771743,-1.0710595606161744,3.5348566759790385,-3.256975533176509,2.638565091207753,-0.7434784104421226,-0.6575442347513967,-0.08957397209515139,-2.3371770778919387,-0.2396989450055349,3.7079255455498226,-0.5309862689381812,-3.6885389747241124,-0.16400974152372716,False,c1,1,"It would be very nice if the Ve would warn you about inconsistencies in header levels (when you are skipping a level for instance)
--------------------------
**Version**: unspecified
**Severity**: enhancement",51012,-5,Low,
-3.64271462632067,-3.5791863507436457,4.011287433140911,1.958789806319638,1.1750754646417458,1.6924724872881904,0.5492859506332852,-1.3709555060191523,1.1449866509524886,-1.8779014527824627,-1.7456596912176816,-0.8393515423104191,-0.7920940036577431,-3.2050540921190454,2.9378043091063324,1.0429160965013065,1.0810131317620557,0.44321274877215644,False,c1,1,"In https://de.wikipedia.org/w/index.php?title=Anna_Zaja&curid=7691608&diff=118985342&oldid=118754158 a missing space was added after the name, but it should not be inside the bold part.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://de.wikipedia.org/w/index.php?title=Anna_Zaja&curid=7691608&diff=118985342&oldid=118754158",50933,-5,Low,
-3.453599163768025,4.4026219280337955,-4.278861090812567,-0.3413278099387844,-0.3970594748631438,-0.47811683799953897,-1.177591498352399,2.468730323841289,-1.2747779539631467,0.006070849011705626,-1.3136680235828029,0.8990232578873967,1.9527645457557137,-2.3381372802133287,1.0043715297851321,-0.6546952244502244,-1.512051958025243,1.8752147659115035,False,c1,1,"Situation:
* ResourceLoader wraps modules in closures
* MediaWiki developers put a closure in each file
* As a result loading 1 module with 2 files will have 3 closures
```
mw.loader.implement( 'foo', function ( $ ) {
--- foo.a.js
( function ( $, mw ) {
...
}( jQuery, mediaWiki ) )
--- foo.b.js
( function ( $, mw ) {
...
}( jQuery, mediaWiki ) )
} );
inside mw.loader#execute:
script( jQuery );
```
It has been suggested we add ""mw"" to ResourceLoader's closure and get rid of the per-file closure.
The downside of doing that would be that they are less safe to use ""standalone"". e.g. a jquery plugin would be using $ directly, which, outside MediaWiki ResourceLoader context is bad.
There is also the pending refactoring of ResourceLoader debug mode to not be completely different and near useless by executing in the global scope.
",50886,-5,Low,False
-1.8616664825333222,0.6854588227951997,-3.1887636019871053,1.7206687309856452,0.7934378361516699,0.1672967161592045,-0.009709167987286271,0.10140004823132848,0.3271857066853563,-0.6274431055657379,1.0221916261396022,-0.7479576189015101,3.3313995126551355,1.008040888874194,-0.5311484186636477,-0.4454853542006789,0.5161412626804085,-0.37575360036340344,False,c1,1,"Go to some long article (so long that it won't fit on one screen in your browser), start the visual editor, scroll down, then use up-arrow to walk all the way back up to the top of the article. It's not possible: the first lines of the article remain obscured by the visual editor's menu bar; the only way to make them visible is using the scroll bar or with PageUp.
This is Windows 7, Firefox 16.0.2, Chrome 26.0.1410.64 m, Mediawiki 1.22wmf4 (646544a), VisualEditor 0.1.0
--------------------------
**Version**: unspecified
**Severity**: normal",50787,-6,Low,False
-3.521958749659146,5.981063361236277,1.8842538272453027,6.525464157667083,4.392145143927941,4.155171874090089,-1.686848859996318,1.2772347392159369,1.3738079031452282,-1.9081522952352588,-0.8882048963414775,-2.8267155952168386,1.1170659394231448,-0.4259246688081557,-1.035200757611598,-0.9730072083001864,0.2636542627449383,-0.5498611666565503,False,c1,1,"Steps to reproduce bug:
* Edit a page and add the following content: `Hello ""<code>world</code>"".`
* Place cursor before the first quote, then use the arrow keys to move right (after the quote, before W for world).
* Insert a character.
Expected:
The place where the character appears, and the position of the blinking cursor should be the same. In actually, this is not the case.
The cursor is blinking **inside** the code annotation (close to the W, within the padded area of the code block).
The added character appeared **outside** the code annotation (close to the quote, outside the padded area of the code block).
Screenshot of problem (from May 2013):
{F10475}
Video capture (July 2018):
{F23391729}",50680,-6,Low,
-8.030441588027545,1.0882191188032309,-7.2598209332226915,-3.7127004243582507,-1.9056426481604607,-0.3402076752925626,-1.4034919697419772,-0.23325576195263276,0.4495972717124589,-2.6842883001925784,-0.9180986542373293,-1.600165154899115,-1.2477915050045585,-0.61818755391596,-0.9237432651489925,-0.5561997207631679,-1.7079696308274601,-0.3727112461551467,True,c1,1,"When ever the user does a load, save, diff (, other?) action with the server, we should check for whether the new edit token is an anonymous one when we're expecting the user to be logged in, so we can warn the user that they're now logged out (to prevent them asking for their IP to be over-sighted, etc.).
There's potentially utility in doing this in core (for the wikitext editor) as well.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50656,-6,Low,False
-6.5420103382784065,0.8843655970514508,-1.03540809543812,-0.5182191167140779,0.4833284810624885,-3.4888628388591254,0.014869513887452612,-1.0269717943785257,-0.1723884196390052,0.9221198149835743,-1.990582155282043,0.9948844471050904,-0.8719602867633203,0.5417382084373754,-1.7953911415831425,2.919799785176636,-1.1588524508212752,3.436512478846079,True,c1,1,"In the Category inspector, start setting an over-ride for a category's sort key, but instead of pressing return, click out; no sort key is set. If you change and click ""apply"", it seems like it should apply but doesn't, confusingly.
Thoughts?
--------------------------
**Version**: unspecified
**Severity**: trivial",50555,-7,Low,True
-9.356218985899917,6.28821154567223,-1.6754236821518838,-3.7979325639429677,4.139393553061598,2.702278709065671,0.9016328854828206,-4.692028733333518,4.557525796059544,1.1181152986017437,3.8134886585057557,-1.7701628407145042,1.0861012142419697,0.13762824543714647,-0.01871631712284927,0.3159580155127281,-1.917976277419859,0.7682778600272766,True,c1,1,"This seems weird to me, but it still might be intentional.
If you put the caret immediately after a sentence ending in a period (e.g. the last sentence of the lede from https://en.wikipedia.org/w/index.php?title=Kono_Statement_of_1993&oldid=546398254&veaction=edit), then click the Link button, it tries to link the last word, including the punctuation.
I would expect it to let you create an new link, without assuming any existing anchor.
--------------------------
**Version**: unspecified
**Severity**: normal",50487,-7,Low,True
-6.346149849112827,5.464214602804059,2.2889254507938404,1.0555596329310792,2.0706621577790565,5.427521333916028,0.3509010705666089,0.13427308957862988,-1.1068886100919606,-1.423505832340914,-0.9036918754597401,-1.7422638673844053,-0.4213598896391124,-2.0567839026737555,1.063899229954373,0.18412128590012491,0.42648556618978306,-0.5780726547052668,False,c1,1,"When editing http://de.wikipedia.org/wiki/Wikidata the top of the Wikimedia logo in the template at the bottom of the page is cut off. (It might also be hidden behind the grey bar or something.)
--------------------------
**Version**: unspecified
**Severity**: normal",50461,-7,Low,False
-6.201552976038012,11.939933804644241,6.949150250653851,4.597205421639101,-0.9314751571461091,7.7551070725972115,-2.360660500158182,0.2335273428404434,2.0179415076042737,-0.6156097014305191,2.4645294722531115,1.3592401146754798,-1.160236404062104,-1.8999325321102547,3.2545045178085408,0.40971706020638665,0.4747593222865152,-1.3834778794761773,False,c1,1,"It should be possible to edit a part of a MediaWiki page such as a section or paragraph via VisualEditor without loading the entire article into the editor. This would be especially useful on mobile devices. This ticket is designated to serve as the parent task for all work related to such a goal.
The parsing-related work can be seen at [[https://phabricator.wikimedia.org/project/view/3331/|Parsoid: Section-Editing-Support board]].",50429,-7,Low,
-1.5714942631747029,0.5679787547362238,2.0311053442290543,-2.4442157406685467,8.00545131779586,2.7045905947758904,-3.356124180975486,0.5171819619688252,-4.162701569757972,2.0666911725751254,-0.8125903272208088,3.264938098265122,-1.818051474045009,-0.38026442125766735,0.45539204094611474,-0.334542207493185,-2.248369343405408,-0.3865609156581755,False,c1,1,"How to reproduce:
1. Enable the ""Mark all edits minor by default"" option in the preferences.
2. Edit a page in the VisualEditor.
3. Press ""Review and save"", then ""Looks good to me"".
4. The edit summary entering bubble appears.
Observed:
* The ""This is a minor edit"" box is not checked.
Expected:
* The ""This is a minor edit"" box is checked.
Comment: The saved revision IS correctly marked as minor. It's just the check box that appears incorrectly.
GWT scenario for Cucumber:
Given that I am editing an article while the minordefault preference is on
When I am saving the article
Then the ""This is a minor edit"" box is checked
--------------------------
**Version**: unspecified
**Severity**: normal",50347,-8,Low,True
-1.0334471955604614,-2.768166613781661,-0.8424503094944384,-6.586078007340801,-3.124553351620767,0.6521794000091155,2.5374547902174927,2.535033290232506,4.728447836429195,-0.9889081530091466,-1.9117181600966442,-0.7394111407838104,-2.780483800446677,1.3522180920374574,2.967583466959595,0.3328509410518312,-1.8485714643169584,0.21263951673993575,True,c1,1,"Core now has jsduck documentation on https://doc.wikimedia.org/mediawiki-core/master/js/ . It would be useful to provide a standardized mechanism for extensions to have their jsduck documentation automatically added under doc.wikimedia.org as well.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48244",50337,-8,Low,False
-3.4733621553189837,8.038749159146345,0.067609170180841,-0.9290850970561806,-7.474453869176731,-1.274190069992445,-1.132448472276554,-5.170130949485805,1.3336440631106594,4.998191267574466,-2.2527009447985105,-0.02483522149135986,-1.4698993462949757,-0.36209993312048994,1.9605503924976748,-0.24231722512370668,-1.920131479213727,1.0064133438976925,True,c1,1,"Wikitext edit has page title ""Editing Foobar"", as opposed to reading-mode's ""Foobar"". For people with a number of tabs open, it'd be great for them to get a handle on where they are by updating the window title to prepend ""Editing "" to it (and remove it on save).
--------------------------
**Version**: unspecified
**Severity**: enhancement",50272,-8,Low,True
-2.0403677134888474,1.416642042404595,2.7177413353208912,1.4425396458800854,-1.1733920850510526,2.3805852922429676,-2.36928355060267,-0.6814556879016094,0.36154748177248475,-2.28988043546233,-0.6018986523518501,1.2907216082522035,1.151854238875237,-0.1838902352014502,0.18921140203257814,1.1854721634167098,-0.8806742213592882,-0.1766205222139965,False,c1,1,"It would be helpful to have a built-in method in Scribunto/Lua that allows retrieving a list of the categories used on a page.
For example, <https://en.wikipedia.org/wiki/Einar_Schleef> would return a list that includes:
* German dramatists and playwrights
* 1944 births
* 2001 deaths
As these categories are included on this page.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**: {T20596}",50175,-8,Low,False
-3.1936546391217444,5.738529024487338,2.3437704318897516,9.617177722238905,-1.0838987929194395,-1.5159173809699953,2.097104186101352,0.1315511392551082,-0.2709568531795003,3.05144065498145,-0.17901412658774163,-0.9931505597307206,-0.008273656196558399,-1.0406620746000779,0.247304109326568,-0.07416581052969368,0.11738033321651353,-0.5041165801448126,False,c1,1,"many + signs
Tested:
In OpenOffice, create a small table with text in cells a1, a2, b1, b2, c2.
Copy only the rows of the table.
Paste into VE.
* the view immediately in VE is of unusable information and some ""+"" characters apparently indicating cell boundaries.
Version:1.0StartHTML:0000000155EndHTML:0000000881StartFragment:0000000475EndFragment:0000000864➞➞➞➞➞➞➞➞➞➞➞➞➞a1➞➞➞b1➞➞➞➞➞➞➞➞➞➞a2➞➞➞b2➞➞➞c2➞➞➞
* the view in the ""Review your changes"" panel is of a swath of white space with the contents of the table interspersed.
* User tendency is to copy entire contents of rows, yielding many empty cells. VE dutifully tracks these empty cells and displays an enormous number of ""+"" symbols in the immediate view and mostly empty space in the ""Review your changes"" view.
* Upon save, no table is in the page when pasting from OpenOffice.
Other anomalous results are reported when pasting from the Apple Pages application. From another user:
""...number of cells didn't match the number of columns. Since they don't match, tried to delete the cells in order to recover the blank page, but they won't delete.""
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F11079}",50170,-8,Low,False
-2.605364707172037,4.110906172580737,-1.256398873374911,-0.3792510217491917,-2.787702897584737,1.5762640845693034,-1.7574243059685593,-3.548121873785566,3.0576674204664105,-2.6960209992298667,-2.396002874686409,-0.1729322642953306,-0.10922232158131173,-0.6068589345272617,0.7570481206771849,0.84418069776319,0.5976910032197231,0.352403191799213,False,c1,1,"**Author:** `mstankus`
**Description:**
In TeXShop, you can click on a piece of content (for example,
a word) and choose sync and you are sent directly to the
part of the source corresponding to that word. It would be great
if that could happen for wikis.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",50080,-9,Low,True
4.832743574457705,-2.6467817944266336,6.914590507450509,10.91480201616993,-0.21581488324075626,-6.173606513470484,5.134065789442999,1.9295467299288642,-0.1676143243662697,0.773009338687733,2.0053344468915877,-1.3854336808654089,-0.9861347409538901,-0.3212402345468277,-0.10827759277831017,0.15236157821686971,-1.1787732884704645,-0.4325978665202792,False,c1,1,"The close icon as defined by the [[ https://wikimedia.github.io/WikimediaUI-Style-Guide/visual-style_icons.html | WikimediaUI icon principles ]]. OOUI is already featuring the correct icon.
| | Product | Description | Code | Screenshot | Screenshot after
| | -- | -- | -- | -- | --
| {icon check color=green} | OOUI | [[ https://doc.wikimedia.org/oojs-ui/master/demos/?page=icons&theme=wikimediaui&direction=ltr&platform=desktop#widgets-mediawiki-vector-ltr | Uses the correct icon ]] | | {F9379666} |
| {icon check color=green} | Post-Edit Feedback popup | Uses the Unicode × glyph with hover behavior | Extension:PostEdit outputs CSS generated content `×` with style rules. | {F7451633} | {F26525706}
| {icon check color=green} | Recent CentralNotice banners | ""x in a circle"" icon, no `:hover` behavior | Extension:CentralNotice outputs an img tag showing :$wgNoticeCloseButton which defaults to [[https://upload.wikimedia.org/wikipedia/foundation/2/20/CloseWindow19x19.png|CloseWindow19x19.png]] | {F26525761} |
| - | ~~Visual Editor Feedback dialog~~ | As of 2017-09 not an issue any more => converted to OOUI | | {F9404470} |
| {icon check color=green} | ULS | ~~Thicker stroke “x” SVG, no :hover behavior~~ | Extension:UniversalLanguageSelector custom `.uls-icon-close` class | {F9362244} | {F9404483}
| {icon check color=green} | Extension:GuidedTour | different icon with different size | `.guider_close` | |
| {icon exclamation-triangle color=red} | Extension:MultimediaViewer | bolder, less contrast; Exempt from amending is the main close icon as it would need a full icon redesign. Will be revisited after T177432 | | {F10595012} |
| {icon check color=green} | Extension:GettingStarted | different icon with different size and lighter grey | `.mw-gettingstarted-cta-close` | {F10172642} | {F10188673}
| {icon check color=green} | Extension:PagePreviews | different icon, bolder and bigger | | {F10318266} | {F10319955}
| {icon check color=green} | Extension:Translate | ~~Similar to ULS, different icon though, as it's minimally smaller in layout~~ | `.grid .tux-message-editor .close` | {F9405760} |
The differences make WMF wikis feel unpolished.
--------------------------
Original report:
**Version**: 1.22.0",50067,-9,Low,False
-4.33601894274647,4.514743165393668,-0.8785134130372558,-2.601130834450677,5.030827771277336,-2.147883986936828,0.3701706097154931,0.08683968101550832,-1.9818603302251758,-0.5961768562241998,-1.2460354654582684,0.4350060907984219,0.00258965989188642,-2.1131671107397305,1.0016486650717233,1.1843890669738948,-1.702502667383344,-0.37105021558924456,False,c1,1,"Component: UI
The speech bubble icon and ""Leave feedback"" link in Visual Editor look like they apply to the page being edited. I was expecting a Talk: tool.
It would be more clear if the text were ""Report bug in Visual Editor"", but that's annoyingly verbose. Which is sort of the intention here, I assume ;) Normally, this link would get buried in a dropdown menu or something, IMO.
The problem is exacerbated if you are sort of blind and zoom in your browser a lot, because the VE feedback link becomes very prominent once the toolbar is wrapped.
",49815,-9,Low,False
0.42854213534374486,-5.525453406456842,2.34719181037671,4.460549392449723,-3.700491811787842,-2.5942824106937703,-0.9909421549083026,0.3991888684979873,-0.1890263429989124,-1.302067218997982,-1.4412400506098475,-1.155438469780406,1.3929616867206596,-1.9198826160063613,-1.3191312648815492,2.0953202528637496,-1.6359714512547145,-1.44013030115604,False,c1,1,"Screenshot of page in view mode
Show thumbnail in user preference size in edit mode.
1. Set user preference to 300 pixel: ""Thumbnail size:"" of https://de.wikipedia.org/wiki/Spezial:Einstellungen?uselang=en#mw-prefsection-rendering
2. Edit page with image included as standard thumb.
Thumbnail is shown in a smaller size instead of the user preference size.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/thumb
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50379
**Attached**: {F10384}",49804,-10,Low,False
3.0603515010123874,-14.311963421833289,1.8257870407088177,-3.6126370779238965,0.5994912717989471,-0.8721561219333083,0.7500323410075191,-3.0176737376892997,1.6530228984993138,-0.2475602992124939,0.5475269205368241,2.001130680012036,0.941236580204114,-0.2279874824954291,-2.391642093976831,1.2096098962014974,-1.3662765901223843,-1.142935075765506,False,c1,1,"Review your changes
See screenshot.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F10352}",49786,-10,Low,True
-8.630478843122676,3.286829736542682,-7.699306266339091,-2.955931564251736,1.7528259607706702,1.693184971356979,-0.555387675588495,-1.204698237841389,0.7814028067204224,-1.3621639322426828,-1.3047196793460614,-3.8484745530992814,0.24535464844424304,0.9109780907843614,-0.2786337484146406,-0.22693755546545957,-0.49720436115876354,0.5339966285260693,True,c1,1,"Given that these all exist in DM, it's ""just"" a question of making a set of icons for each function and adding it to the tool bar (and then working out what to do with a toolbar with eight such icons when we wanted two.
Have left off from the existing list in ve.dm.TextStyleAnnotation.js:
* span - as that'll need to be a distinct bug given the complexity (it'll need at least an inspector, possibly a dialog)
* strong/em - should we just silently use these instead of b/i (or vice versa)? Either way, it feels confusing to give the user both options.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49780,-10,Low,False
10.402887932442512,-5.443821795658433,3.325809346064517,-2.440870319958703,-3.9022879740838534,0.4702049633412311,-0.06978223573887998,1.881466755518419,3.4241000653601104,-0.18787054593859853,-0.6003047591327455,0.1491779381788354,0.3476529792125409,-1.1651858990535469,-1.1002526667884824,0.7577674262426968,0.8565944054736148,1.5003009910566687,True,c1,1,"Cannot reproduce in Firefox/Mac or Chrome/Mac; asking user to reconfirm.
--------------------------
**Version**: unspecified
**Severity**: minor
**Platform**: PC",49679,-10,Low,True
-5.748548279815605,4.108412460764978,-5.759495619227131,-7.117454183918891,1.2810814104608454,-2.194363895925056,-0.8296955248823696,-3.6579413271808034,-2.618144450238513,4.36089844700189,-1.6362585139452623,0.03582124202145942,-0.2584994640510283,0.053008833701879254,0.9151485613208044,-1.301790007611934,3.186348055277082,-0.7514898181604248,True,c1,1,"As suggested by Timo - currently we have 'wmgUseVisualEditor' and 'wmgVisualEditorParsoidPrefix' which both need to be defined for each wiki we're putting VE on, which is a bit annoying (and prone to mistakes) - when we have all 295 Wikipedias with it switched on, it will be even worse. We should probably clean this up a bit.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49557,-10,Low,True
-6.626434149459664,3.288524658762185,5.569331052109707,1.7637070023467714,-3.77350632559528,3.406619641792118,-1.006616580113345,-1.1667363699466473,4.283986346787554,0.1228316331410868,0.4662350168647591,-1.7872795121147473,0.8496078895425452,-0.2564364834445403,-1.1694993079130303,0.08445873848281008,-1.3702493584323594,-0.8434024803095446,False,c1,1,"Please write your bugs report to http://parsoid.wmflabs.org/_bugs/ only with https to avoid a secure hole.
Please see this as a blocker for the coming roll out. Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",49508,-10,Low,True
-0.2125610691910449,-3.0322620739278356,-3.712679540792184,-1.6939468012723502,0.615194218928413,-4.296767266997947,0.3897473898319799,1.4572566031497622,-3.8161674775838463,1.2929235813458488,-0.08451017842842701,2.9165213941690107,-2.173252478768384,-0.9346901285393656,0.07313188214484079,2.5586460432771574,0.049466605000789254,-0.08330973810538822,False,c1,1,"It seems <syntaxhighlight is working just fine, but it's old deprecated 'redirect' <source is not recognized by VE, as can be seen in the link.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/wiki/User:TheDJ/Sandbox",49454,-11,Low,True
2.9260887066815218,-3.407904072386975,5.179894511954938,3.2719856011217745,1.5048255532124721,3.889312764578091,2.05337421588644,-1.5725563070082682,-2.556549405255053,-0.27020073529634736,0.024976310653427092,1.5549162643064067,0.03644697185706125,-0.35177856325136503,-2.1040391205566866,-0.22358417187799262,-0.5256120398599989,-0.7973314004342638,False,c1,1,"https://en.wikipedia.org/w/index.php?title=Phil_Thompson&action=edit&oldid=535300833
Note that in this mode, the VE tab is missing the oldid
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Phil_Thompson&action=edit&oldid=535300833",49453,-11,Low,True
0.2903850548675755,-4.02668669654377,-1.902758530690594,1.746914746791341,8.166387499719795,3.683975680290323,0.4985783290170076,3.023587998500184,-2.2724102686682355,3.174790325747564,-1.4821442443949018,2.140836180434259,-0.7730636782210167,-1.1073808310671875,1.7265143321078895,-0.9908209305468105,0.24134528791358778,0.4984607828291836,True,c1,1,"Currently the ""Edit source"" button's label is the same whether the page is extant or not. This should change.
--------------------------
**Version**: unspecified
**Severity**: minor",49421,-11,Low,True
6.7248124720994475,-5.037120455413991,2.362204623670152,12.180616161220561,-0.9392247463220693,-7.495478219910908,0.2058654386889618,-1.7090658289366192,-1.279142249204478,-3.4335731608035935,-1.9269112509706232,1.8756302882659577,4.207741219246529,0.35953706555202203,0.8075139211618074,-0.591820285111816,0.2725476929404944,-0.8946839309652435,False,c1,1,"That is https://github.com/senchalabs/jsduck/wiki/Inline-examples
For instance:
resources/js/ext.translate.editor.js
9: * Example usage:
resources/js/ext.translate.proofread.js
107: * Example usage:
resources/js/ext.translate.pagemode.js
10: * Example usage:",49113,-12,Low,False
2.6272666935391684,2.143463469789644,0.6889732061799769,-1.1661975024452609,3.7572845469598506,3.562133556577513,-4.2508860182878445,0.932377407333478,0.14115474506878795,3.053613514542218,-2.28247990409963,2.097614547306902,0.4729365071391003,-1.3412285440269307,1.935942859112406,2.2381499816945434,0.9090140840347336,0.9176397430607148,False,c1,1,"- Edit an article on the English Wikipedia in the VE
- Click ""Review and save""
- Click ""Something is wrong""
- Enter text into the field and click ""report problem""
Nothing happens - either the error report is not sent, or the fact that it was sent is not conveyed to the user.
Reproduced three times in a current Chromium version (Chromium/25.0.1364.160) on Ubuntu.
--------------------------
**Version**: unspecified
**Severity**: normal",49111,-12,Low,True
-7.510133065598216,-1.4882836530314822,2.1364042237371237,6.900196681421181,-3.8376115982553425,1.503778062256447,-0.35284736185183974,-0.553292940747889,1.1001326928017767,-2.6992712627890816,-0.12097878281448793,-2.152188239127347,-3.562113166240649,-0.06503508278495218,-0.6544625593372597,-1.2479467152718553,0.054074724456078416,1.5031163147101723,False,c1,1,"An automatic tracking category for pages with errors in <math> (when parsed by texvc) would help finding these pages and fixing the errors.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49037,-12,Low,False
3.9624829671096546,4.792801378884114,-0.09383931304845561,-5.745716101960846,-5.316288771612342,1.5254061687768712,-0.2303943012378591,-0.29081430020079396,3.1365327827738856,-0.9836980715465331,-1.9861745189167788,1.5064612814768885,-1.27820904677142,0.4580095415896217,0.10341474396533368,0.04069422979326032,1.5597984330716,0.6039218736158978,False,c1,1,"Per IRC discussion between me and Trevor:
* Move list of MetaItems to dm.Document
* Keep MetaList (possibly rename it) with current API, wraps around list of items in Document
* MetaList takes a surface, and can make changes using that surface
* MetaItem.remove method will have to be removed, because it can't call back into the surface
(This is for post-July)
--------------------------
**Version**: unspecified
**Severity**: enhancement",49025,-12,Low,
-7.795349777052905,3.005108313837166,-4.260278256725792,2.910474712835409,4.0653022842918585,4.4967260888935865,-0.49536318556789904,1.9637353476300023,-2.2177610455094414,-0.32535881118223564,-0.21284570882845033,0.45530422878019006,-3.021770269674751,1.7662935713174983,1.2306974803886481,0.48777865687571786,0.08023297440202382,-0.6883986156531985,False,c1,1,"Take the document:
<!-- meta -->content<!-- data -->
If you remove all of ""content"", the two comments now have to share an offset in the metadata array but this process is not recorded in the transaction. As a result, when the commit is rolled-back the comments aren't re-split so the resulting doc is:
content<!-- meta --><!-- data -->
--------------------------
**Version**: unspecified
**Severity**: normal",48954,-13,Low,True
-0.9262663691919024,4.270019538837698,4.743525615100246,-2.6217260164760567,-1.41700675368219,-1.21566324995139,1.4265369220013042,2.883981845769461,-2.0126286697655305,-0.23326632714610263,0.8425170095323442,7.883193391300311,1.8935627237509634,-4.053427931806079,1.8073820906386908,-1.3060596798628812,-1.0367548331812309,1.2298182441591854,False,c1,1,"We are using `sleep` in several places. Sleep is evil. The code should be refactored so the sleep is removed.
There are more robust ways to wait for something to happen than using sleep:
http://watirwebdriver.com/waiting/
https://github.com/cheezy/page-object/wiki/Ajax-Calls
```
$ grep --include *.rb -R -F 'sleep' .
./wmde/WikidataBrowserTests/tests/browser/features/support/env.rb: sleep env_no * 4 # sleep time to give webdriver time to setup
./wmde/WikidataBrowserTests/tests/browser/features/support/modules/entity_module.rb: sleep(1.0 / 3) while execute_script('return jQuery.active') != 0
./wmde/WikidataBrowserTests/tests/browser/features/support/modules/entity_module.rb: sleep 1
./mediawiki/selenium/features/step_definitions/environment_steps.rb: sleep 0.3
./mediawiki/vagrant/mediawiki/extensions/CirrusSearch/tests/browser/features/step_definitions/general_steps.rb: sleep(Integer(seconds))
./mediawiki/vagrant/mediawiki/extensions/CirrusSearch/tests/browser/features/step_definitions/search_steps.rb: sleep(5)
./mediawiki/vagrant/mediawiki/extensions/CirrusSearch/tests/browser/features/step_definitions/search_steps.rb: sleep 1
./mediawiki/vagrant/mediawiki/extensions/Gather/tests/browser/features/step_definitions/common_steps.rb: sleep 5
./mediawiki/vagrant/mediawiki/extensions/Gather/tests/browser/features/step_definitions/edit_collection_steps.rb: sleep 5
./mediawiki/vagrant/mediawiki/extensions/MobileFrontend/tests/browser/features/step_definitions/editor_ve_steps.rb: sleep 2 # this gets around a race condition bug in ChromeDriver where both the confirm and the toast are in the page at once, and Chrome reports either ""stale element reference: element is not attached to the page document"" or ""Element does not exist in cache""
./mediawiki/vagrant/mediawiki/extensions/MobileFrontend/tests/browser/features/step_definitions/notification_steps.rb: sleep 1
./mediawiki/vagrant/mediawiki/extensions/MobileFrontend/tests/browser/features/step_definitions/notification_steps.rb: sleep seconds.to_i
./mediawiki/vagrant/mediawiki/extensions/MultimediaViewer/tests/browser/features/step_definitions/mmv_download_steps.rb: sleep 1
./mediawiki/vagrant/mediawiki/extensions/UploadWizard/tests/browser/features/step_definitions/upload_wizard_steps.rb: sleep 1 # Sleep because of annoying JS animation happening in this menu
./mediawiki/vagrant/mediawiki/extensions/UploadWizard/tests/browser/features/step_definitions/upload_wizard_steps.rb: sleep 1 # Sleep because of annoying JS animation happening in this menu
./mediawiki/vagrant/mediawiki/extensions/UploadWizard/tests/browser/features/step_definitions/upload_wizard_steps.rb: sleep 1 # Sleep because of annoying JS animation happening in this menu
./mediawiki/vagrant/mediawiki/extensions/UploadWizard/tests/browser/features/step_definitions/upload_wizard_steps.rb: sleep 1 # Sleep because of annoying JS animation happening in this menu
./mediawiki/vagrant/mediawiki/extensions/UploadWizard/tests/browser/features/step_definitions/upload_wizard_steps.rb: sleep 0.5 # Sleep because of annoying JS animation happening in the date picker
./mediawiki/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/tests/browser/features/step_definitions/cite_steps.rb: sleep 1
./mediawiki/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/tests/browser/features/step_definitions/cite_steps.rb: sleep 1
./mediawiki/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/tests/browser/features/step_definitions/cite_steps.rb: sleep 1
./mediawiki/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/tests/browser/features/step_definitions/cite_steps.rb: sleep 1
./mediawiki/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/tests/browser/features/step_definitions/media_interface_steps.rb: sleep 1
```
",48887,-13,Low,False
-2.9560094689977654,-1.9606763621086802,-5.505805538507236,-2.8820386743697775,-1.0977789569043486,-2.88483100245094,0.9228194907506335,6.625928585150013,2.8215173619646485,-2.205234258993644,-2.565694008429944,-0.4791666661268331,-1.803191946878142,1.98413103501891,-0.1949065171904074,0.2598811527925908,1.0073757064300566,-1.4291715473514413,True,c1,1,"mw.ViewPageTarget tabLayout is currently hard-coded, which means that we can't have VE work in replace mode on one wiki and add mode on another.
[No doubt other aspects of the integration configuration should not be hard-coded.]
--------------------------
**Version**: unspecified
**Severity**: minor",48871,-13,Low,True
-1.675182638566228,2.8273028107769775,-1.476900864251606,4.917587140642519,-2.539142759972808,1.7540260057102344,-2.797186473714173,-0.19378348902611878,-1.6081657182692028,-2.3356164407286273,0.34729527480149436,0.036080776496399514,0.012958927744998405,0.8734570872263125,0.9393898421880724,0.5499372759482235,1.1774626847770515,0.14908264190355625,False,c1,1,"Page: pages are not plain wikitext pages but are split into three textareas: header, footer and body and a proofreading level tag (note 1).
So, an adaptation of the VisualEditor to these pages is needed in order to make edition of the pages work.
The UI need to be tweaked in order to allow the splitting of the main textarea into three and the edition of the Proofreading level at the save of page as it works currently for wikitext editing (example: https://en.wikisource.org/w/index.php?title=Page:La_Fontaine_-_The_Original_Fables_Of,_1913.djvu/20&action=edit ).
An other useful (but less important thing) things is to add modules to the Visual Editor to support specific tags used by Wikisource like <pages>, <section> and <poem>.
note 1: structure of the page as save in the database:
<noinclude><pagequality level=""LEVEL"" user=""LAST PROOFREADER"" />HEADER<div class=""pagetext"">BODY<noinclude>FOOTER</noinclude>
--------------------------
**Version**: unspecified
**Severity**: enhancement
This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey
This proposal received 41 support votes, and was ranked #23 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Wikisource#Visual_Editor_adapted_for_Wikisource",48580,-14,Low,False
-1.3565140580412474,-7.017816316447702,-2.642936594948331,-4.6963264392861195,0.3975209617229759,-1.0018039917310417,0.04633511286952885,-2.5210966561469488,1.920764755545452,-1.52227744741043,-0.41728129258205016,1.5823340201294258,0.8186755990833632,-1.2627054594665004,-1.0463741188953994,1.051162657291098,-0.7729450854833719,-0.6365200075579998,True,c1,1,"Inline comments would be powerful addition to AFT. It would be something like
https://en.wikipedia.org/wiki/Stet_%28software%29 integrated into MediaWiki.
I think it would help people make useful comments that could more
quickly be acted on/resolved.
I realize this would be a large enhancement, but I think it's worth considering at some point in the future.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://annotator.wmflabs.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",48440,-15,Low,False
-7.18031764671092,-1.048946031191397,-1.7702898110139866,-1.0286185933998784,-0.9519512217767215,-1.0841403052114722,4.789812712116869,0.9381195312452361,0.7082482365060534,-0.060619674734892826,-0.31419646072351126,-0.6595107162020538,-0.638057369776261,3.4929434817955496,3.1260171319868144,2.197635239172597,-0.6638321347956574,0.6520680363642415,False,c1,1,"Various users find them inappropriate in #mediawiki because it is a support channel, not as much a developer discussion channel (#wikimedia-dev).
Whether to move them there or to a dedicated channel isn't clear yet.
See discussions on bug 46282 and bug 46144.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",48322,-15,Low,False
3.417831210429951,-11.428049807811894,3.855731336159753,1.5882564082090327,-1.5800050866603448,-2.0567937304202712,0.5943367351669755,-0.5641063054516782,1.4334333694913526,-2.5976778263095217,-3.1999144644425566,0.7620970478833882,-0.9281270818292722,-0.17946673768863164,-1.9952067491894216,-0.48766512740148926,-0.7684952414176243,0.5029005369099833,False,c1,1,"wikibugs has gone missing from #mediawiki.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://www.mediawiki.org/wiki/Git/IRC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=28402",48144,-16,Low,False
-3.4250127154303818,-2.847324459748771,-8.736422678539254,-1.784596564545348,4.056670143345233,-3.310756015696504,-0.3042049131916018,-0.40915222713242894,-0.913561482047449,-0.7937203879226216,-1.6305651276194688,-0.05300619963766917,-1.7894640136139497,0.6213900678694078,0.9158296099191983,-0.959196933518657,0.5654028161374443,-0.4211607761176699,False,c1,1,"This is kind of a ridiculous case, but it cost me an hour of debugging time, so documenting it here for posterity. It won't be a practical issue until we start composing transactions together.
Consider:
var data = ve.dm.example.withMeta,
oldDoc = new ve.dm.Document( ve.copyArray( data ) ),
newDoc = new ve.dm.Document( ve.copyArray( data ) ),
tx = new ve.dm.Transaction();
tx.pushRetain( 11 );
tx.pushReplaceMetadata( [], [ { metadata element here } ] );
tx.pushReplace( [] , [ 'a', 'b', 'c' ] );
ve.dm.TransactionProcessor.commit( newDoc, tx );
ve.dm.TransactionProcessor.rollback( newDoc, tx );
After running this, you'd expect oldDoc.metadata and newDoc.metadata to be equal, but they're not:
> oldDoc.metadata[11].length;
4
> newDoc.metadata[11].length;
5
When the transaction is rolled back, the metadata element that was added was never removed. I think this is because the content insertion pushes the metadata back, and then when the rollback tries to remove the metadata again, it can't find it. When the metadata replacement and content replacement are swapped, it works fine, so that's my workaround for now.
--------------------------
**Version**: unspecified
**Severity**: enhancement",48138,-16,Low,False
-16.33384102039058,17.14232791246794,3.680706258755901,5.0173310928051995,-3.365504046886419,-2.164172504676963,-3.095182361004993,2.0004756455988257,7.661220479914324,-1.0523327847662247,-2.0310169677611793,-0.6080031758083682,-0.03184437790747996,1.4137677443106949,-3.0163599370364533,-1.273815633122615,5.701303736268488,-1.7409751604751948,False,c1,1,"Trevor complained the naming of these things doesn't make sense, so let's sit down and come up with a strategy for renaming this stuff at some point.",48133,-16,Low,
-3.495010261513247,3.4843712401943634,-5.407582894540738,-7.389546016065213,3.706724533586526,-1.8884848902273939,3.175143695812909,2.2362154186718213,1.2420094781543143,-0.32981137067205424,0.4354320427532592,-4.766283541818589,-1.0505728070333893,0.2785554492179063,0.42260460851532144,0.3173572352962635,0.9527620011914377,-0.4611232687276552,False,c1,1,"TODO comment in ve.dm.Converter.test.js:
// TODO: this is a hack to make normal heading/preformatted
// nodes the most recently registered, instead of the MW versions
It's not entirely clear to me how we should fix this. Maybe once we hard-split the VE and MWVE code bases and each of these has its own test suite, then we won't have to worry about this as much.
--------------------------
**Version**: unspecified
**Severity**: normal",48048,-16,Low,True
-5.875095653027283,3.5429554112261457,-3.3578922587825453,-4.637867584922832,6.245418703562034,-6.978897247479563,3.020702560299944,-3.625838482439808,-2.811903316088717,-0.5335798298360226,-0.7312088162821793,-2.3019322847632226,-0.3920373943942792,1.2829982460732499,1.496910956361936,-0.37504530145730763,-2.6520542270110816,-0.01662268746975526,False,c1,1,"When the Parsoid server is down completely (e.g. because you forgot to start it), the error message VE gives you is ""parsoidserver-http-200"". It's kind of ridiculous that it's presenting an error with 200, but it's also a lie: 200 wasn't the response code we got from Parsoid, we got no response whatsoever.
--------------------------
**Version**: unspecified
**Severity**: normal",47916,-17,Low,True
-4.6751572137833195,1.4301201450933885,-1.5646314654922815,0.7581952708096475,2.922402029169786,-2.0084666172545287,5.629559584986738,0.9080210795624976,-3.1825367654157484,-0.7646041507220787,-0.04036330269532451,-0.49457557765212545,-1.5427090078595187,-0.11928510389923819,0.6872145142603996,0.7655975681953381,-1.8968123858714325,-0.8059045035796013,False,c1,1,"DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).
--------------------------
**Version**: unspecified
**Severity**: normal",47701,-17,Low,True
-4.807539932706501,-1.697621571401374,-7.17563450143779,-4.63818076923727,1.5028173973751597,6.5874724362029475,8.57152981556095,10.770860649391054,-2.7561112021313754,4.3811319143141265,4.272242588262893,0.20783288145708423,0.1716460638674242,-1.7821584046525993,4.000319125095353,1.1585598050658978,2.0681867960662137,1.8883089215650626,False,c1,1,"Functions like runConverterTests() and what not are often global functions in the test file. These should be un-global-ified somehow.
",47291,-19,Low,
-0.9972542955830401,1.2509572918766434,-2.948629150372172,-5.800116063535845,-5.3043945332228795,6.6992585080074205,2.0011339891390163,1.0018276114356341,-0.6036003710993716,0.5208855109148134,-0.5815651122641663,-4.299398183117607,-0.729271614562057,3.2710223113396655,0.3272416405026455,-0.12987073957766415,0.9649585081948173,-0.8709828715102461,False,c1,1,"The hallmark of chainability in VE, dm.SurfaceFragment, doesn't actually use @chainable to document the chainability of most of its methods.
--------------------------
**Version**: unspecified
**Severity**: normal",47264,-19,Low,True
-8.217814535401411,-1.2623093827766567,-10.734808097730504,-7.485380667027281,1.253232003570486,2.1826937403100732,-0.4869781454544624,0.3748531611041418,2.6863908756517,-1.2791282677579061,-1.112832329167522,0.6879339735448586,-0.8316204258969311,0.9366689155577603,-0.8459419942650168,-1.4531669894103538,0.7507825901841316,-0.05969232448324746,False,c1,1,"ve.dm.Transaction.newFromWrap() currently doesn't check that the transaction it generates will be valid. That is, it will ensure that things are unwrapped correctly, but it doesn't check that the result doesn't end up violating parent/child restrictions.
It's not entirely clear to me whether we should try to rectify that or throw an exception, but either of those is better than generating a transaction that, when applied, will make the document nonconformant.
--------------------------
**Version**: unspecified
**Severity**: enhancement",47183,-19,Low,
-5.930450148397224,-0.9154114133337519,-2.040281505147556,6.097975197706742,-2.45793951436646,-1.3863617071013432,-1.7310867549780538,0.35478330055281804,3.2122729353713995,-0.6137014072797156,1.2695274580545228,0.060197817767057904,-0.6262554731604384,-0.8620699126410116,-1.317774028991435,0.6378973578538871,-0.3412776908807664,0.3821979688529502,True,c1,1,"When a user saves a page, VE should check for references (<ref>s) created without the de-referencing block (<references /> or {{reflist}} or...) and intervene:
* prompt them to fix before saving (out of the notices area?);
* refuse to save before fixed (grey out the save button?); or
* auto-fix for them (insert a ""== References ==\n<references />"" section just above the categories), though this (a) sucks, (b) enforces a particular wiki's style on other wikis in code, and (c) would be difficult to internationalise
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54906
https://bugzilla.wikimedia.org/show_bug.cgi?id=51260",47132,-19,Low,False
-0.952599249185452,4.909748241410949,-5.10656456000955,-4.305633699889098,2.01131514346832,0.24608971670294788,-1.6901858409824655,4.0553969841996125,-1.280608441729196,-0.8832965009600011,0.18230610616734166,-2.6382499050477612,0.22253177657966638,-1.2274546131430686,0.23655308693489285,-0.31984178509137084,0.8412581451892633,-0.9475048173662528,False,c1,1,"Using a more extensive default $linkTrail regex was tried in 416c84480 (although I don't know why it used `\p{L&}` rather than `[[:alpha:]]` or `\p{L}`), but this was reverted in 5b97a5bb due to {T17035}. We could probably try that again (without the apostrophe, see T16655) now that we require a more modern version of PHP with a more modern version of PCRE. It may not work correctly for alphabets other than Latin.
----
Please have a look at
https://www.wikidata.org/wiki/MediaWiki:Gadget-rightsfilter/hu
where the link has the form [[:hu:Reguláris kifejezés|regex]]alapú
and ""ú"" is not linked.
This is a multilingual project, so all letters should be included into links, or at least all Hungarian letters. :-)",47126,-19,Low,
9.47536587752131,-1.182848967963416,-11.018930567235401,5.449423514994016,-1.821608826218413,-0.8551428170422735,-2.2397331581810773,-0.4816897172053681,-3.029806637566719,3.879217962889097,6.969381778207092,-1.6169891038347401,-4.159376739872758,-1.1898547116277327,0.632733050762126,1.191103173918563,-1.3258675321809152,0.05034674147802787,False,c1,1,"This test works in Chrome, but in Firefox it fails with:
Expected:
""a<b>b<span typeof=\""mw:Entity\"" class=\""ve-ce-leafNode ve-ce-MWEntityNode\"" contenteditable=\""false\"">c</span>d<div class=\""ve-ce-leafNode ve-ce-alienNode ve-ce-alienInlineNode\"" contenteditable=\""false\""><tt>e</tt></div></b>""
Result:
""a<b>b<span class=\""ve-ce-leafNode ve-ce-MWEntityNode\"" typeof=\""mw:Entity\"" contenteditable=\""false\"">c</span>d<div class=\""ve-ce-leafNode ve-ce-alienNode ve-ce-alienInlineNode\"" contenteditable=\""false\""><tt>e</tt></div></b>""
(the difference is in the order of the class and typeof attributes)
We should probably implement DOM comparison instead of string comparison in the ce.ContentBranchNode test suite.
--------------------------
**Version**: unspecified
**Severity**: enhancement",46808,-21,Low,False
-6.439123740052922,-1.0324293140042844,-6.224171550128482,-3.373968472683736,-1.0623411340587539,-0.21332865027528347,1.2008236604556535,1.6425827914959248,0.28628088474231883,0.14244978625306004,-0.8373008271557896,-0.18700431835593256,0.1680598873852519,-0.12669465547346714,-2.4325456914078547,-2.544966983873356,1.4232054590764889,1.4982699170428877,False,c1,1,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.
The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.
And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.
--------------------------
**Version**: unspecified
**Severity**: enhancement",46364,-23,Low,
0.7175968107920361,-8.9045490905241,-0.1334612782004605,1.2477072754789686,0.20353570783326502,5.532693949890839,2.8786789022826627,-0.37655443888967705,0.3417874360756509,-0.6454742400865445,-0.810778597124787,3.588000886743206,-0.16390507516484387,1.1707563544008748,3.895138972651755,-2.0027909269767314,1.1043081894041438,1.6469571347799776,False,c1,1,"The GettingStarted extension is tagging edits of new users (bug 43191). These tags should be temporary.
--------------------------
**Version**: unspecified
**Severity**: enhancement",46361,-23,Low,True
-6.814766421422659,6.67566873199846,-8.088213195777206,-2.4541051254270574,-2.622538046803003,1.8822109550059973,0.09793082508115081,-0.8590037483550617,0.9309348433044056,-1.505133854311647,-0.4713975582133645,-0.4429274371473654,0.6647035498554863,-1.0273216537024075,-1.0200831958710523,-0.9414885043706622,0.6056339505480823,0.3130135777808787,False,c1,1,"I encountered many times now on wikis (usually the small wikis) that there are 100s of local MediaWiki pages with translations from before translatewiki.net covered that language.
And even after twn covered it, there may have been local improvements that over time make it into twn, but then the local page stales.
To avoid translations from going out of sync (the longer we wait with this, the harder it is to clean them up as the difference between an override and an outdated translation becomes harder to tell), and also to avoid migration issues when messages change.
Lets run this asap.
--------------------------
//EDIT//: deleteEqualMessages.php has been completed on the following wikis:
{P1988}",45917,-25,Low,False
-6.946907537831461,1.0404464638898538,-2.9481948775781,0.8211081819176083,-2.8497432907381373,0.10012320882847492,1.4205897244067822,1.6488168287717517,1.630131349556957,-0.6959382349109582,0.23030143442081075,-1.011999225741402,-0.6085474185268547,-0.47557970085940493,-0.09367483243697627,-0.32770101660464634,-0.031174259320826847,0.1678524550636491,False,c1,1,"We should amortize per-request overheads by batching API requests.
AFAIK there is no generic batching support in the API currently, and adding it would probably be a bit too time-consuming for now. Instead we can add a unique string as a separator, for example something like
<nowiki>d41d8cd98f00b204e9800998ecf8427e</nowiki>
This would work for for action=expandtemplates and action=parse which are the main workarounds we currently use. In the longer term we should switch to explicit methods that don't involve parsing wikitext, which is probably also a good moment to add real batching support.
Decisions about batch sizes could be based on wikitext source size initially (based on the assumption that templates with a bazillion parameters also take longer to expand). A fixed number of templates per batch would be another simple alternative. Really fancy batching could use stats of previous processing times (returned by the PHP preprocessor per transclusion and stored in HTML).
Ideally we would also enforce separation between batched requests to avoid non-deterministic behavior for stateful extensions.
--------------------------
**Version**: unspecified
**Severity**: enhancement",45888,-25,Low,False
-2.3511277682612004,-4.108215993205482,-6.707650511339965,-9.858865873063658,-1.5279212049776447,-3.2969675021668783,5.452094803359615,6.335869236838941,-0.020510799001781932,-1.8184217440352057,-2.684251221472211,-2.0100604780655593,-2.9089151339556114,1.508057880314639,2.8538597353470854,-0.7163640135678593,-0.9903728176321389,1.4461010190837957,True,c1,1,"From user suggestion:
| Heading 1 is very rare on enwiki, and indeed on most other installations.
| Where it is used (mostly on project discussion pages), it does not usually
| need to be edited. VisualEditor should not offer it.
--------------------------
**Version**: unspecified
**Severity**: enhancement",45334,-28,Low,True
6.944014015714632,-1.1724941025945999,-1.4986913527416892,-3.647177334307483,-0.9955245729453415,-1.7288971039165524,1.5745937610503145,-1.8801427925210712,-0.16913124842645738,-0.46632908307891263,1.6305744727561762,3.4705269269339185,-1.0435620975922317,0.15883694900630108,-0.8790246493159586,0.39367586675135974,-0.07700579202755464,0.23240128457890497,False,c1,1,"**Author:** `turb`
**Description:**
When cookies are disabled, VisualEditor loads indef. It would better to either 1) be able to use it without cookies (I suppose that's not possible) or 2) display an adequate error message.
Tested on Firefox 17.0.1 with Cookie Monster 1.1.0.
--------------------------
**Version**: unspecified
**Severity**: minor",45193,-28,Low,True
6.003277607813882,2.5854757297570963,-0.8292622843335558,-4.768248598726297,-1.8977495032844425,-4.419060032868781,2.9087618278558027,2.5422625546616655,-0.7922864854411991,-0.6750808256896184,-0.3441182311099644,-3.809237481805315,0.32605365686869847,-1.2103124045510936,-0.6031827463095736,1.43249156035457,0.20104674430012381,0.3061880088415634,False,c1,1,"**Author:** `kartiksinghal`
**Description:**
I am using WikiEditor 0.3.1 in my mediawiki (1.19.2) installation and found that for some weird reason, undo/redo (Ctrl+Z and Ctrl+Shift+Z) doesn't work in the editor with Chrome, Chromium and Firefox browsers; while it works for Rekonq and default KDE webbrowser.
I found T33780 - a slightly different but probably relevant bug report.
Also, undo works just fine in default VisualEditor in Chrome.
Interesting point to notice is that Undo/Redo work fine even on WikiEditor used on Wikipedia, but not in my mediawiki instance, looks like some good changes not pushed to upstream yet.
I also tried test2.wikipedia.org, it works fine there as well.
--------------------------
**Version**: REL1_19-branch
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31780",45187,-28,Low,False
-1.7021167445796643,-2.223157311603199,-0.4558391839943674,4.34011052610725,1.3481811709088412,-2.611761257960743,3.607176077870853,3.4428820554201454,-0.4144479373377375,1.181028200208556,-0.3609677131827671,-1.4258509547586786,0.11664690725089866,-4.097509304782194,3.3635179312339423,-1.7526380571881282,0.1029634069053551,-0.29769966569019846,True,c1,1,"Parsoid diff failure errors are not very descriptive - ""error loading data from server: unsuccessful request: diff failed."" but not why (in this case, it was because the target oldid had been deleted subsequent to the user pressing save, but a more graceful message would be good.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44354
https://bugzilla.wikimedia.org/show_bug.cgi?id=39057
https://bugzilla.wikimedia.org/show_bug.cgi?id=63149",45147,-29,Low,False
-8.510102019525512,4.532372160675145,-2.9897848682357875,0.8469549802754104,0.8223071393460966,1.4248738339294096,-0.4955463312841095,2.6340137693022116,1.5053085123461096,0.7364524178659666,-1.1067594599799375,0.2314891160255821,0.008242888326134512,-1.0221871386191506,0.4415212206920094,1.63595166056458,0.4629259996423747,1.913668439284699,True,c1,1,"For content which is alienated, provide a way for users to get a wikitext editing window for just the wikitext for that item. This allows users to modify content that does not have an inspector yet, and for ""power users"", make tweaks in an environment that is familiar to them, without overwhelming other users. Ideally, this would be syntax-highlighted and pretty and helpful, but anything at all would be a start. :-)
This will require some serious magic in Parsoid to identify the causal wikitext and allow partial document retrieval, and so this is very much in the ""enhancement"" pile for now; putting in UI as it's an inspector, but it will have impacts all the way down through DM.
--------------------------
**Version**: unspecified
**Severity**: enhancement",45133,-29,Low,False
3.443189895189103,-10.531968382888016,0.04993778734470666,5.257746592672724,-2.9269044821004533,-1.5958544887938233,0.9966203246995162,-0.787608663127039,-1.5332315706907205,-2.1299230723622973,1.3575391864711448,1.7669282328328568,-3.4245213590441113,-1.2648743709287342,0.38257571339369534,1.8229993096745674,0.36943748233074136,0.038621799035969184,False,c1,1,"<poem>....</poem> is unparsed but shown as plain wikitext:
https://en.wikipedia.org/wiki/User:Raymond/poem
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/wiki/User:Raymond/poem",45120,-29,Low,
3.561210519413384,-6.588952125444378,-0.09633557512799129,-1.902858774745622,-1.9294780400819622,-4.159696900975619,-5.693937104875774,5.079193988769812,-2.9874427721726953,-3.303554219111173,6.28297512137166,3.7738833137853325,-3.000974671659952,-2.8127597005676512,-1.1429350096708335,4.364955483614311,-0.567378068397733,-0.46016159541598767,False,c1,1,"<timeline>....</timeline> is unparsed but shown as plain wikitext:
https://en.wikipedia.org/wiki/User:Raymond/timeline
**See Also**:
{T29157}",45115,-29,Low,False
-2.1847415248688526,4.036154331900004,-2.808263486602643,-5.261542669973383,2.3437806178555394,6.553131761320158,1.24634018946725,2.5958225764612184,-1.5826687867119453,-0.03973484599403143,0.1861736291343421,-3.8217179973197926,-0.30841916786332124,-0.22170562747484723,-0.1893051837534534,0.6893080562390097,0.8534585349135588,-0.6116555737869593,True,c1,1,"On successful save, VE informs the user with a notification; however, this is not the same as the one deployed to the English Wikipedia (and elsewhere?). We should just inherit that, if possible.
--------------------------
**Version**: unspecified
**Severity**: trivial",45091,-29,Low,True
4.291306479636024,-0.2742497321162638,-0.30955085050371345,1.5135967699311745,-5.0184328246848455,-2.286928604095622,-2.2594098988351408,-0.8330347788913497,-1.3491162898139424,-2.156797799257601,3.441247566134425,1.1896242404773492,-1.2290295220177452,1.6437392045304131,-0.3105786210443595,0.379876648487194,0.16532779374785767,0.8867426095058761,False,c1,1,"//This task is about PHP errors, for fatals, see T89169.//
-------
Although we get PHP warnings in the apache syslogs, we don't really get much information about it:
Dec 13 18:30:43 10.0.11.48 apache2[9987]: PHP Warning: preg_match() expects parameter 2 to be string, array given in /usr/local/apache/common-local/php-1.21wmf6/extensions/FundraiserLandingPage/FundraiserLandingPage.php on line 96
Dec 13 18:30:43 10.0.2.198 apache2[24462]: PHP Warning: preg_match() expects parameter 2 to be string, array given in /usr/local/apache/common-local/php-1.21wmf6/extensions/FundraiserLandingPage/FundraiserLandingPage.php on line 96
We could do with recording more information (to a different log file on fluorine), like we do for both the fatal log and the exception logs
-------
Patches: <https://gerrit.wikimedia.org/r/#/q/message:T45086>
Checklist:
* [x] Improve de-duplication and message counting by ensuring `normalized_message` does not include the exception_id. – Pending review: https://gerrit.wikimedia.org/r/374895
* [x] Introduce $wgPropagateErrors to avoid duplicate logging under `type:hhvm` – Pending review: https://gerrit.wikimedia.org/r/338911
* [x] Enable $wgPropagateErrors in Beta Cluster. https://gerrit.wikimedia.org/r/c/409171/
* [x] Enable $wgPropagateErrors in production Cluster.
* [x] Remove unused `exception-json` conversion filter from `filter-mediawiki.conf` in `operations/puppet.git`
",45086,-29,Low,False
-1.0414248463861844,0.48223286802220855,0.13087731699119942,0.19799993865437848,-0.41944527119366853,-1.3435369993300506,-1.4489090643182614,2.129888749386691,-4.204837108148012,2.619738644317085,2.356192124007165,-0.4397751860104525,-1.870173504756874,0.38104320780951717,-2.1925729234488514,0.7733868430643982,1.8044334608654589,-2.0534739979758303,False,c1,1,"Visual Editor sometimes creates nowiki markup around simple square text brackets. Interestingly, it does that only in some cases, and not in others. For the same structure, it can also handle the text with nowiki, but does it in others. Text case:
The example below shows that in some cases this is done, in others not:
# Remains unchanged: Test text for the VisualEditor: [[Link target|These are ['''just''' normal brackets]]].
# Superflous nowiki-tags added on editing: Test text for the VisualEditor: [[Link target|These are '''just''' [normal brackets]]].
Edit with Visual Editor to see the effect.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T54268}",45067,-29,Low,True
-5.317693523192395,3.8400924824713734,3.587256468722977,4.5392495301135325,2.6737454911459366,0.0013626678545599624,0.8164312238483813,0.4270690218394406,-1.1289492857047732,2.530942257391213,-1.2361343357850756,-1.3520719761579256,-0.8283128124411974,-0.1985200006033807,0.7867060671838919,0.5281343625525341,-2.7534031103288763,2.979188531983329,False,c1,1,"Present situation: the Visual Editor, when clicking on an existing Wiki-Link, provides the chain-link icon which in turn opens a dialogue which contains a pick list. In the pick list two sections exist: ""Existing page"" (value e.g. ""Pretoria"") and ""Web link"" (e.g. ""http://Pretoria"").
The present dialogue is good enough for creating new links. However, for existing links it is somewhat confusing to offer a nonsense http:// link as an equally valid alternative to an existing or previously confirmed wiki page.
I suggest to keep the present behaviour for new links, but for existing wiki-page-links suppress the ""web link"" part of the pick list. It will still be possible to enter URLs directly in the dialogue box, the enhancement is only about suppressing it in the pick list.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43841",45063,-29,Low,True
-7.110849426481819,3.4600911923343745,-1.397571980110147,-0.40130141518409745,0.18637299263408003,3.73777318220593,0.683518772935801,0.9502746728870511,2.3303498916575522,0.7930011169008386,0.25921633353990714,0.17932550641271217,-0.6286405343717556,1.7633999190972567,-1.3732607834910873,1.3138557700226565,0.4689279440526475,0.4454039280257758,False,c1,1,"To account for editors that don't open a new page, simulate a click instead of using window.location directly.
That way editors such as VisualEditor will get the edit event and initiate the editor.
VisualEditor works without this as it updates the ca-edit url with ?veaction=edit, so it'll work. But still, going through a useless reload is... useless.
--------------------------
**Version**: unspecified
**Severity**: enhancement",45052,-29,Low,True
-6.325681110778235,1.332334200114719,2.663231489714999,2.7432737150416004,-0.9737136007301546,4.018626411215168,2.2622735356705688,0.25925246557308956,-0.8746223196726945,-0.007619662035097896,-0.5707505274434133,0.7201705049718066,-0.9419528353885926,2.7193928298159653,-3.4327279945171605,-0.48214177149806636,-0.09998664936484847,1.620340505154404,False,c1,1,"Reported at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Error_saving_data_to_server:_error: the parsoid appears to time out(?) and reports that there's an error, while actually saving the page. Meanwhile, a second attempt at saving has the same problem, /also/ saves...but adds random duplication of sentence fragments. See
https://en.wikipedia.org/w/index.php?title=Cologne&diff=next&oldid=527666838
--------------------------
**Version**: unspecified
**Severity**: normal",45043,-29,Low,True
-0.7417337557559267,5.5785286105890854,0.31029204222581797,0.07857935029228669,-2.337394806477004,1.1674225221489427,-0.14552643496161544,4.483802536648715,-1.911199928759357,2.735984483878667,-0.9819415869256138,1.0965759479671642,1.0484126773802394,1.2846209419161827,-0.48260940367461114,0.23796230376845617,-2.202836796141301,1.4465645623460095,False,c1,1,"When using the VisualEditor and having the Preference ""Edit pages on double click (requires JavaScript)"" on, the Editor is stopped as soon as one tries to select a word (= double click)or paragraph (= triple click). The javascript for ""Edit pages on double click (requires JavaScript)"" needs to be modified to check whether in VisualEditor mode or not (all works ok when in normal editing mode.
--------------------------
**Version**: unspecified
**Severity**: minor",45023,-29,Low,True
2.179012737850695,1.1501349073099867,5.343334882443763,-2.092801349082574,-2.3735926145581723,-0.8983890012943188,0.0006479760321287387,-3.618034690771193,-1.8970080686116904,-1.4922825314967159,2.763688255566739,0.38675381351832283,-1.1521836748952783,0.2827318940837076,1.0727297184111384,-2.430932865407628,-0.730019331506776,1.6119316004215436,False,c1,1,"When trying to use VisualEditor on the English Wikipedia at <https://en.wikipedia.org/wiki/James_Mackay,_Baron_Mackay_of_Clashfern>, I get the following error in my browser's console:
---
[11:35:31.120] TypeError: this.registry[name].static is undefined @ https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-raster%7Cext.visualEditor.viewPageTarget.icons-raster%7Cjquery.multiSuggest%7Crangy&skin=monobook&version=20121212T032708Z&*:207
---
--------------------------
**Version**: unspecified
**Severity**: normal",45017,-29,Low,True
4.4481490414786204,0.06059683675230332,4.609456449233367,-6.432951344249349,-1.7327174947432393,-4.300441605675554,0.30869979060259123,-3.7292501116998102,0.04161030084081663,4.480221204070707,1.1279468094701088,-1.0602649517581064,-2.3110959696772175,1.0786562462157043,-0.19483081886479248,-1.3333876781135638,1.0850890656535757,-0.5604245789415432,False,c1,1,"When I try to use VisualEditor with <https://en.wikipedia.org/wiki/User:Trevor_Parscal>, I get the following error in my browser console: Uncaught TypeError: Cannot read property 'typePattern' of undefined.
--------------------------
**Version**: unspecified
**Severity**: normal",45014,-29,Low,True
-0.5337284375405238,3.935658444736408,-4.231034408508428,-5.375481775782767,-3.9443690102906994,4.965108181206564,0.5802216133701652,2.4346572483056663,3.101367697185352,-0.07927379736362639,-0.3448436157871426,-1.5199209740863084,0.13362049616202043,3.6111693166811953,-1.076434473379412,-0.4177710259484153,2.6869822058892145,-1.5561772147370732,False,c1,1,"Enable VisualEditor on test client and check if the two extensions do not interfere with each other.
They should not interfere with each other except for the additional parser function(s) introduced by Wikibase client.
--------------------------
**Version**: unspecified
**Severity**: enhancement",44981,-29,Low,True
-1.7426517957009962,-3.762619984649687,-4.130959324627966,-5.36173224947973,-2.633489067071611,6.861355405949768,0.6912618973374833,3.1270169254771263,3.7153353759630754,-0.24485926725123708,-0.8475239912671779,0.6201796981821373,-0.12796332215396777,5.415072353688016,-0.5728170485170363,0.2294559943584163,2.9230899707563927,-0.2631932127950558,False,c1,1,"Enable VisualEditor on test repo and check if the two extensions do not interfere with each other.
--------------------------
**Version**: unspecified
**Severity**: enhancement",44980,-29,Low,True
-6.3236187827010735,5.952094500120975,-1.4029437925292676,-6.71413767999937,-0.9704838435008345,-2.814930520077171,0.29664206133784976,1.0644498349122937,0.820777492304972,1.0253602797065247,-0.2265592414822719,-0.3440022859033953,0.5549496380647465,3.1280638302511896,-1.0250315563522872,-0.6620210975106768,3.4899944580282396,-2.9735670797059925,False,c1,1,"Feedback is one-way, we don't need to read the reponse (and we can't, due to origin policy). So we should convert this into a regular POST without XHR so that it doesn't error.
Apparently though the current method does work for one-way (the request isn't blocked in Chrome).
--------------------------
**Version**: unspecified
**Severity**: normal",44974,-29,Low,True
-5.72041571860394,2.7950502605991296,-1.2778781683918083,-3.672297695474297,-4.152144487790702,7.2854520033052514,0.814853533319619,0.7286248849627693,2.96625509670746,0.42101854451445586,0.2022493636093281,0.8249163876471381,-0.5003365141837577,0.7284608579167999,0.500985574881196,1.5021694611777128,0.36198376496014095,-1.0724579945556436,True,c1,1,"In VisualEditor.hooks.php the function to evaluate whether or not to show the VisualEditor has ignoreHidden set true on the user preference check; this should be false in production.
--------------------------
**Version**: unspecified
**Severity**: trivial",44936,-29,Low,True
-3.667403042053166,4.5476754307038725,-1.3772234363927414,-0.05549069004552387,2.364760199427234,0.014889872544893379,-1.0808318226123603,0.18731242362950168,-1.5880777699724091,2.1679358550133507,-0.22084094336711724,0.8739038710318578,-0.5795744846153559,-0.1717347007112089,-1.0621306609942778,-0.07459253269517524,-0.4111777592060448,0.5516655856881305,False,c1,0,"On a site such as the English Wikipedia, editors often create redirects for misspelled versions of page titles so that readers can have an easier time accessing the content they're after. For example, if a reader enters ""Barrack Obama"" or ""Dave Chapelle"" or ""Steve Carrell"" into the search bar, they'll be redirected automatically to ""Barack Obama"" or ""Dave Chappelle"" or ""Steve Carell"" (respectively) automatically. This is a good thing.
However, these redirects can be problematic when editors insert this text into a page in the form of a link and don't get any feedback that the text they've entered is a misspelling (that it's likely wrong and not the text they intended to insert). In fact, the user gets the opposite feedback: they get feedback (a blue link) indicating that they've inserted an appropriate, working link.
These misspelled redirects can be tagged with templates such as ""{{R from misspelling}}"" which generally automatically categorize them.
I'm not sure what the appropriate behavior here is. I believe that continuing to allow users to insert links to misspelled words or phrases unknowingly is a bug and should be addressed somehow.
There are a few options here, but I'm curious to read what others think about this. The goal here is to reduce the number of misspelled links that are added to a page by giving the user warning or notice that they've tried to insert a misspelled link (e.g., [[Hilary Clinton]] or [[Stephen Spielberg]]).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/wiki/Wikipedia:Database_reports/Linked_misspellings
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=13595",44880,-30,Low,
-8.937358621402856,1.6778968788044253,3.734786103123028,6.82989563798461,9.502381485020805,4.885312417840887,0.009521339628618009,2.862348521003103,6.2979432840827325,-0.6591265128052779,-0.3618828615222154,1.2245544086562525,-1.4727962624907196,1.5728015785174723,0.8141399576956685,-0.4418681709313824,2.1126378080179826,0.995917688505864,False,c1,0,"Select some whitespace and open the link inspector and create the link.
The SurfaceFragment.trimRange method is not trimming the space if the range only contains space.
The correct behavior should be to trim the space then insert the location text into the document.
--------------------------
**Version**: unspecified
**Severity**: normal",44839,-30,Low,True
0.08994047002322558,-11.94181523933402,-0.4064387732114252,-3.6710507924202713,-6.704459202123264,5.87382020904777,2.035683351470241,1.2541922633992821,2.5743871888961074,2.464145552359736,3.5420481264067782,0.5299434514174532,3.906774965121496,3.121078857745415,1.7855775263751479,-1.7971286185252175,0.1680406677676225,0.40328960224767374,False,c1,0,"Similar to bug 41865
--------------------------
**Version**: unspecified
**Severity**: normal",44750,-30,Low,True
10.071660025638934,-9.492670009214047,-1.0522151283222776,4.454635562839004,-3.0388272151309628,0.5451451962463785,2.5034021378911246,-1.827749902044867,0.39598319361731005,1.3812193709763854,-2.1334503526016775,-0.8894125723416209,-1.0811944570218852,1.3173389893020477,1.1002960066179792,-0.709154603126525,0.8587247588822013,-0.3197018160117766,False,c1,0,"**Author:** `bugzilla.wikimedia.org.76374`
**Description:**
curl -I 'http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CmwExtension%7Cmediawiki.cldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cutil%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup&skin=vector&version=20121203T183954Z&*'
curl: (52) Empty reply from server
--------------------------
**Version**: wmf-deployment
**Severity**: normal",44653,-30,Low,False
5.4918051483025465,1.1036589091666045,6.345103979186742,2.1621334565246344,-0.635015794804628,2.6751243890596212,-0.19284362625353335,0.2391575382048967,0.3714486052014693,-2.089114635626876,-3.2564577830920585,-2.634218847640757,-2.0367576105516445,0.5262729357748164,-0.5461229115185091,2.3362749070612696,-1.15785491483441,-0.5153404002673974,True,c1,0,"Go to a VE wiki page directly in edit mode:
http://mediawiki.org/wiki/VisualEditor:Test?uselang=he&veaction=edit
The integration changes the URL to:
https://www.mediawiki.org/wiki/VisualEditor:Test
... instead of:
https://www.mediawiki.org/wiki/VisualEditor:Test?uselang=he
--------------------------
**Version**: unspecified
**Severity**: minor",44553,-31,Low,True
3.5043255981092982,-7.958637111072305,-5.5072532664254545,2.465583723145245,1.2630768829362895,0.5159258847257764,2.6323911536564735,0.6412420502314825,-0.46367933031647085,0.5723954134685059,-0.7335316375832637,0.6291722680726006,-0.3426685953738069,0.28892360592219557,-0.3861312331388591,0.3727860034464855,-0.48603075079790936,-0.44090659836197066,True,c1,0,"VE/MW integration fails (does not trigger but instead throws two errors, below) if an article has an '@' character in its title, though these are valid
Uncaught Error: Bad constructor arguments mediawiki.Uri.js:165
Uri mediawiki.Uri.js:165
mw.UriRelative mediawiki.Uri.js:318
(anonymous function) mediawiki.Uri.js:325
(anonymous function) mediawiki.Uri.js:328
Uncaught TypeError: undefined is not a function ve.init.mw.ViewPageTarget.js:18
VeInitMwViewPageTarget ve.init.mw.ViewPageTarget.js:18
(anonymous function) ve.init.mw.ViewPageTarget.js:1121
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://www.mediawiki.org/wiki/VisualEditor:Test@4",44306,-32,Low,True
-8.222355867780658,-2.4627332759786675,-6.48914926211696,-1.7540566136016986,5.403711604630956,-0.0006577203467810211,2.1580595371153786,-0.22083516415868565,-1.7442416656319049,-0.5240489013954308,2.0809293518582535,-3.061457604179862,1.6142258948221064,0.5958662901090737,-1.825189926943359,0.3357853594974653,-0.9053121169443649,0.9791133023126826,False,c1,0,"Currently, putting the cursor inside a link displays the inspector icon (except for bug 42276). Putting the cursor immediately after a link (i.e. between the last linked character and the first non-linked character) also displays the icon, but putting it immediately before the icon (between the last non-linked character and the first linked character) does not. I think it should.
Of course, the interesting question here is what should happen when you have two directly adjacent links and you put the cursor between them.
--------------------------
**Version**: unspecified
**Severity**: normal",44281,-32,Low,True
-2.4704136357972324,-4.120470444759626,-5.569645374334103,1.668835228125039,1.6779625441166566,-1.7999202597718869,-7.536937188887112,-0.48237104453523677,-1.147834318963734,8.226106367144116,-0.6188196414806275,-1.3072387209745158,-3.016982513613672,1.4924293825964448,-0.046512471535381295,-1.0778848091688518,2.6377723376176014,-2.929304142088873,False,c1,0,"1. Open any document
2. Blank it
3. Type some text
4. Dump the model into the console (ve.instances[0].documentModel.data)
Expected output: [ 'F', 'o', 'o', 'b', 'a', 'r' ]
Actual output: [ 'F', ['o', ve.AnnotationSet([])], ['b', ve.AnnotationSet([])] ...
The pre-annotations code is applying the empty set as a pre-annotation to every character except the first. This shouldn't happen, it should just not annotate if it's got nothing to annotate with.
--------------------------
**Version**: unspecified
**Severity**: normal",44279,-32,Low,True
-5.271472838214233,-0.7351609196386715,-4.026578921958723,-3.3788539795303185,2.119316633771028,-1.5017147596035143,-0.7269975191200873,1.895087257783302,2.6035367578315194,0.16526087872632989,-0.795669906433695,0.2587662173305061,0.4319878077551005,-0.5155147582138992,-0.7706172026264122,-0.40187483273037883,-1.070733514358878,-0.08089920284543206,False,c1,0,"Currently to view the underlying wikitext of a page that's in a namespace where VisualEditor is active, one clicks an ""edit source"" tab. However, when editing, if you want to see the underlying wikitext but not lose your changes or really just not have to reload the page, that isn't possible. It'd be awfully nice if you could toggle between wikitext and the VisualEditor interface without needing to reload the page.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57462",44141,-33,Low,
-5.747691743097329,2.712495837939745,-1.9288492731566365,3.8714319192731264,9.4130353566375,2.1308259585701244,-1.9270176554241258,2.234970050263478,-2.312733984042418,1.717016796251932,-2.884556814843669,0.7126894290142209,-0.8656411409967051,-0.02704020069251989,-0.40367397949090833,-1.4472093913622741,-2.5176060476630564,-0.4501129372970589,False,c1,0,"Currently when using the VisualEditor extension, there's a big green button that reads ""Save page"" in the top-right corner of the browsing window.
When a user clicks this button labeled ""Save page"", the page is not saved. Instead, a dialog box appears in which the user is prompted to enter an edit summary. If the user then clicks the ""Save page"" button again (a second time), the page will be saved (maybe).
I believe this is behavior is a little wrong. Historically the behavior of the ""Save page"" button has been to actually attempt to save the page to the database. This new workflow changes that behavior.
Roan suggested perhaps changing ""Save page"" to read ""Save page..."", which would give the user a clue that it's going to be a process, not an immediate action.
There's also no warning within the ""Save page"" dialog box that says that the page has not yet been saved to the database. There's no ""this is only a preview!"" text. Perhaps that's a separate bug, though.
--------------------------
**Version**: unspecified
**Severity**: enhancement",44138,-33,Low,False
-3.8793271451758793,-0.15434351203932728,0.17257630421142167,1.580053280625493,5.544292507360682,-4.106982449140671,-0.5815420784739818,-3.450373507548816,-1.9617491006700674,1.9011850939505637,-2.0815468591623296,1.1460351369080761,-0.30415745888340595,-0.17796333475335047,-0.9585673463540125,-1.3797453005738525,-2.107530064209411,0.28678074809721843,False,c1,0,"When using VisualEditor currently when creating a page, the ""Save page"" dialog box has two checkboxes below the edit summary input: ""This is a minor edit"" and ""Watch this page"".
The ""Watch this page"" checkbox is not auto-checked, even though it is (for my account) via the non-VisualEditor editor. There's a user preference (""Add pages I create and files I upload to my watchlist"") that controls whether this checkbox is checked by default when creating a page. VisualEditor currently ignores the value of this user preference. It should respect it.
--------------------------
**Version**: unspecified
**Severity**: minor",44136,-33,Low,True
3.874930480369486,-15.855629606523653,2.9415879142341943,-3.426195989012982,-0.04244087527873375,0.913437999203242,0.7830065858185087,1.4368442064718643,4.044215900020263,-1.9401802464288878,-2.9636691492465546,-0.3138165964547117,-1.9786738339888474,1.0435873546827068,-0.3799837600305169,0.4286834438629438,-0.769209489843582,-0.5943280719117778,True,c1,0,"
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66452",44115,-33,Low,
-2.462066674909948,-4.173746397063715,0.9417878247585421,-1.5316348302491845,-6.209407413321168,3.382864792129581,4.136789169518278,-0.6797737489280773,0.9659480972752281,2.6436560246140246,3.082475895708543,-1.5539286367172167,-2.105613525167124,1.8309184184435452,-0.4262228826905705,-2.3696090288207783,1.5561749073924005,0.6697048909913363,True,c1,3,"[Unused; we don't do tracking bugs, post-Phabricator transition.]
A central place for people to keep track of tracking bugs for VisualEditor. (Yay for bug meta-ness.)
--------------------------
**Version**: unspecified
**Severity**: enhancement",56363,11,Lowest,False
2.7777355508175874,0.6243597682141644,-4.454059740868269,-3.8557883438516867,4.747418806824234,0.6137757430852893,0.8041899450135261,0.9725129205698179,-1.8228147347952426,1.213065298160867,0.11348129759333281,-2.2839754687315867,0.987688881078225,-1.4114357560830624,0.16427748726146518,0.8891742603410403,2.334591967438988,1.4438495147215396,False,c1,3,"Missing scan and edit toolbar
I am posting three separate bugs and mentioning this in this first report because they are somewhat related.
The user defined edit toolbar, defined in my very simple
https://en.wikisource.org/wiki/User:Ineuw/common.js stopped functioning in this latest version of the mw software. In versions previous, it worked reliably and always, permitting me greatly increased productivity. The toolbar does show up intermittently and occasionally.
Regardless of the toolbutton definition syntax used, the same intermittent functioning is the result. The syntax is either the current definition one, or an older one:
mw.toolbar.addButton(
'',
' Æ ',
'Æ',
'',
'',
''
);
I also used the definitions without image buttons, thinking that this may be the cause, but it doesn't make a difference.
The problem is also not browser related. I tried other browsers and OS's as well:
Firefox in Windows, Xubuntu, and Apple OSX.
Safari in Windows and Apple OSX.
Google Chrome in Windows and Linux (Xubuntu).
but the intermittent behaviour is the same. . . . .
Finally, this is also true on the Commons and Wikipedia, where it's less critical because I am not so active on those wikis.
Please see attached image.
--------------------------
**Version**: master
**Severity**: normal
**Attached**: {F11589}",56308,11,Lowest,True
34.3298946852046,3.258161195010178,7.398777840937683,-2.071276323727911,1.9438119770903808,2.450880098842738,-1.6112091027699833,-0.0857990644119721,1.484197971355236,-0.36964392029532345,-0.2966586890325198,-0.6093052113977941,0.7818626872463925,-1.8368202347188847,-1.7712550564419751,0.3008474824132909,0.4213607566679616,-0.4813162585912254,False,c1,3,"The link input widget should have separate fields for the link target and the displayed text.
From various comments at T50789
> There are essentially two ways to create a link:
>
> […]
>
> #2 You click the link button first, enter the target and get out of the dialog, at which point the link text (identical to chosen link target) will be entered.
>
> […]
> With this method, the user will often have to adjust the link's text afterwards, for instance in the case of plurals or if the target article is disambiguated with parentheses. But it is not clear to the user that adjusting the link text is safe and won't create a broken link; indeed the crucial distinction between link text and link target remains obscure. (Changing a singular to a plural is especially difficult since editing links at the end is not allowed.)
>
> I have checked the workflow of entering links in LibreOffice, Gmail and Word; they are all basically the same as in the Visual Editor, with two major differences:
>
> a) the dialog popup window has a clear OK button, and [T54462]
>
> b) the dialog popup window contains separate clearly labeled boxes for the link text and the link target.
>
> I believe both of these changes make a lot of sense.
---
>>! In T50789#510194, @Thryduulf wrote:
> An English Wikipedia user comments that the current behaviour of the input widget is not intuitive at all:
>
> ""I clicked the link tool while not focused on any text, to try and add a new link. I got a largely empty box with no instructions, and the next word in the article highlighted within the box. I fiddled with it a few times, and still don't know if typing in the box A. changes the text of the link. B. allows me to select more words. C. Changes what is linked to, or D. is followed by another, nearly identical box for a secondary function""
>
> To me this is further evidence that we need two boxes: one to enter the link target and one to enter the link display text. The second box would default to the same as the link for internal links and for external links either (ideally) the page title or (less ideally but probably easier) the filename sans extension.
>
> See also T53438
---
>>! In T50789#510207, @Thryduulf wrote:
> Adam Cuerden comments again on the suggestion to have separate boxes for link target and link title:
> ""Yes [that would be better], but do make sure it's on the same page. Don't give one dialogue, then a second. Also, if one of the boxes is left blank, it should be auto-completed from the other box. ""
>
> For the second part of the comment they mean that if someone gives a link target (e.g. Fish) and doesn't specify any title, produce a link: [[Fish]]
> If someone gives a link title (e.g. Hedgehog) but doesn't specify a target, produce the link: [[Hedgehog]].
--------------------------
**See Also**: T52945",55973,10,Lowest,False
-2.2474534362708063,5.2782673585318065,1.337411529835368,1.493059221799819,-0.2308316114272952,1.7319447197475764,-2.905489085081135,-1.404393199615594,-1.7121998471345254,0.25453927520280306,2.407152333809648,-0.5900963142678898,-2.8042875081101295,1.0290416597868992,1.522640092859323,0.14172642307242464,-1.1288356143544052,0.406498081567354,True,c1,3,"<< Currently when you click on a template with the ""VTE"" (view, talk page, edit) links, Visual Editor gives you the option of adding parameters to the transclusion of the template. Most of the templates with the ""VTE"" links are navigational boxes or other transcluded items without parameters, but as the VTE links suggest, we want people to easily view the template page itself. Maybe if someone clicks on a template with VTE links in Visual Editor, rather than being given the regular option to add parameters they should instead be given a dialogue box saying something along the lines of ""This is a template that appears on many pages. Would you like to open this template's page in a new tab?"". —[[User:Arctic.gnome|Arctic Gnome]] <small>([[User talk:Arctic.gnome|talk]] • [[Special:Contributions/Arctic.gnome|contribs]])</small> 13:45, 20 August 2013 (UTC) >>
--------------------------
**Version**: unspecified
**Severity**: enhancement",55099,7,Lowest,
3.749302393572387,-15.248566553035646,3.0020700991460245,-3.2511609543014024,0.22349817359879753,0.4111902676082919,0.8701721879642088,2.453233347940972,3.110317983029436,-0.15199080548596378,-0.07186464839646867,-0.4498799024645963,0.538364915526933,-0.3989573949803926,-1.492043807595012,0.32048226926403195,-1.1343269318540032,-1.074227359580981,False,c1,3,"
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51527",54188,3,Lowest,False
9.211429469159174,-1.0067936036455638,10.18199533192838,0.012828191720039683,-3.8946016310477236,-5.44245048158608,2.277639451808855,1.7245507690592632,4.459638468307903,1.1692543919373861,1.0527964239424725,1.4094749249474863,0.5418793759208493,0.39495690757234225,-1.708414390889117,0.25983018897626575,-1.8795234813512973,-1.1801336903419979,False,c1,3,"**Author:** `jonathan_haas`
**Description:**
It's currently impossible to change table cell background VE
See for example http://de.wikipedia.org/wiki/Suriyakati-Kalender
**See also**
* Open subtasks of {T49780} ",54180,3,Lowest,
-6.661833723811252,1.9815191758460458,-2.2741342168896477,4.870934891384728,-2.6995438629855304,-2.214077037521,0.8209508412649837,0.17659462230291195,0.8366547838913907,0.0020748169510360626,0.7879507236865382,1.0468358444462356,0.9570703790792994,-2.1930054244082076,0.030904269952726438,-0.388071926583359,-1.3105567600518173,-0.08356325270559828,False,c1,3,"Links are frequently placed in edit summaries but the user is currently perversely required to revert to wikicode to insert them. The VisEd menu should be available for the edit summary and the text should be displayed as it will be seen. Wysiwyg should apply to all elements of the edit summary (eg, the recently added section title is displayed as code rather than the grey italics as it will be seen).
=== Potential use cases/impacts/hypotheses
- **[potential impact]**: if people publishing edits write more expressive edit summaries, these edit summaries will be compelling/interesting to people whose primarily relationship to Wikipedia is as as a reader
-- //See more in {T379405}
- **[potential use case]**: enable people to relate edits to the events/campaigns that inspired them to make them (T373232)
-- //Inspired @AlexHollender-WMF and @ifried...//
- **[hypothesis]** If people have an easier time doing things like mentioning other people, inserting links, and formatting text within the edit summary input, they will invest more effort into writing edit summaries.
- **[potential impact]** If people write more descriptive edit summaries, then machine learning models will become more effecting at learning from the actions volunteers are taking because these models will have to make fewer inferences/assumptions about the semantic meaning of a change/changes someone is making. //This thought is inspired by the conversation we (the Editing Team) had with @diego on 27 July 2022.//
- **[potential impact]** If people write more descriptive edit summaries, then people visiting an article's ""page history"" will have an easier time: A) understanding how the article they are interested in evolved over time and B) identifying changes they are curious to learn more about
-- this could also open up the potential for edits/diffs being presented as small, standalone pieces of information people could ""consume""
=== Related
- T123529
- T323875
- https://hashtags.wmcloud.org/",54174,3,Lowest,
-6.246471637573902,5.786079508053604,0.5617544795482736,2.735907769437001,0.7857493689527242,1.7721073779513572,1.149083404375789,0.004701189727418786,0.41246294764241576,0.24696366648522172,1.5870198685819834,3.768692160353954,1.451879594145896,-2.088706643226011,0.9796190628854546,0.7489812721879047,-0.8426758860009725,-1.4495200647262831,False,c1,3,"There are many pages for which VisualEditor is broken. In some cases, the page syntax can be changed to avoid the problem. In other cases (such as nlwp's largethumb, dewp dab pages, enwp episode lists), the design affects many pages, and the only feasible solution is to fix the parser. While we wait for fixes, the VE should be disabled on those pages known to be affected.
The set of pages to be VE-disabled could be a category, if you trust the villagers..:-)
Or a page title blacklist in MediaWiki: namespace so it is admin only
Or a page content regex blacklist in MediaWiki: namespace so it is easier to blacklist all pages which include a certain element.
**See Also**: {T55767} (also declined)",54141,3,Lowest,False
-2.409615604062407,5.36560409645956,-2.1074909807585076,-0.5026498823927342,-0.12642006939829342,0.6162886879254013,-1.5810726917423557,4.964525101426864,3.8258890657102933,-0.9422157005083207,-0.014756119553647196,0.7146663058669076,1.8377990058271152,-1.7927140319984618,-0.5511585845240647,-0.5771559629452103,-0.6827872960710989,-1.8243075925525647,False,c1,3,"The Visual Mode editor of Wikia is able to check all the available parameters automatically without the need for editors to edit the TemplateData for each template manually which is unrealistic to be done for over 505k templates on English Wikipedia.
However, Wikia's template editor has a severe flaw that it cannot handle a template to be included inside another template. The visual editor will deem the coding to be too complex and forcibly switch back to source mode editor.
--------------------------
**See Also**:
T54581 / {T191756}",54135,3,Lowest,
-8.666722691743024,4.152428284096867,-6.484768613866313,-0.8395842857767617,3.565874664092919,2.5731166351125614,-1.05618318923461,0.10281503458492947,-0.6441556038304099,0.6001389696169293,-1.8044758049132126,-1.8368731468407586,-0.5089531265586622,-0.7498587117019486,0.06924479016081975,-0.4544801815301275,-2.6111955636610205,0.9917885759201395,False,c1,3,"The editor an en.wp who signs as ""Josh, linguist"" has left the following suggestion about toolbar placement in the Visual Editor:
""I've encountered a sort of inconvenience which is the following: while editing, the toolbar occupies a significant area in the upper third visually and otherwise blocking the text, when we, at the same time, usually have an unoccupied area to the left (where the navigation column is which is often empty much below the existing items); the question is why not to devise a possibility, an option to change its place — I mean the toolbar could be opted to place it either where it's offered to be now – or, otherwise, on the left side of the pane – where it should not be blocking an essential area of the text to edit, in this case the text available without scrolling will be by, approximately (depending on your zoom), a half more than it is now.""
For RTL wikis read ""right"" instead of ""left"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",53951,3,Lowest,
-6.956714409001041,2.2925337671935786,-2.3979648508328886,2.4799052024649564,1.005301613294844,1.1171745518411285,-1.0013445386937692,3.2802447397679533,2.774667928927178,-1.641819327802681,-2.1642029594031293,0.5543339710017812,-1.341022844297763,1.3076022861211998,0.3423489725161728,-1.6888588067719508,-0.683407450133266,0.17328129263221492,False,c1,3,"one thing that makes life better with existing editor is the fact that when editing a specific section, the section name is automatically added to the edit summary. often, this ends up being the entire edit summary.
REQUESTED ACTION
1) when hitting ""save"", test to see if all the diffs are contained in a single section, and if so, add the section name to the edit summary automatically.
2) just like with existing editor, allow the user to modify or remove this part. i.e., the request is to pre-populate the summary box, not to add section name outside of summary box such that the user can't touch it.
peace.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**: T54859, T50274, T52872, T60488",53903,3,Lowest,
-2.555677222098235,8.709735896700554,1.4049000018194562,0.5151981888972432,-1.024615619859451,2.480514859772578,0.25305327802131483,-1.4017769771826885,1.9267718113846672,1.7784706104907881,1.185872887074766,1.2919390430794382,-1.232158976682559,1.2631238698877088,-0.4274178514142122,0.40483119728196726,0.7624952828249454,1.250610186915922,False,c1,3,"The basic idea is to have a clear and pleasant-to-use web-based interface for generating a MediaWiki instance manifest. The interface should allow you to tick off the extensions you want, for example, and it would automate the configuration of supporting software like Apache and memcached. There's an attractive example of such an interface at <https://puphpet.com/>.
MediaWiki-Vagrant already implements the bulk of the work in that it provides a set of parametrized, MediaWiki-oriented Puppet modules and resource types. In plain English: MediaWiki-Vagrant can take a configuration file that says ""give me a MediaWiki instance with Scribunto and VisualEditor that is set up for development work"" and configure a machine to match these specifications.
A number of cloud computing platforms provide hooks for uploading Puppet code to automate the creation and customization of servers. Some are event implemented as Vagrant 'providers', which means that you can run 'vagrant up' and Vagrant will create a cloud instance rather than a VirtualBox VM. Examples include vagrant-rackspace for Rackspace Cloud (<https://github.com/mitchellh/vagrant-rackspace>) and vagrant-aws (<https://github.com/mitchellh/vagrant-aws>) for Amazon AWS. A vagrant-openstack provider (<https://github.com/aodn/vagrant-openstack>) also exists; I don't know how much work it would take to make it work with Labs.
The major work-item would be to build the web interface (or adapting the source code of <https://puphpet.com/> or some other project -- there are several), ideally as a MediaWiki extension so that we can offer the ability to provision a virtual server (either local or cloud-based) right on MediaWiki.org.
I think that this could considerably broaden the appeal of MediaWiki to a new generation of internet users. The success of Wikia shows that there exists considerable demand for point-and-click wiki creation. It could also help drive third-party usage of VisualEditor / parsoid, if it is true that adoption is held back by anxiety over having to configure and maintain an additional software component.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53782,2,Lowest,
-11.548662580236094,5.042898143805228,-4.595923894695698,-1.4083062860969142,5.575116408002415,0.7075414546834504,0.1831043104471437,-2.833505853262509,1.0085167873881513,0.7968496130380096,1.4515029486451119,-2.5709319231896908,0.9002099783229824,-2.5056590406143133,1.8137183747501888,1.797495825799662,-1.9495762941670547,1.1005014169259082,False,c1,3,"The ""clear formatting"" button returns bold and italic text to its plain state, as expected. However it also removes any links in the selection, which is not expected, rather there should be a separate ""unlink"" button to do this job - conceptually I regard a link as an attribute not as formatting.
For example selecting a bolded sentence with an italicised title and a linked word in it. I clicked the clear formatting intending to clear the bold and italic, which it did but it also removed the link. Similarly if using it to remove a link it also removes bold/italic which is unlikely to be the intention.",53757,2,Lowest,False
-10.728594911249777,7.448256179203902,0.7595094822900315,2.4394631738901906,0.9235139575075633,0.5558250244197773,1.7514316207896385,0.8806453126270452,0.8356640205063095,1.2539259315305467,1.5689467762253,-2.5457014532786646,1.0620139917305584,0.4022307411556971,0.18551370010913448,0.83560539170685,-0.1413246035163387,-0.19682965194692437,False,c1,3,"One of the major advances in wiki editing in the last few years has been support for the short template-based referencing systems like SFN. I've made it a basic rule to use SFN if a reference is used more than twice within the article, and an inline only in the rare case where it is used once or twice. I realize my editing patterns are not normal, but I think support for these templated refs would improve the editor greatly.
Perhaps a ""toolbar-like"" editor to one side of the main editor could list of global references created so far, and allow the user to drag a handle from them into the article to place the ref in the body.
Even better, perhaps the use could drag URLs or text into the bar to create semi-filled out master refs.
--------------------------
**Version**: unspecified
**Severity**: enhancement",53522,2,Lowest,False
-3.495117249879563,2.8055189501603195,0.11504839628491936,2.2398690917671313,-5.668816499834218,0.9499244360298078,0.45304160944920646,3.3598246495834774,3.4533427575075706,0.004380051081046332,0.30830075769844045,0.7901469024648613,0.5879397840375917,-0.01782833180905108,-0.7342338733661826,0.5243544538961246,0.5329964358377062,-0.21930760869761312,False,c1,3,"Hi,
a: Currently language list displayed below MediaWiki:Visualeditor-dialog-meta-languages-readonlynote/mr does not open the respective language wiki but when that is possible along with that respective language item ULS should offer option to open up the respective language wiki with related display and/or input .May be this shall need to mingle three extensions VE,wikidata,ULS and also
b When in menubar languages displayed by wikidata if curser hover over any wiki language name options as requested in 4a should display and available. (Whether this needs to split as a separate bug ?)
*To understand further the need for above request,please do refer to survey
data and analysis provided at
http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#feature_to_make_content_language_input__default_28864
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51431",53355,2,Lowest,
-6.68020135826995,7.910453863047806,3.3586981037583854,2.2618027445991085,-3.639600775397459,-1.8788275628927564,1.5915294262869173,2.135046819038881,-0.6851996273348175,-0.8061518440757598,-0.27973317832513134,3.4845294744156607,1.2743968511265824,-2.922719594302782,3.2359149983777096,-0.30345928389078447,0.0366914924284627,-1.9230599072305574,False,c1,3,"The ability to sign posts is useful outside of talk name spaces. For instance http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback is in project space. While that might one day be in flow there are many other project space items where its useful to be able to sign. For instance lists of project members. Some uses have guest books in the User: space which can be signed.
You can't even enter them manually due to T51820.
A button to insert this would be good, possibly done at the same time as bug 38029 which would insert symbols.
This was discussed at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Let_me_sign.21
----
VisualEditor now allows you to insert signatures on pages that are in `$wgExtraSignatureNamespaces` (and any talk pages).
This was previously implemented as a user script / gadget is available at https://meta.wikimedia.org/wiki/User:Matma_Rex/visualeditor-signature.js.",53154,1,Lowest,False
-6.035202466369315,-1.0907083651458809,-4.949875311731226,-2.5987501748212614,3.824528016945133,-6.370798160626869,3.109011103346634,-0.6394407887500247,-0.1301492435169564,-0.32074896870290637,-0.7439639519394468,2.7045886493875777,-0.6161610294695805,-0.8737227150506488,0.8041538967235207,0.09044629992162612,-1.1931174348095075,-0.6201808932654247,False,c1,3,"**Author:** `mcdevitd`
**Description:**
""Preformatted"" is HTML jargon which most of VisualEditor's target users will not understand, and it actually produces an effect (text with less formatting) which is unexpected if you don't know what it means beforehand. It should either be given a plain-language name so that people will expect the behavior, or removed.
I actually don't understand why this style effect is in the header-level pull-down when it is not a header-level. My preference is to remove it, since it is uncommon and mostly adding noise, but it should be renamed if kept.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52918,1,Lowest,
-7.38714222681403,-0.700084468137705,-7.9216065327086,-6.823181719208228,0.9879602208914964,-4.2543894884902365,-0.9995917121278364,0.4251725452689121,2.4146113334323926,-1.3976675974572332,0.44981605217191234,1.3483347986849405,1.5677807566080788,-0.686317554189678,1.6306825955866318,0.8716903871894784,-0.06380552857166033,-0.39636964137365993,False,c1,3,"I think we can (almost) remove Opera from the blacklist now, see blocking bug 36000. Opera < 12 should still probably be blacklisted, though, and < 10 should be blacklisted for sure (there's a bunch of people who insist that 9.64 was the ultimate version ever and stick to it).
It'd be cool if it could be added to the whitelist as well, but I guess that would be a promise to support it and you guys probably don't want to promise that ;)
--------------------------
**Version**: unspecified
**Severity**: normal",52813,0,Lowest,True
1.7170895987137222,-13.276638429873532,-1.9519821269447917,-6.528304868297948,-5.778259309298075,7.184661903298989,0.8530034303494949,-2.1147481425914902,-0.14982742803317775,-2.4301823538516305,-4.997091304373959,-1.5657539649058383,-3.533913136446853,1.4786168474814145,-0.004562668881651355,-1.9640922698303842,-0.3819650762543778,-0.3730031269270049,False,c1,3,"Because.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52804,0,Lowest,False
-9.237172966622387,10.051686483653935,-0.1530704699281582,1.734309848653636,3.843983422963228,2.2831236993205444,1.5534174462253443,-0.31407650403584597,-0.30834540930465415,-0.08475665019300571,2.1951272910689164,0.9228637273405764,-0.6404655298747581,0.9214093204846234,-0.26491661203196415,-0.130811249312978,0.48281208807711984,-0.5720042170134023,False,c1,3,"When you add a new citation in VE, templates which wrap the `<references />` tag do not update to display it until the page is saved. Examples include [[https://en.wikipedia.org/wiki/Template:Reflist|`{{reflist}}`]] on the English Wikipedia and [[https://es.wikipedia.org/wiki/Plantilla:Listaref|`{{listaref}}`]] on the Spanish Wikipedia. This bug doesn't block any of the core citation workflows (creating, editing, and reusing) since those are accessed from the toolbar and the in-text reference numbers, but it's still very annoying.
However, it remains unfixed because it's an //extraordinarily// hard technical challenge, verging on impossible given the current architecture of Mediawiki. No one has any idea what a workable solution would look like. Just to give one facet of the problem, you could implement this in VE right now //if// you completely re-parsed the entire page every time the user touched a template or a reference—which would be a //horrible// user experience and place //insane// loads on the servers. It's possible that in the future, someone will think up a brilliant solution that avoids all these huge issues, so this task remains open.
In the meantime, the planned solution is to update the `<references />` tag, which does update properly during editing, to support multiple columns and alternative list styles so they have all the functionality of these templates (T53260). When that task has been completed, communities will be able to replace the templates with references tags at whatever pace and with whatever tools they prefer (if there's demand for it, it would probably be possible to do a more immediate, bot-driven changeover).
",52769,0,Lowest,False
-2.0649968717510907,-2.3429399889535354,-2.264184314663151,-5.089588027437335,0.4513622944117568,2.2640121561901045,-0.47126606510475444,0.6955722675287909,-0.5195676268888826,-1.2549481603688464,-0.41313492540463237,1.7876593912145335,-0.5334358043850074,0.7174483866835226,-1.7430191526801782,-0.5561069497157964,-0.9389867677738931,-0.6685307811201282,False,c1,3,"A user has requested a tool to alter the case of text that has been typed. Marking as lowest priority, since we've made clear it's not something anyone is likely to work on any time soon.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T55210}
{T52678}
{T55495}
{T52452}",52745,0,Lowest,
3.3833561236282867,-6.502856700598685,-1.2648042940515207,1.3515149773324384,-0.47129998592227196,-2.710064258423851,-0.6363579946994413,0.9649404254465254,-0.4494589737545121,-1.9466376418440623,0.40259335109934824,-1.6247244023736656,0.856957019248604,-1.9164356851527278,-1.222262023451667,-0.7937728475133512,-0.5702161618146726,-0.3544537812712787,False,c1,3,"Occasionally wiki links are being mangled adding ./ to the start and replacing spaces with underscores. For example replacing [[specific name (zoology)|specific epithet]] with [[./Specific_name_(zoology)|specific epithet]]. I've only noticed it with piped links.
Examples
https://en.wikipedia.org/w/index.php?title=Austropotamobius_pallipes&curid=3945333&diff=562783871&oldid=545518009
https://en.wikipedia.org/w/index.php?title=Ron_Davies_(songwriter)&curid=31118393&diff=562723238&oldid=553701771
https://en.wikipedia.org/w/index.php?title=Sibling_relationship&curid=22409572&diff=562636237&oldid=561958868
https://en.wikipedia.org/w/index.php?title=Double_Rainbow_(viral_video)&curid=28129724&diff=562626607&oldid=560477885
https://en.wikipedia.org/w/index.php?title=Roger_Mompesson&curid=39389398&diff=562625481&oldid=560045122 (also changed a category link)
possibly related to bug 50428
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50539
https://bugzilla.wikimedia.org/show_bug.cgi?id=48769",52720,0,Lowest,False
3.04065802389958,5.486326599627365,2.855472364038846,1.144095208464917,-6.174020549305549,0.8967483957240348,3.7176244807581,7.052200174031082,-5.339229065492509,10.256842338120817,2.5447397107312377,-2.793045181504584,1.2706215979645537,-3.3378478823641196,2.8749087826835114,2.1599374791137755,-3.710474147452948,0.14305117155058134,False,c1,3,"Enhancement request for more informative error messages - as simple as ""Syntax error in JSON on line foo."" would be better than the current message, which is just ""Syntax error in JSON.""
| {F34099979} | {F34099994}",52511,0,Lowest,
-9.159573211567956,10.007920990572575,3.610449348759012,5.111404521183931,0.8656412080823863,1.364682523610672,-0.992003932656254,2.2332601770599494,1.1518583994992622,0.43667808565881927,-2.1847688190517487,-1.33659346188125,-0.8515498075827717,-0.8443422204792483,0.942096238198797,0.28403451573562105,-0.23429654505557185,-1.1106684349298441,False,c1,2,"Until a recent MediaWiki change the default behavior of edit section links was to float to the far side of the heading (right on LTR Wikis, assume this case in the following).
This was changed recently but almost all Wikis provide Gadgets to restore the old behavior (see http://en.wikipedia.org/wiki/MediaWiki:Gadget-righteditlinks.css or http://de.wikipedia.org/wiki/MediaWiki:Gadget-editsection-align-end.css for examples)
The problem is, that the VisualEditor's fly-out-links reserve space to the right for the ""edit source"" link. Therefore when aligning the links right they actually appear with a large distance to the page-margin. The fly-outs should therefore be modified to not reserve any space so the ""edit"" link is correctly aligned right.
To prevent the fly-outs to shift the whole ""edit"" link left as soon as they become visible they could be changed to fly-out to the left in this case or to the bottom.
--------------------------
**Version**: unspecified
**Severity**: enhancement",52405,-1,Lowest,False
-3.199095221347515,-0.5483016695464578,1.944547522205628,1.8849993138134966,-0.17102347952667962,2.882875406191628,-2.177716138684019,-2.043668988789656,-1.2601718992875295,-1.874520122840233,3.3143867867235124,-0.6464813084453858,-0.9719232040865391,0.24687201759120203,0.8579546017360382,-1.2551920827499374,-0.43328815500294726,-0.560626081214882,False,c1,2,"It has been mentioned in some places[1][2] that the JSON syntax might be a problem for typical (non-technical) users, so I suggest creating a plugin for editing the content of the <templatedata> tags.
[1] https://commons.wikimedia.org/wiki/Template_talk:Information#Adding_TemplateData_information
[2] https://pt.wikipedia.org/wiki/WP:Café_dos_programadores#Mais_uma_novidade:_TemplateData
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51734",52169,-1,Lowest,False
-7.0107928004988125,-0.652910946833634,3.102546776862436,4.937433328108327,-7.061320798812284,7.242101345422898,2.3459021763150885,-2.0191131223487835,-1.052691293026235,-0.2053928807378096,-0.3373009739670363,-4.0235083527174496,0.3291096023685727,2.2399704445821564,1.4724486342229648,0.7876755385672101,0.01780836597263291,-0.7232371816226251,True,c1,2,"A retread of bug 42847 for issues in the run-up to wider deployment.
--------------------------
**Version**: unspecified
**Severity**: normal",52085,-1,Lowest,False
-3.997069471584393,16.346891911425754,0.4752508602186616,-4.18629253781315,-5.586452330120833,-0.32643215517300295,1.9661607440733624,4.8960142290460835,-4.80335530277109,-2.034922282988652,-2.0395329766901362,3.8742657663785875,0.9126313352522986,0.06975483812676853,3.4532080333289814,-2.40153978168356,1.1584078515590666,-2.152323641367276,True,c1,2,"One of our long-term objectives is for VisualEditor to be enabled by default on all (public) Wikimedia wikis; this is a tracker for that ambition.
As of August 2016, it isn't likely to be completed anytime soon, because some projects differ substantially from the Wikipedia use case for which VE has been primarily designed. For example, Wiktionary pages tend to be composed almost entirely of templates.",52000,-2,Lowest,
5.125554038897544,-6.426815063140318,14.089488616459253,-6.4965700937232205,-15.229040564846281,7.877744757457035,-7.8545970790073305,0.6793392987002143,-7.692559537094384,-2.220243050774556,18.83774528053014,-2.8083573281457683,-18.342271565840065,4.611700050571537,4.375503532135421,-3.504489120426977,2.9924975021732374,1.1403732525862444,True,c1,2,Current deployments listed at [[https://www.mediawiki.org/wiki/VisualEditor/Rollouts|mw:VisualEditor/Rollouts]].,51999,-2,Lowest,
-5.810093180412584,1.5644977563017939,2.2589320972475555,3.799674861480039,0.776515784266409,-1.220334576215243,0.9513443861189428,2.1544137262997336,2.5645359136723256,1.794829748098171,3.3304163500006507,1.08994378986352,1.4466505848124127,-1.0385083625157217,-0.7378686167456463,-0.8891885929101786,1.1831967523884874,1.4939431392771614,False,c1,2,"###Problem
There are various workflows where a user wants to both interact with (or at least see) a page's content, and also interact with a potentially complicated form/process, which may have many controls/inputs.
Some VisualEditor examples:
- Adding/editing categories (T51969#548266)
- Adding/editing a template with many parameters
Some non-VE examples:
- Rater dialog (T51969#2847958)
- [[https://en.wikipedia.org/wiki/Wikipedia:Twinkle|Twinkle]] dialogs ([[https://github.com/azatoth/twinkle/issues/414]])
###Feature request
Dialogs that have no need to be modal (intended to interrupt the primary workflow, and requiring some action before you can get back to the primary workflow) should be draggable.
Gadget/script/other developers using OOUI should have a simple way to enable this feature, e.g. a config setting that can be set to `true` to allow dragging.
Some specific workflows may have viable alternatives to dialogs, e.g. {T52239}, but that doesn't solve the general problem for more complicated dialog-based workflows.
###Initial task description
Quoth requester: If I can't read the article, because the ""page settings"" box is large and un-draggable and hides all the article, how can I see what defaultsort or categories I want to add (especially as for defaultsort I probably want to copy and paste all or part of the article title).
",51969,-2,Lowest,
-2.4425524336802544,-1.4379463877149945,6.396531396022365,8.029961283693824,0.070111084572967,-2.2681308810648675,2.7035132505430726,2.325402173907107,1.6599750478648212,0.21824241192181315,0.2931515006197465,-1.478030567394077,0.5795654668629391,-2.424236154989402,-0.010199172929135969,-0.5190759795354286,-1.6742194153536443,1.2584113021621197,False,c1,2,"When in the template editing dialog, a link going to the [template:name] page, would be really helpful for:
* Reading detailed documentation
* Easy access to (edit or examine) template source code
**See Also**:
* {T52354}
* {T52656}
* {T53311}",51772,-2,Lowest,False
-4.9569976974862024,-1.3104337009595248,-6.107189243471934,-2.6839552970882314,2.28506134718677,-2.2886871616201523,-1.6168450465232,1.2500162820295215,-0.37749522224888354,2.669777854618739,0.6660197832756798,-1.229207583220812,0.362414009985669,-1.2310233312000416,0.05172707342988225,-0.5621923790694646,0.5241458115781426,0.40527368645551465,False,c1,2,"This is more of a tracking bug than anything else, but it should be something people are aware of and something that's formally logged; the VisualEditor is very slow on large articles, to the point where it causes confusing output.
Using the example of https://en.wikipedia.org/wiki/OpenOffice - I edited this and it took a good 20 seconds just to render 'review changes', and another 20 to save. David Gerard did the same and the server popped up ""Error saving data to server: timeout."" with both 'review' and 'save'. Despite this, it saved anyway.
Obviously as a long-term thing: we shouldn't have an editor so slow that someone in an industrialised, Western nation (i.e. the UK) can't make things work.[1] As a short-term thing, we shouldn't be informing users ""something has gone terribly, terribly wrong, abort!"" when it has actually saved.
[1] It's David Gerard, he's not going to be using dial-up.
--------------------------
**Version**: unspecified
**Severity**: normal",51685,-2,Lowest,False
23.736089251755956,-0.9425857155049862,9.157768074475502,-6.208476311760408,-3.828959685849314,-0.2289853676328828,-6.70654010161495,1.6329079067544505,-0.32610791940766304,-3.7917140899080666,1.551560787790717,-0.976813243022265,-1.9245100120256105,1.2572634299863026,-0.27074565827475183,-0.5773506964979255,-0.049454154021676855,-0.5283107874625885,True,c1,2,"From [[https://phabricator.wikimedia.org/T50429#518092|a comment]] on T50429.
>It would be wonderful if the ""edit source"" links or icons for sections also showed up inside the Visual Editor. The Visual Editor could treat ""edit source"" links or icons as uneditable links. But the link would still work. So people could click ""edit source"" links or icons to open source editing of a section.
>
> People could go to source mode editing at anytime, even from inside the VisualEditor. That would be so convenient and so useful. Later on, this functionality could be extended to anything the VisualEditor can't edit. People could click on templates, tables, etc. inside the VisualEditor and go directly to source mode editing of that section. Or they could right-click templates, tables, etc. to go to a new tab in source mode for that section.
**See also:**
T50429
T51664
T49779",51665,-2,Lowest,
-0.9163148143550397,-3.0600222389976537,3.2318322662407226,3.239506192449995,-1.5620443151215015,1.4153791808497809,-1.3568879444510964,0.7412720824590769,1.372482552995041,-0.8242830592498938,-3.494657556087925,-1.9846097998992396,-1.4464268377790388,1.717157137547523,2.6284464512581627,-1.3590961176187384,-0.5083462181491706,0.029564067205181344,True,c1,2,"[From bug 48429 comment 20.]
Switching to ""edit source"" tab when VE was triggered via a section-edit link should enter the wikitext editor for that section, rather than the entire page.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48429
https://bugzilla.wikimedia.org/show_bug.cgi?id=49665",51664,-2,Lowest,True
-1.4965304244774742,5.613045669303336,-2.349434754871382,-3.5574173363484176,-1.7825452072081014,-4.554830573174256,2.146019928233552,3.054052611682092,-1.6650497202679597,-1.4190674787970008,-3.089478987167418,-0.21372243218082698,-3.2357037603103027,0.8337154560523583,0.5913831634710478,-0.056428405299196405,0.39648335454770733,-1.8089816014699198,True,c1,1,"These links being red at all come about because content of templates is rendered by the PHP parser, which sets class=""new"" (Parsoid itself doesn't hint about target colour yet). However, because dialogs are implemented as <iframe>s, we can't inherit MW's CSS for the body element, so they appear differently.
--------------------------
**Version**: unspecified
**Severity**: minor",50984,-5,Lowest,False
-3.3996156613488324,-2.8720698775176423,-0.23783375428209652,3.0468739890124894,2.5186023470996073,3.6376041914335806,-1.4443377415480283,0.14987715538419688,3.182437453664992,-2.601503108682333,-2.7317247858182983,-0.2328672035103302,-1.2268369306069822,-0.18839235268478483,-0.6377496224492161,4.686000188146716,2.0844842764445444,1.8306134719933758,True,c1,1,"There's a search-and-replace tool in the wikiEditor which some users might miss and would like in VisualEditor somehow.
--------------------------
**Version**: unspecified
**Severity**: enhancement",50368,-8,Lowest,False
-5.0666093926237235,-2.9956268108196547,3.4339471845392993,2.8903517552156512,-1.3221248325274342,1.5195935083115881,2.863744276952601,1.4100016153904753,-1.8141429199620824,-0.7990417859296324,-3.341564612542487,-1.229550619936189,-2.4669260028511513,0.19703218342499262,-0.08057706688122312,-1.4347604261587572,3.348908093570026,1.990176879514913,False,c1,1,"The difference between editing and reading mode isn't obvious enough for the user.
(reported at http://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/Alpha2013-04#Unterschied_Bearbeitungsfenster_und_gespeicherter_Artikel)
--------------------------
**Version**: unspecified
**Severity**: enhancement",50008,-9,Lowest,
-5.118270287322918,-2.5565051130791616,-3.8351217336247707,-8.209050749219873,2.4305774882153894,-2.4705776133730377,1.5274890819263227,-2.425100429196522,-0.38623631195070174,-0.7739581103137976,-1.6246295834552393,0.46980969789736715,-1.711468977421303,1.3982971945577995,-1.3291380476509813,-1.4765925092247265,-0.05383516039006131,1.6950831574944092,False,c1,1,"The link inspector doesn't open. Clicking the little button causes it to animate as if it was opening, then disappear completely.
I'm investigating.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49794,-10,Lowest,True
-3.574904690839021,-0.007436767114180398,-4.241095573777063,-5.788704924762691,-2.76741664488809,4.086475887103275,-1.2390497969882546,-0.6142695776473431,-0.7884831509514381,-0.5601957942888252,-0.5004964990192162,1.5222523021783247,1.165702276382412,-0.07366738501849301,-3.0605751819753704,-2.006367050443065,-0.4984797590531559,1.0373133898113795,False,c1,1,"Something causes ve.ce.SurfaceObserver.prototype.stop() to be called without a subsequent call to ve.ce.SurfaceObserver.prototype.start().
Apparently happens after clicking on a link. I'm investigating.
--------------------------
**Version**: unspecified
**Severity**: normal",49793,-10,Lowest,True
-4.570255783930244,-0.911485089364982,-5.2697430256553215,-5.048632768868547,1.4793606009652898,-1.5716855827707683,0.49790966993623353,3.3610076348539866,-1.1523130539792852,-0.1511938714755976,-1.4499228524246939,-0.5691510444841844,0.23829720032039514,0.5543048834274025,-2.3979746015886096,-1.5684804533924297,0.15081815401226306,0.7332391578000375,False,c1,1,"ve.ce.Surface.getSelectionRect() throws errors in Opera. I think this is the root cause of bug 37861 and likely various other issues.
It seems that rangySel.get{Start,End}DocumentPos consistently fails in Opera, because nativeRange.getClientRects() inside of the private createClientBoundaryPosGetter() function returns an empty collection. This causes the ""Cannot get position for range ..."" error to be thrown.
I'm still investigating the why, I'm just putting this here. Changing getSelectionRect() to just always return some static value seems to work (or at least not fail miserably anymore).
--------------------------
**Version**: unspecified
**Severity**: normal",49772,-10,Lowest,True
-3.7390684678618027,-0.77604524074561,1.3335208946336827,7.900650330935838,2.179750465503936,1.5800174221030152,0.7871486816897573,-0.8644281670684769,3.563161425407123,-0.5165717349297241,1.8763246868581303,-1.0302842555766083,-1.1606438492389906,-0.10964104359786475,-0.6119982838457068,-0.7774186663807934,-1.5147027483019855,2.3234751856811844,False,c1,1,"**Author:** `suitongbowgn`
**Description:**
Feature request:
A feature that supports insertion and simple editing of source code snippets in a general article. It may include a simple grammar checking mechanism which checks some fundamental grammatical errors such as having a { without closing it, having a () with a trailing period and nothing else, having solely a pair of brackets, etc.; an indentation correction tool which will perform indentation formatting on the codes; a beautify code tool which will reorganize code formatting, including indentation to make the code more reader-friendly in format.
Features:
* Insert or edit a code block.
* Basic IDE features (perhaps re-use WikiEditor/CodeEditor)
* Syntax validation (matching quotes/parenthesis/braces etc.)
* Follow indentation level when breaking lines.
* Live grammar highlighting.",49742,-10,Lowest,False
-6.015816688355301,8.088546674405123,1.917274840491725,1.3516245051131475,-2.0542095075687223,-1.9073838678316983,1.2203244382779381,-1.540205725480845,-1.4510159843231183,2.573257030276463,1.777293747479645,-0.5801169287962226,0.06394475410375922,-0.075566779862001,1.359964628775237,-0.47562006907758214,0.12612423169278264,1.209104083513339,False,c1,1,"Let's crush the [categorisation backlog](https://commons.wikimedia.org/wiki/User:Multichill/Categorization_stats) once and for all!
some categorization could be automated already.
Searching for pictures based on meta-data is called ""Concept Based Image Retrieval"", searching based on the machine vision recognized content of the image is called ""Content Based Image Retrieval"".
What I understood of Lars' request, is an automated way of finding the ""superfluous"" concepts or meta-data for pictures based on their content. Of course recognizing an images content is very hard (and subjective), but I think it would be possible for many of these ""superfluous"" categories, such as ""winter landscape"", ""summer beach"" and perhaps also ""red flowers"" and ""bicycle"".
There exist today many open source ""Content Based Image Retrieval"" systems, that I understand basically works in the way that you give them a picture, and they find you the ""matching"" pictures accompanied with a score. Now suppose we show a picture with known content (pictures from Commons with good meta-data), then we could to a degree of trust find pictures with overlapping categories. I am not sure whether this kind of automated reverse meta-data labelling should be done for only one category per time, or if some kind of ""category bundles"" work better. Probably adjectives and items should be compounded (eg ""red flowers"").
Relevant articles and links from Wikipedia:
# [w:Image_retrieval](https://en.wikipedia.org/wiki/Image_retrieval)
# [w:Content-based_image_retrieval](https://en.wikipedia.org/wiki/Content-based_image_retrieval)
# [w:List_of_CBIR_engines#CBIR_research_projects.2Fdemos.2Fopen_source_projects](https://en.wikipedia.org/wiki/List_of_CBIR_engines#CBIR_research_projects.2Fdemos.2Fopen_source_projects)
Some demo links bawolff found:
# [http://demo-itec.uni-klu.ac.at/liredemo/](http://demo-itec.uni-klu.ac.at/liredemo/ ) (Lire might even be integrated with CirrusSearch because it's based on Lucene)
# [http://image.mdx.ac.uk/time/demo.php](http://image.mdx.ac.uk/time/demo.php)
# [http://mi-file.isti.cnr.it:8765/CophirSearch/](http://mi-file.isti.cnr.it:8765/CophirSearch/)
# [http://orpheus.ee.duth.gr/anaktisi/](http://orpheus.ee.duth.gr/anaktisi/) (not free)
# [https://youtube.com/2eaGwk4Xhks](https://youtube.com/2eaGwk4Xhks)
- Skills: image recognition/analysis, possibly Natural language processing; language depending on implementation, e.g. python for a [PWB tool](https://www.mediawiki.org/wiki/Manual:Pywikibot), JavaScript and PHP for a MediaWiki extension, JavaScript for a [tool](https://www.mediawiki.org/wiki/Tool_Labs) similar to the [Wikidata Game](http://magnusmanske.de/wordpress/?p=203).
- Possible mentors: Kristian Kankainen (Keeleleek); WereSpielChequers?
- Additional info: ""I like the idea of automating categorisation, but I think we are a long way from being able to do much of it. So this would be a big longterm project. One of my concerns is that we are a global site, and we are trying to collect the most diverse set of images that anyone has ever assembled. Image recognition is a good way of saying that we now have another twenty images of this person, but it could be confused when we get our first images of one of the fox subspecies that we don't yet have a picture of. Or rather it would struggle to differentiate the rare and the unique from their more common cousins. There are also some spooky implications for privacy re image recognition and our pictures of people, aside from the obvious things like identifying demonstrators in a crowd or linking a series of shots of one person in such a way as to identify that this photograph of a face belongs to the same person as this photo of pubic hair because the hand is identical; We have had some dodgy things happening on Wikipedia with people wanting to categorise people ethnically and I worry that someone might use a tool such as this to try and semi accurately categorise people as say Jewish. Another major route for improved categorisation is geodata, and I think this could be a less contentious route. Not that everything has geodata, but if things have it could be a neat way to categorise a lot of images, especially if we can get boundary data so we can categorise images as being shot from within a set of boundaries rather than centroid data with all its problems that the parts of one place maybe closer to the centre of an adjacent place than the centre of the area they belong to. WereSpielChequers (talk) 09:58, 20 June 2014 (UTC)""
----
Proposed in #community-wishlist-survey-2016. Received 33 support votes, and ranked #45 out of 265 proposals. [[ https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Commons#CW2016-R045 | View complete proposal with discussion and votes here. ]]",49492,-10,Lowest,
-3.959531943741206,-5.307100438989721,-7.042799160935285,-2.9936468770046765,1.644464290460144,2.467027579935057,-0.6262784452844503,2.124515848935994,5.887468635031418,-0.8441450917672384,-0.16971039135762256,0.5894490661657381,1.1775420935056462,-0.15718119312659695,2.16519526520793,1.699445844486165,1.738377995830872,3.82797431257152,False,c1,1,"The job will vote -1. But only in gate-and-submit, when working on it the tests should pass (or have this one be non-voting).
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",48860,-13,Lowest,False
-0.4131158360987808,5.495606992659187,1.2009936637316123,1.7336053342659663,1.8785708193815105,5.77058717060779,-0.19845455093189202,-0.5124446094640791,-2.1311808358544004,-2.685788635863973,-2.471142104376378,-0.22951768503607195,-2.531232268912513,0.013262787607394522,0.3565458347814383,-0.32767708090147074,0.7084431565088722,-1.679855923923424,True,c1,1,"This is a tracking bug for the creation of VisualEditor plugin editors, for each of which the primary bug should live in that product/component instead (where they're about an existing Extension etc.).
This task has been replaced by #VisualEditor-MediaWiki-Plugins
--------------------------
**Version**: unspecified
**Severity**: enhancement",48803,-13,Lowest,False
4.259185588657008,3.7827339978739474,5.610302937897522,-3.038617336733706,5.9735212330358465,-0.9990992400803892,-0.23045557485882373,3.1996407747163595,-3.253525700801098,-2.7201185905470378,-1.9452033914994376,3.2943636055198366,0.4522515147946651,-1.9709600700195598,-0.8817452054079551,1.2092944635178875,-2.77514409876739,-2.81451375442965,False,c1,1,"When you are editing an article the language links from Wikidata are not shown in the sidebar. Local links are shown.
(Reported at https://en.wikipedia.org/wiki/Wikipedia_talk:Wikidata/Archive_1#No_interwiki_links_when_you_are_in_edit_mode%3F)
**See Also**:
{T48488}
{T63768}",47687,-17,Lowest,False
-3.5427239992667037,4.978413595585643,-0.16636335259942925,0.6632445757509065,2.283111977186504,3.2473918106932302,0.031142427956503127,-0.07229336256329,0.3181506290101723,0.738518999773893,-0.26170573535124886,-0.3378654142514843,-0.9325982278747462,0.38697342418617175,0.13909355184987238,1.159558962124935,-0.9697792814870974,0.06017200923383714,False,c1,1,"Perhaps might be nice in MediaWiki core, but would definitely be nice as at least a MediaWiki extension, we should implement a ""zen mode"" capability from ?action=edit.
GitHub and it seems like the Cloud9 IDE both have this mode. It's demonstrated here: <https://docs.c9.io/zen_mode.html>.
In short, in the case of GitHub, it appears to be a bit of JavaScript that adds a ""zen mode"" button to the UI. When the user clicks this button, the non-essential page elements are hidden from the page, allowing the user to focus on the textarea (or other central input area) alone. Basically it reduces the amount of noise on the page in order to increase the signal.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14501",47300,-19,Lowest,
10.943789795280535,-3.6412231143530693,-0.47608393642326696,-1.292115687003352,5.074626971872833,-1.3289608630453675,-2.660926520103114,1.2570576070254904,1.5245004468129382,4.596214760710781,-4.489122140540923,0.040988116515221495,-2.4422889156376453,2.8231689835942415,-0.3131848456930699,1.1332500268732224,2.1429041641881064,1.7113759919597287,False,c1,1,"**Author:** `Coiby.Xu`
**Description:**
I try a clean install of MW 1.20.2 and also install VE and Parsoid extension. When click ""VisualEditor"" button, the VE doesn't appear and there's a js error: ""Uncaught TypeError: Cannot read property 'error' of null"".
--------------------------
**Version**: unspecified
**Severity**: enhancement",45898,-25,Lowest,False
-0.33527242634795185,-12.732754582326672,1.8004117513840647,4.140909146483448,-3.0901273631043873,-1.6792924515007073,-0.7017166563344297,-0.6903878735521665,-2.206331619796594,-2.741481225790792,2.4623587557700275,1.742590643418669,-4.1505003702291665,-1.314675507171565,0.3515333725356591,1.7306680647359534,0.43189580409379524,0.07765634934858467,False,c1,1,"<hiero>....</hiero> is unparsed but shown as plain wikitext:
https://en.wikipedia.org/wiki/User:Raymond/hiero
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/wiki/User:Raymond/hiero",45118,-29,Lowest,
7.574797786265339,-5.381534477916297,6.485889326999136,7.422858921039481,-6.42735854650882,-1.3527425146386687,3.982490608655909,-2.748562634019109,1.1700176396462558,-1.507649828235405,-3.269514143807937,-0.5933177051475176,-2.9829021496277717,0.2646554477375256,0.360111460834319,-0.6505788358525861,0.6079366128492685,-0.23853725149190597,True,c1,0,"Puppet config for wikibugs:
https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=blob;f=manifests/misc/wikibugs.pp
Puppet config for gerrit-wm:
https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=blob;f=manifests/gerrit.pp
--------------------------
**Version**: unspecified
**Severity**: enhancement",44735,-30,Lowest,False
-6.587222190088983,-2.0152382077489577,-6.722995749077445,0.951716371845643,0.9262291133888467,-4.969144117889913,-5.192696476789621,-0.5083783833245068,-3.6917713628059348,4.897685805309445,-2.796980477599715,-1.2605706845906195,-4.194461365888018,1.3699646516699548,-0.9773149587596759,-0.13299724152431996,4.416567902215007,0.18007046047944963,False,c1,0,"Test case:
+ 'removing then inserting a character': {
+ 'calls': [
+ ['pushRetain', 41],
+ ['pushReplace', ['i'], []],
+ ['pushReplace', [], ['j']]
+ ],
+ 'expected': function ( data ) {
+ data[41] = 'j';
+ ve.setProp( data[37], 'internal', 'changed', 'content', 2 );
+ }
}
This sets the second change marker on data[36]. This happens because the start offsets handled in TransactionProcessor.replace are translated using this.adjustment , but that glosses over the fact that not all adjustments captured in this.adjustment actually apply if the offset is before the cursor. Instead, we need some sort of offset translation. I tried using ve.dm.Transaction.translateOffset() but that doesn't seem to work out of the box very well.
I guess theoretically this might also be an issue with other uses of .start attributes in the replacement processor, but it hasn't led to issues so far.
Low prio because we currently don't generate transactions that trigger this case.
--------------------------
**Version**: unspecified
**Severity**: major",44222,-33,Lowest,True
-1.2094920371969495,-0.47722848190536027,1.5320795535313927,2.7916146408000375,0.13654566641234422,0.05302425861868576,-3.539939346769273,0.09301635360026539,-0.26077939115002896,-4.1156095579146275,1.5800648399333732,2.9694085071231333,-1.480365774590326,2.265761196703453,2.1431045356232703,-0.22727415505192927,0.3195061473694927,-0.28946678840358997,False,c2,3,"Now the HTTP login page redirects to the HTTPS version, but for some reason creating an account is exempt.
Is there any reason to allow the login details to be sent in cleartext even once?
What I expect: [1] should redirect to [2]
[1] http://en.wiktionary.org/w/index.php?title=Special:UserLogin&returnto=Wiktionary%3AMain+Page&type=signup
[2] https://en.wiktionary.org/w/index.php?title=Special:UserLogin&returnto=Wiktionary%3AMain+Page&type=signup
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55651,0,Unbreak Now!,True
2.432519645770942,5.039221652636019,-3.757238863362071,1.2397171714413098,4.393172659248062,-0.8958546171089805,2.8997427128667246,1.5260170596721498,-2.8555510485164746,-0.798394304952248,0.18583085130920862,-1.9789951706841393,0.6698611333970046,0.2618705449848884,2.108904530653727,0.05567793933040238,-0.9500794362806869,-0.5213505480413567,False,c2,3,"When a user logs out on a single wiki (not included in a wiki farm) the forceHTTPS cookie is deleted. In the Wikimedia environment, login.wikimedia.org sets top-domain forceHTTPS cookies (.wikipedia.org, .wikiversity.org, etc) which are not deleted when the user logs out and therefore s/he is still redirected to HTTPS as anonymous user; even if s/he logs in again after having unckecked the preference ""Always use a secure connection when logged in"" s/he still is redirected to HTTPS since the global forceHTTPS cookie is still here. So these global forceHTTPS cookies should be deleted when the user logs out. The relevant HTTP headers are:
Login from the specific wiki (here frwiki):
Set-Cookie: frwikiforceHTTPS=true; expires=Sat, 28-Sep-2013 00:49:37 GMT;
path=/; httponly
Continuation of the login, from login.wikimedia.org:
Set-Cookie: frwikiforceHTTPS=1; expires=Sat, 28-Sep-2013 00:49:37 GMT;
path=/; domain=.wikipedia.org; httponly
Logout (specific wiki):
Set-Cookie: frwikiforceHTTPS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT;
path=/; secure; httponly
I originally reported this bug on bug 53379 but this one was focused on a user interaction issue rather than on a real forceHTTPS cookie issue (it was a single wiki); my first remarks are there. I mistakenly made a diagnosis and proposed a solution, but the real bug is this one.
--------------------------
**Version**: master
**Severity**: major",55536,0,Unbreak Now!,True
10.428478805103984,-2.901926681856107,0.6915190778153537,0.2870617433147835,4.539689389306204,3.834217219711398,3.3088494072305865,-1.3922605925416875,-4.914572565389806,-0.5677008439579447,-0.6016976268859411,6.558303046769838,-1.0211072558129013,2.5846353713135475,-3.548544139510968,0.11979373259471829,-1.1654728306721254,-0.7764764202202046,True,c2,2,"https://en.wikipedia.org/wiki/Special:Contributions/208.80.154.51 shows edits from a WMF IP, which reverse DNS says is ssl1007.wikimedia.org
--------------------------
**Version**: unspecified
**Severity**: major",54497,-4,Unbreak Now!,True
9.311923842642177,2.5208318073346057,-4.160911341275515,0.571694477454159,-1.7230540855863719,-0.02671598720654389,1.7397156509355218,0.7816932445487573,-1.2246901587756143,-1.2628417758273347,-1.1251732516436743,-1.0158642697018316,0.05167299141997095,-1.2668029745300209,-1.5885086233806724,-0.7507991139456203,-0.9565124398322515,-0.3455445466055975,False,c2,1,"**Author:** `the.anonymouse.wikimedia`
**Description:**
When using a secure connection (https) on Wikidata, all Wikivoyage links should link to the secure page (with the prefix https: ). However, only some Wikivoyages are linked with https.
For example, with https://www.wikidata.org/wiki/Q145 (United Kingdom), here are the results:
Uses https (when using https on Wikidata): de, en, fr, it, nl, ru, sv
Does not use https (regardless of using https on Wikidata): el, es, he, pl, pt, ro, uk
The results are consistent across other items with Wikivoyage links, such as https://www.wikidata.org/wiki/Q30 (United States of America).
--------------------------
**Version**: unspecified
**Severity**: critical",54311,-4,Unbreak Now!,True
-1.3744295235858648,-4.89874129914058,1.4313468278413843,5.1746039368845995,-1.1561735572199021,-4.3246327766497785,-0.36572133971248455,0.26712951899286197,-1.1639454588560902,1.2379755037219375,-2.0107084791133,-0.21483497035758314,1.3098751362819936,-0.641076577229259,-1.3330001222823205,0.12255641132015638,0.3490466766388207,-0.060799297353372195,False,c2,3,"The Puppet templates/labs-localsettings has
if ( array_key_exists( ""SERVER_NAME"", $_SERVER ) ) {
$wgServer = ""//"" . $_SERVER[""SERVER_NAME""];
}
Because $wgServer is not prefixed with http:, MediaWiki thinks https://servername links will work, thus several places in the code generate them, e.g. Special:UserLogin's _Use secure connection_ link and Echo notification e-mails. But most labs instances don't have working SSL, even via instance-proxy.wmflabs.org/
Project admins can't override this in orig/LocalSettings.php because these lines come after it is require_once'd.
Ideally the puppet LocalSettings would determine if https worked to the labs instance, and if not set
$wgServer= 'http://' . $_SERVER['SERVER_NAME'];
Possible workarounds include unset ($_SERVER['REQUEST_TIME'] ), overwriting $wgServer in some later config hook, and configuring SSL on the labs instance (bug 54065).
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://toro.wmflabs.org/wiki/Special:UserLogin",58389,9,Needs Triage,False
6.185093344065162,-6.902813655759238,-10.336034546959635,3.3534672740638953,-2.612169928343214,-2.9193161516003006,-6.308026842450482,0.8109078611529189,-0.48104471727209774,-3.871618862169962,2.851689789779854,-0.5214278531160224,-2.907512094944561,-1.0434660369462518,-1.6260689077976496,-0.42068239932174767,-0.4432747950840539,-0.17652709558986834,False,c2,3,"Test script
Running <code>python setup.py install</code> while in virtualenv does not install automatically the httplib2 dependency.
```
(pywikibot)cristian@cristian-F5N:~$ python test.py ""Alessandro_Manzoni""
Traceback (most recent call last):
File ""test.py"", line 4, in <module>
import pywikibot
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/__init__.py"", line 313, in <module>
from page import Page, ImagePage, Category, Link, User, ItemPage, PropertyPage, Claim
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 16, in <module>
import pywikibot.site
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 33, in <module>
from pywikibot.data import api
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 13, in <module>
from pywikibot.comms import http
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/comms/http.py"", line 30, in <module>
from httplib2 import SSLHandshakeError
ImportError: No module named httplib2
```
`test.py` is attached.
I am using Python 2.7.3 under `virtualenv` version 1.9.1 on Ubuntu 12.10.
Furthermore installing the dependency with `pip install httplib2` cause the following bug.
```
(pywikibot)cristian@cristian-F5N:~$ python test.py ""Alessandro_Manzoni""
ERROR: Traceback (most recent call last):
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 284, in submit
body=paramstring)
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/comms/http.py"", line 123, in request
raise FatalServerError(str(request.data))
FatalServerError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Traceback (most recent call last):
File ""test.py"", line 12, in <module>
item = pywikibot.ItemPage.fromPage(wikipage)
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 2527, in fromPage
repo = page.site.data_repository()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 98, in site
return self._link.site
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 3224, in site
self.parse()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 3207, in parse
if self._site.case() == 'first-letter':
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 1173, in case
return self.siteinfo['case']
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 1167, in siteinfo
self._getsiteinfo()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 1100, in _getsiteinfo
sidata = sirequest.submit()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 462, in submit
self._data = super(CachedRequest, self).submit()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 284, in submit
body=paramstring)
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/comms/http.py"", line 123, in request
raise FatalServerError(str(request.data))
pywikibot.exceptions.FatalServerError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
```
Steps to reproduce:
* download core.tar.gz and unzip
* create virtualenv
* run <code>python setup.py install</code> from <code>core</code>
* run <code>python test.py ""Alessandro_Manzoni""</code>
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**Attached**: {F12229}",58386,9,Needs Triage,True
1.8152945026898828,1.4928591906731228,1.8248450853456255,4.688551746772832,6.4590225770883585,6.637532712262909,-1.3095856501429957,-5.156685462995609,6.177080461280536,-0.11444345355059671,-1.0206392597128215,-2.5233807706862974,-2.5848473815717536,2.1867644249420817,1.949563819207289,3.430227895049798,-1.6090799864444867,-1.595153710697662,False,c2,3,"Visit a link in an email notification for a Flow event – you'll receive an SSL error.
--------------------------
**Version**: master
**Severity**: normal",58280,8,Needs Triage,True
0.5104585096553715,-5.886497048590359,5.125834087105851,0.4050328763911377,1.7872242093238944,-3.31124237497845,3.4190922733972675,1.6193177019833498,-3.569022840281784,2.6555199310372792,-0.9024622544835394,-0.11591521443146102,-0.8401078628334337,-0.6162789536165212,0.01846511021289654,-1.3087903346892986,-0.6543065099953398,0.07079166737218023,False,c2,3,"Some ""plain-text"" files like JS code is extremely slow to access. This has started only today. Example:
http://tools.wmflabs.org/magnustools/resources/js/bootstrap.min.js
Sometimes it works, though. Some lighttp issue?
--------------------------
**Version**: unspecified
**Severity**: normal",58244,8,Needs Triage,True
-4.730265351570923,8.300264797790721,-2.4752754456130717,-6.498574668606427,-5.026956450538876,0.3308696629147536,1.2790740283930626,0.6366773386420744,0.3516550073340061,-0.7064607215625038,0.1335356195200914,-0.2134253550847094,0.13385684100414785,-0.7338992170856837,0.6618011444255751,0.049864821377763324,0.10823058672832175,0.04548293169617579,False,c2,3,"In facebook ( https://www.facebook.com/settings?tab=security ), one can selectively log ones self out of other current sessions, but in Mediawiki, one is helpless if one wants to log out of a session for which one no longer has access to the terminal of.
Please implement being able to log out of selected other sessions, or at least a way of logging out of everything everywhere, short of changing one's password.
From the other task:
Currently, there’s no way for me to see which sessions are valid/active for my account on Wikimedia projects – if I want to be sure that I can’t be compromised by an old session, I have to change my password. It would be useful if MediaWiki instead offered a way to list those sessions, and ideally allowed me to selectively terminate them as well.
GitHub and Twitter have such a feature, for example:
{F30311189, layout=inline} {F30311223, layout=inline}
In MediaWiki, this is currently offered by [Extension:SecureSessions](https://www.mediawiki.org/wiki/Extension:SecureSessions) (CC @Parent5446), but that extension isn’t deployed on Wikimedia wikis and also doesn’t always work, for example due to T73066; in T73066#2386198, @Anomie outlined an alternative way to track sessions. I think it might be worth adding this as a core feature.
See also:
{T55156}",58212,8,Needs Triage,
2.967461880623255,-7.1602976622606676,-1.3501709555319277,-1.5430216036116502,0.4970599243717384,-1.2834216418082904,-2.6551343955116944,-1.176623557704212,1.8641513623754593,-0.774104753351236,0.14550509713029136,-0.4656767344628795,3.6590150767978877,0.1111854858953567,1.5939181157140583,-0.47800035485582015,0.7451075720915858,0.2742568160249761,False,c2,3,"Example[1]:
...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...
Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.
Workaround it so clone the repositories via SSH[2].
Contacted Cloudbees support[3].
They were able to reproduce the problem[4] and fix it.
1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218
--------------------------
**Version**: unspecified
**Severity**: normal",58098,8,Needs Triage,True
-5.193568668580253,-3.113227546373734,0.20656561105282378,-1.8607024057766277,-11.934051380452019,3.4405928241816426,2.8018180787707427,1.4794108239307877,-5.455970576130375,6.790802330706169,-0.9763235820044387,-3.034164957849715,0.04913147005113583,3.412090995408885,0.2836261267792519,-0.9512292730205434,0.6303590632084066,-1.1337924493465934,False,c2,3,"'Mobile view' link always heads to https because of incorrect value in second argument of MobileContext::getMobileUrl().
--------------------------
**Version**: unspecified
**Severity**: major",57982,7,Needs Triage,False
8.453788512069966,-5.220494493765813,-6.733988929694725,-5.363553134443972,-2.5929399834881175,3.8339021358999625,1.8660926511979676,4.201396538543292,1.7118282181471776,0.4700713702923558,0.5760834676681181,-0.655997325121048,1.163336179919058,2.1477417106306396,-0.994425521682917,-1.420055246989895,-0.37426167953917777,-1.058618508489309,False,c2,3,"So that services like these:
* http://acc.wmflabs.org
* http://parsoid.wmflabs.org
* http://cvn.wmflabs.org/api.php
.. can get proper valid HTTPS connections.
See also bug 48501 (for *.{projects}.beta.wmflabs.org, probably needs separate treatment)
--------------------------
**Version**: unspecified
**Severity**: normal",57957,7,Needs Triage,True
3.8098603817276246,-5.946822927416514,3.9020388663499155,7.640260297694189,-3.816221632537154,-4.636378242296034,4.2186420318113464,-0.948581393097708,2.309563895151687,0.5644265654691623,0.3999157961437412,0.9534769047237257,0.060181553820259026,-1.26798369123886,-0.49235198996900564,-0.7604772173530534,-0.30566755779813914,-0.9162264504653999,False,c2,3,"**Author:** `johan.gunnarsson`
**Description:**
Can not ssh to tools-dev from tools-login:
johang@tools-login:~$ ssh tools-dev
If you are having access problems, please see: https://wikitech.wikimedia.org/wiki/Access#Accessing_public_and_private_instances
Permission denied (publickey).
--------------------------
**Version**: unspecified
**Severity**: normal",57945,7,Needs Triage,False
12.071941939372373,5.110732489905335,1.7149152742523448,-2.441509947550959,-2.3057346190748396,0.8736148443262173,-4.071579638141848,2.4650695460926793,0.5958884327721906,5.352646602442974,-3.7093837172985777,0.20908781543978483,-0.7943385020472782,2.620595234323,-2.190011821111191,0.16855351994177875,3.0948539380412976,0.18744148369715208,False,c2,3,"seen on test2wiki Oct 17 after deploy
http://test2.wikipedia.org/wiki/Special:UserLogin?type=signup
correctly goes to the 'Create account' UI
http://test2.wikipedia.org/wiki/Special:UserLogin?type=signup
redirects to https but goes to the Login UI, not to the 'Create account' UI
Special:CreateAccount and Special:UserLogin/signup continue to function correctly
--------------------------
**Version**: unspecified
**Severity**: major",57854,7,Needs Triage,True
-6.842342205106876,3.488259651367791,-0.443051273209111,-5.468634811585896,0.7700594399878375,-1.9941801085463498,2.5206728372506033,-3.9866786650467465,0.6781779481028343,-0.19856103386825197,0.09717901069727963,-0.3089607717394527,-1.1557459788371887,0.3370755153786158,0.3609074306031479,0.20060011896407134,2.8779004133455066,-0.8812991998047979,False,c2,3,"It looks like in beta, the apache configuration is redirecting http://login.wikimedia.org to https.
I'm not sure where those configs are stored, but can we remove that? I did that for production a while back, but it looks like the change didn't get into beta.
This will let us enable SUL2 without https support in beta.
--------------------------
**Version**: unspecified
**Severity**: normal",57804,7,Needs Triage,True
3.6985854591024023,-5.410815247941233,-0.8455228902612753,3.0334139397094644,-3.5072532011474427,-1.0133663781136444,1.8900955980794505,0.9052658734595213,0.2875535606600189,-0.1647741413002599,-1.471897056846509,-0.46640740904252265,-0.49981172548990394,-0.11602430360851645,-1.919730254331693,0.8910221064235035,1.5991405761852178,-1.7676053904133533,False,c2,3,"cookies in Chrome
don't send forceHTTPS cookie for any beta.wmflabs.org host
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12680}",57760,6,Needs Triage,False
-6.366848425758185,2.0435501867489307,-6.0402437280020465,-4.291062208539201,-1.7428866991484282,-0.854365698810724,-0.7813693465586846,-2.162528414448701,-0.3881838241513632,-1.8965776375035044,-0.6638278428900306,0.06599172079148086,2.3509016406481678,1.3815134736677788,-1.0113186554075675,-0.06629355481637855,1.5216173375360997,-0.21758502995780682,False,c2,3,"Needs patches for other versions - only got 1.17 and 1.20 at the moment, so it probably needs 1.19, 1.21, and 1.22, especially as those are all of the current releases.
Uncyclomedia has the file patched for 1.21, but nobody exported an actual patch file and I'm not sure it actually works, either - seems to have worked for uncyclopedia, but testing failed for ?pedia?
(From what I understand, this is the patch to make it prevent the creation of accounts with names that folks might otherwise try to import. If I'm wrong about this someone smack me.)
--------------------------
**Version**: master
**Severity**: normal",57640,6,Needs Triage,False
-0.7881096595312789,6.310671350334147,-0.5304069872602071,-5.333442984080937,-2.3485789316122485,-7.149365232775401,4.4001666710287966,-5.386696443123501,-1.905310871216904,-0.7926190755047497,0.12706898729445637,4.572014377268831,-0.8017542122895591,0.41651308223196004,-0.20092634202541237,0.9031072560608364,-3.029916840671812,0.03069215306274864,False,c2,3,"It only seems to be passed when you click sign up. What is stranger is if you inspect the URL of the login link it is there - it somehow gets stripped on click ing it.
Expected:
Whilst logged out click on edit button
CTA shows with login and sign up buttons
Click login
Address bar URL has campaign=mobile_editPageActionCta in it
--------------------------
**Version**: unspecified
**Severity**: normal",57474,5,Needs Triage,True
-5.089227073978457,1.1738164380126044,2.6778622525611517,1.8255284874079827,-1.2811884651048504,-5.240298716656,1.5796226943973837,-1.3278652634197745,4.241617284415424,-0.3471495920910739,1.4899331388809034,1.007800993563867,2.763885446986367,-1.7971673725622885,4.168710606649214,0.28461796838076087,1.3786927007850924,1.0722047701723192,False,c2,3,"Hi please update login and create account buttons because the layout and look of them was changed in 1.20 when they separated them into create account and then login so please update the looks and the create account could be redirect to special request account. I am running Mediawiki 1.22 Wmf 20. I was told to file a bug here at https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Create_account_/_login_in_extension:confirmaccount
--------------------------
**Version**: unspecified
**Severity**: trivial
**Whiteboard**: aklapper-moreinfo",57468,5,Needs Triage,False
3.7762496871859583,-11.677169090877515,-6.012983902028068,4.5642963438265465,-1.515664480466413,-1.166092518832906,1.419810419592637,0.5867290204859243,-3.5659351979724043,2.2314279440997318,4.48090173383423,0.04454549565182164,6.868390876341506,2.931569911425667,0.42851149855485104,-0.7240744651050617,0.06485555851534097,-0.31195119433594054,False,c2,3,"2013-10-06 12:01:48 mw1053 enwiki: [7b14de3f] /w/index.php?title=Special:UserLogin&action=submitlogin&type=signup&returnto=Special:UserLogin&returntoquery=article_action%3Dwatch Exception from line 109 of /usr/local/apache/common-local/php-1.22wmf19/includes/WikiPage.php: Invalid or virtual namespace -1 given.
#0 /usr/local/apache/common-local/php-1.22wmf19/includes/actions/WatchAction.php(124): WikiPage::factory(Object(Title))
#1 /usr/local/apache/common-local/php-1.22wmf19/extensions/MobileFrontend/includes/MobileFrontend.hooks.php(427): WatchAction::doWatch(Object(Title), Object(User))
#2 (): MobileFrontendHooks::onUserLoginComplete(Object(User), '<!-- do CentralAuth redirect -->')
#3 /usr/local/apache/common-local/php-1.22wmf19/includes/Hooks.php(199): call_user_func_array('MobileFrontendHooks::onUserLoginComplete', Array)
#4 /usr/local/apache/common-local/php-1.22wmf19/includes/GlobalFunctions.php(3898): Hooks::run('UserLoginComplete', Array)
#5 /usr/local/apache/common-local/php-1.22wmf19/includes/specials/SpecialUserlogin.php(926): wfRunHooks('UserLoginComplete', Array)
#6 /usr/local/apache/common-local/php-1.22wmf19/includes/specials/SpecialUserlogin.php(313): LoginForm->successfulCreation()
#7 /usr/local/apache/common-local/php-1.22wmf19/includes/specials/SpecialUserlogin.php(200): LoginForm->addNewAccount()
#8 /usr/local/apache/common-local/php-1.22wmf19/extensions/MobileFrontend/includes/specials/SpecialMobileUserlogin.php(15): LoginForm->execute(NULL)
#9 /usr/local/apache/common-local/php-1.22wmf19/includes/SpecialPage.php(631): SpecialMobileUserlogin->execute(NULL)
#10 /usr/local/apache/common-local/php-1.22wmf19/includes/SpecialPageFactory.php(489): SpecialPage->run(NULL)
#11 /usr/local/apache/common-local/php-1.22wmf19/includes/Wiki.php(291): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#12 /usr/local/apache/common-local/php-1.22wmf19/includes/Wiki.php(591): MediaWiki->performRequest()
#13 /usr/local/apache/common-local/php-1.22wmf19/includes/Wiki.php(460): MediaWiki->main()
#14 /usr/local/apache/common-local/php-1.22wmf19/index.php(55): MediaWiki->run()
#15 /usr/local/apache/common-local/w/index.php(3): require('/usr/local/apache/common-local/php-1.22wmf19/index.php')
#16 {main}
--------------------------
**Version**: unspecified
**Severity**: normal",57379,5,Needs Triage,True
-2.6965358094509777,-0.9542191046568078,-0.49117173518635937,3.8607799747865457,-0.20919055994180952,2.1298415766043295,4.723690919562613,2.8163336591947146,-2.320689393320065,2.7333818746230394,-0.9648855983009494,1.5016929521808924,-1.8689963027818504,0.5389274704126832,1.216569233488598,-0.1243014748525566,-0.8788298098369454,0.04693811982156704,False,c2,3,"Although the ""Always use a secure connection when logged in"" check box is unchecked, de.wikipedia uses secure protocol for some users and also each explicit http page request is redirected to https.
https://de.wikipedia.org/wiki/Wikipedia:FZW#Sichere_Anmeldung
--------------------------
**Version**: wmf-deployment
**Severity**: normal",57368,5,Needs Triage,True
5.9482525043995125,-3.363472499912737,-3.0260279307586497,1.5857293852290222,-0.6888796547752583,-2.783836607771293,-3.6222180340661083,0.03967813306134366,-1.815103015414591,-4.3365482512313145,-1.0318746121760243,-1.4611623287684128,8.724387922155984,4.708342960872336,3.1003544086079335,-1.3199228549117588,0.144123815581235,1.4239071235965055,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1136/
Reported by: Anonymous user
Created on: 2010-03-09 13:34:43
Subject: Login no longer available
Original description:
I get the following errors when using a known good user-config.py and family configurations for an SVN checkout of 2009-11-05. This is for a local wiki.
Using 2010-03-09, I get the following error on Ubuntu 9.04 \(Python 2.6.2\) and Ubuntu 8.04 \(Python 2.5.2\):
Logging into FamilyName:en as UserName via API
Error downloading data: No JSON object could be decoded
Request: en:/scriptpath/api.php?
Retrying in 1 minutes.... \(I changed line 152 of query.py to retry\_idle\_time\*0.01 so I could see the dump without growing a beard first\)
Dump output:
Error reported: No JSON object could be decoded
127.0.0.1
/hcrscript/api.php?
\{""login"":\{""result"":""Success"",""lguserid"":3,""lgusername"":""UserName"",""lgtoken"":""2b448df9379b445c225c0a5c1d3af18b"",""cookieprefix"":""DatabaseName"",""sessionid"":""3dd4cc3dd33236b57da8234d2f73e6d3""\}\}
on Ubuntu 9.04:
python version.py
Pywikipedia \[http\] trunk/pywikipedia \(r7983, 2010/03/09, 08:14:34\)
Python 2.6.2 \(release26-maint, April 19, 2009, 01:56:41\)
\[GCC 4.3.3\]
also broken on Ubuntu 8.04
python version.py
Pywikipedia \[http\] trunk/pywikipedia \(r7983, 2010/03/09, 08:14:34\)
Python 2.5.2 \(r252:60911, Jul 22 2009, 15:35:03\)
\[GCC 4.2.4 \(Ubuntu 4.2.4-1ubuntu3\)\]
But it seems to work fine on this system:
foreignhost:pywikipedia-2010-03-09 alex$ python version.py
Pywikipedia \[http\] trunk/pywikipedia \(r7983, 2010/03/09, 08:14:34\)
Python 2.5.2 \(r252:60911, Feb 22 2008, 07:57:53\)
\[GCC 4.0.1 \(Apple Computer, Inc. build 5363\)\]
Any ideas what's happening?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1136",57285,5,Needs Triage,False
2.24708115347998,-4.463216619852968,-2.529680523597982,1.2008114776579086,-2.932774167601081,-1.1418479567009536,-1.4957183550487203,1.3516931892992754,-1.3258892988676427,-2.928703352867459,-1.8836646786881623,-1.9113630505162764,3.887411423420921,1.3914006397060836,-1.0856434979132983,-0.9302293946126201,-0.13707039104153496,-0.20764814775357499,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1360/
Reported by: nakor-wikipedia
Created on: 2011-10-14 14:23:06
Subject: login.all always asks for password
Original description:
When calling
login.py -all -pass
the script first asks for a password and then asks for password for every sinmgle wiki site:
login.py -all -pass
Password for all accounts:
Password for user Almabot on mediawiki:mediawiki:
....
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1360",57232,5,Needs Triage,False
3.229901906310427,-0.8985917360409665,-3.3863745548230177,6.73175330145532,-4.281926151788556,-6.893934161942432,-1.6212671459497425,-0.9467801580524643,-2.979690939400802,0.5154317717691077,-2.707788450993774,-0.08447185927762146,2.0737607266335116,1.8188081755527241,2.5263407490203464,1.9779425714866445,-1.0283309114112549,0.2447874482669523,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1488/
Reported by: reza1615
Created on: 2012-07-08 12:29:13
Subject: interwiki and login errors on en.wiki
Assigned to: xqt
Original description:
my bot \(Rezabot\) has a flag on en.wiki and it is not blocked there but it couldn't edit on there
File ""interwiki.py"", line 2296, in run
self.queryStep\(\)
File ""interwiki.py"", line 2274, in queryStep
subj.finish\(self\)
File ""interwiki.py"", line 1723, in finish
if self.replaceLinks\(page, new, bot\):
File ""interwiki.py"", line 1961, in replaceLinks
status, reason, data = page.put\(newtext, comment=mcomment\)
File ""/home/reza/pywikipedia/wikipedia.py"", line 2024, in put
newPage, self.site\(\).getToken\(sysop = sysop\), sysop = sysop, botflag=botflag, maxTries=maxTries\)
File ""/home/reza/pywikipedia/wikipedia.py"", line 2143, in \_putPage
self.site\(\).checkBlocks\(sysop = sysop\)
File ""/home/reza/pywikipedia/wikipedia.py"", line 5461, in checkBlocks
raise UserBlocked\('User is blocked in site %s' % self\)
pywikibot.exceptions.UserBlocked: User is blocked in site wikipedia:en
also my bots name is listed on \[\[Wikipedia:Bots/Status\]\] bot iterwiki code says it's name is not in the list\!
--------------------------
**Version**: compat-(1.0)
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1488",57183,5,Needs Triage,False
1.5627401085848036,-2.127239825301709,1.7237482131985722,2.2060305982937445,-4.7412702915709435,-4.937514661358857,-3.205712455919856,0.7912028063649122,-0.4364388029613974,2.219691441756736,-1.4415322410456433,-1.0895533623627347,2.6953414173111456,0.4912178816883328,1.4566638094489557,1.1121146411705243,-0.020266309177642716,0.1358935010486524,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.
The following was outputted when I tried
family = 'wikisource'
mylang = ''
Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language does not exist in family wikisource
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572",57154,5,Needs Triage,True
0.13732386548088815,-0.8088587332420936,-0.1351564417159512,1.674612861146596,-0.4647782435134676,-1.7192598098241882,-1.9399221956416888,-1.2926045629724254,-0.47119287279669664,-2.8758232830475032,-2.4113536926293024,-1.9089165232011043,3.4318033146354927,2.229332700030489,2.12418802053274,-0.9402937292814157,0.09734204020940296,-0.2801791371258502,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1632/
Reported by: nu11zer0
Created on: 2013-05-03 05:54:46
Subject: force login after performing a sysop action
Assigned to: russblau
Original description:
After my bot performed a sysop action, then wrote to a page, the bot wrote without botflag\! It seems that the framework cached some informations and understood that the bot has no flag. My workaround is to add ""site.login\(\)"" after every sysop action. But it should be implemented in the framework. Note that now redirect.py also has this problem.
\----
Pywikibot branches/rewrite/ \(r11487, 2013/05/02, 07:59:55, ok\)
Python 2.7.3 \(default, Sep 26 2012, 21:53:58\)
\[GCC 4.7.2\]
unicode test: ok
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1632
https://bugzilla.wikimedia.org/show_bug.cgi?id=55066",57140,5,Needs Triage,False
7.566848998351947,-6.542439722520028,7.240293012307376,2.5633149064568204,-1.7528628175568588,-1.9849634473029032,4.231711673337517,-2.5131366270278557,-0.07398908959142725,-0.45763568966474377,-1.0757278440428824,-0.617704127656972,-1.891394775288016,0.24574008243643863,-0.25004619384568105,-0.18424162762677354,0.4272509164907803,-0.4717420521691078,False,c2,3,"**Author:** `metatron`
**Description:**
HTTPS on both wmflabs-sites not possible:
http://icinga.wmflabs.org/icinga/
http://ganglia.wmflabs.org/latest/
On wikimedia-sites it works fine
https://icinga.wikimedia.org/icinga/
https://ganglia.wikimedia.org/latest/
--------------------------
**Version**: unspecified
**Severity**: enhancement",56710,4,Needs Triage,False
0.37314431262717607,-2.8676317284323876,3.964361969305074,-3.331938225308046,-3.7908006359539916,1.9502469778627274,-4.133012889295884,1.7420691879590988,-0.6260325188051983,-3.1885872562516355,-1.7997184704434621,-3.140495340612664,3.2436858155726016,2.591252434606381,0.3464419871323017,-1.4917679799233305,-0.9271077539964044,-0.404419011303484,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/patches/621/
Reported by: gallaecio
Created on: 2013-08-03 20:30:54.056000
Subject: When loging in to a site, try the site-configured username if any
Original description:
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/patches/621",56541,3,Needs Triage,False
-5.958197358107558,3.2875733023322056,1.8290750975905148,-0.026716029242400463,0.8995240878475599,-0.8723581588952366,2.1648347864776403,-3.5573255243522355,0.4476917047708042,-2.053977952331028,-3.0163520318101393,-1.7687740709097646,-3.2434059128955344,2.778279550811564,-1.485161747110375,-0.4706236306156407,1.5451246744992215,-1.2029108672929185,False,c2,3,"Grepping through the code shows no use of this variable outside of its declaration. It certainly doesn't remove the login link.
--------------------------
**Version**: master
**Severity**: normal",56506,3,Needs Triage,True
-3.2021144719892827,-0.17372299830123872,3.8075641004471166,-0.6890810807320813,-4.856924113315836,-8.189427062269646,3.8403353003220664,-1.342567203629811,0.39010056442340835,0.7073541628859852,0.2212276288565005,0.7503927474541152,0.09626232451257,0.8816572006911692,-0.6849101038023946,-0.4814041472189081,-1.0608461092316648,-0.51249320909198,False,c2,3,"Please enable HTTPS on parsoid.wmflabs.org. Unsure if it needs it's own certificate or if there is one for *.wmflabs.org.
It recently had CORS enabled so users can write custom scripts to access parsoid, however they'll face mixed content blocking issues since HTTPS doesn't work yet.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://parsoid.wmflabs.org",56192,2,Needs Triage,True
-4.5101162782788045,7.617352061584064,-0.5325537573728507,3.765643754140828,2.126814359088816,4.30701495759789,-0.014006331847904008,0.5399605921273269,-0.5715542227622237,-1.683581891834323,-2.3386996593340608,-1.1101583836212907,-1.1324694553418562,0.8183163514632517,-0.23103839020762607,0.16679851795489925,0.5896819127567026,-1.8356461007918239,False,c2,3,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.
rfc5849 - 2.3 says that:
Since the request results in the transmission of plain text
credentials in the HTTP response, the server MUST require the use of
a transport-layer mechanism such as TLS or SSL (or a secure channel
with equivalent protections).
However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.
--------------------------
**Version**: master
**Severity**: normal",56110,2,Needs Triage,True
6.17691203435729,0.32510387831221266,0.10057421471859129,-12.108672597581227,-1.4292801850841959,-2.29621679644978,-1.542608612999878,-3.972274152712819,3.9542350966152506,1.756348863909686,1.7487277632045157,0.12249490236182026,2.025194680625113,-2.137876705946399,-0.47254960887605435,-1.6349274778332383,0.18819590459275304,0.8582007229711615,False,c2,3,"We switched to Labs hoping that it would bring us HTTPS, but apparently not.
I created an instance with this enabled:
- role::lamp::labs
- certificates::star_wmflabs_org
But Firefox says ""Unable to connect"": https://i-000008da.pmtpa-proxy.wmflabs.org
Am I missing something? What should I do to allow visitors to connect via SSL?
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48501",56065,2,Needs Triage,False
26.550520659744475,1.2580945778626944,-17.038750241131456,10.189331729835358,0.23612446936418774,-1.498309494039892,7.2385757996929785,-0.21667540528850726,-0.6847921503377246,-0.03457066486046578,-0.5915350075755716,4.269080481348831,-1.6377306156390778,-0.5785903321795054,0.5579619878397057,-0.1715253810889712,-0.554122064384386,-0.38344847697660245,False,c2,3,"metrics.wmflabs.org gebruikt een ongeldig beveiligingscertificaat.
Het certificaat wordt niet vertrouwd, omdat het zelfondertekend is.
Het certificaat is alleen geldig voor wikimetrics.pmtpa.wmflabs
--------------------------
**Version**: unspecified
**Severity**: normal",55892,1,Needs Triage,True
-0.3849615273583429,2.5488511741094193,-1.98812855524889,-2.2819267948219606,-6.314328688902721,0.509583780972148,-1.8315960457147762,0.6139515079883229,-0.8661903714598987,-2.799131821740674,-2.129676132181357,-0.7217559354856915,0.26305603701841296,-0.4403036153606399,-1.9501438438234562,1.83595948351508,0.3998236099157262,0.2845865883105383,False,c2,3,"**Author:** `winne2i`
**Description:**
After recent changes in HTTP/HTTPS logging in for users there's a problem*.
Google search results point to HTTP versions of articles but users are not logged in while on HTTP. This enforces users to reload page or re-log in.
I see some solution in bug 51002 ?
*)Although this also occured before but user could login via HTTP (and optionally use a DIY script in common.js to redirect to HTTPS).
--------------------------
**Version**: unspecified
**Severity**: normal",55703,0,Needs Triage,True
1.0100475459467089,1.4875013858745554,4.344854179120436,-7.169529598367902,-5.0203546769650735,1.1237749620686504,2.5590210460709715,3.179756760163628,1.7955362960098313,1.8231318316740603,1.974438514057105,3.6799821691261343,1.0286530435093315,1.4387852571506876,-1.9274268056526895,-2.0723077627455964,-2.0144753251141148,-2.3025924729724343,False,c2,3,"See https://tools.wmflabs.org/liangent-php/detectProtocol.php/enwiki
Feel free to move this bug to MediaWiki product if there's some reliable way to check so there while MediaWiki is unaware of it.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64627",55689,0,Needs Triage,False
-6.229795241842295,-0.8395937037301273,-1.8384370464873445,7.831640009692297,3.8355016595965776,-0.6653568939788472,0.46670129428797136,-0.42595274606066014,-0.0024382024760151166,1.4311481475634862,-2.517096769862568,1.8467351825474008,-1.393588272979339,0.3345462417347518,-0.6032921024124596,-1.099400356817908,0.9259848205524295,-0.7218968105052712,False,c2,2,"OATHAuth uses the following line to add the extra input to the login form:
$template->set( 'extrafields', $input );
This actually overwrites the extrafields parameter, so if there is any other extension that also adds fields to the login form, it will be overwritten.
--------------------------
**Version**: master
**Severity**: normal",55198,-1,Needs Triage,False
2.874443361095073,2.1301749528709486,2.5398138956981633,-5.16966403778853,-1.2417010335532859,-2.6131470876995264,3.8144718148897434,-2.226491216547816,-1.8450712249132901,0.9114689592725824,0.5616578686071221,-0.054229701005283015,-2.2089326731429546,0.9642160889282394,0.6446888609419172,1.3557469454951259,-1.1183553428607391,1.5423911115835136,False,c2,2,"The ACC <https://en.wikipedia.orgg/wiki/WP:ACC> project is in the final stages of moving from the Toolserver to Wikimedia Labs, but since it requires HTTPS (to protect users' privacy) and is also its own Labs project (by necessity), it also requires its own valid SSL certificates.
Thank you very much in advance!
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56927",55175,-1,Needs Triage,False
-4.0524478624907605,0.7991348451850637,-2.7248718431570254,-3.0824030360193824,0.9594753898749155,0.9352493724347541,1.4438915785214208,0.9564173641337076,0.8328393198286268,-1.0624537510102505,-0.6252539011669231,3.1155445644240674,-0.05055604604560582,-0.5107768596890976,1.1457038744922663,0.7643060905405432,1.2457725399669675,0.7180896704783779,False,c2,2,"This bug is about the problem of HTTPS for languages of China (where HTTPS is blocked). I suggest not to discuss political implications here (and discuss it on the wikimedia-l mailing list) but only technical things.
The bug/problem is largely known but I don’t think there is an open bug for that, so this is the case now; probably the resolution can be INVALID or WONTFIX because it is due to external factors, but it will serve to concentrate the discussion.
This bug is related to bug 52846 about a similar problem in Iran, and resolution/discussions can be different although related.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52846",55144,-1,Needs Triage,True
-3.8326129466945242,1.1273746571209635,9.865266452202253,2.075844169860152,-7.344087569602854,-0.828477430719373,-1.0828944549941824,1.8429887668247682,1.8149767929819445,5.669657162057552,-0.8779095144258315,4.766870372639558,0.26309699466042424,0.20603302333579787,-0.3364680733971488,-1.1834336444366695,-0.2464174676225659,-0.7159064229348979,False,c2,2,"Attempt to login on beta commons with improper credentials.
Messages like ""Login error/There is no user by the name ""asfdasfa"""" do not appear.
Such messages do appear on http://commons.wikipedia.beta.wmflabs.org/
Note: this may be because http://commons.wikipedia.beta.wmflabs.org/ redirects to http://commons.wikimedia.beta.wmflabs.org/
--------------------------
**Version**: unspecified
**Severity**: normal",55080,-2,Needs Triage,True
-0.41121410439267025,-5.964145848250624,4.624674090198148,5.719226099957273,-5.386615800226227,-1.1264316565196586,-3.4001185681026564,-3.155178914919415,0.8891147259585457,3.1864617281095367,-7.865119100346627,-0.6607608751798654,-3.6951618758900437,0.23647840484285787,0.9626936494184957,-0.6595366066473437,-1.1247066855398398,0.5659969545267403,False,c2,2,"Please, replace the ocurrences of ""http:"" by ""https:"" at
https://bugzilla.wikimedia.org/describekeywords.cgi
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://bugzilla.wikimedia.org/describekeywords.cgi",54949,-2,Needs Triage,True
0.5117924076924965,4.8811225231543425,2.551285505684085,-3.26504826693632,2.56313988125079,-2.646279190032508,0.09752953460986369,-5.112721479400168,-1.0584944429440184,-0.9015174309315124,0.12053206165872199,-4.3675267515908685,0.994644206822191,-3.9675248113812174,4.205823160609316,0.5611965423942535,3.532032086230065,-1.2255806425163844,False,c2,2,"On a test browser instance I visited https://en.wikipedia.org, and clicked Log in. I used a WMF test account (SpageTest AC 0618-1) that I probably hadn't used since June.
Login displayed an unexpected failure from http://wikimediafoundation.org/wiki/Special:CentralLogin/start?token=TokenHereBlahblah , ""No such special page"". I was actually logged in to enwiki. Note the URL above is CentralLogin/start, not CentralAutoLogin/start, I think I copied and pasted it from the browser location bar.
I logged out and repeated the login, with Firebug active. This time I logged in fine. There was still a 404 in the Net tab but it didn't display as a failure and it was from http://wikimediafoundation.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikisource&type=1x1&from=enwiki
I logged out, cleared my cookies, and went back to enwiki and logged in; this time there were no requests to wikimediafoundation.org
Maybe this is a remnant of some old-style login cookies.
--------------------------
**Version**: wmf-deployment
**Severity**: minor",54568,-4,Needs Triage,True
-5.2428851323246475,1.4094523887833628,-3.1456789035035815,-3.276951345596828,-9.32359869809437,5.707554338982649,3.5239706062150384,-2.1040767158971243,1.2259205268379427,0.36523077011170013,-0.7143932948325769,3.4127824060046095,-2.2118573136862905,1.8663989694247727,1.730515617825139,0.3879394465233599,-0.43647937280279536,0.17904317383503332,False,c2,2,"MediaWiki appears to normalize spaces in names to _, before extensions are able to read the original names.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54481,-4,Needs Triage,True
1.8698795330939677,-4.086867684331489,1.0137902879064953,-4.481486700425812,1.7604308445158332,-4.86659554474674,1.6207708052683794,-4.049218550050156,-1.8936905973783782,-0.34783617057960825,0.5724522474447786,-2.547352799541823,1.46953217914613,-0.8362221043797131,-0.6447667388381202,0.8135478536337437,0.539006954447786,-0.4170818574839008,False,c2,2,"**Author:** `hosse`
**Description:**
Sorry for my bad english. If I'm logging in I'm only registered in german Wikipedia and not in all other projekts in what I have an account (SUL). I noticed it first yesterday. And I've tried it now several times - ever the same.
It is not only a problem of mine: https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Anmelden
I'm using Firefox 22.0 over https.
Thanks
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC",54397,-4,Needs Triage,True
-1.0750375696977632,-0.27990868010948056,-4.8347281070696315,2.8143728508497823,2.245664249544318,1.06321098114214,0.7582201121971455,2.3088387972639848,-2.663861223935247,0.1170762498041853,-0.9818035888484622,0.3139521131919585,0.7281902358727121,-0.33244228962706934,-3.501759742425692,0.6086336720905474,0.7994681199404823,-0.01896743801868861,False,c2,1,"Without javascript, the central login check is failing to run correctly.
Local wiki writes an image call that looks something like title=Special:CentralAutoLogin/start&type=1x1&from=enwiki
However, CentralAutoLogin checks for
} elseif( $request->getVal( 'from' ) === wfWikiId() && $wgCentralAuthLoginWiki !== wfWikiId() ) {
Which is true in this case, and so the browser is redirected to the central wiki, to Special:CentralAutoLogin/start, which fails.
The pure javascript version of the check makes a call to:
index.php?title=Special:CentralAutoLogin/start&type=script
So the code above doesn't evaluate true, and everything works.
--------------------------
**Version**: unspecified
**Severity**: major",54356,-4,Needs Triage,True
1.1399928599874838,-2.580197822068161,-1.5147616810618363,-3.6601170387182704,1.4265548115972346,-0.42500207996767614,-0.008619915556084656,-0.12668385744533425,-0.3006289312991152,0.16434046679116499,-0.1571758100879168,0.44211250684311887,1.4495104458711552,-0.8124752475871286,-0.5204511021018199,0.10783988032260453,0.47817504515461784,-0.3895528217931903,False,c2,1,"500 Internal Server Error
At http://tools.wmflabs.org/ftl/cgi-bin/ftl?st=wp&su=Rosa+Parks I currently get the default Apache HTTP 500 error page.
It is uninformative. In particular I want to see information to the effect that ""this error could either be a problem with the individual tool you are trying to use, or with the Labs server setup more generally"".
(I don't know if this is specific to Tool Labs or the entire wmflabs.org cluster, so please recategorise accordingly.)
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://tools.wmflabs.org/ftl/cgi-bin/
**Attached**: {F11402}",53745,-6,Needs Triage,True
-9.01788517836128,3.6754904754450735,-4.179064558701985,-6.886896325251093,-0.10847963404742716,-1.968901959922038,3.2451382417977994,-0.8260538443639791,1.5999627204091875,0.9122257459004199,2.472726162408748,-3.185143763731906,0.4633800743776768,0.03192469216471849,-0.29890848726157593,-0.054117570016990635,0.38483546538513314,-0.40331489666196485,False,c2,1,"To have beta's login fully mimic productions, we should setup a loginwiki equivalent in beta.
To make it similar to production, the wiki should only us https, and have most features and extensions disabled. However, the only thing required for SUL2 is that we have a central wiki designated as the one keeping track of all logins. So if it's too much work, it's probably not worth the effort right now.
Realistically, I probably don't have the time to figure this out on my own in the next couple of weeks, but if I can get some help on it, I think we should be able to set this up pretty quickly.
--------------------------
**Version**: unspecified
**Severity**: normal",53622,-6,Needs Triage,True
15.84330738873799,-0.9259296648252953,-0.5339630158456572,-1.8972501594106816,-7.060970925303387,1.6220369805033006,-3.772499529605851,-0.031217855288225432,-0.672235283435195,0.1437892064193269,-1.339861869227616,-0.2779669187601861,4.182855276239784,4.944314103566098,2.8604432518708593,-0.2238256328843612,-0.018832905200002248,0.6688761832063734,False,c2,1,"at http://commons.wikimedia.beta.wmflabs.org/
click ""Log in""
get fatal error:
Request: GET http://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page, from 127.0.0.1 via deployment-cache-text1 deployment-cache-text1 ([127.0.0.1]:3128), Varnish XID 992017130
Forwarded for: 127.0.0.1
Error: 503, Service Unavailable at Thu, 18 Jul 2013 15:29:44 GMT
--------------------------
**Version**: unspecified
**Severity**: major",53616,-6,Needs Triage,True
18.066839507275535,-2.5152237416167242,-7.926108654977057,1.2486852191229878,-0.9441872196794446,-1.0573978212414115,-2.4714992420897253,-0.6521001072860423,-1.2614831396813484,-3.4474926962723607,-1.1044768804683933,-1.415925990558455,6.387799703927027,2.8279607993995093,1.6227435452288788,-0.6121785903907689,0.3942869142014995,-0.19655632769903653,False,c2,1,"Yeh there seems to be another issue here as well. The login session is only lasting for 2 days on my mobile. Bugzilla and Gerrit seem to stay logged in forever on the other hand.
The mobile site uses HTTPS - could this be part of the issue?
Here's an inspection of my HTTP headers:
On mobile site:
Sent:
enwikiUserName Jdlrobson / en.m.wikipedia.org Wed Aug 14 10:40:59 2013
centralauth_LoggedOut xxx / .wikipedia.org Wed Aug 14 10:43:58 2013
mfsecure 1 / .wikipedia.org Mon Jul 15 11:51:50 2013
enwiki_session xxx / en.m.wikipedia.org End Of Session
centralnotice_bucket 0-4.2 / en.m.wikipedia.org Mon Jul 22 09:54:35 2013
enwikiLoggedOut xxx / en.m.wikipedia.org Tue Jul 16 10:43:58 2013
received:
centralauth_User Jdlrobson / .wikipedia.org Wed, 14-Aug-2013 17:44:14 GMT
centralauth_Token deleted / .wikipedia.org Thu, 01-Jan-1970 00:00:01 GMT
centralauth_Session xxx / .wikipedia.org End Of Session
enwikiUserID xxx / en.m.wikipedia.org Wed, 14-Aug-2013 17:44:14 GMT
enwikiUserName Jdlrobson / en.m.wikipedia.org Wed, 14-Aug-2013 17:44:14 GMT
enwikiToken deleted / en.m.wikipedia.org Thu, 01-Jan-1970 00:00:01 GMT
enwikiforceHTTPS true / en.m.wikipedia.org Wed, 14-Aug-2013 17:44:14 GMT
enwiki_session xxx / en.m.wikipedia.org End Of Session
On desktop site:
Sent:
uls-previous-languages xxx /w/ en.wikipedia.org End Of Session
ext.moodBar%403-tooltip 1 / en.wikipedia.org Sat Aug 3 15:03:44 2013
mediaWiki.user.id xxx / en.wikipedia.org Thu Oct 17 15:13:09 2013
wikimedia-SUL-final-CN-general 5 / en.wikipedia.org Thu May 8 22:24:51 2014
centralnotice_bucket 1-4.2 / en.wikipedia.org Mon Jul 22 10:44:50 2013
enwiki_session xxx / en.wikipedia.org End Of Session
Received:
centralauth_User Jdlrobson / .wikipedia.org Wed, 14-Aug-2013 17:45:00 GMT
centralauth_Token xxx / .wikipedia.org Wed, 14-Aug-2013 17:45:00 GMT
centralauth_Session xxx / .wikipedia.org End Of Session
enwikiUserID xxx / en.wikipedia.org Wed, 14-Aug-2013 17:45:00 GMT
enwikiUserName Jdlrobson / en.wikipedia.org Wed, 14-Aug-2013 17:45:00 GMT
enwiki_session xxx / en.wikipedia.org End Of Session
--------------------------
**Version**: unspecified
**Severity**: major",53377,-7,Needs Triage,True
-3.185992426603651,1.0089348556358537,-1.0937081071950576,0.2570657362102904,-7.319003507740753,-1.1479340359167691,-1.444417600497518,1.774473904047511,-0.17920059142552958,-1.6704826444541907,0.6983050128109558,0.702035560425212,-1.8723640956966836,-0.4435511668280441,-1.3740285638777605,1.1406230921518605,0.0903374129815202,-0.2667910987427127,False,c2,1,"Hi,
When not-logged in (ip) user goes to language >> language settings >>Display language (which he currently can not change without being logged in) >> if he selects link log in and logs in >>Requested enhancement : ULS language setting display should be open next to [[MediaWiki:Loginsuccess]] or ''best thing is link of ULS language setting in [[MediaWiki:Loginsuccess]] to all the users''
*Purpose: To complete users expected logical next step of action of language selection in smooth manner.
*To understand further the need for above request,please do refer to survey
data and analysis provided at
http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#feature_to_make_content_language_input__default_28864
--------------------------
**Version**: unspecified
**Severity**: enhancement",53358,-7,Needs Triage,True
3.843659631380612,-1.5628941882117218,0.9117208405411716,1.3565665273817893,-2.6922832205516998,1.1972243175482438,-0.28500195669585615,-0.7999357535284701,-2.9728287135617553,-1.5970504434220105,-0.4821680628494911,-0.5800415149054932,3.7447075655301076,1.9468929476075996,-1.0415709358372762,0.9722072532322443,0.13770619020119756,-0.319041039181605,False,c2,1,"Fixed file - ready for commit to REL1_21
When logging into OpenID (At least with myopenid),
Notice: Undefined offset: 0 in extensions/OpenID/SpecialOpenIDLogin.body.php on line 524
Notice: Undefined offset: 0 in extensions/OpenID/SpecialOpenIDLogin.body.php on line 556
Notice: Undefined offset: 0 in extensions/OpenID/SpecialOpenIDLogin.body.php on line 556
This is caused by using a non-existent array key and shows up as an error.
I haven't checked the current head, but the attached patch fixes REL1_21
(Two files, one patch, one fixed REL1_21)
--------------------------
**Version**: master
**Severity**: normal
**Attached**: {F11326}",52430,-9,Needs Triage,True
-1.3456067339784326,2.4422609150256527,-3.603855012033476,-3.715973405691275,-3.617501281826126,-0.2216526193936097,-1.9363542179138253,-0.6586518551732415,0.4370948431321715,-1.620555077572806,-2.1777548726349227,0.3834868393381192,0.8728206742708182,-0.9546351045669752,-2.8944147708469528,-0.4975039647172149,0.18577863558237095,-0.37108093923183727,False,c2,1,"Selenium_user is now a Global account.
Because of that, login at test2.wikipedia.org redirects to login.wikipedia.org before returning to test2. This is ""SUL"" I believe.
This breaks our idea of what visit() and on() mean in term of pages for logged-in users, and all of the tests that require @login for test2wiki now fail.
I have disabled the test2 builds until we can resolve how to login both with SUL and without.
--------------------------
**Version**: wmf-deployment
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49708
https://bugzilla.wikimedia.org/show_bug.cgi?id=47843",52130,-10,Needs Triage,True
5.447329891068248,0.4819124103671708,12.666469368441668,-3.1876749017396766,-1.4262246622860815,-1.1381998283516177,4.592005103108488,-5.93015817528322,-2.242126740282923,0.7543457506993123,1.4528136798267997,-0.7819710589878102,-0.6849321072327115,0.26679602830428983,-0.9819439450348142,-2.11182892308347,1.2836417266890139,-1.9206199099315238,False,c2,1,"When I open
https://pt.wikipedia.org/wiki/Jorge_VI_do_Reino_Unido?veaction=edit
I see several warnings like this on Google Chrome:
The page at https://pt.wikipedia.org/wiki/Jorge_VI_do_Reino_Unido?veaction=edit displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Commons-logo.svg/22px-Commons-logo.svg.png.
--------------------------
**Version**: unspecified
**Severity**: normal",51984,-10,Needs Triage,True
3.832445746221899,-5.956163100357106,0.3989925688640099,4.940108526141354,-0.32547561206703934,1.8351082829770393,0.4804948543724539,-1.0530835539528967,-0.5588932864016511,-2.8485141566870755,-0.2557706661404846,-1.7182949885664465,-3.617765463613938,2.6345835101369897,0.5454962127584873,-1.1662247085235589,0.24765692088457092,0.9577444681679037,False,c2,1,"Having a http deep link to git.wikimedia.org gets not redirected to the https version.
http://git.wikimedia.org/summary/mediawiki%2Fextensions%2FVisualEditor.git -> 404
http://git.wikimedia.org/ -> https://git.wikimedia.org/
--------------------------
**Version**: wmf-deployment
**Severity**: normal",51827,-10,Needs Triage,True
-7.847330674667372,-1.4822687029656247,-5.892819534118557,-0.19251670871069693,-1.379661546665755,-1.6471002918874604,5.297134788996028,2.218554887156343,-3.743203461519445,0.48099055585892714,2.0422228499043693,2.9759545632754696,3.058632942327109,1.7054344084146642,0.8737053921231999,-1.873379184632873,0.7006887042938994,0.21188610603061364,False,c2,3,"Right now tools-login provide doxygen 1.8 but other nodes only doxygen 1.7
this is not the only inconsistency other packages may have different version as well, it seems that old nodes like tools-exec-01 are using different repository.
This should be somehow resolved, for example we need doxygen 1.8 but on exec nodes we have only 1.7, and what is ever worse I am afraid that some exec nodes provide 1.7 while others provide 1.8
if that is true for other packages too, this may have critical impact for certain jobs which expect same version to exist on all execution nodes
--------------------------
**Version**: unspecified
**Severity**: critical",58326,8,High,True
1.7068838673975644,-16.127433954373032,2.880769033622677,1.0046801632254487,-1.8306765007085601,1.9856589899702255,3.4701922060568178,-0.009616588664199677,4.614361197587154,1.614113416066739,1.3587143688455332,1.636351919186877,-0.21560079605811122,0.7760668550750589,-0.4317302644683094,0.5291458231143799,-0.549665146236134,-1.2678895792423819,False,c2,3,"see http://ganglia.wmflabs.org/latest/?c=tools&h=tools-webproxy&m=load_one&r=hour&s=by%20name&hc=4&mc=2
--------------------------
**Version**: unspecified
**Severity**: normal",58158,8,High,True
0.5624552028619454,5.8260391098559055,5.747296052981607,-0.9565100173174186,0.20185754023596147,0.013786673706254637,1.3004229607908053,1.050060964531228,-3.7529704894527596,1.0213171184174907,-1.5437140276057866,1.72868925957773,0.027562951056248508,2.5741417344055995,-0.797798163512085,-1.4190359818621638,-0.3702381910863479,0.3553488924076962,False,c2,3,"Introduced by 1c927b1df2a (Iab2bda1ebc). Turns out PHP expects the context scheme name to be ""http"" regardless of whether the actual protocol is HTTP or HTTPS. This breaks PHPHttpRequest for all HTTPS requests since it no longer sets the stream context properly.
--------------------------
**Version**: 1.22.0
**Severity**: normal",58047,8,High,False
-2.2171860796243865,3.406367185997947,-2.6856193562848514,-3.908204470886172,-3.9880037780292628,1.4017039726722083,-0.709357135578375,-0.8869276694222867,-1.18348296612228,-1.6936620004693563,-0.3691000536045954,0.3290923754975661,1.492200330926026,-1.6583321365386277,-0.4841410202047314,-1.0410586158710713,-0.31997811424942824,-0.21048392935434568,False,c2,3,"To replicate, go to https://m.mediawiki.org - with console open, you should see an error like:
[blocked] The page at https://m.mediawiki.org/wiki/MediaWiki ran insecure content from http://meta.m.wikimedia.org/wiki/Special:BannerRandom?uselang=en&sitename=M…roject=wikimedia&anonymous=false&bucket=1&country=US&device=android&slot=6.
I presume this makes it impossible to run CN banners on mobile devices for logged in users.
I chatted briefly with Matt Walker about this and it sounds like this is the result of how infrastructure is currently architected, though there may be an easy solution of forcing mobile URLs in CentralNotice using MobileContext::getMobileUrl() from MobileFrontend.
--------------------------
**Version**: master
**Severity**: normal",57860,7,High,False
-5.291936030098813,5.4853839067851915,1.485247831396201,0.8339681104060348,-2.8787815906212755,-3.0319335789909925,1.04750802086863,-1.4238791645137225,-0.5794367006202018,1.090249286603413,-1.1307164699115502,1.024820762710435,-0.13005460784678746,0.7404377356262106,-0.8351696358642338,1.9331910261359289,-0.35846818246148815,2.240010974564294,False,c2,3,"Now that $wgSecureLogin defaults to true for most WMF wikis, Special:UserLogin/signup redirects account creation to https. When it does so it drops all URL parameters to signup apart from returnto and returntoquery.
As a result, we're losing campaign information, and other control over login such as &showGettingStarted=false.
To reproduce:
Browse enwiki over http, visit a random page, click Edit, if the yellowish ""You are not logged in...."" anoneditwarning bar appears, then note the http: link for "" or create an account"" contains &campaign=anoneditwarning""
But when you click it, you are redirected to
https://en.wikipedia.org/w/index.php?title=Special:UserLogin/signup&returnto=Ectoedemia_sabina&returntoquery=&fromhttp=1
with no campaign parameter.
One fix is to test for campaign and add it back to the $query, in the execute() function in includes/specials/SpecialUserlogin.php. Or, include all query string parameters in the redirect URL.
--------------------------
**Version**: 1.22.0
**Severity**: normal",57761,6,High,True
1.1098866385770578,-8.60549001282775,0.0049664627221588376,2.18569010555349,-0.9490530294838604,-2.134940792110857,-0.958242413650833,0.5476937546813323,-0.5620302227350613,-2.4898930382703353,-1.1795030118770462,0.11541731071014838,1.4093175532818152,0.2782081683811537,-2.291699227089491,0.6932227646425639,-0.6674555137686248,-0.022691065966490287,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1657/
Reported by: valhallasw
Created on: 2013-08-22 15:14:10.237000
Subject: core hangs on killed http(s) connection
Original description:
Steps to reproduce:
>>> p = pywikibot.Page(pywikibot.getSite('nl', 'wikipedia'), 'Wikipedia')
>>> p.get()
# now kill the connection, e.g. using tcpview in windows
>>> p = pywikibot.Page(pywikibot.getSite('nl', 'wikipedia'), 'Wikipedia')
>>> p.get()
# hangs
Expected result:
pywikibot reconnects and executes the .get()
Actual result:
complete hang (deadlock?)
--------------------------
**Version**: core-(2.0)
**Severity**: major
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1657",57127,5,High,False
-7.50773632145423,0.49091937745328984,-0.6972837131956879,2.6269982456518433,-4.387758883952919,-1.3031181436020314,2.997058736369328,3.1571859160056053,-0.9577744873364116,-0.5029932407960969,-0.28907590067786515,-0.7983658221243534,0.509978125062085,-2.4509073514700295,-0.05673761206018746,1.3862978175108511,1.0326761339204464,0.7835242745387399,False,c2,3,"In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.
--------------------------
**Version**: unspecified
**Severity**: normal",56914,5,High,False
0.9934486542889842,3.4796794155781754,-1.6283414622007015,-6.997454017382717,4.257718309076104,-3.846125685974,0.4967725459014707,-2.6181227766825628,-3.5107149599961494,-2.024471081499353,0.5288499651105742,-3.2253924751859238,2.893123717089326,-0.4658587151640843,4.110320185658629,-1.0590622265917398,1.3152029013336788,1.2145542774810585,False,c2,3,"Forced secure connection...again...[edit]
Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)
Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)
I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)
I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)
--------------------------
**Version**: master
**Severity**: normal",56626,4,High,True
-1.9531579603560825,0.8292004598349791,-1.5067066864072167,-2.494565583492026,3.1237335798028822,-3.7702834919469668,0.6383353332959647,-1.5801454531588117,-2.3939817651710875,-0.07176072680011991,-0.9614784570030821,-0.007397155458758409,0.42088518024053867,-0.04217203054167129,-1.9292624677198051,1.1034198809375135,-0.9010435274516169,-0.35578596072281,True,c2,3,"Copying from https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574338454#Log-in.2FLog-out.2C_Skins_problem though this seems to cover two aspects:
Upper right corner: Cologne Blue skin not showing, notice appears ""CENTRAL LOGIN. You are centrally logged in as Carrite. Reload the page to apply your user settings."" Which doesn't work. Log-out fails. Ridiculous. 24.20.128.148
When I get this message, I wait a few seconds then hard-refresh the page
(it's Ctrl+F5 in Firefox). That usually fixes it. —Redrose64
I believe loading any page would apply settings, not just reloading
the previous one, but I may be wrong. —πr2
Small guess, the JS that does the login redressing only works for
Vector and Monobook. And it seems there is a problem that every time
you visit a http address while logged in over https, you get the
'central login, you are centrally logged in as' notification for
every page view. I'm seeing this as well right now. —TheDJ
--------------------------
**Version**: master
**Severity**: normal",56513,3,High,True
0.8002661608350272,-3.978876306097961,-4.586954182223515,-1.1245610745034644,0.6984474212665297,-0.8951113082951919,0.767454797816904,-4.164939205851588,-0.5860324706028304,0.7115767151650045,0.24118078624117611,-1.1894156837379795,0.9271160602799418,-1.1189904471125325,-0.8951059220673825,1.025956596466815,0.40867686029424655,-0.4038494230586591,True,c2,3,"This is weird, but reproducible. The *first* time you try to clone a repository in a directory with:
git clone https://git.wikimedia.org/git/mediawiki/extensions/SomeExtension.git
it fails with:
Cloning into 'SomeExtension'...
error: RPC failed; result=22, HTTP code = 405
fatal: The remote end hung up unexpectedly
The second time, it succeeds. I've reproduced it with multiple extensions (e.g. UploadWizard) on both Labs and my own machine.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: aklapper-moreinfo",56417,3,High,False
-1.9861285604325822,0.13690933579136555,2.7448525749868686,-0.8547620918707252,6.301350986048453,-0.754357093748514,1.366665239683729,2.219178074207433,-2.444166869411858,-1.5686992337860683,-0.38689503146701254,-0.4993587101541691,0.6312709471991989,-0.028335984699754846,-2.1689260082919204,-0.4493919484604545,-0.8677815183443568,0.7926191469816712,False,c2,3,"Requesting https://commons.wikimedia.org/wiki/User:CommonsDelinker/commands?action=edit often returns
HTTP 504: Gateway Timeout.
This does not happen when requesting the page with a high frequence but if you do it e.g. once an hour. Just look at https://commons.wikimedia.org/w/index.php?title=User:Rillke/CDC_mystery&action=history where I dump the profiling report of this page using https://commons.wikimedia.org/wiki/User:Rillke/profile.js -- about every third request fails.
Other users experience this issue as well:
https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard&oldid=104206956#Extremely_slow_performance_to_open_edit_interface_of_COM:CDC
If I remember correctly, this is an issue for a long time. Updating the page via API often works without any issues (but is slow). The page is regularly queried and updated by a bot: http://toolserver.org/~delinker/helper.txt
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53577
https://bugzilla.wikimedia.org/show_bug.cgi?id=49734",56122,2,High,False
1.6100535525994224,0.35198128012078556,-0.6256831625919492,-4.182524706130112,-2.2660400651478243,-2.970294022405736,-0.7478542033449909,0.05132305596375991,-1.6456924852421362,-0.9044153457985313,2.433837098127904,1.5204680822182814,1.645402142386517,-0.21194101016753653,0.7415788306918687,2.1111717453624683,1.1828378249190468,-0.6923236616066808,False,c2,3,"Steps I followed to reproduce:
1) Pick or produce an account registered on it.wikt (home), en.wikt, it.source, en.source; clear all cookies and start new incognito window on Chromium (27.0.1453.93 200836)
2) Visit ru.wikt
3) Login on it.wikt
4) Visit ru.wikt
I. Expected: I am logged in (account is autocreated).
II. Actual: Account is not created and I am not logged in. (Not bug 45578 comment 3 because I had visited the site.)
5) Visit en.wikt
III. Expected: I am logged in (account already exists).
IV. Actual: I am logged in.
6) Visit it.source
Same as III, IV.
7) Visit en.source
Same as III, IV.
In some previous test I was not logged in at step 7 (i.e. in other projects but same language subdomain, but not same project different language), I don't know what happen.
The messy situation at [[Special:CentralAuth/Bug 16864 test]] is due to bug 16864: if you sort by date you can spot the accounts autocreated by logging in on wikimania2013 and outreach (without any logic). I don't know how the various bugs are interacting here.
--------------------------
**Version**: master
**Severity**: major",56119,2,High,True
-1.9654390331416232,-1.5393231727879613,-3.364136238949138,0.6995116866203333,2.6089731184219027,-2.7348200095968918,-2.449120194591586,0.7256004596106668,-2.1193654215922013,-2.301357586702001,4.714213772429973,0.2291228442987412,-3.17027277551931,0.20782167740735602,-0.8439942017943824,-1.425194927144528,-0.5591691117430101,2.761650268872235,False,c2,3,"When requesting random images from Commons' MediaWiki API and requesting a thumbnail for it, I often get a HTTP 500.
For example:
GET http://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg
HTTP 500
<html><head><title>Error generating thumbnail</title></head>
<body>
<h1>Error generating thumbnail</h1>
<p>
Error creating thumbnail:
</p>
<!-- http://commons.wikimedia.org/w/thumb_handler.php/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg -->
<!-- mw1154 -->
</body>
</html>
Usually when trying again, it just works.
I've been getting these errors in many different environments:
* When reading articles and HiDPI plugin swaps the src attributes (the larger version would fail maybe)
* When opening the VisualEditor (rendering the new DOM means we re-parse the <img>tag and thus re-request it, thus making it more likely for the error to happen again)
* When working with gadgets that render image galleries through requesting file category members and the thumbnail url.
I don't think the scenario is relevant, there is either something wrong with the thumbnail generator script that is triggered by lots of images. Or there is a few faulty servers in the upload.wikimedia.org pool that cause the errors.
--------------------------
**Version**: wmf-deployment
**Severity**: critical",56045,2,High,True
9.171231303984614,-3.252934268233467,3.85694345396951,-0.6861987415223529,-4.119466754856658,1.967754114580431,-0.923504582329719,-0.3109721182216708,1.1287310310692873,-2.7453748700202563,-3.281360817186883,-1.7960899299337851,-0.11890343552577054,0.76215584502736,-0.22201587083372143,0.25603326882929356,-0.42158695791368594,0.30497731535416395,True,c2,3,"Mirroring RT #5011 in Bugzilla, for the sake of transparency.
https://gerrit.wikimedia.org/r/#/c/82879/
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://rt.wikimedia.org/Ticket/Display.html?id=5011",55959,1,High,True
-5.479424268941481,10.274225234323275,-0.682616618225385,0.22362032186207825,-2.107062691497119,-0.18664428436052327,2.0157543560254565,-0.670165419281744,-2.0287336637170053,-4.413022288453205,-5.237465407175696,0.4873671696511419,-3.376674967418565,-0.5742479818909638,1.3187243325820015,-2.4191900257219325,-0.5367364646445624,2.0002046877226576,False,c2,3,"To hopefully address the situation where users are reporting issues where they are logged in on some wikis, but not others, RobLa asked that we look into re-running the SUL logic after a user is logged in with the javascript ping.
--------------------------
**Version**: master
**Severity**: enhancement",55953,1,High,True
-7.600078678485891,-0.029653587433017492,-0.9179254980407396,0.7492739196567884,4.577785558938363,3.156035539441196,0.4741053213932691,4.771214288886634,0.5198320561454132,-1.420643609517426,-0.6748755691917365,0.8710628099026867,0.5288353100597356,0.9592939385961534,-0.7648687952553379,-0.014111801117093314,0.3451366435144616,-1.0198957319751316,False,c2,3,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.
Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",55905,1,High,False
3.8702515959004047,-2.8226320195173358,1.1595186845366428,-1.7225125529612137,-0.9416359199570044,-3.9315842446533527,2.7484707132043438,-1.4615551121276988,2.8508727287004216,-0.24659383213310182,0.6709991712226335,-1.5954847478221827,0.36447916224291754,0.9406238847001998,1.2742931264421857,4.313356016411662,-0.6781622187509697,0.4762760485209714,False,c2,3,"They should use own messages or we run into problems even in the source language, see e.g. Change-Id: I565971a90fc383327a51d717a80013cb7a3e9c9b
--------------------------
**Version**: 1.22.0
**Severity**: normal",55655,0,High,False
-3.8332184664117257,6.661283122720707,-2.5041633816767455,0.517620250215789,-2.5025686005200294,4.29231446245995,1.2407724962919042,1.2089317706024425,-5.041114354777703,-1.3347195939262204,0.5158314044078862,1.4666147647751957,1.5785095155745852,-0.5326494231736119,2.141570870586216,0.5845805903917469,0.9263724504016053,-1.2209909514357982,False,c2,3,"In the recent deployment of HTTPS the users who asked for being redirected to HTTPS are given global forceHTTPS cookies to be redirected to HTTPS on (theoretically) all wiki projects: Wikipedia, Wikisource, etc. In the current setup these global forceHTTPS cookies are set on global domains (.wikipedia.org, etc) but they are prefixed by the original wiki prefix (e.g. frwikiforceHTTPS) or by English-language prefixes (e.g. enwikisourceforceHTTPS), therefore the other language wikis are not redirected to HTTPS.
I guess that this is a bug since some languages (English) are redirected to HTTPS and the others are not, at least it is non-intuitive from a user point of view.
This bug is related to bug 53536 about the absence of removing of the global forceHTTPS cookies in the Wikimedia environment.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55538,0,High,True
-5.9921202323605955,2.105481573525566,-3.5817408974996443,-5.0544330873391115,1.5130148924395446,-3.4237395292605237,-1.2312228341719562,-2.3083617778620655,-0.6543584846074328,0.33687945716545986,-1.4770533885502524,-0.5207093916104133,0.512024720556338,0.5052144237275016,-2.4260893878173575,-0.3359834985644915,0.36484316792572424,0.4051926199293503,False,c2,2,"$wgSecureLogin is enabled on test2 wiki, so my logins redirect to https. The fix for bug 29898 is also on test2 wiki, so I have a preference ""Always use a secure connection when logged in"" which defaults to checked.
But if I uncheck this and save my preferences, I can't access the site over HTTP -- I still get redirected to https. It's very confusing. No matter what I do, accessing any page over HTTP redirects me to the https secure URL until I logout.
It's happening because my UserLogin sets $wgCookiePrefixforceHTTPS to true, and changing the preference does NOT clear this cookie. I have to logout, after logging back in (which redirects to secure page), I can then access other pages over http.
Changing the 'prefershttps' preference should clear the cookie, or the preference needs a warning/tooltip/explanation that ""This change will only take effect after you log out and log back in.""
--------------------------
**Version**: 1.22.0
**Severity**: major",55379,-1,High,True
-3.5865575195842467,-4.409474175356786,3.498155095187265,7.935531480650811,-1.9449995655574808,3.180888764522269,3.1620761231777026,-1.1816134730316348,1.1950578899504856,1.4483858441322077,2.1873942198044936,-0.6425838575298595,1.6481344082409781,2.3033735333693803,1.010892877097037,1.1028881679387845,-1.1121646246682007,-0.3911477177273326,False,c2,2,"Fatal error: Call to a member function formatDuration() on a non-object in /usr/local/apache/common-local/php-1.22wmf14/includes/specials/SpecialUserlogin.php
on line 818
Will grab a stack trace
--------------------------
**Version**: 1.22.0
**Severity**: normal",55246,-1,High,True
-6.661371839693489,7.3120074310362355,-2.5718587121821077,2.4118245937173257,2.857054777012985,1.0104873419456053,1.6994263843947186,4.080825611921929,-1.4238491477454043,-1.150442802783875,-1.3418130428572377,-0.09439925539016292,-0.7997823792576577,-0.14780403677975684,-0.6512596819965273,-0.24431007966679208,-1.4258730857359994,-0.5294806438364983,False,c2,2,"When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.
Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.
--------------------------
**Version**: unspecified
**Severity**: normal",55085,-2,High,True
5.376815685033096,-0.985666550720536,-0.9224453162820492,-1.4513660901189942,-1.415550407126793,-2.004397491249028,1.7226988275565693,0.925564642449212,-1.2454678201105427,-2.559952407540148,-2.621297365938878,0.22692134794821994,-0.527155666037407,-2.7428088999410405,1.8171963113313536,0.6819068198256075,0.7591416400784528,0.02564126094484176,False,c2,2,"**Author:** `popeno2003`
**Description:**
As was declared here:
https://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/
and also said in Wikimania, wikimedia Websites are going to be HTTPS by default from 21 Aug.
Wikimedia Websites are not accessible in Iran through HTTPS and Ryan Lane told me that there would be an exception for fa* websites which are mostly edited and used in Iran.
After discussion with community, there were also another languages that are mostly used in Iran and wanted the same exception, I hereby enlist them here:
fa*
cbk*
mzn*
glk*
ku*
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: https1308
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53144
https://bugzilla.wikimedia.org/show_bug.cgi?id=53739",54846,-2,High,True
-7.638419908536225,4.859929557955805,-2.9232108052449384,0.5013940020305758,-1.0986461815385518,1.4860849327069643,-1.471437375576512,-0.1820205665169059,0.7629807952329688,-0.5493515661338257,-1.2642704689843791,1.110779120609579,0.30731042838436506,-0.4469922224033107,-0.9775616918577805,0.20521428591406127,0.8436523447830477,-1.280030967320383,False,c2,2,"Not sure if maybe Wikimedia/Site requests would be the appropiate place.
When an user account is blocked on a private wiki that has the 'wgBlockDisablesLogin' in the config, the blocked user should not continue to receive email notifications about pages changed on his watchlist. This is happening to me.
Blocked users on 'wgBlockDisablesLogin'-wikis won't be able to login and check the change made, and there's the posibility that private data may be leaked in the edit summary (data that the user is not suposed to access anymore).
Since blocking on those private wikis such as <http://noc.wikimedia.org/conf/highlight.php?file=private.dblist> (& I'm speaking for those that I know: CU and steward wikis) is not used as a way to prevent abuse, but as a tool to remove someone's access to the wiki, it makes sense IMHO to disable from blocked users the ability to continue to receive email notifications. I guess that that is the primary use of the tool in all of the other ones.
Thanks.
--------------------------
**Version**: 1.22.0
**Severity**: normal",54453,-4,High,False
1.904622781038103,-2.823242938164112,-1.070622167322929,1.7797834002980735,2.2920898839999935,2.373240604781201,3.9350267843570803,1.256804971404541,-1.6009678926211257,-2.690490669842166,-4.195599638304224,0.9661991486979764,-3.7587905910961394,1.646640580328631,0.11509212962682724,-0.868729919138705,1.297397362222368,0.6166567507178595,False,c2,1,"**Author:** `swalling`
**Description:**
Since virtually all modern browsers on desktop and mobile indicate to the user when a connection is HTTPS or not, these icons are redundant.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",54282,-5,High,False
3.299793376639792,0.15016482144127608,4.209785593381934,-5.876053683605372,0.5205334724044024,3.9937843636007457,1.8001648085470014,-1.9667710588358442,-0.35475994917778286,2.496505308791349,4.440372600587731,1.814864883001851,2.7285397191267657,-2.6008590673868373,0.729201880500618,-1.2901774583708239,-1.118127867382579,-1.928573861569509,False,c2,1,"While logging into English Wikipedia on Chrome, I was sent to
http://wikimediafoundation.org/wiki/Special:CentralLogin/start?token=<token>
(I can provide the token if it is helpful)
which is an error page:
No such special page
You have requested an invalid special page.
A list of valid special pages can be found at Special pages.
Return to Home.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53498
https://bugzilla.wikimedia.org/show_bug.cgi?id=54195",54206,-5,High,True
-1.4664042855373651,0.7000605003811469,5.932218425847477,0.6043600267749543,-3.6784740211490186,3.407385463977235,-2.5183562434386895,0.7122462839106943,-0.5274640577289561,2.0974123459483174,-1.3434820389378201,-0.9798984934241765,1.3958911574836068,-0.8291036409636545,1.7280877350663353,1.7823565805648152,-2.099758811320383,0.7617272916358593,False,c2,1,"As of 24 July, attempts to login all result in an error ""Login error
There was an unexpected error logging in. Please try again...""
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page
--------------------------
**Version**: unspecified
**Severity**: major",53988,-5,High,True
8.702054066501251,-8.492268306583277,4.676476329283613,1.9346336263200068,0.06609293728030641,-0.0640051403469093,2.0309231852103222,-0.1880714699575225,-3.5286416289371054,-0.7122207607799558,0.4143861085367866,3.6776578324864895,3.1112846083038335,-0.35049949154092186,1.453320582311762,-0.05506503285863412,1.586835763651831,0.3662551843309265,False,c2,1,"https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#IP_editor_in_ur_base_killin_ur_d00dz
https://en.wikipedia.org/wiki/Special:Contributions/208.80.154.75
https://en.wikipedia.org/wiki/Special:Contributions/208.80.154.76
These are ssl1005 & ssl1006. Edits from 23 July (today). Similar bug 48919 has been resolved.
--------------------------
**Version**: unspecified
**Severity**: normal",53862,-6,High,True
-5.274323042188776,6.569268550152469,-8.094066802173822,-7.697202756371152,-1.250638182563005,-2.607470169640945,0.1295181415386759,-2.7819089476373122,-0.12299615078653073,-0.8167366641597216,-0.44975055977156453,-1.1060014065604307,0.7219767261489811,-1.1062464515713324,-0.29465230284283983,2.034144996820131,-1.6689966885597833,-1.1259931410357396,False,c2,1,"When a user logs in, and they have checked ""Keep me logged in"", and they have a global user, the centralauth_Token cookie is only set for the wiki where they are logging in. It is not set for loginwiki, or any of the other SUL wikis.
So the user will be logged out of all the other SUL wikis except the one where they logged in, if they close their browser and then return.
I think we should also set it on loginwiki, so that they will be logged in centrally for 30 days. Other attached wikis can rely on the login check to log them in.
--------------------------
**Version**: unspecified
**Severity**: normal",53644,-6,High,True
0.528522294966967,-4.975318157770831,-5.303827615883929,1.4991546826125668,-1.9431471885398042,-2.1281684851572367,-0.3745563507128882,0.6336646876147732,-1.4413828236999888,-0.11084699072229665,-2.717674786844091,-0.07162684759946569,0.761421899214862,-0.5195093656186689,-0.7880323720118749,0.8541119267973168,0.02921635010266832,-0.06806069485906119,False,c2,1,"**Author:** `p.selitskas`
**Description:**
Dash-to-underscore conversion is frucked up yet again?
When ""Edit"" is clicked, an API request is issued with params:
action:visualeditor
paction:parse
page:Новая_зямля
oldid:1630719
token:[screened]
format:json
Response: {""servedby"":""mw1141"",""error"":{""code"":""parsoidserver-http-bad-status"",""info"":""404""}}
VE works at be.wikipedia.org, but it doesn't work at be-x-old.wikipedia.org, bat-smg.wikipedia.org, and maybe other sites with dash in the site ID.
--------------------------
**Version**: unspecified
**Severity**: major",52173,-10,High,True
0.015439573800745343,3.3261635171225628,21.123906493272145,6.551984134204829,-2.7192391717711963,-4.472862489682279,2.6306160119136726,-3.180048924397595,-0.9919127166887396,-1.0378940121824676,-1.1256214415897845,0.29620891439807795,-0.7493423676880129,-1.9084398086660794,0.9391845237651575,-2.280539505021688,1.0432018922275332,-1.2756194634593856,False,c2,1,"https://en.wikipedia.org/wiki/Jeffrey_Chiesa?veaction=edit
When I go here currently, I get HTTPS warnings.
---
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/New_Jersey_Attorne…effrey_S_Chiesa.jpg/144px-New_Jersey_Attorney_General_Jeffrey_S_Chiesa.jpg.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/f/f0/Seal_of_the_United_States_Senate.svg/80px-Seal_of_the_United_States_Senate.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/Seal_of_New_Jersey.svg/90px-Seal_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Flag_of_New_Jersey.svg/75px-Flag_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/New_Jersey_Attorne…effrey_S_Chiesa.jpg/144px-New_Jersey_Attorney_General_Jeffrey_S_Chiesa.jpg.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/f/f0/Seal_of_the_United_States_Senate.svg/80px-Seal_of_the_United_States_Senate.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/Seal_of_New_Jersey.svg/90px-Seal_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
The page at https://en.wikipedia.org/wiki/Jeffrey_Chiesa displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Flag_of_New_Jersey.svg/75px-Flag_of_New_Jersey.svg.png.
Jeffrey_Chiesa:1
---
action=view is fine (no console warnings). When I go to veaction=edit, the console fills with warnings. It looks like VisualEditor is loading thumbnails unconditionally through HTTP. This should be changed to be protocol-relative.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/wiki/Jeffrey_Chiesa?veaction=edit",51283,-12,High,True
6.7253463952237915,-10.58911897661526,-2.3277912162059273,10.556024373423126,-1.7017903998689443,-4.10853172783968,-0.12279242245843225,-2.16754274588067,-0.39816370693752323,6.837121788358948,-3.0619042062820974,-0.36870525233336837,-3.688444322255026,-0.2312081734379987,1.6538019350086515,-0.9696339580236968,-0.9412563844193048,0.41300081239203856,False,c2,1,"curl --data ""action=login&lgname=User1&lgpassword=xxx&format=json&callback=foo"" 'http://localhost/wiki/api.php'
foo({""login"":{""result"":""NeedToken"",""token"":""317d0a5134f80898af6c619115293e1f"",""cookieprefix"":""wiki_test1"",""sessionid"":""p7sgh8o7h2ltsi5635mh19h6c2pg7me2pekaee84kdq3k68gr1l0""}})
--------------------------
**Version**: unspecified
**Severity**: normal",51090,-13,High,True
21.177224509325125,1.1540217417630547,0.5446919108362671,-0.3899967638266788,2.2208506723558585,0.789124369180612,-5.114758659097686,-1.0530849821391666,-2.864151391391614,-4.201177370436637,-0.8974013283565099,2.4877998556130807,6.282857217758968,0.5335404637180545,1.0869698230976956,0.6433150131535303,-0.6493443068730742,-2.05623257343854,False,c2,3,"%%%gurvin 1H IN A 208.80.152.20%%%
%%%gurvin is a Wikimedia ISSLPv6 Proxy (ipv6proxy).%%%
%%%gurvin is a Wikimedia SSL Proxy (sslproxy).%%%
%%%Linux gurvin 2.6.32-47-server #109-Ubuntu SMP Tue May 7 02:17:05 UTC 2013%%%
%%%x86_64 GNU/Linux%%%
%%%Ubuntu 10.04.4 LTS%%%
%%%this is Tampa, needs to go%%%
**Referred To By:**
{T83156}
{T83191}
{T84665}",83211,9,Medium,False
-2.5753315084633157,-1.5251963005317588,-9.555561696142401,-0.4285088125729706,-3.0114670349462154,-1.1778479527613401,-0.7194648137657653,2.7688856383415814,0.9869599064457435,-1.3213753712334797,0.5201070565591079,0.2081300339939458,4.592383448360919,-3.1744019647948036,0.41677074205256304,0.034421968150527615,-0.709986181042287,-2.723040172179794,False,c2,2,"%%%login.wikimedia.org should be moved to its own IP address, so that if content%%%
%%%appears on some other wikimedia-lb site (such as meta.wikimedia.org) which is%%%
%%%offensive to government censors, only wikimedia-lb will be blocked, and login%%%
%%%to unrelated projects will continue to be possible.%%%
%%%Also, given the continued failure to implement IPSec (RT #3536), the%%%
%%%login.wikimedia.org IP address should not be geographical, rather it should%%%
%%%point directly to the active backend datacentre.%%%
",82877,-1,Medium,False
6.524286992446125,-2.6466808868496035,-3.7508812513945156,-2.038122632014045,-2.329003597927403,1.1117942555555766,-6.050201782665526,0.5192007105069631,-0.68802872834384,4.656682741802072,-5.6753346615626485,0.8343264312227714,-0.6224294982717131,-0.8782929064250409,-0.21960210870104913,-0.19264130865564255,1.7651592462501589,-1.839271366031864,False,c2,3,"User signup during wikimedia installation -> Field is 'Real Name'
While installing medaiawiki 1.21.2, in the sign up Page, The Feild 'Real Name' value is taken up by the Mediawiki server as 'username' and is used to login after the installation.
The feild 'Real Name' should be changed to 'username' during installation step.e
--------------------------
**Version**: 1.21.x
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56551
**Attached**: {F11933}",58235,8,Medium,True
-1.7469035857907698,4.3505041987210475,2.528639471098849,-1.6057916854466847,-0.8260764246449666,-0.7362837491389124,-5.246195554456012,1.608459798695153,2.308992118730063,1.966854797273239,-1.6681858774157565,1.8900791384003666,-1.4318483720451924,-0.5186364735291669,0.4562101144909416,3.661894716685825,-1.9486786343273539,0.5793051030974044,True,c2,3,"On https://en.m.wikipedia.org/wiki/Special:UserLogin and https://en.wikipedia.org/wiki/Special:UserLogin
When a user is logged in we should add a greeting above the login fields that says
""Hello, $username!"" to show the user they are already logged in.
The [Sign in] in button should say [Switch Account] and create account should say ""log out""
--------------------------
**Version**: unspecified
**Severity**: normal",58023,7,Medium,False
3.5733961750626153,-4.088705314230678,-2.1420643244745587,0.03254564648845393,1.2818369346475906,-0.3653644251931165,-1.6533203495910174,-1.0936621078104714,-0.7936812558744107,-2.1088365410909944,1.0751908346397,-1.0880581708431951,1.9973048769338835,-0.46641434782934876,-0.026193818164038873,-0.25747484281530864,-0.35967241365984726,0.3269424199633304,False,c2,3,"**Author:** `kudu`
**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki
Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).
I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.
Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).
--------------------------
**Version**: master
**Severity**: major
**Attached**: {F12201}",57978,7,Medium,True
-0.25403651155549767,-6.066841296452155,-2.118056969670196,-2.7543850616923677,-0.3560359897797273,-0.9026158152804008,-0.711123703509676,-1.550067115639131,-3.816077329503111,-3.2199971893261665,-2.3388640975815997,2.736249009697673,-1.567870706895362,-2.066456758029247,-0.24749076995962493,-2.1882568671025027,0.08682296156589975,-0.5322045617440254,False,c2,3,"```lang=bash
<~/pywikibot>git clone --recursive ssh://multichill@gerrit.wikimedia.org:29418/pywikibot/core.git
Cloning into 'core'...
Warning: Permanently added the RSA host key for IP address '[208.80.154.81]:29418' to the list of known hosts.
Enter passphrase for key 'key':
remote: Counting objects: 10842, done
remote: Finding sources: 100% (10842/10842)
remote: Getting sizes: 100% (1495/1495)
remote: Compressing objects: 100% (2292733/2292733)
remote: Total 10842 (delta 7190), reused 10548 (delta 7165)
Receiving objects: 100% (10842/10842), 23.42 MiB | 326 KiB/s, done.
Resolving deltas: 100% (7337/7337), done.
Submodule 'externals/httplib2' (https://gerrit.wikimedia.org/r/p/pywikibot/externals/httplib2.git) registered for path 'externals/httplib2'
Submodule 'i18n' (https://gerrit.wikimedia.org/r/p/pywikibot/i18n.git) registered for path 'scripts/i18n'
Cloning into 'externals/httplib2'...
error: SSL certificate problem: self signed certificate in certificate chain while accessing https://gerrit.wikimedia.org/r/p/pywikibot/externals/httplib2.git/info/refs?service=git-upload-pack
fatal: HTTP request failed
Clone of 'https://gerrit.wikimedia.org/r/p/pywikibot/externals/httplib2.git' into submodule path 'externals/httplib2' failed
```
I'm cloning over ssh. Why are the submodules being loaded over https?
--------------------------
**Version**: core-(2.0)
**Severity**: normal",57654,6,Medium,False
-2.865304251686181,-6.253991580425513,0.9681674523562016,8.231532176549,8.296476189997486,0.6564815436040934,0.05067791326094717,0.12548747025459833,8.55429207063551,-1.7491053409020072,-4.395684339645955,1.6099323982163274,-4.864626268207513,4.60145339591104,0.394079243022162,2.2051878854780345,3.6140349283953848,0.33373622906754163,False,c2,3,"Add the login help page, so the login form doesn't have a redlink
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",57425,5,Medium,False
-4.359812713616321,0.6256654750012025,2.475523103954263,-2.349641708753558,3.3217750841467355,-0.3667769710630261,1.1979939160694437,-1.7321366117596875,-0.9507705737260869,-2.3013053410642743,-1.6496628391975015,3.8406962680315697,-0.21245090521898646,1.7198038890008283,3.269738715506622,0.7740267799287512,0.6462658269632715,-0.5694668288510958,False,c2,3,"Hi
When I run parsoid linked to a wiki which is https only, it doesn't work. This can be reproduced in any installation.
I set port 80 to be a redirect to port 443, and the parsoid URL is https://wiki.name/api.php in localsettings.js
--------------------------
**Version**: unspecified
**Severity**: enhancement",57369,5,Medium,False
-5.068726435531736,0.3290396531216242,-0.39512935793746173,-3.4616756024411077,0.9054074338869063,1.3706837764652213,2.169874144057034,0.9162788649945403,-1.6332559275400096,-0.1832366834132264,1.411469149769514,3.7823028908335843,1.8326583675603767,-2.5530903495737918,2.6900249749373915,-3.3417350850892,-1.5006439304405488,1.0677087772866167,True,c2,3,"UDP logging for search is currently disabled. However, it would be good to be able to track the main errors. An example of one that seems important (which I was receiving earlier tonight) is:
An error has occurred while searching: HTTP request timed out
--------------------------
**Version**: unspecified
**Severity**: normal",56865,5,Medium,False
4.622046395222393,-3.2660977876874604,-1.8015324825382635,-1.9020543445503733,5.6782175713734535,4.01069704510894,1.515973978995489,-2.5254530396959094,2.043094731754227,-1.266513881985567,-0.5520960093982326,0.060437259479589445,-1.4208023666726755,0.026282668034768975,1.157293228810322,-1.443002331104299,-0.2820244312584248,0.9231763218573248,False,c2,3,"https://login.wikimedia.org/wiki/Special:CentralAutoLogin/deleteCookies?type=icon - this is using a Wikipedia logo currently. Can we use a Wikimedia logo at least?
--------------------------
**Version**: wmf-deployment
**Severity**: normal",56500,3,Medium,True
-0.8979465878542623,3.5765569326227045,1.9779321217206771,-1.906478673432221,3.3856040179966307,5.572757893202964,2.1463886591093564,2.5989752966128936,-3.4497219648317357,1.1816498703543719,2.4473291474714443,-2.0724055739552742,0.12559331801577844,-0.3125761300218617,-1.443966222115404,0.6892889846727382,0.3204187889451995,2.4592703985843727,False,c2,3,"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.
When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.
--------------------------
**Version**: unspecified
**Severity**: normal",56468,3,Medium,False
-4.167328230963918,0.944343477792021,-5.630487697311558,-0.8803020005168496,1.359375993994989,0.24511353675931735,-0.389265194205751,-0.14638895592031315,1.1340773068275252,-1.582339299295096,-0.504141325138912,-3.750247953230229,1.2466857937154354,-4.27745526508747,1.2417453375363117,-1.2231615468608537,0.6534709318782259,-0.7576825795156059,False,c2,3,"DGarry (WMF) was hitting a bug today where he logged into enwiki, and SUL logged him into most of the other projects. But, his account wasn't attached on commons, and so that autologin attempt failed, with an error in the header saying the user didn't have an attached account.
When he logged in directly on commons, the account was autocreated correctly.
We should be autocreating the accounts, like used to happen with the old AutoLogin.
--------------------------
**Version**: master
**Severity**: normal",56292,3,Medium,True
13.054734696180482,3.0837791021550203,1.3320643122994653,-0.9438489257033892,-0.17184314314658505,-3.523041333807191,0.08135373174360883,0.06572028615122094,-1.7311418650357435,-0.4644955102143138,-0.5340728036253015,1.6736719792419084,2.211244109179715,1.1632078722769688,-0.03036287341394317,-0.14505613112219484,0.05677568059303262,-0.7103506020349375,False,c2,3,"Ops pointed out that almost 60% of the apache traffic is calls to Special:CentralAutoLogin. About half of that traffic is to /start, so it looks like Special:CentralAutoLogin/start is still not cached, even though we don't disable client caching in the output page. MediaWiki is sending Cache-Control private.
csteipp@linux-hv06:~> curl -Ik 'https://en.wikipedia.org/wiki/index.php?title=Special:CentralAutoLogin/start&type=script&returnto=One&returntoquery=' | grep Cache-Control
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
It seems like that is because OutputPage checks to see if $this->mSquidMaxage != 0, otherwise it sends out the private header. On my dev system, I added $this->getOutput()->setSquidMaxage( 3600 ), and I then get
csteipp@linux-hv06:~> curl -Ik 'https://127.0.0.1/wiki_port83/de/index.php?title=Special:CentralAutoLogin/start&type=script&returnto=One&returntoquery='
HTTP/1.1 302 Found
Date: Mon, 16 Sep 2013 23:32:21 GMT
Server: Apache/2.2.22 (Linux/SUSE)
X-Powered-By: PHP/5.3.17
X-Content-Type-Options: nosniff
P3P: CP=""This is not a P3P policy! See http://127.0.0.1/wiki_port83/de/index.php?title=Special:CentralAutoLogin/P3P for more info.""
Vary: Accept-Encoding,Cookie
Cache-Control: s-maxage=3600, must-revalidate, max-age=0
Location: https://127.0.0.1/wiki_port83/pool/index.php?title=Special:CentralAutoLogin/checkLoggedIn&wikiid=dewiki83&proto=https&type=script&returnto=One&returntoquery=
Content-Type: text/html; charset=utf-8
Is that enough to have varnish cache these, but logged in users will always bypass the cache?
--------------------------
**Version**: master
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52206",56195,2,Medium,False
-6.200682750557084,-1.0642495207295166,-7.097534131465682,-4.3251966760965495,-0.605851593011476,-1.8827537198321722,-0.7630753677906474,-4.611348945173739,0.5448260993004413,-1.0875367508240146,0.5171354092090041,-0.3164396663643594,0.5302886729056668,-1.3374876609029456,1.2585825679819171,-0.09036695190238136,-0.7939520589276176,1.6412145623419432,False,c2,3,"helplogin-url is shown in a very prominent place by default and it should point to an existing page to avoid confusing users with links to nonexisting pages, similarly to bug 53862.
We have [[mw:Help:Logging in]], which given the author I assume ok and that can be made translatable when we are comfortable about the quality of its content (it had some ""manual"" translations on Meta). Linking it will help improve it, but it's already better than the default red link.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",55888,1,Medium,False
-1.6077650622670598,-3.459691089579769,-5.4906653210246095,0.08571723391036334,-3.7363627571373454,-1.4715819968040733,-2.769550925680437,0.3553257151193262,0.12037584830684195,5.03481492231316,0.8803471673838832,-0.9738061309988235,-0.8339293660663234,-1.1814720742638545,1.0165644732199217,-0.20522051562739818,0.6794467398570851,-1.55862465908042,False,c2,3,"**Author:** `Thehelpfulonewiki`
**Description:**
In bug 23231 a number of private wikis had wgBlockDisablesLogin set as true. Since then we've had some more private wikis created (such as IEGCom Wiki, Transition Team wiki etc). Instead of requesting this setting to be set on a individual wiki basis, can we just set it to be true for all private wikis? i.e. Add
'private' => 'true',
to 'wgBlockDisablesLogin' => array(
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55871,1,Medium,True
1.7091669180379765,4.093808428017944,5.60778252466773,-3.521892619463279,-3.1895573581493686,1.8618182240773733,0.32038169637933755,-1.0564829488277705,6.064437748558805,0.05255540689556515,0.3122027521480608,0.705044019359492,-0.6259484314042156,1.2806133141222835,0.09765378101648281,-0.3014428910524658,-0.6779130339047192,-1.98318446772248,False,c2,3,"With the recent move to push HTTPS, it makes sense to also link to the HTTPS version of diffs in the Recent Changes IRC feed.
To consider:
Bots that read those feeds might expect HTTP. Can we notify bot operators somehow?
--------------------------
**Version**: unspecified
**Severity**: enhancement",55526,0,Medium,False
-5.187312971179929,1.3303676898351746,-1.7641963623143866,0.7887543803924275,1.8028071649225965,0.29678340521217317,1.946048341713566,3.784557424547616,-0.4464587115082821,-0.15953971558422264,1.695950197312245,-0.4503980659750053,0.4908016199696883,-0.29949416641103976,-0.2525194072426844,-0.2538485072022283,-2.2626415345886715,0.057190015074984,False,c2,2,"[[Special:UserLogin]] is missing a link to signup form when user is logged in. This appears to be the intended behavior (per LoginForm#showCreateOrLoginLink), but is rather annoying when a logged-in user wants to create another account.
This is rarely useful on Wikimedia wikis, which have a very open model (although even there sometimes it's useful to e.g. create account for user using banner IP range), but some third-party wikis use a more closed model where only site admins can create accounts – for them it's an important regression, as the previous form always had the link.
(As reported on #mediawiki a few minutes ago.)
--------------------------
**Version**: 1.22.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53447
https://bugzilla.wikimedia.org/show_bug.cgi?id=56854",55306,-1,Medium,True
-1.1091764039917305,0.693943667377539,-1.5933687816418995,1.5676927858171683,-0.3851930123032592,2.3289257021498555,6.835622014198372,3.7688973142752866,-3.9985248287146575,3.686007799567493,7.884409569356688,-3.36317366570284,1.0744799472192512,0.17431076606625862,0.6361834447568961,-2.3812749263912867,2.9939395737891576,0.5372446767791981,False,c2,2,"**Author:** `michael+wmbugs`
**Description:**
~~Forward Secrecy capable ciphers are not currently available on wikipedia.org. The only ciphers available on wikipedia.org are:~~
^ Original assertion no long true, but this ticket is now tracking progress on all of our many other sites, aside from the primary wikis.",55259,-1,Medium,False
-1.3914910232258575,0.33885300850790756,1.1570235077465725,2.8605047148739433,1.031505851566824,0.3958866058031494,-2.1822665837329045,0.6671292350014141,0.47664214238806824,-0.8690406219124083,0.7446379595300745,1.8772178679653353,1.3102269354526799,-2.3478152138495307,-1.7557856973008525,0.15733620790593694,-1.0152651441317762,0.4858429219178182,False,c2,2,"**Steps to reproduce**
* Create an account
* Log in to [[https://en.wikipedia.org|en.wikipedia.org]]. Might need to select ""keep me logged in"" type settings to set the central auth cookies on loginwiki.
* Visit a wiki on a different second-level domain, such as [[https://en.wikiquote.org|en.wikiquote.org]].
**What happens?**:
* Ping and notice icons are replaced with text like `Alert (0)`. Sometimes the icon styling is missing:
{F11729}
sometimes it is repeated:
{F35784175}
A page refresh fixes the issue.
**What should have happened instead?**:
* Ping and notice icons are normal on first page load. No refresh needed.
{F35784182}
**Other information**
* HTML looks identical.
{F35784192}
* Possible CSS issue. The following appears to be present in the working example and missing in the non working example.
{F35784189}
* Caused by CentralAuth autologin (sometimes) replacing the user toolbar without reloading the page, see `modules/inline/autologin.js`
* That script calls the `centralauth-p-personal-reset` JS hook, which is probably the right place to fix this",55134,-2,Medium,False
-1.5617819040015928,-0.6356190747575727,1.5918511972681806,-1.752177237788608,-1.8953492093295239,-0.2161803599473785,1.0789387157825665,0.1264853217662565,-0.05465743062506051,-0.7783741687960632,0.3889040829636934,0.1391091245789191,2.041005624276001,0.06298776987055721,1.753492686008741,2.8446731579806963,-0.7578773760892057,-0.4038928994315405,False,c2,2,"multiple reports coming in via IRC.
The banner can be hiden on one page, but as soon as another page is opened, it reappears.
I can confirm this on enwiki.
The notice in question (generic maintenance one):
https://meta.wikimedia.org/wiki/CentralNotice/Generic_maintenance_notice
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=17108",55116,-2,Medium,True
5.886849469268995,0.5925480485232981,2.1662355899964574,-1.7596129627411157,-2.712637725187373,-1.0683041710078578,0.9886705241403586,-0.8202485762883654,1.4166332778149615,-0.924705292584671,-0.5797853537698794,0.9527740552235155,0.49064849351152784,0.200105307170797,-0.9963923879119534,0.48308001592181327,-0.15356612602996478,-0.5286445959817654,True,c2,2,"From Nemo at bug 43172:
> Thanks Krenair and MatmaRex. The worst offender for this bug is the title of
> Special:UserLogin/signup, MediaWiki:Createaccount .
> It was originally only the title of the special page, but got recently abused
> as link label from the personal toolbar of unregistered users; the result is
> that e.g. in Italian it says ""Register"" to satisfy the new usecase and is no
> longer ok as title for the special page. The two messages should be
> separated.
This can be fixed by making the register personal tools message separate (e.g. pt-createaccount).
Nemo, do you think it makes sense to also do this for login and logout?
--------------------------
**Version**: unspecified
**Severity**: enhancement",54861,-2,Medium,False
-1.288623209255906,-1.2763604462686864,3.029580922669737,-2.5896495465448988,-5.0214480688084535,-1.3133155537739978,-0.8004407290532001,1.2164448046697638,2.4380329878963183,-2.7747395048892867,-2.109701559891619,-2.898397326196462,-2.5608180014422866,0.6827011085667607,-0.9308413888327332,-1.717680251070485,-1.617803501629097,-0.16057046786279416,False,c2,2,"When going over https://wikidata.org to wikidata.org, you will end up on a http page, not on requested https.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://rt.wikimedia.org/Ticket/Display.html?id=5666",54698,-3,Medium,True
8.65527900207531,-12.04575367800129,-0.667385042119669,1.8396285332021693,-0.3646396395933481,1.5906854239618589,4.113583674468074,-0.957316491920977,-1.0604827349803176,0.03096892319900757,-0.16322419616858852,2.2198988920408853,-0.5576602065196665,-1.2034631282670643,-0.22288313917512959,-1.3027860941981382,-0.3952126239021838,1.5096986360551268,False,c2,2,"**Author:** `rlane32`
**Description:**
Cert chain is missing intermediate cert.
--------------------------
**Version**: unspecified
**Severity**: major",54630,-3,Medium,False
3.8285800034731534,-10.72677250073259,-1.5086638522016624,6.961345621192727,-1.1184990618594775,-2.7785077405701655,0.9154106939922979,-0.17047540084597457,-0.07774453682436863,1.706285469552264,2.130866848066202,-0.2851062345419959,1.0454421555624083,-1.2639322156631616,-1.0948737576835805,-0.10026608584529911,-0.41164379983758304,-1.1418211685964175,False,c2,2,"http://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin
PHP fatal error in /data/project/apache/common-local/php-master/includes/AutoLoader.php line 1158:
require() [<a href='function.require'>function.require</a>]: Failed opening required '/data/project/apache/common-local/php-master/extensions/Translate/specials/SpecialManageGroups.php' (include_path='/data/project/apache/common-local/php-master/extensions/TimedMediaHandler/handlers/OggHandler/PEAR/File_Ogg:/usr/local/apache/common-local/php-master:/usr/local/lib/php:/usr/share/php')
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52316",54534,-4,Medium,True
-5.171176524604051,3.015892544439705,2.402362271299772,5.509806835412822,1.0247248477909203,1.28734605929228,1.4295102784288227,1.9453768223044308,2.391117656097152,-0.33210472801123636,0.3360019905108915,-1.5487926814619817,0.4337710339298737,-1.056069221330863,1.180589225991132,1.21167519924018,-1.118049191898593,-1.7471202716305618,False,c2,2,"I just learned - after having asked in the chats, that the Mobile Android App uses only https . This was not apparent, and should perhaps be mentioned somewhere.
Suggestion
==========
This bugzilla has the aim to add a new entry in the settings with which the fingerprint (as md5, sha-1, sha-256) of the connected server's certificate can be shown on the device.
Of course, the foundation server(s) should have a page entry, where the certificate fingerprints can be cross-checked.
See code for a tiny certificate viewer in PHP https://github.com/Wikinaut/MySimpleCertViewer perhaps useful as a starting point to bake your own viewer in Java.
--------------------------
**Version**: Unspecified
**Severity**: enhancement",54506,-4,Medium,True
-4.423148236859073,-1.5314482849356938,-2.6490779620381772,-3.1052161473077833,2.492870137348257,-2.1731541291735192,-1.809148020196715,-1.536921022764064,-1.700721750011315,0.5146876134050746,-1.9194026195969502,-0.8837727708586942,1.3888868952849154,1.244476544607772,-0.7464403384833513,0.14079890131997655,0.16331972761423108,-1.1890343960588465,False,c2,1,"In the User profile options in the preferences, we have the checkbox: ""Remember my login on this browser (for a maximum of 30 days)""
Why ? Does anyone use that ? What's wrong with checkbox on the Login page ? Is it just that we don't persist the 'last' choice on the login page ?
Seems rather overkill to me, definitely clutters the preferences and possibly it is confusing to users ?
--------------------------
**Version**: 1.23.0
**Severity**: normal
**See Also**: {T69133}",54342,-4,Medium,False
1.9228581673849834,0.5823369534633027,0.4197251825564585,0.6956494112728777,-4.610233815510735,-3.6727792486796798,0.4365058814418932,1.8785552201791642,-1.0504639509248266,1.4718787190507285,-1.4496155268046116,-2.082562420251589,1.5348626157356833,-2.9430741652389925,1.4880472012405388,-1.0711808436854533,0.4787327061778959,0.514135311152468,False,c2,1,"Account TCN7JM was created on most WMF wikis except one or two, due to rules in MediaWiki:Titleblacklist.
Before MW 1.22 it was possible for admin to create account for user (simpler than changing MediaWiki:Titleblacklist). Today I got following:
""Account creation error
Cannot create account: the requested username is already taken in the unified login system.""
Tried twice, thought that only filing bug report here will help, but workaround solved problem (created temp name and renamed it to wished name - TCN7JM).
Anyhow, that should not happen, as check for wanted user name on local wiki gave: ""User account ""TCN7JM"" is not registered.""
Account & wiki where bug occurred (for easier troubleshooting):
http://hr.wikipedia.org/wiki/Razgovor_sa_suradnikom:TCN7JM
Thanks!
--------------------------
**Version**: master
**Severity**: normal",54335,-4,Medium,False
3.0867343843577264,1.3324478028348228,4.094148917645789,-2.4866106096543463,-3.752401787029884,4.242767699804837,-0.7525467723762089,0.4303441208236658,2.0032049490290396,-0.985199523061075,-0.9231502879603157,2.7792731044165286,0.7772705042120767,0.2521848866335894,2.1145146464910027,0.9336084051765798,0.029302930210368672,-0.914451655045466,False,c2,1,"**Author:** `kwwilliams`
**Description:**
Per http://parsoid.wmflabs.org/en/User:Kww/certtable the failure to display the certification template tables in http://en.wikipedia.org/wiki/User:Kww/certtable (live version http://en.wikipedia.org/w/index.php?title=Metallica_%28album%29&oldid=566196578&veaction=edit) appears to be rooted in Parsoid. This means that it must be a different bug than 50589 but may be related to 44498.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44498
https://bugzilla.wikimedia.org/show_bug.cgi?id=50589",54296,-5,Medium,True
1.2133830761711573,1.7336237468327873,-2.4219916371735195,3.066852086292652,0.6944689591443658,-3.8261570430534073,-3.4332426666170823,-2.2575793323180395,-0.671989960623347,1.2241472948921128,3.7481084022651117,-1.582291101056949,-3.1064259252147934,-1.397798425244801,1.0748940727387275,0.03703934158715749,-0.11657656603475597,-0.21860237865647214,False,c2,1,"**Author:** `sumanah`
**Description:**
webpage displaying login error
This might be multiple bugs that need to be split up.
I went to zh.wikipedia.org and clicked the 登录 link in the upper right hand corner (next to the user icon) to sign in. I presumed that my user account for User:Sharihareswara_(WMF) would get me in, thanks to SUL.
I know the login UI so it didn't bother me that it was labelled in a language I don't know. I filled in:
Username: Sharihareswara (WMF)
Password: [correct password]
and got the following error message in red (see screenshots):
登录错误
<<table id=""mw-protectedpagetext"" class=""plainlinks fmbox fmbox-warning"" style=""clear: both; margin: 0.2em 0; border: 1px solid #aaa; background: #f9f9f9; width: 100%; background: #FFDBDB; border: 1px solid #BB7070;""> <tr> <td class=""mbox-text"" style=""""> <p>本用户已经被禁止创建，由于用户名“Sharihareswara (WMF)”和<a href=""/wiki/MediaWiki:Titleblacklist"" title=""MediaWiki:Titleblacklist"">本地</a>或<a href=""//meta.wikimedia.org/wiki/Title_blacklist"" class=""extiw"" title=""m:Title blacklist"">全域</a>黑名單<code> .*(apologise|war).* <newaccountonly></code>配合。请确保用户名符合<a href=""/wiki/Wikipedia:%E7%94%A8%E6%88%B7%E5%90%8D"" title=""Wikipedia:用户名"">用户名方针</a>。如果需要协助，请参照<a href=""/wiki/Wikipedia:%E8%B4%A6%E5%8F%B7%E8%AF%B7%E6%B1%82"" title=""Wikipedia:账号请求"">Wikipedia:账号请求</a>所列指示直接向管理员申请账号或提交反馈。 </p> </td> </tr> </table> >
When I switched to English via the ""：中文（简体） | 中文（繁體） | English | 日本語 | 한국어"" choices just above that error and tried again, I got:
Login error
<The user name ""Sharihareswara (WMF)"" has been banned from creation. It matches the following blacklist entry: <code> .*(apologise|war).* <newaccountonly></code>>
(My last name has the string ""war"" in it; never realized that before.)
However, if I tried logging in with an *incorrect* password, I got a well-formatted error ""Login error: Incorrect password entered. Please try again."" or ""登录错误: 你输入的密码错误。请重试"". That error message doesn't reveal any of the <table> or <code> tags to the user in the message.
Therefore:
1) Zhwiki administrators or Chinese translators, could you fix the messaging for the ""this username has been banned from creation""? I looked in https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=core&filter=&action=translate and I couldn't figure out what message needs fixing, sorry.
2) If the wiki's administrators have banned a particular user name from creation, but our SUL unification tries to make an account for them, then is it the right thing to do to still display a regular ""wrong password"" error message when someone tries to login with that username but gets the password wrong?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44718
**Attached**: {F11533}",54191,-5,Medium,True
-4.111875679862003,3.373341970621805,-3.9092288962596324,-6.309318176953716,-0.042638523733410705,-1.9251885055121996,1.443107378531285,-3.3851598115271777,-1.9645838636038535,0.5620541908395387,0.5733902207770574,1.606028817644659,0.5075650841950399,-1.3034356978874984,0.27349723291008043,0.9211950500214523,-0.9540799616029665,-1.5109189551413347,False,c2,1,"I'm not sure which is the correct component/product, if it's WMF configuration or CA, so please move if it's not in the right place.
On every wiki I visit, since the loginwiki has been made active, instead of being welcomed by my locally set monobook interface, I get a vector UI with the following message:
""Central login
You are centrally logged in as Snowolf. Reload the page to apply your user settings.""
It is rather timeconsuming to have to reload on every wiki I browse... is there no way around it?
--------------------------
**Version**: unspecified
**Severity**: normal",53850,-6,Medium,False
-1.7445163853571082,-8.904659785174506,0.6186183555851947,-2.45635278047925,-2.738895070367233,-4.626499052624329,3.2807072542413716,-8.41306983519031,-0.8135014895590078,-1.9215051262335052,-0.565783096317773,0.05449727285628314,0.6778618743478746,2.6587344185108703,1.465344733855198,4.022719302409824,-1.7776702732303074,-0.8622951872157953,False,c2,1,"In case they forget their user names.
--------------------------
**Version**: 1.22.0
**Severity**: normal",53807,-6,Medium,
-6.182497785745692,2.2868805103815433,-1.8746637249276805,-0.9120605755390754,-2.6522970254808786,-1.798807290641117,0.7736972055211622,-1.728556844368239,-0.1276990727116226,0.014511327125746654,-0.025787625276934012,-0.07375948337822158,1.1690771289729627,-0.7242235182225567,-0.6137404240769548,0.9784612589460723,0.44614228298264913,0.9244547317026444,False,c2,1,"When attempting to use en.m.wikipedia.org on a desktop browser (tested w/ Chrome 28 and FF 22), I get a red warning message after logging in:
""Central user log in
No active login attempt is in progress for your session.""
This message is displayed via the desktop site and so I have to manually return to mobile mode. It does log me in properly.
This is without beta or dragon mode enabled.
I can't reproduce this behavior on a mobile device, but in addition to causing issues with testing, it might affect tablet users who want to use the mobile site.
--------------------------
**Version**: unspecified
**Severity**: normal",53789,-6,Medium,True
-0.072505311120592,6.326798271091871,3.916183913448286,0.9882666204586976,-0.32986921498345584,1.188810404180096,-0.7384517816756322,1.1545568894944265,-1.6387695535360125,-0.5964880098263938,-1.783079767170549,-0.22106060265841643,0.4371007187560987,0.857546766039353,-0.9499670463000145,-0.6600930530906295,-0.06711098168477303,0.04930743695142881,False,c2,1,"This RFC has been scheduled for public discussion on June 28 (Wednesday) at 21:00 UTC (2pm PDT, 23:00 CEST). As always, the discussion will take place in the IRC channel #wikimedia-office
### Problem statement
Currently `/wiki/Redirect` responds with the Target page, with three notable differences:
* A ""Redirected from .."" message is rendered.
* A piece of JavaScript is inserted that will jump to the destination `#Section` (if any).
* A piece of JavaScript is inserted to normalise the address bar from `/wiki/Redirect` to `/wiki/Target#Section`.
Internals:
* Page markup (wikitext) refers to the title as specified. – `[[Redirect]]` is saved as-is, no pre-save transformation)
* Page rendering refers to the title as specified – HTML: `<a href=""/wiki/Redirect"">`
* When clicking on such link within the wiki, or otherwise navigating ""to"" the redirect, the server responds with a modified version of the response for the target of the redirect. – `/wiki/Redirect` responds the same as `/wiki/Target`, including a `<link rel=canonical>` specifying `Target` as canonical, and a special header informing the reader ""Redirected from Redirect"".
* Once the page is rendered, JavaScript does two things:
* Jump to the intended section (if any).
* Swap the address bar from `/wiki/Redirect` to `/wiki/Target`. This encourages further social sharing to share the canonical link, and makes it so that those other people will not needlessly see ""Redirected from Redirect"" - which doesn't apply to those readers.
Benefits:
* Parser cache: Changing the redirect does not require invalidating parser cache of incoming links.
* Performance: ""Following"" a redirect responds quickly (no HTTP redirect).
* Usability: Users know when they followed a redirect (header message ""Redirected from""), and the message doesn't show for others when you share the link.
* Search engines: No indexing of duplicate content. (due to canonical url).
Problems:
* **Redirect to heading**: When redirecting to a heading on a destination page (e.g. `Topic` redirecting to `General#Topic`), the browser does not natively jump to this heading because it's rendering content at `/wiki/Topic` not `Topic#Topic` or `General#Topic`. This is currently worked around with JavaScript. While this technically works it is bad in two ways:
* Performance: The jump happens very late. Sometimes 5-10 seconds after the first paint, because it waits for all content to arrive and all JavaScript to arrive and execute.
* Fallback: In our Grade C experience for older (but supported) browsers, the jump never happens.
* Fallback: It also means that on supported browsers, the jump doesn't happen if there were intermittent connection issues.
* Fallback: There is no recovery for the user when the jump doesn't happen. There is no manual way to get to this information (it's hidden in invisible JSON data)
### Solution 1
Change the response of `/wiki/Redirect` to be an HTTP redirect to `/wiki/Target?rdfrom=Redirect#Section`. When viewing `/wiki/Target?rdfrom=Redirect#Section`, client-side code normalises the address bar to `/wiki/Target#Section`.
This addresses all the problems.
* Drawback: Users will be subject to an HTTP redirect.
* Benefit (compared to Solution 2): Redirects are instantly up-to-date (no need to wait for job queue).
### Solution 2
Same as solution 1, but in addition, optimise the common case by changing the Parser to resolve to this url ahead of time.
* Benefit: Faster user experience for the common case.
* Drawback: Updating of urls depends on job queue, similar to template transclusion updates.
>>! Original task description:
>
> With Javascript disabled/not available:
>
> *Links to sections, works correctly, e.g. [[https://en.wikipedia.org/wiki/Albatross#Biology|Albatross#Biology]]
> *Links to sections via a redirect, works correctly, e.g. [[https://en.wikipedia.org/wiki/Beiruit#History|Beiruit#History]] -- ([[Beiruit]] is a redirect to [[Beirut]]).
> *Links to sections via a redirect to a section, do Not work correctly, e.g. [[https://en.wikipedia.org/wiki/Camden Market Fire|Camden Market Fire]] takes you to the top of the target page but not to the section -- ([[Camden Market Fire]] is a redirect to [[Camden Market#Incidents]])
>
> Fixing this may partially fix the section links issue in {T53122}
>
> See also:
> * {T144781}
> * {T37858}
> * {T20883}
> * {T37045}
",53736,-6,Medium,
-7.7183697791036465,1.6508592636374146,-2.5992671092343667,-0.6027109364665424,-1.1124380884582208,0.37637088015700204,1.395439404029779,2.3070406281720226,-1.4286843531538598,1.5275696513493369,0.5874152340653964,-1.1455348108901968,1.714211679688455,-2.287124887956852,1.810670740795441,-0.5451530001646515,-0.7683387654010116,-0.7046918955574324,False,c2,1,"In production right now we're causing RL to have to do a separate HTTP request for modules like ""ext.vector.footerCleanup"".
This is pointless, it should be part of the regular queue that is on every page. It was perhaps useful in the past when there were more modules in the ""ext.vector"" group that load on every page from the same queue (so that different pages with different modules in their queue would share this cache), but right now this is the only one left and no longer justified being in a separate request.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45051",53564,-6,Medium,True
-4.970877344811683,2.04344925606415,0.27859448036354095,4.164565740421683,0.9151568625874362,-0.23308166478924364,-1.0989750791903727,1.0454055896753878,-0.005522785258076035,-2.124404778871657,-0.6184993456309877,-3.048335459814878,2.6617742531768576,-1.3436162558726292,-1.213724830406754,-0.7818298619842194,0.2288558216797434,0.3299124715176449,False,c2,1,"**Author:** `davidt-mediawiki-bugz`
**Description:**
There are two code paths that can lead to ResourceLoader.php calling tryRespondLastModified:
ResourceLoader::respond
if ( $wgUseFileCache )
ResourceLoader::tryRespondFromFileCache
ResourceLoader::sendResponseHeaders
ResourceLoader::tryRespondLastModified
or
ResourceLoader::respond
tryRespondLastModified
Only one of these paths calls ResourceLoader::sendResponseHeaders.
The other path will set a HTTP 304 status and Status: 304 header, but no other headers. The lack of the Expires header in particular causes a variety of odd problems when using (at least) mod_proxy/mod_disk_cache as an apache-based caching reverse proxy.
Using mod_proxy and mod_disk_cache from apache2 pre-2.2.18, this leads to the proxy returning erroneous 304 responses to clients who sent unconditional requests (see https://issues.apache.org/bugzilla/show_bug.cgi?id=45341).
After the fix/workaround added in 2.2.18, mod_proxy will now correctly send the cached content back to the client, but will then immediately purge the page from the cache, which is not ideal.
I fixed this locally by moving the call to sendResponseHeaders from the first call path after the call to tryRespondLastModified, then adding a call to sendResponseHeaders in tryRespondLastModified itself.
--------------------------
**See Also**:
https://issues.apache.org/bugzilla/show_bug.cgi?id=45341",53283,-7,Medium,False
-9.865062998392851,5.814140939367029,1.6443479033494626,-1.2385423792738826,-2.9913221092916364,-0.3019790883814527,2.1617678277460124,-2.3685430635151246,2.107373807560859,-0.5103370745661131,0.5571352507852985,-0.40906754758970987,0.6647084751497023,0.6672124197536524,1.5366339183799678,0.03678946650937537,1.953478717106339,1.42766012359771,False,c2,1,"Our API connections are currently using the request library due to bugs in earlier versions of the native http module. We should investigate if those are fixed in 0.8 or 0.10, and then see if we can use a pool of persistent connections per worker. That should hopefully speed things up a bit by removing some latency, and give us control over the maximum concurrency we are requesting per worker.
See also:
http://nodejs.org/api/http.html#http_class_http_agent
--------------------------
**Version**: unspecified
**Severity**: normal",53272,-7,Medium,False
-6.396432601900765,2.637148712740686,-1.9755076269823082,-2.417253318933761,2.4085176804883353,-3.579005939652757,1.530025295917289,3.4029051979528275,-1.4014740124032876,0.0660067618636031,-0.1499787746455925,-0.38176071768497233,-0.4274527749960697,-0.35087090153903766,-0.1380674606454848,-0.06613338695320575,-0.6412939224054968,0.21040859436606918,False,c2,1,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).
I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.
Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all.
Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless).
The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",53073,-8,Medium,True
-1.948527540935884,7.889002481497528,0.14047598835789898,-4.311741352020066,-2.9956904821023467,0.586543577892497,-0.5003515033469403,1.178051226819397,2.5895471366386156,-0.8661747769202104,-0.31740874253473983,0.8381230266414674,1.1510359019835432,-1.2833726214236139,1.459653586050642,-0.765722903091945,0.8095607526820523,0.5354381139258824,False,c2,1,"I propose setting $wgEnableCanonicalServerLink = true everywhere, and setting $wgCanonicalServer to HTTPS on all servers except Chinese language wikis.
We did this with uz.wikipedia.org, and so we know with some confidence that it will cause Google to provide links directly to the https website. This will cause most of our traffic to go to HTTPS.
I'm filing this to create a place for discussion, rather than as an immediate action item. Before this can be done, the SSL cluster would have to be expanded significantly, assuming Ganglia capacity data is correct -- maybe by a factor of 10. It may be simplest to wait until HTTPS is sent directly to Varnish, but even then, some proper capacity calculations would be in order.
This would be an alternative to {T50402} and a significant step towards {T49832}.
Update:
>>! In T49832#1240813, @BBlack wrote:
> As I've stated before, personally I'd prefer to do the hard redirects before the rel=canonical during the initial rollout process, simply because it's easier to take back in realtime if anything doesn't work out as planned in terms of load and capacity. We already have a process down for this stuff. It's not my place to speak to the rest, but I assure you people are aware and working on it.
**See Also**:
* {T50402}
* {T49832}",53002,-8,Medium,False
3.0372218768858708,-1.3267505504877644,1.1969626664699327,1.286680210539656,4.559265011096812,0.07102075497259497,0.14832878402861915,-3.753315025311197,-1.0232700840318825,1.557391400413743,0.5380566039652983,2.272700635957058,-0.28329881902623466,0.8258843502228705,-1.203847408673556,0.472450842402531,0.4557691321583235,3.7293394717732227,False,c2,1,"Intermittently, I get 502 Bad Gateway errors using HTTPS on en.wikipedia.org while logged in. The footer reads ""nginx/1.1.1.9"" or similar. <https://en.wikipedia.org/wiki/List_of_Anything_Muppets> is a sample URL. A browser window refresh solves the issue, but we should investigate and address what's causing these intermittent errors.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",52891,-8,Medium,False
7.892278161854135,-7.485961583423247,0.9059904181546514,4.109998348920323,4.614462527882987,-0.13406461193778063,2.0365279629418405,-4.320957097127127,0.054183036632340975,-2.211890680013315,-2.193761850484111,1.9701425642665835,-1.8583742646160477,-0.10655399476222982,0.3564457814984223,0.6885782086072232,-0.9705848468698587,-0.26891906668050325,False,c2,1,"**Author:** `lcarr`
**Description:**
https://en.mobile.wikipedia.org/wiki/Main_Page is an example page -
It uses the *.wikimedia.org cert.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://en.mobile.wikipedia.org/wiki/Main_Page",52748,-8,Medium,False
13.018347445620336,0.31916472979409605,-0.2549029978108024,0.5395745236316136,-3.590182462902313,-1.5141192186550965,-0.8467796418947797,-0.04196214822413247,-0.39293731712931596,-2.066182826749733,-0.7364168538649407,-1.8524629335872247,1.7068913711956237,0.2872542581936184,-0.7144802892933102,-0.6206288771565903,0.7447030031042454,0.44576818925395423,False,c2,1,"The current Play store version and recent nightlies crash with a Java memory error soon after login.
I've replicated this on three different devices (Android 2.3.7, 4.1.1, and 4.2.2). It will crash, then attempt to start again and almost immediately crash again.
USER_COMMENT=after a minute or so of browsing my feed, app crashed.
ANDROID_VERSION=4.2.2
APP_VERSION_NAME=1.0beta9
BRAND=htc
PHONE_MODEL=One X
CUSTOM_DATA=
STACK_TRACE=java.lang.OutOfMemoryError
at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:122)
at com.android.volley.toolbox.BasicNetwork.entityToBytes(BasicNetwork.java:215)
USER_COMMENT=crashes soon after login
ANDROID_VERSION=2.3.7
APP_VERSION_NAME=1.0alpha1
BRAND=verizon_wwe
PHONE_MODEL=ADR6300
CUSTOM_DATA=
STACK_TRACE=java.lang.OutOfMemoryError
at com.android.volley.toolbox.ByteArrayPool.getBuf(ByteArrayPool.java:101)
at com.android.volley.toolbox.PoolingByteArrayOutputStream.<init>(PoolingByteArrayOutputStream.java:53)
at com.android.volley.toolbox.BasicNetwork.entityToBytes(BasicNetwork.java:202)
at com.android.volley.toolbox.BasicNetwork.performRequest(BasicNetwork.java:104)
at com.android.volley.NetworkDispatcher.run(NetworkDispatcher.java:105)
USER_COMMENT=
ANDROID_VERSION=4.1.1
APP_VERSION_NAME=1.0alpha1
BRAND=samsung
PHONE_MODEL=GT-I9100
CUSTOM_DATA=
STACK_TRACE=java.lang.OutOfMemoryError
at com.android.volley.toolbox.ByteArrayPool.getBuf(ByteArrayPool.java:101)
at com.android.volley.toolbox.PoolingByteArrayOutputStream.<init>(PoolingByteArrayOutputStream.java:53)
at com.android.volley.toolbox.BasicNetwork.entityToBytes(BasicNetwork.java:202)
at com.android.volley.toolbox.BasicNetwork.performRequest(BasicNetwork.java:104)
at com.android.volley.NetworkDispatcher.run(NetworkDispatcher.java:105)
--------------------------
**Version**: unspecified
**Severity**: major",52733,-8,Medium,False
-2.8210829443094383,-0.5784004512929641,9.039710079953654,2.561728790121015,-2.8491375274138795,-2.369309629078516,-3.74033868252806,0.08597857198164949,3.6962183336446497,2.2661365547021655,-4.194749582697902,-0.5959529636039055,-1.2869548343177106,-0.07660654400509515,-0.43708877010657066,-0.741594439482012,-2.509024257961395,2.5545086844156675,False,c2,1,"Trying to ""Edit"" on http://en.wikipedia.org/wiki/List_of_Advanced_Dungeons_%26_Dragons_2nd_edition_monsters after a minute or so results in a popup ""Error loading data from server: error. Would you like to retry?"". Trying again, repeats the issue
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39057",52475,-9,Medium,False
-9.382237438287493,3.890154853811655,2.604649267974448,0.06846878629185005,7.662176489499755,-0.987322076927853,4.82226202975117,0.5740970584203767,-1.19718128892764,-1.3767377956206137,0.07026931550023274,-6.609173305880549,-0.8024962872396006,0.6857484688375521,3.9834524223443823,-1.2622525870015264,-1.3664547305583734,-2.9992681230186595,False,c2,1,"When I first saw the lock icon next to the input field on the new login page, I assumed it meant the current page is secure, not that the link is to a secure page. (Not really a bug so much as feedback)
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",51660,-11,Medium,True
16.097030173376368,0.7494401295875104,-0.7073208388866039,0.9416950248379701,-0.7145087211081131,-2.0463011937190174,-2.3840279982768178,1.2551775751523921,0.4558976700933005,-1.9063195225059841,2.227083021814811,-0.12678527384574956,-0.7729038446127685,2.306834975734004,1.7105420357365348,-0.48690923757137794,0.647119596357925,-0.8679819389387498,False,c2,1,"Please see below the transcript of the failed HTTP 1.1 session with upload.wikimedia.org.
The problem appears to be that the server upload.wikimedia.org doesn't properly process absolute URI. Normally clients send it relative URIs. I got this example with misconfigured proxy server. HTTP 1.1 specification demands that clients send absolute URIs to proxies, but my proxy accidentally didn't convert URI absolute->relative. However, HTTP 1.1 specification says that HTTP 1.1 servers ""MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies"", see here http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
This is a deviation of upload.wikimedia.org from the HTTP 1.1 specification which needs to be fixed.
--- failed HTTP session ---
GET http://upload.wikimedia.org/wikipedia/commons/thumb/e/e5/Pizda.svg/100px-Pizda.svg.png HTTP/1.1^M
Host: upload.wikimedia.org^M
Proxy-Connection: keep-alive^M
Cache-Control: max-age=0^M
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36^M
Accept-Encoding: gzip,deflate,sdch^M
Accept-Language: en-US,en;q=0.8,ru;q=0.6^M
^M
HTTP/1.1 404 Not Found^M
Content-Type: text/html; charset=UTF-8^M
X-Varnish: 791003890, 1369041883^M
Via: 1.1 varnish, 1.1 varnish^M
Content-Length: 279^M
Accept-Ranges: bytes^M
Date: Wed, 12 Jun 2013 03:10:50 GMT^M
Age: 0^M
Connection: keep-alive^M
X-Cache: cp1026 miss (0), dysprosium frontend miss (0)^M
Access-Control-Allow-Origin: *^M
^M
<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>404 Not Found</h1>
The resource could not be found.<br /><br />
Regexp failed to match URI: "http:/upload.wikimedia.org/wikipedia/commons/thumb/e/e5/Pizda.svg/100px-Pizda.svg.png"
</body>
</html>
--------------------------
**Version**: wmf-deployment
**Severity**: normal",51467,-11,Medium,False
0.8247908933633421,-4.399871334384255,4.792314505571316,6.086278276738216,-6.205472560221352,-1.5905170578972694,2.642421202708543,-0.18298106703247524,-0.47443935181600677,0.3199101919546523,0.6180327066249216,-0.8976733869820482,1.5471679602066275,-1.1174209931362302,-1.228858311178242,1.1515489727667076,-0.7691123031282611,-1.1118621406169937,False,c2,3,"Login captcha (in Polish)
Login captcha shown after too many incorrect attempts to log in looks ugly, compared to the nicely styles create account form captcha.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**Whiteboard**: gci2013
**URL**: https://en.wikipedia.org/wiki/Special:UserLogin
**Attached**: {F12184}",58370,9,Low,False
-2.777394317222268,-0.9693276936678146,-1.3451321175297437,-4.8079417806312605,-0.11428422145762962,-2.0499784736754085,0.7774487274266617,-3.55331385406913,-0.4640691319724209,-1.116495372334311,-0.057095928431290854,-0.7002182750655455,-0.14489110278005324,-1.0817609262404604,-0.5592735265186572,0.5157725462729859,-0.057635919663343804,-1.1678897085505728,False,c2,3,"**Author:** `swalling`
**Description:**
Desktop screenshot
On the desktop sight, if I visit Special:UserLogin (such as through a link in a help page), but I'm already logged in, I now get a helpful message telling me that I am already authenticated. [See screenshot attached]
On mobile, I am given the normal login form, and no indication that I don't need to log in again. It would be nice if you just displayed the same warning message that gets displayed on desktop.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F12150}",58359,9,Low,False
-2.1726972529508535,-2.187761407894193,3.770828914730572,-7.8748233850623635,5.048168052571601,-5.331016172527391,0.890413974308153,1.5800636703473603,1.545151729814349,3.143018811857176,-0.41749807865367794,-0.8907222038313782,-0.9838582045887305,-1.2670687873658304,3.1674713329400292,1.8504121632715305,0.5910627908229753,0.7970467073614051,False,c2,3,"There is URL in 'Source' column here http://toolserver.org/~erfgoed/api/api.php?action=search&format=html&srcountry=ua&srlang=uk&srid=61-212-0002&props=image|name|address|municipality|lat|lon|id|country|source|monument_article|registrant_url , but there is no A tags there, and I cannot go directly by link. I should copypaste it. It will be more useful if add A tags there.
--------------------------
**Version**: unspecified
**Severity**: normal",57657,6,Low,False
7.525026412986234,-10.567996697169225,2.7401601508639857,-3.3810738767750976,-5.351822819723662,5.996085052234484,3.0134636830644554,-0.9276232968220158,-0.519434619159356,0.8839385602108223,0.1464673581437017,-1.5322935839999308,-0.6902090804728331,-0.1377003515481645,-0.4055333893897286,-0.8638119038715233,0.5768483718141784,-0.25426230424157037,False,c2,3,"From Jared
--------------------------
**Version**: unspecified
**Severity**: normal",57575,6,Low,False
-3.1796470768868885,5.088272220338428,1.7845637545917867,7.892074884680682,-0.43954027066681,-0.5968080563563447,1.4923139205145457,1.113038065949525,-1.2412804627814853,0.557317579303632,-0.02989941977792565,-0.24074020954272257,1.9122813698301546,1.0986837057574084,0.29870811768736427,0.13740493507771268,-0.8081091818509373,-0.4729994822188861,False,c2,3,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1475/
Reported by: jaclayiii
Created on: 2012-06-26 04:52:22
Subject: *-login.data can have case discrepency on Linux host
Original description:
Pywikipedia \[http\] trunk/pywikipedia \(r10401, 2012/06/21, 06:18:43\)
Python 2.7.2+ \(default, Oct 4 2011, 20:06:09\)
\[GCC 4.6.1\]
config-settings:
use\_api = True
use\_api\_login = True
unicode test: ok
Summary: the \*-login.data file maybe saved with an uppercase username but when load cookies tries to find it on a Linux host, the case of the username maybe lower. This has the unintended consequence of not allowing bots to login on private wikis that have anonymous read api rights disabled.
If a user connects to a wiki that has LDAP or some other form of ""add-on"" authentication, the user name returned may vary in case from what is in the user-config.py file. The reason this matters is that the <wikifamily>-<language>-<username>-login.data file may be saved with an upper case letter in the username. Thus if the user-config.py file contained:
users\[""mywiki""\]\[""en""\]=""james""
but the LDAP authenticator returned back ""James"" as the username, then the \*-login.data file would be mywiki-en-James-login.data, but when \_loadcookies goes to look for such a file on line 5572:
if os.path.exists\(localPA\)
localPA is /~some/path/to/mywiki-en-james-login.data
Notice that the James is now lower case in the file above.
As Linux is case sensitive, it cannot find the login data and thus prevents access to wikis the do not allow anonymous access to api's. A temporary work around requires setting user name to the appropriate case \(even if the username is case insensitive in the LDAP authentication scheme\), for example:
users\[""mywiki""\]\[""en""\]=""James""
keywords: SSL, Login failure, https login failure, https linux login, https pywikipedia, https pywikipedia linux
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1475",57190,5,Low,False
-0.8883560932814651,10.274815744425485,3.155388318461256,2.2463371435715254,-0.3461184810307866,1.4725184400622846,-0.2852583282079397,1.4507127887512414,-1.753327724771616,-2.716148028918495,-2.3094751204569595,-0.9489718788770817,0.14170551276606602,1.7799788833071446,-1.4617008286621163,0.42181462223766003,-0.6009097309449986,1.1819145220241964,False,c2,3,"Special:OpenIDXRDS returns URLs based on $wgCanonicalServer. But when it attempts to redirect the user to these URLs, the forceHTTPS cookie kicks in and triggers a redirect to the corresponding https URL, which then fails due to loss of POST data.
Chris suggests this be worked around somehow in OpenID rather than having core use a 307 redirect instead of a 302.
--------------------------
**Version**: master
**Severity**: normal",56512,3,Low,False
28.68800933170505,-6.3928977563385585,1.8730778756720667,0.4771457317731027,0.18160069830712378,1.5489387041938418,0.1517169967406744,-1.5955032236054616,0.28921496430008575,-1.9975944179014182,-0.06854232459300036,-0.3970069518291748,-2.039920546736326,1.7365516291115473,1.8578411489309392,-0.36074489395222464,0.4890376288195786,0.3397516026093028,False,c2,3,"URL: https://zh.wikibooks.org/w/index.php?title=Special:用户登录&returnto=Wikibooks%3A首页&returntoquery=&fromhttp=1
Browser: Google Chrome 29.0.1547.66
OS: Microsoft Windows XP [5.1.2600]
--------------------------
**Version**: wmf-deployment
**Severity**: normal",56457,3,Low,False
3.1683443454439577,-0.8658472096929657,-4.372643667737707,0.20174382524991463,-0.04538204137695567,0.20015382086781952,-5.716539861605225,-0.8737964024671724,-2.180103234981356,3.300388357785369,-2.8981375084650165,-1.3697768122300487,-0.310720687413756,-3.1393508573054643,2.0280542990315844,0.5472831483744928,-0.47876365755757977,1.2390731206421022,True,c2,3,"1. There is a ""Wikimedia > SSL related"" component in Bugzilla.
It feels wrong as ""SSL related"" is not an ""isolatable"" part of the codebase.
For example bug 39676 should be under ""Wikimedia > Email"" instead.
2. Tracking bug 27946 had the name ""Secure Server (tracking)"" and refered to the secure.wikimedia.org URL. At some point people (ab)used it for general SSL issues and renamed to ""SSL related (tracking)"".
Maybe both should be killed and turned into a ""ssl"" keyword.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55999,1,Low,False
5.716670540598503,-4.869423010229237,-6.8944668437737935,-0.23809558292839939,-1.769428185766652,-1.2808226696825669,-5.825609515740132,-0.018287906792082503,-2.316924219064842,4.987178553047867,-4.253314661762388,-0.9412202240411645,-1.0681532345822244,-1.9561152673785713,-0.6987668424270463,-0.39631391690920215,0.8684240661816627,-2.008051680613424,False,c2,3,"It was reported by users that HTTPS block in China was only for Wikipedia, thus the following change is proposed, given the current policy of having the best security while trying to keep access for logged-in users in China.
'wmgHTTPSBlacklistCountries' => array(
'default' => array(
'IR', // Iran
),
'wikipedia' => array(
'CN', // China
'IR', // Iran
),
),
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
{T54846}
{T66207}",55739,1,Low,False
2.2972510058274795,0.7145093438612449,1.5352922121879793,1.0272284763694164,3.351312319603095,-0.48463599313991235,-0.41707152426271854,-0.7933862022649125,-1.850597847570191,-0.15859643910099575,0.5965105943801623,1.3281129766766508,2.1880773576450805,2.229275447333059,-0.06819234137568664,1.2553348846125827,-0.592827935816764,-0.3011125050086072,False,c2,3,"Use a mobile web browser. I used ""User-Agent: Opera/9.80 (Android; Opera Mini/7.5.33361/30.3793; U; sv) Presto/2.8.119 Version/11.10"".
Steps to reproduce:
1: Delete all cookies.
2: Log in to Wikipedia. You should now see the mobile site as you are using a mobile web browser.
3: At the bottom of the page, click on the link to the desktop version.
4: Elsewhere on the Internet, find a link which points to Wikipedia's desktop HTTP edition, and click on the link. Alternatively, type in a URL yourself.
Actual result: The browser shows the mobile HTTPS edition of Wikipedia.
Expected result: The browser shows the desktop HTTPS edition of Wikipedia.
IMPORTANT: You must perform steps 2 and 3 in the order indicated above! If you perform them in the opposite order, then the result is different (due to bug 43771).
== Explanation ==
Steps 2-3 should give you two cookies:
Set-Cookie: enwikiforceHTTPS=true; expires=Mon, 30-Sep-2013 23:24:04 GMT; path=/; httponly
Set-Cookie: stopMobileRedirect=true; expires=Mon, 30-Sep-2013 23:15:06 GMT; path=/; domain=.wikipedia.org; secure
When you request the Wikipedia article (say, http://en.wikipedia.org/wiki/A), the following happens:
1. Browser sends ""GET /wiki/A HTTP/1.1"" to en.wikipedia.org. As the connection is insecure, the stopMobileRedirect=true cookie isn't sent, but enwikiforceHTTPS=true is sent:
Cookie: enwikiforceHTTPS=1
2. Server detects a mobile user agent, so you are redirected (302 Moved Temporarily) to http://en.m.wikipedia.org/wiki/A (still no HTTPS).
3. Browser sends ""GET /wiki/A HTTP/1.1"" en.m.wikipedia.org. As it is still insecure, stopMobileRedirect=true isn't sent:
Cookie: enwikiforceHTTPS=true; enwikiforceHTTPS=1
4. Server detects enwikiforceHTTPS=true and enwikiforceHTTPS=1 (no idea why the browser has two cookies with the same name) and you are redirected (302 Found) to https://en.m.wikipedia.org/wiki/A.
5. Browser switches on SSL and sends ""GET /wiki/A HTTP/1.1"". Now all cookies are sent, including stopMobileRedirect=true (private information removed):
Cookie: enwikiSession=REMOVED; centralauth_User=Stefan2; centralauth_Token=REMOVED; centralauth_Session=REMOVED; enwikiUserID=808814; enwikiUserName=Stefan2; enwikiforceHTTPS=true; enwikiforceHTTPS=1; stopMobileRedirect=true
6. You see the mobile website.
Problem: As the redirect to HTTPS happens after the redirect to the mobile site, the stopMobileRedirect=true cookie is sent too late and the server won't know that you wish to stay on the desktop website.
--------------------------
**Version**: unspecified
**Severity**: minor",55667,0,Low,True
3.395226558388812,3.59237598982023,-1.3427313704099735,-3.2140846239768166,0.9636847412242873,6.366292895920667,-0.26932934798959085,-1.718085236292243,0.7635417187899258,-3.220645827742292,-3.7912849301191915,1.903609076636213,-2.6910212575289965,0.13777882091034588,1.9181832417737015,-1.2554812193343265,0.180758864046638,1.0866491941657734,False,c2,2,"The TOTP RFC recommends all communications (especially those involving the secret key) be over TLS. I recommend using $wgSecureLogin as an indicator of whether communications should be forced over HTTPS.
--------------------------
**Version**: master
**Severity**: enhancement",55197,-1,Low,
-6.342594794071877,0.8318662534767434,-0.22945859715740724,2.2097334837096403,0.3960739464863532,2.1540952886964986,0.4469533201853375,-2.1896194912292,1.5929237335509567,-2.3533750578784893,-2.066211880712743,0.13582957381147787,-0.8941916307923723,1.373198789783892,0.10861310051713158,-0.111882663258499,-0.08351377479520239,-0.9573584378533813,False,c2,2,"This is similar to bug 26538, but for the user side I presume
It is requested that people be able to set an option that would allow them to configure the duration time of their login session.
Use case:
Multiple Wikipedia users sharing the same computer/browser in a household.
We have seen a number of times now that people/siblings/partners accidentally use each others accounts in this situation. The option would forcefully expire the login session after a certain amount of time, independent of the cookie expiration of the browser.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56212",55156,-1,Low,
-3.4604894404429216,-0.785838841669225,-0.46571471659629715,-1.4090088426421352,0.43886689101475107,-4.861346327724158,1.5943187994091819,0.9899351859459676,1.5143343884271696,-0.3405599079811523,-0.7812615639510216,1.4873125569727905,0.0625186653535108,-0.8363757860266912,-0.5969895324682533,-0.8011752658457649,0.9011794504824973,-0.9798088860831737,False,c2,2,"**Author:** `mr.tamershlash`
**Description:**
$wgUseInstantCommons protocol appears to be relative according to this bugfix: https://bugzilla.wikimedia.org/show_bug.cgi?id=32219
However, in some countries (like Syria) Wikimedia Commons is blocked if you're using http, so if you're on another wiki that doesn't have ssl, you'll not be able to see any image form the commons, which is really odd.
I think that $wgUseInstantCommons should always use https, I tried to use $wgForeignFileRepos code here: https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons and changed the apibase to use https and everything worked just fine, it'll be better if just the easy $wgUseInstantCommons use https always.
Thanks.
--------------------------
**Version**: 1.21.x
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=32219",55131,-2,Low,False
0.607675614459684,-5.233386765734741,5.539157138314728,10.23922662614956,4.113601266523975,-0.46714142533477543,-0.01599805616793759,-2.294918391232056,3.2058550688651453,-2.5430347330688075,-2.4831089124603922,-1.1628008570263404,-1.174766495634029,-0.8047874673402973,-0.4839642243960558,0.4447467527906057,-0.45243334688472836,-0.11900364951037168,False,c2,2,"**Author:** `jeffluo35`
**Description:**
A screenshot of the problem.
When browsing a wikipedia article in the internet archive wayback machine, somebody could click the login link and access the login page.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: http://web.archive.org/liveweb/https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Bugzilla
**Attached**: {F11337}",54946,-2,Low,True
-3.6162001533904684,0.8604231499382724,-3.801526676683906,-4.453989246371949,-0.6288077788802493,-2.312880687987951,-0.46041080856260663,-1.4814012659479214,0.8446211880922354,-1.6126566654600873,-1.8657640059690537,0.8435989617243431,0.29250819458537647,-0.21690951318264684,0.10829062770471687,0.8637703497936547,-1.2189446380610702,0.17926261736263593,False,c2,1,"**Author:** `swalling`
**Description:**
Currently with wgSecureLogin set to true, it adds a checkbox on Special:UserLogin (which is checked by default) to let the user ""Stay connected to HTTPS after login"" or not.
I think it is probably not necessary. HTTPS is a sane default, and if there's going to be an option to turn it off, it should likely be in user preferences, not on the login page every time you view it.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=29898",54283,-5,Low,True
1.023440612319654,1.499871778009263,0.7695500513117182,-1.1133104884145475,1.4908476401276975,-1.013420302494074,1.71513737230776,-1.2105951701301518,-0.6551853534255334,0.7758747644924835,1.8846011823703237,-0.459798104079046,1.8671526857239096,-0.9828020689548027,-0.8444694148925471,-0.08560363052435316,-0.17155339619977483,-0.8792703640794415,False,c2,1,"Protocol-relative URLs might be various kinds of awesome, and they work with every major browser. The problem with them is, they break many things that are not browsers. It's easy to write an app that fetches some HTML with HTTP, but less easy to correctly interpret that HTML. Using obscure features like protocol-relative URLs causes the less carefully-written HTTP clients to break.
Access logs demonstrate that there are many broken clients:
http://paste.tstarling.com/p/HonYcW.html
Note that the browser-like UA strings might not be fake -- Flash and Java apps running under the browser send the UA string of their host. Of the UA strings without ""Mozilla"" in them, we have:
* Three versions of perl, two Java libraries
* Microsoft BITS (a background download helper, probably used by an offline reader app)
* KongshareVpn (website defunct)
* Instapaper (an offline downloader/reader for Android)
* Googlebot-Image (IP confirmed to be Google)
* A couple of phone models (Dorado, Symbian)
The length of this list is limited by the sample size, not by the actual number of broken scripts. It's a long, long tail.
This is just a gripe bug, I don't have any concrete plan for replacing protocol-relative URLs in our infrastructure. Krinkle asked me about it at I4155c740 , so I thought I may as well document the problem.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44647 T46647
https://bugzilla.wikimedia.org/show_bug.cgi?id=20342 T22342",54253,-5,Low,
0.19390273733943575,8.453432062883302,0.5612863761839222,-6.637659190051255,-5.20765353262664,4.432959544142628,0.1274702186106209,1.7413708411379551,-1.083576296378268,-1.7156069030793715,-2.577299856043032,-1.704636372561573,-1.9661351174348036,2.09004168096996,-1.8824350672163033,2.0954359761539236,-0.6434498655701848,0.3419591365236181,False,c2,1,"OpenID adds a link to the header for logging in with OpenID. MobileFrontend does not support this.
Maybe it's possible to add support for this in OpenID, rather than MobileFrontend.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54059,-5,Low,False
3.8788463297433844,3.438112629510332,1.92418763987002,1.2114240698615664,-0.17931381863524776,-6.3540101890224845,2.8826267876004428,-4.053345899223793,-1.403064763462727,-1.6577970636833723,-3.039119386061535,0.5396813951638613,-3.5042769651732595,0.29448749582365696,0.32239671781818213,-1.434709509358213,0.32668819399816384,1.2541813196214442,False,c2,1,"I dont know wheter this is a bug on Wikimedia side or on my side, but recently at Wikimedia projects I get sometimes following statment when browsing:
""Při hledání došlo k chybě: Čas pro HTTP požadavek vypršel.""
It sais that during search the bug was detected: HTTP request timeout.
--------------------------
**Version**: wmf-deployment
**Severity**: minor",53096,-7,Low,False
4.806672050029887,-5.76119857218448,2.10848362873989,2.630225683983886,3.5059882878019946,2.472614744685914,3.439474710745139,-3.1864286877279313,0.6150858853766548,0.3889182622783798,0.8494453810212539,2.955362472491654,-0.896436347991048,0.43725528825234505,0.36711743695336985,-0.7511426457267818,-1.1886244261983923,1.1227212953414882,False,c2,1,"Visiting https://en.wikipedia.beta.wmflabs.org/ gives a bad certificate.
It is possible to fix the certificate? Thanks.
Error code: sec_error_untrusted_issuer
--------------------------
**Version**: wmf-deployment
**Severity**: normal",51533,-11,Low,True
-4.229751938639438,4.631748925416037,-2.931164455504735,2.0267963892954355,0.41333554635631375,1.3080758286634084,0.38413011353475923,-4.479158779958418,5.548546896595165,-0.8421874425813627,0.38675238191424866,0.21726939680226964,0.24840896401695733,-0.49714358508140144,2.00564831713283,-1.3546415434461379,-0.09384981494327338,1.1864475143780198,False,c2,1,"http:// link that point to git, get a 404. Would it be worthwhile writing a rewrite in the apache config files that move the urls to https:// ?
Unthinkingly, and through habit, I made the mistake of making the link protocol neutral. I can see that it would be useful to help workaround for others making that mistake.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",51305,-12,Low,False
-1.6236737098075653,-2.526149744790944,-1.8166251061021157,0.453985515814771,5.16006401499566,5.331767910806982,0.31634567750866793,3.318556753673623,4.369324820609812,1.075559681793183,2.3604518377443893,1.062939752651279,1.666727775318431,-0.3584373888059842,-1.474668901188159,-1.8569355461869081,-1.5912586073287869,1.2750504939911347,False,c2,3,"See https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:I-00000601&action=history
eg. when trying to restart the bot or read something, finding a seemingly blank page like this https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:I-00000601&oldid=87399 is a bit annoying.
--------------------------
**Version**: unspecified
**Severity**: normal",58316,8,Lowest,False
-0.5949196643854533,3.4076993924076575,1.8724918238222017,-6.99964019150029,4.067535680414148,-2.911299512660592,1.9105034819943896,-2.4684961859341072,-4.650419945516139,-1.6478778561293366,-0.6338896950491595,1.3773677830060882,-0.43323886726986416,-1.6245626633288284,2.2357963664454195,-0.04925442824220122,-0.7057888243454705,-1.856899375411238,False,c2,3,"**Author:** `salisria`
**Description:**
I had originally filed this as a reopening of bug 54626 (comment 9 https://bugzilla.wikimedia.org/show_bug.cgi?id=54626#c9 ) as I was uncertain what had triggered it. Now I know. When I translate a wikipage with Google, that is when the forceHTTPS cookies are being set despite that breaking my preferences.
In case this affects things, at the time I do that, I am not signed in to Google, but I am signed in to Wikipedia. When I translate the webpage on Goggle that is when I first get the popup message:
""Central login
You are centrally logged in as <username>. Reload the page to apply your user settings.""
That also is likely when the fifteen unwanted cookies are placed.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57081",57887,7,Lowest,False
-0.36973190494815267,-7.115034881508149,-7.775161762075273,-4.138554852225999,-1.5351664053088543,-0.1928284260764901,-3.1008025970172355,1.670752476485105,2.351151210040819,1.3237705792733774,-0.644114733408311,2.129116897685318,2.2646218364182804,-2.1713703234143455,-1.6493429583382095,-0.006208803929847906,-0.37164332325997296,-2.174124048484932,False,c2,3,"You must log in to view other pages.
Return to Main Page.
This is because:
// Make sure the user is logged in
if ( !$user->isLoggedIn() ) {
// If not, let them know they need to
$out->loginToUse();
// Continue
return;
}
OutputPage::loginToUse: throw new PermissionsError( 'read' );
which may not be applicable...
--------------------------
**Version**: unspecified
**Severity**: normal",57394,5,Lowest,False
0.9455404182520897,-1.2829118600042246,-0.08582909307373754,-3.8885800629032765,-3.652913845148712,-4.123183271725228,3.33231415083823,3.332007886624552,-1.9830069148965768,-2.111861307816353,-2.904550294645406,2.1743673095100196,-1.6532200552043061,0.5534536904195821,-0.32586100789841677,0.9959624490442645,-3.0452355264042197,-0.3482561605697594,False,c2,3,"To be more exact, it seems that Explorer only keeps track of history for as long as max-age allows.
IE users are annoyed... :D
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53636",55681,0,Lowest,False
-4.691890625285229,0.8017787067693583,-2.6459100598739873,-2.309956854488587,-1.6911039489079651,-0.8553801467341654,-0.9693165340890335,0.8870067084224192,1.0240759980785805,-1.6434330707618758,-0.5654548754048982,0.8307633482826045,2.2670357281005535,-1.0877520534782907,-2.28216486889033,-2.788434318359534,-0.38398583257080365,-0.5510489815701995,False,c2,3,"We have reports that since the HTTPS enabling, the autocomplete history of (most notably) the editsummary is no longer working for IE users.
This seems to be caused by Explorer that actively enforces this when pages are served over https and set cache headers to private/must-revalidate
http://webmasters.stackexchange.com/questions/2160/form-autocompletion-not-working/2455#2455
http://stackoverflow.com/questions/364066/why-is-the-internet-explorer-autocomplete-feature-disabled-for-all-html-forms-on/364094#364094
We might want to check if autocomplete=on bypassed the default setting, and consider adding that to the fields where we want people to have this available ?
--------------------------
**Version**: 1.22.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53681",55636,0,Lowest,False
-4.096406575844765,-0.9949475054357375,-8.363692296866091,4.107095111753724,0.703883357360729,2.760275723567344,3.0915497987518306,0.4965255297074812,-1.536863824044665,-0.3649537244521026,0.16888848421320501,0.147121612101913,0.31008445611996427,0.23722029099353925,-2.665925312548052,0.6935151070237926,-0.0301188538193653,1.6622119777813558,False,c2,2,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page:
mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro‐
vides speculative local echo and line editing of user keystrokes.
Compared with ssh, mosh is more robust — its connections stay up across sleeps and changes in the client's IP address —
and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi‐
ately, without waiting for a network round-trip.
mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key
authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the
SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.
--------------------------
**Version**: unspecified
**Severity**: enhancement",54693,-3,Lowest,False
14.045264849168351,-6.676505870839068,3.3683414527414577,0.5333404006538118,1.8680079871844568,5.223857521679528,0.7945444919078373,-1.9293276921339104,-0.8990964547305519,-1.0124871562835778,-0.5227745999467874,-1.0195744569070977,0.9394739081929244,2.6439398571548383,1.3497333811730243,1.203166812659802,-0.2805867728795608,0.004930551363114155,False,c2,1,"**Author:** `ka.hing.chan`
**Description:**
In version 1.21.1, the special pages get an Server Error HTTP Error 500.
--------------------------
**Version**: REL1_21-branch
**Severity**: normal",51774,-11,Lowest,False
2.591670749477901,-2.33746286298749,-2.8120609435574817,0.6693890543162051,2.4870126939320976,-2.5384807740100297,-1.4768279882098376,0.2428184986126536,-3.466678865717822,-2.9763560548404335,1.4966805279268889,-1.9162903595380643,3.3209154154186624,3.861555266843368,1.9730845582878942,-1.390617460993571,0.10609211719895417,-0.03495940961959376,False,c2,1,"**Author:** `mr.heat`
**Description:**
The server http://bits.wikimedia.org/ is insanely slow since two days. Requests almost never return anything. The requests time out instead. This leaves all Mediawiki projects (including Commons) naked without any CSS (except for my user CSS).
Maybe an DNS issue?
Is there an DoS going on?
I'm sure this is not an issue on my side because I tested this on different computers using different internet connections. It's the same everywhere.
I'm in Germany. Here is the relevant part of a tracert:
C:\>tracert bits.wikimedia.org
Routenverfolgung zu bits-lb.esams.wikimedia.org [91.198.174.233]:
[...]
8 50 ms 51 ms 52 ms ge0-1-0-cr0.ixf.de.as6908.net [80.81.192.244]
9 58 ms 56 ms 59 ms xe-5-1-0-core0.nknik.nl.as6908.net [62.149.50.42]
10 54 ms 55 ms 54 ms xe-0-0-1.cr2-knams.wikimedia.org [78.41.155.38]
11 57 ms 56 ms 56 ms bits-lb.esams.wikimedia.org [91.198.174.233]
Ablaufverfolgung beendet.
I can't explain why the tracert looks so good. Requesting any bits URL in the browser almost always times out.
--------------------------
**Version**: wmf-deployment
**Severity**: critical
**See Also**:
https://rt.wikimedia.org/Ticket/Display.html?id=5118",50257,-16,Unbreak Now!,True
-5.331624788904838,3.7930493478234872,0.3190615087578941,-7.481292095639079,-5.1423030038990625,-4.043537358271942,-2.130034235225879,-3.974370142052559,1.8236099009409374,3.794919283324841,3.117561437976715,2.9108356660379684,-0.7652929374461275,1.115125638211567,-1.8487918984770197,1.848486373603968,0.6016754077551651,2.294240313074848,False,c2,1,"Attempting to log in via <https://meta.m.wikimedia.org/wiki/Special:UserLogin> does not work.
I input my username and password, submit it, the site says ""Login successful"", but when I try to visit <https://meta.m.wikimedia.org/wiki/Special:Watchlist> or other parts of the site, it says ""Please log in to view or edit items on your watchlist.""
I'm able to log in via <https://en.m.wikipedia.org/wiki/Special:UserLogin>. This problem seems specific to meta.m.wikimedia.org.
--------------------------
**Version**: unspecified
**Severity**: major",49647,-18,Unbreak Now!,False
-1.695173514687584,-2.6596842711987048,-2.590820712082591,-2.0313033202588153,-1.8070959493521963,-3.305810248217573,-0.832516392100791,1.1899017628361759,-3.026931501938451,-3.4362982380853806,0.7723183839875971,-1.297056977148514,-2.931241654836752,-1.2633429746279417,-0.6319739063866914,1.0553207814561814,1.0648596496503175,-0.759196504470911,False,c2,1,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.
On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].
Please log this automatically account creation on manually login also in the newusers log. Thanks.
--------------------------
**Version**: unspecified
**Severity**: critical",44434,-40,Unbreak Now!,True
-9.275449310369062,1.8000682702651112,-4.434342876665344,1.5693349191082224,-0.32460590342305684,-3.4588459482216134,1.0707980221999964,-2.316873186866345,-2.12970299927749,-0.6692402524517931,-2.794377430385252,-0.1967384871551361,-0.9564248605115386,-0.16473652870263233,-1.3136831941598377,0.24175671599305193,-1.0067977042186744,-0.6305860619624712,False,c2,1,"When using $wgSecureLogin, if a user leaves wpStickHTTPS unchecked, they are stil redirected to an https page after login.
I think it's because getFullURL returns a protocol relative url by default now, so preg_replace( '/^https:/', 'http:', $redirectUrl ) has no effect.
(NB: fixing this seems to prevent a user from logging in without wpStickHTTPS checked, because their session cookies are set with the secure attribute, but they are immediately redirected to an insecure page, so their session cookie no longer exists in the request.)
--------------------------
**Version**: 1.20.x
**Severity**: major",42541,-48,Unbreak Now!,True
-8.76918740817628,7.345351975773092,3.884309073986625,-2.7952181579279904,-5.591022401467649,-4.441136636624919,1.8115794003348116,-0.28546414665175374,1.2276987235966814,-0.8776077530255586,-0.6966168970719915,-4.813585706639865,0.17069521330347825,-3.2430829759754993,1.7590144573665123,-1.560138405332112,1.4928668291025489,0.6802854573724268,False,c2,1,"Early on I had lots of issues logging in. It seemed strange that I wasn't able to take photos and save photos for later whilst not being logged in and ended up switching between camera and app until I fixed the problem with an upgrade.
A new user might want to contribute before registering and uploading.
Expected:
login only occurs when you hit the upload switch
--------------------------
**Version**: unspecified
**Severity**: blocker",41711,-53,Unbreak Now!,True
2.281203701390529,2.5586055909324976,2.9461773778725906,-2.332392647853433,-2.0800761272878803,-2.1779768572693134,-0.22894734394013394,-2.375245504956316,2.5018661918348526,-1.2524235005706412,-0.4799458345503118,0.450815834996833,0.10887350859041867,-0.6558178823328342,0.5186003590876611,-0.831183299957136,1.448319015500742,0.5493165831694105,False,c2,1,"**Author:** `yoplitein`
**Description:**
On my wiki (http://beniki.beniesbuilds.com/) attempting to access the page User:Yoplitein/Python directly from index.php, rather than through a URL rewrite (/wiki/User:Yoplitein/Python), causes the software to return HTTP 501. It is not caused by extensions or any configuration customizations, I commented out everything I added to LocalSettings.php and the problem persisted. Similarly named pages, such as User:Yoplitein/PythonCGI or /Python2 work perfectly fine. I've tried to get the software to log output but whatever is causing this seems to prevent any logging of any nature. I'd be happy to provide further information if anyone could tell me how to go about procuring it.
--------------------------
**Version**: 1.20.x
**Severity**: normal
**OS**: Linux
**Platform**: PC
**Whiteboard**: aklapper-moreinfo
**URL**: http://beniki.beniesbuilds.com/index.php?title=User:Yoplitein/Python",50749,-14,Needs Triage,True
-6.452827803044215,-2.1004909429349734,-1.3618158163047838,-3.7726675928544022,2.9528704874942657,-4.120680597944764,2.8034945659355115,-1.8475839063350832,3.7058472859675717,-0.41986825765298263,0.7244090396030116,3.8541678735309697,-0.7583272950076765,-0.6478319721859362,2.332748096569243,1.8303951510543155,0.23229809701129267,-0.215009988942104,False,c2,1,"Login button can be pressed even when no username and password are fill in. Let's disable it until the we have some text.
--------------------------
**Version**: unspecified
**Severity**: normal",50587,-15,Needs Triage,True
9.864885114092123,-12.204225712550446,3.621360367434985,4.974408755895017,-1.0871089457159062,-0.8992417875863836,2.5118299282543584,-2.7791203694291875,1.894559223687063,-2.3747036241246575,-3.7027324668749775,-0.011712490780057871,-2.867849494789814,-0.03742044791923682,0.38903975077989106,-0.03756843015066752,0.20018045516884708,-0.05343752515675626,False,c2,1,"**Author:** `david.narvaez`
**Description:**
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://gerrit-review.googlesource.com/#/c/44930/",50362,-16,Needs Triage,True
8.187033520702656,1.4787361257892684,7.487464232944102,1.7515363999359765,-2.4622747459834873,-0.12249849921201683,1.6982222319078213,-2.9858898332718025,0.4303962238710134,0.48372535400888506,0.5018838764116103,2.085323045317927,0.08275842417506674,0.6133049136187072,-2.4384490689148,-1.1884827052535862,-1.7013059952461291,0.4831103690908207,False,c2,1,"Zero team uses a HTTP header to fake IPs. Until they implement a different way of faking IPs, investigate if Selenium can fake HTTP headers.
--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: gci2013 https://www.mediawiki.org/wiki/Google_Code-In#Candidate_tasks
**URL**: https://www.google-melange.com/gci/task/view/google/gci2013/5854732451053568",50218,-17,Needs Triage,False
0.4713774029393458,-0.42257571258228666,-2.522561757695799,1.864797012748339,-4.082354249892595,-3.288872236911562,-2.4927731280264664,-1.0649352307427673,-2.265655214548242,-2.99080627958862,0.7073914088572031,-1.0576036612453235,3.894754308086583,2.539110454008223,1.2161909302288825,-1.4348803429301529,0.9529476550435352,0.010968737227940117,False,c2,1,"**Author:** `mediazilla`
**Description:**
Hi folks,
since last night, I've been unable to access any Wikimedia site using https (plain http works just fine). I'm in Germany, and I'm getting served by the esams cluster.
I've tried a variety of sites, including https://en.wikipedia.org , https://en.wikinews.org , https://www.mediawiki.org and https://meta.wikimedia.org ; none have worked. (https://mediawiki.org , which is getting served by the pmtpa cluster, works.)
When attempting to connect to any site served by the esams cluster, according to Wireshark, there is never a reply of any kind to the inital SYN packet. Given the TCP traceroutes below, I'm inclined to believe that the problem lies somewhere in Wikimedia's cluster.
I already asked about this in #wikimedia-tech last night and spoke to Leslie Carr and Ryan Lane, but they didn't find any obvious problems. It was noted that another user had already asked about https access issues earlier that night.
Since it's still not working today, I'm filing this bug so it won't be forgotten. Thanks for looking into this - please let me know if you need more information or if there's anything I can do to help.
--- Sample curl output ---
$ curl -I -v https://en.wikipedia.org
* About to connect() to en.wikipedia.org port 443 (#0)
* Trying 91.198.174.225...
* 0x8001f2b0 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x80057550; line 1032 (connection #0)
* After 149981ms connect time, move on!
* Trying 2620:0:862:ed1a::1...
* After 74978ms connect time, move on!
* Failed connect to en.wikipedia.org:443; Operation now in progress
* Closing connection 0
* The cache now contains 0 members
curl: (7) Failed connect to en.wikipedia.org:443; Operation now in progress
$
--- Sample tcp tracerote on port 443 ---
$ tracetcp en.wikipedia.org:443
Tracing route to 91.198.174.225 [wikipedia-lb.esams.wikimedia.org] on port 443
Over a maximum of 30 hops.
[local hops]
3 12 ms 13 ms 13 ms 145.254.10.201
4 23 ms 27 ms 31 ms 92.79.213.138
5 19 ms 18 ms 19 ms 195.69.145.176 [xe-1-1-0.cr2-knams.wikimedia.or
g]
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
[...]
$
--- Sample tcp traceroute on port 80 (for comparison) ---
$ tracetcp en.wikipedia.org:80
Tracing route to 91.198.174.225 [wikipedia-lb.esams.wikimedia.org] on port 80
Over a maximum of 30 hops.
[local hops]
3 10 ms 10 ms 12 ms 145.254.10.201
4 31 ms 23 ms 27 ms 92.79.213.138
5 19 ms 18 ms 19 ms 195.69.145.176 [xe-1-1-0.cr2-knams.wikimedia.or
g]
6 Destination Reached in 20 ms. Connection established to 91.198.174.225
Trace Complete.
$
--------------------------
**Version**: wmf-deployment
**Severity**: normal",50208,-17,Needs Triage,True
-7.588340124145763,3.1435162097670073,-1.7696691226572607,-3.072221011287589,2.3866159696324716,-2.1582800925051666,1.611165531992679,0.9181595263515435,2.425599819306072,3.5001353607776924,3.010881441181621,0.44253519069887726,1.4369757680881117,0.1573150473927898,-1.0275862264269486,-0.2880083304261857,-1.0016120647788103,-0.679040161513226,False,c2,1,"The new ACUX shows this link ""(help me choose)"" prominently on top of the first textfield. This is a wikipedism that has several problems:
* Most MediaWiki instances don't have any username policy. With that link enforced you need to create a wiki page not to show that link in red. See for instance http://www.mediawiki.org/w/index.php?title=Project:Username_policy&action=edit&redlink=1
* Even if you do have a policy (like English Wikipedia has) this is probably not a page you want all new user to look, scared that they might be doing something wrong. http://en.wikipedia.org/wiki/Wikipedia:Username_policy is so dense and boring that it might drive potential new users away.
I'm not sure how to force a wrong username and I don't want to create fake accounts trying to test this, but I bet when you try to create a ""blacklisted"" user name you get an error message. Place the ""(help me choose)"" link in the error message instead, since that is the place where legitimate users will need it.
In the meantime most people just trying to register with their NameSurnameXYZ and other innocent variants will just go through, unaware (for good!) of the dense boring policy they just followed unconsciously.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47801",49704,-18,Needs Triage,True
-2.581069199686225,-1.3604686090327327,-1.0929226359714246,-0.10281964498107465,-1.0659423296798534,0.5741233500188241,-1.9779484682123032,-2.6109382697000063,0.9633540324277876,5.250373162679111,-0.6463041939848639,-1.0904504844702518,0.385037291171634,-0.9025391758688381,-0.18631742960763997,0.22905819048001344,-0.982962944560933,-0.0016584883284804786,False,c2,1,"**Author:** `Thehelpfulonewiki`
**Description:**
When I logged in without a username that exists, I got the message ""There is no user by the name ""Thehelpfulone3"". Check your spelling, or go to Wikipedia's signup page to create a new user account.""
""Wikipedia's signup page"" links to https://en.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup. Can we change the wording from ""Wikipedia's signup page"" to something better? I'm open to suggestions, but as a first idea: ""click here to create a new user account""?
--------------------------
**Version**: unspecified
**Severity**: enhancement",49695,-18,Needs Triage,True
3.253737717527778,-3.682143871930476,6.503327096999577,-0.3124712413961517,5.668054461012913,-5.027402340254889,-0.11074607386991442,-2.4899098645157305,-1.729066371286453,2.445114909592154,0.3717685913435993,-0.5463454376472068,-1.6552367645722903,0.43610385299766286,-1.3672607132149377,-1.1488178332882073,-1.078934872161096,-1.372218226946356,False,c2,1,"Screenshot of meta.m.wikimedia.org's user login screen inexplicably showing a ""W"" icon
When I go to <https://meta.m.wikimedia.org/wiki/Special:UserLogin>, I see a large, prominent ""W"" icon. I don't know why.
The icon is <https://bits.wikimedia.org/static-1.22wmf2/extensions/MobileFrontend/stylesheets/specials/images/W.png>. I've also included a screenshot with this bug report.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://meta.m.wikimedia.org/wiki/Special:UserLogin
**Attached**: {F10879}",49648,-18,Needs Triage,True
3.172112429320387,3.578366005779106,5.0010062716829715,-2.0622224076763467,-2.3672146030079393,8.077537384742747,1.5354221176011178,0.27827085951174924,-1.175202176160549,0.8591038528848856,0.805299807734023,3.7634356485229254,-0.11464394711429637,1.195343202993591,-1.2172121267489402,-0.5766642879154255,-0.19322274317563104,-2.0360328777473544,False,c2,1,"Since https://gerrit.wikimedia.org/r/#/c/58728/2/includes/site/MediaWikiSite.php wfScript is used to construct the API-URL for Http-Requests to other wikis. This makes no sense as wfScript uses local configuration which can lead to a broken URL.
--------------------------
**Version**: unspecified
**Severity**: normal",49242,-20,Needs Triage,True
6.593230209422936,-1.6505462339628885,-2.162504276903899,-3.5250746774864736,-1.1863195599474556,-2.9065219657229973,1.4796740842189307,2.1171986045031495,0.34120266285173806,-0.1903833546756255,-3.7684952304434596,-0.25625188336142357,-2.180403223019546,-2.8288240634496042,3.5693109092750666,-0.9637303968288635,-0.3664613431650179,1.1002391805649612,False,c2,1,"**Author:** `dwarika1987`
**Description:**
http://toro.wmflabs.org/wiki/Special:UserLogin?useAgora=1
When we are clicking on Secure sign in then getting message like ""Google Chrome's connection attempt to toro.wmflabs.org was rejected. The website may be down, or your network may not be properly configured.""
--------------------------
**Version**: unspecified
**Severity**: normal",48967,-21,Needs Triage,True
13.778180650544826,-2.101142224093044,7.960562346189359,3.955906774138695,1.0354436128187636,0.1181800499223089,0.46589103850953695,-2.211190324313353,0.6010316671258356,1.4343879446939312,0.11270810564736466,-2.078560222941558,0.7483512094434355,-1.563584513065761,0.6236905318795332,0.1863509298714362,0.3069463492875921,-0.3374319891929032,False,c2,1,"**Author:** `anyumousse`
**Description:**
From Logon page (http://toro.wmflabs.org/wiki/Special:UserLogin?useAgora=1)
i chose Tools then Special Pages (http://toro.wmflabs.org/wiki/Special:SpecialPages)then the link for Log In/Create an Account and got the old style login page (http://toro.wmflabs.org/wiki/Special:UserLogin) without the green new account ""Join testwiki"" button.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC",48963,-21,Needs Triage,True
-0.7558090087234186,5.858931814856781,0.6250225831109759,-5.258579888806546,4.248837151392971,-0.9856325835047846,0.26807007950402184,-1.890513475529771,-0.2009216654984389,2.4308214788845204,-0.43156632252953253,0.06329014517892517,-0.8596755065309898,1.8520971928101364,-0.4144101712306263,0.2950505445399563,0.03812360939545312,-1.3496340254077646,False,c2,1,"**Author:** `testingwithfire`
**Description:**
I'm using the new login process (useAgora in query string).
I have HTTPS Everywhere enabled in FF 19.0.2. I suspect that HTTPS Everywhere may also be buggy on this browser because I see some other unrelated sites that should have HTTPS in the URL don't have it.
When I copy the ""http:"" link for the toro server into the FF location bar, the http disappears and I'm left with something that looks like:
http://toro.wmflabs.org/wiki/Special:UserLogin?useAgora=1
I also see a ""use secure server"" link, which looks like it's dead:
""Firefox can't establish a connection to the server at toro.wmflabs.org.""
As a user, I would wonder why https:// isn't in the location bar and why I have to click another link to use a secure server. Again, this may be an issue with HTTPS Everywhere.
--------------------------
**Version**: unspecified
**Severity**: normal",48962,-21,Needs Triage,True
-6.358777299627242,2.99737695385695,3.2990696949025526,2.131117330921556,-4.439623332402438,-0.020394210210071373,-2.3979460584982313,1.4886982986085546,5.857425891737089,1.0195908097207163,-0.8757891244497884,2.384523514931735,0.5933150584360711,-0.7128690010211765,-0.09954964999799998,1.443833134881611,0.2960291252398335,-0.6814265823617389,False,c2,1,"- user should not be logged in
- go to http://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page
- click the star in the top-right part of the page (watch icon)
- ""Please login or sign up to watch this page. Login/Sign up"" section opens at the bottom of the screen
- click Login link
- I was expecting login page to open
- http://meta.wikimedia.org/wiki/Missing_wiki page opens instead
--------------------------
**Version**: unspecified
**Severity**: normal",48649,-22,Needs Triage,True
-0.8459605487671324,1.210259086957981,-1.1762024632324817,2.2041210711819734,3.7567251243587783,2.7823472800055056,-0.7977696656410203,-1.3031655079263684,-1.4882945972106258,-1.2830213086087654,0.3452435277857817,0.1970158352961595,2.8248585226116814,-1.0034333202709145,-0.9176058751249583,0.15958249762047721,1.936346549944138,-0.8202058880149348,False,c2,1,"from https://app.asana.com/0/1891117540465/2773569521405
Dec 15, 2012 Diederik van Liere:
HTTPS traffic poses a second challenge and that is that it generates two hits in the server logs: one nginx hit and on squid hit. Nginx forwards the request to squid and so the squid hit contains the IP address of the Nginx server and not of the original requestor. This means that we will over-estimate the mobile usage from the US and The Netherlands (were the data centers are located). This will affect Andre's country report.
--------------------------
**Version**: unspecified
**Severity**: normal",48276,-24,Needs Triage,True
-3.799979561266465,1.0397128911162028,0.05940004602615545,1.4299942792308507,-0.40566745701473494,0.06187388669211891,-2.027106425731491,0.6433813878174558,3.131239290318521,1.5473474513870364,1.5044196312295717,1.2751945886559224,1.2213826422030496,-1.192416558672884,0.8889554961148693,1.049990900198952,0.38439151776987823,0.06409467813209369,False,c2,1,"Try the following:
1. Browse mobile site (stable or beta) as a logged out user
2. Find any article, tap the left navigation menu and tap log in
3. Enter login credentials. You will be taken to a post login overlay that says ""Return to Main page.""
Now try:
1. Browse mobile site (stable or beta) as a logged out user
2. Tap the left navigation menu and tap the Watchlist link (or the Uploads link if you're in beta)
3. Follow links to log in and enter login creds. You will be taken to a post login overlay that says ""Return to Special:Watchlist"" (or ""Return to Special:DonateImage"")
We should make sure users are able to return to the article they were on before entering the login/signup funnel, not just the special pages. Also, we should make sure the that titles of special pages are consistent with the copy on the mobile web – Special:DonateImage should be Special:Uploads – so users won't be confused.
--------------------------
**Version**: unspecified
**Severity**: normal",47996,-25,Needs Triage,True
3.549558829208165,-7.451775118087067,9.74737350110436,2.7346464129875767,-2.576813258602786,-0.6962567919235296,0.169349254296975,-0.1943177646178024,1.0967995005904272,-0.9780841324744496,0.44267342099099993,-1.2939447013807608,-0.9150376038483392,-1.2029523451210755,-0.5863864317313245,-0.7419172332276445,0.20786466814785332,-1.3258435623022233,False,c2,1,"[blocked] The page at https://translatewiki.net/w/i.php?title=User:Amire80&action=formedit&debug=true ran insecure content from http://maps.googleapis.com/maps/api/js?language=fi&sensor=false.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44224",47697,-26,Needs Triage,True
5.381736561538064,1.5597810619858894,1.0469036429234357,-5.894816053834327,-1.2485033184543357,2.7852181332421564,-1.012407389808172,2.513850234400861,-1.7465070812713654,-1.3665462488351352,-0.8592939183130706,-0.4450181262137721,1.3586803431259162,-0.4132782702718929,-1.2968563505422344,0.3988203249642968,-1.697134625143951,-0.7051029667054254,False,c2,1,"https://commons.wikimedia.org/wiki/File:Wikimedia_Commons_Android_App_Login_Screen.png shows the text
LOGIN TO UPLOAD MEDIA TO WIKIMEDIA COMMONS
centered in one line. However, in a Nexus S with Android 4.1.1 is appears with the text in two lines and aligned to the left. Ugly:
LOGIN TO UPLOAD MEDIA TO WIKIMEDIA
COMMONS
Also:
- Why such a long string, which is not even accurate? You have to login for anything.
- Why all in upper case? Seems to be unusual for a Wikimedia UI.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Platform**: Smartphone",47393,-27,Needs Triage,True
-0.1950730231774198,2.5164472781550202,1.140827782778235,-4.164497280612352,-7.505221859506365,1.9334857463386232,-1.3983288470240955,0.8583038542689673,5.2855643104291214,-1.8956895328998016,-1.4258107919939829,1.2669569862828725,-2.798654340198163,0.08789779987666702,1.8781138381666427,0.3370465260125281,-0.9316539014907679,1.5682084790810766,False,c2,1,"**Author:** `wikimedia-bugs`
**Description:**
Allow users to log in with Persona instead of having to create a new account.
Some documentation on persona and how to integrate it can be found at: <https://developer.mozilla.org/en-US/docs/Persona>.
--------------------------
**Version**: unspecified
**Severity**: enhancement",47220,-27,Needs Triage,True
0.4093695054825299,-7.287978946780067,9.572654127917168,1.8415613634151553,-5.268137207122207,-1.5943625626988671,2.3158673443113402,-0.3541055426047478,1.34412865451403,0.4499301004313514,-0.16383788735498817,4.516988345516925,-0.29242037222127326,1.5773149509106803,-2.512377799480862,2.617475882660249,-1.0775556483505557,-0.7808100499584403,False,c2,1,"Go to http://en.m.wikipedia.org/wiki/Special:UserLogin?welcome=false&returnto=Tanks%20in%20the%20Spanish%20Army&returntoquery=article_action%3Dwatch&type=signup
Get login page. Notice type=signup in url...
--------------------------
**Version**: unspecified
**Severity**: normal",46658,-30,Needs Triage,True
0.9294433505315021,-11.429391599606829,3.578948673126227,8.815711895755964,1.4020486031776687,-0.6688617701511858,4.640174370532274,-1.4030227564489275,1.97324748399321,0.1498315642564858,-0.09741509773632462,-0.07605559848978061,-1.1920403219242788,-0.22702283772604392,-0.4171502037249395,0.6627031599825661,1.4776901842941583,1.8023641497922533,False,c2,1,"**Author:** `massaf`
**Description:**
mobile frontend account creation page
The account creation page and login page have too many visual differences, including typefaces, font sizes, and margins/paddings. See the attached screenshots.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F10746}",46646,-30,Needs Triage,True
3.5992954641178883,-2.2727118366826424,1.0604109956678087,-1.2556288433987217,1.401770488704655,-2.4999766141495,3.604390654281821,-5.050568325527845,-2.1074488993499325,-2.1957235918300837,-1.613043619417107,0.653090908719397,-1.3467332685473883,2.4170162915459734,0.6787276929235393,2.0434722260378972,-1.9856339751144076,0.9289703285599791,False,c2,1,"As reported by xyzram in #wikimedia-dev, http://wikitech.wikimedia.org/view/SearchShards is currently outputting an HTTP 500 error. It's a giant wikitable. I imagine it's simply memory exhaustion.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: http://wikitech.wikimedia.org/view/SearchShards",46491,-30,Needs Triage,True
-2.4551850029169344,-1.5336844133724963,-6.073211590139543,-4.421752309980733,0.7730922738430364,-1.3897319402014978,-1.5112201263134954,0.5125640948246846,-0.4875022093033097,-0.6484731266315977,-1.883424788833593,-0.2955976416709357,-0.3556833458962618,-1.4694243361372372,0.4438621437402315,-0.5901988152808298,0.2640491710802402,-0.03757584081773402,False,c2,1,"Please set $wgBlockDisablesLogin false for wikimediafoundation.org.
In https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php it is currently set to:
'foundationwiki' => 'true', // RT #690
which can just be deleted.
It makes no sense to have this enabled since wmf.org is a public wiki and it only prevents them from editing their talk page while blocked, which is not a concern.
There was also some discussion at https://wikimediafoundation.org/?oldid=87432 about disabling the setting.
I will ask Guillom and Philippe to comment here as well.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",46473,-31,Needs Triage,True
-4.373654025249336,-5.41211016895511,0.8698809082874845,2.0961886661880147,5.994453787537438,3.701017513276488,-0.7628778308347375,2.0929093185303604,5.306746993884638,0.8493442228465868,-0.18207671058748165,0.6229087134546807,-0.8728410417080745,2.664540891781799,-1.2825162283485607,0.5708909904968867,0.7545110219624693,-1.9696125379525204,False,c2,1,"Login with an account that doesn't exist.
The error message should have a margin.
--------------------------
**Version**: unspecified
**Severity**: normal",46355,-31,Needs Triage,True
2.4779661455823176,4.277569307737597,0.9844277150949345,0.8402288105905436,-2.821549600153067,4.888048314889256,2.382217819445585,0.1451884923790961,-1.908471204950832,-1.4507444117375239,-2.627815646357726,1.2683854909343293,-2.3315234670140326,1.4959322147189802,-1.0219398471208576,-2.900279490594874,-0.3329475673877458,-2.0278788833457493,False,c2,1,"When $wgSecureLogin is set to true, the OpenID login page should redirect the user to HTTPS so that all transactions occur over TLS.
--------------------------
**Version**: master
**Severity**: normal",46353,-31,Needs Triage,True
0.7968151234746066,0.8312105139146375,8.022437367001057,-7.478657066300584,-1.7247700357612292,-7.301437102590547,0.790139226340334,3.506049616300827,3.485568076421969,-1.1156157654819898,-0.9807508860101022,1.568447457372755,-0.14203405965840155,-0.6996648837777135,0.5836285519700537,2.821895555714307,-1.5624741427269282,-0.29551999246379435,False,c2,1,"Go to http://en.m.wikipedia.org/wiki/Typhoon_Rusa
Click the watchlist star and click login
(Note you are now on https://en.m.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Typhoon+Rusa&returntoquery=article_action%3Dwatch&wpStickHTTPS=1)
Login
Click back twice so you are back on http://en.m.wikipedia.org/wiki/Typhoon_Rusa and hit refresh
You are no longer logged in
Expected:
Login on https should log you in on http
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43909",46330,-31,Needs Triage,True
1.599584524611799,1.7346696472437735,2.656529093902929,-2.6418088441279117,3.7844039495938806,-2.9606400334128953,-0.35060547628812877,0.6349101456595219,1.4538307173882241,-2.024140488547046,-1.2553411254341984,-0.3763552551451882,0.4389960763419589,0.030826095889492144,-1.224112863724887,0.22997535432701094,0.49323390597782435,2.2303261875772202,False,c2,1,"**Author:** `buster2`
**Description:**
The change from Wed, 29 Feb 2012 in includes/HttpFunction.php broke mediawiki’s proxy support.
see https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=commitdiff;h=1d065d50f63676e081b0101f849aaa0249b950c7;hp=2730e89017079d4675a8ef9d353255661a03a112 in function proxySetup()
- if ( $this->proxy && !$this->noProxy ) {
If there is a proxy set AND we should NOT USE proxy then return instantly without setting a proxy.
That sounds reasonable.
+ if ( $this->proxy || !$this->noProxy ) {
If there is a proxy set OR we should NOT USE proxy then return instantly without setting a proxy.
(Correctly) Applying De_Morgan's laws we get:
If there is a proxy set AND we should NOT NOT USE proxy then return instantly without setting a proxy.
Simplifying we get:
If there is a proxy set AND we should USE proxy then return instantly without setting a proxy.
That doesn’t make any sense.
--------------------------
**Version**: 1.20.x
**Severity**: normal",46113,-32,Needs Triage,True
-0.8519425563233858,2.603782133581447,-0.5220398898259742,1.6752738345732698,1.1446534893434817,3.113773918114693,2.8050178466184095,0.020705670546353583,1.2892740920714227,0.8290818336837384,1.635932113866302,2.153746429134751,0.9162219248154426,1.9384749336369413,0.9581146460539625,-1.0117345734596757,-1.1487248676600257,1.4877019945128727,False,c2,1,"Visiting https://integration.mediawiki.org/ direct or with a link from gerrit gives a bad certificate warning, because the certificate is for *.wikimedia.org.
It is possible to get the right certificate here? Thanks.
See also bug 40697
--------------------------
**Version**: wmf-deployment
**Severity**: normal",45583,-34,Needs Triage,True
-6.942329498645664,-2.6371391476253407,-7.108112255720767,-3.0512161444850676,2.6116269908172827,-0.292295079818907,-0.09607219285578061,2.657460928463572,-0.4652935025297148,-2.386505117043084,-3.21685689773999,0.8641750296914148,-0.45743871358998955,0.003093009739884245,0.18541912322827514,0.3227772983073524,0.5577808194799296,-1.3003242234143069,False,c2,1,"When $wgSecurelogin is true, the login has the checkbox ""Stay connected to HTTPS after login"".
If this option is left unchecked, the user's session cookie is set with the secure flag, but the user is then forwarded to http, and loose their session.
If you have not patched bug 40995, then you will often not see this, since the session frequently will be started under an insecure connection, and is not refreshed on login.
--------------------------
**Version**: 1.21.x
**Severity**: normal",44832,-38,Needs Triage,True
-4.166371060948893,4.692114449305194,7.056642239974689,5.297788529773768,-4.149645121066127,5.684202916319938,0.764320230105918,-3.6437683988324197,1.9728495422671346,-2.2330606738667322,-3.1887158266237448,-3.211576594748017,-2.9165552071373098,1.0640378771589685,0.8397879141014641,-1.2818099152217157,1.1515541339195001,-1.1805492976752867,False,c2,1,"**Author:** `Thehelpfulonewiki`
**Description:**
Per recent guidelines to document every change, I adjusted the URL for the upgrade notification message at the bottom of this page to use https:// instead of http://, per a request by a user.
--------------------------
**Version**: unspecified
**Severity**: enhancement",44823,-38,Needs Triage,True
3.306767436006536,-3.232800477281536,-1.1609980852879982,0.3896736536727339,-2.826851236006509,0.6893941914552764,-0.35842766519623925,-1.1758406655754918,0.6802394983942063,-1.2611763332105088,-0.5382742645712675,-1.5005462514127756,1.7180179927241266,-0.4745912233241629,-1.5078955834018677,-0.04719203988094023,-0.6247608669894584,0.2828567040566867,False,c2,1,"If you try to open a https Wikipedia page (for instance https://en.wikipedia.org/wiki/Wikipedia) on a mobile browser (for example Android 4.1's default browser), you get redirected to a non-https Wikipedia page (in the example above, http://en.m.wikipedia.org/wiki/Wikipedia).
It should preserve the user's choice of http vs https, or always redirect to https.
Version according to Special:Version: MobileFrontend (Version 0.7.0) (a572c13).
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: Smartphone",44605,-39,Needs Triage,True
2.8316853199376646,-15.75952757739788,9.048290183843775,6.410805361990528,-2.126772743313943,-1.0333867946825224,3.2024613672297866,-1.6832687410044325,-0.04244958057429449,0.22282611751206005,3.6391598751522465,-0.1305771120160213,-3.8989091135198857,-0.0031762455846919835,1.130031776741757,-0.6693116216879711,0.38088913207432973,0.008384242250328855,False,c2,1,"https://www.wikimedia.org/wiki/A => http://wikimediafoundation.org/wiki/A
--------------------------
**Version**: unspecified
**Severity**: normal",44409,-40,Needs Triage,True
5.464532498903235,-3.7677918509392168,3.898283299433242,-1.2869010471353355,-3.828340323300366,-2.161159744729794,-0.4902077003443104,2.5241509852142823,2.1947688247758315,-3.1811980213180115,-4.282695035129848,5.259241095225057,-1.3607909634102375,-2.253846574512459,2.0320480231945997,2.474438955187313,0.5347793357337765,1.2488643799543067,False,c2,1,"Seems to be introduced in Iaa04af187d182c0253931f3b4d099bbdd453bdf2. Could be CLI script or something else.
--------------------------
**Version**: master
**Severity**: minor",44146,-41,Needs Triage,True
-2.155160813350036,-3.5980388366880796,-2.9648842344939474,-6.374353619393642,2.872046596103624,-3.785545457108231,-0.8819048116542181,-1.1007690797380845,0.3046027243601914,0.8590193540032729,1.2383779240023025,-2.7107210825062062,0.36105595964585824,-1.0748614469400772,-1.473470072219822,-1.0251006418025985,-2.206160469820959,-0.18035126041772065,False,c2,1,"When I go to <https://labsconsole.wikimedia.org/wiki/Special:UserLogin>, I see:
Username: [ ]
Password: [ ]
Your domain: [labs]
Token: [ ]
[ ] Remember my login...
The ""token"" field is apparently completely useless for a typical login. I'm not really sure why it's there at all. It confused the hell out of me when trying to register a new account. It should, at a minimum, say ""Token (optional)"" or something.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46179",44131,-41,Needs Triage,True
-4.96972693302825,-1.2280499643830982,-4.221000254222391,1.9608694412215875,-0.9673582842463315,1.4358411594303073,1.8312966807445346,1.0193222890488682,-1.1649739361113243,-0.38276788010424934,0.4800335202332313,2.115012795551875,1.9395300430411182,-0.48098924032664225,0.9614666646863332,0.04661147223733714,-1.0944549517708486,0.1034627557127672,False,c2,1,"**Author:** `jgerber`
**Description:**
Creating thumbnails from videos on backends without POSIX access is expensive since a local copy of the video has to be created in /tmp first.
TMH should create thumbs from the public http url and seek using http range requests instead.
avconv supports http so that part should be possible.
One open question is if the public url is the best one or if we can use a swift url instead.
--------------------------
**Version**: master
**Severity**: normal",43744,-43,Needs Triage,True
-2.973884639642953,-0.7643625741367188,8.561774345382645,7.895658195179443,2.8893021421509166,1.0879860999970752,2.2073594115926793,0.607282356079682,1.592707928471452,0.14411729754943625,0.37314398449124164,-0.8002374228819391,-0.735964759500046,1.3783939228478816,-1.1218565426185343,1.4595540470257928,-1.4352486158685,-0.6333590301621546,False,c2,1,"In beta click a link on a page
The page loads dynamically
CLick the menu button
Click login/settings
Click back - get taken to first page
--------------------------
**Version**: unspecified
**Severity**: normal",43710,-43,Needs Triage,True
4.454097241558937,-2.0402946459305813,-9.434191486456296,-5.9917774591709945,-0.25712642926374446,-1.8731781032843,-0.21103676579124375,-3.7652071116853016,1.5526102094846672,2.5937457118734963,-0.9696382140289979,-5.245416168942024,-0.5150754233458352,-2.895670120109544,2.4936991393000847,2.4195385343302545,-3.044888395109777,2.128839807671481,False,c2,1,"https://www.wikidata.org/
""You attempted to reach www.wikidata.org, but instead you actually reached a server identifying itself as *.wikimedia.org.""
--------------------------
**Version**: unspecified
**Severity**: major",43486,-44,Needs Triage,True
8.83656492207146,2.83760427629516,-1.2932629238845053,-6.152294645458587,1.6637621347131906,2.8203212843856917,-0.6383163250282129,-2.076274107650408,-2.365226561849912,1.1984187216968891,0.8868867231389466,-2.384326148800505,-1.5311636759089575,0.7358037733128127,-1.9729303732502759,-1.2417948098847311,-0.5176407807957443,0.9632509825967459,False,c2,1,"Screenshot of the English Wikipedia's post-login screen showing a broken Wikidata icon
After successfully logging in to the English Wikipedia at <https://en.wikipedia.org/w/index.php?title=Special:UserLogin>, I'm presented with a broken "".wikidata.org"" icon. It looks like it's referencing <https://www.wikidata.org/wiki/Special:AutoLogin?token=aa5a4a580a35eb19530cb5759b0cff48>, which doesn't work properly. Screenshot attached.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Attached**: {F9634}",43429,-44,Needs Triage,True
-2.3337054933635395,3.1887570611690244,0.9394842937535621,-2.107631595842177,-0.21790442386708603,-2.6105142189460704,-1.650196990886963,-4.642342193626289,-2.0510830814385086,-0.9609550486091623,-0.2873204442449504,-0.33271972570999087,0.5532266112052975,0.042741118278607715,-0.7066676141043651,2.0339345616190485,2.3350254016837386,1.7005134128862058,False,c2,1,"**Author:** `savannah.cozette`
**Description:**
Hi,
I've got a problem after user login my mediawiki.
We recently change our server and since I have a problem with the page on which users are redirected after login :
it redirects towards Home page but without the www. before adress so there is a 404 error.
I've tried to change the page with $wgRedirectOnLogin either in LocalSettings.php or in DefaultSettings.php and that does'nt works.
Moreover I tried to enter directly the adress of Home page as an external link, with all possible syntax ([http://www.], [[http://www.]], and even 'http://www.' or ""http://www."") but nothing is working.
Can anybody help me?
--------------------------
**Version**: 1.16.x
**Severity**: normal",43418,-44,Needs Triage,True
-3.555121710074795,3.432197834666443,-0.5869602329499468,-3.5554797712772976,0.7214679271802051,-0.3041953323323,2.8082314850972496,1.0903357033376695,-0.6314593601747809,-2.116895128333414,-2.106594865012266,1.3098964190986384,-2.340013220749533,-0.23759998584490738,2.091291889837964,2.226100291040564,-2.6806543377229723,0.7768805399820471,False,c2,1,"MobileFrontend appears to be overriding the Special:Userlogin template on the desktop view as long as the extension is enabled.
It may not be checking whether it's actually in mobile mode...
--------------------------
**Version**: unspecified
**Severity**: blocker",43282,-45,Needs Triage,True
3.5946672211640487,-2.5424399020335873,0.32311574965455137,1.6654092309404294,1.3573787818252376,3.056950482355397,0.9487721333747867,1.144594199669453,-1.21703187751204,0.38442060229017905,1.8083082197133042,-0.7310128413538819,2.9165921423145917,-1.7477153001199222,0.8109387003673438,0.3705363405626529,-0.7333300755042982,-1.0225922319416003,False,c2,1,"**Author:** `M8R-udfkkf`
**Description:**
When on a secure wiki page (SSL), such as
http://en.wikipedia.org/wiki/File:Vulpicida_canadensis_44260.jpg
and you click a non-secure (http not https) link, such as
http://www.mushroomobserver.org/image/show_image/44260
the referer is sent. This is against RFC 2616. No referer should be sent.
Per RFC 2616 § 15.1.3 (http://tools.ietf.org/html/rfc2616#section-15.1.3):
Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.
General http referer info: http://en.wikipedia.org/wiki/HTTP_referer
--------------------------
**Version**: unspecified
**Severity**: normal",43265,-45,Needs Triage,True
7.910584240161867,0.9241984450234053,-0.8312005199757788,0.6760563863642808,-3.648108805165327,0.8392398393191332,-1.832586294724834,-2.3757513915616535,-1.2128830652246205,-1.618800380595331,-0.8309366849447204,-1.3150034412402156,1.6559678587250053,-0.014152303463767169,-0.6471166969706141,-0.07921492506540023,-1.1269369844517005,1.3621105537447555,False,c2,1,"**Author:** `andrew`
**Description:**
Attempting to install using Oracle as the backend. Fresh install of 1.19.2. PHP with OCI8 is working fine in other apps.
Going through the MW installer, after submitting a configuration on the ""Connect to database"" page (specifying the Database TNS, Database username, etc.), clicking Continue results in an HTTP 500.
In my web server's error log I see:
PHP Fatal error: Call to undefined function mb_check_encoding() in /var/www/wiki.example.org/includes/db/DatabaseOracle.php on line 307, referer: http://wiki.example.org/mw-config/index.php
--------------------------
**Version**: 1.19.2
**Severity**: critical
**OS**: Linux",43146,-45,Needs Triage,True
12.37457437470941,-11.916457875753913,13.260751154401607,-3.311245777002829,-0.5006555491390413,-0.08301454625294968,0.5281826183330516,0.33352547042043323,-0.4650875519947776,-2.1534445632421986,-2.260623257059275,-2.097563941195971,0.7971887196711447,1.5948200284034257,2.1653527064051152,-0.9445024074920971,0.227241139810336,-0.009228525994242842,False,c2,1,"https://mediawiki.org/
returns
HTTP/1.1 301 Moved Permanently
Location: http://www.mediawiki.org/
expected result
HTTP/1.1 301 Moved Permanently
Location: https://www.mediawiki.org/
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://mediawiki.org/",43070,-46,Needs Triage,True
-1.3321198624017405,7.1075251498729735,0.3657219041369508,-4.662789790290551,-3.1326153274361888,0.19703473801774551,1.2954320472038354,-0.034836168367720605,-2.1205632513606325,-2.0522809875810104,-2.2989001958803694,-0.17182399549321237,-1.3677542444598796,0.2912585692209744,-0.571552191701449,1.753454043489469,-1.9931001554617989,-0.3944032388834593,False,c2,1,"Right now, if you log into the wiki under HTTPS protocol, then visit a page under HTTP protocol, it shows you as logged out. This is bad practice, because requires logging in again. The cookies should be shared in HTTP and HTTPS.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",43022,-46,Needs Triage,True
0.43249325835696206,-15.73087546797008,-0.7965979682565258,3.345542692618835,-1.7975576698458477,0.015061368506357864,1.4224926483150613,-1.2700112113025877,-0.19303828456140198,-1.1698628992338014,-0.26052736621707995,-0.8737069897520717,2.630703857555571,0.7924045663469563,0.5641490740745381,-0.406132244352412,0.009319349701377488,-0.2871579447588224,False,c2,1,"
--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: storypoints: 2",42550,-48,Needs Triage,True
-2.167566469430432,-4.015565178946707,-1.818299333307431,3.0777059003577882,3.8317319335172297,-0.8756848051713659,4.09857313638999,-2.2820342758467396,0.22654224728857442,1.0738048961573385,3.0639507050339625,2.3613119318954636,1.921151829869137,-3.6729162233391177,-0.10150484611011645,-1.4634799227853779,3.5267607096766946,2.947606592676288,False,c2,1,"There are some hacks that check HTTP_APPLICATION_VERSION and hide the header or logo depending on settings that came from our old iPhone and Android apps that did screen scraping.
These old apps are dead and we should remove the special-cases, which had caching issues anyway.
--------------------------
**Version**: unspecified
**Severity**: normal",42194,-50,Needs Triage,True
-1.0112646061655015,3.7816312071644695,-0.5601781751876036,-2.8574486587333228,0.7755796942790008,1.3409955091913786,0.9396415829961491,0.17911847312101398,-2.820248965392813,-0.6479009612150675,-0.75786397109905,1.1891406659124193,0.5775803704351739,0.6123932321426961,-1.135515948406863,-0.5702263713285944,-1.444148596402882,-0.8335892116285462,False,c2,1,"**Author:** `lowzl`
**Description:**
Patch against 1.19.1
If a DBError is thrown – such as when MySQL is returning the ""too many connections"" error – MediaWiki returns an error page with the HTTP 200 OK status code. This is quite troublesome, since automatic polling by Varnish only checks the status code of the returned page to determine whether the backend is healthy or not.
I have attached a simple patch to work around this problem. I notice I have to use the PHP header function directly instead of going via $wgOut – I suppose that's because the error page is being output raw instead of through OutputPage.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F9873}",41460,-54,Needs Triage,True
-5.450304150923973,-3.4537042737440586,0.11920419196338727,-1.3594142492690253,-7.304162267651844,-1.6940406648772868,2.0258341888740743,2.1566259080147736,4.765564375775235,2.128931316525132,2.1463492372730566,4.765200487441064,1.5442834882824652,0.18079305648240318,-1.3913033295468047,1.3673677448631676,0.06444910178513896,-0.1464743177736234,False,c2,1,"Make sure you are logged on.
From welcome page click on uploads and get taken to login screen
Click back button
nothing happens
expected: should go back to welcome screen
--------------------------
**Version**: unspecified
**Severity**: normal",41347,-55,Needs Triage,True
-4.093158544404229,-4.930809859548718,-6.273165765862791,-4.518403654980506,3.192158048288319,-4.187832099710998,-0.9615134355773236,0.9102534815627054,-1.596654063744346,1.5468940745965707,-1.1415509337524823,-0.00594827126022901,0.8716233779455944,-2.6637344627424158,-0.6987228624957451,-0.46934681675047896,0.7172699190393128,-0.524500160882168,False,c2,1,"Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though.
I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://status.wikimedia.org/",41325,-55,Needs Triage,True
1.698947539881456,-1.4539219313686758,-5.232610359594778,-6.54482373069905,0.5052152522631537,-2.308877043599927,-4.248126382273672,-3.170601320981943,-3.795593316120569,3.744612102799465,-2.245885174545933,-0.07440866918250899,-1.7577757412134334,0.08921811779906186,-1.6014260314492668,4.198838684331452,-0.8788220518338737,1.97175587984556,False,c2,1,"I use the app in Hebrew. After I press ""Uploads"", I get a login screen. The words ""Username"", ""Password"" and ""Login"" appear in English.
It looks like the words ""Username"" and ""Password"" are not even internationalized: they don't appear for translation in translatewiki.net.
The word ""Login"" does appear in translatewiki.net, and it's translated to Hebrew, but it still appears in English.
--------------------------
**Version**: unspecified
**Severity**: major",41291,-55,Needs Triage,True
0.43119630823836363,7.497953411845479,4.833652033174484,-0.15113203801697983,-0.79718693111205,2.532578087215266,1.4440794423346688,4.892084953860043,-2.3961303965004044,-1.2347432276239796,-1.6023674306950106,-1.7616054264073782,-0.55656687931089,0.0010939281409383383,0.7915080382559108,1.3433940755854217,-1.167865986397348,-0.43128228214488185,False,c2,1,"Page URLs are at least in some cases returned as HTTPS, even if the call to the API uses HTTP. The URLs should be protocol-less if possible, only using the protocol if one of HTTP/HTTPS is not supported, and otherwise act as a network-path reference http://tools.ietf.org/html/rfc3986#section-4.2
--------------------------
**Version**: unspecified
**Severity**: normal",40570,-58,Needs Triage,True
-0.07925182020188926,2.116594621479834,-7.427848020586076,-4.33475059425804,-1.3843612826086773,-3.405582424863181,0.27156736212344423,-5.781394745606117,0.3047536646139264,1.1450057759954033,-0.8001262138151359,-3.2835685468697813,0.7096253759350231,-1.9587174752768695,2.9209081101344934,0.643027899980769,-1.6573271491222412,2.9161438194513156,False,c2,1,"https://en.m.wiktionary.org/ is giving me this error: ""You attempted to reach en.m.wiktionary.org, but instead you actually reached a server identifying itself as *.wikipedia.org."" followed by warnings of possible dangers.
--------------------------
**Version**: .5
**Severity**: normal",40434,-59,Needs Triage,True
-3.0139556373853527,0.8119103716740526,2.1946337514795964,2.0522635834218295,-0.24891712599161303,5.487054901901663,0.6562304019590908,0.9053958212249967,0.8079613024843166,-0.9279990540845771,-0.9223006205094304,0.30579766283021614,-0.6347766418716771,0.38708256060595847,-0.32690451362978834,-1.2454551979924682,-0.08838779450176037,-0.8082109336645849,False,c2,1,"There is currently no way to create a Commons user account from within the app.
--------------------------
**Version**: unspecified
**Severity**: normal",40270,-60,Needs Triage,True
2.5125643013755137,3.099197896936534,-1.1854652270177635,-7.606599183053165,-5.114083337348816,2.4852490549352915,-4.963795720489668,0.9140055463162345,0.04291294716050065,-0.09067068662459743,-4.165673680840588,-1.4983701256946522,0.989467669309152,-1.80894023922631,0.86008471186768,-0.6411398839364452,-0.4832239129170558,4.0588624432131075,False,c2,1,"When being logged out and using a link from Recentchanges like this:
http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143
And then trying to log in, it will return to ""Main Page"".
--------------------------
**Version**: 1.19
**Severity**: major",40251,-60,Needs Triage,True
-7.125912608996488,-1.8131869285666387,4.216627365622845,6.996937996947848,2.842634348730397,7.148799606189779,2.8588270306245844,-0.478606200542162,2.555006198197555,2.9676251890466094,3.8237679977414305,0.49085924208114884,0.48184002625891864,1.4092500719089758,-0.8419780143507714,4.2567938465242,0.6672458966980745,1.2066657905824065,False,c2,1,"Go to a monument page and click the upload button in the right hand corner. An upload form appears. Click back button in the top left corner and nothing happens.
--------------------------
**Version**: unspecified
**Severity**: normal",40220,-60,Needs Triage,True
3.110253838513604,-13.56278549232387,4.938808613547721,-2.9841692131216706,2.281248161962183,-3.988425958921588,1.7771737788325694,-3.331595726506673,-2.046560701703883,4.925201542507557,-1.6062328146900515,-1.1303193549663164,-1.7190897581600542,-0.7165749560593113,1.6728953869527992,-0.5981440990562014,-2.120070765635761,1.0359825251335961,False,c2,1,"Currently it says ""Login failed :( NotExists""
--------------------------
**Version**: unspecified
**Severity**: normal",40072,-61,Needs Triage,True
-4.472855217581061,-5.367232797741304,-1.9881006265156813,-1.5410252628616816,4.34578210868176,3.615620922428784,1.4139265393155318,3.1225577296291016,-3.7997960842559095,-1.246182919352342,0.45794361422805174,1.3953313183693348,3.0158758060835567,6.25611628631739,-0.20399065652606208,2.9188748310547865,-3.6008508852886836,0.09733193890726155,False,c2,1,"http://en.wikipedia.org/w/api.php?action=mobileview&format=json&page=Main_Page§ions=references - expect an empty resultset, get a 500 instead.
More problematic is http://en.wikipedia.org/w/api.php?action=mobileview&format=json&page=Main_Page§ions=0|references - expect to get contents of section 0, get a 500 instead.
--------------------------
**Version**: unspecified
**Severity**: normal",39886,-62,Needs Triage,True
-1.140050541312693,-1.7348460110795187,-1.3367177016307537,0.4856186675638636,0.09940359069451621,-1.2219373279163313,-0.012701992809340368,-0.898199855091592,-0.4938038291474638,-1.6374798773500427,-0.24742147733429842,1.1463586913975468,0.16438255970384752,-1.8997903951304602,-0.6445431041150878,0.32393978296295833,-0.8451248045537428,-1.1459587958902837,False,c2,1,"When you visit <http://shop.wikimedia.org/> currently, the site login link is in the sidebar:
---
* Shop navigation
** Home
** Apparel
** Accessories
** Travel
* Customer login
** Login
[...]
---
This doesn't make any sense to me given that the site is attempting to emulate MediaWiki's Vector skin. The login link should be in the upper right-hand corner just as it is on Wikimedia wikis.
--------------------------
**Version**: unspecified
**Severity**: normal",39791,-62,Needs Triage,True
3.26674569907825,4.768707282554015,0.5666099591587646,0.5010311804188654,-9.465356245243584,-2.1656404139113343,7.2774873877887805,10.596714273401986,6.812126128728603,4.1319950039017534,2.5850223657305578,-2.8561045727545755,-1.5146039053459077,1.2285504626200474,1.989438998793923,4.900998195667869,0.967576064431557,3.9326635113904276,False,c2,1,lists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,82576,-17,High,False
7.196041384243733,-3.428016713794431,-1.4271616274971848,-0.8044111712443609,0.4515504369830148,-2.8059987877577957,-0.005283846467940556,-1.285067338086494,2.031498485298803,-2.1253134286610456,-1.8675189070093183,-0.15056577744455257,0.09446071825757851,-1.6496145941255462,-1.5427021482118635,-0.8686580694809825,0.1674350012849286,0.1522416460269238,False,c2,1,"According to Google, HTTPS versions of our pages should have the rel=canonical head tag that points to the http version. See http://support.google.com/webmasters/bin/answer.py?hl=en&answer=139394
I can't remember that we ever had it like this, but if Google suddenly started enforcing this, then it might explain the http-https google split and google rank penalty that Wikid77 has been discussing on WP:VP/T.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: http://support.google.com/webmasters/bin/answer.py?hl=en&answer=139394
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25882
https://bugzilla.wikimedia.org/show_bug.cgi?id=28602
https://bugzilla.wikimedia.org/show_bug.cgi?id=51002",50402,-16,High,True
14.470529452913539,-4.632263155827058,13.325663700093848,-9.254592680440195,-1.3858045814994573,-2.2150625796742305,-5.319167730571524,4.109060882352254,3.060996638293081,-2.1058026801491407,-2.059310397207752,-0.45831702607345104,2.3019975159967268,-1.8245471137967288,-3.8992601827585043,0.3685074858657883,-1.5986994703040533,-1.7135880917788626,False,c2,1,"> ""Whenever I try to add an interwiki link by following the ""Add link"" link in the ""Languages"" section, the following error message pops up: ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature."" However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the ""central data repository"" is or how to log in there. —Psychonaut (talk) 17:43, 11 May 2013 (UTC)""
(Reported at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.22You_need_to_be_logged_in.22_error_when_trying_to_add_interwiki_links)
**See Also**:
{T68521}",50389,-16,High,False
-3.4775278886122534,-3.3535341645142065,-4.726030457786477,-0.3535620116565902,-2.700266724533859,-0.5130403974787684,-0.24373932019108846,-0.6149233523890405,0.17142308303315146,-2.7934115681115443,-2.5309996136277633,0.2222500772006608,1.120301976530644,-0.25047549066869745,1.220615854717824,-0.5267644687160358,0.9123295112908496,0.6096041053469501,False,c2,1,"**Author:** `afeldman`
**Description:**
MWHttpRequest currently sets CURLOPT_TIMEOUT ($this->curlOptions[CURLOPT_TIMEOUT] = $this->timeout;) but doesn't provide a way to set CURLOPT_CONNECTTIMEOUT_MS.
MWSearch as deployed in production has a 10 second timeout. Today we had an outage where lsearchd was up on servers but hung and apaches waited 10 seconds for the connection attempts to timeout. It would be better if search connection attempts timed out at 500-1000ms.
--------------------------
**Version**: 1.21.x
**Severity**: enhancement",49027,-21,High,False
-5.730671932641681,0.9560278318791493,3.87244596843691,5.333730810750453,-3.1392809634707652,4.911553816347915,3.144160983953914,-0.03291068708672315,2.551446025133841,2.283187791200408,2.1304876736775014,2.9244248125898205,0.14598351610903837,1.42652295641585,-0.46680833977463543,-0.012814196740940642,-0.6751486785377512,0.18791297635999427,False,c2,1,"To set a cookie and establish a central session for global users who login, redirect users through a central domain after login.
Initial design is at:
http://www.mediawiki.org/wiki/Auth_systems/SUL2#Redirect_on_Login
--------------------------
**Version**: master
**Severity**: normal",48903,-21,High,True
-4.3464793677856655,1.398341436358903,-2.4809690952006704,-0.11537745546629474,-0.7048192526926808,2.4999349981030115,-2.9716427567157697,0.5804508467355839,6.3459319575979976,-1.7410959421384886,-1.1328590441845598,1.3194431352504317,0.8940330226585709,-0.49862175369545003,-0.1884648597687315,-0.18166442682370776,-0.019020098610188274,-0.19963480929195643,False,c2,1,"To complete bug 46901, we need a single domain where global users will be logged in, and all of the WMF sites can test check to see if the local wiki should allow a user to login.
Because this website will have a session for every logged in user, the site should:
* Highly restrict the javascript that can run on it
* Minimize the amount of content and features, to reduce the risk for XSS vulnerabilities
* Only be accessible over SSL
* Disallow any iframing
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",48902,-21,High,True
1.753301553135453,-8.91812403829923,-2.5155770214524864,3.011085262415107,-0.9155182871405766,4.367420426224725,4.21408121006925,-0.3072566060098214,-2.5822440568889817,0.9074457794903257,1.8453014606760232,1.5018816585896972,2.905480144566373,1.6302246222313705,2.9473032625820332,-0.04618923910653738,2.000109786408597,1.9404523411550503,False,c2,1,"The new login screen for Gerrit 2.6-rc0-76-g52fb5ae is unstyled and ugly.
--------------------------
**Version**: wmf-deployment
**Severity**: major",48700,-22,High,True
1.3056258352690757,-1.2510948708425733,1.0923654721650458,0.9671710661856316,5.664331044389172,0.8955518125720583,3.3863040899052352,2.3361692501434828,-3.317913358115841,-2.4820438535957594,-2.7165060599129873,2.481684404018056,-2.280335323647183,-1.5854998547616206,2.229825432593855,1.7604183540734413,0.20229135964665002,0.586545144988585,True,c2,1,"The account creation (ACUX) and user login changes in E3Experiments have been removed to core. However, they only apply when a useAgora flag is in the URL. This allows testing and MW message cleanup where necessary.
When this is done, useAgora should be removed and Agora made the only version.
--------------------------
**Version**: 1.21.x
**Severity**: normal",48333,-24,High,True
8.223731977340412,-8.46319725634337,-1.2909033730271329,9.175788197893892,-3.6548457656780124,-3.5265448667043673,-1.8277920942832404,-1.389381161518132,-1.496020117938107,1.4217731595539993,2.583889287969479,-0.6752377192618231,-4.631816803670264,0.8704421758473648,2.0090820408882557,-1.1522082448303606,-0.6618384427629027,0.4995640013237044,False,c2,1,"<?xml version=""1.0""?>
<api servedby=""mw1115"">
<error code=""internal_api_error_MWException"" info=""Exception Caught: Solarium_Client_HttpException at /usr/local/apache/common-local/php-1.21wmf9/extensions/Solarium/lib/Result.php, line 98: Solr HTTP error: Java heap space java.lang.OutOfMemoryError: Java heap space (500)"" xml:space=""preserve"" />
</api>
for http://en.wikipedia.org/w/api.php?action=query&list=geosearch&gsradius=10000&gspage=Washington,%20D.C.
--------------------------
**Version**: unspecified
**Severity**: major",47014,-28,High,True
0.5596554679921373,-1.2504889691335084,-2.0497663098072483,-1.3861057685711593,1.98220154288428,1.4595625659863944,0.5799019763183795,-0.28863426471782727,-0.34001982515619245,-1.3768435420932907,0.13467139406941087,0.6778100028619223,0.35984765845199185,-1.829916590311671,1.4225084317864445,1.4987170512801666,-0.6021235172306229,-1.6900833632712455,False,c2,1,"I attempted to make this HTTP POST request to api.php on testwiki:
action=stabilize&title=Gold&token=<VALID EDIT TOKEN>&protectlevel=autoconfirmed&expiry=1%20month&reason=vandalism&format=xml
An HTTP 500 Internal Server Error, with no debug information, was returned. Apparently the same occurs on enwiki.
As far as I can see, the query is valid. Therefore the action=stabilize API is broken on these wikis, which in my view is a serious bug.
--------------------------
**Version**: unspecified
**Severity**: major",46527,-30,High,True
-3.0465331669235587,-0.29391602307945064,-0.4118403183021577,-4.284675217523175,1.0322580231526994,-3.825380851596429,1.2533206273696713,4.038857353552152,-0.26189345516966944,-1.5533370995312823,-0.8582795495718889,0.5493748017784688,0.48155879955153535,-1.089725714913071,-1.4252674319830163,-0.38263081059115756,-1.8199199401420256,0.1722488064972756,False,c2,1,"In Safari Desktop browser go to http://en.m.wikipedia.org/wiki/Little_Moreton_Hall whilst not logged in
Click the star, log in. When redirected back to article the article does not get watched. Logout
Go to the same page but in https mode
https://en.m.wikipedia.org/wiki/Little_Moreton_Hall
Click the star, login. When redirected back the article is watched.
The problem is that localStorage is protocol dependant. There is different localStorage for https to http.
We should probably consider using https entirely as this is going to bite us harder when we start using localStorage more aggressively..
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44330",45909,-33,High,True
15.96702914181219,-0.6700497926989311,6.096557559861246,2.0895306773020614,1.158182854330931,3.1559956250505348,-2.1073081272767764,-2.2905653665990164,0.16368704688342228,-0.4664500648414833,-3.928437689832257,-0.3625201139294777,-1.4108051771987613,-0.3112903940089362,1.182124392083347,0.08763580679675015,-0.2614447252616636,-0.5081194924434524,False,c2,1,"**Author:** `sumanah`
**Description:**
Per http://lists.wikimedia.org/pipermail/wikimedia-l/2012-December/123135.html - ""should the Uzbek Wikipedia be set up in a way that makes access via the HTTPS protocol the canonical one?""
Tim Starling asked http://lists.wikimedia.org/pipermail/wikimedia-l/2012-December/123142.html :
> Is it enough to set the <link rel=""canonical"">, or is it also necessary to redirect?
> Either way, the Squid cache would have to be purged, then the search engines would have to reread that site.
Answer http://lists.wikimedia.org/pipermail/wikimedia-l/2012-December/123148.html :
> When I asked the nice folks at Google's search team, they answered me the following:
> * The best answer would for them to use rel=canonical tags so that http://example.wikimedia.uz points to http*s*://example.wikimedia.uz. So I'd send them this page: http://support.google.com/webmasters/bin/answer.py?hl=en&answer=139394 and tell them to start doing that. If they're very serious (and it's a small property, so there's not much risk) then they could make every http page 301 to the https version as well.
> I don't know how much effort each of these two measures would be. If you'd ask me, I would suggest to be ""very serious"", but we are not under a deadline (the situation has been like this for more than a year now), and setting the rel=""caonical"" would already be really, really helpful.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",45466,-35,High,True
-10.026232304944362,6.491557177451398,0.731994838906985,-3.690049478893668,-2.0704002270886375,-2.191240832397423,2.7530633833327736,-2.7321145765472923,2.2263907939330325,-1.7227412814560283,-1.4719025023728516,1.2039357082655477,-2.3808489605262855,0.7776724140329705,2.0290589454060317,-0.1571924742915649,-0.681483754083137,1.0350882711575935,False,c2,1,"Why is it contained in a table element?
This causes huge restrictions on how one can style it.
I am currently trying to style the login form to look like https://mingle.corp.wikimedia.org/attachments/3408386b028630169e1105579e7b53da/186/Wikipedia_Signup_-_iOS.png for mobile and it is impossible to do so without changes to the core.
Let's replace it with a form with clearly marked input elements and input labels. There is absolutely no need for the table elements.
--------------------------
**Version**: 1.21.x
**Severity**: normal",45108,-37,High,True
0.20332052187209015,-1.3914810943985412,7.231966650561951,1.412321280366478,1.7682844738401378,-3.1294143239754595,1.409422388206722,-1.5157537458911943,-1.9271265500970505,1.9149684976660497,1.2209421204194686,-1.5662813962799376,-1.6900598221988066,-0.1821553765720596,-0.343445105583414,0.7584618334447586,-0.5491068252398528,0.4502043205128132,False,c2,1,"When I go to <https://en.wikipedia.org/wiki/User:Trevor_Parscal> and click the ""visualeditor"" tab, my browser console says:
---
The page at https://en.wikipedia.org/wiki/User:Trevor_Parscal displayed insecure content from http://en.wikipedia.org/w?title=Special:FilePath/California_Bay_Area_county_map.svg&width=.
---
Consequently, the pretty green lock icon in Google Chrome turns yellow.
--------------------------
**Version**: unspecified
**Severity**: major",45015,-37,High,True
-1.4757246407133828,4.75555836783839,3.877435699196468,-3.38964784477035,3.080760392700316,-0.5426727398251662,-1.4958668732045899,-6.965430495629816,1.9014557667648984,1.8328888032678927,1.2475230133581747,2.028765309805304,-0.4714424220689848,1.7699865193627504,0.3282140324204521,-1.0764331402885419,-1.1240362200706138,-0.4411484810262878,False,c2,1,"When I try to make an account on the English Wikipedia at <https://en.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Main+Page>, it gives a strange error after I press the ""Create account"" button. It might be related to the username. I'm attaching two screenshots which should give steps to reproduce.
--------------------------
**Version**: master
**Severity**: critical",44982,-37,High,True
4.428095410413544,-0.9394342171554815,2.450216422885724,1.1376731375295441,-0.571580358771841,-0.5997973888726378,-2.66639045508926,-1.8038555031501264,1.489127388646073,-0.06538789695515934,-1.8074392848595608,-0.8804515697828279,0.9106000872300499,-1.9513993382966857,-1.7201988743896655,-0.08262745516622372,-0.43243037077627555,-0.23334091562705295,False,c2,1,"**Author:** `sumanah`
**Description:**
At https://test.wikipedia.org/wiki/Special:UploadWizard and https://test2.wikipedia.org/wiki/Special:UploadWizard I tried to add images from Flickr using the ""Add images from Flickr"" button.
I tried the following URLs to photos:
https://secure.flickr.com/photos/library_of_congress/8211550552/
http://www.flickr.com/photos/quimgil/8220094378/in/photostream
https://secure.flickr.com/photos/quimgil/8220094378/in/photostream
In all cases, at the next step (Uploading...), the file seemed to fail to download, but the title got captured, e.g.:
Parliament of Catalonia - Elections.jpg
Unknown error: ""http-curl-error"".
Kaldari thinks it sounds like a problem with the proxy.
--------------------------
**Version**: master
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42441",44468,-40,High,True
-1.2555423293050139,1.0728534652298407,-0.40623743990582817,-1.361679543313667,1.7624309478614943,-3.532949127276323,2.255729325807958,-0.6023698228631431,-1.3507493817655223,-0.2621663197586468,1.835054994338782,-2.3890080289065567,0.2611517673545962,-1.0353859447274325,-0.170755109011262,0.12367964456080527,1.963985358490141,1.506702853439455,False,c2,1,"Screenshot of the post-login screen on the English Wikipedia showing missing auto-login icons
When I go to <https://en.wikipedia.org/w/index.php?title=Special:UserLogin> and successfully enter my username and password, the post-login screen isn't always loading all of the icons as it used to. This appears to have started today (October 31, 2012). I asked in #wikimedia-tech and another user (Danny B.) reported similar strangeness today.
It _feels_ like the third-party cookie behavior has changed a bit and now browsers consider .wiktionary.org, etc. to be third-party and blocked when they were previously allowed. But I'm not sure.
After submitting my username and password, I'm successfully logged in to en.wikipedia.org, but not to the other sites. Attaching a screenshot as well.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Special:UserLogin
**Attached**: {F9965}",43610,-43,High,True
7.0607778560075065,-3.1173747351011656,-5.097153532504718,-0.37978248002247317,5.877271881992899,0.13880362991013118,2.015899965963544,3.3570217808955922,-4.69205877657083,-2.761859204657009,-2.2497070137779596,2.383321416430534,0.4586885089822119,1.1474749857833642,-1.8851065278015717,-2.265129651676227,-0.4600998869822638,2.049050488000904,False,c2,1,"Wikidata.org is using the SSL certificate for *.wikimedia.org
Reedy says this is RT #3803, creating bug here so no one else does.
--------------------------
**Version**: unspecified
**Severity**: normal",43437,-44,High,True
9.208745372668158,-5.965497137400668,0.06881888294482152,4.8218491383118485,-4.483056245124594,-0.9978045523573631,1.7022919795372973,-0.32086438129232764,-0.9359939983493514,0.20115867567105017,2.3366775810736145,-0.4077443523479388,3.7162215864343464,1.0342863584572042,0.8572952202859705,-0.47174491305268273,-0.06860157794708788,-0.4511040577533225,False,c2,1,"https://oc.wikipedia.org/wiki/Sent_Medard_de_Moissida
https://oc.wikipedia.org/wiki/Sent_Privat_daus_Prats
https://oc.wikipedia.org/wiki/Sent_Sieurin_de_Prats
https://oc.wikipedia.org/wiki/Sarlanda
https://oc.wikipedia.org/wiki/Sodac
etc...
https://oc.wikipedia.org/wiki/Sent_Medard_de_Moissida?printable=yes return:
PHP fatal error in /usr/local/apache/common-local/php-1.21wmf1/includes/objectcache/MemcachedClient.php line 908:
Allowed memory size of 134217728 bytes exhausted (tried to allocate 499456 bytes)
--------------------------
**Version**: unspecified
**Severity**: normal",43115,-45,High,True
-1.0273720493108391,-6.156411144167102,10.11349466775064,4.657486377661486,-7.660734085970402,-2.4793889370140034,3.8705743515865736,0.2376996539505276,-0.406072061076865,-1.5511508303966375,-3.173051880670374,-3.0509606505244253,-2.53552253471201,-0.4420281717869745,0.5801809568638854,1.5184929536976264,-0.657612270255163,-0.049552113788879915,False,c2,1,"Redirect loops just like described in https://gerrit.wikimedia.org/r/#/c/25530/1/includes/specials/SpecialUserlogin.php
--------------------------
**Version**: 1.20.x
**Severity**: major",42789,-47,High,True
4.000153746101049,3.521807037795817,-2.4012480776285,-0.7639064386133652,2.701759950480956,3.0671632891219787,-1.506752368396893,0.4479863297422545,1.2590559134452495,-1.9920987716945482,-2.1008604051348563,-0.1673936865203951,-0.31666674041513065,-0.4074141812966605,-1.3224685926057935,0.24180922674457542,0.1732645157183974,-0.3689821172565284,False,c2,1,"Currently, if a user needs to login the provider will redirect to Special:OpenIDServer/Login. This is a form that only accepts a user's password. Rather than doing so, it should redirect to the normal login form Special:UserLogin with a returnto parameter that causes Special:UserLogin to return the user back to the OpenID form.
The reason for this is that the wiki could be using other authentication extensions like OATH, LDAP, or CentralAuth, and they won't exist in the Special:OpenIDServer/Login form.
--------------------------
**Version**: master
**Severity**: major",42067,-51,High,True
0.42265071996698067,-2.1512056752771507,2.4218428185397656,0.570583443224784,3.9917850915542004,2.966936844964648,-0.9219917896605949,0.6499958428273016,-0.29995670797341606,3.814757448544931,-0.1545150125396728,2.161574710514679,0.8190037864669235,0.5598916539366146,0.5911730463405087,0.3146742990491587,-2.992799606232211,-0.1109215683695437,False,c2,1,"Getting a ""502 Bad Gateway"" on https is bad, it is possible to get also the ""Wikimedia has a technical problem, please donate"" page as the http version shows? Thanks.
Seen at the outage today.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://rt.wikimedia.org/Ticket/Display.html?id=5021",41077,-56,High,True
2.810102688251497,-7.966544983416802,10.953250916026679,-2.74226460779596,-0.14037672295400982,-7.528497856513998,-0.4184304688649165,8.884351475948433,1.8307030076038144,-1.2078671226569675,1.712071590272608,-2.479544575453734,-4.731736101492094,1.9878347694151142,-0.7252115553667693,-0.4205775222926338,0.8222635661523052,-0.9749525853497134,False,c2,1,"Currently <https://shop.wikimedia.org> doesn't work at all. Ideally <http://shop.wikimedia.org> would unconditionally redirect to <https://shop.wikimedia.org>.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://shop.wikimedia.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61528",39790,-62,High,False
24.713678848119127,-2.132373883085494,0.4076904593585162,-1.1400390763468475,-2.3071619364109175,0.9664775968647719,-1.4188512478489894,-1.4803953428245498,0.3405647772115419,-2.587624117966246,-3.187164886783102,-0.7352356915252994,-0.2978750069388143,-1.805944132761288,-1.8987349161785056,-0.18764948164603357,-0.028605197733489574,-0.7221143478352501,False,c2,1,"**Author:** `lcarr`
**Description:**
**Refers To:**
{T83554}",82499,-17,Medium,False
2.241482522680925,-5.433168539564736,-2.8351945545569013,0.0677979076256463,-0.4064607382238392,-3.0366376966277278,-4.5859903424420905,-0.889948777207818,0.5405784310312337,-3.7457076636538704,-0.003156610306258134,-0.5938846372248301,1.1778072780207265,-2.490294733403549,-2.930687942967552,0.21296227301089016,-0.6319248882449442,-1.8537897286159148,False,c2,1,"**Author:** `hashar`
**Description:**
%%%We have a bunch of virtual hosts explicitly declaring the SSL certificate to%%%
%%%use. Per Faidon review, we should instead use: SSLCACertificatePath%%%
%%%/etc/ssl/certs Then apache will find out which one to use. (note I have closed%%%
%%%the bug report, lets track this in RT).%%%
__________________________
**Bugzilla Ticket**: [[ https://old-bugzilla.wikimedia.org/show_bug.cgi?id=46325 | 46325 ]] => {T48325}
**Referred To By:**
{T82359}",82319,-23,Medium,False
-3.2412089561523363,-14.367369742354919,-16.140987021126797,-1.0711966087864133,-0.6045386946248407,-1.0795824643045058,-5.97116710465117,-0.241660955292893,-0.3250151361546402,-4.756790452261016,-3.0716443784057765,-1.1732573004872067,4.251262031561436,-4.870179121532534,-5.526035010791839,0.28693315355287025,-1.4141156880541368,-1.9315546762416975,False,c2,1,"
",81686,-42,Medium,False
-7.810045520506247,1.9307227461902556,-8.753918654847817,0.08659403746097794,2.6350041663194537,-7.924465176880374,2.1104098768722954,-7.1359575187996525,4.104437288515692,-0.041502423643955844,4.293726306214076,-1.2908937990503373,5.341346425561554,-0.32153897221196637,1.505154903510432,1.6668569276450635,1.3208767335882439,-0.8955644435568197,False,c2,1,"%%%it is 99.5% certain we will use this domain. we have already talked to the%%%
%%%current owner about the domain transfer and they will visit us here at the%%%
%%%office next week.%%%
%%%we will need a *.wikivoyage.org SSL cert and we will need it relatively quick%%%
%%%given the current schedule to start with the wikivoyage project%%%
",81588,-46,Medium,False
-7.349635593680711,5.665914942010048,2.2870843228853666,2.5451073017566137,0.5597245771783632,-1.5269821732732372,0.25807375136097477,1.6021615181877342,1.8213257594839807,-1.324093736325778,-0.05477463066838428,1.0982610095339231,0.13103965254369676,-0.24340071172791689,-0.0052609912627943345,-0.6368619111571016,-1.8318677113492454,0.17706714126321166,False,c2,1,"Image patch (https://gerrit.wikimedia.org/r/#/c/57817/) is missing error handling when the mw API is queried to get information about an image.
Two kind of errors that handleResponse in LinkHandler.js has to deal with:
(1) API error: Given that ApiRequest retries, an api error is an indication that the api may be temporarily down or that something else is wrong. So, rather than continue, it is better to abort processing and return an error code to the clients so they can handle it however they want (ex: ve might tell the user that the page cannot be edited right now because of api/server issues). This will require calling the error callback found in env.
(2) Image missing: If the api comes back and tells us that the image is missing, we should handle this similar to how the PHP parser does it for missing images.
- Maybe link to a special page/url that will let VE present an upload handler (check with VE folks as to what this url could be. PHP parser behavior can be found by editing a page on wikipedia sandbox with a non-existent image)
- Dont add a thumb.
- Add a special rdf type on the image/wrapper tag: mw:Image/Missing maybe?
EDIT: These properties should apply to missing templates as well.
--------------------------
**Version**: unspecified
**Severity**: normal",50900,-14,Medium,False
-8.884633740871395,3.8695314662281746,1.8495444921786621,2.8651661520818212,0.1462401841605322,4.873721508050893,3.773079484543149,-0.059117409635463664,0.11480843655383671,-0.75631735996402,-1.0487887935948716,1.496795501956133,-2.354271258847068,0.5032345120863315,2.8554910251259136,-1.2156112601989395,-0.24501999335096847,-0.8990628459581782,False,c2,1,"The email announcement that comes through newproject mailing list from the wiki creation process currently shows an http://... link. Would it be possible for that email to be converted to offer the https login rather than http, or even both with a little explanatory text. Selfish request though with the direction that is being taken, it is just a matter of time. Thanks.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",50572,-15,Medium,True
13.141635137844684,2.6226486532966646,-12.548095879031173,2.3045233227012303,1.4603987089321828,-2.0720151354652154,-1.029192259635475,-0.4564297355889788,0.3499774217972472,-1.1680270315373322,-0.8276073484602366,-0.19825060988240772,1.5303967233539586,-1.1507178697027962,-2.2055020043798432,0.1475497658247776,0.03265925874235465,-0.8344623515511624,False,c2,1,"We now have nginx SSL proxies in front of the beta caches (Bug T38648). We still have to fix the certificate (that is *.wmflabs.org for now).
We need certificates generated by 'Labs CA' for the entries listed in role::protoproxy::ssl::beta and some more. I guess the easiest would be to create *.beta.wmflabs.org cert that will also contains the following DNS entries:
*.wikimedia.beta.wmflabs.org
*.wikibooks.beta.wmflabs.org
*.wikinews.beta.wmflabs.org
*.wikipedia.beta.wmflabs.org
*.wikiquote.beta.wmflabs.org
*.wikisource.beta.wmflabs.org
*.wikiversity.beta.wmflabs.org
*.wikivoyage.beta.wmflabs.org
*.wiktionary.beta.wmflabs.org
And the mobile ones:
*.m.wikimedia.beta.wmflabs.org
*.m.wikibooks.beta.wmflabs.org
*.m.wikinews.beta.wmflabs.org
*.m.wikipedia.beta.wmflabs.org
*.m.wikiquote.beta.wmflabs.org
*.m.wikisource.beta.wmflabs.org
*.m.wikiversity.beta.wmflabs.org
*.m.wikivoyage.beta.wmflabs.org
*.m.wiktionary.beta.wmflabs.org
*.zero.wikipedia.beta.wmflabs.org
**See Also**:
{T56065}
{T70387}
{T71269}",50501,-15,Medium,False
-1.859227313156024,-0.9334075465517273,-2.3658393672491496,-0.05311321664742996,4.568974076180336,1.6703608244786328,3.405895986364544,-0.8725309242608681,-0.8497792490133407,-1.8272955666432034,-1.1937781599284771,-0.3415426248260428,-1.3798858584467268,1.822726405660183,2.088573416939945,1.0253859599205604,-0.47760143607246475,3.08822196297439,False,c2,1,"login.wikimedia.org is using https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Wikimedia-logo.svg/135px-Wikimedia-logo.svg.png for its logo currently, but this logo is weird. There's a green line connecting the two green pieces in the logo. Surely there's a 135px version on Commons somewhere we can use instead.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",50236,-16,Medium,True
3.332566461369788,-1.8551530907999059,3.555200022090361,0.08517629874443178,-1.3356324939637443,-2.604623321868539,2.359927629495661,3.4559964283743447,-1.3605169668920618,-0.8596113125546458,-0.0460189496152279,-4.28826630731314,2.1817209405293716,1.7063321657221637,0.060288232771760875,0.24405952019372135,1.30771307648087,0.16766162392445882,False,c2,1,"Possibly all files affected by the commit in bug 47363 return errors for large thumbnails. (Bug 47363 changed $wgMaxImageArea and $wgMaxAnimatedGifArea to 50 MP)
Example files:
https://upload.wikimedia.org/wikipedia/commons/thumb/b/bf/Mejeri1.gif/576px-Mejeri1.gif
works for me,
https://upload.wikimedia.org/wikipedia/commons/thumb/b/bf/Mejeri1.gif/577px-Mejeri1.gif
and above does not anymore.
https://upload.wikimedia.org/wikipedia/commons/thumb/0/0a/File-Ulysses_S._Grant_from_West_Point_to_Appomattox_partially_restored.png/276px-File-Ulysses_S._Grant_from_West_Point_to_Appomattox_partially_restored.png
OK
https://upload.wikimedia.org/wikipedia/commons/thumb/0/0a/File-Ulysses_S._Grant_from_West_Point_to_Appomattox_partially_restored.png/476px-File-Ulysses_S._Grant_from_West_Point_to_Appomattox_partially_restored.png
Not OK
(Could not find an appropriate tiff file by now)
--------------------------
**Version**: wmf-deployment
**Severity**: normal",50003,-17,Medium,True
-4.59396173038817,-2.147628240635534,2.890075811371336,2.6606863176869324,1.2722924177630894,-3.117445708250078,-0.6386553269372142,-0.9091232600853631,1.2901095609661242,6.418628198283285,-1.5568069350972336,-0.1160794254854316,-0.9874614121441194,2.529879766368933,-0.42371857616897124,0.11463666265482098,1.922894563187257,-1.2725554914974584,False,c2,1,"The new login form does not handle the messages 'loginstart', 'loginend' and 'login-https' (by default empty).
The community use them to customize the login form.
Maybe use new message keys to enforce creation of new text :-)
Otherwise I predict that some Wikipedians will misuse the standard messages for their ideas...
--------------------------
**Version**: 1.22.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56455",49883,-18,Medium,False
6.396588551548861,-5.653063622310368,1.0231774559356026,-9.828910697798406,-0.5802382098393531,-1.4229972390905303,-1.1306324390276057,-0.986974562475936,4.203960772592799,-2.2226202979026985,-1.7451718437427195,-0.06309440873060956,0.014092396933295781,2.124494505602317,0.21066377181622542,0.5649246228141508,-0.6723737702692025,-0.4310620380788863,True,c2,1,"It's 2013. Let's just get on with this.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31323
https://bugzilla.wikimedia.org/show_bug.cgi?id=39380
https://bugzilla.wikimedia.org/show_bug.cgi?id=51002",49832,-18,Medium,False
13.148148708826145,3.4303686913033395,-2.2930642530640633,-2.29960053431936,1.1781456607261904,-0.28334860664534967,4.018109228439026,-7.584189348992398,1.814230745745807,-0.34262939204711973,0.30310606141761065,-0.34021522738416843,-2.3625225482079433,1.2483301063972982,0.7296074077900228,1.9140652221608294,-0.4010705832006427,0.5963395417723423,False,c2,1,"On the new Special:UserLogin, the custom language selection bar stands out in all its weirdness and ugliness:
Lingua: Deutsch | English | Esperanto | français | español | italiano | Nederlands
UniversalLanguageSelector/ULS will allow us to kill it, in the meanwhile I doubt it's worth improving it.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Connexion&useNew=1",49802,-18,Medium,
-6.797708364911072,-0.9900844280111514,-4.771944658425317,-2.3820655423776955,0.1906303412172382,-2.729185571889763,-0.06456291310811402,3.4634554659365486,0.275728513557427,-1.0826459336744767,-0.8404289565840464,0.6148388749726312,1.1727751305870977,0.029576144113151237,-1.4791628507020569,1.3386601394255666,2.1113408004986285,0.001930445576085127,False,c2,1,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed).
Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface.
Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in .
--------------------------
**Version**: 1.22.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",49801,-18,Medium,True
2.3746594897082685,-3.104397011959046,-2.8754961063372413,-0.4025950293313024,1.3279277381562684,2.1554917372763036,1.273429449102136,1.5462100904030018,1.3650338622601574,-1.566165587320239,-1.8952220740147347,-0.08001846183968886,-0.5071599168587797,-1.9453131865188564,2.8007924202560384,-0.6389485194303907,2.9327069422849537,0.5729457780400631,False,c2,1,"**Author:** `usermono`
**Description:**
ENWP had a nice little JS feature that checked the username and password against existing usernames and bad passwords. This was already written & isn't that hard to do, so it should be implemented into the ACUX deployment.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",49685,-18,Medium,False
6.692098969952832,-0.7763410937980861,-4.392337128890123,1.4420649356731046,1.5085271659805328,-1.7111231990081963,-6.482866429322102,-0.896636883251527,-2.078124169031776,3.1093595373242815,4.879241877154048,-0.47000637084266406,-3.8400975527384675,-0.9109883484120518,1.2656208320408133,-0.8125749607956014,0.41172401616516185,1.0571473302644547,False,c2,1,"When I visit <https://wikimedia.de/wiki/Hauptseite>, there are a few resources coming in via HTTP, causing my Web browser to throw warnings.
<img alt="""" src=""http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Wikidata-logo-en.svg/170px-Wikidata-logo-en.svg.png"" width=""170"" height=""120"" />
<img alt=""Wikipedianer auf Exkursion im Kirchenarchiv Kaufbeuren. Foto: Benutzerin:Elya, CC-BY-SA 3.0"" src=""http://upload.wikimedia.org/wikipedia/commons/thumb/0/09/GLAM-Aktivisten_im_Kirchenarchiv_Kaufbeuren_04.JPG/170px-GLAM-Aktivisten_im_Kirchenarchiv_Kaufbeuren_04.JPG"" width=""170"" height=""128"" />
<img alt=""Logo von Wikivoyage"" src=""http://upload.wikimedia.org/wikipedia/commons/thumb/1/1b/Wikivoyage-logo-en-TTO-attempt.svg/170px-Wikivoyage-logo-en-TTO-attempt.svg.png"" width=""170"" height=""180"" />
[a bunch of other images ...]
<img src=""http://i.creativecommons.org/l/by-sa/3.0/88x31.png"" alt=""Attribution-Share Alike 3.0 Unported"" width=""88"" height=""31"" />
<img src=""http://secure.wikimedia.de/piwik/piwik.php?idsite=2"" style=""border:0"" alt=""""/>
This is probably the not the best place to report this issue, but I couldn't find a better place and I figured some of the German Wikimedians can be copied on this bug report and can forward this issue as necessary and appropriate.
--------------------------
**Version**: 1.20.x
**Severity**: normal",49653,-18,Medium,True
6.23033226820729,-0.9253549521097142,4.203904543623292,-0.51138880360505,-0.8439430032394579,-0.5002174460356152,-1.4110876434769777,0.9505139292084069,-1.4935207952188447,5.213286289150146,-3.128252349608989,1.335282878528367,-1.212652571762729,-0.4393900007059761,0.42084686978126484,-0.9486260091047758,-2.202071729123342,1.4017999718727714,True,c2,1,"Pasting an email from Matthew Flaschen here:
Steven Walling suggests that the MW ""User login"" component is meant to
include signup. There are definitely signup-related things at
https://bugzilla.wikimedia.org/buglist.cgi?list_id=196453&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&component=User%20login&product=MediaWiki
So could you rename ""User login"" to ""User login and signup""?
--------------------------
**Version**: wmf-deployment
**Severity**: normal",49600,-18,Medium,True
-6.476268189228749,4.618818418915787,2.3025588183855668,2.5279865532406856,2.677180541218076,4.022012634755862,1.2961956576744225,1.4677278087976493,2.868930344241699,0.8840132601771904,1.7152951686555844,-0.7578690952861344,0.44779382032970005,0.6472674826017117,0.6836187326948906,-0.207128661233142,0.25939272763511156,-1.5975431771278727,False,c2,1,"**Author:** `usermono`
**Description:**
This is a design suggestion: move the create account call to action in the new ACUX user login page to the right. This would help fill the massive white space there.
See http://awesomescreenshot.com/0a316de0b2 for a visual demo.
One other idea would be to center everything to even out that white space. Also the language selector should be moved to the sidebar like all other Commons pages or somewhere else - it doesn't fit with the minimalist look here.
It just seems a little bland with all that white. A border/shadow around the login box if it's centered might do the trick. Another idea would be to add a huge picture in that space with the CTA there, similar to http://outlook.com
--------------------------
**Version**: unspecified
**Severity**: enhancement",49392,-19,Medium,
-6.563818619679599,1.0033926600038168,5.27513734461774,5.198402426252164,-0.1318550266572049,2.540519953670289,0.22359250161781663,0.09646829341549845,0.4645235953779141,0.3299477298922371,0.8887909398682821,1.5512318552971929,2.276878080850959,3.3662910153208294,-2.082427124906538,-1.0906379727548552,1.0223211202815288,-1.680556343672219,False,c2,1,"The new vertical login form moves the header contents (if any) out of the form. This means that the captcha that appears (by default after three bad login attempts) doesn't work!
To reproduce, visit http://www.mediawiki.org/w/index.php?title=Special:UserLogin&useNew=1 and enter a bad password.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**URL**: http://www.mediawiki.org/w/index.php?title=Special:UserLogin&useNew=1 ",49371,-19,Medium,True
2.645226912966058,-10.322495829953683,-4.958065728731281,4.758521511819662,-2.056266550747877,-1.4477475460344258,1.1061326632298938,0.3109171770054593,-3.093197496569961,0.7423113674581323,3.627557829195411,-0.14141517103573698,7.795616218329692,1.612227229224417,0.16924400122520034,-0.5365021552727366,-0.2037780847765549,-0.5167932435949765,False,c2,1,"[11-Apr-2013 19:45:54] Catchable fatal error: Argument 1 passed to LoginForm::userBlockedMessage() must be an instance of Block, null given, called in /usr/local/apache/common-local/php-1.22wmf1/includes/specials/SpecialUserlogin.php on line 829 and defined at /usr/local/apache/common-local/php-1.22wmf1/includes/specials/SpecialUserlogin.php on line 964
Server: mw1076
Method: POST
URL: http://meta.wikimedia.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Link/a/b&returntoquery=type=signup
Backtrace:
#0 /usr/local/apache/common-local/php-1.22wmf1/includes/specials/SpecialUserlogin.php(964): LoginForm::userBlockedMessage()
#1 /usr/local/apache/common-local/php-1.22wmf1/includes/specials/SpecialUserlogin.php(829): LoginForm->userBlockedMessage(NULL)
#2 /usr/local/apache/common-local/php-1.22wmf1/includes/specials/SpecialUserlogin.php(184): LoginForm->processLogin()
#3 /usr/local/apache/common-local/php-1.22wmf1/includes/SpecialPage.php(613): LoginForm->execute(NULL)
#4 /usr/local/apache/common-local/php-1.22wmf1/includes/SpecialPageFactory.php(486): SpecialPage->run(NULL)
#5 /usr/local/apache/common-local/php-1.22wmf1/includes/Wiki.php(291): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#6 /usr/local/apache/common-local/php-1.22wmf1/includes/Wiki.php(565): MediaWiki->performRequest()
#7 /usr/local/apache/common-local/php-1.22wmf1/includes/Wiki.php(458): MediaWiki->main()
#8 /usr/local/apache/common-local/php-1.22wmf1/index.php(59): MediaWiki->run()
#9 /usr/local/apache/common-local/w/index.php(3): require('/usr/local/apac...')
#10 {main}
--------------------------
**Version**: 1.22.0
**Severity**: normal",49138,-20,Medium,True
6.788991741336323,-0.5371290713657597,-6.673442778247082,0.7472408747800519,1.7379355055108046,-2.9265622497292565,-3.8359971072143866,0.1816235016428221,-2.1757274613839996,1.4777576425688839,-2.5734421837689148,-1.0546327511810043,0.7476388963186751,1.6559824203447366,1.8611328700346723,-0.7584807290815301,-0.7559091603295923,0.20702938327109988,False,c2,1,"I don't know whether it is really a bug or just some JPEG-encoding-internal-strangeness
Test at https://commons.wikimedia.org/wiki/File:Bot-Test.jpg
API query at:
https://commons.wikimedia.org/w/api.php?action=query&prop=info|imageinfo&iiprop=size|comment&titles=File:Bot-Test.jpg&iilimit=5
Start size: 324829; then, after first rotation 281901, then 275364, then 270655 and finally after 4 rotations just 268076 Bytes:
<ii size=""268076"" width=""512"" height=""512"" comment=""Bild um 90 Grad im Uhrzeigersinn gedreht"" />
<ii size=""270655"" width=""512"" height=""512"" comment=""Bild um 270 Grad im Uhrzeigersinn gedreht"" />
<ii size=""275364"" width=""512"" height=""512"" comment=""Bild um 270 Grad im Uhrzeigersinn gedreht"" />
<ii size=""281901"" width=""512"" height=""512"" comment=""Bild um 90 Grad im Uhrzeigersinn gedreht"" />
<ii size=""324829"" width=""512"" height=""512"" comment=""Reverted to version as of 18:08, 29 November 2012"" />
Expected result: After 360° rotation and if the image is not cropped, the file size is supposed to be the same.
Why isn't simply the Metadata of the file manipulated (the EXIF-Orientation-tag). The image-scalers would do the remaining work.
--------------------------
**Version**: 1.21.x
**Severity**: normal
**See Also**:
https://rt.wikimedia.org/Ticket/Display.html?id=4821
https://bugzilla.wikimedia.org/show_bug.cgi?id=36221",48549,-23,Medium,
2.1688078676996008,2.7749976372545717,0.08477359070243295,-0.05173696622654189,1.5035895155541108,-2.6556855882737738,-0.7450828427288991,0.8631017010596943,-2.878033335169146,-0.1747135370590822,-1.8394289579888685,1.1051879449118236,-0.34519467031964446,2.212835254109514,1.122094980415734,0.24056113591761705,0.5953634500345337,0.9859853058606765,False,c2,1,"**Author:** `jskarvad`
**Description:**
HTTPS detection is not reliable. It uses $_SERVER['HTTPS'] == 'on', but according to PHP docs [1]:
> 'HTTPS' Set to a non-empty value if the script was queried through the HTTPS protocol.
This maybe problem e.g. when mediawiki is running on Amazon cloud through HTTPS, their load balancer sets the HTTPS to '1'.
Also the detection code suppose the HTTPS to be SSL on port 443, but IMHO it can be also TLS on port 80 and injecting the explicit port in this case also breaks things for me (Amazon/HTTPS/Firefox). Attached is the fix for mediawiki 1.16. It seems that the latest mediawiki 1.20.3 is also affected, but the code is slightly different there.
This problem results in e.g. inability to save the user preferences.
[1] http://php.net/manual/en/reserved.variables.server.php
--------------------------
**Version**: 1.21.x
**Severity**: normal",48511,-23,Medium,False
-4.589128705376874,3.067298399690351,-4.160835066611252,-0.9421063596775389,1.321751198808968,1.1262739691607966,4.781714637860001,4.689121032291198,-3.4205461038777933,-1.0672270354061721,-1.046874872002137,-3.9127335218068398,-1.518037159118565,-1.3002723129217464,1.491884029680521,1.214103910954114,-1.8937429394884222,3.2028827107342446,False,c2,1,"Right now it is an undocumented domain name (not in use anywhere) falling back to the default docroot on Gallium (which is for doc.wikimedia.org) and as such as serving an invalid certificate.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",48298,-24,Medium,True
-4.023656392635103,-1.5997883584785217,-3.5824927437328693,4.53406204608316,0.5777304977995761,-0.9423247789844631,-2.7402321935739113,1.0878787193255697,2.1203649002774645,-0.15192593621584205,-3.0791095254689793,0.5579419907849934,1.2392914027770043,-0.48902755202711834,-0.0211371090547825,0.22212252060386747,-0.08072200809482277,1.8252820154414533,False,c2,1,"see also bug 45324 .
The implementation would require a user_openid table schema change, so that an additional column uoi_openid_ignore_certificate_check can be added and can be set to ""1"". (per user).
""per-OpenID provider"" would either require
+ an additional database table openid_providers which save their properites including whether not to ignore certificate checks; or
+ hard-coding the value for the preprogrammed providers.
A setting (checkbox ""ignore certificate checks"") for manually entered OpenIDs must be added on the Login and Convert panels.
--------------------------
**Version**: master
**Severity**: enhancement",48189,-24,Medium,True
-4.5785331402007925,-3.575513282900735,-1.4894556794539486,-6.850360337286907,1.5396383461356895,-3.315529854283568,4.388936507671963,-0.9546172472344374,-0.02782849191212111,-1.3000511651352409,-0.5198647874343436,-1.3427928636240734,-1.6236204979036568,-0.86634501214139,1.6025395114217869,-3.606902804197583,-2.989921455479232,0.16581380352897468,False,c2,1,"When editing page with redirect, I can edit just the page to where it is redirected.
--------------------------
**Version**: unspecified
**Severity**: normal",47808,-25,Medium,True
3.9487556265046044,-1.3796483355249247,2.8927169323433723,-0.2888091635871175,-2.5493071722019423,-1.2561475700644094,0.8469795794976829,-3.7488403459361113,4.940812126532384,-0.8218371708239705,-0.7762780226577051,0.49379432136214363,-1.0320699522401107,0.5042366513968624,-0.13402199660625325,0.6187020173963496,-0.3081499910216985,-0.41601801254293647,False,c2,1,"**Author:** `mattbisanz`
**Description:**
Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist",47380,-27,Medium,True
-3.919579873653962,-1.6422826128369525,-2.4536927366661665,2.946038643262523,1.1747802795080682,2.062608749203057,0.37829143854439806,1.8393495015865176,3.2170124009479615,0.22496088787365487,-0.08141491787864341,-0.13142956633667535,-0.41976676862651896,0.8567263771527216,-1.1711413024147168,0.671413766473193,-1.4696761118704345,-0.4020822426373749,False,c2,1,"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA
Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.
Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate.
Additional improvements:
+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)
+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing)
--------------------------
**Version**: master
**Severity**: normal",47324,-27,Medium,True
-1.0966191454629093,4.667121758076952,9.741065259695368,3.16549821486159,4.270989067591858,-9.767828742565879,-1.7169272070230832,-9.965345263490997,1.346174888780029,0.8672909499466197,2.599951549607226,0.2976070447337589,-1.4464791734055051,-0.36650961386443104,3.416248840198743,-0.5248541869212321,0.21984718772014977,0.6028642505757345,False,c2,1,"If I was on Wikidata:Project_chat, then login, the login success page give me the following.
<a href=""//wikidata.org/wiki/Project_chat"" class=""extiw"" title=""wikidata:Project chat"">wikidata:Project chat</a>
and it redirects me to http://wikidata.org/wiki/Project_chat",47077,-28,Medium,False
-2.3111846591944105,3.719961451496026,4.516016724411877,3.5825748015660226,-6.747307499956332,1.3999402647475165,2.438295783686299,1.451388774017623,2.872293513185655,-0.7145000825493559,-1.9149140164829492,-0.7448392669395008,-2.14071658746055,1.0845042666463192,-0.3309050727477931,-0.5954433170246051,-1.3894470042652343,3.3457686224755614,False,c2,1,"When calling the API of other wikis using HTTP, as for instance MediaWikiSite does in order to normalize page titles, provide options to Http::get() to force a reasonable timeout and perhaps other hints.
--------------------------
**Version**: master
**Severity**: enhancement",46991,-28,Medium,False
7.8971835195308575,0.6713462531309151,4.758980582633281,-3.169455878403684,-5.1698142663902455,0.25714819600053507,-0.6608216439606958,-0.8201122614093362,-0.028708934730826086,2.822738055760552,-1.3205043677467543,5.362041905501455,-0.0384766427229577,-1.978205871220168,1.6027795738338293,0.8564149657222239,-0.004305880942495399,1.270127699889067,False,c2,1,"* View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit
* Click ""View Attachment as Diff""
Request url:
https://bug-attachment.wikimedia.org/attachment.cgi?id=829
This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS.
--------------------------
**Version**: unspecified
**Severity**: major",46777,-29,Medium,False
-2.3555195811667637,-4.662376493506498,1.651759374355457,4.835630616110958,-0.5536878659592365,2.6935195014428848,-0.05986966126919668,-2.3879105978057886,-2.490769263904763,0.418898157921455,-3.986764346904864,1.259629675885688,-1.2219052058942266,1.3878648371212225,0.8297805820521749,-0.3447051364180961,0.17745908360284335,0.5957670086757754,False,c2,1,"Both domains return an ""untrusted connection"" warning if accessed through the https protocol.
For wikitech, but 22926 is related.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://wikitech.wikimedia.org",46760,-29,Medium,True
9.589188894257967,-5.6241286750446715,2.3676683706617077,-2.7914240165286843,3.0339183996152377,-3.10207887057176,2.309015273547147,-2.1221752658231874,0.4986986882805371,-0.7569592357592718,-0.1182648461250273,0.17634476593142412,-0.49042017887590106,0.4350683365084427,-1.8232042009051157,0.18593300642441513,-2.389480584183029,-1.0129439485073317,True,c2,1,"When you visit:
https://mail.wikipedia.org/mailman/listinfo/wikitech-l
it provides the cert for *.wikimedia.org
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68553
https://rt.wikimedia.org/Ticket/Display.html?id=6981
https://bugzilla.wikimedia.org/show_bug.cgi?id=73290",46731,-29,Medium,False
4.569131604090119,-3.779140975022699,-0.954412067195058,3.0610702803631487,1.7639669373062108,-3.4355043855600256,-1.4493775551529957,-0.5969204562099404,-1.683123247705643,-2.623654663858961,2.981832173814617,-0.13635066527414375,-2.5986066000102808,-1.849073080482198,-0.6683576854012099,2.5033195224562976,0.41114380668764583,1.2081415571509357,False,c2,1,"the id is
<id>//en.wikipedia.org/w/index.php?title=French_language&diff=536359399&oldid=536357691</id>
it is missing
the scheme (http or https)
both in watch list
https://en.wikipedia.org/w/api.php?action=feedwatchlist&allrev=allrev&wlowner=Xavier+Combelle&wltoken=...&feedformat=atom
and in [[Special:RecentChangesLinked]]
https://en.wikipedia.org/w/index.php?title=Special:RecentChangesLinked/User:Xavier_Combelle&feed=atom&target=User%3AXavier_Combelle
in thunderbird it makes [[Special:RecentChangesLinked]] broken but strangely not the watch list.
--------------------------
**Version**: 1.21.x
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52253",46647,-30,Medium,True
-4.367902063420829,4.968231567517922,-3.1270159067547265,-5.476424806830564,-1.3893598486238392,3.073934526562031,-0.7015285242836393,-0.46551072447743735,-0.7281034949694989,-1.4848144618741586,-1.0708527868372628,-2.6703494083915134,1.1237100144350216,-1.5828542193326895,1.7456232192659042,-0.2908239305911182,2.023369770723387,-2.051941314031943,False,c2,1,"The Interwiki table currently requires the specification of the protocol. Instead, there should be an indication of whether the server at the destination supports HTTPS, and then the protocol should be selected dynamically, to match the protocol in use on the current page. If HTTPS is not indicated as being supported, then the Interwiki extension should fall back to HTTP by default.
I tested this on MediaWiki 1.18.x, using the older version of Interwiki required for 1.18. I looked at the code changes, and didn't see anything recent that indicated protocol-relative URLs were implemented in newer versions. If I've overlooked it, apologies.",46573,-30,Medium,
8.381412216059736,-7.125362278500958,4.507960118617856,-0.6033498731238199,1.6147683129150434,-3.3670195103646448,0.7781775155888546,3.5809501073792376,-0.7584244131448818,-3.092537567824297,-2.0330580059507075,0.4508339113266837,-2.4905951865505003,-0.8843129060747081,-0.4260533617957991,-0.41736813487343516,-1.9904827630236532,0.30892558927897107,False,c2,1,"**Author:** `bugzilla+wikimedia.org`
**Description:**
When installing through HTTPS, LocalSettings.php $wgServer still has HTTP protocol thus no stylesheets are loaded.
--------------------------
**Version**: 1.20.x
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66481",46260,-32,Medium,False
-0.817494019279561,-0.8088570120717424,-4.7387531836566765,-0.0886567734114948,3.805011795229744,2.9923510057299136,-3.02579305884598,-0.44890605608612955,-1.1427196080856068,-3.054172615852754,-0.08589546835541428,-0.3925050006083475,0.34520891075587956,-2.4655377088345225,-0.6708756371076721,0.6233360952880738,-1.0730823346569471,-1.7997176267485389,False,c2,1,"Screenshot of described error.
While working at ACC on the English Wikipedia, I came across an expected error. While the error was fine, the message itself needs to be fixed as the link is shown improperly. I have attached a screenshot and the text of said error is pasted here:
The requested username is already taken in the <a href=""http://meta.wikimedia.org/wiki/Help:Unified_login"">unified login system</a>. Please choose a different name.
--------------------------
**Version**: 1.21.x
**Severity**: normal
**Attached**: {F10231}",45939,-33,Medium,True
3.5754496470284916,-4.157705978568682,4.591860408635238,1.2661847725001487,-0.6028193008658163,-0.6997169510068073,2.211444292365372,-2.507389111337981,-2.0056038251821495,-1.4011285600112942,-0.7114239826255329,-0.6211009070457648,0.7077585289541912,-0.7691426998475084,0.043577163783233175,-0.246580842132754,-0.15309581541625805,3.3213833930038126,False,c2,1,"**Author:** `mathias.schindler`
**Description:**
While accessing directories such as http://dumps.wikimedia.org/other/pagecounts-raw/2013/2013-01/ and others in the directory hierarchy, I am getting HTTP 403 errors.
Reloading the page usually helps.
--------------------------
**Version**: unspecified
**Severity**: normal",45623,-34,Medium,True
-1.1832815852346878,5.007500910662227,-2.6432255131576383,-1.3360884679463316,-6.400750145275584,3.4084794933852702,-1.011560671313224,0.53627635175065,1.3518480772297834,-1.148317167388071,0.908960475618827,-2.0338795098002995,0.4822627650051272,1.6345337637734607,1.3271559870004364,0.4455230895714599,0.5558682935039314,-0.006135908484148134,False,c2,1,"Info:
The develop branch (since 2012-11-24 https://github.com/ether/etherpad-lite/commit/fdf0b1a3844b2441852e472781a7bf41f8775b18 ) of Etherpad lite has been enabled to support (optionally, currently not by default) SSL i.e. to run EPL via https:// on native node.
The only required change:
* set up the ssl section in settings.json and let it point to a suited server.key and server.crt on your server
--------------------------
**Version**: unspecified
**Severity**: enhancement",45404,-36,Medium,True
0.2798771157043789,1.884174532840575,0.15132078135359706,-1.5085342634245051,-5.577757189888889,-1.481624710286401,-0.6098761315755077,-1.3510645916200716,-0.19397473950712807,-1.174362731424504,-1.2206070013483195,0.3268823683596116,2.0970733698429314,-1.6996513805095002,1.7175855255786274,-0.9560071371275585,0.21604380346405438,-1.1727932629324336,False,c2,1,"**Author:** `russavia.wikipedia`
**Description:**
Currently, all uploads to Commons using UploadWizard are categorised into:
http://commons.wikimedia.org/wiki/Category:Uploaded_with_UploadWizard
There are now some 2 million files in this category, which makes it almost impossible to browse due to the sheer number of files. It would be better if uploads were categorised by the month and year they were uploaded. e.g. ""Category:Uploaded with UploadWizard (November 2012)"" to make browsing of files easier.
Can we get UploadWizard amended so that this can occur in future. Current uploads can be re-categorised by one of our friendly Commons bot operators.
--------------------------
**Version**: master
**Severity**: enhancement
**URL**: http://commons.wikimedia.org/wiki/Category:Uploaded_with_UploadWizard",44548,-39,Medium,True
-6.140041020961087,2.277497289947469,1.6319633355705747,5.955866519262489,2.691721541802829,1.7977058469273477,0.5982135943454736,1.2173076117322874,-0.2470794587822625,-1.3208501772187522,-0.4177164614448805,0.9925808931168121,1.0471583732260044,-0.11744800098655439,-0.35333090077797014,0.7116332758101451,-0.505325889081293,-0.3505494646113725,False,c2,1,"Screenshot of a broken error message
When TitleBlacklist blocks creation of a new user account, the error message is now correctly parsed and displayed (see bug 41242). However, if it blocks autocreation of a local user account, the message is broken. See the attached screenshot.
The problem is that while the AbortNewAccount hook (see http://www.mediawiki.org/wiki/Manual:Hooks/AbortNewAccount) returns the error _message text_, the AbortAutoAccount hook (http://www.mediawiki.org/wiki/Manual:Hooks/AbortAutoAccount) returns the error _message name_. But both hooks are implemented with TitleBlacklistHooks::abortNewAccount which currently returns the error message text, so that AbortNewAccount works, while AbortAutoAccount does not. (Note the extra angle brackets on the screenshot: the resulting _message_ is used as a message name.)
The simple solution of separating the hook implementation into a new abortAutoAccount method and leaving the wfMessage call just in abortNewAccount is probably not acceptable, because AbortAutoAccount would result in a message without the $1 and $2 parameters. Either a new nonspecific parameterless message would need to be used in this case or the whole AbortNewAccount hook would need to be redesigned.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F10268}",44228,-41,Medium,True
0.21859212909601444,-3.1048566313661627,-2.302695278327292,1.9775353394308195,-2.6290121155385786,-4.846966064977845,-2.5331998885288485,-2.040826974605459,-0.8688365271909999,-1.2729042417150054,-0.36773322923682183,-0.4167908363802483,-0.7603204574694153,0.7633942622310155,-1.2733622220847884,-0.36247663068148617,-0.039765000342526946,-0.9677839992603201,False,c2,1,"From mediawiki-l at http://permalink.gmane.org/gmane.org.wikimedia.mediawiki/40553
Situation: InstantCommons does not work for me (I sitting behind a proxy).
Configuration:
- mediawiki 1.20 on debian squeeze
Proxyconfig in Localsettings.php
# PROXY Setting
$wgHTTPProxy = ""http://*<myproxy>*:8080"";
# proxy bypass list
$wgConf->localVHosts[] = '*<www.secret.com>*';
In my firewall-log I see that the debian-box tries to connect directly
(which does not work)
- Server: 91.198.174.224 port 80 http
- wikimedia-lb.esams.wikimedia.org
--------------------------
**Version**: 1.20.x
**Severity**: major",44196,-41,Medium,True
-6.552624529739476,-0.2692418939423984,3.39808492046204,1.9199339579342278,-0.2900895039450628,-2.0259803048029497,2.521921012552144,0.7100447505587402,1.2642214534392178,-0.012892529823631094,1.3197618590188118,-1.410945436390359,1.4522229089478267,0.6884789301653047,0.569609434251535,0.9820826421059609,-0.49558155443359,-0.8324744215624624,False,c2,1,"Currently it's almost impossible to detect trends as 5xx errors are buried at the feet of the peaks of gazillions 500 errors.
Perhaps it should also have a month-old report but that's less important.
(I wanted to check the amount of 504 errors in the last few days/weeks.)
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://gdash.wikimedia.org/dashboards/reqerror/
**See Also**:
https://launchpad.net/bugs/925635",43754,-43,Medium,False
-4.028159730986289,-4.800549671185269,-7.955635391524144,-6.502984175806807,3.147818896831706,-4.896389634961188,1.7445636818022816,2.6965057083236674,-2.5500961729978204,5.137608881929186,-1.5048273672113401,1.3281179104984109,-1.4340327283481589,3.928256843082684,-4.75400307183248,0.4883150847120248,2.1040991294271567,2.2038166463787707,False,c2,1,"If you change your password, then the app just sortof gets 'stuck' and doesn't go anywhere - keeps trying to auth and fails.
--------------------------
**Version**: unspecified
**Severity**: normal",43704,-43,Medium,False
7.434463331563968,1.0487605902551973,-10.89663850388601,8.359418667890083,-1.6045468865848618,-1.3827301036555029,1.9196899851810079,-0.8618351536807611,-1.82772519811006,2.6143395717230824,0.24771456767329214,1.0648208860370942,-0.1729242509295572,-1.5510510769745216,-0.20230323592524613,-1.3896837632000552,-0.9979046792506994,-0.23951081461542056,False,c2,1,"the lgtoken attribute (which is need to create a valid cookie for future requests) is invalid after successful login.
request (POST):
action=login&lgpassword=xxx&lgname=MerlIwBot
response:
<api><login result=""NeedToken""
token=""087cb80705ed9564d18c3309fae1ec""
cookieprefix=wikidatawiki
sessionid=""9b4c867c526e06f0e55ee395287ff0""
/></api>
request (POST):
action=login&lgtoken=087cb80705ed9564d18c3309fae1ec&lgpassword=xxx&lgname=MerlIwBot
response:
<api><login result=""Success""
lguserid=""3280""
lgusername=""MerlIwBot""
lgtoken=""<22><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>""
cookieprefix=wikidatawiki
sessionid=""9b4c867c526e06af0e55ee39f287ff0""
/></api>
password, sessionid and first token is a bit modified for this paste of course. The problem is that the lgtoken is invalid because it only contains character hex:EF BF BD (which is ""object replacement character"" according to unicode table)
Login on all other wmf wikis and wikidata-test-repo.wikimedia.de work for me.
--------------------------
**Version**: unspecified
**Severity**: normal",43586,-43,Medium,True
-3.9890485561397533,-12.331374608390355,-5.86996203282016,8.015100368301995,-1.3684627276936472,-6.109797842108809,4.6942508583488545,7.143090815902837,-4.1214585139447815,2.0835211345709848,7.8482810604621225,-5.627902317834922,11.634238177333142,8.231241268667352,5.8357626810652325,-1.7960151281601688,1.1839077857977174,-0.08671442099837545,False,c2,1,"$ curl -v -H 'User-Agent: iPhone' http://www.wikipedia.org/wiki/
* About to connect() to www.wikipedia.org port 80 (#0)
* Trying 2620:0:861:ed1a::1...
* connected
* Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0)
> GET /wiki/ HTTP/1.1
> Host: www.wikipedia.org
> Accept: */*
> User-Agent: iPhone
>
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 504 Gateway Time-out
< Server: nginx/0.7.65
< Date: Fri, 19 Oct 2012 20:29:48 GMT
< Content-Type: text/html
< Content-Length: 183
< Connection: keep-alive
<
<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor=""white"">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/0.7.65</center>
</body>
</html>
* Connection #0 to host www.wikipedia.org left intact
* Closing connection #0
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=36601",43224,-45,Medium,False
-0.19811624831477337,0.3115535099406852,-3.140479329250061,-2.408332123370654,-3.6052445647863953,-0.41029035697837635,-0.12079449940774634,-1.5958200134921632,-0.032052923900788344,-0.6076154207084628,-1.0633166822207833,-0.3470823620328506,0.7604045857453885,-0.580523897080699,-1.7441957422929004,0.11497586510368377,0.2367774172904198,0.08297844393851439,False,c2,1,"Reportedly, Idf0a6547 causes insertDefaultSites to fail with an error:
""Warning: Invalid argument supplied for foreach() in /Library/WebServer/Documents/wikidata-repo/extensions/Wikibase/lib/includes/Utils.php on line 88""
I was not able to reproduce this, but to allow for easier investigation of the issue, I have submitted changes that report more meaningful errors on failure: Iab7e750e for Wikibase and Iad3995a6 for core. If you experience the problem described above, please patch these in and report your findings.
--------------------------
**Version**: unspecified
**Severity**: normal",42701,-48,Medium,True
-2.019450240778605,0.16432445359891723,1.0220260646439705,0.7534977189858822,5.026035716812444,-0.9180454083819181,1.7827942904031824,0.021861136092501787,0.09942628982879548,-1.7571822107238666,-0.0459743849530434,3.191713025895888,-1.0996793296733376,0.47172617973681064,1.5103128616194361,-2.2313963088862696,-3.0572162846310156,1.0514101092817099,False,c2,1,"When $wgServer has a scheme, i.e., it is not protocol-relative, which happens to be the default, wfExpandUrl( ..., PROTO_HTTPS ) will give an HTTP link. This causes ResourceLoader content to be loaded over an insecure connection. It also causes redirect loops when redirecting to HTTPS using wfExpandUrl.
--------------------------
**Version**: 1.20.x
**Severity**: major",42679,-48,Medium,True
1.0633276213219767,6.400012989160452,7.8826989827791465,-0.36805269791464046,-4.859103888117277,0.038112112761146344,0.9521122933147828,-0.5300295442841907,-0.7942573581350462,0.38940133063939886,-0.6263364900415054,0.1411269805326032,1.0233436064809553,-0.046185153504040066,1.3728092470658915,-2.529138183732473,1.7016103925907802,-1.6490607885198494,False,c2,1,"Any attempt to download files from HTTPS sources via url-downloader.wikimedia.org:8080 results in an error: Error fetching URL: Received HTTP code 403 from proxy after CONNECT
I'm guessing this is just because the proxy wasn't setup to allow HTTPS...
--------------------------
**Version**: unspecified
**Severity**: normal",42596,-48,Medium,True
-5.145353713884573,-2.4025327517964463,-0.6115531461153836,3.8142945404660455,-1.9937300516930372,-1.78154531728943,3.4995663484302346,-1.7482934485512676,-0.4706408376035476,-0.9977395099804638,-0.7628680920847222,1.9687383164435939,-0.20940454631470296,-0.5476178757852743,-1.6765234144379182,-1.700037644664889,-0.02884035827103082,2.3112967332175325,False,c2,1,"Just like we have $wgCaptchaBadLoginAttempts, there should be a config array maximum attempts for other $wgCaptchaTriggers. Without this, guessing and building canned answer libraries becomes easier (though $wgCaptchaDeleteOnSolve helps).
--------------------------
**Version**: master
**Severity**: enhancement",42496,-49,Medium,
2.673557617329655,-1.0308506277842682,3.5987332194552977,-3.766929516527782,-0.044509362289977816,3.520116055084424,2.415702813560194,1.3158103590030357,-0.05571368572044311,0.335111256818708,0.3197606954663086,-3.629098810571368,-0.8748415683077502,0.9712716792401919,-1.0150723183972392,-0.031155098259127934,-0.09762682534413081,-1.3970055002303574,False,c2,1,"**Author:** `M8R-udfkkf`
**Description:**
The Wikimedia blog at https://blog.wikimedia.org/ does not link to the secure versions of the various wikis. That is, it links to http://en.wikipedia.org instead of https version.
(Not sure if its the right component)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37229",41539,-54,Medium,False
-0.32656598153005323,3.0510022145408193,2.7541861865662725,-5.283015571132993,0.49794384251210677,-1.9563109307533728,-0.876300945145851,-3.18124829002717,1.89376418803264,0.6011955352791531,-0.02347186289430203,0.3115306244619571,0.5243747459987427,-1.2023116286204405,1.0824249605302105,1.7694165128252008,-0.12021767508326286,0.41718828860192425,False,c2,1,"**Author:** `simone.hinterseher`
**Description:**
After Login with OpenID I get to:
""Verification succeeded
Successful verification and log in as user username.
Your OpenID is https://www.google.com/accounts/o8/id?id=someId
This and further OpenIDs, and an optional account password, can be managed in your preferences.
Return to Main Page.""
When I click on my user profile to add the OpenID to the created profile I get
""Not logged in
You must be logged in to set user preferences.""
I can send me an email reminder of an account password to login later and add the OpenID, but I think the login should be there automatically.
Also, is it possible to automatically add the OpenID to the created user profile?
--------------------------
**Version**: unspecified
**Severity**: normal",41435,-54,Medium,True
1.7139440097119159,-1.7340224764409964,0.7925051632286149,-0.35086406896454614,0.4389593099510911,3.4340879858893834,3.476165242033084,3.349083743675516,-1.7404945638295553,-0.7927537005722867,-1.273628617589964,-0.09207828497053372,-1.3235980370328768,0.3935690239324314,-0.035301548467495,-0.6421960987129942,0.3224767537580544,-1.5407973550183498,False,c2,1,"With the exception of a few minor bugs (specifically email links), $wgSecureLogin functionality is for the most part complete. Is there any reason HTTPS login has not yet been enabled on enwiki?
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=29898
https://bugzilla.wikimedia.org/show_bug.cgi?id=31323
https://bugzilla.wikimedia.org/show_bug.cgi?id=47832",41380,-54,Medium,True
8.186241696022101,-3.169105377204371,-6.92275076648883,2.4243541511340236,0.30481661718223274,2.472167312815892,-1.1527243780997862,0.02056819451448405,1.2051822415824192,-3.2476510943492944,-1.8763075865365901,-1.1237380100981371,-1.6039190402058248,2.1610763147140624,-0.3174924639695904,0.07254272343993279,0.02395790275295573,-0.4722248007659069,False,c2,1,"Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of https://www.mediawiki.org/ (*.mediawiki.org)
--------------------------
**Version**: wmf-deployment
**Severity**: normal",40412,-59,Medium,True
-1.8686939825116677,-7.265047964897938,-4.894060884633909,-0.5110688325563689,-0.34603932792038694,0.04811320939498742,-2.0727163128344324,0.010537596542739447,0.99669572449601,2.1862552031778533,-1.3573838621390872,0.007045236965927737,1.5248746785596623,-0.46551831738575267,-0.22339014264663692,0.09878149565084918,-0.1007227159489208,0.0854329448962543,False,c2,1,"The last modified timestamp is available and already being included:
header( 'Cache-Control: s-maxage=3600, must-revalidate, max-age=0' );
header( ""Last-modified: $lastmod"" );
We could extend this further and make it respond with ""304 Not Modified"" (without body content) for requests that have the same version cached. Should save a fair amount of bandwidth.
https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob;f=extract2.php;hb=HEAD
--------------------------
**Version**: unspecified
**Severity**: enhancement",40168,-60,Medium,False
3.2111874104420735,6.771798520557482,-0.7103539493787796,-8.787503879177706,-4.018677203273225,-2.097562658473346,2.571869919386434,-5.458691206337848,-0.6665415886882605,0.48422046767449434,2.0265739355054095,2.0283261534762644,1.0803659462913302,-2.5886011737967145,0.4823151774359973,-1.7565177169171355,0.5891551361589273,0.934693210317395,False,c2,1,"When trying to log in to the English Wikipedia at school, I get told that my IP is blocked from creating accounts. This is correct but it should -not- stop me from logging in.
Relevant block log: https://en.wikipedia.org/w/index.php?title=Special:Log&page=User%3A89.238.166.170&type=block
Screenshot: https://dl.dropbox.com/u/10971457/Wikimedia/Login%20blocked.jpg
I have not been able to reproduce this on my local test wiki.
--------------------------
**Version**: unspecified
**Severity**: minor",39969,-62,Medium,True
0.9784392558263657,-17.86992776358544,-5.219818564832162,-2.574762388680587,-2.044303214755108,5.861222248596336,3.0289500550584103,-0.6503536183421449,0.1615675483468746,0.5658695065401274,0.4597574700441389,-1.2991801474850757,-0.15692152869220966,-0.4236415978750214,-0.5844015127003601,-0.49031876968427435,0.07090060870768489,-0.29145247952854025,False,c2,1,"
--------------------------
**Version**: unspecified
**Severity**: normal",39912,-62,Medium,True
2.2334644788650766,-16.01221072148655,2.6961084062615654,2.11490128566519,-1.4779802180143928,1.1672250810568603,2.755630299216027,-1.3909080560338025,0.4365253360039655,0.029009133436314727,-0.04017675114223396,-0.5640651416720179,-0.015769156774218196,-1.2035070449136098,-0.7112840404540801,-0.30505683819825546,-0.054988504378126635,-0.4484685756647704,False,c2,1,"
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.m.wikinews.org",39650,-63,Medium,True
-1.6134312620949824,-0.09575196366069072,-3.1859846943672423,1.2019145363663193,1.8956302790056077,-2.4309476365644898,-0.7929227227427251,0.2780442841573526,-0.6352180975471249,-1.3066016966597798,-1.1626470738698473,0.07162834173534716,1.073277374051349,-2.4149238889043394,-1.1141540720148608,0.2017520186369049,-1.1937443498791835,1.4198488240145621,False,c2,1,"The placeholder text at <https://en.wikipedia.org/wiki/Special:UserLogin> should be removed.
""Enter your username"" and ""Enter your password"" is unnecessary and possibly insulting to the user (it can be read as condescending). Looking at other sites, it seems the practice of using both a placeholder and a label is uncommon for fields of this nature.
---
On mobile (with smartphone media query, not tablet) the placeholders take a more important role, as they are the only field indicators.
That's questionable on it's own, as the information, what field the user is currently typing in, is disappearing after the first character is typed.
Should we improve the #voice_tone of the placeholders or get rid of them?
| Desktop | Mobile (showing the issue when User is typing) | Mobile (Tablet)
| -- | -- | --
| {F4582762} | {F4582755} | {F4582758}
| Sign Up |
| {F4537580} | |
--------------------------
**Version**: 1.22.0",51018,-13,Low,
6.558845915792745,-11.798936482346452,6.351114199235205,-0.9610204367104025,-1.3760438884494166,-0.9474391091215304,-1.8564843134877194,-1.3054087748828809,0.44798446811565273,-2.531282584446091,-2.2555685293812378,1.396367754679136,1.6271135856173236,0.13350144034250722,-1.8861730844115274,0.3592059328720111,-0.3773644649463206,-0.7759987910466191,False,c2,1,"Signup on TWN
See screenshot.
--------------------------
**Version**: 1.22.0
**Severity**: trivial
**URL**: http://dev.translatewiki.net/w/i.php?title=Special:UserLogin&type=signup
**Attached**: {F10844}",50887,-14,Low,False
7.611107034189317,1.949288566024535,7.721392422729846,0.7111157923102507,-0.6257054489014011,4.306218875515428,-0.6083857495533396,-1.408283604641496,-1.1749929840181352,0.16288579673004833,-2.0247442011694257,0.3731403368429338,-0.6268693584453704,0.4160532567663191,-2.647678859785589,-1.2444836458948008,-1.1191994391583444,1.639557996710182,False,c2,1,"Seen at
http://commons.wikimedia.beta.wmflabs.org/wiki/Special:UserLogin/signup at least after navigating to Special:CreateAccount
The browser test for creating an account has a function that checks for Resource Loader errors: https://github.com/wikimedia/qa-browsertests/blob/master/features/step_definitions/create_account_steps.rb
That function is returning an error ""Error modules: jquery.NavigationTiming."" for IE7 and IE6.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48309",50303,-16,Low,True
7.248815170764731,-10.770033835200262,1.4063617765208996,0.5739363947602527,-2.1224709541211126,0.9588216883139735,1.8646366393026748,-0.5649696821534655,0.797871048887516,0.20528986316494713,0.22370917067779716,1.160232039772547,0.5984085994322563,-0.447090583425684,-2.1514181338079608,0.12021546333906682,-0.4566477312798245,-0.9118472758199467,False,c2,1,"**Author:** `swalling`
**Description:**
Create account
See attached screenshots for minor spacing/whitespace issues.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F10342}",50189,-17,Low,False
6.774124323763649,-0.27748829179145673,1.204842721356247,-3.686150039869927,-0.9952456742888267,-1.0379371515994384,1.1535159870414455,-2.3005788236877645,-0.7646083132739525,-1.1873794310833397,0.22846381567290308,0.38881828943659325,-0.09545395996213202,-1.184311550159316,1.1684928087783018,0.23161944508226376,0.19066989368495157,1.2018277421266246,False,c2,1,"**Author:** `swalling`
**Description:**
Login in IE6
Completely bonkers.
IE6 is less than 1% of our user base, and is Grade B for compatibility (http://www.mediawiki.org/wiki/Compatibility#Browser) but this is pretty bad. We should take a hack at it unless it would require completely rewriting the CSS etc.
--------------------------
**Version**: unspecified
**Severity**: major
**Attached**: {F10338}",50188,-17,Low,False
9.812879278000443,-6.176453594350889,6.850936672615049,2.549191045295814,-4.286834088069895,-2.1374309072954487,-0.6652143991599031,-1.1869969795402593,0.3927974560075439,-3.2696089413042135,-2.7462593949866276,-0.7935741678438177,0.39984298602566515,1.5652300071665195,0.6020467066359982,-1.4541822002987135,0.3299628419305196,0.613544990041816,False,c2,1,"Screenshot of error page
Location: https://gerrit.wikimedia.org/r/#/c/62207/
-------
HTTP ERROR: 500
Problem accessing /r/. Reason:
Guice provision errors:
1) Cannot open ReviewDb
at com.google.gerrit.server.util.ThreadLocalRequestContext$1.provideReviewDb(ThreadLocalRequestContext.java:71)
while locating com.google.gerrit.reviewdb.server.ReviewDb
1 error
Powered by Jetty://
-------
--------------------------
**Version**: wmf-deployment
**Severity**: major
**Attached**: {F10881}",50061,-17,Low,False
-3.4687620452434325,-1.5098057369752667,-3.493531411773308,-4.160946778337895,-1.7085582956111862,0.7440277104731927,-0.3124802056327747,-0.3568446324528327,-3.384724481399741,2.666769062829104,3.926163940433623,1.6393779308650893,0.7704202782588925,-1.848868834831154,-1.082897611812247,-0.21441626264206803,-0.5094800327206385,0.7023484440980379,False,c2,1,"Looking at <https://en.wikipedia.org/wiki/Special:UserLogin?useNew=1>, the ""Log in"" button is really big. I think it could be described as oversized. I'm not sure why this is. In Vector, it's a lot of blue to deal with.
Looking at facebook.com, gmail.com, and twitter.com, it seems like stylizing these buttons is common. But all of them seem to use regular/normal size buttons.
Even at <https://en.wikipedia.org/wiki/Special:UserLogin?useNew=1>, the other button (the green ""Join Wikipedia"" button) is closer to normal size.
--------------------------
**Version**: unspecified
**Severity**: normal",49785,-18,Low,False
-7.618108358262573,0.3025231088375939,1.4516172117270578,0.6026901477430837,2.536741246307398,-0.39208132157043996,1.451336531563867,-2.7849601410602682,6.034303090302194,1.0545286603738653,2.830642882794304,-0.6489140464494915,1.392904251326219,0.47009912175626667,0.676273230826645,0.9985788591068383,0.40249731798267563,-0.2662748795444543,False,c2,1,"We should explicitly investigate the appearance of the forms in low-light / low contrast environments and see if we could improve it. We could try making the placeholder text a bit darker, and ensure that the labels are darker than the placeholder text.
--------------------------
**Version**: 1.22.0
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47698",49777,-18,Low,True
2.462119994009417,-8.186726764791112,4.116474286247783,-1.6646444540293555,4.275591597421819,1.2265929871978967,2.05829715323354,4.81783342051751,-0.4787752152946597,1.1535047270632672,2.5934098216411265,-0.8582216042503594,2.9130008812243755,0.13158497852148354,-0.7721640304353636,0.4587136242285904,0.1284974429712853,0.649544120243833,False,c2,1,"Compare:
* http://piramido.wmflabs.org/wiki/Special:UserLogin?type=signup&useNew=1&useskin=monobook
* http://piramido.wmflabs.org/wiki/Special:UserLogin?type=signup&useNew=1&useskin=vector
The blue button is no longer blue. And there's a grey background with strange padding. Maybe some other quirks.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47777",49698,-18,Low,False
-3.8321084200880695,0.1817124879316392,2.8207258685547743,5.10540413413695,4.707580647895311,0.6918179649768215,-0.9568927366639342,-0.26989634480913705,0.619220919722884,2.5949715452270734,-0.853292586816782,-2.4595799543219203,-3.0885733438558765,0.6346587764719631,1.4327882572212483,-0.15114258651826806,-0.010072815555463466,-1.267775191355664,False,c2,1,"**Author:** `Thehelpfulonewiki`
**Description:**
<https://en.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Main+Page&useNew=1>. Please can we make the image on the left of the ""contributors this month"" text gender neutral (instead of the male one that it is now)?
The same with <https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&useNew=1>, the background image behind the ""Don't have an account"" text is not gender neutral.
--------------------------
**Version**: unspecified
**Severity**: enhancement",49696,-18,Low,True
-0.4709437254655593,1.034689725097234,0.4246026957469127,-1.5042322648758404,0.6268545842077395,-4.568348165312449,-7.228006931535254,-1.9609629746255206,0.5980052852616533,3.7591192075793405,-3.624999420882642,-2.4717236683625456,1.6979072714030998,0.7046742528528203,1.0952982228462913,0.16098666398095873,-1.4734977537993925,1.775580350231318,False,c2,1,"**Author:** `Thehelpfulonewiki`
**Description:**
On <https://en.wikipedia.org/w/index.php?title=Special:UserLogin&useNew=1> next to the check box and the text ""Remember me"" the ""(for a maximum of 30 days)"" is missing. Perhaps we can shorten it to ""(for 30 days)"" or even ""(30 days)"".
--------------------------
**See Also**:
{T62437}",49694,-18,Low,
-4.445295008749967,-2.547053742173306,-1.6779876534719893,1.4390802980092476,2.4246365763027233,-1.7143405095363826,-0.9507019445438321,1.1443628547740485,-2.0119083083237195,0.4102775785641599,-3.037213440622153,-0.4330173033541148,-0.7507316595345088,0.17439740856558306,-0.6356056151965079,-0.4701750572651703,0.48558086872821526,0.2982167367035753,False,c2,1,"**Author:** `Thehelpfulonewiki`
**Description:**
When I go to https://en.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Main+Page&useNew=1 and make an error (username is use, non-matching passwords etc), the Header of the red error message is an the text ""Login error"" in bold. This isn't quite correct because the user isn't logging in yet - they're trying to create an account.
Perhaps ""Account creation error"" or words to that effect?
--------------------------
**Version**: 1.22.0
**Severity**: minor",49691,-18,Low,True
-6.626434149459664,3.288524658762185,5.569331052109707,1.7637070023467714,-3.77350632559528,3.406619641792118,-1.006616580113345,-1.1667363699466473,4.283986346787554,0.1228316331410868,0.4662350168647591,-1.7872795121147473,0.8496078895425452,-0.2564364834445403,-1.1694993079130303,0.08445873848281008,-1.3702493584323594,-0.8434024803095446,False,c2,1,"Please write your bugs report to http://parsoid.wmflabs.org/_bugs/ only with https to avoid a secure hole.
Please see this as a blocker for the coming roll out. Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",49508,-19,Low,True
-3.6745228900218434,-1.6487566340887323,-4.107044704788052,-4.993210369637818,0.4539937538015786,-2.499396325610972,1.2483864407597318,-0.425819201740116,2.338342827004868,-0.24652387006558296,0.59731844504689,0.9456496555561491,-0.7476748147321421,-0.5383000726701503,0.8803441660898228,0.6792906071355951,0.7917259941610666,-0.7418367552906429,False,c2,1,"HTTPS can be enforced via <https://noc.wikimedia.org/conf/remnant.conf>. I had a thought today that wikimediafoundation.org should be HTTPS-only. Subsequent thoughts added doubt. For example, the wiki doesn't really get used for donation forms as much these days, I don't think, so some risk is mitigated.
But... it's still a weird fishbowl wiki that allows strange uploads and raw HTML, so it wouldn't be totally unexpected for it to enforce HTTPS. I think it might be nice to have. Filing this as an enhancement request for consideration.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",49276,-20,Low,True
-1.3844739425774297,-5.20009836321527,-1.7184208220915984,-2.922167091447497,0.6927926688359627,-2.6029459292997075,-2.8760836041637505,-0.319288188770218,3.171239266892589,-0.2290489146760093,-2.283696328630102,-0.9025705030999333,0.7221362640965707,-0.10980409362455656,-1.1452389850482874,-0.50165470919799,-1.543001466944577,-0.31901859641456154,False,c2,1,"**Author:** `testingwithfire`
**Description:**
I'm testing the new login process with ""useAgora"" in the query string.
If you have too many failed attempts to log in, you'll get this message: ""You have made too many recent login attempts. Please wait before trying again.""
How long should I wait? The message should specify the time to wait.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=29191",48965,-21,Low,True
6.594692301475186,-2.6453815776991014,3.378128332952638,-7.719780870508859,-3.768731875922173,0.5004020200645893,0.39677812743293916,-3.833134677612953,-0.07285980901186809,-1.8174329488098242,-3.204451196959625,-0.1704151831915377,-1.9929658908481658,-1.2000690150579616,1.645302379024221,-1.0618527695850923,0.7570066698933731,-0.31015995570439703,False,c2,1,"I keep getting redirected to https://samarium.wikimedia.org/ by HTTPS Everywhere in Chrome. It'd be nice if this worked.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://samarium.wikimedia.org/",48827,-21,Low,True
-7.383480210209411,1.1446328668217625,-6.076073304793697,-5.056491079526426,-1.1109079382929763,-2.6748472241476455,-1.080051353494766,-3.806285353010538,1.620424585722241,1.2347621891867444,0.31841298021014985,1.1084732940279804,1.7362029284482272,-0.29354398839710516,-2.1275041903051393,-0.7011738410493606,-0.7585044528151809,-0.20559046693796934,False,c2,1,"Currently, there is no ""remember me"" checkbox on the mobile site for en.wikipedia. This means that every-time my browser crashes or I close it, I have to re-login to check my Watchlist. This results in me having to login 20 times a day on average and has driven me away from using the mobile site. Would like to see this checkbox added to the mobile login page, even if it is only ""remember me for today.""
--------------------------
**Version**: unspecified
**Severity**: normal",48241,-24,Low,True
0.9447689177388567,-4.641181185077919,3.86952963060925,4.614428098807261,3.9579497742695797,-0.12610951098381062,-5.336527370310398,-0.7766372661512617,0.7776681028928172,0.4469896790090706,0.8155499211524551,0.5841506184954728,-0.8633362263077808,-1.6412011478030606,1.0026177814297181,1.1123320857362324,-0.20143874366150527,-0.36032682510365444,False,c2,1,"screenshot of the problem
1. Set the phone's language to Hebrew.
2. Install the Commons app.
3. Start the Commons app.
4. The placeholders in the ""username"" and ""password"" fields are aligned differently.
They should be aligned the same way.
--------------------------
**Version**: unspecified
**Severity**: normal
**Platform**: Smartphone
**Attached**: {F10852}",47989,-25,Low,False
-5.875095653027283,3.5429554112261457,-3.3578922587825453,-4.637867584922832,6.245418703562034,-6.978897247479563,3.020702560299944,-3.625838482439808,-2.811903316088717,-0.5335798298360226,-0.7312088162821793,-2.3019322847632226,-0.3920373943942792,1.2829982460732499,1.496910956361936,-0.37504530145730763,-2.6520542270110816,-0.01662268746975526,False,c2,1,"When the Parsoid server is down completely (e.g. because you forgot to start it), the error message VE gives you is ""parsoidserver-http-200"". It's kind of ridiculous that it's presenting an error with 200, but it's also a lie: 200 wasn't the response code we got from Parsoid, we got no response whatsoever.
--------------------------
**Version**: unspecified
**Severity**: normal",47916,-25,Low,True
-4.536174134782585,-0.3495300661882137,-2.0350083999248856,1.7122306078990066,-2.762711693758977,-3.055862411915381,-6.832787721058319,-0.41522317810942144,-2.9370013551777063,2.759634040496823,-2.9259755234545586,0.16798838003662642,-3.2822937442689932,-0.04905541704471261,0.31551366695255734,-0.4868595681166926,-0.07722317318422633,-0.036656913395630264,False,c2,1,"If you go to
https://pt.wikipedia.org/wiki/Especial:Entrar?uselang=pt
you'll notice the borders of the <div id=""userloginForm""> and <div id=""loginend""> are not left/right aligned.
This seems to be caused by the presence of ""margin: .5em;"" for ""#userloginForm"" but not for ""#loginend"".
--------------------------
**Version**: 1.21.x
**Severity**: enhancement
**URL**: https://pt.wikipedia.org/wiki/Especial:Entrar?uselang=pt",47775,-25,Low,True
-0.17647046869936212,-0.6196017000841483,-0.4949759714127886,3.878827891366467,1.8903455546935315,1.759131656967148,-3.440546468473272,1.728629483381491,3.4084282640787515,3.6956546140584496,-4.624904772074506,-0.4866659538630945,-2.0819982433510553,-0.8866043831136148,1.8657603398360028,-2.3835751206592577,-1.5456393965640514,3.0060963750365755,False,c2,1,"Correct the button message text when converting OpenID (must be ""converting"" or ""adding"", not ""Login"").
A few more changes may be needed than to simply adapt the text above the button on the provider selection page ( Special:OpenIDConvert ).
--------------------------
**Version**: master
**Severity**: enhancement",47304,-27,Low,True
-1.858406316201655,1.3494373140438949,6.669499765651736,2.313586414983658,-0.7195799048714673,0.021934095003877774,1.2544615675455884,-2.997780270476484,-0.09098074415694662,1.4618835268124517,-1.3109427181076554,-2.1092664815225244,-1.488315780391126,0.10328580829364054,0.19522490159736527,0.22917152547249975,-2.662903365469208,-0.11922288845858842,False,c2,1,"As one can see on the URL provided, when browsing the thread history page, on the ""Comment text edited"" diff link it points to HTTP instead of HTTPS.
Looks like a hardcoded protocol.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://www.mediawiki.org/w/index.php?title=Thread:Project:Support_desk/GLobafunctions.php_wfParseUrl_choking_on_url&lqt_method=thread_history",47249,-27,Low,True
-9.721173277886711,3.4691743240524247,-0.9358760818985452,-1.5046342056650754,0.37735107281515023,0.4820096316622897,2.9069101675290705,-1.5696378281956833,0.33944854809164093,1.4221111345752346,1.2291557144749814,0.21949535885469795,-0.32397087846889505,-1.5543265751432318,2.7381560925934343,1.0597475039281217,0.5561325325796098,-1.6422505169842905,False,c2,1,"After having your account renamed, it is possible to log in again as the old name using your current password. This should not be the case.
I'd hazard a guess that the old user's password field in the database isn't being cleared at rename time.
--------------------------
**Version**: unspecified
**Severity**: enhancement",47101,-28,Low,False
7.393031098750045,-5.364880885486633,1.5459259497302646,-0.8093281706406787,4.282837631228199,-0.4927320717428486,0.08494144612075694,-1.6404481256572874,2.2639716297233017,-2.867477863443428,-4.299187653978301,1.4771597698478784,-3.110763185806257,0.5607389158842713,1.03230492491479,-0.2268649889842529,1.3193040844075032,-1.4244278371529417,False,c2,1,"**Author:** `sumanah`
**Description:**
https://en.planet.wikimedia.org/ -- SSL is now supported. I'd like an HTTPS Everywhere rule that says the browser should use SSL on that site.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",46751,-29,Low,True
-4.167016944361526,0.7702164475329223,4.478539916542246,8.566501661645965,-2.138261396821401,-0.34117237030699255,-0.35532171265169943,-2.550943356303341,-3.0943345907896687,4.847655048537405,-3.543566201602393,-0.2853570297380369,-1.566554871335689,-1.3180623816579011,1.278544491408769,-0.58869259985971,-1.73620571600099,-0.5904342029218681,False,c2,1,"**Author:** `fut.perf`
**Description:**
The image links in the final result page of the upload wizard (under ""Thanks for uploading!"") have an incorrect use of url protocols. They are ""http:"" links even if the wizard was run under ""https:"".
--------------------------
**Version**: unspecified
**Severity**: trivial",46226,-32,Low,True
0.627580454574121,4.840819946370054,-3.3961940323005386,-11.469495174262095,1.9320142097081892,-2.89319301772373,2.265275970710774,-2.782522374883849,4.043755258008068,0.11837427626927433,1.7219089624863337,0.4945126345399091,-0.35346379379665915,0.7857766649571882,0.257899268987428,-0.5023142799018655,1.081000186860826,0.5735715723083661,False,c2,1,"It's not sending a valid SSL cert for that but I know it may be not easy to configure so. I propose to point them to another IP, then disable https on that IP.
--------------------------
**Version**: unspecified
**Severity**: minor",45265,-36,Low,True
9.306775298971937,0.4440515714575799,2.0807036093547353,5.995844925947227,2.423913395920719,1.6056931323949384,-0.6540300309386584,-1.8405607645460176,-2.9841547809987334,2.274361790934538,-2.279626990394263,2.056170273051606,-0.02041647692726034,-0.11566283059500115,-0.544682057136658,-0.8894210621811651,-1.2393475747390514,-0.03103189849447552,False,c2,1,"The e-mail to the oversighter ""Articlefeedbackv5-email-request-oversight-body"" contains $4 with a link to the AFT-Oversight FAQ. The content on dewiki is:
//de.wikipedia.org/wiki/Wikipedia:Artikel-Feedback/Umgang_mit_Feedback
That means, ""http:"" is missing.
--------------------------
**Version**: master
**Severity**: normal",44901,-38,Low,True
2.038889522003988,2.0180628300755004,3.942856743975451,0.16250901208535184,-1.605582367475707,-0.8297231968556129,-1.9986781699481844,-3.6822663994151172,-0.028356199157758333,1.4999352592578248,-1.8941135216770038,-2.3065864298639553,0.7899203738146148,0.4572491756527386,-0.14023347774617,-1.2170501625994015,-0.3083276800368391,-1.0205032085942491,False,c2,1,"Since my hosting provider upgraded to php 5.3.19 a template on my wiki fails with '/includes/HttpFunctions.php(68): CurlHttpRequest->execute()' as the top line of the backtrace.
--------------------------
**Version**: 1.20.x
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44135
https://bugzilla.wikimedia.org/show_bug.cgi?id=42468
https://bugzilla.wikimedia.org/show_bug.cgi?id=70262",44441,-40,Low,True
-2.123052379674374,4.033722921128092,-0.9391896464497886,0.46847065641254915,-2.0688198116378187,3.4895846247731885,1.687685759897521,0.7083477189170811,-2.783871414271321,2.0462427491822064,-0.5893174740913825,-2.248191838320429,0.1466383115822465,-1.460130850188908,1.9494158563978559,-0.16590953053745006,2.6404719950716196,-0.9831698799096785,False,c2,1,"So, we had the following incident a few moments ago:
An Apache on the fleet was misconfigured, with wrong permissions in at least /wmf-config/.
Random bits hits for some CSS (e.g. for it.wp) ended up on this Apache, which returned a page full of CSS comments with DBConnectionError ('DB connection error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) (localhost)' in /usr/local/apache/common-local/php-1.21wmf3/includes/db/Database.php:797), since no configuration, database or otherwise, was readable or defined.
The problem is that this CSS full of exceptions and no actual content was returned with a 200 status code and subsequently cached in Squid and Varnish. Fortunately the TTL for those is short, and the site recovered quickly.
Could you please adjust it so that 500s are raised on such cases?
--------------------------
**Version**: unspecified
**Severity**: enhancement",44166,-41,Low,True
8.794223897213838,-11.259257022633012,9.090960624216542,3.875030537082753,-2.547515881861302,-1.0957988598130046,1.5309881355825823,-2.0850444042740226,-0.2701223660154009,-1.3327173380378698,-1.0270831400352698,-0.5517345516139086,1.9188043387985303,1.9850888177294035,1.9299268090242618,-0.5853894579453938,0.5127526002518485,0.16981902148964179,False,c2,1,"From bug 34788 comment #8:
> On a related note, if you go to .com addresses (like https://en.wikipedia.com/)
> using HTTPS protocol, before you get forwarded to the .org address, you will
> get an error message regarding the SSL key. That is because the .com addresses
> use the SSL key that is for *.wikipedia.org
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.com",42998,-46,Low,False
0.5914072451179271,-2.035926453645528,-2.3171328868973102,3.9255548898578683,-2.6373972093478915,0.10925353144140626,-2.076536110991975,-0.2801313458635215,-1.4562236209392312,0.691692897796476,-3.400360028245228,-0.33839100503465613,0.6002925312457243,-1.1311296519181457,-1.3744809091327648,-0.8972604385595131,1.4546329243150955,-1.424119831924883,False,c2,1,"**Author:** `jacoblesser`
**Description:**
The link to the Asirra clientscript is hardcoded as http://. This causes mixed content warnings in internet explorer when viewed over a secure https:// connection and the CAPTCHA does not display. This can be fixed by modifying line 8 of Asirra.class.php from this:
public $asirra_clientscript = 'http://challenge.asirra.com/js/AsirraClientSide.js';
to this:
public $asirra_clientscript = '//challenge.asirra.com/js/AsirraClientSide.js';
--------------------------
**Version**: master
**Severity**: minor",42631,-48,Low,True
-0.35203048429025907,6.1430105376782365,-0.7382077035459922,-9.848007919414348,3.029820883390966,-1.7881323434513177,2.921229855947243,-4.347100587633424,-1.4604147221991717,-1.969942220563138,0.23904285083758747,-7.87299610336331,-0.4500728059479302,-6.364160524929753,6.024728624756304,-0.7625361010179479,3.3258242338158306,-1.587833410265819,False,c2,1,"I was logged into all the main wikis, and when I visited wikimania2012.wikimedia.org I was not logged in, so I logged in using my unified account. However, I was simultaneously logged out of all the other sites including Meta and Wikipedia. When I logged back in to those wikis the login to the wikimania2012 wiki stayed.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",42036,-51,Low,True
-1.2240923093830376,0.6016129225891831,0.1743181912486591,-4.695457297494666,5.127702148333967,-0.46801067630695947,1.7445277104407166,-3.985177142648535,-1.1665527165389136,-0.8649808786609268,0.8164275819246494,1.7074777469470501,0.3931836172127672,-0.695289179893992,-0.6827912735849688,0.7108449869950486,2.0565497382858586,-0.7362521030144022,False,c2,1,"**Author:** `jack.sns`
**Description:**
The email I received from Chinese Wikipedia. All the link are http, not https.
Sometimes Wiki project send some E-mail to users and some of them have links, some links are https but some of them are not. For example, the Chinese Wikipedia send email to me about some article change but the link in the mail are all http. I usually https and when I click the link, I will log out. In addition, it's not safe. I think all the links should be https to make the connection safer. I hope someone can solve this problem. Thanks!
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F10209}",41676,-53,Low,
1.832512589320641,-5.850736665362861,-2.542318573826199,1.0408492595502112,-1.8941368477320435,-4.11851778166596,0.9871313996927249,2.7445624082284206,-0.7178533170070182,1.3421674071241432,-1.3598791952382911,-2.021095419491955,1.6195770196540415,-0.19697226745675334,0.18428597943635516,-0.8640022367308842,1.148049379487657,-0.4173628691595179,False,c2,1,"CentralAuth correctly autocreated and attached some local accounts (see 2012-08-05 20:44 entries on URL) but now I can't login to some of them, specifically map-bms.wiki, mwl.wiki, wo.wikt. Local password reset fails, apparently with 'noemail' error, but Special:MergeAccount is happy.
For folklore: «Bii baatujàll baaxul. Jéemaatal.» «Ora ana alamat imel sing kecathet kanggo panganggo ""Nemo bis"".»
Maybe incomplete attachment (??) due to race conditions? Compare bug 29234 where local account wasn't attached at all.
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://toolserver.org/~pathoschild/stalktoy/?target=Nemo_bis",41060,-56,Low,False
0.5636184113589748,-4.702410010692875,-2.7897823883579953,-4.940286227842029,3.0298459312285173,-0.23222375816150387,-0.5169500713801432,-0.44003668230012416,2.8457946282261206,3.929503868590123,-1.0771850867443267,1.3649589175990402,-0.9219346779521542,-0.3790433581151973,1.7548070813891625,1.555239982190096,1.1527410717901418,-0.13196387814917498,True,c2,1,"Though pauswikimediawiki is 'somewhat' dead, it should either be renamed or we should find a solution to the SSL cert failure.
--------------------------
**Version**: unspecified
**Severity**: trivial
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58024",40763,-57,Low,True
-3.862685897001584,-8.355260141039384,-4.152656299751152,-2.6943689982029015,2.905195836043576,2.7080424670630867,1.9351993876543006,-1.6470225916665902,1.9290341612151922,-1.277738091354454,-0.9997408218690809,-0.635745013277209,-1.6701751708250887,1.1672876489420085,-0.6530237190298243,-0.9345894122604663,-0.7935152118314731,1.1019369130484755,False,c2,1,"According to documentation execute() should return a value, which it does not.
--------------------------
**Version**: unspecified
**Severity**: normal",39713,-63,Low,False
-3.8949756008844982,2.4124687332209227,-1.7178718499372856,0.7214962883628744,5.388022902387592,6.439966131010388,-0.5118855422033688,-0.24562886162360714,1.1035819852497348,-2.37127328084607,-2.5220379356368934,5.816511186580424,-1.5468059571236497,-0.15165644597039396,1.7109997834845183,-1.9826406892044228,0.528756296774419,0.446270249584771,False,c2,1,"The Visual Editor is writting problems to that url, but does not use https, so that is a unsafe operation, which should be avoid, because it is a secure hole.
This should be a blocker for the coming roll out. Thanks.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",49507,-19,Lowest,True
-5.811671729739265,-9.192630996064718,-0.8651535284180198,6.7647936938808195,-3.3638108372669966,-6.3062213598314525,0.12171900578564365,1.6555563387823664,6.782891593765729,4.205169179595902,-4.226228316547969,4.073696775817371,-3.2477332681850495,3.0451374054404914,0.20412004343613432,-1.040362944854468,0.2844336005037824,-0.29854425213387636,False,c2,1,"add new default user right: login
user only can login to account who have 'login' right.
--------------------------
**Version**: 1.21.x
**Severity**: enhancement",48057,-24,Lowest,False
21.867510052823892,-2.066205414687582,0.24221136220358375,2.5543063703044706,-0.25968115673642417,-1.0572686142728314,-0.8273676677757917,-0.19973779316854645,-0.3495491660416657,0.1900977708089675,-0.2575097826720909,0.3529155666379462,1.4152320984194415,-0.3739625005337315,-0.3880376401647361,-0.3108683494925577,-0.695341511961128,-0.7477615635085046,False,c2,1,"**Author:** `M8R-udfkkf`
**Description:**
When logging in via the commons API https://commons.wikimedia.org/w/api.php with an IE user agent, the response says ""Connection: close"" even if ""Connection: Keep-Alive"" is set in the request. This behavior is not seen if the user-agent is set to Firefox.
Steps to replicate:
**IE user agent request**
POST https://commons.wikimedia.org/w/api.php HTTP/1.1
Accept: */*
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Host: commons.wikimedia.org
Content-Length: 51
Connection: Keep-Alive
Cache-Control: no-cache
format=xml&action=login&lgname=user&lgpassword=pass
**IE user agent response**
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Thu, 15 Nov 2012 01:10:11 GMT
Content-Type: text/xml; charset=utf-8
Connection: close
X-Content-Type-Options: nosniff
Cache-Control: private
Set-Cookie: commonswiki_session=<removed>; path=/; secure; HttpOnly
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Content-Length: 173
X-Cache: MISS from cp1003.eqiad.wmnet
X-Cache-Lookup: MISS from cp1003.eqiad.wmnet:3128
X-Cache: MISS from cp1011.eqiad.wmnet
X-Cache-Lookup: MISS from cp1011.eqiad.wmnet:80
<?xml version=""1.0""?><api><login result=""NeedToken"" token=""<removed>"" cookieprefix=""commonswiki"" sessionid=""<removed>"" /></api>
--------------------------------------------------------------------
**Firefox user agent request**
POST https://commons.wikimedia.org/w/api.php HTTP/1.1
Accept: */*
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Host: commons.wikimedia.org
Content-Length: 51
Connection: Keep-Alive
Cache-Control: no-cache
format=xml&action=login&lgname=user&lgpassword=pass
**Firefox user agent response**
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Thu, 15 Nov 2012 01:14:11 GMT
Content-Type: text/xml; charset=utf-8
Connection: keep-alive
X-Content-Type-Options: nosniff
Cache-Control: private
Set-Cookie: commonswiki_session=<removed>; path=/; secure; HttpOnly
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Content-Length: 173
X-Cache: MISS from cp1003.eqiad.wmnet
X-Cache-Lookup: MISS from cp1003.eqiad.wmnet:3128
X-Cache: MISS from cp1010.eqiad.wmnet
X-Cache-Lookup: MISS from cp1010.eqiad.wmnet:80
<?xml version=""1.0""?><api><login result=""NeedToken"" token=""<removed>"" cookieprefix=""commonswiki"" sessionid=""<removed>"" /></api>
Could this be related to:
http://blogs.msdn.com/b/ieinternals/archive/2011/03/26/https-and-connection-close-is-your-apache-modssl-server-configuration-set-to-slow.aspx
--------------------------
**Version**: unspecified
**Severity**: minor
**Whiteboard**: aklapper-moreinfo",44129,-41,Lowest,True
-2.8528644673157006,-1.8403993830455576,-3.042805539421609,-1.0653802114877782,3.9384302067621086,0.9936168851254801,-0.4759654877309112,3.302531366615749,0.8712528243913185,-2.978902580284596,-2.482188056144975,-1.1560410402455523,-0.33758555674393786,1.0666314133768218,0.8469647704764158,-0.6061106866175989,1.1176325259041666,0.5471348775736085,False,c2,1,"Bug 40714 was invalid, but I think this is a valid request although a low priority one: if the browser doesn't allow to load unsecure resources, the GeoIP lookup to freegeoip.net should be skipped or anyway the behaviour should degrade gracefully (or more gracefully than it currently does).
Of course chasing browsers is not an option but maybe someone will come up with a smart solution. The linked thread mentions HTTP 304 Not Modified responses which might give some some clue to ULS maybe?
--------------------------
**Version**: master
**Severity**: enhancement
**URL**: https://translatewiki.net/wiki/Thread:Support/HTTP_request_on_HTTPS_translatewiki.net",42965,-46,Lowest,True
-0.9929604341017209,-3.0376253055288007,-3.5927840979052306,0.8052809991091392,-0.3396809029514676,-2.2647487833772955,0.01028762686920981,-0.27680952208871046,1.5130956341076753,-2.7864321425847693,-2.528088473113668,-0.7357010277178778,-0.18060871933623268,-1.0726982651672219,-2.138723096572502,-0.19593256396770398,0.6711646317948976,1.1354873248378576,False,c2,1,"**Author:** `swalling`
**Description:**
View of login page while browsing via en.m.wikipedia.org
Currently, you can visit the login page (Special:UserLogin) via en.m.wiki... and MobileFrontend will re-skin the page. However, submitting credentials simply reloads the page.
I understand that there are some blockers around doing mobile logins and registration, but we should probably just serve the desktop view of that page until mobile fully supports login/signup.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F9903}",42318,-50,Lowest,True
0.263943406024139,3.2924088222485572,3.2493060834042353,-2.800460881462314,1.15000197343236,0.8001631986825293,0.4446606788378036,-2.381151775096921,0.4805733308977834,-0.6408929280666733,0.715840270180832,1.598643613442755,1.215652529455336,-0.41499024389661443,-0.30433003646079637,-0.45150744791272124,1.7147797624481715,0.872939576974521,False,c2,1,"Go to:
https://en.planet.wikimedia.org
https://zh.planet.wikimedia.org
After clearing the SSL warning screen (this appears to be bug 31335 ), I am taken to a slightly dated official WMF blog page (it's the same for both languages). I expect the served content to match http://en.planet.wikimedia.org and http://zh.planet.wikimedia.org respectively, but served over HTTPS.
--------------------------
**Version**: unspecified
**Severity**: normal",34028,-96,Unbreak Now!,True
-6.6131692418676415,4.370495600055985,0.6099981112001451,-1.3820906521533531,-1.8393191234753639,-2.8656884680940857,0.7717369836481529,-1.8388105648325972,2.196023311382775,2.099067951177485,0.6255959508706908,-3.467971301858091,0.9243099484893267,-2.6696230862310277,0.6524090752897633,-0.5453863783584865,2.2440254654582743,-0.22671655641486876,False,c2,1,"While loading https://www.mediawiki.org/wiki/Special:Code/MediaWiki/91123 I found that some sort of ""mobile user survey"" banner displayed in the sitenotice area, and a mixed-content warning popped up in my browser indicating something was loaded over unencrypted HTTP.
I popped open Firebug to check the network panel to find the culprit and reloaded to populate it, but the banner disappeared and hasn't reappeared so can't confirm it just yet.
--------------------------
**Version**: unspecified
**Severity**: major",33446,-99,Unbreak Now!,True
2.2500398812323588,-4.92823877911108,-1.747947546413048,-3.7633783425990024,-3.325120520045236,5.003882468183224,3.212308067875205,-2.661096156039973,-0.9721171762192822,0.5363268374565147,0.5611987943240302,1.1126862712302168,-0.5381799339981912,1.2841529504473588,-2.0816879708070783,-0.12455048352988513,2.6336536729309366,0.2534637319377133,False,c2,1,"Please set
$wgUseCombinedLoginLink = false
for all WMF projects per discussion on
http://lists.wikimedia.org/pipermail/wikitech-l/2012-May/060842.html
I read no objections but strong acceptance.
--------------------------
**Version**: unspecified
**Severity**: normal",39211,-65,Needs Triage,True
5.697898584546515,-1.1653871714385193,-5.039001464429061,8.185662310584052,-2.733133637688187,-5.553343716834764,-1.9944633311931161,-0.795149364959815,-1.9077675504195493,5.928714778359623,-1.2754808585442197,-1.4299260501503035,0.1322210835677211,0.01741088638292343,1.7902957103304997,0.3463864562576657,-0.45021733424845833,-0.47726578506048223,False,c2,1,"With OATHAuth enabled on a wiki (ie labsconsole), it is not possible to login via the API. It is rejected with a wrong password (tried with add-labs-user as below, and also AutoWikiBrowser)
sumanah@formey:~$ sudo add-labs-user --wikiname=""Giovanni Luca Ciampaglia"" --mail=""glciampagl@gmail.com"" giovanni
Traceback (most recent call last):
File ""/usr/local/sbin/add-labs-user"", line 37, in <module>
main()
File ""/usr/local/sbin/add-labs-user"", line 34, in main
site.login(options.wikiname, passwd, domain=scriptconfig.domain)
File ""/usr/lib/pymodules/python2.6/mwclient/client.py"", line 341, in login
raise errors.LoginError(self, login['login'])
mwclient.errors.LoginError: (<Site object '('https', 'labsconsole.wikimedia.org')/w/'>, {u'result': u'WrongPluginPass'})
--------------------------
**Version**: unspecified
**Severity**: normal",39031,-67,Needs Triage,True
3.93893071316738,-5.452563607656915,3.2375552456161536,3.9178701038488084,-4.457959821296946,3.7258561382571846,7.02066600280055,0.7099248687942028,-1.147199756578604,4.183419331594685,4.362330348530291,-0.36205651509691517,0.8240060930681263,-0.34125130792501324,-0.3453653976668454,-0.32102990960679045,-0.11732961711341172,-0.8993633741327214,False,c2,1,"**Author:** `lambdav`
**Description:**
HTTPS Mobile version of non-wikipedia projects have bad certificates : the certificate is for *.wikipedia.org domain instead of project specific domain.
See the below mobile version of non-wikipedia projects:
* https://fr.m.wikibooks.org/wiki/Accueil
* https://fr.m.wiktionary.org/wiki/Wiktionnaire:Page_d’accueil
--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://fr.m.wikibooks.org/wiki/Accueil",39024,-67,Needs Triage,True
0.09315480238896923,-3.6825693897348657,5.061825167665667,0.29576047576335496,-12.388374872287482,4.901625391306603,4.2235063851715955,-1.2253052545200929,1.6432321262208742,0.3118565785268803,-2.109599948889625,-1.1058313616204998,-3.2746523403785943,1.63640677655515,0.9879251922760286,0.7618433182575195,1.8489675940862897,1.161189712075281,False,c2,1,"**Author:** `tiger197`
**Description:**
Native option for automatic redirection from http to https.
In other words, merge http://fs.fsinf.at/wiki/SecurePages extension into source code. Plus add relative options to preferences.
--------------------------
**Version**: unspecified
**Severity**: enhancement",38456,-69,Needs Triage,True
-4.427029224546945,-6.492608711569868,-4.449804851426473,0.24518878585371717,0.07462964095761027,-2.5651995363702476,-3.0904583169680007,0.6529079859373286,1.8371138663075788,3.900231723753329,-1.0177533959129303,1.197863135930411,0.31928996110143437,-1.052891406714628,-1.2427581063500721,-1.5233264183952684,1.4571318735579266,0.05848402200145997,False,c2,1,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing.
Replacing lines like
} elseif ( $this->method == 'POST' ) {
with
} elseif ( strtoupper( $this->method ) == 'POST' ) {
should do the trick and be more developer friendly.
Fix forthcoming.
--------------------------
**Version**: unspecified
**Severity**: normal",38137,-71,Needs Triage,True
9.084650122666437,-6.011755695114484,-2.574633364989948,0.5290543326250239,-4.543496300087827,3.019904692438492,3.548278547789864,-0.49748885331212656,-1.3723076180594904,0.32136861239339165,-0.09913564386215867,0.9229837026752248,0.03591332215469478,-1.7564814442592973,-0.6256440477956371,-1.374537816559211,0.7103459957512628,2.5629721316440417,False,c2,1,"**Author:** `shealen.clare`
**Description:**
CA for en.m.wiktionary is different from CA for en.m.wikipedia, but mobile frontend servers using wikipedia's CA, breaking security.
--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: other",37096,-77,Needs Triage,True
-4.134662209516655,0.17377248562598702,-2.811883744356731,2.159343404685473,1.1654881514923126,-2.91543926780741,-0.003026079957566985,-3.331188145201948,1.1665762068731274,-2.0225955530776347,-0.7345370414652379,0.2182559551602472,0.9719833345237032,-1.3323280453233628,-1.3157199307443355,1.584862786661959,1.2148901249930162,0.669101129733727,False,c2,1,"**Author:** `startrekcafe`
**Description:**
Hi. i try to reset my password in wicamideia. but not liking my user name of StarTrekCafe. says that there is no user, but in the login system. i am a blind website design student and using jaws for windows. tried to use the mpa it program with the map of australia for the web html challenge, but says the image a .png is not decroded or decrypted. tried to upload as a svg, but i cannot login. can you help.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC",36722,-79,Needs Triage,True
-1.3467082222949562,3.419196421283768,0.6362670306112861,-7.931111133576227,-0.8288951541696074,-4.635127540461054,2.131862375019785,-3.3846209756350505,0.439718362568999,0.9229436545166347,2.7820548660425968,-0.3275907286948423,1.4240359212899056,-2.9373232829970175,2.5453854035515766,-1.947339903940684,2.903106792679484,-1.8224604218718434,False,c2,1,"**Author:** `kontakt-bugzilla-wikimedia-org-22.07.2011`
**Description:**
First of all, I'm steward and my SUL is active for years. At the moment it is active in more than 400 wmf projects.
Today I went to some page on ru.wikibooks.org and uz.wikiquote.org (Special:RenameUser to be precise). Usually I only need to change the settings to my language when I enter a new site where I haven't been before. But this time something went wrong.
I was told, that I'm not allowed to call this page, then I mentioned I wasn't logged in. So I tried to login, but I was told, that my password was wrong. On ru.wikibooks.org I was able to request a temporary password, and I was also able to merge this account into my SUL.
But on uz.wikiquote.org I was told, that there is no email address attached to this account thus I'm not able to merge this account into my SUL.
Two requests:
1. Please try to find out what went wrong (server problem? database problem?)
2. Please add my bugzilla address to this local account that I'm able to get a temporary password.
Regards
Andy aka. axpde
--
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=34512",36381,-81,Needs Triage,True
4.591228844148548,-3.317475392094696,5.3335050631058145,-0.592074923042357,3.0604631394105213,-2.5330555120007547,-0.6354308199651459,-4.295808342174152,0.7749954930425027,-1.9436567663712427,-0.8434192861582321,-0.8740194802037294,1.3505668993929225,-1.0385437770371335,0.6384565983428825,-1.4931723529412544,0.96542190555051,-0.7478178394119626,False,c2,1,"**Author:** `qbphcqdw`
**Description:**
While I was translating a page on wikimania2012.wikimedia.org into Korean, I encountered this error: I couldn't save text including the protocol https. Please review the error.
Here is one of the urls:
http://wikimania2012.wikimedia.org/w/index.php?title=Special:Translate&group=page-Scholarships&task=view&language=ko
Thank you.
--------------------------
**Version**: unspecified
**Severity**: trivial
**OS**: Windows 7
**Platform**: PC",36197,-82,Needs Triage,True
-2.03084865388989,-0.15125802088311602,2.9732412276874314,0.7375052356909071,-0.6408669316429376,-0.25278422391396793,0.5640484663635021,-1.6987114890155426,-0.03530608037666383,-1.841346262886903,-4.547316042176076,2.9107168399917267,-2.373388726584537,-0.17270014436845127,2.8611886438751535,-0.6212652335551213,0.5773282589777893,3.189028419422006,False,c2,1,"There are a lot of http links to mail.wiki[pm]edia.org, where mailman and pipermail are located.
I use the HTTPS Everywhere, and it was trying to force https instead of http, and reporting ""Connection refused"" errors.
One solution is to add an exclusion to the ruleset. eww
https://gitweb.torproject.org/https-everywhere.git/blob_plain/HEAD:/src/chrome/content/rules/Wikipedia.xml
Another solution is to add https support.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://lists.wikimedia.org/",35897,-84,Needs Triage,True
2.5205159419726226,0.6430100485692645,-2.005100925060562,0.45225278901600174,0.9931503961060388,1.8223819637544658,-2.4890417675424277,-2.3172942668586995,0.34149490420694495,-1.3302879129663747,-0.6473795491846301,-2.74658068460203,1.5086808484516347,-0.6517631765138807,-1.1013956691432396,0.2364983719531598,-2.206150607090307,-0.11374778615668313,False,c2,1,"**Author:** `it_is_me_here`
**Description:**
On the English Wikipedia, at least, if you type something like ""[//en.wikipedia.org/w/index.php?title=Main_Page&oldid=464887589]"" and are yourself browsing the site through https://en.wikipedia.org, then the external link will show up with a normal EL symbol (a square with an arrow leaving it), rather than with an HTTPS EL symbol (a padlock), even though the link will direct you to an HTTPS URL.
--------------------------
**Version**: 1.18.x
**Severity**: minor
**OS**: Windows 7
**Platform**: PC",35269,-89,Needs Triage,True
5.330370065950371,-0.9730350361993558,0.21284034096091986,-0.890061414539079,-1.4943670614936773,4.974969602119762,0.467896825841402,-2.722991948674514,4.799717841675098,0.20327283953514552,-0.9876855163115779,0.6753565790956388,-1.6072798213533224,0.0207013059498502,1.8133860730376492,-1.2423886321641826,1.9311698754317173,1.4086659328644375,False,c2,1,"**Author:** `todd_taft`
**Description:**
I'd like to be able to connect to a (remote) MySQL server using SSL connections between the web server and the MySQL server.
--------------------------
**Version**: unspecified
**Severity**: enhancement",34774,-91,Needs Triage,True
1.7847487141255427,-3.7096171825853723,3.593674468788521,-0.34933281698393825,1.2632165670364084,-1.3026738247478564,1.3209797991216181,-3.857510774654643,-0.6805419140757898,0.48910479694816633,-0.3674085028194094,2.475020973951281,0.6597500802995118,1.2238409223593356,-0.21223946032622898,0.16459345851928667,-0.5373650516281622,-0.5678541033424733,False,c2,1,"At https://donate.wikimedia.org/wiki/Special:FundraiserLandingPage?uselang=en&country=IN&template=Lp-layout-default&appeal-template=Appeal-template-default&appeal=Appeal-default&form-template=Form-template-default&form-countryspecific=Form-countryspecific-variable1&utm_medium=sitenotice&utm_source=B11_Donate_Jimmy2_AvsB&utm_campaign=C11_1114_AvsB_IN seen on bug 32484, my Firefox 8 shows:
""Security Warning
You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party.""
Offending file is:
http://upload.wikimedia.org/wikipedia/donate/e/e3/BPAY_Landscape_MONO.gif
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://donate.wikimedia.org/wiki/Special:FundraiserLandingPage?uselang=en&country=IN&template=Lp-layout-default&appeal-template=Appeal-template-default&appeal=Appeal-default&form-template=Form-template-default&form-countryspecific=Form-countryspecific-variable1&utm_medium=sitenotice&utm_source=B11_Donate_Jimmy2_AvsB&utm_campaign=C11_1114_AvsB_IN",34522,-93,Needs Triage,True
-3.0293965568094983,-2.8871385297487464,-7.025622750303391,-1.9748158966826415,-0.29173782926928465,-1.3921913303413738,-3.217749235681995,-0.16795146870167776,0.5032296442231076,-1.5404282444648763,-2.9645135175715063,0.958071263757329,0.5793045808065895,-0.47680642570069764,-1.241088034950173,0.4017308086627196,-0.9443030522418915,-0.9554522745761853,False,c2,1,"**Author:** `raphael.droz`
**Description:**
If
* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),
* and you don't have curl (should I ?)
=> then you're getting failures because wfIniGetBool() is not yet defined
There should be a way to require(GlobalFunctions.php) in such a case.
HTTP component set to ""redirect"", feel free to change this.
--------------------------
**Version**: 1.20.x
**Severity**: minor",34477,-93,Needs Triage,True
-4.703913399141619,-4.047600537374095,6.518206066249807,6.835551708026962,3.733502818976756,-0.8390391641219813,3.4117098359605604,1.9429228867464157,0.6020435412339643,0.09464516669835543,0.5884107432103352,2.524293139797349,0.12100165893397108,0.099245789020733,-1.9107438062996263,-0.8373501735777367,1.6932198277039985,0.17954567816399014,False,c2,1,"The page https://lists.wikimedia.org/mailman/listinfo/wikibugs-l loads the bugzilla logo over http, not over https.
Please change this and check all other mail lists, which are using logos.
Maybe use protocol relative urls
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",34396,-94,Needs Triage,True
-0.8233705738618919,2.9543524435516098,-0.9431970383271064,-0.11102538822846864,-1.7038464287827966,-1.157098546013291,-1.643999441299374,-1.5572907011205537,-1.4820808974021868,-2.6089213248055927,-0.6188353326691591,0.8267190933381403,0.08838674610994612,-0.4581256819975925,-1.1603964337974215,0.11673945595385277,-0.3844551743721991,-0.0960160937476453,False,c2,1,"Having FCKeditor installed, I get the following notice when I run the maintenance scripts:
Notice: Undefined index: HTTP_USER_AGENT in extensions\FCKeditor\fckeditor\fckeditor_php5.php on line 37
The file in question attempts to access $_SERVER['HTTP_USER_AGENT'] which is not set in command line mode.
People have already asked for a fix in CKEditor itself, however the CKEditor guys say they will not fix this issue. See http://dev.ckeditor.com/ticket/6279
I see no reason for FCKeditor to be loaded when running command line php scripts for mediawiki maintenance.
I propose to fix the issue in the MediaWiki extension by adding an early return, if we are in command line mode:
At the beginning of FCKeditor\FCKeditor.php:
<code>
// There is no reason for FCKeditor to run in commandline mode.
// Returning avoids breakage of scripts like dumpBackup.php.
if ( isset($wgCommandLineMode) && $wgCommandLineMode )
{
return; // Simply return from the include, so no FCKeditor code is run
}
</code>
I am running MediaWiki 1.17 and the according released version of FCKeditor.
--------------------------
**Version**: unspecified
**Severity**: normal",34322,-94,Needs Triage,True
-6.92318240382063,-1.58026424186167,5.707532218545687,7.899081253799908,-0.8470809217345114,3.1657473786924717,3.2009697192279747,-0.09412560445878745,-0.5230721971500382,4.272826433325463,0.1808987877965622,-0.28656469421539277,-1.0481326148498713,-0.2699368970268363,1.199047943176688,-2.842959792989629,-1.0525173397143401,0.36632986627542485,False,c2,1,"When accessing commons via https, the ""File usage on other wikis"" section on a file page uses http links to the other projects. These links should be https.
--------------------------
**Version**: unspecified
**Severity**: normal",34196,-95,Needs Triage,True
-1.2736403840085762,-5.139137553211771,-4.975778741284737,-8.807979252295713,-1.4781513581454284,-1.48054648679641,6.276093584561518,-3.3646873276503255,-1.5904310348477153,-1.0052810255277826,-1.6528036644796644,4.614777105191347,-3.4458675468271087,1.1195280647082475,1.9014681482907791,-1.4121368006327666,1.3547317949109405,2.7126288815786896,False,c2,1,"I am wondering whether it is by omission or purpose that http://noc.wikimedia.org/ does not have https:// available?
--------------------------
**Version**: unspecified
**Severity**: enhancement",34066,-96,Needs Triage,True
-7.463250261592128,0.9147661706228511,-2.5056350122562474,-1.864747303217887,-1.3394926996727041,-4.103955529393307,2.049813440335183,-4.130720089815806,-0.7022043964471116,-1.2743532842405805,0.12441810383327923,-1.503394525871468,0.8955716898014963,-2.341826911152302,-0.3727701962186547,-0.8236630640202685,0.11517182014219207,-0.09263014784012635,False,c2,1,"Since relative https URLs became possible a few days ago, i started using them for browsing Wikimedia projects. I intentionally logged out first and logged in again in https.
Now when i get notification emails about user talk page update or code review, they contain links to http. If i click them, i appear logged out, and this is fine, because i indeed logged out of the http site.
The email should link to https. If some users prefer http links, it can be a preference.
--------------------------
**Version**: unspecified
**Severity**: normal",33537,-99,Needs Triage,True
0.49308621879295345,-2.1985454935450655,0.37909011358847877,2.7037970409448295,-1.142296744000014,0.77508470156937,-0.7080191181204816,-0.7149576921325311,1.3837502920775118,-0.05757152903467855,2.4363097738945574,1.2230398509444933,0.7636686397577996,-1.3247986131975127,-1.8734042746911643,1.523005392448451,-0.6670446690433174,-0.4187368648419567,False,c2,1,"Since secure server has changed, neither {{SERVER}} nor {{SERVERNAME}} provide a way to do this check. See [[MediaWiki:Loginend]] as a case.
* {{SERVERPROTOCOL}} should return → http or → https
or, as an alternative proposal, it may be:
* {{SECURESERVER| Text if secure | Text if normal }}
--------------------------
**Version**: unspecified
**Severity**: normal",33531,-99,Needs Triage,True
-2.9609843723031006,-6.299911319302105,3.571914913397901,2.0119729255033163,-2.8184154795360072,-1.437900283856343,3.9511322030939118,3.3530015681063374,-2.8663911425697366,-1.6297416145762638,-2.280309555753221,-0.15771116167404253,-1.3160130683695348,-1.6329950173152503,0.7230622683928498,0.9089127442672766,0.3968381741090843,-1.424819039938076,False,c2,1,"These are still hardcoded to http. Switch'em to protocol-relative urls instead.
--------------------------
**Version**: unspecified
**Severity**: minor",33437,-99,Needs Triage,True
-10.547202783044298,8.960424202076194,-0.07046034118718225,0.9426401203412484,-0.5099704489923,0.4756181428814328,0.702745058906987,-3.1099035002436604,0.8055515374434914,-0.6553879305511323,-0.5200987066170004,0.9340340751129175,-0.051348975644409656,-0.4771702744756796,0.09504580283744968,-0.7392567948571434,-1.2195678682061748,1.7479192847709,False,c2,1,"Currently if a user is logging in on https page, when he's coming to Wikipedia by following a link on a 3rd website which points to http version, the page will be in unlogged in state. If he failed to realize this and edited page, his Wikipedia page browsing history and IP address may be leaked. If he realized this, he have to change http to https again and again (unless he's using a 3rd party browser extension).
There can be a resolution: when a user is logging in on https page, set a insecure cookie which says ""redirect me to https page"", and clear it when he's logging out. In this way, the only disadvantage I can see is one more request and the info for a possible attacker: there's a logged in user at this IP reading this page by following some link on this website.
--------------------------
**Version**: unspecified
**Severity**: enhancement",33432,-99,Needs Triage,True
-2.2925649814489106,-5.001947404420566,12.787091621027063,9.914893110609874,-9.314112018349118,-3.1760901871669276,4.773916143311534,-2.509430343605044,0.04655027812786644,-0.04064860567831108,-1.0983284651631409,-0.8538224542340871,-1.065567678458728,-1.0930908953057994,-0.6871117854253939,-2.104754390069089,0.3103389080574708,1.0654178161374988,False,c2,1,"Tracking ticket for https on mobile. Reference ticket on ops private tracker : http://rt.wikimedia.org/Ticket/Display.html?id=1662
--------------------------
**Version**: --
**Severity**: normal",33390,-99,Needs Triage,True
1.7089102887954106,-0.3075667904037882,4.912183322052684,8.095497250652583,-0.3021685022102401,3.8754866320783856,1.9776079747867952,-1.8200964974856264,-0.5363969580697494,2.0008003776015055,0.3501443379207081,-0.811205367997258,0.061825960597643004,0.21694016264439586,0.29284299259530755,-0.2305489376870431,-0.4541683081132246,-0.3408985307805217,False,c2,1,"**Author:** `M8R-udfkkf`
**Description:**
On the secure english wiki, enabling the gadget
(User:Pathoschild/Scripts/Regex menu framework) ""Add a sidebar menu of user-defined regex tools, with a dynamic form for instant one-use regex"" breaks the secure connection as the script is called from
http://meta.wikimedia.org/w/index.php?title=User:Pathoschild/Scripts/Regex_menu_framework.js&action=raw&ctype=text/javascript
--------------------------
**Version**: unspecified
**Severity**: normal",33375,-99,Needs Triage,True
-4.212113836904121,6.685042750919916,-0.8586191700845962,-7.437598116386896,-1.8777557575445145,-0.9907896100233461,-1.3320390055432245,-0.1699141376395966,-0.5014657505795721,-1.7413915164749176,-0.1906386020365467,-0.94888839654096,-0.04755289630792525,-1.6752176431403236,0.15411932553506613,0.5257607499508631,3.2221501101158125,0.18949376893249448,False,c2,1,"If I go to
https://www.mediawiki.org/w/index.php?title=Special:UserLogin
and mark the options
[x]Also log me in to other wikis of the Wikimedia Foundation
[x]Remember my login on this browser (for a maximum of 30 days)
I'll be logged in on https://www.mediawiki.org but NOT on http://www.mediawiki.org
If I go then to
http://www.mediawiki.org/w/index.php?title=Special:UserLogin
and log in using the same account, I'll be now logged on both http and https.
So far so good, but if I go to
https://www.mediawiki.org/w/index.php?title=Special:UserLogout
then what I would expect from the login proccess is to be logged out ONLY from https, but currently this is not the case and I'll be logged out from both http and https.
Could someone take a look into this?
--------------------------
**Version**: unspecified
**Severity**: normal",33355,-100,Needs Triage,True
-2.2977237780405884,-5.183479403976433,-1.8862162206445134,-2.218513830706689,-1.833330128488519,-3.8405375263798938,2.6404170539264245,-0.667641593700451,-2.855791528018112,-0.6049158780984518,0.29183282296361845,1.6713767020968275,1.571823785892576,-1.2978402949375138,-2.1166673869633197,-0.4327632035282747,-2.2537504662402155,-0.9957712610018407,False,c2,1,"Hi,
I think I've found a major issue in how CentralAuth handles https : when logging in with global login enabled, Special:UserLogin loads remote images from http://wikiwhatever/Special:AutoLogin?token=secrettoken (one image per project), while it should load them from http*s*://sameurl (when browsing using https, of course).
What happens is that cookies are sent unencrypted =/
I guess images should use protocol relative URLs as well.
Best regards,
--
Arkanosis@frwiki
--------------------------
**Version**: unspecified
**Severity**: major",33320,-100,Needs Triage,True
0.5362109861465063,3.9362060190835066,5.156634389051579,0.037406865105401366,-11.116409495830162,0.9635066037527726,3.885978412198905,2.058088766363706,-1.6948521661168283,0.14571759822528563,-1.4162237578637469,1.1811691317991568,-1.038214902611923,-0.3521173887725295,-0.7583125638755881,-0.5534822155851462,3.08550559576907,2.043314452646184,False,c2,0,"http://www.wikipedia.org/ and other portals do not have HTTPS version, and links on https://secure.wikimedia.org/ (which looks like http://www.wikimedia.org/) are pointing to English site of projects directly.
Portal pages of projects should be added to HTTPS site and pointed to by links on secure portal of Wikimedia.
--------------------------
**Version**: unspecified
**Severity**: enhancement",33278,-100,Needs Triage,True
-0.6459237537551239,1.4092944223153552,-1.0102360213320942,-1.3232069083521356,0.48588804877082503,1.0123016200522426,-1.5437579939920756,0.858881790089067,0.08387570523141447,-1.303845667781399,-1.0548141931434647,-0.8028316372825977,-0.2660228078893372,-0.8491698424255398,-0.11387408307731306,0.41165804338078704,-0.7489066386228072,-0.9064850039780077,False,c2,0,"The current reCAPTCHA module in ConfirmEdit does not support loading the CAPTCHA via HTTPS. This will cause ""insecure content loaded"" warnings when browsing on an HTTPS-enabled wiki.
To get support for this, two changes are needed:
* Update recaptchalib.php to the current version as provided by Google. The bundled version in ConfirmEdit still has the old host names, while Google uses google.com, especially for the HTTPS service. There are redirects in place, but they might cause certificate warnings.
* Use a HTTPS url when the wiki request itself was made via HTTPS as well.
I'll attach patches for both.
--------------------------
**Version**: unspecified
**Severity**: enhancement",33252,-100,Needs Triage,True
18.870506594013676,-0.7959003782525755,-3.605476127932368,-8.157436582844575,3.3366121631198413,-1.3179681954733176,1.728643744629001,-1.8244448499882275,-3.2823353387461367,-0.45606936858986646,0.45657838708754106,0.6127940598562722,1.1753206275854318,-1.3051243149053593,-0.5905425907211601,1.516616763510291,-0.4706059441228324,-1.1789489080874787,False,c2,0,"**Author:** `romaine.wiki`
**Description:**
When I am not logged in it shows (in Dutch): Niet aangemeld Overlegpagina IP-adres Bijdragen IP-adres
When I am logged in it shows: Romaine Overleg Voorkeuren Volglijst Bijdragen Afmelden
But the first page I see when I log in is: Romaine Overleg Voorkeuren Volglijst Bijdragen Afmelden Niet aangemeld Overlegpagina IP-adres Bijdragen IP-adres
And that last one isn't correct, it shows the top two lines together.
Greetings - Romaine
--------------------------
**Version**: unspecified
**Severity**: normal",33191,-101,Needs Triage,True
-2.7955575892630735,-3.947222046170422,0.29873975236734296,3.5787731940590186,5.482382380296702,0.8711343073827422,2.818311664516453,-2.8661087443638493,1.6550080821721223,-2.289188347991238,-2.378233475893829,1.7328830871126295,-3.205117189238355,2.590700504591795,-0.3041727617901371,0.124048926577949,-0.6779693569331592,-0.04850690411005876,False,c2,0,"**Author:** `olivier.beaton`
**Description:**
for any extension that uses Http::get a common task is setting the user-agent, which means they have to use the request object instead. Really $options should include the user-agent string
--------------------------
**Version**: unspecified
**Severity**: enhancement",33072,-101,Needs Triage,True
0.8463518818493792,-6.262760546950709,-3.6243755865248044,0.6936333314470402,1.5936359910873579,-1.564196001064215,-0.05898621895913614,0.33826598030681376,-0.23761713553267072,-2.7748541711265813,-1.0073931015226565,-0.9710760117600177,0.7989833760064298,-1.004516514791574,0.30759748412958565,-1.638817828735375,0.05861648434640343,-0.4578887665784783,False,c2,1,"$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git
fails with error:
RPC failed; result=22, HTTP code = 500
Related bugs and mailing list posts:
* https://code.google.com/p/gerrit/issues/detail?id=769
* http://www.gossamer-threads.com/lists/wiki/wikitech/278195
* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060
* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757
Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.
If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major.
Should your server's memory size be increased ?
--------------------------
**Version**: unspecified
**Severity**: major",37949,-72,High,True
-1.0112433650082737,-6.165542533122553,-5.5708688169628715,-10.635120571164315,6.710832515532932,-3.55881826514908,4.3333534316242615,0.2854805129278204,-3.5229832600836994,-2.6539057869906233,-1.2142818148946715,-3.1203089393280896,-1.3538745871432436,1.3763399884081258,1.826386300421075,3.5119315659325787,-1.2404145019451482,2.312084902943816,False,c2,1,"In all my attempts it always returns HTTP 500. However sometimes the moving action is done but sometimes it's not.
--------------------------
**Version**: unspecified
**Severity**: major",37030,-77,High,True
7.319821980104962,-13.06247394274509,8.758028814671533,5.982032035241267,-0.8803203413788933,-2.3928396724219834,2.692513185582164,-2.3928118967753162,1.1686869096379073,-1.048284191008614,-1.625528235874638,0.13529369943554048,-1.1324485203800991,-1.1472204901191314,-0.22127321559865099,-0.1073823597327595,0.014107802159560201,-0.33680055953882015,False,c2,1,"**Author:** `neil`
**Description:**
--------------------------
**Version**: unspecified
**Severity**: normal
**Platform**: PC
**URL**: http://en.wikibooks.org/w/index.php?title=A_General_Style_Guide_for_the_English_Language&diff=cur&oldid=2267115",36544,-80,High,True
5.243531555400834,1.5122307657268053,-1.0906788553636133,-0.373805846941882,-0.32741337687307054,-5.095732677072003,0.8882909533473118,-3.128366913024895,1.630983417087365,2.050498561336651,0.9183977443735563,0.23436910234611275,0.5006839217646664,-2.0127094245722468,0.48291685586158284,-0.23385903347833936,1.4767760662809717,0.38449759010512197,False,c2,1,"**Author:** `kontakt-bugzilla-wikimedia-org-22.07.2011`
**Description:**
It happened again, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34381 ...
I'm steward and my SUL is active in more than 400 wmf projects. Today I was renaming some user accounts via http://toolserver.org/~quentinv57/tools/global_renaming.ph - then I came to ru.wikiversity.org:
http://ru.wikiversity.org/w/index.php?title=Special:RenameUser&oldusername=Mietchen&newusername=Daniel+Mietchen&reason=see+[[meta%3ASteward_requests%2FUsername_changes%23Mietchen%40global]]
... and on top of the page I read ""Axpde Моя страница обсуждения Настройки Список наблюдения Мой вклад Завершение сеанса"", i.e. my account has been automatically created. But then it reads:
""Ошибка доступа
Перейти к: навигация, поиск
Запрошенное действие могут выполнять только участники из группы «Бюрократы».
Возврат к странице Заглавная страница.""
... i.e. permission error! And with the next click the top line vanished telling me to login first. But then I wasn't able to login. I tried to reset my password, but it reads:
""Для участника с именем Axpde электронный адрес указан не был.""
... which means something like ""no email address attached to that account"" (exact translation impossible 'cause translate.google.com went nuts :(
Same happened on zh-yue.wikipedia.org, ru.wikibooks.org (managed to get it working via reset password) and uz.wikiquote.org before (no email address to rest password, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34381 ...).
Please fix and please, tell me how can this happen for the second time this month?!?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=34381",36512,-80,High,True
-8.940924161049761,1.884092316194149,2.738857226889415,6.425516686729097,2.0569373141505127,-2.008944284194641,-1.099401535720017,4.1606948302977225,1.9401055525297275,1.0697362481350403,-2.9652721396746218,-1.5945043534905317,-0.19548172429549115,1.6388980289141495,0.16856766190892447,0.5505865294157969,2.5563400284153524,-1.0391686842338088,False,c2,1,"Since the fix for bug 33985, the spam blacklist will now block links for all protocols, not just http or https as documented. Is there any reason not to use the 'm' flag and anchor the regex?
--------------------------
**Version**: unspecified
**Severity**: normal",36179,-82,High,True
-3.335636261645762,-2.687776446141184,2.8132011009841484,5.705393372237605,0.9258085981816089,0.9024849805544151,-0.2448196797651523,0.592495539784986,-2.795192739261294,2.6600813235668888,-0.9295780005352596,2.3079738825797502,3.1413918054381305,1.8522099649854376,4.389017993944621,-1.0302877425939228,-0.876199313500033,0.8697175980898881,False,c2,1,"""Bad title"" page is served with an HTTP 200 ""OK"" response, should be 400 or maybe 403 or 404.
Blocks bug 33628 -- mobile client is unable to determine that this was an error case because the page comes back without an HTTP-level error indication.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.org/wiki/%23",35646,-86,High,True
-6.256235267472265,3.421968851199189,1.7509862035362715,-0.8739129137004811,3.3895683725394483,1.3643909439585833,0.6421571514597373,-7.158483653231776,-1.890944606077749,-2.655480325546582,-1.0993276499335773,-2.0213377609268908,-0.25678513649931745,-0.36397065446840227,-0.6354305804648082,-0.0009895809511293319,0.23205898588554974,3.3580352169446392,False,c2,1,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error:
Login error
You have not specified a valid username.
Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log.
--------------------------
**Version**: unspecified
**Severity**: blocker",35609,-86,High,True
-3.2857462875687418,3.128650307795194,-2.4109466067668066,-0.022990619474974494,-0.3812163607926495,1.5361512579421788,-0.8632080254386558,0.2206297200650576,-1.8446106292915054,-0.8005178374641306,-1.6967345655955386,-0.17389378126480826,0.8069266068245957,0.34166438972459723,-0.7062458163754579,0.8170493398053922,-1.7397312863519976,-1.9147674502345646,False,c2,1,"**Author:** `phil`
**Description:**
When visiting a private wiki, users are shown the message
'You must log in to view other pages'.
Because of the recent changes in 1.17.1 that hide page titles from users who don't have permission to see them, the log in link now has a returnto of Special:BadTitle.
The net result is that when a legitimate user logs in, they are taken to the Badtitle error page, rather than to the Mainpage.
--------------------------
**Version**: 1.17.x
**Severity**: major",34709,-92,High,True
27.743867571330707,-0.3597722141917874,3.712017138194735,0.1685715183107579,-1.901829629171013,0.12683806964040345,-0.4319588323707828,-0.27903171283643113,-1.676931269187351,0.12962309846134534,1.487565245953283,-1.1140905002647399,4.622103158842583,0.35656596768427384,0.20766756491559946,-0.8247036784174904,0.09421444780226618,-0.44811412332979494,False,c2,1,"While repeatedly fetching the URL
http://en.wikipedia.org/w/api.php?format=xml&action=query&list=categorymembers&cmtitle=Category:Candidates_for_speedy_deletion
with ""Accept-encoding: gzip"" set, occasionally (about 10% probability) I will receive a response that is uncompressed. I've received reports this also happens when using API login (see [[User talk:MER-C#Wiki.java...again]]).
Test code:
import java.io.*;
import java.net.*;
public class Blah
{
public static void main(String[] args) throws IOException
{
for (int i = 0; i < 25; i++)
{
URLConnection connection = new URL(""http://en.wikipedia.org/w/api.php?format=xml&action=query&list=categorymembers&cmtitle=Category:Candidates_for_speedy_deletion"").openConnection();
connection.setRequestProperty(""Accept-encoding"", ""gzip"");
connection.setRequestProperty(""User-Agent"", ""Test script"");
connection.connect();
System.out.println(connection.getHeaderFields());
}
}
}
This merely dumps the HTTP headers. Sample output:
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:51 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq38.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq38.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:52 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq64.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq64.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:52 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq64.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq64.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:54 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq65.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq65.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:57 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq64.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq64.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:57 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq74.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq74.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:58 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq60.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq60.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:58 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq37.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq37.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:48:59 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq66.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq66.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:00 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq65.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq65.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:00 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq66.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq66.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:02 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq77.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq77.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:04 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq37.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq37.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:05 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq39.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq39.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:06 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq40.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq40.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:06 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq62.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq62.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:07 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[759], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq72.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq72.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:07 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq75.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq75.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:08 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq72.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq72.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:09 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq66.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq66.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:11 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq72.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq72.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:13 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[759], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq60.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq60.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:14 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[759], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq60.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq60.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:14 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq62.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq62.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
{null=[HTTP/1.0 200 OK], Date=[Tue, 11 Oct 2011 08:49:15 GMT], Vary=[Accept-Encoding,X-Forwarded-Proto], Content-Length=[332], Content-Encoding=[gzip], Content-Type=[text/xml; charset=utf-8], X-Cache-Lookup=[MISS from sq73.wikimedia.org:80, MISS from sq34.wikimedia.org:3128], Connection=[keep-alive], Server=[Apache], X-Cache=[MISS from sq73.wikimedia.org, MISS from sq34.wikimedia.org], X-Content-Type-Options=[nosniff], Cache-Control=[private]}
This wasn't an issue prior to the 1.18 upgrade on Wikimedia.
--------------------------
**Version**: unspecified
**Severity**: normal",33603,-99,High,True
2.283044499370941,-10.721906579814547,5.640817684425539,-2.8120730986474607,1.0031562706517356,-0.4437700271216717,1.643650250423244,4.502285770602862,1.1508465978182558,-0.04913762894763263,0.04617272030651964,3.5337891704887863,0.8274419458829891,-2.755941550184001,1.4430484487253752,0.2385853644723166,0.6208696548342207,0.06182877347673821,False,c2,1,"https://mediawiki.org redirects to http://www.mediawiki.org/ currently. This is wrong and should be fixed.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68553",33369,-99,High,False
-2.667845868449803,-1.6364040281414987,4.302246209104183,-4.8505831341322825,0.5877738251076934,-0.7497648592023002,1.8738672428498617,-0.7510686091790888,-1.1395513491109774,0.2841374908698615,1.5911566021013424,5.123711238587227,1.3399421537535132,-0.1725053049564016,0.482886285738819,1.2401819537267729,-1.410518746464158,-0.14085540529198393,False,c2,0,"Visiting https://commons.wikimedia.org/x shows two problems:
* It says I am at http://commons.wikimedia.org/x , which is not true. This needs to be fixed to use the current protocol, as should the redirect
* It uses images from http://upload.wikimedia.org, should use protocol-relative instead.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://commons.wikimedia.org/x",32733,-104,High,True
2.5043201611865222,7.806186809639666,-0.7646690035655386,-2.9291290658905917,1.8283885602871948,-0.3987206197536155,-2.343905621997187,-3.1995866961051767,6.674245513008007,-0.895431290296413,-0.9762069240996301,-3.51834226882898,-0.46076148209877665,-1.0278508037786338,1.4501194527295844,-1.5448653432034993,3.248531123241185,-2.3473696590155204,False,c2,1,"I created an account for Dan-nl ( https://nl.wikipedia.org/w/index.php?title=Speciaal%3ALogboeken&type=newusers&user=Multichill&page=&year=&month=-1&tagfilter=&hide_patrol_log=1 ). The email didn't contain a link so Dan tried to login on the English Wikipedia with his temp password, but that didn't work. He had to go to the nlwp to get it working.
--------------------------
**Version**: master
**Severity**: normal",39240,-65,Medium,
13.035365085314936,-8.12814096691914,-1.5209438371262305,-1.9582006192028785,-0.1372387452468649,3.1584739413690768,-3.732960810295815,-0.5498862764937258,-2.435543260425862,-2.300215519194598,3.4674883711683804,-0.5114938551245688,-3.0902402311230937,-0.7698145044453097,-1.4838511998172121,0.8377035797991224,-0.35948949805266084,-0.5018691305604477,False,c2,1,"As the topic says:
* https://www.wikimediafoundation.org -> http://wikimediafoundation.org
* https://mediawiki.org -> http://www.mediawiki.org
* https://www.wikisource.org -> http://wikisource.org/
* ..
--------------------------
**Version**: unspecified
**Severity**: normal",38952,-67,Medium,False
-2.056333052971613,8.34951640373949,4.228316123892231,0.31008575525635496,-3.194192166531767,3.782996407123502,-0.7820553256027205,-1.830429480908403,6.402743183126533,-0.2466575874499357,0.07532847428257172,2.0738922763673475,-0.38394296939267836,-0.7574706039770671,2.469098218230921,-0.027752135937963607,-0.1355860615955755,2.122027805715751,False,c2,1,"It would be great to have access to the labs using HTTPS. Some tests might require us to have access to a wiki using both HTTP and HTTPS, login tests come to mind.
Following a discussion with ops, it would be possible to use a NGINX proxy as a frontend to split HTTP and HTTPS requests. HTTPS would be terminated on a second NGINX proxy just like in production.
--------------------------
**Version**: unspecified
**Severity**: enhancement",38648,-69,Medium,True
2.7310977501889906,-2.0331871006847972,1.9242595988711457,3.5949454039888487,-0.5358547388916333,0.24438522213750313,-3.162212804922571,-0.753342219830065,1.6949155386486863,-0.9863259785569496,0.22963160621311118,-0.5507427545853816,0.6552951698038938,-0.4612632122510263,-1.8510113066902245,-0.4021164892910859,0.007826365683548664,-0.8835410967248103,False,c2,1,"**Author:** `Thehelpfulonewiki`
**Description:**
Scrollbar problem
See the attached screenshot.
Steps to reproduce. I'm on a computer with Windows 7, IE9.
1) Go to the super secret page URL.
2) Scroll down until the end of the page.
3) Scroll back up to the top and the ""showing namespace..."" bar will continue up past the New Pages Feed title to cover the login, user page/talk page etc pages.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC
**Attached**: {F9225}",38628,-69,Medium,True
-3.2786673457998092,1.7378923799055457,-1.028143986533065,-2.0320663925225397,1.710630696235926,0.5424637260903131,-0.9066205843872579,-1.2906869272664294,-1.3497381423837649,-0.9498847410145053,-2.02987081665938,5.354047563414492,0.06370535155796819,-1.4205491922551121,-0.2806102691233274,-1.4100543088417652,0.09097802506509223,-0.8469973542228462,False,c2,1,"there is the text
""leaving a request on this page (MediaWiki.org) (this is recommended""
which links to
http://www.mediawiki.org/wiki/Developer_access...
Would someone be so kind to convert that to protocol neutral. I am told that it it is done by the interwiki map that labs uses and to post this bz.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68751",37826,-73,Medium,False
-0.7447970166056836,-2.5482231976734084,-4.629913168830122,1.9416400173866308,1.9149187652381858,-2.7433614465639238,-1.5478156009270574,0.041302555488889725,-2.4058895587557725,-2.354548044487131,3.216947749569631,-1.2685371040357767,-2.117996870640905,0.6668420530746939,-1.6592429417858559,1.0780313212859853,-0.12051358459092176,-0.6594234140566428,False,c2,1,"> @willow:~/externals$ git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git mediawiki/core
> Cloning into mediawiki/core...
> error: SSL certificate problem, verify that the CA cert is OK. Details:
> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing > https://gerrit.wikimedia.org/r/p/mediawiki/core.git/info/refs
>
> fatal: HTTP request failed
It seems Toolserver doesn't have all the local certs up to date and thus I'm unable to do an anonymous check out there.
[#mediawiki] <thedj> yeah i think the intermediate certificates are not in the chain sent by the server.
[#mediawiki] <thedj> Krinkle: en.wp has 3 certs listed in the cert chain when you use openssl. But gerrit.wm.org just the server cert.
--------------------------
**Version**: unspecified
**Severity**: normal",37709,-73,Medium,True
-6.3623394318064435,4.371227182180988,1.616885534305947,3.9393669636962976,1.277765163121451,-0.6967279820889825,-0.4725018915849484,-1.7905711302860365,-0.1353221126998204,-0.5608384606174637,-0.5855323138433772,0.5739643095366826,1.233589188981202,-0.24754798292836977,0.12353780808980996,-1.1896417997780462,-0.6953357240775059,-0.9147373226633968,False,c2,1,"Since a while I enabled a semi-automated reporting of a very heavily used script on WikimediCommons.
The user has the possibility to press a button to post the error message to a list of those.
Now, after about 1 month there are 4 reported (this means that this occurs much more often) errors:
API request returned code 200 parsererror. Error code is SyntaxError: JSON.parse: Parsed string contains more than single value: <!DOCTY...
or
API request returned code 200 parsererror. Error code is SyntaxError: JSON.parse: unexpected non-whitespace character after JSON data
This means that jQuery received a 200 response and tried to build a JS-object for the presumed json-string and that failed.
Since we are using ""secure techniques"" (js objects) to build the query string, and the format-parameter is always set to json by a wrapper-method (all requests are handled by doAPICall), this problem only occurs when editing, I think the problem is at the server side.
If you would like to be up-to-date with those issues, just watch https://secure.wikimedia.org/wikipedia/commons/wiki/MediaWiki_talk:AjaxQuickDelete.js/auto-errors for new entries with ""API request returned code"" (I could make a separate page for server errors, if you want or send them with JSONP to a health-status-server.
It's a page you can learn a lot from: E.g. ""API request failed (hookaborted): The modification you tried to make was aborted by an extension hook"" is a very bad error-message. User has to guess which hook of the the thousands.)
--------------------------
**Version**: 1.19
**Severity**: normal",37300,-76,Medium,False
-8.993203161710294,4.824304635893753,2.9584490897386218,1.8623996754019112,0.9801096921602794,1.6809966772520146,2.360409558543531,-0.347863085706944,-3.9691967380551496,-1.608757752137226,-1.1573253775840204,2.808559763733806,-0.11910363287355707,2.5426650123018426,0.3424615467584262,0.3263922405017161,-2.2478296886116356,-1.8568365075198607,False,c2,1,"At http://mediawiki.org/wiki/Extension_talk:$wgBlockDisablesLogin, it appears that an anonymous user has found a bug in the software. Apparently, while logins are disabled, read/write access is still granted to a user blocked with this setting set.
--------------------------
**Version**: 1.18.x
**Severity**: normal",37252,-76,Medium,True
-2.321386247612692,-3.226360693700082,4.589085324238564,-4.667610179662667,4.3778017262229945,-4.915378064446372,3.97169678962861,-7.16962119899296,-1.6691147702868019,-0.9609769398610726,1.1028241850571603,-2.9224225788071183,0.5270788222430212,2.162101019577218,0.3906808529092549,-0.7604495508961628,1.9532695266720588,0.4462002954263393,False,c2,1,"When I access https://en.wikipedia.org on my cellphone, the redirector sends me to http://en.m.wikipedia.org but not the https one.
--------------------------
**Version**: unspecified
**Severity**: normal",37215,-76,Medium,True
-2.3455805307723416,5.329416342306438,0.4791594966900554,-3.0627553875052227,-7.340368828571563,4.728088178988893,2.045852859129318,2.093154080836233,-2.6600802370001784,-2.1647211513126896,-4.46845495868113,2.909021675857642,-3.047516545122507,2.346916960718916,-0.8527809969166515,-2.11978452489897,1.948558411651448,-1.4462025903680185,False,c2,1,"There is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=30348",37199,-77,Medium,False
11.889224817448751,-2.5943858679218916,-0.7085807953554539,1.5129042502216432,0.5940957677531076,-1.4213165562219354,0.4164800617991711,2.387895120288707,-0.1928800153101088,-1.025920756373723,-0.3456524747495249,-0.8079993622229873,2.5751037299310573,-0.16413879274988474,-0.15068961230036493,-0.36069050666107605,-0.1955489465479192,-1.0485638157687358,False,c2,1,"The 404 page used to have a meta-refresh tag. Now it apparently has a Refresh HTTP header:
---
mzmcbride@gonzo:~$ curl -I ""http://en.wikipedia.org/wfhsdklfjsdklfj""
HTTP/1.0 404 Not Found
Date: Thu, 08 Mar 2012 04:23:19 GMT
Server: Apache
Cache-Control: s-maxage=2678400, max-age=2678400
X-Wikimedia-Debug: prot=http:// serv=en.wikipedia.org loc=/wfhsdklfjsdklfj
Refresh: 5; url=http://en.wikipedia.org/wiki/wfhsdklfjsdklfj
Content-Length: 5091
Content-Type: text/html; charset=utf-8
Age: 166
X-Cache: HIT from cp1019.eqiad.wmnet
X-Cache-Lookup: HIT from cp1019.eqiad.wmnet:3128
X-Cache: MISS from cp1008.eqiad.wmnet
X-Cache-Lookup: MISS from cp1008.eqiad.wmnet:80
Connection: close
---
Auto-refreshes/auto-redirects like this are generally considered terrible from an accessibility standpoint. This header should simply be removed.
This is kind of related to bug 17316, but not really.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54357",37052,-77,Medium,False
0.9166747082643494,-7.399738562124984,0.9646839845795405,-2.3511510300771237,3.1894791234736335,-0.3252462362891493,-0.47993733131900385,0.4775739917073889,3.5611898659974512,-0.045904490406573295,-0.38996750081872067,4.386618664820453,0.0835768017091425,0.17933257555111748,-1.6005478385552236,-0.8964053912751715,1.049400164101287,0.9340807180619819,False,c2,1,"Try visiting https://en.m.wiktionary.org/wiki/Wiktionary:Main_Page - you'll get warning that host does not match certificate. The cert is issued to Wikipedia.
--------------------------
**Version**: unspecified
**Severity**: normal",36788,-78,Medium,True
-2.4782279803142435,-0.49838050513585586,0.1965669581783871,5.405085838816573,-0.47962899231360656,-1.1442548747300678,-1.315361552260331,-1.3622232058618717,-0.388664373251632,-0.21462111736601397,-2.552477125142831,0.14874599176926018,0.5652362504762474,-0.44082179758933027,-1.655221847717518,-1.2420231146753207,-0.4343851245045407,1.0426189839421711,False,c2,1,"patch for changing from table layout to CSS layout
The login and registration forms are using tables for laying out the page. I propose the attached patch to change it to CSS. The patch also includes the usage of methods (i. e. Html::element()) for creating the form fields instead of embedded HTML. The patch also removes the default type attributes' value to make sure the CSS-selector for ""input type=text"" is working.
--------------------------
**Version**: 1.18.x
**Severity**: normal
**Attached**: {F9123}",36751,-79,Medium,True
-4.527751062644665,3.0156302430287276,-4.765185054890631,-0.18827781676250133,2.53992540168871,-1.2463184954876627,-0.8508126449949334,-2.3292499345704583,2.8439161471640624,1.3443536166551544,-0.02044614688635704,-0.037006091931048646,-0.0029354345565648643,-0.07955056638092195,0.2633188550183565,-0.23894285115763347,-0.08499855113237675,0.08394675973254073,False,c2,1,"Let's say we are browsing a 'foreign site'. To make it less foreign, we
must append ""uselang=en"" after each url right there in the URL bar of
our browser.
http://dev.baidu.com/wiki/map/index.php?title=%E7%89%B9%E6%AE%8A:%E7%89%B9%E6%AE%8A%E9%A1%B5%E9%9D%A2&uselang=en
Go ahead and now click on one of the juicy links displayed.
Note how frustrating it is that we are now back in their native language.
After a while this becomes frustrating, and we wish MediaWiki had a
""uselang=en&remember_uselang=1"" or some way to make the @#$! uselang
parameter stick.
Note there is no chance any such business sites would let a user login
to set a preference.
Compare all the effort put into providing translation strings, with this silly barrier to seeing them.
--------------------------
**Version**: 1.20.x
**Severity**: enhancement",36748,-79,Medium,True
-4.658256261871168,10.803993593059381,1.1011519773540677,-5.748612263933973,-4.437512061676992,-1.1773603890735542,1.7526017475437001,-2.1531318225136875,1.6984138897383703,2.166420127519771,3.178180402833435,1.8910234038486242,2.4534042256747837,-5.252059115604356,3.147958537828157,-1.8298048962087337,0.827043948832251,1.357710885680705,False,c2,1,"Per IRC, it was noted numerous sites were including arbitrary http files in CSS, JS and otherwise which isn't good.
If we can gather a list of offending wikis, we can look at trying to fix them up.
Visiting the main page on all wikis via HTTPS should be enough
",36670,-79,Medium,False
5.603860829138723,-1.8181848573501647,4.865908845301906,-2.6183355811891538,-2.6095138518069114,-2.838646176794189,3.3196577851458384,-2.0243216713432926,0.07543301116132484,0.7858462634964587,0.5855491990284443,0.8949935635782211,-0.2059492251281707,0.10057279041150746,-1.2845520185298795,0.06995050213874815,-1.4404229720494817,-0.743344112919089,False,c2,1,"**Author:** `it_is_me_here`
**Description:**
See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#HTTPS_issues. When browsing https://en.wikipedia.org on Google Chrome, the padlock is normally green (for HTTPS padlock colours, see https://support.google.com/chrome/bin/answer.py?hl=en&answer=95617), but if you'd enabled mwEmbed in your user preferences, it changes to red.
--------------------------
**Version**: unspecified
**Severity**: normal",36520,-80,Medium,True
-2.0702975713105802,-10.809385657090822,-4.472271879829744,-7.687729662315816,-1.6363994626072658,2.017279499174103,7.180251208904333,-1.7953509833567405,-3.6668088167202963,0.9841773289157132,0.9151879508043055,1.9829782197341206,-1.5646859392529144,0.6002469203469758,1.650210931590535,-1.1652082354015376,0.07977359778042259,0.5337500121905394,False,c2,1,"I often work with wireless, http is insecure.
--------------------------
**Version**: unspecified
**Severity**: enhancement",36367,-81,Medium,True
3.899837763467621,1.372318165788604,-2.411455727506336,0.5953964642571681,3.9178958077818575,0.2631431740380228,-0.4681002431806016,1.8137852210089216,1.5466193014968241,-1.0370164548064924,0.7667166499817948,-1.5996707976413211,0.45747572741415254,-0.9794312983997351,-1.9291767540021123,0.10261663705105747,-0.011836268353497825,-0.17863249251488433,False,c2,1,"I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also.
When users have requested a temporary password through Special:PasswortReset and
- come back to the wiki
- and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page.
Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment.
When doing a passwort reset (enter the temporary password and twice a different, new password) on
/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset
the Create Account/Login portlet has incorrectly
/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset
instead of
/index.php?title=Special:UserLogin&returnto=Main+Page
--------------------------
**Version**: 1.20.x
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57098",35997,-83,Medium,True
3.134533388689658,0.7508350733756455,2.9881141221949434,-0.12868062790562984,-4.819025661866737,1.8895767908169254,0.34036938428038166,-1.9168299217237017,-0.12436904080714858,-0.9721492106505334,1.5852570526132355,-0.4751481020309788,-1.0900410580849407,1.040281281398598,1.1252102328472562,-0.8986670525432552,1.7641063375305948,0.18112119619203537,False,c2,1,"Apache configuration for redirections ( redirects.conf ) always redirects user to the http:// scheme. Since we support SSL on most site, we should stick to whatever protocol was requested by the user.
Example of buggy redirection:
RewriteCond %{HTTP_HOST} mediawiki.org
RewriteRule ^/(.*)$ http://www.mediawiki.org/$1 [R=301,L]
Should either redirect to a relative URL ( //www.mediawiki.org ) or replace http with SERVER_PROTOCOL
--------------------------
**Version**: unspecified
**Severity**: normal",35751,-85,Medium,True
-3.32507528987753,3.0808518405045078,-1.8806757374572545,-1.2946008285341366,-0.4302704999882727,-1.002614457391833,-1.3780750515858236,-0.4520453669035117,2.0764395733753194,1.5427894398621769,-0.32573198941810944,-0.5299118698270113,0.847562168378281,0.2677086179764805,-1.9298461110250358,0.46717910841167376,-0.4848597526954781,-0.9745686965323437,False,c2,1,"Why can't MediaWiki do like all major sites' software, and allow setting
the interface language without requiring the user to establish an account?
Observe the bottom of e.g.,
http://www.facebook.com/
http://www.flickr.com/
http://www.youtube.com/
Each has a language selector that doesn't require login.
http://www.couchsurfing.org/
even puts it right at top.
Yes, patient users can set their language preference in Preferences.
But what about read-only sites? I.e., What should one suggest on
http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_creation
to say to users who wish to view in a different language?
Painfully suffix ""?uselang=..."" to the end of each URL they browse?
One might argue ""users will confuse MediaWiki uselang= with
XX.wikipedia.org languages"" ... well they haven't yet with the language
choice in Preferences.
I'm not saying rip it out of Preferences. I'm saying add an additional
way to set it for even non-logged in users, just like the aforementioned
""real websites"" do.
Also consider the current accessibility up until the point the user has
managed to register an account and finally set his/her language
preference... all of which has to be somehow accomplished in the ""dark""
of the default language, unless he/she knows to add the magic
uselang=... to MediaWiki URLs every step of the way.
Please don't suggest an add-on for such basic functionality.
--------------------------
**Version**: 1.20.x
**Severity**: enhancement
**Whiteboard**: UniversalLanguageSelector-fixed
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=20151
https://bugzilla.wikimedia.org/show_bug.cgi?id=56464",35677,-85,Medium,True
-2.373810617118078,1.4489941451054271,1.8722414270765313,-1.1803626125987572,2.706445281546878,0.3087291746904841,-0.9604283970025476,-1.6167395757040266,-1.5810075687225267,1.225419208145956,0.18257391214272545,-1.7027059329598446,1.266737071380001,0.3767541628464155,1.1964398300875665,0.30631040470387566,-1.3433669534071624,0.19970777640833748,False,c2,1,"**Author:** `pakseykin`
**Description:**
Setting ""$wgDebugRedirects = true"" in ""LocalSettings.php"" does not work as it described by the documentation:
http://www.mediawiki.org/wiki/Manual:$wgDebugRedirects
If redirected page is accessed using original URL, the redirect still happens automatically.
It is either (1) problem with the code or (2) lack of explanation in documentation.
STEPS TO REPRODUCE:
1. I have a MediaWiki instance installed into (similar) URL:
http://example.com/content/
2. I created a page which is directly accessible through:
http://example.com/content/index.php?title=Initial
3. Then I redirected (moved leaving a redirect) the page giving it new name:
http://example.com/content/index.php?title=Moved
4. Then I enabled (""$wgDebugRedirects = true;"" in LocalSettings.php) the feature to disable automatic redirects. According to the documentation, this should disable redirects and show new location instead.
4.1 EXPECTED RESULT:
In the example above, when I enter the first URL, the wiki engine should not show content of the page. It should simply show a some kind of auto-message with a link to the new ""Moved"" page.
4.2 OBSERVED RESULT:
When the first URL is used, the wiki engine still redirects the page showing its content. In other words, it behaves as if there were no changes to ""$wgDebugRedirects"" variable.
--------------------------
**Version**: 1.18.x
**Severity**: minor",35554,-86,Medium,True
5.0869801044526,-1.8596941477382387,-1.7970811547739292,-3.5264181587718317,1.1118499229832315,-4.23249181127371,1.5413369689267755,-0.29676924286844747,1.7458037825454278,-1.4909749658652909,-0.0008346801989600472,-0.2696703643167816,0.11945102289130105,-1.5770094708468263,-0.2860421776401658,-0.539325822510683,1.3832278117195578,2.84861199864359,False,c2,1,"**Author:** `free4spams`
**Description:**
No matter what login to use, it still request to enable cookie
I have hard time to login using IE6 (OS WinXP SP3), login page keep telling me to enable cookie, and I already enable cookie in IE6. I tried the configuration using WAMP.
I knew IE6 is so damn old already, but working under corporate and decentralize users hard to upgrade this old browser, and users also did not have any internet connection.
Is there any workaround or suggestion regarding this issue? I had no problem in using modern browser, ie chrome, firefox and opera.
My IE6 only using Google Chrome Frame installed as addon. Fiddler addon is later installed.
--------------------------
**Version**: 1.18.x
**Severity**: normal
**Attached**: {F8740}",35503,-86,Medium,False
-1.2525121822823797,-4.841565449962889,1.3255049312702312,5.281172519028584,0.28188150807982415,1.7597349811960632,0.936774605917706,-0.3127310886433714,-2.0370634596218387,-1.5819528271132168,0.5990032596935344,-0.40508131122444524,-0.030584635661284665,0.4260045528832368,0.170680593364529,-1.4310130813845574,-0.5534975332250055,0.6328308945982262,False,c2,1,"Split out from bug 29550:
integration.mediawiki.org uses an invalid security certificate.
The certificate is only valid for the following names:
*.wikimedia.org , wikimedia.org
(Error code: ssl_error_bad_cert_domain)
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://integration.mediawiki.org/testswarm/",35301,-88,Medium,True
2.4384804826646778,-9.778199242647672,-1.5491628788647738,1.4203874445301565,1.6763996997107977,-0.9397025036013498,-0.2960334324490077,-2.1866991550700825,-1.004690618977464,1.1234552763437762,-0.238919458163537,1.6168609147765365,1.7233499712841316,-1.8056458251449397,-1.3727170987673976,-0.6150127113999586,0.3516652950841992,-1.2825975985121874,False,c2,1,"**Author:** `thomas.kujawa`
**Description:**
Can anyone help me to fix the error ?
This is the error: http://www.familienfreund.de/wiki/Spezial:Interwiki
This are my versions: http://www.familienfreund.de/wiki/Spezial:Version
This is the part of my local settings:
# Erweiterung Interwiki
require_once(""extensions/Interwiki/Interwiki.php"");
$wgGroupPermissions['*']['interwiki'] = false;
$wgGroupPermissions['sysop']['interwiki'] = true;
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: other
**Platform**: Other
**URL**: http://www.familienfreund.de",35169,-89,Medium,True
-2.922171109423276,11.696456744935155,0.7200598965372826,-0.3225312561266025,6.512544292362321,3.2142914971830088,1.209245006838458,-3.017095711509613,-2.5905141379212226,1.2325965511032635,-0.29963975475248894,0.8923079073185509,-1.0615804972736047,-0.43502046656540116,1.4271003380158822,0.01385782287522297,-1.0115074952569438,1.445815050974878,False,c2,1,"Currently, status.wikimedia.org has no HTTPS at all. I suspect this was the ""workaround"" for it having an incorrect certificate in the past.
Previous description: status.wikimedia.org is using an security certificate from *.io.watchmouse.com which give a warning in IE and Chrome.
Is it possible to install a wikimedia certificate on that domain? Thanks.",34796,-91,Medium,False
1.9616432292568793,0.9864201165640001,0.14677987743371546,-1.3673101626552846,-0.8630702096737606,0.9944408389174904,-0.6526576975322458,0.26955581341746193,1.7126806373893435,0.07844185899886025,-0.49601142371746754,-0.15650109689833336,1.048416548752483,-1.0189288628691666,0.6814697155280802,0.053762724672213436,-0.41218163032544397,-0.5036941086243831,False,c2,1,"Just got a new message notification:
Dear Multichill,
The Wikipedia page ""User talk:Multichill"" has been changed on
2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking
on National Register of Historic Places in Lowell, Massachusetts */ link
fix
See
http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500
for all changes since your last visit. See
http://en.wikipedia.org/wiki/User_talk:Multichill for the current
revision.
To contact the editor, visit
http://en.wikipedia.org/wiki/User:Magicpiano
Note that additional changes to the page ""User talk:Multichill"" will not
result in any further notifications, until you have logged in and
visited the page.
Your friendly Wikipedia notification system
--
This email notification feature was enabled on English Wikipedia in May
2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you
would like to switch off your notifications, visit
http://en.wikipedia.org/wiki/Special:Preferences
Feedback and further assistance:
http://en.wikipedia.org/wiki/Help:Contents
(end)
All links should be https now we properly implemented ssl.
If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.
--------------------------
**Version**: unspecified
**Severity**: normal",34769,-91,Medium,False
-12.53397425314116,8.643604433120949,1.6423787417986055,3.573572688549695,-0.5751076510087819,6.807272011040138,2.386040724009267,-2.4357221033250376,0.3533732044653667,1.9467831406186908,3.542638659219023,-2.558287747116456,1.4873814768062572,-1.9317477718012102,1.339862345096571,-0.786315458369024,0.16669352155723782,0.09166359082671094,False,c2,1,"It would be nice if there was an easy way to go from http to the same page on the secure site, and the other way around. E.g. a footer link like the one we have for going to the page on the mobile site.
--------------------------
**Version**: unspecified
**Severity**: normal",34690,-92,Medium,True
3.3582773577937384,-5.125323745603032,8.333989921606548,4.5774325692550315,0.8051788458297722,-0.2027854309097361,-0.8872116151965619,-2.5560039999571442,-1.3692328515879304,-0.3999345009734716,7.2069130040008424,0.8962785541384208,-2.535540461140255,0.3625085339264791,2.0880395741301703,-1.2708043223719865,1.4410483272651262,-0.9410804398979962,False,c2,1,"The culprit is this cute bugzilla logo on the link to our Bugzilla:
[10:25:02.522] GET http://www.bugzilla.org/img/buggie.png [HTTP/1.1 200 OK 4ms]
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://svn.wikimedia.org/viewvc/mediawiki/trunk/",34550,-93,Medium,True
-1.9274844564828735,-6.451996998865247,5.394739394378803,2.9685862073748313,-3.9191571971180363,0.1532107111852017,1.9381326356057054,0.6278926004915789,-1.9074019850189678,-1.7043638205635219,-1.4386222378526572,5.106148506882085,1.1819143968774548,-1.5981991896812118,4.0887001626766635,1.0904532089375527,0.31691596186362325,-1.6846997690645997,False,c2,1,"In DatabaseError.php are tow hardcoded http which can be changed to protocol realtive urls.
Thanks.
--------------------------
**Version**: 1.20.x
**Severity**: trivial",34379,-94,Medium,True
-5.294903470972692,1.768492376414482,-1.9323198043849867,-1.1240743344464215,-0.9337580480437278,0.667818315015041,-1.315957544402039,1.979168402152638,0.47703947062426044,-1.8922540152913352,-3.1869392101321825,1.7099318432843365,-0.5967260131957799,1.9359333683116606,0.8961832011198805,-0.6155414407375009,-0.34618728312038427,-0.1591051682943183,False,c2,1,"**Author:** `dnessett`
**Description:**
This bug was discovered while working on bug 32122 (https://bugzilla.wikimedia.org/show_bug.cgi?id=32122). In order to reproduce it reliably, a developer must make the following changes to php.ini (this should *not* be done on a production machine, since the settings force the PHP garbage collector to run on every page access).
- session.gc_probability = 100
- session.gc_divisor = 100
- session.gc_maxlifetime = 60
- session.save_path = <some directory writable by httpd>
After making these changes restart httpd. Then execute the following:
Login
Immediately log out
Wait more than 60 seconds. Do not change the page, stay on the ""Log out"" page
which states: ""You are now logged out. You can continue to use MW_1_16_5
anonymously ...""
Login
The error:
""Login error
There seems to be a problem with your login session; this action has been
canceled as a precaution against session hijacking. Go back to the previous
page, reload that page and then try again.""
is displayed.
This bug appears to arise due to session management logic in MW in tandem with PHP session garbage collection. One commenter on bug 32122 suggests this is expected behavior. However, from a user's point of view that is highly unlikely.
One possible solution is to destroy the session on logout. There is a PHP function, session_destroy that destroys session data, but it isn't clear whether that function actually deletes the session file. Also, it isn't clear how to delete sessions held by memcached.
--------------------------
**Version**: 1.16.x
**Severity**: normal",34363,-94,Medium,False
-7.68331469763733,2.151337194542812,6.45547044103763,8.354446267425143,-0.9271562680773816,3.455055989234345,1.4217987664678713,-1.404078654251034,-0.7439765165241172,-0.15363892260130285,0.42630901251435205,0.6614390176177185,0.8651766232694138,-1.3447092244807086,-1.5277469853125405,-1.2404867891077973,1.3597262086416453,-0.16433193864695905,False,c2,1,"Going to https://blog.wikimedia.org/ gives a mixed-content warning, because the images of the sidebar and the images of some posts/threads are loaded over http.
Please change all images to protocol relative url.
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",34227,-95,Medium,True
-3.9812373867611424,-4.21128741742549,-3.8737857781004585,1.716339709507848,0.91705885596131,-0.5412975130165132,0.5245012619170213,0.3075786521056779,-2.975345532990409,-1.1999911725644785,2.2385884484359466,-0.49182869621637504,-0.2039812431422794,-0.6891215829824073,-2.9143197938463934,-1.4521711111734708,-0.5870358432710998,-1.8291120446606421,False,c2,1,"I am not sure, if protocol-relative url in the sidebar works, when it works, please change all sitesupport-url to protocol-relative urls, so https user get a https link. When not, we need another bug for that, which blocks this bug.
This needs also some on-wiki changes, because at least de.wp has a local message [[de:MediaWiki:Sitesupport-url]].
Thanks.
--------------------------
**Version**: unspecified
**Severity**: normal",34215,-95,Medium,True
-0.3269459300262585,-0.4891044801679527,0.8260633609704549,0.9760635006343055,-0.18968327797051865,-2.25573145171311,2.439567317771693,1.6677442751039866,-1.519008964450691,-1.346302067273366,-0.710458100846941,2.072547840501997,0.9708817549254469,-0.01907208713777475,0.03897388841489402,-0.058831349322095605,1.0654931387765487,0.37173161538155575,False,c2,1,"When you go to https://toolserver.org/~krinkle/testswarm/ and start the tests only two scripts are loaded via https: jquery.js and run.js. All other scripts (line http://toolserver.org/~krinkle/testswarm-tmp-checkouts/r101990/resources/jquery/jquery.js) are loaded via http. This should change to https, too.
--------------------------
**Version**: unspecified
**Severity**: normal",34214,-95,Medium,True
-7.452556913156444,4.451621411574333,-2.2680505454416053,0.9246839405116236,-9.857934078553507,4.696319169216515,-0.16930748171490162,0.08978751621480058,-2.5508502628583694,-2.7830076736361224,-3.714122808746979,1.0438527766557992,-0.4913596553439614,-4.129757302423016,1.9451863610075417,2.7219498576104897,1.2862221832878176,0.8032015467847924,False,c2,1,"Or if the user was logged in via http and is logging out via https, the logged-in state in http will be kept.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",34144,-95,Medium,False
0.7912547488477171,1.357354214094478,1.5579373646907086,-1.4091624522017465,0.5044696873502745,-1.4846076294415167,2.285706894061115,-1.5427653040233702,-0.49256583230527967,0.8630810373667366,-0.5720847359414512,-0.6684034351948078,-0.6561768864003525,-0.40134661869072286,-0.16462198353919266,-1.0516246247509164,-0.5275594790410345,0.6073808053065661,False,c2,1,"When trying to access stats.wikimedia.org via https:// (I just did a copy and paste of url), it throws up an authentication form for username and password with text ""Nagios Access"". I am not sure whether this is the expected behaviour.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://stats.wikimedia.org
**See Also**:
https://rt.wikimedia.org/Ticket/Display.html?id=4749",34143,-95,Medium,True
1.1773361190018572,5.499756388599554,4.469863541216476,2.7167957698733134,-3.5615991986626105,2.772744761136426,-1.1093596281184643,0.22231028452124602,-0.28614206411878085,-1.7912768219522546,-1.8670367404571164,0.5678599440776964,1.1660794849663638,0.6464987904097672,-0.511809154705321,-1.70006827586006,-0.2241526083450287,-1.1250550783449902,False,c2,1,"Mails to the mailing list mediawiki-cvs start with a URL that leads to code review like:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100252
Please change this to be a HTTPS link like:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/100252
Slightly related to bug 29008.
--------------------------
**Version**: unspecified
**Severity**: normal",33826,-97,Medium,True
19.648671664534277,-1.4960021367065508,-5.93897398285077,7.2630728667627285,0.7220800289471954,-4.593173931863649,0.749952959857378,0.1060804871396534,0.13404588486088964,-1.5770487129516466,0.4894021822558732,0.025546352226129887,1.6088914678442485,0.5083933615388192,0.3955038452650479,-0.5544343291022026,-0.36066743904712917,-0.5556573067522794,False,c2,1,"**Author:** `maxi`
**Description:**
When connectiong via IPv6 to upload.wikimedia.org a wrong certificate is shown.
The certificate is issued for ""*.wikimediafoundation.org"" and ""wikimediafoundation.org"" which does not match upload.wikimedia.org. See below.
- Certificate[0] info:
- X.509 Certificate Information:
Version: 3
Serial Number (hex): 027a5f
Issuer: C=US,O=GeoTrust\, Inc.,CN=RapidSSL CA
Validity:
Not Before: Mon Jul 18 07:19:38 UTC 2011
Not After: Tue Jul 19 16:14:20 UTC 2016
Subject: serialNumber=DN84DBlZKsoLji7PlLHE4Pyj6ARQXJ-L,C=US,O=*.wikimediafoundation.org,OU=GT55614722,OU=See www.rapidssl.com/resources/cps (c)11,OU=Domain Control Validated - RapidSSL(R),CN=*.wikimediafoundation.org
Subject Public Key Algorithm: RSA
Certificate Security Level: Low
Modulus (bits 2048):
00:c3:79:a7:e0:cc:5f:7b:cc:10:5b:d2:eb:88:0d:55
ee:66:da:63:7c:0d:73:19:e8:04:85:95:d1:7f:b1:ae
fa:92:60:c8:8c:79:99:72:5b:c6:42:72:80:b9:b5:9a
11:6a:43:0f:d1:f3:c7:87:84:79:5d:56:56:b5:97:f9
2e:39:5a:61:18:8b:4f:83:56:94:38:30:44:a9:43:79
1f:ed:3f:36:ef:33:61:21:ca:fa:e3:90:3e:c9:52:18
6e:c5:3d:24:19:52:a7:90:ed:75:7a:b4:6f:40:e5:58
57:75:75:54:a2:ba:07:5c:26:57:66:7c:d4:46:f3:82
fe:c9:29:be:86:be:3c:a2:d7:e4:6e:5a:3a:fe:77:df
76:85:97:79:08:00:6b:66:fd:be:fd:1d:e5:f5:36:16
7c:92:a3:12:17:b0:f5:72:9a:7a:6b:e4:d8:31:42:70
3e:84:b4:8c:ae:69:c2:29:34:b1:89:c7:60:85:f4:2e
33:8a:1a:4a:50:26:dd:4d:7b:34:71:85:02:1e:6f:1d
8f:f1:db:b2:e0:6c:05:a5:b0:98:c1:74:39:2d:04:9d
cb:51:80:36:d9:e8:bb:3f:76:27:01:c9:65:f4:d5:dd
04:fe:1e:f7:0e:c2:c4:59:84:c8:b1:04:71:c8:f6:aa
bb
Exponent (bits 24):
01:00:01
Extensions:
Authority Key Identifier (not critical):
6b693d6a18424add8f026539fd35248678911630
Key Usage (critical):
Digital signature.
Key encipherment.
Key Purpose (not critical):
TLS WWW Server.
TLS WWW Client.
Subject Alternative Name (not critical):
DNSname: *.wikimediafoundation.org
DNSname: wikimediafoundation.org
CRL Distribution points (not critical):
URI: http://rapidssl-crl.geotrust.com/crls/rapidssl.crl
Subject Key Identifier (not critical):
16f250574f6b2250a9caa67c53a7b59b9eefbc5c
Basic Constraints (critical):
Certificate Authority (CA): FALSE
Unknown extension 1.3.6.1.5.5.7.1.1 (not critical):
ASCII: 0;09..+.....0..-http://rapidssl-aia.geotrust.com/rapidssl.crt
Hexdump: 303b303906082b06010505073002862d687474703a2f2f726170696473736c2d6169612e67656f74727573742e636f6d2f726170696473736c2e637274
Signature Algorithm: RSA-SHA1
Signature:
84:98:5c:64:9a:f1:09:05:31:5c:3f:89:56:41:a4:4c
02:3d:8c:87:db:d2:31:91:21:1b:4a:f8:a7:83:5d:2c
8d:90:63:ff:02:b5:7e:57:9e:42:22:63:23:cb:36:6d
d8:a5:46:a2:97:68:97:ee:b9:ce:29:b4:89:bd:13:82
01:c3:d2:eb:81:07:16:5a:38:18:97:fe:05:22:e0:ad
7b:b1:c8:2a:8c:47:e8:60:cc:63:ae:61:2d:5f:45:a8
e1:b6:eb:d2:8d:03:a1:84:0e:74:1c:af:75:f8:ab:10
09:85:31:c0:58:16:82:fd:ca:eb:4e:7c:79:4c:cb:ec
a7:39:70:96:ce:f5:fb:56:14:5b:c6:20:f7:8b:63:b3
f7:90:84:2f:dd:bb:99:54:86:cf:e6:38:b4:e1:f9:a2
85:61:05:0f:6f:51:73:04:76:60:a6:b5:c9:4d:18:ee
27:17:6a:a7:cb:d9:c4:3d:a3:8d:7e:74:5a:1d:25:41
ad:9e:ea:41:03:d1:c3:0f:a1:62:ed:76:04:cd:1e:62
e6:0c:77:c7:34:e4:48:6e:85:83:e1:a0:c4:62:ab:5d
e4:21:7d:89:d8:0c:d4:e2:8f:79:86:a4:4b:09:01:79
05:64:5c:e3:ab:2c:85:1e:b1:be:fb:93:c1:ec:42:89
Other Information:
MD5 fingerprint:
272480c41a073648db7fedd9066e96be
SHA-1 fingerprint:
70616f43e39edd64c5aedaa3f79372e654d0e30c
Public Key Id:
16f250574f6b2250a9caa67c53a7b59b9eefbc5c
-----BEGIN CERTIFICATE-----
MIIFBTCCA+2gAwIBAgIDAnpfMA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEUMBIGA1UEAxMLUmFwaWRTU0wgQ0Ew
HhcNMTEwNzE4MDcxOTM4WhcNMTYwNzE5MTYxNDIwWjCB+TEpMCcGA1UEBRMgRE44
NERCbFpLc29Mamk3UGxMSEU0UHlqNkFSUVhKLUwxCzAJBgNVBAYTAlVTMSIwIAYD
VQQKDBkqLndpa2ltZWRpYWZvdW5kYXRpb24ub3JnMRMwEQYDVQQLEwpHVDU1NjE0
NzIyMTEwLwYDVQQLEyhTZWUgd3d3LnJhcGlkc3NsLmNvbS9yZXNvdXJjZXMvY3Bz
IChjKTExMS8wLQYDVQQLEyZEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQgLSBSYXBp
ZFNTTChSKTEiMCAGA1UEAwwZKi53aWtpbWVkaWFmb3VuZGF0aW9uLm9yZzCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMN5p+DMX3vMEFvS64gNVe5m2mN8
DXMZ6ASFldF/sa76kmDIjHmZclvGQnKAubWaEWpDD9Hzx4eEeV1WVrWX+S45WmEY
i0+DVpQ4MESpQ3kf7T827zNhIcr645A+yVIYbsU9JBlSp5DtdXq0b0DlWFd1dVSi
ugdcJldmfNRG84L+ySm+hr48otfkblo6/nffdoWXeQgAa2b9vv0d5fU2FnySoxIX
sPVymnpr5NgxQnA+hLSMrmnCKTSxicdghfQuM4oaSlAm3U17NHGFAh5vHY/x27Lg
bAWlsJjBdDktBJ3LUYA22ei7P3YnAcll9NXdBP4e9w7CxFmEyLEEccj2qrsCAwEA
AaOCAVAwggFMMB8GA1UdIwQYMBaAFGtpPWoYQkrdjwJlOf01JIZ4kRYwMA4GA1Ud
DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwPQYDVR0R
BDYwNIIZKi53aWtpbWVkaWFmb3VuZGF0aW9uLm9yZ4IXd2lraW1lZGlhZm91bmRh
dGlvbi5vcmcwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3JhcGlkc3NsLWNybC5n
ZW90cnVzdC5jb20vY3Jscy9yYXBpZHNzbC5jcmwwHQYDVR0OBBYEFBbyUFdPayJQ
qcqmfFOntZue77xcMAwGA1UdEwEB/wQCMAAwSQYIKwYBBQUHAQEEPTA7MDkGCCsG
AQUFBzAChi1odHRwOi8vcmFwaWRzc2wtYWlhLmdlb3RydXN0LmNvbS9yYXBpZHNz
bC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAISYXGSa8QkFMVw/iVZBpEwCPYyH29Ix
kSEbSving10sjZBj/wK1fleeQiJjI8s2bdilRqKXaJfuuc4ptIm9E4IBw9LrgQcW
WjgYl/4FIuCte7HIKoxH6GDMY65hLV9FqOG269KNA6GEDnQcr3X4qxAJhTHAWBaC
/crrTnx5TMvspzlwls71+1YUW8Yg94tjs/eQhC/du5lUhs/mOLTh+aKFYQUPb1Fz
BHZgprXJTRjuJxdqp8vZxD2jjX50Wh0lQa2e6kED0cMPoWLtdgTNHmLmDHfHNORI
boWD4aDEYqtd5CF9idgM1OKPeYakSwkBeQVkXOOrLIUesb77k8HsQok=
-----END CERTIFICATE-----
$ host upload.wikimedia.org
upload.wikimedia.org is an alias for upload.esams.wikimedia.org.
upload.esams.wikimedia.org has address 91.198.174.234
upload.esams.wikimedia.org has IPv6 address 2620:0:862:1::80:2
When using the IPv4 address a valid certificate is provided.
This is especially annoying because I get certificate warnings every time I vistit a wikipedia page via https.
Please let me know If you need any additional information.
--------------------------
**Version**: unspecified
**Severity**: normal",33800,-98,Medium,True
-1.423117860763656,-0.15602994714587126,-2.896748007910592,-5.616439764348463,2.3789568860568644,0.5493783981487652,1.2425409290103238,-3.6372832973463862,-1.7327898804949782,1.968119121832343,0.6730874502133708,1.614733553743535,0.24356793422258693,-0.6824041307561917,0.3793743753974228,-0.7624767891081665,-0.7987428132837835,-1.2090437850697136,False,c2,1,"Looks like svn.wikimedia.org was restructured. At the moment, it points to the ""formey"" server which also host gerrit.
The viewvc tool is no more reachable : https://svn.wikimedia.org/viewvc/mediawiki/trunk/
We have it linked from www.mediawiki.org main page. Did someone forgot to reinstall viewvc? :-)
--------------------------
**Version**: unspecified
**Severity**: normal",33776,-98,Medium,True
15.070311755274819,-1.6156789893616548,1.987057149948786,-8.264650579263696,-1.450859231821058,-1.2288820298767704,-0.46548489665958215,-5.1432131609579,-4.745509727307725,2.4641492723167966,-1.7862893222795804,3.4733222906986834,0.602077591188301,1.6295733411332982,-1.6629386986788868,-2.4594368085267457,-1.111423121142166,0.260195294304711,False,c2,1,"SSL POSTs to /w/api.php are getting ""400 Bad Request"".
Sample POST: http://paste2.org/p/1721585
Result: http://paste2.org/p/1721603
Note that I've since changed my password.
--------------------------
**Version**: unspecified
**Severity**: normal",33756,-98,Medium,True
0.45477219842321004,-1.3675021131788867,7.411404209994885,5.083666797634423,4.726007638984747,2.6015682222561898,-1.9643415432898834,-0.4790710860072949,1.3277412452334503,-1.757979789573493,-0.7563269254583793,-1.1544135532058308,1.496532797097852,0.17284986275339875,-0.9678316390404564,2.982979452014012,2.0769785833461416,1.6271221761109593,False,c2,1,"Both
https://secure.wikimedia.org/wikipedia/en/w/api.php?action=parse&text=[[Link]][[File:Example.jpg]]
and
https://en.wikipedia.org/w/api.php?action=parse&text=[[Link]][[File:Example.jpg]]
create a link to http://en.wikipedia.org/wiki/Link and get the file from http://upload.wikimedia.org/wikipedia/en/a/a9/Example.jpg
Instead the link and the file should point to the secure site.
--------------------------
**Version**: 1.18.x
**Severity**: normal
**URL**: https://en.wikipedia.org/w/api.php?action=parse&text=%5B%5BLink%5D%5D%5B%5BFile%3AExample.jpg%5D%5D%5B%5BFile%3AExample.jpg%7Cthumb%5D%5D",33667,-98,Medium,True
0.52489690778097,4.127821416788034,3.1470183340005953,-0.30134121738291764,-4.489580752182587,4.6992371170794,-2.0488959403313536,-0.06408151402335016,3.5979078711311967,0.21666186389209408,-2.2110914047407118,-1.245185752829322,-1.0683675528664507,-0.3569650243027551,0.9583555867919591,0.2137199375816896,0.1453434950235577,-1.1144302585310288,False,c2,1,"**Author:** `matt`
**Description:**
To complete the deprecation of https://secure.wikimedia.org in favor of the SSL sites on the original domains, it should redirect to those sites. For example, https://secure.wikimedia.org/wikipedia/en/%s should redirect to https://en.wikipedia.org/%s .
The description of the ""SSL related"" bug component could stand to be updated as well.
--------------------------
**Version**: unspecified
**Severity**: major",33563,-99,Medium,True
-2.2847072675175166,-1.6591742085932157,-0.5810829134502278,1.9485176560669628,4.893098099616562,-2.367560909161808,1.226740930660048,1.436610589082481,2.884821810274021,-1.2781401325862736,-0.4018845616114093,0.7242149571429366,0.6960221443706045,1.6953352575551968,2.365415129912858,0.046713032527737064,1.2358844783298386,-1.6229307975475589,False,c2,1,"Before any authentication-based features are added, should definitely make sure it can do all its network access over SSL.
Currently the mobile frontend on the m. domains don't offer SSL directly (bug 31333 etc) which might be an issue. :)
--------------------------
**Version**: 1.0.0 (Android)
**Severity**: normal",33497,-99,Medium,True
-0.16376007549995997,-8.308776519842436,-6.715681347168106,-10.967690743467548,0.6702494811097033,-4.168622934291588,5.470898582511325,-4.396522755807927,4.094537249764408,2.6704382610849136,2.397969593461022,-1.9172412630797244,-1.5599128135768847,1.651560072467281,0.9313145506889446,1.458884868166786,3.2600566306096947,1.1574708028214482,False,c2,1,"and I'm not sure about revision links: r1. Let me test it here.
--------------------------
**Version**: unspecified
**Severity**: normal",33328,-100,Medium,True
4.742901438282608,-10.805337932885159,1.4094269936904418,-1.6675367814471116,-3.7785857767738564,4.239775535930959,3.1191769533973615,-1.1019736286297295,-3.052465286762633,2.9625825509034174,-2.9652443781658713,3.2876030757314743,-2.8284913815882415,0.030001375787061413,2.7352784642961003,-1.1282966728064332,-0.4334124762255247,1.0793805486672008,False,c2,1,"https://en.wikipedia.org/w/opensearch_desc.php is full of ""http://en.wikipedia.org/""
--------------------------
**Version**: unspecified
**Severity**: enhancement",33325,-100,Medium,False
1.4873530758777354,-0.8826216841741736,-1.6510169940031627,1.922057589495485,0.588803451048084,1.3242423088450186,3.208469057507185,-1.4051261245604332,3.6807773028152537,-0.425130985655902,-0.6685323563960113,0.07171252114833582,-1.8532417433702832,-0.22012026324163525,2.2872938944766608,0.8093903930584683,1.3640039416323118,2.1517632158427897,False,c2,1,"Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39380
https://bugzilla.wikimedia.org/show_bug.cgi?id=47832
https://bugzilla.wikimedia.org/show_bug.cgi?id=29898",33323,-100,Medium,False
-3.4320987142005297,-1.4826486003587753,-5.0822663308042735,-0.37718402296171627,-0.4228421786701719,-1.5005117849413414,-5.37296166732691,-0.6247418557540014,-1.5291984981299087,0.8283996430048788,1.7695282834029658,1.3371850071377887,-1.0390286080262117,0.048576513754598594,-0.5808714682618277,-0.16501228204630947,-0.09098016240204698,-0.4581383135840442,False,c2,0,"With the new 1.18 version, the magic word {{SERVER}} don't allow anymore to check protocol (http or https).
But there is one place where it is needed : in [[MediaWiki:Loginend]], system message used in [[Special:Connexion]]. We have to check the protocol to provide the good message permitting to the user to go to ""the other"" protocol.
It appears that it is not possible with magic words/wikitext, and it is not possible either to ""patch"" with a javascript feature as JS is disabled in [[Special:Connexion]].
The only solution I've found is to check the protocol in PHP, and provide the system message [[MediaWiki:Loginend]] or [[MediaWiki:Loginend-secure]] (to be created) depending on the result.
The file to update is /includes/templates/Userlogin.php. The class ""UserloginTemplate extends QuickTemplate"", near the end, the folowing line :
<div id=""loginend""><?php $this->msgWiki( 'loginend' ); ?></div>
have to be replaced by something like that :
<div id=""loginend""><?php
if($PROTOCOL==""https""){
$this->msgWiki( 'loginend-secure' );
}else{
$this->msgWiki( 'loginend' );
}
?></div>
I don-t know exacty how to perform the ($PROTOCOL==""https"") test, I assume that you'll get a solution...
--------------------------
**Version**: unspecified
**Severity**: normal",33293,-100,Medium,True
1.6807741670625158,0.871518756759512,0.2512913486637949,3.2637832862885974,2.132119487923778,-2.081057166484862,2.073386845053732,1.0877062690853903,-2.183626305976471,0.8882943118293491,-1.4343672907616065,0.03391398895449593,-0.3018698079480213,1.5050655480803554,0.25389506424822983,-0.06860912704107791,-0.04866644281917232,-2.1543158167048224,False,c2,0,"When login-in with $wgSecureLogin=true set, all logins return to the Main Page.
Cause:
When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters.
--------------------------
**Version**: 1.17.x
**Severity**: normal",33040,-102,Medium,True
12.809128657200905,-9.023051772387628,4.642257251603528,5.126952378078611,0.7238481405326846,-4.920373777734214,2.0846735439288766,1.1231091074575232,0.19594867844067765,-1.822764475792341,-1.5810212698190722,-1.7231788709475784,1.454438125153613,1.1546600559055014,1.1363820346745026,-0.4915453907013233,0.3802267916637325,-0.28002629194990125,False,c2,0,"**Author:** `RSYQFIOJGWZA`
**Description:**
en.m.wikipedia.org/w/index.php?title=User_talk:Jeff_G.&action=submit
403 HTTP method not allowed.
Error 403 HTTP method not
allowed.
HTTP method not allowed.
Guru Meditation:
XID: 1646037111
Varnish cache server
--------------------------
**Version**: --
**Severity**: normal
**URL**: http://en.m.wikipedia.org/w/index.php?title=User_talk:Jeff_G.&action=submit",32951,-102,Medium,True
-3.2233534058295845,-3.2195239762044476,-2.9887394846487823,0.4382937231928523,-3.036731975856911,-4.257840604299188,-3.41772486315755,-0.8480331149471478,-1.3912186660129737,2.520403970787651,-3.3710841001349157,-0.1951240850016297,-0.4516427878916014,-1.2599814478335887,-1.9726164290222385,-0.19489207553464216,1.1624301048318764,-1.3547189360422929,False,c2,0,"Not strictly in the scope of this tracker, I know, but putting this in as a TODO for myself.
On [[commons:MediaWiki:Vector.js]] (and possibly elsewhere), this:
var metaBase = 'http://meta.wikimedia.org';
if ( mw.config.get( 'wgServer' ) == 'https://secure.wikimedia.org' ) {
var metaBase = 'https://secure.wikimedia.org/wikipedia/meta';
}
needs to be changed to just
var metaBase = '//meta.wikimedia.org';
after we deploy HTTPS to meta.
--------------------------
**Version**: unspecified
**Severity**: normal",32734,-104,Medium,True
4.838264525521984,-0.5977321818501409,0.7445536825602268,-3.182645611100047,1.7420521644636553,3.249740559983943,1.7592827501832442,-0.3968537550355343,0.24268606893736688,-0.2629086198793438,0.21556440092905982,4.143872625462027,-0.17377601346344917,-0.051127355560453225,0.32431963416560716,1.7754586943265742,-0.10410398983669134,-0.3960546230956594,False,c2,1,"Special:Login is more intuitive than Special:UserLogin. I suppose there's no reason to move the current one, but could Special:Login be created as a redirect?
--------------------------
**Version**: unspecified
**Severity**: enhancement",39137,-66,Low,True
15.399459941272681,4.156367983714453,1.0119104051876455,-0.15108078340028974,-6.550727645238778,5.45186104033476,0.46767537302319795,-1.2722611401552504,-0.6587072091918785,-0.5474690672348066,-1.3290320149562673,-2.493124324122297,-0.29675300190695975,-0.7126365970009392,-1.6614564791529967,-1.171295692744531,0.766054365806802,-0.9981585376378975,False,c2,1,"Change Meta (fav)icon on Special:Userlogin (after form submit) from Wikimedia to the Community logo.
--------------------------
**Version**: unspecified
**Severity**: trivial",38982,-67,Low,True
4.283156606549294,0.1501763566675649,1.4347574810739516,0.7868522496536983,0.2611917020965263,0.2958170061396912,2.090847150810748,-5.85177961948736,4.526109416892573,0.23927753149448883,1.1154666429300986,-0.4711522325436185,-0.8418480183754742,-0.23097337209136803,1.4459317254495785,1.6418188867460273,-1.068051163913557,-0.8672884917569927,False,c2,1,"**Author:** `kete`
**Description:**
Nontrivial JavaScript should have a free license, so we can know what our browsers are doing. With libre licenses, we can study the JavaScript source code. Your wiki code could use a simple license declaration in the header as described at http://www.gnu.org/philosophy/javascript-trap.html#AppendixA
Regards
--------------------------
**Version**: unspecified
**Severity**: enhancement",38866,-68,Low,False
-0.46305864089161375,-7.3158822090158,1.7448829572834477,5.112252834069267,-1.873399039194958,-1.832889103434133,0.9226053824784808,1.900641672497592,6.05505635998559,-0.3756329974589354,-0.43422377931109857,6.507596137642869,0.5775569256221691,-3.311339234702144,2.3084287235253607,0.8077904177183228,1.727220651446358,-0.47518472628029085,False,c2,1,"See https://en.mobile.wikipedia.org.
*.mobile.wikipedia.org should be added to domain list or these domain name should be disused.
--------------------------
**Version**: unspecified
**Severity**: normal",38126,-71,Low,False
4.714907964277851,-3.7930607815649147,7.864127577108945,-2.537161917932662,3.8960713748910085,-1.063391862166006,0.28280637145007415,-2.7065510180061128,0.2556086651976721,3.276946115989798,0.16651295666564847,-2.5670354693337574,-0.49669873147535615,-0.7156954856986744,0.34973198768048785,1.399197776133542,0.9221132955891569,0.254439187579367,False,c2,1,"https://office.wikimedia.org/wiki/A outputs Retrieved from "" http://office.wikimedia.org/wiki/Special:Badtitle "" but I cannot get this Login required page from the given URL. (Instead I get a Bad title error page)
--------------------------
**Version**: unspecified
**Severity**: normal",38055,-71,Low,False
-0.7930589847525873,-8.836452730050322,-4.5656055635179165,6.190618748112876,-0.2930299444497076,-2.9953409849725148,-0.9420074072821141,-0.750449918011618,-2.919084115717517,4.1540535323635925,3.3451160502391644,-0.1859652186664359,3.4960246055656157,2.1912995204076706,0.150582109848159,-0.9069017614400898,0.12459521485206859,-0.3755567033842737,False,c2,1,"The query
https://en.wikipedia.org/w/api.php?action=query&list=watchlist&wlprop=loginfo&wllimit=max
shows the following output for me:
<?xml version=""1.0""?>
<api servedby=""srv265"">
<error code=""internal_api_error_MWException"" info=""Exception Caught: Internal error in ApiResult::setIndexedTagName: Bad parameter"" xml:space=""preserve"">
#0 /usr/local/apache/common-local/php-1.19/includes/api/ApiBase.php(1300): wfDebugDieBacktrace('Internal error ...')
#1 /usr/local/apache/common-local/php-1.19/includes/api/ApiResult.php(197): ApiBase::dieDebug('ApiResult::setI...', 'Bad parameter')
#2 /usr/local/apache/common-local/php-1.19/includes/api/ApiQueryLogEvents.php(264): ApiResult->setIndexedTagName('???[edit=autoco...', 'param')
#3 /usr/local/apache/common-local/php-1.19/includes/api/ApiQueryWatchlist.php(306): ApiQueryLogEvents::addLogParams(Object(ApiResult), Array, '???[edit=autoco...', 'protect', 'protect', '20120403012329')
#4 /usr/local/apache/common-local/php-1.19/includes/api/ApiQueryWatchlist.php(201): ApiQueryWatchlist->extractRowInfo(Object(stdClass))
#5 /usr/local/apache/common-local/php-1.19/includes/api/ApiQueryWatchlist.php(40): ApiQueryWatchlist->run()
#6 /usr/local/apache/common-local/php-1.19/includes/api/ApiQuery.php(266): ApiQueryWatchlist->execute()
#7 /usr/local/apache/common-local/php-1.19/includes/api/ApiMain.php(705): ApiQuery->execute()
#8 /usr/local/apache/common-local/php-1.19/includes/api/ApiMain.php(360): ApiMain->executeAction()
#9 /usr/local/apache/common-local/php-1.19/includes/api/ApiMain.php(344): ApiMain->executeActionWithErrorHandling()
#10 /usr/local/apache/common-local/php-1.19/api.php(117): ApiMain->execute()
#11 /usr/local/apache/common-local/live-1.5/api.php(3): require('/usr/local/apac...')
#12 {main}
</error>
</api>
It seems to happen when a watchlist entry refers to a protection, but not when it's an edit or a move.
I can replicate the error on my local wiki (although without the stack trace) that runs from master. And showing the same protection using list=recentchanges works fine.
--------------------------
**Version**: unspecified
**Severity**: normal",37797,-73,Low,True
-5.172454583207058,-1.563174961093349,-4.758645034270485,-2.2556616946269097,-1.2343077740025876,-1.025004984558196,-0.4273040152221066,7.813015938641969,-1.4843904365983327,-0.9166500161291475,4.387257112652058,0.2048943582273417,-3.252396636415959,1.4458849717265467,-2.4773027106650605,-0.8839104843856267,2.372858100111947,-0.9191110233411233,False,c2,1,"Not sure whether this should be part of [[bugzilla:34367]] or not
Anyway the server does not have https:// configured which means that one drops out of login, or cannot use protocol relative links.
--------------------------
**Version**: unspecified
**Severity**: normal",37488,-75,Low,True
13.803351427430414,-1.332799539676694,9.721623983004264,1.5503196271582298,3.2298642080207034,0.9683615804909935,4.163504537266191,2.190702094045876,0.1671904682981072,1.6125185867790242,1.527354800303946,0.9655023450006801,-0.3660668970200973,1.137181524774653,-1.5794869984342546,-0.3607020180208783,-1.433929667004349,-1.2812849997038218,False,c2,1,"Various old links to https://bugzilla.wikipedia.org are currently showing an SSL cert error:
> You attempted to reach bugzilla.wikipedia.org, but instead you
> actually reached a server identifying itself as *.wikimedia.org.
> This may be caused by a misconfiguration on the server or by something
> more serious. An attacker on your network could be trying to get you
> to visit a fake (and potentially harmful) version of
> bugzilla.wikipedia.org. You should not proceed.
Note that https://bugs.mediawiki.org does not show an SSL error
--------------------------
**Version**: unspecified
**Severity**: normal",37313,-76,Low,False
0.3479132530913107,-1.604523433254732,-0.0005288796330908951,4.861126137104367,-1.8932181153023637,-1.3704999006534895,-3.854900567136576,1.072323235581612,-1.6154954808637585,-2.9691576498941235,3.9391901273373633,0.09124762349745263,-4.184941498794044,-0.9404931369948115,-0.13891851660234522,-0.7554925226738591,1.0349991084273757,0.19268073839199196,False,c2,1,"**Author:** `carlb613`
**Description:**
There is a hook [[mw:manual:hook/LoginAuthenticateAudit]] which is currently called with (username, password, status) to report a status of any one of:
a) user logged in successfully
b) user supplied a bad password
c) user requested an e-mail password reset link
This hook is used by [[mw:Extension:Fail2banlog]] to ban (at the server firewall level) IPs which attempt brute-force attacks which repeatedly try to log in with bad passwords.
Unfortunately, it only detects access attempts blocked by core code and then only on login attempts. There are many more attempts to access the wiki in some way (edit, registration, upload...) which are blocked not by core code but by extensions hooked into any or all of the following:
* edit: ([[mw:Manual:Hooks/EditFilter|EditFilter]], [[mw:Manual:Hooks/EditFilterMerged|EditFilterMerged]], [[mwLManual:Hooks/APIEditBeforeSave|APIEditBeforeSave]])
* login and registration [[Manual:Hooks/AbortLogin|AbortLogin]], [[Manual:Hooks/AbortNewAccount|AbortNewAccount]]
* move: [[Manual:Hooks/AbortMove|AbortMove]]
* upload: [[Manual:Hooks/UploadVerification|UploadVerification]]
* delete: [[Manual:Hooks/ArticleDelete|ArticleDelete]]
Each of these hooks has some means (such as returning 'false' or setting $error to a non-null string) to reject an edit or other access attempt as spam.
Perhaps [[Manual:Hooks/LoginAuthenticateAudit|LoginAuthenticateAudit]] should have one extra event code added to indicate each of these actions (edit, login, register, move, upload) being rejected by an extension due to abuse.
That way, if [[mw:extension:SpamBlacklist]] were repeatedly rejecting edits due to spam URL's in the message payload, or [[mw:extension:ConfirmEdit]] were reporting repeated wrong answers to CAPTCHAs, [[mw:extension:fail2banlog]] could block the offending IPs once and for all.
--------------------------
**Version**: 1.20.x
**Severity**: enhancement
**URL**: http://www.mediawiki.org/wiki/Thread:Extension_talk:ConfirmEdit/SimpleCaptcha_now_useless#SimpleCaptcha_now_useless_12717
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=41522
https://bugzilla.wikimedia.org/show_bug.cgi?id=46292",36914,-78,Low,
-5.052884248433429,4.667221267104875,0.7254065667245904,2.2318728831936774,-2.396514526054164,1.3507291347839938,0.3343021822675212,1.0407979675402128,1.9922410377112916,-0.6662573213504386,-0.5333307072761495,1.221599447376178,0.20109470691703368,0.23829975593085084,-1.7467531699990686,-0.3388908203029697,-0.1501775841808446,0.859419585249982,False,c2,1,"**Author:** `carlb613`
**Description:**
AbuseFilter provides various mechanisms to block or demote a user who repeatedly does something questionable, based on its own ruleset (for instance, repeatedly blanking articles or article sections) but provides no means to create a rule which would perform some action in response to repeated login failures or repeated failures to get spam past an extension (such as ConfirmEdit or SpamBlacklist).
While we don't currently have a mechanism to notify AbuseFilter that a user is repeatedly falling CAPTCHA (short of changing code elsewhere in the system) we do have LoginAuthenticateAudit to report failed attempts to log in with repeated bad passwords. Unfortunately, the only extensions to use this info are either Fail2Ban (which firewalls the offending IP at the server level) or other CAPTCHAs (to present a CAPTCHA on subsequent login attempts if previous brute-force attempts have failed). There is nowhere where AbuseFilter requests to be notified on LoginAuthenticateAudit failures and no means to create a rule in the AbuseFilter to block an IP after an abusive number of failed login attempts.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://www.mediawiki.org/wiki/Thread:Extension_talk:ConfirmEdit/SimpleCaptcha_now_useless#SimpleCaptcha_now_useless_12717",36913,-78,Low,
-3.697134327625656,4.266274159248525,-0.34090860198583073,-3.6848462093865844,2.3596012110842937,1.7339405012301607,-0.3893652656647095,-0.5866466545859013,-1.38515547869808,-0.22570230379086453,-1.3046212335671696,1.2151444618853928,-1.934033578832886,1.6659768235422812,-0.42054625701802806,1.8288392483263591,-1.3096878444150504,1.4140943283457108,False,c2,1,"**Author:** `it_is_me_here`
**Description:**
See https://en.wikipedia.org/wiki/User_talk:Anomie#User_script. If you aren't logged in on a particular browser, then you paste in a Wikimedia URL that is only accessible to Admins/whatever and that includes doing an action (e.g. deleting) on multiple items (log entries, old versions of pages, etc.), and then you log in and click ""return to X"", you get an error message. An example of such a URL is https://en.wikipedia.org/w/index.php?title=Wikipedia%3ASandbox&action=historysubmit&revisiondelete=1&diff=477738682&ids%5B477738682%5D=1&oldid=477736475&ids%5B477736475%5D=1&ids%5B477734577%5D=1. The error message you get when trying to return to the page is:
""Invalid target revision: You have either not specified a target revision(s) to perform this function, the specified revision does not exist, or you are attempting to hide the current revision.
Return to Main Page.""
If you are already logged in, pasting in the URL works fine.
--------------------------
**Version**: 1.19
**Severity**: normal",36521,-80,Low,True
1.268392599750619,-3.737036118043303,7.675749872858152,3.2404515836046057,0.9122341426140221,-3.1384692266712735,1.7062448731901325,-0.6810909995045109,0.7385976369873881,0.16757527199035582,0.09401134964377222,0.06920931619369375,0.8936322956847276,1.7086850073810167,-1.1500481792762418,-0.11869439698802897,1.09436673985155,-2.1858641102811625,False,c2,1,"Try the example URL (found on https://blog.wikimedia.org/2012/01/31/getting-ready-for-when-the-freeze-is-done/ ): it's converted to mingle.corp.wikimedia.orgprojects which obviously doesn't work: Error 105 (net::ERR_NAME_NOT_RESOLVED. The same URL with https works.
--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: http://mingle.corp.wikimedia.org/projects/internationalization/cards/grid?color_by=type&filters[]=[Type][is][Story]&filters[]=[Sprint][is][%28Current+Sprint%29]&group_by=status&lanes=Ready+for+Analysis%2CIn+Analysis%2CReady+for+Development%2CIn+Development%2CReady+for+Testing%2CIn+Testing%2CReady+for+Signoff%2CAccepted&tab=Sprint+Backlog",36160,-82,Low,True
2.3630483803767137,-5.258400518505132,-1.0677283482231168,-3.5577750556656604,-1.2910886208031993,0.5838769133963564,1.9222441963033088,1.815079811849344,2.2150909230989173,-3.2762223445874588,-4.788094750038176,1.8856634905953065,-4.106236850342472,-0.9742389767908337,4.938372566422802,4.715437185030575,0.20293815902376822,0.5713027254460765,False,c2,1,"Global function wfHttpError() is only used in core by AjaxDispatcher. It should be deprecated and callers should use the HttpError exception instead.
--------------------------
**Version**: 1.20.x
**Severity**: enhancement",36151,-82,Low,False
0.2533729765604318,-4.154369440970173,6.529739243588843,-5.441040276455295,-2.738963788699899,-1.7674283393177899,0.6021659524269296,-1.8176463900204354,-1.1975028616967736,-0.17888345976538478,-0.595414195955505,0.8804075901094965,1.57257867020006,2.6398365033559044,-2.04831686234445,0.024412272668702384,3.0804714652592917,-0.07975642707349007,False,c2,1,"Input 12345 on https://en.wikipedia.org/w/index.php?title=Special:CongressLookup and press Look up then I'm sent to https://en.wikipedia.org/w/index.php?zip=12345&submit=Look+up which shows nothing related.
--------------------------
**Version**: unspecified
**Severity**: normal",35959,-83,Low,True
-11.470701550365742,6.394751954306464,-1.8071543800281855,-1.176399618933269,-3.1473565616772428,2.2564684517632028,2.8480805906430904,2.194610016048185,-2.7420855141037084,-1.8063298004987685,-1.9827087483357275,2.0868936817428967,-0.695662991825861,2.4592044701351714,0.059055616597404104,-1.384694079701312,0.5015840250876138,0.4370465913777337,False,c2,1,"Most often many users use wikitionary by directly entering the word they are looking out in the url and if article doesnt exist, get 404, page not found. Is it possible to get access to these 404 logs and share with the community, so that the community can create entries for nonexistant pages which are being looked up by the readers
--------------------------
**Version**: unspecified
**Severity**: enhancement",34514,-93,Low,
-0.05673506359179514,-5.6324735601162,-2.0695310963831677,0.39061239370062384,1.6406983408181803,-1.1638072870974194,-2.5062172517082844,-0.7215911823200566,1.0045564520840333,-1.6281695831981358,-0.965180825280767,0.054431189734469365,1.0458395699251382,-0.561194536618431,-2.04586218152401,-0.8590146424955349,-0.461932767008445,-1.6793450345981766,False,c2,1,"**Author:** `a.d.bergi`
**Description:**
proposed patch
When logged in, there is a button ""Benutzerkonto Anlegen (mit Passwortzusendung)"" which flows out of the containing box - see given URL.
I can't see any reason why that box should not have the usual 100% width, so I propose to remove all the width-related css.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://de.wikipedia.org/w/index.php?title=Spezial:Anmelden/signup&useskin=vector&debug=true
**Attached**: {F8579}",34397,-94,Low,True
-2.698281423152242,1.2097345342188461,3.7669536554362715,-0.22871862792589426,-1.0389462634654762,-3.029953515995543,4.466269930903278,3.2285288624615953,-2.4216257225276916,1.3317401593867597,0.7361725677419324,0.7117495557394113,-0.011228271387151878,0.05169666572892506,-1.9404554202395934,0.08099443536030865,2.0567444092951375,-0.797470669152327,False,c2,1,"CodeReview diffs that include images show the old & new images inline; when on https://www.mediawiki.org/ these are loaded from http://svn.wikimedia.org/ and so throw mixed-content warnings in browsers.
The images are loaded via ViewVC, which doesn't currently work on https://svn.wikimedia.org so we can't just switch it over to SSL or protocol-relative links.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/10262",34209,-95,Low,False
-3.359009780368923,0.5079095854075621,6.359032185537345,2.9352879778021297,-0.8906205228714139,-0.629007406245079,0.973197312148236,-4.292291538144161,-3.330571477619161,-2.0787220508736515,-1.4499876888360252,2.6190170632321843,0.4583250007449493,-0.6490519671158728,-1.017098814614533,1.0183866789534113,0.4815590712133897,-0.039044158642731475,False,c2,1,"If you access gerrit.wikimedia.org via http you are redirected to https. But URLs with a semicolon are broken after the redirect:
https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=tree;f=files/apache/sites;h=14baed1d9e959206c8fa15a6ff8e79bac2d04ab0;hb=HEAD
works,
but
http://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=tree;f=files/apache/sites;h=14baed1d9e959206c8fa15a6ff8e79bac2d04ab0;hb=HEAD
redirects to
https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git%3ba=tree%3bf=files/apache/sites%3bh=14baed1d9e959206c8fa15a6ff8e79bac2d04ab0%3bhb=HEAD
which gives a 404.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=tree;f=files/apache/sites;h=14baed1d9e959206c8fa15a6ff8e79bac2d04ab0;hb=HEAD",34201,-95,Low,True
-0.7847870800364163,-3.936382595207135,2.369328010302862,2.242859086914581,-6.101436614042905,-0.40378473460473285,5.4701045012458644,0.7577378524330011,2.3872175318864786,3.353591570724694,4.462728615259477,3.9397629950742523,0.6244819121133904,-2.707914564089241,3.6804618714427724,-2.0625344536087273,-0.5708317684000815,0.7356633956239487,False,c2,1,"For uploading higher-quality audio source material, it would be nice to support open lossless formats; Apple Lossless is now available as open-source so this should be feasible: <http://alac.macosforge.org/trac/wiki>
Transcoding to our standard output formats (eg .oga Vorbis) would be useful to keep playback support consistent.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://alac.macosforge.org/trac/wiki",34104,-96,Low,False
-1.7740698017139465,2.155734157186899,-0.18457675140331808,-1.276464227022014,-5.30587318995544,-0.4595014760329508,0.7651181171042598,1.8361388246723669,1.8369580712624758,3.0075844388650017,-0.3950524897464316,-0.28711444189517976,0.04188352725087796,2.4416818964928817,-1.6078067351307257,-0.3861158171881969,1.0603330012027363,-2.3789858305095164,False,c2,1,"https://en.m.wikipedia.org/
""Unable to connect
Firefox can't establish a connection to the server at en.m.wikipedia.org.""
*.m.wikipedia.org has its own font-end proxy (mobile-lb) which doesn't appear to handle port 443 for HTTPS.
Note that SSL certs for *.wikipedia.org won't apply to something.m.wikipedia.org as they only apply for that single level of wildcarding. Nice.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.m.wikipedia.org/",33333,-100,Low,True
0.9644744413115407,-4.950371898332888,-2.525956016534664,-10.958042529545255,5.514469287383992,-6.164944112501383,2.886215536071208,6.615680267292554,-1.7440785485686467,-1.5401068959105588,0.31803878560882914,-1.987851584475913,-3.6192383516011812,-0.6329645916002429,2.6394484538951906,2.3030709567702816,0.8544387295469369,0.7825931030693363,False,c2,1,"According to <https://en.wikipedia.org/wiki/Special:Version>, the CongressLookup extension (<https://www.mediawiki.org/wiki/Extension:CongressLookup>) is currently installed. It's no longer needed, as far as I know, and can safely be uninstalled. God willing it won't ever be needed again.
--------------------------
**Version**: unspecified
**Severity**: minor",39363,-64,Lowest,True
9.032660991785976,-7.8804675970897655,6.585519758884324,-2.244785327624493,-4.385743051705946,5.403001861745938,1.1691780611410403,-2.642909669074149,0.6454878535964614,-2.5974571703969977,-4.549499538624992,-1.153644013645234,-3.6910342071281343,1.1133936509952056,0.5314604615898793,-0.8353358074349126,1.9062188628096484,-0.15480017755121356,False,c2,1,"For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg
http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg
Some sort of Guru meditation.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",38166,-71,Lowest,False
-0.21005399491224797,-3.567753856449702,2.2111653502235455,0.6966898876279883,2.203214364538672,0.9651406216321095,0.878106280004368,-1.1064632293699233,-0.0065275830244238,-0.7874816593128515,-1.085892289698656,0.5370416734069801,-0.26147884077351513,-2.3246725883753956,0.7204668300545549,-0.6184192500906788,4.797753877139325,-2.323005538866094,False,c2,1,"**Author:** `pfhayes`
**Description:**
This change was made for the beta, but we can't release the real app until this is fixed.
Caused by this bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=34788
--------------------------
**Version**: unspecified
**Severity**: normal",37760,-73,Lowest,False
-6.0174440570381424,0.4609301358744258,-4.437684443919224,-0.2037371684647422,-0.4896570384063214,1.0223125903268502,2.633584704732937,0.01956932659252225,-2.5655534889024105,-0.8412905403142781,-0.2821771005576035,1.319043410333222,0.368042221764612,-1.054043138119857,-1.0009048610226783,-1.2541552209518896,-1.0537498826169456,0.39916781151721525,False,c2,1,"etherpad.wikimedia.org fails to work on https. The page loads correctly, but the channel appears empty, and after a few seconds you get a disconnection notice. At first glance the problem seems to be that the comet request is sent to http: even if the page is on https: and so it is tripped by cross-domain restrictions.
This is a big problem when using HTTPS Everywhere because it force-redirects everything under *.wikimedia.org to https.
--------------------------
**Version**: unspecified
**Severity**: normal",37637,-74,Lowest,True
15.909505280995152,-3.235660156368562,-4.046937282432152,1.3233546640489164,-0.14965659396581021,0.21329632732353443,-2.2194469728292856,-0.49728425419684064,0.06492920773706795,-2.418486229019799,-2.1264640159890433,-1.0442040017542578,2.9366700739523304,0.7254513271708731,0.05634210882570034,-0.6875023903333493,0.2820054222292758,-0.48493852845398466,False,c2,1,"**Author:** `wmf.amgine3691`
**Description:**
Error validating server certificate for 'https://svn.wikimedia.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *.wikimedia.org
- Valid: from Tue, 03 Aug 2010 14:43:56 GMT until Sat, 22 Aug 2015 21:23:10 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: ba:8a:be:34:b1:34:3b:af:06:05:4b:48:a9:27:aa:d9:b4:75:45:6e
--------------------------
**Version**: unspecified
**Severity**: normal",36721,-79,Lowest,True
-2.9148713319379778,-0.27795220569618095,-3.8105175210302775,-5.20379435552783,1.2093155177662183,-1.5507814863184377,-0.10381593224217855,0.7096225517430331,1.4093775567094393,-1.5662469439625304,-1.3603935757393555,2.097947354543142,-0.6949331115577344,-0.07218090453372561,-0.9033834105597016,-0.8058388515201504,0.6059278256648615,0.14736392227946538,False,c2,1,"This Connection is Untrusted
You have asked Firefox to connect
securely to en.planet.wikimedia.org, but we can't confirm that your connection is secure.
Normally, when you try to connect securely,
sites will present trusted identification to prove that you are
going to the right place. However, this site's identity can't be verified.
What Should I Do?
If you usually connect to
this site without problems, this error could mean that someone is
trying to impersonate the site, and you shouldn't continue.
Technical Details
en.planet.wikimedia.org uses an invalid security certificate.
The certificate is only valid for the following names:
*.wikimedia.org , wikimedia.org
(Error code: ssl_error_bad_cert_domain)
--------------------------
**Version**: unspecified
**Severity**: minor",35293,-88,Lowest,True
4.594816746037598,-3.0061578247181107,4.39902773057214,3.0793290252262695,1.69429731156607,1.8668975887817065,2.964153041390884,1.3574714640529328,-0.6052328075528834,-0.11037330528123324,-0.12311503504873622,-3.1339583270873423,-0.46387878456410725,-0.5049014594257848,-1.8802493085507073,-1.521792104386977,0.409321671529145,3.601651088143627,False,c2,1,"Updating a mediawiki file @enWP, and the call of javascript only works for http:// call
Working
http://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js
Not working
https://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js
--------------------------
**Version**: unspecified
**Severity**: normal",34893,-90,Lowest,True
-4.024865113466239,4.122824034082239,0.18984612861780548,-5.820877986632249,-6.351136932665364,-3.4513686045397476,2.5593292062899318,-0.3216547249178031,1.3632258465387739,-0.6065551651759531,-0.5970577986506376,-2.8896476649064904,-0.606935876415827,0.4383387957487592,-1.4433680074522401,-2.6752306988618635,-1.0371409115749701,1.3385494190003742,False,c2,1,"Hi,
It there anything against moving mwEmbed to commons / meta instead of prototype?
If it's only about having people to do the job, I'm considering to ask for editinterface rights for other security fixes related to https, so maybe I could do this too.
Best regards,
--------------------------
**Version**: unspecified
**Severity**: normal",34457,-93,Lowest,True
7.024196173294991,-7.9875497842894,-0.3069796155429696,-0.18263248383420105,-0.13579556100338952,4.5693117767845655,-1.3637615422405727,-1.3257161325832532,-2.495087983346928,1.4484081833554567,0.5713642252955355,-0.6628577992824496,-2.204022473575524,0.15018912292779696,-0.6263771666853897,1.7458149176319342,-1.8290842207611073,0.13578135001471225,False,c2,1,"E.g. https://en.wikipedia.org/wiki/Main_Page gives:
Retrieved from ""<a href=""http://en.wikipedia.org/wiki/Main_Page"">http://en.wikipedia.org/wiki/Main_Page</a>""</div>
--------------------------
**Version**: unspecified
**Severity**: trivial",33322,-100,Lowest,True
7.083387530204453,-6.299174267927624,2.357466123787546,5.598191156793122,-3.89699101210611,-2.757568110090694,1.8341459627311094,0.030708866855098882,-0.6588088496337596,3.3905009102753674,-0.5315610311756047,0.20841954884216052,1.5156714466100794,1.0422344121148956,0.36428884055056887,-0.3815418090405611,0.06901464023516657,-1.6834574341644295,False,c2,3,"seen since Saturday Nov 23:
attempt to login http://en.wikipedia.beta.wmflabs.org/
error is:
PHP fatal error in /data/project/apache/common-local/php-master/extensions/GettingStarted/Hooks.php line 84:
Class 'GettingStarted\MobileContext' not found
--------------------------
**Version**: unspecified
**Severity**: critical",59540,12,Unbreak Now!,True
14.1809280007236,-5.405303165458623,0.22688720458830858,3.2604682937729637,-2.1264415663817102,-1.461709340749597,3.444620339669707,1.0717142922469893,0.7207334310719402,-0.3684304126707936,-0.9296936247000831,-1.6858073580275084,-0.5251477708026311,-0.5669515229259856,-1.3608293081035985,-0.3321271278538115,-0.04557471577623007,-1.3447809380056328,False,c2,3,"https://m.mediawiki.org/wiki/Special:UserLogin
Exception thrown by mobile.issues.beta load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:145
Error: Template not found: overlays/cleanup Error {} load.php?d
--------------------------
**Version**: unspecified
**Severity**: normal",59624,12,Needs Triage,False
6.1547633931221934,3.889267145532237,-0.20856529013380332,-6.230477721051929,-1.7617862052230713,3.8791215489406303,0.6255539704799844,1.580399150533125,-1.0361878821624506,-0.6319279995980098,-0.2767922217378689,2.7703760492890668,-0.0723132831035267,-0.30559599050843556,0.4702729758587125,0.9211739010214645,-2.1902207476275644,-0.5232571348398334,False,c2,3,"Currently, a Google account is required to log in into Wikimetrics.
Now OAuth has been deployed for Wikimedia accounts, https://metrics.wmflabs.org/login seems a good candidate to consume it.
--------------------------
**Version**: unspecified
**Severity**: normal",59493,12,Needs Triage,False
3.1287478323982953,0.05507289641115065,4.074044257486253,1.9835201191405742,2.2754530172944945,-1.1346505920768122,2.2398944504454645,-4.213086125268934,0.49771996157007037,-0.931656336833957,0.01118901782472248,-1.4826713230354716,-0.44360419645709115,-0.4540725908665948,-0.5447595207997251,-0.0063064724600375155,0.37098618241973447,-0.4900234730666888,False,c2,3,"Hi. We have a problem with the entrance and exit to the site.
Please correct synonyms, we are no longer able to enter the system under its
entrance
https://ce.wikipedia.org/w/index.php?title=%D0%91%D0%B5%D0%BB%D1%85%D0%B0%D0%BD:%D0%A7%D1%83%D0%B2%D0%B0%D0%BB%D0%B0%D1%80/%D1%8F%D0%BB%D0%B0%D1%80&returnto=%D0%9A%D0%BE%D1%8C%D1%80%D1%82%D0%B0+%D0%B0%D0%B3%D3%80%D0%BE
output
https://ce.wikipedia.org/w/index.php?title=%D0%91%D0%B5%D0%BB%D1%85%D0%B0%D0%BD:%D0%90%D1%80%D0%B0%D0%B2%D0%B0%D0%BB%D0%B0%D1%80/%D1%8F%D0%BB%D0%B0%D1%80&returnto=%D0%9A%D0%BE%D1%8C%D1%80%D1%82%D0%B0+%D0%B0%D0%B3%D3%80%D0%BE
Userlogin → Чудалар
Userlogout → Арадалар
--------------------------
**Version**: wmf-deployment
**Severity**: major",59410,12,Needs Triage,True
5.207794617139095,-3.1764757190440367,10.362429944293776,2.589736321378973,-3.6452905678141767,-1.0227462219115226,1.3204355783940995,0.4693406924218888,2.1918015160668984,0.12347715606859655,-0.1981071742441669,1.0699725356875767,0.21664020549402085,-0.10518678884227661,-2.0515046316110452,0.2055886923344688,0.6611711357801464,0.39952581712789015,False,c2,3,"Unable to connect via https to https://ee-dashboard.wmflabs.org/ with Firefox and Chrome.
Firefox gives the error message: ssl_error_rx_record_too_long
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://ee-dashboard.wmflabs.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60865",59371,12,Needs Triage,False
9.090648762294695,-6.913347478141879,7.542659873850152,1.8144844050064708,0.6795681284693473,0.8328871199708241,-0.23525189143681757,-0.7384747907793906,3.3041488435933566,-1.9455384400958127,-2.5488241074063174,-0.6091572060364006,-1.2958103261925205,0.07569656530845226,-0.5552100390240167,0.353377016857317,-0.5998124722193854,-0.9427690005216345,False,c2,3,"**Author:** `tparis.wiki`
**Description:**
Please set up an SSL cert for the UTRS project.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://utrs.wmflabs.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53175",58927,10,Needs Triage,False
2.42270183568005,-2.445717401615214,6.880509437394554,5.364073907654558,-3.9794188396436594,-0.8264453773231479,-0.9236821411196026,-0.6214796181004636,3.863440134251314,2.245948540352429,-0.5274695132112921,1.1498528735022842,0.903335159183102,-0.963716571042391,-1.8720505119995252,-1.9709101019776916,-1.6867818823771823,0.22544611954745641,False,c2,3,"Error message
Steps to reproduce:
Click on the edit button
Observed Result:
""Error loading data from server:parsoidserver-http-bad-status:503"" shows while attempting to edit using VE
See the screenshot attached
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12683}",58584,9,Needs Triage,True
-1.6344522728088393,-1.105295340542094,-0.5324249026540695,2.462561490882317,-2.210302706912225,-4.503868436301103,-0.04329309203673404,-0.9400509472349049,0.5332389233773653,2.3182890753423626,-0.33097059313747,0.7687933525679544,2.251465603260853,-1.022349976709041,1.2802839505535442,1.5223963364766473,0.060081546884652504,0.8833572762509674,False,c2,3,"* 1.23wmf3 (e2e9b85)
Scenario:
+ en.wikipedia.org as of 2013-11-20
+ go to ""Reset Password"" page and trigger the I-forgot-my-passwort e-mail-password mail
+ come back to the login page
+ enter the temporary password
+ you are now correctly asked to change your password (=mandatory password change after login with temporary password)
+ after a successful password change you will see
Bug:
===
page title after successful password change is (still):
""Change Password""
URL is:
""https://en.wikipedia.org/w/index.php?title=Special:ChangePassword&returnto=&returntoquery=&fromhttp=1""
with unsuited information on it:
""You must be logged in to access this page directly.""
This is striclty reproducible.
--------------------------
**Version**: 1.23.0
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57098
https://bugzilla.wikimedia.org/show_bug.cgi?id=57065",59289,12,High,True
-0.49174079610282817,8.078072155683998,-3.3722370966549633,-6.733639578065968,-4.828403558259243,3.374893469155615,2.2488064615267698,2.669014669813088,-2.645149785469206,0.5095950177306499,0.18132842629082147,3.6178594259743413,0.21735958594619387,-2.538723313307965,3.2985244627492802,-0.16393901792841703,-0.4798983306275926,-2.7880943402985854,False,c2,3,"The redirect added to CentralAuth in Ia1232ac39e8 is effectively uncacheable, since it depends on wfCanIPUseHTTPS(), which can't be varied on in Varnish. The change should probably be reverted. It's essential that /checkLoggedIn be cached if the backend request rate impact of CentralAuth is to be reduced.
--------------------------
**Version**: unspecified
**Severity**: normal",59223,11,High,True
5.038702239900633,1.221294005352597,7.024703135255233,2.9133951158865012,3.485742825360466,0.321143270488508,0.9405043272145059,0.2773962295964584,0.6884175614659063,-1.5850329552226747,-1.2507139410497483,0.4287957555191002,-0.35833026254445866,1.0633431736935846,-1.1251956621648773,0.35478754969019655,0.9609650758259101,-0.9982968754487823,False,c2,3,"The current Parsoid unit tests (parserTests.js and friends) use Parsoid as a library directly. This means that the HTTP API code paths are not tested, leadig to issues like https://wikitech.wikimedia.org/wiki/Incident_documentation/20131104-Parsoid .
We should develop some way of unit-testing all the HTTP API endpoints.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56601",58730,10,High,False
-1.856563099406656,5.221666445617636,7.315829988502234,3.8958586029840454,-4.0406207588652485,-1.77621068706852,4.054182867152703,-2.4640598133856386,-1.2886915900391749,-0.29287772938513434,-0.28917741270285546,-2.2109102370361926,-1.0852933636681605,0.05082941418046705,-1.2272355251108857,2.2354286833347214,2.30332062994375,1.4010791679365677,False,c2,3,"Parsoid currently tests parsing and serialiation of content. Currently, testing of the HTTP API wrappers and any issues with libraries and bugs in the endpoints relies on manual testing.
Gaps in manual testing can lead to incidents like this: https://wikitech.wikimedia.org/wiki/Incident_documentation/20131104-Parsoid
So, we need an automated test setup for our HTTP API endpoints.
--------------------------
**Version**: unspecified
**Severity**: normal",58590,9,High,False
-6.300290432171359,5.4951833165147335,0.7964206020008433,2.225746434019874,1.018745148441187,0.44498685608142385,-0.22112475131111786,2.318326744734561,0.5746919632414152,-3.101097172667047,-2.494639726159561,-1.3056065287274126,-2.065942310288789,0.21186469753676818,-0.047644582937843794,0.14903087509756957,-0.7555360028868555,0.40422581761053844,False,c2,3,"$wgPersonaLoginAnywhere turns on having the Persona login button on every page in the Personal URLs section, rather than just having a button on the login page.
However, when $wgSecureLogin is enabled, all logins must be over HTTPS. Right now this is handled poorly: if the user is on HTTP and clicks the Persona login button, they go through the whole login process just to get an API error.
Unfortunately, there's really no way to make it work completely, but there are a couple of options:
1) Throw a configuration error if a sysadmin tries to have $wgSecureLogin turned on, $wgPersonaLoginAnywhere turned on, and $wgServer with non-HTTPS as the scheme
2) Automatically redirect all users to HTTPS (probably the less friendly option)
--------------------------
**Version**: unspecified
**Severity**: enhancement",59635,13,Medium,False
-1.8100476890300135,-2.9157611150515166,0.8042235810059495,0.2579479352221201,-3.056666634743974,1.0958218653705185,1.8837653040331581,0.8810324938221606,-0.2239218725813064,6.588606441675852,2.4061741808183235,1.2792019734331916,1.3214979941708864,-2.5633056501739966,2.013554299325218,0.2078214821426232,-2.568905618110253,0.2709563127863446,False,c2,3,"semantic-mediawiki.org offers https access. Thus it will be nice if the link for the existing interwiki prefix ""semantic-mw"" could be changed to ""https://www.semantic-mediawiki.org/wiki/$1"". Many thanks in advance!
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://semantic-mediawiki.org/wiki/Semantic_MediaWiki",59513,12,Medium,True
-1.730534693004028,0.27046605881206354,-3.4934883777252033,-2.237416858163662,3.739659426934552,-1.3832781145714979,0.25810903101508575,1.5607542694304057,1.358376291797024,-0.008369277416528043,-0.5898513096552445,1.5631764166467523,-1.5583667606424516,1.7674879450657022,-2.4507791042160405,2.011238122024596,5.143628247628261,-0.5701046460302397,False,c2,3,"Spam BlackList doesn't block links which doesn't have http or https or // (at the first)
for example I could add www.atbriders.com to the text which is listed in https://en.wikipedia.org/wiki/MediaWiki:Spam-blacklist
see
https://en.wikipedia.org/wiki/User:Yamaha5/Spam-blacklist
it should block also URLs which doesn't have http: or https: or // (at the first)
--------------------------
**Version**: unspecified
**Severity**: enhancement",58932,10,Medium,True
0.6161909181503011,2.464581633826132,-2.1481719840848594,-0.2624986183109389,-2.971772151751929,-1.1334952114480126,-3.7619886869048735,2.5039394924572105,0.35369574962151873,-0.9539712504762901,-0.02430270056819328,-0.44154648502356,-2.220302473039636,-0.37707039630124317,-0.47285026118926865,-1.2134742872488553,0.16700074610159588,-0.10567344099213094,False,c2,3,"The ConfirmEdit extension allows for local wikis to whitelist links using [[MediaWiki:Captcha-addurl-whitelist]]. But this only allows for whitelisting http and https links, even though the extension will trigger a captcha for any protocol.
The question here is twofold:
1. Should ConfirmEdit trigger captchas for other types of links in the first place?
2. If so, how can we extend [[MediaWiki:Captcha-addurl-whitelist]] to allow these to be whitelisted?
Personally, I'm inclined to answer ""yes"" and ""Perhaps add flags like in [[MediaWiki:TitleBlacklist]], one of which would indicate that this line should not be prefixed with /^https?:\/\/+[a-z0-9_\-.]*/""
--------------------------
**Version**: master
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Contains_external_links",58485,9,Medium,False
-0.8841596331999981,-2.238732008686304,1.8382108296675987,5.667242812655673,-0.5837482980433756,1.6795847909537815,3.7844525571150163,0.8787752160961441,0.32601580220544,1.013280149173097,0.7478195479474214,1.9583078890659806,0.002588306956416986,-0.927735616761622,0.5350421886219214,-0.7495801544521705,0.39515623800344746,-0.11167797174069904,False,c2,3,"For old svn commits giblit provides a link to mediawiki.org/wiki/Special:Code, but that link is always http, please provide a https link.
If possible, this link should be clickable.
Thanks.
Example on:
https://git.wikimedia.org/commit/mediawiki%2Fcore/96906d6cd38ba7c1c5af81e05a30105e6a29414f
--------------------------
**Version**: wmf-deployment
**Severity**: trivial",58953,10,Low,False
4.135932838252145,10.27335980572003,4.009336359875121,-4.542928144002667,-1.7580055569883373,1.4905470566609036,-0.3574682084152201,0.6341104967355595,-0.3232260001198741,1.4271456100226718,1.3369153763531627,2.3383016908673246,1.4147049058974912,-0.4293229203148883,-2.4216894818444055,-0.7993904110457997,3.9005229229427343,-1.6553589783555474,False,c3,1,"As of the last few hours, OAuth login does not appear to be working for any consumers.
I've tested these:
http://quarry.wmflabs.org/
http://wizard.wikiedu.org
http://tools.wmflabs.org/oauth-hello-world/",75968,-32,Unbreak Now!,True
-0.5727687653142097,5.683498749106189,-1.9248888461655902,-9.068333064143317,-10.021881114469268,-0.9784938454773153,2.6472845821244304,-1.8538111092700627,-2.546442564284648,1.8092696270257553,1.8278774397389417,1.7286008795156411,2.95391425553059,1.9996465103368655,0.7573190470566677,-3.697685116579993,-0.1323829008706594,0.2708467479226051,False,c3,1,"User:NickK reported in IRC that they're getting 504 timeout errors when trying to login to their unattached accounts on 1.24wmf22. On Wikipedias (still on 1.24wmf21), they're able to login fine.
My initial hunch is that I3a219d86a8837ed9c0c3788604dc3229ee1245ee is to blame.
--------------------------
**Version**: unspecified
**Severity**: critical",73223,-41,Unbreak Now!,True
8.031744716056918,-6.357667525159904,-2.8839900985566977,1.72146354355998,-2.431118168878796,0.48266522090638464,0.7524544221122014,-0.14886451801760697,-2.211805119664287,0.6233357825644097,3.0514762752158098,-1.4959681927977895,5.316385111215643,2.1579423546298058,1.0464569598023568,-1.1586513545856867,-0.5183376788316973,0.2256047133263015,True,c3,1,"Upon going to Special:UserLogin on English Wikipedia on Beta Labs (http://en.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin), I got redirected to Special:CentralLogin/complete (with token). However, it then threw an exception:
---
Unexpected non-MediaWiki exception encountered, of type ""BadMethodCallException""
[31c07ff4] /wiki/Special:CentralLogin/complete?token=201d1e72216aa80eef3f599b689e7bdc Exception from line 166 of /srv/common-local/php-master/extensions/CentralAuth/specials/SpecialCentralLogin.php: Call to a member function getId() on a non-object (boolean)
Backtrace:
#0 /srv/common-local/php-master/extensions/CentralAuth/specials/SpecialCentralLogin.php(33): SpecialCentralLogin->doLoginComplete(string)
#1 /srv/common-local/php-master/includes/specialpage/SpecialPage.php(357): SpecialCentralLogin->execute(string)
#2 /srv/common-local/php-master/includes/specialpage/SpecialPageFactory.php(516): SpecialPage->run(string)
#3 /srv/common-local/php-master/includes/MediaWiki.php(300): SpecialPageFactory::executePath(Title, RequestContext)
#4 /srv/common-local/php-master/includes/MediaWiki.php(609): MediaWiki->performRequest()
#5 /srv/common-local/php-master/includes/MediaWiki.php(460): MediaWiki->main()
#6 /srv/common-local/php-master/index.php(46): MediaWiki->run()
#7 /srv/common-local/w/index.php(3): include(string)
#8 {main}
---
--------------------------
**Version**: master
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69834",71565,-46,Unbreak Now!,True
-0.4050878575784371,-6.1438810606572964,-3.0139441465863026,-0.7788591831935328,-2.8125967682861392,-0.23220158119499268,-3.360685363763025,1.1586480545400972,-0.25564989871678223,-3.1198127916421194,-0.36358754259182113,0.3069591792081596,3.8409600537890616,3.0147135049322182,1.9178201300394289,-0.9574538687774721,1.881038902213464,-0.2419856108738654,False,c3,1,"This doesn't seem to affect all accounts (I am able to login just fine), but some accounts seem to have issues logging in since today on mediawiki.org, and 1.24wmf16 was deployed yesterday. This can't be just a coincidence.
[b596cdd3] 2014-08-01 09:04:31: Fatal exception of type PasswordError
[979b6eb4] 2014-08-01 12:49:06: Fatal exception of type PasswordError
See URL for those reports.
--------------------------
**Version**: wmf-deployment
**Severity**: major
**URL**: https://www.mediawiki.org/wiki/Thread:Project:Current_issues/Can%27t_log_in",71007,-48,Unbreak Now!,True
-2.19464426564232,2.0616527017025703,4.016757782342033,6.68074282440531,-4.628333666311246,-0.35538348261512986,0.6731196401391148,-2.709244008626652,0.5904415178034192,-1.4587245614671667,1.3093075005151564,1.0651245452736606,-0.7320422385006236,1.1613546374245454,1.73990464296653,-1.4511973399505105,1.0648493448272884,1.136202979994479,False,c3,1,"The public report files on wikimetrics need to be served with the right set of headers for caching and CORS so the dashboard can use them
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Whiteboard**: u=EEVSUser c=Wikimetrics p=5 s=2014-09-04",70445,-50,Unbreak Now!,True
3.2369265131106357,-5.349859055435532,-1.7927419341751154,1.8483692591031584,-2.504065732686636,-0.4914213594655513,-0.6518102038783908,0.08228640175092566,-1.9911792609446046,-0.45650474862895063,-1.054748190321345,0.8886215516249318,1.4974083351308005,-0.8636151144657171,-2.556513788002332,0.386095198677533,-0.595237276146351,-0.9374688893125245,False,c3,1,"**Author:** `mluxen`
**Description:**
If...
$wgGLAllowedDomains = array ('domain.tld');
$wgGLAllowedDomainsStrict = false;
...is enabled a blank webpage is shown after pressing Login with Google button and succesful Google Login.
The server log shows:
Fatal error: Call to undefined method SpecialGoogleLogin::getHost() in /<WEBROOT>/extensions/GoogleLogin/includes/specials/SpecialGoogleLogin.php on line 154
--------------------------
**Version**: master
**Severity**: critical",70316,-50,Unbreak Now!,True
-3.1946941256664543,7.607139064921167,3.650765178690083,4.0045323776499355,-3.403997349813102,1.052581679916533,2.2177144176777626,-0.8493677360609115,-0.8239346465601212,-1.2523710431943456,-1.7273530531869452,-0.8544809656759047,-1.5747016979088286,0.43923954160875933,-0.05909364803294537,0.17761309130599956,-1.6958120497948634,-1.3347992063990903,False,c3,1,"Actually it's only possible to login with Google via the button at the login form, if a valid (~existing) username is given in the login form.
Caused by: https://gerrit.wikimedia.org/r/#/c/143053/6
--------------------------
**Version**: master
**Severity**: blocker",70163,-50,Unbreak Now!,True
-1.8769765936763374,3.1578155836723525,5.132925954613601,-1.6874169773889085,-2.67037910877038,-4.124792560208369,-0.19373860949512167,-3.1887021520046566,0.6945718009423061,0.7205803940439592,0.07690787414205635,3.793548217199162,-0.6009414890158293,0.8679780573774618,-1.9294580449114345,1.2212331468131588,-1.600970654077897,0.18559690183104505,False,c3,1,"If you try to log in at <http://en.wikipedia.beta-hhvm.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page>, you get: ""Login error: Wikipedia uses cookies to log in users. You have cookies disabled. Please enable them and try again."" This is despite the fact that HHVM-powered wikis map loginwiki to loginwiki.wikimedia.beta-hhvm URLs, and the cookies that it sets appear to have the right domain.
--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68044",65981,-64,Unbreak Now!,True
-7.770266307523851,0.44205572289867767,2.341143670205078,-0.28627626497449976,-2.7822004971355034,-4.87263342422938,5.564074281675773,-0.9446187281623082,-0.36867226986759627,1.7738179259706337,3.2370032148419736,3.9754716516180864,-1.4108902790424587,-0.8433281602895546,2.0935121609861342,-3.0933636823587167,2.6637991891809563,-0.30660252084564266,False,c3,1,"when I setup wmflabs.org dns for any eqiad instance and try to relay it through https://wikitech.wikimedia.org/wiki/Special:NovaAddress I am getting some bad gateway error
this is likely because new instances can't be resolved from old cluster
--------------------------
**Version**: unspecified
**Severity**: blocker",64234,-70,Unbreak Now!,True
4.155778185775473,-10.293301169640372,0.520577253800024,1.4921153865723142,-6.227943943591871,3.7224109030370407,3.6914518474406117,-2.504774847494238,1.195447695003861,-1.7858449115749764,-3.9158584721299246,-1.1585227569410157,-3.9721689336375166,1.4775885879080537,0.8948373704809676,-0.6619907754278966,0.8372856340217714,0.13783281353526156,False,c3,1,"on https://meta.wikimedia.org/wiki/Main_Page
--------------------------
**Version**: wmf-deployment
**Severity**: critical",62970,-73,Unbreak Now!,True
-4.3840214719756245,-3.307834556957715,4.306145678482778,3.3702796058136393,4.770435810706969,-1.5726971634984679,1.4771914630353908,-0.3799153949232545,0.23220626100015396,-1.9285613313415455,-0.7622880441922879,-1.7243919820008653,0.23615215359299846,1.4904873967218224,-0.6217350673943542,-1.0786424784650015,-1.5959489876986768,0.2797296966292848,False,c3,1,"I currently get a 500 error when trying to login in the gerrit uploader. This basically makes the uploader useless.
--------------------------
**Version**: unspecified
**Severity**: blocker
**URL**: https://tools.wmflabs.org/gerrit-patch-uploader/oauth-callback?oauth_verifier=6cf9ad17806bbd30adcc941956af2f11&oauth_token=7d64f00ae120ffff36982fe64063300d",60705,-80,Unbreak Now!,True
7.083387530204453,-6.299174267927624,2.357466123787546,5.598191156793122,-3.89699101210611,-2.757568110090694,1.8341459627311094,0.030708866855098882,-0.6588088496337596,3.3905009102753674,-0.5315610311756047,0.20841954884216052,1.5156714466100794,1.0422344121148956,0.36428884055056887,-0.3815418090405611,0.06901464023516657,-1.6834574341644295,False,c3,1,"seen since Saturday Nov 23:
attempt to login http://en.wikipedia.beta.wmflabs.org/
error is:
PHP fatal error in /data/project/apache/common-local/php-master/extensions/GettingStarted/Hooks.php line 84:
Class 'GettingStarted\MobileContext' not found
--------------------------
**Version**: unspecified
**Severity**: critical",59540,-84,Unbreak Now!,True
-1.2094920371969495,-0.47722848190536027,1.5320795535313927,2.7916146408000375,0.13654566641234422,0.05302425861868576,-3.539939346769273,0.09301635360026539,-0.26077939115002896,-4.1156095579146275,1.5800648399333732,2.9694085071231333,-1.480365774590326,2.265761196703453,2.1431045356232703,-0.22727415505192927,0.3195061473694927,-0.28946678840358997,False,c3,1,"Now the HTTP login page redirects to the HTTPS version, but for some reason creating an account is exempt.
Is there any reason to allow the login details to be sent in cleartext even once?
What I expect: [1] should redirect to [2]
[1] http://en.wiktionary.org/w/index.php?title=Special:UserLogin&returnto=Wiktionary%3AMain+Page&type=signup
[2] https://en.wiktionary.org/w/index.php?title=Special:UserLogin&returnto=Wiktionary%3AMain+Page&type=signup
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55651,-96,Unbreak Now!,True
-3.2737418290211866,7.2396822732054815,2.7075362601069415,7.89581351565009,3.0366936877221224,5.042508214779478,1.3913504638179015,0.7067022422912673,1.3427615331470102,0.07504299064134123,0.742241340485529,-2.1000101751355658,0.16227157619248,0.09251456483471276,-2.81316458945123,-2.2412452381869814,2.479366737367152,3.2871574735330986,False,c3,1,"https://rt.wikimedia.org/Ticket/Display.html?id=8212
Long story short, need a cert for the file serving domain. Without this and according to the legal requirements, users cannot upload files.",373,-45,Unbreak Now!,True
3.2870827563478566,7.76754709066342,1.0080998677819402,-7.232492901241712,0.3180588244726902,-4.0314044695520925,-1.209232985393574,3.17611569968831,0.29213958633444703,3.2432422361491753,-2.0753426872723866,0.28721330882913865,-0.8622073325281523,1.2714311862817906,-1.9310836333049308,-1.0636777176497252,1.3537211597592422,1.0991827820931135,False,c3,1,"On wikipedia I use Yurivict.
When I try to login to phabricator, wikipedia password doesn't work.
""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"".
Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.
So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"".
Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia.
Now this leaves me confused, and unable to use single login at all.",76117,-31,Needs Triage,True
-3.9735931084406277,2.631677437321599,-3.5264133013266985,-11.543609521268625,5.781897331628576,-6.662465961156415,0.8316916981045024,1.3356174565728542,-4.370412175808427,-0.06381577246023795,1.620920618078705,2.7775031398371537,0.3454800117805874,2.0027630423863423,-2.316502389967741,-0.8684233425395316,2.753838621392009,0.5449881808337251,False,c3,1,"See: https://logstash-beta.wmflabs.org/#dashboard/temp/2SNGw0-8S1CRMRhiSZdiVA
I'm only calling this out because:
1. It's far and ahead the noisiest log there is
2. This is logging stuff that we don't log in prod, right?",75929,-32,Needs Triage,True
12.320451959367734,-1.9320118603625325,1.465963407815135,4.676541300169694,-0.03844795654109556,-2.2616184009703026,-2.788601459769919,-0.6285004252690614,0.5912786455665165,1.2582992519458465,-2.681029616372248,0.26785810113375974,-0.58216086466002,-2.0496816305988683,-0.6637111867480154,-0.15336441247533894,0.44178730126986876,-1.3076889583764233,False,c3,1,"The API returns result 'NotExists', but pywikibot prompts for a password
DEBUG:pywiki.data.api:API response received from vikidia:en:
{""login"":{""result"":""NotExists""}}
ERROR: Login failed (NotExists).
ERROR:pywiki:Login failed (NotExists).
Password for user Jayvdb on vikidia:en (no characters will be shown):
--------------------------
**Version**: core-(2.0)
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=73539",75533,-33,Needs Triage,True
11.711639543003253,4.959157528920642,5.003258551758748,-1.6352769604645319,1.8702510726535406,1.7699808617973785,0.6177037753762669,-0.287781273213165,-0.9280521840741726,-0.6681932951419265,-0.35944891869688256,-0.33693550770458014,0.6885346700525363,0.4513291400627537,0.7862169055543582,-1.3415987250802406,0.6069875255516888,-0.05883256956150529,False,c3,1,"Apparently Chrome Canary is unhappy with a certificate expiring in 2017 now. I'm not sure if this has anything to do with the SHA-1 signature.
You attempted to reach bugzilla.wikimedia.org, but the server presented a certificate for which the period is too long.
NET::ERR_CERT_VALIDITY_TOO_LONG
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.2 Safari/537.36
--------------------------
**Version**: wmf-deployment
**Severity**: normal",75190,-34,Needs Triage,True
4.6554767899666185,-14.901668499502007,-1.8208420798325236,0.06143768518482773,-1.131679710222592,2.0048767933626124,1.24323341489748,-0.9940146457621468,0.24813548914335037,-0.5990417377086752,-0.4082518183294721,-0.7871551712341799,0.6261408974148122,-1.6441463015034952,-1.4445787857705277,-0.24643932659486978,-0.2290083270018648,-0.6201487670837673,False,c3,1,"error
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F14847}",74980,-35,Needs Triage,True
0.21857737668103594,0.7307776042055689,-3.517805499872665,0.8028938855871317,-3.68332973757344,-6.172807285910214,4.175311536113976,8.190626797487493,1.148312014563153,1.982574417478494,1.315969167450111,1.9389287317635004,0.7529736433233118,2.6215196821506295,-4.9835401575869875,0.2756751254482692,1.7568494470451814,-1.6666352573889578,False,c3,1,"generate_family_file.py does not add support for https
```
$ python ./generate_family_file.py https://wikiapiary.com/wiki/Main_Page wikiapiary
Generating family file from https://wikiapiary.com/wiki/Main_Page
==================================
api url: https://wikiapiary.com/w/api.php
MediaWiki version: 1.23.6
==================================
Determining other languages...
Loading wikis...
* en... in cache
Writing pywikibot/families/wikiapiary_family.py...
$ cat pywikibot/families/wikiapiary_family.py
# -*- coding: utf-8 -*-
""""""
This family file was auto-generated by $Id: 185033971c163ea46b2b1904773b8c407069a4d0 $
Configuration parameters:
url = https://wikiapiary.com/wiki/Main_Page
name = wikiapiary
Please do not commit this to the Git repository!
""""""
from pywikibot import family
class Family(family.Family):
def __init__(self):
family.Family.__init__(self)
self.name = 'wikiapiary'
self.langs = {
'en': 'wikiapiary.com',
}
def scriptpath(self, code):
return {
'en': '/w',
}[code]
def version(self, code):
return {
'en': u'1.23.6',
}[code]
```",74895,-35,Needs Triage,True
14.420973708882855,-1.5209953057414012,10.47356474314143,-6.162915283536718,-6.517266649111887,5.231320056037079,0.3712192768758751,0.10423208918984728,-2.275444434271363,-1.4346134232676642,-2.371302636325151,-1.7902476483005678,-0.24260329963274163,-0.6611527599125653,2.4345835890722034,-0.8520448966810401,1.344960454241953,-0.5066997222169829,False,c3,1,"From EditPreviewFragment:
https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=7922735
https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=7921778
Were these caused by Gerrit change 168313?
Also from EditSectionActivity in https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=7918248
--------------------------
**Version**: Stable
**Severity**: normal",74832,-35,Needs Triage,True
3.1555501441416784,-8.743864548445647,3.1010921439970573,-4.2412607017627835,2.918368755440367,-1.89140511759591,1.8092161666227566,0.89988428847909,-1.3788778407114193,0.4229362301139368,0.13923749509347783,1.963055556000932,0.5602840216842804,0.37989685121789485,-2.6312638190387916,2.03817326752403,0.34026806425758593,-2.9293913722616605,False,c3,1,"Eek
See screenshot.
In JS we don't show the icons
Expected: icon is not visible.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F14851}",74723,-36,Needs Triage,True
-0.059712172387024864,-6.638598692496036,1.4855566844630204,0.18607565203549137,0.2502704140832813,-2.7580981129749347,1.6543798525644178,0.3891395290585741,-0.31445946919414297,-1.6141529867404532,-1.277822000493435,1.1825099356329754,0.11956432676497997,-1.189846181146406,-1.3980892817301065,1.0990298605974886,-0.04744617455449207,-0.09300148198444247,False,c3,1,"alpha login page
See image. The language links should be centered (or maybe hidden?). Now they look out of place.
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F15220}",74597,-36,Needs Triage,True
-12.801892232279204,7.9777548430004295,-1.3896596768069074,1.3501581049133606,-0.3368363920416391,2.6746310217679987,1.0322857477086265,-3.300504776147476,0.8769441667740909,0.3499971612645085,0.25076672317049864,-1.4889359104142827,-0.6736378243668639,1.3245240642974707,-1.2672063142853656,1.8205957570626632,-0.6950581724658978,-0.6178108993599674,False,c3,1,"If you click on the edit pencil (you're not logged in) on a section heading, you'll have a returnquery in the login link (returntoquery=action%3Dedit%26section%3D1) which will result in a redirect to the mobile editor after a successful login.
This returnquery is missing for the lead section edit link, so if you successful logged in, you only see the article, but have to click again to edit.
--------------------------
**Version**: unspecified
**Severity**: normal",74580,-36,Needs Triage,True
-0.20203348400122056,-6.25202953849832,-3.8887636883421184,-0.8508791009579161,-4.764982140145504,-1.3144704995806675,2.0591031790849064,5.100312661432471,1.7544754294005258,1.141649119020058,0.19593214785723756,-2.83931257468503,0.8736250386668512,-0.7153096460815203,-2.1296191339996535,1.4324043284609898,1.196557482502605,-0.9224278218235407,False,c3,1,"unstyled login buttons
Tested on master, but can't reproduce in beta labs (see image), so unconfirmed for now.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F14880}",74482,-36,Needs Triage,True
1.739396055603946,-0.8350836418486409,-0.8371263457220817,1.2300329758172976,1.2555308202963478,-4.86812686136238,-1.6298226718743019,-2.480734397765038,-1.4777127288110263,-0.42754625113233224,-1.8141888899093823,0.2539168081291532,1.1287339977549138,-0.6164630963450817,1.01862014627679,-1.3137409522229373,0.939737205261651,0.8759718237360341,False,c3,1,"I recently upgraded from 1.20.8 to 1.23.2 and it now appears the job queue is not running, though manual runs of the runJobs script do work. The wiki debug log has messages saying:
[runJobs] Running 1 job(s) via '/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=NNN&signature=NNN'
[runJobs] Failed to start cron API: received 'HTTP/1.1 411 Length Required'
It was suggested on the IRC channel that others are seeing this too and that I should file a bug report, so here it is.
--------------------------
**Version**: 1.23.2
**Severity**: major
**OS**: Linux",74274,-37,Needs Triage,True
-3.2005042335734704,-4.846926906902738,-4.754326870067274,5.008402900481982,-0.13560238806221064,-3.890087379299019,-2.9938157156067695,-0.716501833427702,0.05260601957828204,2.060500706304545,-2.119403762534007,1.3178063119191454,0.5443107661374351,0.5808797573302495,-0.3253039915615492,-0.8781080414294413,0.4960467962881534,-0.3956583141015011,False,c3,1,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.
Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2.
Steps to reproduce:
1. Uninstall httplib2 from python34 environment.
2. rm -rf externals/httplib2
3. mkdir externals/httplib2
4. python34 pwb.py version
Expected results:
An error like:
Python module httplib2 >= 0.6.0 is required.
Did you clone without --recursive?
Try running 'git submodule update --init'
Actual results:
AttributeError: 'module' object has no attribute '__version__'
--------------------------
**Version**: core-(2.0)
**Severity**: normal",74249,-37,Needs Triage,True
-0.8935341826944505,-1.2184727732778917,1.0293085469196477,0.5371896996809267,-1.1358225449291937,-1.2865320702542373,0.2265879340808752,4.201346893105233,2.453991542130873,-1.2346825515793558,-0.651141136373024,1.3157586106667576,-0.30874605299232893,1.3164244358826025,-1.3274034497418477,-0.0013153507771046513,-0.02397744302113547,1.3553563767536867,False,c3,1,"Very closely related to bug 72009, the http module should detect SSL certificate errors and raise a FatalServerException so that api.py doesnt keep trying to connect. This works in py2, but py3 ssl error codes are different.
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72236",74247,-37,Needs Triage,True
-1.4819458938095733,-1.7021689591968325,-4.12821787796795,-3.548171909045093,-1.8001257749581852,-0.9147585192678664,-6.044618712157336,-2.7944680696194273,-1.9915470642060071,-0.72125526064168,3.523623347149574,-0.3131255061446634,-0.13031549177953927,0.6670377639316953,-0.39825812560283325,-0.3009537919271391,-0.808311643915014,-0.9149433144444423,False,c3,1,"On English Wikipedia, go to [[Special:LinkSearch]]. Enter ""en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Redrose64"", click ""Search"". It comes back with ""There are no results for this report."", even though the link (formatted as [1]) exists at [2] and [3]. I want to find all the places that it's linked in that manner, so that I can fix them all to a proper internal wikilink.
1. https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Redrose64
2. https://en.wikipedia.org/wiki/Template_talk:Same-sex_unions#Template-protected_edit_request_on_15_October_2014
3. https://en.wikipedia.org/wiki/Wikipedia:Requests_for_page_protection#Template:Same-sex_unions_.28edit.7Ctalk.7Chistory.7Clinks.7Cwatch.7Clogs.29
--------------------------
**Version**: unspecified
**Severity**: normal",74185,-37,Needs Triage,True
-0.3622454550895462,1.2746223195629067,-2.3708922513534407,2.629885331671914,-3.8656751852859808,3.000280727417879,6.4564433655056375,2.172455277811,-3.0604988531561936,2.679950143566539,3.167899364920691,-1.0711473295887528,0.6955160203720352,-1.256895564810414,-0.019824234199600888,1.1300716595453162,-1.703853364575556,1.1971823373450945,False,c3,1,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",74182,-37,Needs Triage,True
-3.9355548436713343,2.4558895994504226,-0.8218656867531653,3.5203117984297476,-1.3349411243952074,-0.7149721633136465,0.020078479420833517,2.1629655457887043,0.46363395833570187,2.7544395248133666,-1.0866762461917074,0.2542808201329565,0.574289889977265,0.9317236718175623,-0.5850702445540117,0.19978368677842298,-0.7420379920906107,1.0027384688891938,False,c3,1,"Browser tests explicitly load pages and click buttons that load pages.
Neither seems to detect outright page load failures. E.g. https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/263/testReport/%28root%29/Actions%20menu%20Permalink/Topic_Actions_menu_Permalink/ failed with status 500 response and a printed exception, but the test instead reported
Sauce Labs job URL: http://saucelabs.com/jobs/b15aad5529da47ea979bb0196f17c320
timed out after 5 seconds, waiting for {:css=>"".flow-topic h2"", :index=>0, :tag_name=>""h2""} to become present (Watir::Wait::TimeoutError)
Like ""page has no ResourceLoader errors"" (implemented) and ""browser tests should assert there are no pink error boxes on the page"" (bug 61304), most tests should have an easy way to indicate that an error in a page load should fail outright with something like ""unexpected HTTP response (500)"".
However, note the comment in http://stackoverflow.com/a/5629462/451712 : ""There's a bit of a philosophical debate on whether watir or watir-webdriver should provide HTTP return code information."" so this may be hard to fix. Since beta and production show errors slightly differently, and some HTTP response errors have friendlier HTML content like ""Wikipedia does not have an article with this exact name"", I'm not sure how to easily and generically detect from page content that there's been a breakdown, even though it's obvious to a human being :)
--------------------------
**Version**: unspecified
**Severity**: enhancement",74098,-38,Needs Triage,True
4.157459454749272,-1.1038361917302364,-4.517187506621648,7.386572978963828,-1.2029487984369216,-2.967556067164163,-3.197996774969269,-0.9758089531875054,-2.6898899287505067,-0.18384788115070805,0.8301976284915469,-1.1519874066473392,1.6757007980203946,0.4927535306141655,1.4405219921598773,0.2030250277572814,-0.2592730416845972,-0.5281566616835232,False,c3,1,"An Echo browser test trying to create an account failed with 503 Service unavailable. That's understandable, but the indication of failure was buried in the HTML of the WMF error page.
It would be great if the mediawiki_api gem noticed the HTTP request error status and failed with e.g. ""create_account API HTTP request failure: <Status line>""
I'm confused because gerrit 157300 fixed bug 70193 ""Client now throws an HttpError when handling HTTP responses"", but the check
raise HttpError, response.status if response.status >= 400
seems missing from mediawiki_api-0.2.1 in this CI run and my local .rvm gem.
The failure was in <https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/105/consoleFull>
The line that went wrong is:
on(APIPage).client.create_account(username, ENV[""MEDIAWIKI_PASSWORD""])
The console output is
...
05:35:08 Given I am logged in as a new user # features/step_definitions/notifications_steps.rb:60
05:35:08 757: unexpected token at '<!DOCTYPE html PUBLIC ""-//W3C//DTD XHTML 1.0 Transitional//EN"" ""http://www.w3.org/TR/2002/REC-xhtml1-20020801/DTD/xhtml1-transitional.dtd"">
... entire text of the HTML error page
... 100s of lines later:
05:35:09 <!-- Technical details of the error; shows all the time, with any language -->
05:35:09 <div class=""TechnicalStuff"">
05:35:09 <bdo dir=""ltr"">
05:35:09 503 Service Temporarily Unavailable
05:35:09 </bdo>
05:35:09 <div id=""AdditionalTechnicalStuff""></div>
05:35:09 </div>
... 100s more lines
05:35:09 </html>
05:35:09
05:35:09 ' (JSON::ParserError)
05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/json-1.8.1/lib/json/common.rb:155:in `parse'
05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/json-1.8.1/lib/json/common.rb:155:in `parse'
05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/response.rb:85:in `response_object'
05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/response.rb:46:in `data'
05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/client.rb:51:in `create_account'
05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/client.rb:58:in `create_account'
05:35:09 /mnt/jenkins-workspace/workspace/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/tests/browser/features/step_definitions/common_steps.rb:48:in `block in <top (required)>'
--------------------------
**Version**: unspecified
**Severity**: normal",74056,-38,Needs Triage,True
5.116324349769743,-2.602689281584013,-4.346179628301902,12.138135709779652,-4.596493631660236,-6.544337540379531,-1.4127798643829648,-1.1197166695473921,-1.7909243661209526,2.3383397290186663,-2.488983891293854,-1.1839544461059415,2.3668409168068156,0.17045950097625084,1.5374039879343675,1.0491114065186493,-2.0410770074120643,0.24629316890299946,False,c3,1,"IIRC, there is a problem with certificates in httplib2 pre-0.9 (bug 65189). FC20 ships 0.7.7 on python2 and python3
$ rpm -qi python-httplib2
Name : python-httplib2
Version : 0.7.7
Release : 3.fc20
...
$ rpm -qi python3-httplib2
Name : python3-httplib2
Version : 0.7.7
Release : 3.fc20
...
On py2, the 0.7.7 package works correctly.
On py3, the following occurs running site_tests
On py2, all tests pass using 0.7.7. On python3, tests fail badly (using en.wp as default site).
$ python3 pwb.py tests/site_tests.py
.../pywikibot/family.py:879: DeprecationWarning: imp.load_source() is deprecated; use importlib.machinery.SourceFileLoader(name, pathname).load_module() instead
myfamily = imp.load_source(fam, config.family_files[fam])
ERROR: Traceback (most recent call last):
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 992, in _conn_request
response = conn.getresponse()
File ""/usr/lib64/python3.3/http/client.py"", line 1135, in getresponse
raise ResponseNotReady(self.__state)
http.client.ResponseNotReady: Idle
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "".../pywikibot/data/api.py"", line 517, in submit
headers=headers, body=body)
File "".../pywikibot/tools.py"", line 367, in wrapper
return method(*__args, **__kw)
File "".../pywikibot/comms/http.py"", line 258, in request
raise request.data
File "".../pywikibot/comms/threadedhttp.py"", line 219, in request
max_redirects, connection_type
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 1272, in request
(response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 1026, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, headers)
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 999, in _conn_request
conn.connect()
File ""/usr/lib64/python3.3/http/client.py"", line 1202, in connect
server_hostname=server_hostname)
File ""/usr/lib64/python3.3/ssl.py"", line 245, in wrap_socket
_context=self)
File ""/usr/lib64/python3.3/ssl.py"", line 345, in __init__
raise x
File ""/usr/lib64/python3.3/ssl.py"", line 341, in __init__
self.do_handshake()
File ""/usr/lib64/python3.3/ssl.py"", line 548, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:547)
WARNING: Waiting 5 seconds before retrying.
ERROR: Traceback (most recent call last):
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 992, in _conn_request
response = conn.getresponse()
File ""/usr/lib64/python3.3/http/client.py"", line 1135, in getresponse
raise ResponseNotReady(self.__state)
http.client.ResponseNotReady: Idle
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "".../pywikibot/data/api.py"", line 517, in submit
headers=headers, body=body)
File "".../pywikibot/tools.py"", line 367, in wrapper
return method(*__args, **__kw)
File "".../pywikibot/comms/http.py"", line 258, in request
raise request.data
File "".../pywikibot/comms/threadedhttp.py"", line 219, in request
max_redirects, connection_type
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 1272, in request
(response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 1026, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, headers)
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 999, in _conn_request
conn.connect()
File ""/usr/lib64/python3.3/http/client.py"", line 1202, in connect
server_hostname=server_hostname)
File ""/usr/lib64/python3.3/ssl.py"", line 245, in wrap_socket
_context=self)
File ""/usr/lib64/python3.3/ssl.py"", line 345, in __init__
raise x
File ""/usr/lib64/python3.3/ssl.py"", line 341, in __init__
self.do_handshake()
File ""/usr/lib64/python3.3/ssl.py"", line 548, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:547)
WARNING: Waiting 10 seconds before retrying.
^CTraceback (most recent call last):
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 992, in _conn_request
response = conn.getresponse()
File ""/usr/lib64/python3.3/http/client.py"", line 1135, in getresponse
raise ResponseNotReady(self.__state)
http.client.ResponseNotReady: Idle
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "".../pywikibot/data/api.py"", line 517, in submit
headers=headers, body=body)
File "".../pywikibot/tools.py"", line 367, in wrapper
return method(*__args, **__kw)
File "".../pywikibot/comms/http.py"", line 258, in request
raise request.data
File "".../pywikibot/comms/threadedhttp.py"", line 219, in request
max_redirects, connection_type
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 1272, in request
(response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 1026, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, headers)
File ""/usr/lib/python3.3/site-packages/httplib2/__init__.py"", line 999, in _conn_request
conn.connect()
File ""/usr/lib64/python3.3/http/client.py"", line 1202, in connect
server_hostname=server_hostname)
File ""/usr/lib64/python3.3/ssl.py"", line 245, in wrap_socket
_context=self)
File ""/usr/lib64/python3.3/ssl.py"", line 345, in __init__
raise x
File ""/usr/lib64/python3.3/ssl.py"", line 341, in __init__
self.do_handshake()
File ""/usr/lib64/python3.3/ssl.py"", line 548, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:547)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File ""pwb.py"", line 164, in <module>
run_python_file(fn, argv, argvu)
File ""pwb.py"", line 69, in run_python_file
exec(compile(source, filename, ""exec""), main_mod.__dict__)
File ""tests/site_tests.py"", line 1481, in <module>
unittest.main()
File ""/usr/lib64/python3.3/unittest/main.py"", line 125, in __init__
self.runTests()
File ""/usr/lib64/python3.3/unittest/main.py"", line 265, in runTests
self.result = testRunner.run(self.test)
File ""/usr/lib64/python3.3/unittest/runner.py"", line 168, in run
test(result)
File ""/usr/lib64/python3.3/unittest/suite.py"", line 67, in __call__
return self.run(*args, **kwds)
File ""/usr/lib64/python3.3/unittest/suite.py"", line 105, in run
test(result)
File ""/usr/lib64/python3.3/unittest/suite.py"", line 67, in __call__
return self.run(*args, **kwds)
File ""/usr/lib64/python3.3/unittest/suite.py"", line 105, in run
test(result)
File ""/usr/lib64/python3.3/unittest/case.py"", line 529, in __call__
return self.run(*args, **kwds)
File ""/usr/lib64/python3.3/unittest/case.py"", line 477, in run
self._executeTestPart(testMethod, outcome, isTest=True)
File ""/usr/lib64/python3.3/unittest/case.py"", line 422, in _executeTestPart
function()
File ""tests/site_tests.py"", line 1065, in testRandompages
rn = list(mysite.randompages(total=10))
File "".../pywikibot/site.py"", line 3574, in randompages
g_content=content)
File "".../pywikibot/site.py"", line 1357, in _generator
gen = gen_class(type_arg, site=self, **args)
File "".../pywikibot/data/api.py"", line 1100, in __init__
QueryGenerator.__init__(self, generator=generator, **kwargs)
File "".../pywikibot/data/api.py"", line 819, in __init__
self.update_limit() # sets self.prefix
File "".../pywikibot/data/api.py"", line 914, in update_limit
for param in self._modules[mod].get(""parameters"", []):
File "".../pywikibot/data/api.py"", line 865, in _modules
data = paramreq.submit()
File "".../pywikibot/data/api.py"", line 764, in submit
self._data = super(CachedRequest, self).submit()
File "".../pywikibot/data/api.py"", line 535, in submit
self.wait()
File "".../pywikibot/data/api.py"", line 651, in wait
time.sleep(self.retry_wait)
KeyboardInterrupt
<class 'KeyboardInterrupt'>
CRITICAL: Waiting for 1 network thread(s) to finish. Press ctrl-c to abort
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**OS**: Linux
**Platform**: PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72236
https://bugzilla.redhat.com/show_bug.cgi?id=1154641",74009,-38,Needs Triage,True
7.771725445974253,-1.7362041129901993,2.88923693971309,-2.649300635724977,2.135259188711041,0.21592231313153198,0.3323815903315044,-0.8242647707428594,-0.7431153661450002,3.2002644987054625,-1.5905434753808736,2.823490136397872,-1.0714439892378467,-1.4625026115852813,2.524494126087709,-0.48860485619073435,-0.5636733847151634,0.9320777768428259,False,c3,1,"Expected result:
According to the text on https://phabricator.wikimedia.org/auth/start/ it should be possible to login with the Wikipedia account.
Actual Result:
""Username or password are incorrect.""
Additional Information:
My Wikipedia username is ""Hendrik Brummermann"", perhaps the space character is not supported.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",73946,-38,Needs Triage,True
17.378230562521413,-6.101311586304739,0.011395739187687326,-7.397689146250349,-2.000569600111688,4.331948086351471,2.3689759710529144,-1.5580882241525802,-1.9837412986410625,2.4699507592667755,3.5786653623400375,-0.956884850532132,2.3800928779004513,-1.8581266268477399,-2.36107602195077,-0.033500512553429396,1.2430204271095262,0.4390979738878136,False,c3,1,"For example:
* https://kn.wikipedia.org/w/index.php?title=%E0%B2%B8%E0%B3%8D%E0%B2%9F%E0%B2%BE%E0%B2%B0%E0%B3%8D%E2%80%8C%E0%B2%AC%E0%B2%95%E0%B3%8D%E0%B2%B8%E0%B3%8D%E2%80%8C%E2%80%8C&oldid=491660 (WORKS)
* http://parsoid-lb.eqiad.wikimedia.org/knwiki/%E0%B2%B8%E0%B3%8D%E0%B2%9F%E0%B2%BE%E0%B2%B0%E0%B3%8D%E2%80%8C%E0%B2%AC%E0%B2%95%E0%B3%8D%E0%B2%B8%E0%B3%8D%E2%80%8C%E2%80%8C?oldid=491660 (FAILS)
OR
* https://kn.wikipedia.org/w/index.php?title=%E0%B2%B9%E0%B2%BF%E0%B2%AE_%E0%B2%9A%E0%B2%BF%E0%B2%B0%E0%B2%A4%E0%B3%86&oldid=371939 (WORKS)
* http://parsoid-lb.eqiad.wikimedia.org/knwiki/ಹಿಮ_ಚಿರತೆ?oldid=371939 (FAILS)
I have many more examples with different Wikipedias.
--------------------------
**Version**: unspecified
**Severity**: critical",73880,-38,Needs Triage,True
0.24904266496932337,4.585100258794338,-2.1236541461096436,1.909923470287295,-5.723749446480722,-1.5097228190516434,-0.4046277949112369,-0.3341460937240982,-1.100389193197519,-0.8249427298666387,0.030409786847932718,0.05940156612584113,1.2877146913926514,0.5355584814967029,-0.9224976782675025,-0.5233757963004371,0.31239992259347726,-1.6620470481438887,False,c3,1,"If you have a HTTPS only instance of Mediawiki, it's not possible to use OCG directly.
You get this error:
error: Error: Hostname/IP doesn't match certificate's altnames
at SecurePair.<anonymous> (tls.js:1371:23)
at SecurePair.EventEmitter.emit (events.js:92:17)
at SecurePair.maybeInitFinished (tls.js:974:10)
at CleartextStream.read [as _read] (tls.js:462:15)
at CleartextStream.Readable.read (_stream_readable.js:320:10)
at EncryptedStream.write [as _write] (tls.js:366:25)
at doWrite (_stream_writable.js:221:10)
at writeOrBuffer (_stream_writable.js:211:5)
at EncryptedStream.Writable.write (_stream_writable.js:180:11)
at write (_stream_readable.js:583:24) channel=backend.bundler.bin, id=65848afb3f242ab641e6d3f9cb031244c780172d, writer=rdf2latex, details=undefined
error: Bundling process died with non zero code: 1 channel=backend.bundler.error, id=65848afb3f242ab641e6d3f9cb031244c780172d, writer=rdf2latex, metabook={
It should be explained how to get rid of this error in the document. I'm not sure this is relevant to take care about this as in 99% of the instances this run on the same machine like MW. Maybe a simple option (activated per default?) should avoid this check.
I have achieved to get ride of this problem by addingprocess.env.NODE_TLS_REJECT_UNAUTHORIZED = ""0"";
PS: This problem is also valid for Parsoid.
--------------------------
**Version**: unspecified
**Severity**: normal",73797,-39,Needs Triage,False
3.253131754786247,-5.551857201932073,-6.055775714634141,2.931007449222693,-0.5374890064892076,-2.370488970079271,-3.611277769643193,0.05894855554449874,-2.0321805608154695,-2.646704956982971,-0.18870578798895332,-1.074647428420194,4.748145658103692,1.1109556947035744,0.36493871332329064,-1.2987910817354282,0.059813733082328735,0.4194753299101117,False,c3,1,"One of the longstanding issues with Webstatscollector is that it
counts redirects at the HTTP level.
So, for example, requesting:
- a page with a lower case first letter [1],
- a page from the desktop site on a mobile device [2], or
- a www.wikipedia.org/wiki/ path (first part is www, not a language) [3], or
- Special:MyLanguage / Special:Random / Special:RandomRootPage / Special:RandomInCategory, or
- [[https://www.mediawiki.org/wiki/Manual:$wgNamespaceAliases|namespace aliases]], special page aliases and canonical special page names/namespace names
causes two requests to the caches, and webstatscollector counts both,
although actually only a single page is shown to the user.
Thereby too high numbers get reported.
Since we're about the deploy a new webstatscollector anyways, and this
double counting should not be too hard to fix, let's get it fixed too.
(Note that redirects above the HTTP level are not affected. So for example
http://en.wikipedia.org/wiki/Michael_J_Fox
(no dot after the J) is, was and will be one request, although it shows
the content of
http://en.wikipedia.org/wiki/Michael_J._Fox
(dot after the J). Such redirects at Wiki level are not affected.)
[1]
_________________________________________________________________
christian@spencer // jobs: 0 // time: 13:13:36 // exit code: 0
cwd: ~
wget -O /dev/null 'http://en.wikipedia.org/wiki/main_page'
--2014-10-08 13:13:39-- http://en.wikipedia.org/wiki/main_page
Resolving en.wikipedia.org... 91.198.174.192
Connecting to en.wikipedia.org|91.198.174.192|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://en.wikipedia.org/wiki/Main_page [following]
--2014-10-08 13:13:39-- http://en.wikipedia.org/wiki/Main_page
Reusing existing connection to en.wikipedia.org:80.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/dev/null'
[ <=> ] 67,779 --.-K/s in 0.1s
2014-10-08 13:13:39 (472 KB/s) - `/dev/null' saved [67779]
[2]
_________________________________________________________________
christian@spencer // jobs: 0 // time: 13:13:39 // exit code: 0
cwd: ~
wget -O /dev/null --user-agent 'iPhone' 'http://en.wikipedia.org/wiki/Main_Page'
--2014-10-08 13:13:44-- http://en.wikipedia.org/wiki/Main_Page
Resolving en.wikipedia.org... 91.198.174.192
Connecting to en.wikipedia.org|91.198.174.192|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://en.m.wikipedia.org/wiki/Main_Page [following]
--2014-10-08 13:13:44-- http://en.m.wikipedia.org/wiki/Main_Page
Resolving en.m.wikipedia.org... 91.198.174.204
Connecting to en.m.wikipedia.org|91.198.174.204|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/dev/null'
[ <=> ] 22,002 --.-K/s in 0.05s
2014-10-08 13:13:44 (416 KB/s) - `/dev/null' saved [22002]
[3]
_________________________________________________________________
christian@spencer // jobs: 0 // time: 13:13:44 // exit code: 0
cwd: ~
wget -O /dev/null 'http://www.wikipedia.org/wiki/Main_Page'
--2014-10-08 13:13:49-- http://www.wikipedia.org/wiki/Main_Page
Resolving www.wikipedia.org... 91.198.174.192
Connecting to www.wikipedia.org|91.198.174.192|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://en.wikipedia.org/wiki/Main_Page [following]
--2014-10-08 13:13:49-- http://en.wikipedia.org/wiki/Main_Page
Resolving en.wikipedia.org... 91.198.174.192
Reusing existing connection to www.wikipedia.org:80.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/dev/null'
[ <=> ] 67,565 --.-K/s in 0.1s
2014-10-08 13:13:49 (471 KB/s) - `/dev/null' saved [67565]
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72102",73790,-39,Needs Triage,True
1.6139249355086362,-1.5533388193654698,1.312599334234541,-6.086146946762182,-3.0572283125000532,-1.2993994664609887,1.332524133748377,-2.2641191425832483,0.8579823510175983,0.6383455464535217,1.913673502619853,-0.9764050151458195,1.698568550022168,-0.06225255455172363,-1.146747955607994,1.5144813564077768,-0.594653891045977,-1.4980640871416513,False,c3,1,"Duplicate error messages
Navigate to Special:Watchlist whilst not logged in
You get two messages.
Expected:
You should just get the first styled message
We should look to consolidate our own custom code with that in core...
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F15097}",73771,-39,Needs Triage,True
-4.244247077361454,0.6470887435688439,4.03751569499774,3.4423438954477144,1.0590126984418335,3.684209516927739,0.5136510816973496,-1.341758777256448,3.1826534806925846,-0.02062538251888757,1.2279348716724798,-1.7096708944165937,1.4152897199577628,-0.23481933857438442,2.457938916339484,0.31235550398974354,0.9935912300360334,-2.186374687574733,False,c3,1,"Another case with the root of bug 70468. The fix should be the same as we did for the web interface-- pass $checkHome = true to the merge function.
--------------------------
**Version**: master
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70468",73749,-39,Needs Triage,True
2.191532064793439,-7.03913965880144,2.019871843867996,8.02457016730192,-0.7821581950357733,-5.622873505108989,2.877023316454866,2.226561943566051,3.5800408304289686,1.2252295979995331,0.676024982685302,1.4885076689974561,1.29134028806428,1.1685316830288635,-0.9552985335127024,0.6645014366441617,2.5323363557072858,-0.15755355707291252,False,c3,1,"no mw-ui buttons
On beta labs, login and create account pages doesn't use mw-ui submit buttons (input still mw-ui).
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&type=signup&campaign=loginCTA
--------------------------
**Version**: 1.25-git
**Severity**: normal
**Attached**: {F14704}",73618,-39,Needs Triage,True
5.695202509564064,-13.876667070253907,-3.4215747899227704,-0.9309850203515095,-0.2905224024698084,2.917837220811606,3.1792149356178347,-0.2742245444837847,-3.4884029031471924,-0.7526631186431199,-0.010789748187644665,3.537501841566047,2.2285121900091225,2.231668767378398,2.4426163416671054,-0.38894229356724763,0.16898313786311858,0.33492605794333374,False,c3,1,"http://en.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin
is 503
--------------------------
**Version**: unspecified
**Severity**: critical",73532,-40,Needs Triage,True
2.952252233387942,-5.903712780240085,-2.8182784434032246,10.45722270762111,-2.5028330657640017,-6.465749260281975,-0.8869593721658191,-1.4218142790691255,0.001737008974641241,0.024316720092905975,-1.6305185548641703,-0.3785781384956003,0.8164806346386908,-1.3889821461047251,-1.0301650778834723,-0.2896015657605011,-1.1479669107968316,-0.5133530730667237,False,c3,1,"When trying to get() an item from wikidata I get the following SSL related error:
ERROR: Traceback (most recent call last):
File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit
headers=headers, body=body)
File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper
return method(*__args, **__kw)
File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request
raise request.data
SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
To reproduce:
import pywikibot
repo = pywikibot.Site().data_repository()
item = pywikibot.ItemPage(repo, 'Q4115189')
item.get()
--------------------------
**Version**: core-(2.0)
**Severity**: normal",73497,-40,Needs Triage,True
-3.22178314041908,-4.473785174543883,6.032667102275756,4.016067949596855,1.9608502154359702,1.2372053091846629,2.5416333915545506,-2.7830106650308517,-0.7196472191690026,0.17965032991552565,0.7665411151554569,2.6132074303736736,0.15338562161837643,-0.7757142171734088,-1.215352857176332,2.036352477202984,2.9324078151203006,1.6787253885686624,False,c3,1,"Visit http://en.wikipedia.beta.wmflabs.org/wiki/Special:Watchlist (desktop) and you are redirected to the login form.
Do the same on mobile and no redirect.
http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Watchlist
--------------------------
**Version**: unspecified
**Severity**: normal",73206,-41,Needs Triage,True
7.754656248414172,-12.295668925644208,7.133676864191646,6.21044543870737,-0.7651637521469061,-3.0901934302281457,1.6964019028119512,-2.0145419384168313,0.545430110221807,-1.236535095205249,-0.975100115498055,-0.047358119716736535,1.020327136120891,-0.6861318068125959,-0.024252014145218936,-0.15225399207290946,-0.08625390945130573,-0.4253079120997776,False,c3,1,"**Author:** `ramya.s`
**Description:**
login
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC
**URL**: http://www.ereceivablemanager.com/meritoruat/",72992,-41,Needs Triage,True
3.7394800863885256,-7.522767085133559,-8.272176838200796,5.938409062703423,0.003349901201937011,-6.907661449295559,-4.57045214106429,-1.6669445449638012,-0.6170643178372143,6.64708382038183,-4.585856828575395,0.4499162931344456,-0.6502792609178023,-0.23087004257961397,-0.12047250870195825,-0.2634356350701248,0.9815578738969191,-1.610750237432332,False,c3,1,"would you please add this patch for compat?
https://gerrit.wikimedia.org/r/#/c/160189/
Now when i edit claims it crashes and show this token error
File ""/home/reza/compat/wikipedia.py"", line 4799, in editclaim
raise RuntimeError(""API query error: %s"" % data)
RuntimeError: API query error: {u'servedby': u'mw1191', u'error': {u'info': u""The 'token' parameter must be POSTed"", u'code': u'mustposttoken'}}
--------------------------
**Version**: compat-(1.0)
**Severity**: normal",72820,-42,Needs Triage,
8.612798453090798,0.7965911869550997,-3.1713974424538662,-0.8021746904322503,-2.8575271778091453,-1.3296846172914185,-0.8595743069328794,-3.138578626571148,0.5070578608865289,-1.7365651417709884,-1.32809567236145,-1.2476276814783482,0.18613339204425028,-1.8958302189238498,-1.524407351561802,-1.0821597295943182,0.15637240306970468,-1.0312751192195027,False,c3,1,"**Author:** `vichak`
**Description:**
The error when you use self signed certificate is the following :
Page Fetch failure for ""https://myhost/api.php"": Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE
DoesNotExistError: Page Fetch failure for ""https://myhost/api.php"": Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE
at ApiRequest._requestCB (/usr/lib/parsoid/src/lib/mediawiki.ApiRequest.js:153:15)
at self.callback (/usr/lib/parsoid/node_modules/request/request.js:121:22)
at Request.emit (events.js:95:17)
at ClientRequest.self.clientErrorHandler (/usr/lib/parsoid/node_modules/request/request.js:230:10)
at ClientRequest.emit (events.js:95:17)
at CleartextStream.socketErrorListener (http.js:1547:9)
at CleartextStream.emit (events.js:95:17)
at SecurePair.<anonymous> (tls.js:1386:19)
at SecurePair.emit (events.js:92:17)
at SecurePair.maybeInitFinished (tls.js:979:10)
I push a code review on https://gerrit.wikimedia.org/r/#/c/159811/2
But this not working...
It need to offer the strictSSL option of request module. I found this option on https://github.com/mikeal/request
I hardcoded strictSSL to false in my production server...
I wanted to share this.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64003",72761,-42,Needs Triage,True
-1.353745716820072,5.554106195229171,-1.647114892932656,-1.5365331410230114,-1.8775280761556699,-3.193552953586571,1.6528077626660007,1.2061590685575374,0.4265294220205138,-1.3367691451008792,-0.7535663197029181,0.35466337043513985,0.30616297002642145,-0.6365132335858403,-0.24831494620353567,-1.250978628306826,0.012551634846103443,-1.843033278507849,False,c3,1,"HTTPs delivery for OSM tiles currently results in certificate problems.
If URLs like https://c.tiles.wmflabs.org/hikebike/4/8/4.png are used to deliver the tiles it gives a certificate error.
We already had this on Toolserver and I discovered that the wildcard *.wmflabs.org SSL certificate does not cover c.tiles.wmflabs.org.
This is because sub - sub - domains are not handled by wildcard ssl certs.
So the best way to solve this problem would be to use different host names like tiles-c.wmflabs.org so you have only one sub domain.
We need this to be done quite soon because otherwise we cannot switch the whole OSM stuff from Toolserver to Toollabs.
--------------------------
**Version**: unspecified
**Severity**: normal",72680,-43,Needs Triage,True
10.917086293841582,0.41829600456102334,4.833935705689818,-3.4306539469790516,1.486741556669732,-0.6177543747775882,1.0216898081661565,-0.10984685734443356,-1.5694956892699878,-0.8000834173738718,-0.19158872922895398,2.4880931616065736,0.802340725412237,-1.919461256436601,-1.606625128595676,-0.474305977155125,1.3831231772095485,0.934543928057811,False,c3,1,"While investigating T70521 today, me and Helder noticed that user-created CSS is loaded on Special:Preferences and Special:UserLogin. Both special pages call `$out->disallowUserJs()`, which only controls `TYPE_SCRIPTS`, not `TYPE_STYLES` or `TYPE_COMBINED`.
Is this a bug? Or is it safe for CSS to run on those pages?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
* {T73007}
* {T73621}",72672,-43,Needs Triage,True
-2.047889817453173,-2.950046939632676,-0.02448217067762215,1.2433137540376444,2.0959035876678906,4.062921473703578,-3.280477691516133,-1.1485060872002064,-2.9723486230649856,-3.6711062657488247,1.663788831269383,-2.899073008495746,1.7975327014854634,0.3603431296179602,4.12464259938107,-1.6492850868301272,1.8864260744682249,-0.4878442299531893,False,c3,1,"I was on
https://bugzilla.wikimedia.org/show_bug.cgi?id=68521
and clicked in the link [[Special:UserLogin]] which appears in the bug title. This loaded a page like
https://en.wikipedia.org/wiki/Special:CentralLogin/complete?token=<some token>
which was a mostly blank page, containing just this:
[99330200] 2014-09-10 17:57:56: Fatal exception of type MWException
--------------------------
**Version**: unspecified
**Severity**: normal",72666,-43,Needs Triage,True
4.854628171050482,-2.28103064414492,-3.7454664692473774,6.201309219354388,-4.256964069373378,-5.43653417690977,-3.7346653059390262,-0.1933296208216117,-1.432186861760309,1.8814439439123367,-0.9566747891827827,0.41064360291860247,0.040442179430709047,0.7317529175538358,1.7386677963778432,-0.1429908700443916,-0.5187877077411469,0.4105994831368156,False,c3,1,"After deleting password.lwp, it was unable to login with right username and rights.
Move action then fails.
To recover, I tried replace.py, who asked for a password, and then movepages.py was OK again.
Looks like replace.py has superpowers compared to movepages.py
user@pc:~/python/core {master}$ python scripts/movepages.py -pairs:pairs.txt -summary:""Bot request: move after Index move"" -noredirect -pt:0
Moving page [[Page:Ackermann’s Repository of Arts 1809-v01-Jan-Jun.djvu/1]] to [[Page:Repository of Arts, Series 1, Volume 01, 1809, January-June.djvu/1]]
WARNING: API warning (tokens): action=tokens has been deprecated. Please use action=query&meta=tokens instead.
Action 'move' is not allowed for the current user
Traceback (most recent call last):
File ""scripts/movepages.py"", line 283, in <module>
main()
File ""scripts/movepages.py"", line 271, in main
bot.moveOne(page, pair[1])
File ""scripts/movepages.py"", line 80, in moveOne
deleteAndMove=self.getOption('noredirect'))
File ""/home/user/python/core/pywikibot/tools.py"", line 315, in wrapper
return method(*__args, **__kw)
File ""/home/user/python/core/pywikibot/page.py"", line 1458, in move
noredirect=deleteAndMove)
File ""/home/user/python/core/pywikibot/site.py"", line 3606, in movepage
token = self.tokens['move']
File ""/home/user/python/core/pywikibot/site.py"", line 1168, in __getitem__
storage = self.site._tokens.setdefault(self.site.user(), {})
KeyError: 'move'
<type 'exceptions.KeyError'>
CRITICAL: Waiting for 1 network thread(s) to finish. Press ctrl-c to abort
--------------------------
**Version**: core-(2.0)
**Severity**: normal",72447,-43,Needs Triage,True
8.803276567812727,-4.1544851167604,2.4557789790494198,-2.3213263191424227,-5.418241125087963,1.0529435843778934,-5.225938586036727,-1.062932834510286,-1.0537503826167374,-4.014454063019289,2.4234400458865353,-0.10744692642638265,-0.5385757661519426,1.2278913655153092,5.015669685563185,-0.32607705186725566,0.9097059791739388,-0.48584872818496483,False,c3,1,"**Author:** `swalling`
**Description:**
Steps to reproduce:
1. Be logged in
2. Go to a wiki (in my case, Meta)
3. Search for Special:UserLogin
URL was https://meta.wikimedia.org/wiki/Special:CentralLogin/complete?token=be24f4fe571415dbff35a66c7681c1d4
Error produced was: [d87ff559] 2014-09-04 04:37:35: Fatal exception of type MWException
--------------------------
**Version**: unspecified
**Severity**: normal",72381,-43,Needs Triage,True
-3.2257826186075365,-4.561321249907891,1.9647243500657332,3.83234736620376,-1.3756682112696548,-3.6138761247984856,0.6224689630993643,1.1645933760724332,-0.7648171212539401,-2.688500681719598,-1.1576653713641025,-3.942322606493117,3.6032410939136956,1.758363688904021,1.4756738687335718,-1.6161077161385293,-0.34318701544526253,0.2329936766285574,False,c3,1,"When migrating webstatscollector's filter process from erbium to
oxygen on 2014-07-07 for bug 67456, it seems an old filter binary got used
and effectively the CentralAutoLogin requests got counted again.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57980",72295,-44,Needs Triage,True
-4.238425666784209,8.904350497678543,0.042576934394841004,5.039196401690139,-6.046536345176415,1.1914349066137004,2.0867632371474416,2.672877192821375,-2.596912424527514,-2.089562644928019,-2.6473703918555747,-4.901970581055045,-1.0331008123435605,0.18251082250055095,-2.451501751189475,-0.13298513857502936,-0.13441414041494038,-0.8054661881828713,False,c3,1,"HTTPS requests end up twice in the udp2log pipeline for all
data-centers. Once from directly from the nginx-s, once from the
varnishes. For ulsfo, both entries in the log line get counted by
webstatscollector, leading to double counting of ulsfo https traffic.
--------------------------
**Version**: unspecified
**Severity**: normal",72140,-44,Needs Triage,True
12.012704582191482,-1.386632200064824,-0.33605567506224787,3.689859509766631,-2.0912284771277996,-1.1824644638206143,-1.6417969842802727,0.4873853471587648,0.5038231162041836,6.435687951453328,-1.086517719962521,0.5562159932960129,-0.6686917106932873,1.2082580989430785,-0.8502803191770125,-1.4654115439088462,1.050601786488089,-0.8705101721880382,False,c3,1,"Since parsoid doesn't seem to take the environment variable http_proxy into account the following fails:
$ env | grep prox
http_proxy=http://proxy:80/
$ npm test
...
{ [DoesNotExistError: Page Fetch failure for ""http://en.wikipedia.org/w/api.php"": Error: connect ECONNREFUSED]
name: 'DoesNotExistError',
message: 'Page Fetch failure for ""http://en.wikipedia.org/w/api.php"": Error: connect ECONNREFUSED',
code: 404 }
--------------------------
**Version**: unspecified
**Severity**: normal",71982,-45,Needs Triage,True
10.241654413506149,-3.544883237451847,8.403067889237231,8.225260565219646,-1.9384342531431118,-2.4179711696472825,2.226604928108787,-1.612712828361726,1.6843586587463835,-0.42829124713436606,0.11191909753459228,1.0048436346322622,-0.97177315380641,-1.0661887357106767,-0.5533880036757237,-1.1294432600130226,1.1906364238133926,-1.109301874387476,False,c3,1,"**Author:** `jens.roebel`
**Description:**
This code:
<rss max=4 highlight=""community wiki foundation"">http://blog.wikimedia.org/feed/</rss>
Gives this result:
Failed to load RSS feed from http://blog.wikimedia.org/feed/: HTTP-forespørgslen fejlede af ukendte årsager.
Any ideas?
Thanks
Jens Roebel
--------------------------
**Version**: REL1_23-branch
**Severity**: normal
**Whiteboard**: aklapper-moreinfo",71783,-46,Needs Triage,True
0.24873998272443654,-0.8348057976393441,3.5851985042582477,7.007445797513569,0.49593915077027173,-0.17692346360241762,2.12099503180142,-0.41715968704007506,2.1826360416040265,-1.7840045698334905,-2.2941792586614147,-0.12593009316299586,-1.9734427672813784,0.8019723061004944,-0.36024506277975377,-2.6214557040043016,-0.6362386704715802,-1.1947750352130595,False,c3,1,"When GoogleLoign installed, wgAuth breaks the use of the webinstaller to update database schema.
--------------------------
**Version**: master
**Severity**: normal",71564,-46,Needs Triage,True
0.11461793454953328,-6.969237846435563,-4.644620863311619,8.02824494522493,-3.505621454183916,-4.3245009013073386,-2.140925936681897,-0.8152580362169539,-0.8789609338952529,1.3669026500161996,-3.194388283295219,-0.6190667965970164,2.2707674819518058,-1.0150807832129551,0.07085569885039078,0.9262465477413662,-1.287506707050569,-0.6767052686941233,False,c3,1,"This is probably due to recent changes in the user agent string.
File ""core/pywikibot/data/api.py"", line 337, in submit body=paramstring)
File ""core/pywikibot/comms/http.py"", line 164, in request
username=quote(username),
File ""/usr/lib/python2.7/urllib.py"", line 1268, in quote
return ”.join(map(quoter, s))
KeyError: u'\u05e2'
--------------------------
**Version**: unspecified
**Severity**: normal",71354,-47,Needs Triage,True
0.22584516137683774,-0.9247492982068497,-7.696693540811509,2.1345049795513615,-1.272473963529711,-4.481447125235509,-7.0274083102075835,-0.9939937715062144,-4.762227305011786,8.243260004654221,-4.84558532100831,1.8059799668207475,-2.729840858130663,1.4475925892479884,-0.891872593365683,-0.570374504983072,1.1420612275252127,-2.0215563310282154,False,c3,1,"With this settings in user_config.py:
usernames['wikipedia']['*'] = u'Mpaa'
cannot login, while it can with:
usernames['wikipedia']['en'] = u'Mpaa'
The try clause in login.py fails because self.site.code is 'en' and not '*'.
KeyError is raised (BTW it should be except KeyError ....)
try:
self.username = config.usernames[
self.site.family.name][self.site.code]
except:
raise NoUsername(u""""""\
ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.
If you have an account for that site, please add a line to user-config.py:
usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'""""""
% {'fam_name': self.site.family.name,
'wiki_code': self.site.code})
--------------------------
**Version**: core-(2.0)
**Severity**: normal",71342,-47,Needs Triage,True
-1.8358633782761982,-0.9272992378626217,-1.9779605164524998,-3.8065767440944525,-3.7686154622415335,1.8413024891673049,0.9526069357133373,-0.9810326552637497,4.500603831125672,0.7656811850314433,-1.2572885492591153,-0.8465342775779057,-1.536506313261837,1.1791334224064052,2.732158525423304,-0.7959984608741204,-0.21800070497852309,0.13209731471892927,False,c3,1,"With MW 1.23 a new Configuration class was implemented to access configuration variables/options instead of using ""global $wg..."":
https://www.mediawiki.org/wiki/MediaWiki_1.23#Configuration
Extension developers can use/create it's own instance of this, like explained here:
https://www.mediawiki.org/wiki/Manual:Configuration_for_developers
to use the advantage of this new implementation, too. Let's try it!
--------------------------
**Version**: master
**Severity**: normal",71086,-48,Needs Triage,True
18.88438848113306,-3.948222254283543,-13.69431468169613,3.750145791409805,-0.8555935310267997,-3.2447872255857,-4.4817570409427825,-0.49715880494808085,-2.2432683978559824,-4.844982010278226,-0.95246490860879,-1.2583648909644694,9.98928767264532,6.217038978192576,3.666991409941489,-0.3446945482545143,0.09246899869788727,-0.028068736445502118,False,c3,1,"Alex, can you help me please? :-)
Notice: Did not find alias for special page 'ClientSSL'. Perhaps no aliases are defined for it? [Called from SpecialPageFactory::getLocalNameFor in /srv/vagrant/mediawiki/includes/specialpage/SpecialPageFactory.php at line 597] in /srv/vagrant/mediawiki/includes/debug/MWDebug.php on line 303
Call Stack:
0.0007 253072 1. {main}() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:0
8.4779 60010472 2. MediaWikiPHPUnitCommand::main() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:160
8.4780 60022936 3. PHPUnit_TextUI_Command->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiPHPUnitCommand.php:42
45.7278 275865408 4. PHPUnit_TextUI_TestRunner->doRun() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:176
45.7496 276180680 5. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php:350
46.0237 276182912 6. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
857.7910 468000136 7. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
858.0793 470697832 8. PHPUnit_Framework_TestSuite->runTest() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:749
858.0793 470697832 9. MediaWikiTestCase->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:779
858.0819 470698000 10. PHPUnit_Framework_TestCase->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiTestCase.php:133
858.0820 470698000 11. PHPUnit_Framework_TestResult->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:783
858.0821 470698944 12. PHPUnit_Framework_TestCase->runBare() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestResult.php:648
858.1496 471410880 13. PHPUnit_Framework_TestCase->runTest() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:838
858.1496 471411656 14. ReflectionMethod->invokeArgs() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:988
858.1496 471411992 15. ApiOptionsTest->testReset() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:988
858.1499 471417136 16. ApiOptionsTest->executeQuery() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiOptionsTest.php:233
858.1500 471417400 17. ApiOptions->execute() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiOptionsTest.php:151
858.1622 471424856 18. Preferences::getPreferences() /srv/vagrant/mediawiki/includes/api/ApiOptions.php:75
859.2275 471897512 19. wfRunHooks() /srv/vagrant/mediawiki/includes/Preferences.php:99
859.2275 471897560 20. Hooks::run() /srv/vagrant/mediawiki/includes/GlobalFunctions.php:4031
862.0529 473359440 21. call_user_func_array() /srv/vagrant/mediawiki/includes/Hooks.php:206
862.0529 473359936 22. efClientSSLAddPrefsLink() /srv/vagrant/mediawiki/includes/Hooks.php:206
862.0568 473361048 23. Linker::link() /srv/vagrant/mediawiki/extensions/SSLClientAuthentication/ClientSSLAuth.php:172
862.0581 473362880 24. Linker::normaliseSpecialPage() /srv/vagrant/mediawiki/includes/Linker.php:218
862.0582 473362928 25. SpecialPage::getTitleFor() /srv/vagrant/mediawiki/includes/Linker.php:459
862.0582 473362928 26. SpecialPageFactory::getLocalNameFor() /srv/vagrant/mediawiki/includes/specialpage/SpecialPage.php:70
862.0596 473363216 27. wfWarn() /srv/vagrant/mediawiki/includes/specialpage/SpecialPageFactory.php:597
862.0596 473363416 28. MWDebug::warning() /srv/vagrant/mediawiki/includes/GlobalFunctions.php:1189
862.0598 473364888 29. MWDebug::sendMessage() /srv/vagrant/mediawiki/includes/debug/MWDebug.php:157
862.0598 473365224 30. trigger_error() /srv/vagrant/mediawiki/includes/debug/MWDebug.php:303
--------------------------
**Version**: master
**Severity**: normal",71016,-48,Needs Triage,True
-1.1372065258947122,-4.626454656898803,-4.798805017531233,4.634423278064023,1.121078723600327,-5.691942042639852,-4.885943256757239,-2.4081576568179464,-2.291903238539776,6.157385698782299,-3.4868472888532094,-0.2693958101443117,-0.9735720461006325,0.13923517436133537,-0.6843233860558282,-0.5357377900034086,1.1881898300632339,-1.36527635901074,False,c3,1,"**Author:** `ian`
**Description:**
Running a simple pywikibot script gives error that my server has an invalid certificate, then it retries, and seems to ignore that issue and succeeds.
In the error, it reports the certificate for a different domain that my server also hosts, probably because either 1. it is the domain used for reverse dns, or 2. it is the domain which my server redirects to for urls containing the ip address.
Pywikibot should get the certificate for the domain I configured it to use. Here is the error output.
ERROR: Traceback (most recent call last):
File ""/root/opt/pywikibot/pywikibot/data/api.py"", line 298, in submit
body=paramstring)
File ""/root/opt/pywikibot/pywikibot/comms/http.py"", line 174, in request
raise request.data
CertificateHostnameMismatch: Server presented certificate that does not match host ofswiki.org: {'notAfter': 'May 23 20:21:24 2015 GMT', 'subjectAltName': (('DNS', 'www.iankelling.org'), ('DNS', 'iankelling.org')), 'subject': ((('description', u'0NEmhfbNSxh2R2RF'),), (('countryName', u'US'),), (('commonName', u'www.iankelling.org'),), (('emailAddress', u'REDACTED-AT-iankelling.org'),))}
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65189
https://github.com/jcgregorio/httplib2/issues/243",70794,-49,Needs Triage,True
1.3700682438914238,-2.770014075939983,4.201450653159185,0.6264274075512524,5.433741708049716,-0.28420955412529314,0.06182529951748528,0.4705318322654718,3.332520225090346,-3.4016362506201205,-3.770638730042755,-1.1929235373520823,-2.6994076206596676,1.0381135795189094,1.16578108158357,0.40690854772228696,-1.4426522978823255,-0.599162306018516,False,c3,1,"The GoogleID connected with the user is a setting, so maybe move it to preferences.
--------------------------
**Version**: master
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68726",70727,-49,Needs Triage,True
8.697683113064206,-6.5535471516002,-2.743602457530386,7.104311207794408,-0.6393142162678846,-3.7549627403836494,0.8743468111633046,-0.12754609588082588,0.33103203746214716,-0.8804660547479233,0.7666663943895689,0.5021693712569311,3.088653104441482,-1.9879838117239101,-1.1565333893795877,2.106488457442882,3.4179672233122984,3.699979092873816,False,c3,1,"**Author:** `metatron`
**Description:**
Current Lighttpd seems to be compiled with lua-support option ( --with-lua), but mod_magnet.so is missing.
Pls install/add mod_magnet.so
Refs:
http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModMagnet
(plugin.c.169) dlopen() failed for: /usr/lib/lighttpd/mod_magnet.so /usr/lib/lighttpd/mod_magnet.so: cannot open shared object file: No such file or directory
@tools-webgrid-04:~$ lighttpd -V
lighttpd/1.4.28 (ssl) - a light and fast webserver
Build-Date: Dec 20 2011 14:36:55
Event Handlers:
+ select (generic)
+ poll (Unix)
- rt-signals (Linux 2.4+)
+ epoll (Linux 2.6)
- /dev/poll (Solaris)
- kqueue (FreeBSD)
- libev (generic)
Network handler:
+ sendfile
Features:
+ IPv6 support
+ zlib support
+ bzip2 support
+ crypt support
+ SSL Support
+ PCRE support
+ mySQL support
+ LDAP support
+ memcached support
+ FAM support
+ LUA support
+ xml support
+ SQLite support
+ GDBM support
--------------------------
**Version**: unspecified
**Severity**: normal",70614,-49,Needs Triage,True
11.242519706665183,-6.572727804410542,-0.5462059609538183,-4.637823681644287,0.30031751302052756,0.9262300645019252,2.033141720491776,1.8434480009565202,-2.567015927436519,0.3402613641288097,1.0333387382099501,1.8711704008238563,1.6181166131649518,-2.460472794397947,-1.362077832474367,0.24298463888004176,0.6414453488457699,-0.902918814096527,False,c3,1,"My global JS is being loaded at
http://meta.wikimedia.beta.wmflabs.org/wiki/Special:Preferences
http://meta.wikimedia.beta.wmflabs.org/wiki/Special:UserLogin
http://deployment.wikimedia.beta.wmflabs.org/w/index.php?title=Special:Preferences
http://deployment.wikimedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin
This does not happens with common.(js|css) and skin specific (js|css).
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
* {T24929}
* {T50931}
* {T73007}",70521,-49,Needs Triage,True
0.7232399927282027,2.505521806869229,1.556746345916249,-1.577071439971295,-2.4629995913510685,-1.17393347234115,0.3980473389357906,-0.05222249743769419,-0.40331026088430566,0.049370356541295735,0.6827819937509862,1.1117760604398568,2.417450027205409,-0.7941244602107744,-1.5558261197617167,-1.7448662847792709,-0.8601255296615743,0.06707313050496633,False,c3,1,"**Author:** `neilk`
**Description:**
Bug noted on Mac OS X 10.9.3, using Vagrant 1.6.3 and Virtualbox 4.3.12. As per the standard vagrantfile, it was using a static IP and nfs.
Many things in MediaWiki require it to make calls to external APIs. It seems that when hhvm is on, CurlHttpRequest::execute always times out. I noticed this with uploads particularly.
Enabling the zend role fixed the problem, so it seems to be specific to hhvm.
Problems that I noticed:
* when using instantCommons, uploads always time out. The reason is because MediaWiki is checking to see if the upload is already on Commons, and the request times out.
* when using UploadWizard (or other upload-by-url pages) to get files from Flickr, the request always times out, because Flickr API requests are timing out.
To see this behavior:
$ vagrant enable-role hhvm
$ vagrant enable-role uploadwizard
If change 148505 (https://gerrit.wikimedia.org/r/#/c/148505/) hasn't landed yet, make sure to add the following to your LocalSettings, to allow the kinds of uploads I mentioned.
$wgInstantCommons = true;
$wgAllowCopyUploads = true;
$wgGroupPermissions[""*""][""upload_by_url""] = true;
Then, you can try using UploadWizard to:
- Upload any image file
- Upload any file from an appropriately licensed Flickr URL (https://www.flickr.com/photos/brevity/10423091326/ is fine; if you need more use the advanced search to find CC-BY and CC-BY-SA files).
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
**Platform**: Macintosh",70489,-50,Needs Triage,True
5.60198428079652,-2.1084659280165265,-0.7391569055406357,0.3357817552667932,-3.439820050610931,-2.2703937276557653,0.27905558623095317,-3.356058068087168,2.303428388670957,-0.9054427810664922,-0.8198362678028412,1.9499149919712238,0.7323013930311242,-0.5530942883782224,-0.6749228843732942,-0.6622137306754631,-0.21841645060507053,1.5704578025581715,False,c3,1,"**Author:** `metatron`
**Description:**
According to:
https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help/Performance#Webservice_stalling.2C_OOM_or_otherwise_unresponsive
I'm going to submit a patch, but would like to test it on one webgrid node in advance (preferred tools-webgrid-04)
https://tools.wmflabs.org/paste/view/763db0fb
Additional:
Is /usr/bin/webservice script puppetized?
--------------------------
**Version**: unspecified
**Severity**: normal",70431,-50,Needs Triage,True
-3.1888542846006507,6.765754370098886,12.197890061021717,9.429406126135945,-3.4695708193966497,0.06153782723566947,1.7271978384643063,-1.8133498843133662,0.0658230084044058,-2.556409149408719,-3.961006839309853,5.1950504172012275,-2.8988850412000478,0.46676358698009235,1.5788332604743687,3.33748360275618,-0.0676542073026194,-0.02375949474396788,False,c3,1,"This is a feature request to have longpresses on hyperlinks that are on Wikipedia domains show as HTTPS in the flyup and use HTTPS in the flyup menu targets.
--------------------------
**Version**: Beta
**Severity**: enhancement",70330,-50,Needs Triage,True
-3.206680353395426,3.240789062295409,-2.373139469248816,-0.7178529854583516,2.647795912843512,1.5793920349933204,1.3115537238499817,3.844564886269578,-2.805603703735793,0.9984310822321305,-1.2771171450982197,-0.2775500772414129,-0.7396562624826739,-0.23727194253793016,-0.1990562199757102,1.205483892329446,-0.1089248170785091,-1.39635622856667,False,c3,1,"**Author:** `mluxen`
**Description:**
A new Wiki user is created and linked to a Google account. If this user is now deleted by UserMerge extension the reference within the user_google_user table doesn't match as it's not deleted automatically by another extension (UserMerge in this case).
Afterwards it's not possible to login again another/new user until the whole table is deleted or this specific user entry. The user is always redirected to the main wiki page with status ""not login"". That means ""Login"" is still available in the upper right corner of MW.
The table must be created again if it's deleted completely in the step before.
--------------------------
**Version**: master
**Severity**: normal",70317,-50,Needs Triage,True
1.4653862601852832,-5.281129102388499,3.798535582869061,-0.6456063088484927,-8.54539014547981,-0.41988674234478074,-5.767943249206424,-0.18531369970770228,-0.0693555675221928,1.3030853597274223,0.8545408284439069,-0.7709614729622278,0.5864174041872805,1.5005887180621604,2.6132625846853115,-2.3908611497421854,-0.10159002824634067,-0.8695669914213655,False,c3,1,"1) Go to http://en.wikipedia.beta.wmflabs.org/wiki/special:ContentTranslation while logged out
2) Go to http://en.wikipedia.beta.wmflabs.org/wiki/Special:ContentTranslation
Observed: 1) wikicode 2) ""null""
--------------------------
**Version**: master
**Severity**: normal",70093,-51,Needs Triage,True
3.73200870212372,-1.7923729421777352,-0.5555875925109124,3.025640961694412,-0.5377769313980896,1.4787356595305996,0.22747123888318566,-0.464296859249252,-2.3205474885211785,-1.1493400069953856,-1.0748113160690835,0.6069470714094947,2.5598278149913396,0.7334427280098037,-0.28171827387706383,-2.262544172590722,0.31347492313711456,1.9828309463209195,False,c3,1,"using https://github.com/dhbaird/easywsclient , with the URL adapted to
ws = WebSocket::from_url(""ws://stream.wikimedia.org/rc"");
results in
easywsclient: connecting: host=stream.wikimedia.org port=80 path=/rc
ERROR: Got bad status connecting to ws://stream.wikimedia.org/rc: HTTP/1.1 404 Not Found
which is distinct from Bug 66989 (which uses a socketio specific library, and which reports 502's)
--------------------------
**Version**: wmf-deployment
**Severity**: normal",69955,-51,Needs Triage,True
4.304908944512025,-0.6857076252323662,-3.4164490712436493,-9.227296507532078,3.1756165312081617,-5.695415663686205,2.8235453434013325,-2.518122798661361,2.2948349288669414,0.8038063688898278,1.5165556488561474,-1.2367683428758365,0.0769021464541213,0.8733946952494511,-2.370247653087295,0.45714750755009786,2.0544067864881104,0.31824845207319785,False,c3,1,"https://gerrit.wikimedia.org/r/Documentation/rest-api.html loads:
* http://cdnjs.cloudflare.com/ajax/libs/prettify/r298/prettify.min.js
* http://cdnjs.cloudflare.com/ajax/libs/prettify/r298/prettify.min.css
cdnjs.cloudflare.com supports HTTPS, so I think we should change the protocol to HTTPS, or remove them entirely because I don't see any visual difference between loading them or not.
--------------------------
**Version**: unspecified
**Severity**: normal",69667,-52,Needs Triage,True
-6.214280913012626,1.223726151092448,-3.6484028360975813,1.926833703449728,-0.7213343271162603,-2.0795252127969137,0.06443783379751356,0.9922823583698982,0.31237396137287066,-1.4670944838283737,1.3138895249180949,-1.483260878054325,1.0451561984149178,-0.41279007450639416,-0.6524448907529292,-0.5361459308759341,-0.6909141048937338,-0.16714220617625752,False,c3,1,"When emery got decomissioned, erbium around mid-April 2014 had it's
udp2log instance turned from a multicast consumer into a consumer of
only varnishncsa. Hence, since then, erbium only receives logs for the
traffic the ssl terminators cause on the caches, but not the logs for
traffic arriving at the ssl terminators.
However, to correctly count ssl traffic, webstatscollector's filter
(which runs on erbium) relies on seeing the logs at the ssl terminators.
So as a result, ssl traffic was not counted in webstatscollector's
output since mid-April 2014.
Discussing a bit with ottomata, it seems the best way forward [1] [2]
is to try moving webstatscollector's filter to a host that still
consumes the udp2log multicast.
oxygen consumes the udp2log multicast, and does not look overloaded,
so we could try moving webstatscollector's filter there.
----
[1] We could instead turn multicast consumption on erbium on again. But
that would also affect all the other udp2log filters that meanwhile got
added to erbium. So it would cause further issues.
[2] We could update webstatscollector to stop dropping local http
requests from the ssl terminators. That would be nice as it would mean
that the overall picture of the webstatscollector pipeline gets
simpler. However, people are afraid to touch webstatscollector code,
and we want to phase it out anyways.
--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: u=Community c=General/Unknown p=0 s=2014-06-26",69456,-52,Needs Triage,True
12.024950624279995,-2.8751299051212023,7.22475213926452,0.9495097986334233,5.7615071517050325,-0.7446867255200997,2.4925495929666637,-1.0643834351988408,-1.888649471240143,-0.006929425865301653,1.35567109429581,-0.693520241678126,1.060982566080631,-0.7477723240719119,-1.1168288275164109,-0.6068694728361314,-0.29790372810908283,0.7783624661349446,False,c3,1,"This occurs very frequently when loading a page in the Page: namespace of en.wikisource. I am using the Modern skin, Firefox v30 browser, but I have no other useful info. Thanks
Script: https://bits.wikimedia.org/en.wikisource.org/load.php?debug=false&lang=en&modules=mediawiki.inspect&skin=modern&version=20140701T181553Z&*:2
Script: https://bits.wikimedia.org/en.wikisource.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=modern&version=20140701T181553Z:4
Script: https://bits.wikimedia.org/en.wikisource.org/load.php?debug=false&lang=en&modules=mediawiki.inspect&skin=modern&version=20140701T181553Z&*:2
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows XP
**Platform**: PC",69404,-53,Needs Triage,True
8.856860798867503,-1.6604704288165166,7.33234624622202,-0.3174508962295999,-0.3138386928884923,-0.4598122997201344,1.4850034346357326,0.6543722184740054,2.9683616291122714,-1.0723749416241923,-1.906334475059679,-1.5637769559548458,-1.9464313524584673,1.1332981818353218,-0.19877696420627355,-1.182832097609277,-1.4751656547439682,-0.9793690502275351,False,c3,1,"**Author:** `fn84b`
**Description:**
Wikitech requires HTTPS connections (http://wikitech.wikimedia.org redirects to https://wikitech.wikimedia.org), so could we send a Strict-Transport-Security header, so that browsers will automatically use HTTPS even if a link points to HTTP?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38516",69303,-53,Needs Triage,True
3.404631870444194,1.4946373528427852,0.27930874929060323,-5.1712441336721,5.274994805163134,-4.446509613844329,4.233257077077565,-1.9382118870179985,-0.02154311673442938,-0.19551089939430621,1.096087026948576,3.4690560961930803,-0.6560302093226964,0.22535371362960177,-0.07985963213539016,-0.8310707159154889,0.37861877809190836,0.7913629465044372,False,c3,1,"It seems like our Flickr API calls match the protocol that was used to access the UploadWizard page, which is mostly fine except when those API calls require SSL. Either we should handle that error message and retry with explicit SSL, use SSL where we know it's required, or just use SSL everywhere.
--------------------------
**Version**: unspecified
**Severity**: normal",69298,-53,Needs Triage,True
7.603857573397152,0.04722111309422239,3.91592817169791,-2.5847683062471276,-5.068326799604675,2.5695605955809766,0.8092792545052623,-1.5955492285407753,1.1134958136515152,0.8406601139045966,1.1542160381748237,1.1326917916835548,0.9003482678112369,-1.1185445626330837,-0.24094489150988885,0.8265156876849418,-1.1470297819103334,-0.6932802745584683,False,c3,1,"Hello!
is it possible to create a component in MW-Extensions for GoogleLogin, please?
https://www.mediawiki.org/wiki/Extension:GoogleLogin
Thanks for reply
Florian
--------------------------
**Version**: unspecified
**Severity**: normal",69132,-53,Needs Triage,True
3.3167159544628046,-3.807995856767759,-3.4742233264058644,7.346539331542983,-2.604199826666856,-3.492529526759461,-4.7161647998468155,-0.808409116845091,-2.6759507081651064,-0.016192864143631525,-0.5304916887072091,-1.11888815207203,0.11935092015740523,-0.4342723960721795,-0.5447667942898038,0.5758867820541034,-1.5377317282309844,-0.050422391569086455,False,c3,1,"Running any script or entry point results in a backtrace.
$ PYTHONPATH="".."" python scripts/basic.py
Traceback (most recent call last):
File ""scripts/basic.py"", line 26, in <module>
import pywikibot
File "".../pywikibot/__init__.py"", line
486, in <module>
from .page import Page, ImagePage, Category, Link, User, ItemPage,
PropertyPage, Claim
File "".../pywikibot/page.py"", line 17,
in <module>
import pywikibot.site
File "".../pywikibot/site.py"", line 31,
in <module>
from pywikibot.data import api
File "".../pywikibot/data/api.py"", line
13, in <module>
from pywikibot.comms import http
File "".../pywikibot/comms/http.py"",
line 31, in <module>
from httplib2 import SSLHandshakeError
ImportError: No module named httplib2
Even invoking threadedhttp.py, which includes a dependency check, fails before the dependency check.
--------------------------
**Version**: unspecified
**Severity**: normal",68618,-55,Needs Triage,True
1.5978730686255838,-0.7071584813932343,-3.5977998546494234,-2.1804779064590023,-3.869919539058497,3.353981071587908,-0.13939752572564768,0.5059387938104002,-1.1058651832609343,-1.7854112893751948,-1.1092181933808347,-2.114395948475313,2.1391764967274445,-0.47233570373248757,1.171809025461287,-1.4474745035876464,0.6954838869071656,0.2965846425463632,False,c3,1,"Reading the documentation and a cursory google search suggests that Net:HTTP:Persistent was useful for Ruby 1.8.x, but that the persistent function should be implemented automatically in Net:HTTP for 2.x.
In the meantime, this gem causes these sorts of errors:
too many connection resets (due to Timeout::Error - Timeout::Error) after 286 requests on 23958180, last used 60.017253158 seconds ago (Net::HTTP::Persistent::Error)
We might be better off removing the Persistent gem for modern Ruby versions.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",68451,-56,Needs Triage,True
-6.8204192361610545,-2.0757464433404564,-2.946173308362509,5.906768431394299,-0.36234698661487386,-1.885230841225468,0.83250506497175,-1.711378772287473,2.012412343199567,-2.81540310112696,-1.2841872719338916,2.6180837762731723,-2.38501355577412,-0.3076333327690346,-0.16375338939094153,-1.6080357856063616,0.2889674787776031,3.1827221809151025,False,c3,1,"httplib2 has debugging capabilities (httplib2.debuglevel), which would be useful to control from the pywikibot config, and ideally capture its debug output into the pywikibot logging layer
--------------------------
**Version**: core-(2.0)
**Severity**: enhancement",68161,-56,Needs Triage,True
1.2138046536870095,-1.988466521177001,5.024893442687251,5.043977816769153,-7.187269974548103,0.9709228705099775,1.9506680951128104,-1.307780179083133,1.004269598163632,-0.15369914305275856,-0.010370929484761149,-0.8722128196431727,1.4014546931071599,-0.25668863862041214,-0.9587881898377519,-4.4101152156145975,-0.6988406654208059,3.1054590606986805,False,c3,1,"Getting the following while trying to load VE on Betalabs : Error loading data from server: parsoidserver-http-bad-status: 503
--------------------------
**Version**: unspecified
**Severity**: normal",67553,-59,Needs Triage,True
-2.0123537199554677,-3.0016660528403296,-3.990235300389836,1.7449584211218983,-0.48039300942693275,-1.8636595240666238,-3.19170869174436,-6.034475745172918,-2.9506359645320517,5.697512521806592,-2.746592183206109,-0.9144854154458857,-0.8803311618405809,0.10812704131584905,-0.5228726826426584,-0.5123497525240758,-1.3438721865198004,0.08955139496898723,False,c3,1,"I'm getting a lot of warnings like this
""mw.Api error: "" ""http"" {xhr: Object, textStatus: ""abort"", exception: ""abort""}
in the console. I believe it comes from this line:
mw.popups.render.currentRequest.abort();
of ext.popups.renderer.js.
--------------------------
**Version**: 1.24rc
**Severity**: normal",67442,-59,Needs Triage,True
-4.469621056905151,-2.3392177998401085,-2.409327487697416,-3.721649422455671,2.644324575664484,-5.066032556229232,6.595381816656302,-4.378412882012118,-3.1697830543316865,0.053399914381564884,1.497126158719777,2.576690275633501,-0.9085891974804099,1.007802883434291,-1.3526082044240297,0.9338146080057711,0.6905863675440165,1.0986488136682089,False,c3,1,"Some users do code in unstable network connection (include me). When I reconnect the internet, all ssh sessions being disconected. So I must reconnect to ssh server, become tools account, reopen opened files and recovery vim swp files...
If we have tmux, all coding done in tmux and it is much less stressful...
thank you
--------------------------
**Version**: unspecified
**Severity**: normal",67426,-59,Needs Triage,True
0.6913643828393621,-0.6221021760491006,0.4215098150773464,2.7196985032773457,-4.3681680818099435,-3.798849858402508,-1.7957793990610877,-1.7531609695006427,3.0248425173792093,-3.4025719248913653,-1.052305375306688,0.7083175512724009,-1.0737566621139747,2.5380184326074557,0.1869816229937049,-0.3141347063833184,-0.02701644410617332,0.6102175812670112,False,c3,1,"https://github.com/jcgregorio/httplib2/releases/tag/v0.9 contains a cacert.txt that /does/ work for WMF domains, so we should:
- update externals/httplib2 to 0.9, and
- update setup.py to require httplib2 >= 0.9
--------------------------
**Version**: core-(2.0)
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68794",67189,-60,Needs Triage,True
-2.857907877290744,2.033530413572265,-4.1741447946704255,0.39390111982957077,-8.284427568024702,0.1750456329546286,-2.4921348628255418,-2.0746085155886513,-2.470250297058424,-4.018053245901826,-0.07104874332167777,2.017942020693945,-2.0808339465274424,1.362210036884166,-0.7907152944416982,-0.3938591765978233,-1.5774333626254087,-0.18396763728691345,False,c3,1,"page.put returns nothing but interwiki.py expects status codes to be returned, resulting in a TypeError after one page update at maximum.
--------------------------
**Version**: core-(2.0)
**Severity**: normal",67181,-60,Needs Triage,True
5.167059422334727,-1.8457078430151697,1.585550161512952,7.625513395798787,-4.751496109696815,-7.101475369729534,-5.051502070415781,-1.7213768128348401,-2.896268645670509,3.8808398887348172,-0.9923203836979066,-1.8260525808121466,-1.886087143584465,0.3369137537721629,1.5835593452675747,-0.03392611578722471,-0.8098802421586808,0.6515900271558703,False,c3,1,"I can't use pywikibot in my pc, it return the error ""ImportError: No module named httplib2"". I'm using core version.
$ git pull
Already up-to-date.
$ git submodule foreach git pull
Entering 'externals/httplib2'
Already up-to-date.
Entering 'scripts/i18n'
Already up-to-date.
$ python
Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2
Type ""help"", ""copyright"", ""credits"" or ""license"" for more information.
>>> import pywikibot
Traceback (most recent call last):
File ""<stdin>"", line 1, in <module>
File ""pywikibot/__init__.py"", line 427, in <module>
from .page import Page, ImagePage, Category, Link, User, ItemPage, PropertyPage, Claim
File ""pywikibot/page.py"", line 17, in <module>
import pywikibot.site
File ""pywikibot/site.py"", line 34, in <module>
from pywikibot.data import api
File ""pywikibot/data/api.py"", line 13, in <module>
from pywikibot.comms import http
File ""pywikibot/comms/http.py"", line 31, in <module>
from httplib2 import SSLHandshakeError
ImportError: No module named httplib2
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**OS**: Linux
**Platform**: PC",67089,-60,Needs Triage,True
3.8921996905978635,-0.4765375446287141,-1.0389526770821238,3.0695734185668524,1.2758904480748408,1.9021142381464962,-1.7624736486899417,-0.7756402935378134,0.803004104221541,-0.8059573002441511,0.15466980436206734,-1.0887429442254186,2.2726131073957605,0.5704592533579165,0.4989770975890018,-0.301252415980267,0.16362260022894737,-0.6000477418674164,False,c3,1,"[16:00 UTC] cvn-apache5.eqiad.wmflabs$ bin/update
+ curl https://noc.wikimedia.org/conf/all.dblist
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a ""bundle""
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
--------------------------
**Version**: unspecified
**Severity**: normal",66483,-62,Needs Triage,True
5.779653146390196,-14.091114568475525,-0.41170182945338674,3.0520388273671495,-1.5303473136480532,1.0346878484612574,2.7004942440005246,-2.0065891425177242,1.3225379436708595,-1.43591031736604,-2.264696049647948,-0.46456488043799227,-1.7804204406667141,-0.28776556313921997,-0.0792921204899546,-0.19857133450145215,0.09608394479021287,-0.19886415222038978,False,c3,1,"
--------------------------
**Version**: Android (alpha)
**Severity**: normal",66407,-62,Needs Triage,True
5.779653146390196,-14.091114568475525,-0.41170182945338674,3.0520388273671495,-1.5303473136480532,1.0346878484612574,2.7004942440005246,-2.0065891425177242,1.3225379436708595,-1.43591031736604,-2.264696049647948,-0.46456488043799227,-1.7804204406667141,-0.28776556313921997,-0.0792921204899546,-0.19857133450145215,0.09608394479021287,-0.19886415222038978,False,c3,1,"
--------------------------
**Version**: Android (alpha)
**Severity**: normal",66406,-62,Needs Triage,True
-5.874617142729674,0.9190103165456183,-0.1956810700418128,1.9116380680360456,-5.661720612934955,-0.7406709827481199,-1.885440766323887,2.454942158989468,-3.329679851076392,-2.157265966966624,-0.9651723702090078,0.14482594595793086,1.8495140409580535,0.8288072284371815,-0.04706362351287563,-0.4711428830625263,-0.19646657791131283,0.23443617472324418,False,c3,1,"In the mediawiki_selenium gem login_page.rb line 35 is:
logout_element.when_present(10) if wait_for_logout_element
---
However, some tests clearly fail to honor the 10 second timeout value
https://wmf.ci.cloudbees.com/job/browsertests-en.wikipedia.beta.wmflabs.org-windows-internet_explorer_10/578/testReport/(root)/Edit/Go_to_edit_page/
for example fails with
timed out after 5 seconds, waiting for {:href=>/Special:UserLogout/, :tag_name=>""a""} to become present (Watir::Wait::TimeoutError)
and the gem login method is clearly being called correctly.
--------------------------
**Version**: unspecified
**Severity**: normal",65826,-64,Needs Triage,True
-6.070639079465405,-1.2821207674896957,-3.726705252309097,-6.332263856423524,1.096676068254325,-3.038598916380035,1.982022400661477,-3.2670421723720193,-2.970064632200941,-1.4114792236303937,-1.0639934345240962,-0.49416658219986487,-0.21353723490300425,-0.6103764130534737,0.0686948594299368,0.7936608408757897,-1.427048398483498,-0.7255855933423971,False,c3,1,"I see the error reported in bug 51789.
""No active login attempt is in progress for your session.""
I was logged out reading a wikimedia page in desktop mode.
I log in.
I am sent to mobile version and am shown that error.
The number of times I end up on mobile version is beyond a joke. I never ever ever want it. Especially when it doesnt work.
--------------------------
**Version**: unspecified
**Severity**: major",65821,-64,Needs Triage,True
-3.011472344219974,3.6874488377287413,-4.414620985387552,-8.328456604684806,-2.6133657030490003,-4.238117864679623,-1.1192360830063492,-1.2056905612780255,-0.7398198187888441,1.4359943669622028,-2.352448373617796,-0.9990838698466717,0.2894115645742512,-3.866118684435046,2.1844747351029286,-0.9162924954116594,0.7642533175610022,-0.4718523864623385,False,c3,1,"I went to http://en.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin and logged in.
first it was waiting for login.wikipedia.beta.wmflabs.org
then it indicated it was trying to locate
http://en.wikipedia.$channel.wmflabs.org
(note ""$channel"" where ""beta"" should be)
and eventually failed with
Firefox can't find the server at en.wikipedia.$channel.wmflabs.org.
If I return to enbeta I am logged in despite the error, so this isn't critical.
--------------------------
**Version**: unspecified
**Severity**: major",65756,-64,Needs Triage,True
1.208367147694179,-1.3510260158027343,10.78168216924109,-1.6441249660090596,1.2958447352381905,-4.516737874779828,2.906165356097026,-4.59647312991178,-4.200101131134955,2.7993501126728972,-1.4040826271538815,-0.7436063299865616,-1.4518641950109812,2.5604461475946474,0.5778273502959976,-0.8690241860988781,-1.869650142203521,0.17641248756383798,False,c3,1,"When I enter wrong username in https://test2.wikipedia.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page , I get a ""Wikipedia's signup page"" link which links to https://en.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup rather than https://test2.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Main+Page
--------------------------
**Version**: 1.23.0
**Severity**: minor",65012,-67,Needs Triage,True
-9.02895037748462,0.5981309897476805,6.538825411000797,9.775136201445402,-4.908071037377885,-4.54499468663508,8.163305957940334,-1.5300685117865487,-3.671637443948778,1.7725852048133568,1.646982756502203,2.949778844486959,-0.1688630642160227,-0.08711880033663988,-1.1282166931092954,-0.04476432388732887,0.8713767537586834,0.23130530903953317,False,c3,1,"It seems like xmllint program is available on tools lab from the login host, but not from the job runners.
Expected behaviour is that tools-login and job runners have same set of packages available.
--------------------------
**Version**: unspecified
**Severity**: normal",64944,-67,Needs Triage,True
-3.272967495271514,0.5576382041838279,-2.0882623992723826,-7.272493255255527,4.44398132937294,-0.043243297128321645,4.91019049001648,-3.9043351574870457,-2.3930224579401767,0.3920630153409883,0.39186816991447193,2.706259112797804,-2.1450482696471314,2.9224834384562266,-0.907556273731319,-0.17761948672046468,0.20523008285350475,-0.8988597075537428,False,c3,1,"When I access the Wikimedia blog on https, I get a warning on chrome that it contains unsecured elements, which means the site isn't completely secure. They need to be found and made secure.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",64488,-69,Needs Triage,True
-4.745373699456821,-2.52104418478282,-4.404184678613916,-4.297561464768593,1.629848447992098,-0.873816431594533,0.6545999561314666,-1.7631657938091632,-1.729291766285092,-0.1581932861046056,-0.4831499146794833,0.38817991152291564,0.4502171004000215,-0.8048657797913759,-1.7062915451738148,2.689919868329648,-1.2367415427072428,0.6429400854800995,False,c3,1,"click Login button from http://en.wikipedia.beta.wmflabs.org
Login as usual
Get red-box error ""Login error
There was an unexpected error logging in. Please try again. If the problem persists, it may be because you have cookies disabled, and you should check that they are enabled in your browser settings. ""
No records appear in the fatals log when this happens.
After a brief inspection, I see this in both automated tests and manual operation, and it happens more frequently manually.
--------------------------
**Version**: unspecified
**Severity**: major",64484,-69,Needs Triage,True
5.13337244643362,-7.880624681807181,4.823511104813697,9.006688711278498,-2.190990091794421,-6.006292180179895,2.62939585168892,-0.3670572000391536,2.3412407155196284,-1.6216283031861138,-0.6884833637142007,-0.5340725903641941,-2.1623490510549095,-1.5181966516356704,0.3891463534382895,-2.4607986161468953,0.31524597736300297,0.3263978709660187,False,c3,1,"Fetching origin
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://git.wikimedia.org/git/mediawiki/core.git/info/refs
fatal: HTTP request failed
error: Could not fetch origin
--------------------------
**Version**: unspecified
**Severity**: normal",64432,-69,Needs Triage,True
5.311383993074315,-1.7479501371397657,-6.553085106745005,2.36271446632752,-0.8207557104096892,-2.027442073054402,-1.3026654700669704,0.29089359802918324,-0.7471483158341934,-1.5367792090253198,0.5913439589632921,-0.8097151103787814,3.4463692069224554,1.421917056082819,-0.6909345611359132,-0.6228819105522836,0.0698264639345445,0.20142488932776348,True,c3,1,"After moving from e52153e to 1e54f0c and running update.php (the latter probably unrelated), piramido.wmflabs.org consistently fails to load pages with an ApiRunJobs error:
[c71ea2c8] /wiki/Special:Random Exception from line 1366 of /srv/mediawiki/includes/api/ApiBase.php: Invalid or stale signature provided
Backtrace:
#0 /srv/mediawiki/includes/api/ApiRunJobs.php(54): ApiBase->dieUsage(string, string, integer)
#1 /srv/mediawiki/includes/api/ApiMain.php(862): ApiRunJobs->execute()
#2 /srv/mediawiki/includes/api/ApiMain.php(332): ApiMain->executeAction()
#3 /srv/mediawiki/includes/Wiki.php(649): ApiMain->execute()
#4 /srv/mediawiki/includes/Wiki.php(669): {closure}()
#5 /srv/mediawiki/includes/Wiki.php(451): MediaWiki->triggerJobs()
#6 /srv/mediawiki/index.php(49): MediaWiki->run()
#7 {main}
It looks like the socket method is failing, probably for the same reason a simple:
curl 'http://piramido.wmflabs.org/w/api.php'
fails on piramido with:
curl: (7) couldn't connect to host
I think Labs currently can't connect to itself with external host names.
There is a fallback that should work, but it's throwing the above exception consistently.
--------------------------
**Version**: unspecified
**Severity**: normal",64280,-70,Needs Triage,True
11.466118843836625,-3.097780671416464,-1.661120860201482,1.9254950265227406,1.6443684659768625,-3.0280133046588005,-5.019883245408855,-0.042156593989954916,-3.928570965804468,3.035148320645682,-1.999195780531762,-0.49566880248761735,2.277902691990124,1.830273960435826,2.209249819046761,-1.0656385518072995,-1.707730282459874,1.017312840873435,False,c3,1,"Noticed this while digging into another bug. In beta, users are not created on loginwiki. So cross-project login isn't working.
The odd thing that I think is happening is that the browser isn't getting all of the cookies that the wiki is setting. Maybe a Varnish issue?
In the beta logs, I see the user is redirected to loginwiki:
0.1661 4.2M Start request GET /wiki/Special:CentralLogin/start?token=b4bac89e539642795df51e425a974ffc
HTTP HEADERS:
HOST: login.wikimedia.beta.wmflabs.org
And then (as it should), loginwiki sets the user's cookies:
loginwiki-9c1ccc4f: 0.1995 8.8M [cookie] setcookie: ""centralauth_Session"", ""aa2442f2d2e716dc89eb16d1f89f3cfe"", ""0"", ""/"", """", """", ""1""
loginwiki-9c1ccc4f: 0.2004 8.8M [cookie] setcookie: ""centralauth_User"", ""TestBug16864'7"", ""1396574220"", ""/"", """", """", ""1""
loginwiki-9c1ccc4f: 0.2006 8.8M [cookie] setcookie: ""centralauth_Token"", """", ""1393895820"", ""/"", """", """", ""1""
However, in my browser, the only Set-Cookie header is:
Set-Cookie centralauth_Session=aa2442f2d2e716dc89eb16d1f89f3cfe; path=/; httponly; GeoIP=US:Santa_Clara:37.3541:-121.9552:v4; path=/
When the AutoLogin code runs, loginwiki then has:
0.1973 4.2M Start request GET /wiki/Special:CentralAutoLogin/refreshCookies?type=1x1&wikiid=enwiki&proto=http
HTTP HEADERS:
HOST: login.wikimedia.beta.wmflabs.org
USER-AGENT: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0
ACCEPT: image/png,image/*;q=0.8,*/*;q=0.5
ACCEPT-LANGUAGE: en-US,en;q=0.5
DNT: 1
REFERER: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&gettingStartedReturn=true
COOKIE: GeoIP=US:Santa_Clara:37.3541:-121.9552:v4; centralauth_Session=aa2442f2d2e716dc89eb16d1f89f3cfe
X-VARNISH: 497335809, 1267638667
X-FORWARDED-FOR: 50.136.233.16, 127.0.0.1
ACCEPT-ENCODING: gzip
loginwiki-8577f040: 0.1980 4.2M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
loginwiki-8577f040: 0.2054 5.0M LocalisationCache: using store LCStoreCDB
loginwiki-8577f040: 0.2084 5.5M Fully initialised
loginwiki-8577f040: 0.2148 5.8M CentralAuthHooks::onUserLoadFromSession: no User cookie, so unable to check for session mismatch
So no session because the centralauth_User cookie is missing.
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62001",64244,-70,Needs Triage,True
4.251264627641987,-3.6885659398852777,2.875511622826476,-0.5903308828117814,3.2241805838300306,2.016112185286328,-4.863720140144509,-1.2226174324815853,2.5734650466833164,-1.8039183731369564,3.6223392845173934,-1.5514022537491128,-0.8661632979620402,-1.0431624489243903,-0.2976303214170519,0.9449901206165563,-0.5038069591278616,-0.4730555747567673,True,c3,1,"Intention:
Add a link at the English Wikipedia to the Spanish Wikipedia.
Steps to Reproduce:
1. Type a label/anchor.
2. Open the link inspector.
3. Paste in https://es.wikipedia.org/wiki/Idioma_inglés
4. Exit the link inspector and save changes.
Actual Results:
It created an external link: [https://es.wikipedia.org/wiki/Idioma_inglés Label].
Expected Results:
It should have behaved the same as pasting the same link, but with HTTP:// at the start. It should have created an interwiki link: [[:es:Idioma_inglés|Label]].
Reproducible: Always
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57019",63672,-71,Needs Triage,True
7.930936333028544,-4.4694362736542494,-0.8016294618833726,-3.1553466445777723,0.48590427759564037,0.7503679518353044,-0.654099717450106,1.03623760687015,0.04562563041150369,-2.568119834273405,-2.3087151589310992,0.7292794042243727,0.5202058257793865,-0.6385175347951169,0.2931389818638648,0.2945578122615659,-0.6958442097058017,0.3538913275590654,False,c3,1,"**Author:** `sanjeetkumarit`
**Description:**
create account/login link combined
How to separate Login and create Account options in Mediawiki 1.20.2 when ConfirmAccount extension is enabled? Please give any patch or code soon.
Its already given $wgUseCombinedLoginLink= false; in DeafultSettings.php Even though the link is Login/Create Account link is single. After Enabling the ConfirmAccount Extension in mediawiki 1.20.2 Please give some solution ASAP
--------------------------
**Version**: wmf-deployment
**Severity**: critical
**Attached**: {F13194}",63479,-72,Needs Triage,True
10.827317397105228,-5.262460837821525,0.340183941589455,4.352207794742116,-0.9470080303496116,-4.161287921854237,-1.4188955100598983,-0.7768586471067631,-2.25017078793467,1.4717994060220985,1.0730471533981203,-0.7383419830066374,1.0195194031085952,0.2401620902933148,0.47026691555010025,0.13176995259324867,-0.9746014276963779,-0.14789989406495407,False,c3,1,"**Author:** `hassen.houssein`
**Description:**
Login Error
C:\Pywikipedia>login.py
Traceback (most recent call last):
File ""C:\Pywikipedia\login.py"", line 59, in <module>
import query
File ""C:\Pywikipedia\query.py"", line 172
except ValueError, error:
^
SyntaxError: invalid syntax
C:\Pywikipedia>
I tried the clean_sandbox.py, but got this error
C:\Pywikipedia>clean_sandbox.py
Traceback (most recent call last):
File ""C:\Pywikipedia\clean_sandbox.py"", line 48, in <module>
import wikipedia as pywikibot
File ""C:\Pywikipedia\wikipedia.py"", line 754
raise IsRedirectPage, self._redirarg # do not change unless you see https:/
/bugzilla.wikimedia.org/show_bug.cgi?id=57879
^
SyntaxError: invalid syntax
C:\Pywikipedia>
--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 8
**Platform**: PC
**Attached**: {F13163}",63467,-72,Needs Triage,True
-4.006494996644175,-0.6773526646644292,-3.249576648066311,5.266008803807053,3.8973993865108265,-3.258571339028542,-0.6083047306822058,0.5553400796832626,1.423568819741002,-0.652756447464065,-1.4234143434971218,-3.2649278503079726,0.5890150041301552,-2.5231305781150173,-0.2152992096250772,-0.03747956366060523,1.8169297190843603,-0.24460750699706746,False,c3,1,"I created a (vanilla, no configuration, smallest image) instance yesterday (""icinga-scfc-test"") and the initial Puppet run didn't finish. So I waited several hours, but still no luck. Manual Puppet runs (""sudo puppetd -tv"") showed:
| err: Could not request certificate: The certificate retrieved from the master does not match the agent's private key.
| Certificate fingerprint: 05:91:9E:EE:6C:28:8B:24:FE:19:39:66:03:93:6C:44
| To fix this, remove the certificate from both the master and the agent and then start a puppet run, which will automatically regenerate a certficate.
| On the master:
| puppet cert clean i-00000906.pmtpa.wmflabs
| On the agent:
| rm -f /var/lib/puppet/ssl/certs/i-00000906.pmtpa.wmflabs.pem
| puppet agent -t
I deleted the instance, created another one (""icinga-scfc-test2""), and ran into the same situation again. I deleted the instance, created a bigger one (""icinga-scfc-test3""), and the error occured there as well (after waiting several hours in each case).
I reported this error in December (cf. http://permalink.gmane.org/gmane.org.wikimedia.labs/1976), but then it apparently resolved itself after waiting (cf. http://permalink.gmane.org/gmane.org.wikimedia.labs/1977), while now there doesn't seem to be any light at the end of the tunnel. (i-00000906 is not (and was not then) the name of any of the created instances, but refers to labs-vmbuilder-precise.)
--------------------------
**Version**: unspecified
**Severity**: blocker",63413,-72,Needs Triage,True
-0.8341767061070815,-2.963855238557773,1.1662959440122798,4.615489943355182,3.00701899934159,1.776964818880452,0.029745247381309348,-1.8234468326204434,1.7175748546453657,-0.9356876274743047,0.3692701886164209,-1.180525406488895,0.6143129160926968,-0.47955811132587733,0.22715555908790108,-0.6995226854676617,-0.21025512215862263,-0.632773786052536,False,c3,1,"**Author:** `grant`
**Description:**
clicking on the mobile line from a desktop pc
firefox 27
**
Secure Connection Failed
An error occurred during a connection to www.idahothewhitewaterstate.com. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)
**
chrome
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
Error code: ERR_SSL_PROTOCOL_ERROR
works fine on the android
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC
**Whiteboard**: aklapper-moreinfo",63358,-72,Needs Triage,True
4.051334611325684,-16.49057573437559,1.621634432167781,-3.809288669064981,-1.1378210780907185,3.8621926757748293,0.8072677495459137,0.46156423780977796,3.7482346440075425,0.8605708464502602,0.7626853374891276,1.0901835704854455,0.3272221409841256,-0.4525537293315427,-0.2114729068629826,0.28653873627452114,0.06331299829126302,-0.026918395719679022,False,c3,1,"Should trigger login.
--------------------------
**Version**: Unspecified
**Severity**: normal",63261,-73,Needs Triage,True
2.099831519087981,2.194736432277523,-2.191022260645015,-0.628287276474758,-1.0773188780009755,-0.8394912165321059,-1.9809771404941898,-2.57949103959705,0.2431243474581447,-1.8679077122323515,1.8201003077132296,0.32707933084233054,1.3858039166597118,-0.42538809870380234,0.7156696711224226,0.9488262476280148,-0.6476084137972062,-1.8332156290567356,False,c3,1,"Error in Kannada Wikipedia login page
The Kannada text in the login page on Kannada Wikipedia are wrong. Please see the attachment. The correct text for the numbered text are -
1. ನಿಮ್ಮ ಬಳಕೆದಾರ ಹೆಸರು (ಯೂಸರ್ನೇಮ್) ಬರೆಯಿರಿ
2. ನಿಮ್ಮ ಪ್ರವೇಶಪದ (ಪಾಸ್ವರ್ಡ್) ಮರೆತುಹೋಗಿದೆಯೇ?
3. ನನ್ನನ್ನು ಲಾಗ್ಇನ್ ಆಗಿಯೇ ಇಡಿ (೩೦ ದಿನಗಳ ತನಕ)
The original text in English Wikipedia for the above texts are, respectively, -
1. Enter your username
2. Forgot your password?
3. Keep me logged in (for up to 30 days)
If these are the wrongly translated text in TranslateWiki, please point me to the place where they have to be changed. I will change them.
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F13224}",62965,-73,Needs Triage,True
-3.7644241993875895,-2.313840199243913,-5.229311969817349,-5.6282083302848145,-1.0055747776813893,1.7782882938039,0.3832255836355891,4.287570101118661,1.147993956058913,-0.9807314857312792,-0.07171810427146275,4.484119929311723,1.583377840273466,-0.2866002114133792,1.9120348924731694,0.9755888108762168,0.8383742269057215,-0.02088450749138615,False,c3,1,"Those seem to have been created April 2013 and earlier; they should be removed as to not confuse the upcoming tool usernames change.
--------------------------
**Version**: unspecified
**Severity**: normal",62937,-73,Needs Triage,True
5.4269613714310765,-2.208394081900133,7.826346428608275,0.963496663271969,-4.520534933321471,0.43994229408942087,1.1614650633692554,0.8745255451137522,1.8307074791742581,0.42686844548661806,0.19115415370687705,0.7020829932602191,0.5668575246853904,-0.08262858956015151,-2.2761088143457235,-0.016260979605990267,0.5811668628275257,0.17102548672337492,False,c3,1,"Unable to connect via https to https://ganglia.wmflabs.org/ with Firefox
and Chrome.
Firefox gives the error message: ssl_error_rx_record_too_long
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57371",62865,-74,Needs Triage,True
4.805404641360138,-0.8229564987609717,2.452794022846078,3.2037566159819573,6.7285440473869595,5.397938713195582,-0.9305214917839262,-0.9121013152591646,-2.9039674306294563,0.7353932968776462,-1.564877081047665,1.0327762151376236,-0.4098955024603219,-1.1127354712452044,-0.03352024528185282,0.6951233481388377,-0.012079579125533257,-1.0610105695440333,False,c3,1,"**Author:** `daniel`
**Description:**
While Bug#52630 was fixed and
http://www.sslshopper.com/ssl-checker.html#hostname=tools.wmflabs.org
has an all green result
http://www.sslshopper.com/ssl-checker.html#hostname=fastcci1.wmflabs.org
gives a warning (""The certificate is not trusted in all web browsers."")
The latter goes through a different server (the Instance Proxy).
--------------------------
**Version**: unspecified
**Severity**: normal",62833,-74,Needs Triage,True
-3.1542114261473992,-1.0776408727657927,1.019446017480945,0.5999320101513441,-3.371631277101638,-0.2513800805679054,-0.1215668534267964,-1.806295465472831,-1.7035889849471355,1.7449582622060609,-2.2089237398523855,-0.05007273809322155,-0.4602357715594598,0.04430020793672895,-2.174014876697316,-2.336900883136901,-1.2051866757006258,0.3675827684384594,False,c3,1,"http://en.m.wikipedia.beta.wmflabs.org/w/api.php?format=json&action=visualeditor&paction=parse&page=Selenium_Edit_Test
Any idea why this request ends up with the response:
{""servedby"":""deployment-apache32"",""error"":{""code"":""parsoidserver-http-bad-status"",""info"":""404""}}
It prevents VisualEditor from loading on mobile...
--------------------------
**Version**: unspecified
**Severity**: normal",62755,-74,Needs Triage,True
4.299242701460873,1.7155386004063722,4.8211006312458515,-1.2682971489391568,0.26058873889925305,0.489744288958486,1.1605180369807142,-0.1743024294531296,1.6835141770519193,0.33731907672466477,1.7299989091696273,0.9383159137675838,2.0812894911594184,1.0471426343827916,0.7517995554339958,-1.2161335105862476,-0.6973545020498912,0.8610452921169294,False,c3,1,"Several users have reported seeing a redirect loop error page when attempting to access http://logstash.wikimedia.org. Using the https protocol seems to correct the issue.
I have personally not been able to recreate the redirect loop in my browser, but I can recreate it using curl from the command line:
curl -v -L http://logstash.wikimedia.org
Expected:
* GET / HTTP/1.1
* 301 Moved Permanently; Location: https://logstash.wikimedia.org/
* GET / HTTP/1.1
* 401 Authorization Required
Got:
* GET / HTTP/1.1
* 301 Moved Permanently; Location: https://logstash.wikimedia.org/
* GET / HTTP/1.1
* 301 Moved Permanently; Location: https://logstash.wikimedia.org/
* ...
Behavior seems to be intermittent. During testing to file this bug I could recreate the looping behavior for several requests in a row followed by several proper redirects followed again by several redirect loops. This seems to indicate that a single node in a load balanced cluster is misbehaving.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",62488,-75,Needs Triage,True
1.5708455324592205,-0.0752749712350429,-2.9884577114505433,-2.020220366822408,-0.9011636243330405,2.3385549781693618,-3.9512481821479297,-2.485126198961153,-2.4207239935724205,-0.7648418693216494,1.5848946688123147,-0.378743672160347,0.47087269467334547,-0.34226365232696665,-1.3266917182373108,0.15754367460624105,-1.1856590321081613,-0.7073246259954125,False,c3,1,"Steps to reproduce:
1.Open the Visual Editor for a page which contains an internal link with FireFox
2.Copy the link and paste it into another VE
3.Save the page.
Observed Result:
After copy a ""[[example|example]]"" link, when pasting the link is turned into a ""[[https://fr.wikipedia.org/example|example]]"" link.
It appears as follows: https://fr.wikipedia.org/w/index.php?title=Utilisateur:NemesisIII/Brouillon&diff=100540861&oldid=100181721
With Firefox 28, at least on fr.wp . (Sorry for my bad English)
--------------------------
**Version**: unspecified
**Severity**: normal",62379,-75,Needs Triage,True
0.5103676306606402,-3.6736760787045135,-1.5713021293359635,11.472581496814973,-4.233242702336117,-7.129165528460804,-1.2901705364860065,-2.040495694919871,-0.7985075626449715,0.15082308446798898,-1.4085250882524267,-0.7504733263125365,1.805039398210862,0.47629428222331605,1.0004692046956523,0.6952874001291582,-1.2760243271551857,-0.05952857648610865,False,c3,1,"**Author:** `sumanah`
**Description:**
I'm already logged into meta.wikimedia.org. On metrics.wmflabs.org, if I try to log in by clicking the meta.wikimedia.org logo, the OAuth authorization step goes smoothly.
But on my own local installation of Wikimetrics, in my dev environment running git master, if I try to log in by clicking the meta.wikimedia.org logo, I get an error. (Login via Google goes fine.)
httplib2.SSLHandshakeError
SSLHandshakeError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Traceback (most recent call last)
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask/app.py"", line 1701, in __call__
return self.wsgi_app(environ, start_response)
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask/app.py"", line 1689, in wsgi_app
response = self.make_response(self.handle_exception(e))
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask/app.py"", line 1687, in wsgi_app
response = self.full_dispatch_request()
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask/app.py"", line 1360, in full_dispatch_request
[Display the sourcecode for this frame] [Open an interactive python shell in this frame] rv = self.handle_user_exception(e)
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask/app.py"", line 1358, in full_dispatch_request
rv = self.dispatch_request()
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask/app.py"", line 1344, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File ""/home/sumanah/test/wikimetrics/wikimetrics/controllers/authentication.py"", line 103, in login_meta_mw
redirector = meta_mw.authorize()
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask_oauth.py"", line 331, in authorize
token = self.generate_request_token(callback)[0]
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask_oauth.py"", line 296, in generate_request_token
self.request_token_params)
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/flask_oauth.py"", line 108, in request_new_token
body=body, headers=headers)
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/httplib2/__init__.py"", line 1570, in request
(response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/httplib2/__init__.py"", line 1317, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, headers)
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/httplib2/__init__.py"", line 1252, in _conn_request
conn.connect()
File ""/home/sumanah/.virtualenvs/metrics/lib/python2.7/site-packages/httplib2/__init__.py"", line 1044, in connect
raise SSLHandshakeError(e)
SSLHandshakeError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
--------------------------
**Version**: unspecified
**Severity**: normal",62095,-77,Needs Triage,True
1.054552789245594,-5.047885495304614,0.7903926456431023,1.4599201172077527,7.510467450978622,0.12177882485989122,0.2839383383902856,3.888777206102259,-3.8196214296844078,2.3220468090965003,-3.2617237724138635,1.0278287571112201,-1.5039259319145595,-1.2131877553976982,1.3107733538736683,0.09477142259087898,1.6920078759319293,-0.878895592297579,False,c3,1,"https://en.m.wikipedia.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Uru_people&returntoquery=article_action%3Dwatch
The same line is repeated twice. This is clearly a mistake :)
Also on
https://en.m.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Uru_people&returntoquery=article_action%3Dwatch
A message '<mobile-frontend-watchlist-login>' is not translated.
--------------------------
**Version**: unspecified
**Severity**: normal",62048,-77,Needs Triage,True
0.7141603040783822,-2.5301848981198827,4.946719821055485,2.8921603820430395,-0.3251121561432025,-0.8504052420999031,2.4966417380898607,-1.5507110050683082,-0.3346778812403892,0.7043590034603708,-0.0031801398326622987,-0.3881655488851269,-0.5883166451825579,0.7027451647164176,-1.9993499322307118,0.3982675902578079,-0.13002788145498712,-0.7907371034700994,False,c3,1,"On the lighttpd web server in WMF labs, links fail if they don't contain a trailing slash. Compare:
- http://tools.wmflabs.org/matthewrbowker/cnrd
- http://tools.wmflabs.org/matthewrbowker/cnrd/
--------------------------
**Version**: unspecified
**Severity**: normal",61926,-77,Needs Triage,True
-0.7297985700081409,2.544553511338293,1.2088335253100624,5.4381914667040165,1.6433918319849083,2.6259765584381363,0.7944379747797123,-1.1533515341682936,2.1537493835320785,0.7657157233535861,0.06080056905494491,-0.7372286084192657,-1.0297149007090276,0.01275823875234483,0.4761024570885075,-0.32831096369618573,-0.04082537811084963,-0.7460673937233413,False,c3,1,"hashar@integration-selenium-driver:~$ curl https://git.wikimedia.org/
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a ""bundle""
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
hashar@integration-selenium-driver:~$
--------------------------
**Version**: unspecified
**Severity**: normal",61910,-77,Needs Triage,True
-3.893809906616433,-2.9520553830998875,2.2309182183680534,4.264187368384292,-2.797181973848673,0.7507858705070274,2.2480528500597226,-1.965728428400169,2.689104589201947,1.2951217608021253,3.700672547307939,1.6908766814758993,-0.18165094993701647,0.5673540405633268,-1.5529464455122595,-0.20079431502900824,0.21636430850585087,0.9685804685989556,False,c3,1,"https://tools.wmflabs.org/wikitrends/2013.html includes a javascript-library from jquery.org using http. Some browsers (like chromium) refuse to load it for security reasons. Please make the include-url protocol-independent (://) or use https://.
--------------------------
**Version**: unspecified
**Severity**: normal",61630,-78,Needs Triage,True
3.426406830589236,-5.474160062421687,1.3868140883058864,4.014125447702539,-2.779922369501103,-0.22153197844782124,0.06460068736773383,-2.13566053775171,0.25839220983886724,-1.8165281464638587,0.2833491912237265,-0.2508965810321422,0.47967242871460547,0.8791892976078808,0.4676771440114127,-0.6744338269461461,0.26378645917046484,0.05643045360922172,False,c3,1,"This issue was converted from https://jira.toolserver.org/browse/DRTRIGON-133.
Summary: support of coming https security upgrade
Issue type: Improvement - An improvement or enhancement to an existing feature or task.
Priority: Major
Status: Reopened
Assignee: drtrigon <dr.trigon@surfeu.ch>
-------------------------------------------------------------------------------
From: Herzi Pinki <herzi.pinki@aon.at>
Date: Thu, 22 Aug 2013 20:26:42
-------------------------------------------------------------------------------
DrTrigonBot category discussion summary (https://toolserver.org/~drtrigon/cgi-bin/sum_cat_disc.py), although called via https, provides links with plain http protocol.
For the upcoming security update, can your bot please use protocol relative urls?
see https://meta.wikimedia.org/wiki/HTTPS
--------------------------
**Version**: unspecified
**Severity**: major",61613,-78,Needs Triage,False
1.4112344967687434,1.085072957036532,-2.345183312367075,1.2315768451017903,-0.999657390548016,1.0512751864466356,-1.3640733380565067,1.5448555405993423,-0.8322441774579885,-2.703289062261457,-0.21179802005060955,-1.6190784720122469,0.919710909553836,0.40185877152890637,-0.3231074368348317,-2.388615742121123,-0.2377903975867579,0.6031228950887633,False,c3,1,"This issue was converted from https://jira.toolserver.org/browse/DRTRIGON-112.
Summary: subster_irc bot forgets wiki login when accessing other mediawiki project
Issue type: Bug - A problem which impairs or prevents the functions of the product.
Priority: Major
Status: Closed
Assignee: drtrigon <dr.trigon@surfeu.ch>
-------------------------------------------------------------------------------
From: drtrigon <dr.trigon@surfeu.ch>
Date: Tue, 17 Jan 2012 19:06:41
-------------------------------------------------------------------------------
When looking at the logfile from 2012-01-17 for following comments and later:
> 2012-01-17 19:44:36,744 bot_control INFO Password for user DrTrigonBot on wikipedia:de:
the subster bot (may be just when used by subster_irc...?!?) asks for the wiki password.
(look also at difflink in URL - which triggered the error in the logfile)
We have to protect the bot from logging out when accessing foreign wikis!
--------------------------
**Version**: unspecified
**Severity**: major",61507,-78,Needs Triage,True
13.045685485194817,-5.543100599975368,-2.8972034946206264,3.7022703665697785,-0.663554561415507,-2.7483814749565063,-4.743797556934924,0.6491308966044731,-1.070910377675414,-1.7671388489431994,2.1354441634734456,-0.9606210391272099,0.3038688627189363,0.6550697906510967,1.0036187725957797,-0.9353740382838776,0.5200229720682601,-0.8459876650277405,False,c3,1,"This issue was converted from https://jira.toolserver.org/browse/DRTRIGON-40.
Summary: Passwort/Login for toolserver scripts
Issue type: Sub-task - The sub-task of the issue
Priority: Major
Status: Resolved
Assignee: drtrigon <dr.trigon@surfeu.ch>
-------------------------------------------------------------------------------
From: drtrigon <dr.trigon@surfeu.ch>
Date: Fri, 03 Sep 2010 17:29:59
-------------------------------------------------------------------------------
Passwort/Login wo nötig (sensible Daten od. Funktionen; z.B. 'panel.py') mit [1] (hat auch noch andere [2])
[1] http://toolserver.org/~magnus/tusc.php
[2] http://toolserver.org/~magnus/
--------------------------
**Version**: unspecified
**Severity**: major",61454,-78,Needs Triage,True
6.139669143728842,1.7344683089230948,0.5994442187757123,-0.0314425995092511,0.2951266681339323,-1.935027978324114,-0.9390366214585324,-2.664823068060084,-1.9818440368095473,-0.09469849385734186,0.7205770759991141,0.8889229546739783,3.5758159270919885,1.6168888928647256,2.0996916271249386,-0.12238611915429043,-0.27334745779106084,-0.8901352247302223,False,c3,1,"This issue was converted from https://jira.toolserver.org/browse/DBQ-107.
Summary: How many users have their logins unified?
Issue type: Task - A task that needs to be done.
Priority: Major
Status: Done
Assignee: (none)
-------------------------------------------------------------------------------
From: Paolo Massa <massa@fbk.eu>
Date: Mon, 11 Oct 2010 13:08:15
-------------------------------------------------------------------------------
I would like to know how many users unified their logins, i.e. they can login in all wikipedias using the same login and password, see http://meta.wikimedia.org/wiki/Help:Unified_login
Unfortunately I don't know which db tables are involved. It should be something about local and global accounts.
I know that there is a tool that shows all the ""Users with name Example on Wikimedia projects"".
I tried with my nickname (phauly) at http://toolserver.org/~vvv/sulutil.php?user=phauly
Below there are the first lines of output of http://toolserver.org/~vvv/sulutil.php?user=phauly
{{{
SUL account status
Username: Phauly
User ID: 546004
User registration: 13:03, 09 October 2008
Home wiki: enwiki
Locked: no
Hidden: no
SUL admin (secure) • Contributions
Database ↓ Project ↓ Editcount ↓ Registration date ↓ Flags ↓ Blocked ↓ SUL status ↓
angwiki
(c)
wikipedia 0 2010021809295409:29, 18 February 2010 0 No autocreated
barwiki
(c)
wikipedia 0 2010022613112513:11, 26 February 2010 0 No autocreated
cowiki
(c)
wikipedia 0 2009070618005718:00, 06 July 2009 0 No autocreated
commonswiki
(c)
commons 0 2009051817232917:23, 18 May 2009 0 No autocreated
Home wiki: enwiki_p
Total editcount: 466
}}}
I used the Unified login feature months ago.
You can see that while en.wiki is my homewiki, I have an account in most of the wikipedias.
The account at Spanish Wiki es.wiki is not controlled by me, there is a conflict and in fact it says ""unattached"".
Most of the others are ""autocreated"".
Is there a way to know how many users have used this Unified Login feature.
My final goal is to analyze contributions of the same person in different wikipedias, so I need a way to know for sure that ""Example"" in en.wikipedia is the same physical person as ""Example"" in zh.wikipedia.
Thanks a lot for any hint!
Thanks!
--------------------------
**Version**: unspecified
**Severity**: major",61358,-78,Needs Triage,True
0.06381232894328637,3.7702516187464674,-1.881753710850239,5.65459467922936,1.1424278817650442,3.65615760562454,-0.013986915901045727,-2.647850873455377,1.6106814618082912,-3.2393727984644984,-3.5640124157737367,2.8757080453967907,-2.258412588954335,0.4468025461824281,0.055800898140114796,-0.3193181745997715,0.34581672445304457,0.27852379601941313,False,c3,1,"Some tests rely on an internet access, for example the Math extension fetch material from latexml. Hacking $wgHTTPProxy does fix the issue : https://gerrit.wikimedia.org/r/#/c/105188/
We have to set $wgHTTPProxy in the mediawiki.d configuration, should vary depending on the cluster the test is being run (pmtpa / eqiad).
--------------------------
**Version**: wmf-deployment
**Severity**: normal",61253,-78,Needs Triage,True
-1.06349165970117,0.9969431463878298,2.206588613359937,4.278150211363019,1.419455590401952,-2.3363795586733342,-0.262726608687041,-1.5362898760922832,1.6397600930440845,-1.1206180096638487,0.5067739722444227,-1.316994542701657,1.5702845990426422,-0.8492947281353214,-0.8188880202964572,0.4168999573339717,0.5417676517407568,0.5790267659787209,False,c3,1,"SSL endpoints log %-encoded URLs logged as \x-encoded URLs
When requesting %-encoded URLs like
https://ru.wikipedia.org/wiki/1092_%D0%B3%D0%BE%D0%B4
(note: “https”) we get a log line for
http://ru.wikipedia.org/wiki/1092_%D0%B3%D0%BE%D0%B4
(%-encoded) from the cache, but the SSL endpoint additionally adds a
log entry using the URL
https://ru.wikipedia.org/wiki/1092_\xD0\xB3\xD0\xBE\xD0\xB4
(\x-encoded).
The latter, \x-encoded URL cannot be fetched, and distorts logs.
I'd prefer if we have no \x-encoded URLs in our logs.
Should we:
* try to fix the SSL endpoints to not log distorted URLs, or
* stop having ssl endpoints in the udp2log log stream altogether
(Currently, https requests get two entries in the log stream. One
from the SSL endpoint, and one from the responding cache)
?
--------------------------
**Version**: unspecified
**Severity**: normal",60876,-80,Needs Triage,True
31.480553096646638,-0.8277343736384353,2.8955648652783346,-1.750848189573848,2.053566581396357,1.8616832568289718,-3.3642945962245494,-1.0689173924253002,-1.1534897016928092,-2.646313554584811,0.5060628064508657,-0.09034001854955398,-0.7055349525535997,-1.2463747029157979,-0.5548472474567188,-0.7928453350698927,0.6449397471893017,0.05316951798426639,False,c3,1,"This issue was converted from https://jira.toolserver.org/browse/PYWP-10.
Summary: Login needed for reading site, causing NoUsername exceptions
Issue type: Bug - A problem which impairs or prevents the functions of the product.
Priority: Blocker
Status: Open
Assignee: Merlijn van Deen <valhallasw@arctus.nl>
On Fri, 21 Jan 2011 22:18:49, Merlijn van Deen <valhallasw@arctus.nl> opened the following bug:
> (pwbde)valhallasw@dorthonion:~/src/pwbde/pwb-
> flat/branches/rewrite/scripts$ cat test.py from pywikibot import
> Page, Site print Page(Site('de', 'wikipedia'), 'test').site
> (pwbde)valhallasw@dorthonion:~/src/pwbde/pwb-
> flat/branches/rewrite/scripts$ python test.py Traceback (most recent
> call last): File ""test.py"", line 2, in <module> print
> Page(Site('de', 'wikipedia'), 'test').site File
> ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/page.py"", line 94, in site
> return self._link.site File ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/page.py"", line 2358, in site
> self.parse() File ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/page.py"", line 2341, in parse if
> self._site.case() == 'first-letter': File
> ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/site.py"", line 970, in case
> return self.siteinfo['case'] File ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/site.py"", line 964, in siteinfo
> self._getsiteinfo() File ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/site.py"", line 921, in _getsiteinfo
> sidata = sirequest.submit() File ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/data/api.py"", line 219, in submit
> self.site.login(False) File ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/site.py"", line 703, in login
> user=self._username[sysop]) File ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/__init__.py"", line 124, in wrapper
> return method(*__args, **__kw) File ""/home/valhallasw/src/pwbde
> /pwb-flat/branches/rewrite/pywikibot/__init__.py"", line 124, in
> wrapper return method(*__args, **__kw) File
> ""/home/valhallasw/src/pwbde/pwb-
> flat/branches/rewrite/pywikibot/login.py"", line 105, in __init__
> 'wiki_code': self.site.code}) pywikibot.exceptions.NoUsername:
> ERROR: Username for wikipedia:de is undefined. If you have an
> account for that site, please add a line to user-config.py:
> usernames['wikipedia']['de'] = 'myUsername'
--------------------------
**Version**: core-(2.0)
**Severity**: blocker",60818,-80,Needs Triage,True
-0.47665619460695297,2.3315418650498145,2.261838031137316,-9.329820415157801,0.023590011951135526,-2.6800020929864274,-0.3053242219231098,-7.438010264208911,3.5109965002004886,0.2771606651708316,2.590513181283606,-2.3202517628185877,2.963209353376003,-2.660301848886546,6.191122304741792,-1.943373608116603,3.5163175715946355,-3.5955736581776057,False,c3,1,"First time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error.
May be the same as bug 52749.
--------------------------
**Version**: unspecified
**Severity**: minor",60629,-81,Needs Triage,True
-3.882079292016962,-4.560535882019799,-3.6753887785423007,3.0178645207534283,-3.5071516722465903,-2.5614161975641503,-5.000133141382092,0.374410833307363,-6.489561107947935,8.408861348134751,-6.322351689443854,1.2500240205454711,-2.727235296683183,0.5545072923643026,1.9375006225297167,0.134767384488712,3.407044351335035,-1.642662108331466,False,c3,1,"proxy = {'host': 'localhost:8080', 'auth': None}
is ignored for https connections, and thus has been broken for WMF sites since the forced https switch.
--------------------------
**Version**: compat-(1.0)
**Severity**: normal",60548,-81,Needs Triage,True
6.674801249138557,-5.719583489326757,3.3385951359848,-0.2683518958954316,-2.9143719758120445,-0.6856400902156146,3.919946487581856,2.0972665769404637,-3.0637954236273846,-0.15936787778131656,-0.5361563039556358,1.3400021115198373,-0.30328646479916976,-1.017628609505072,-1.1439643731873135,1.1654907864891881,-0.05977414899638722,1.0988260588989458,False,c3,1,"login looks ugly in IE6
Login to http://en.wikipedia.beta.wmflabs.org/ with IE6
Input fields and text are skewed.
Login works though, so low priority
--------------------------
**Version**: unspecified
**Severity**: minor
**Attached**: {F12165}",60463,-81,Needs Triage,True
3.155700520672712,-11.032353227382286,7.86868278535929,-1.471805941798239,-3.3749439181191923,-1.101742526153952,-0.9476452593502556,1.7918035363309688,2.448863458231009,-2.047821903150181,0.19262671794779695,-0.5269460359102369,-3.260934366350937,0.7852363282330188,-0.5222755602750819,-0.13050501406375853,-0.5159869928591564,-0.7808865223205119,False,c3,1,"See https://gerrit.wikimedia.org/r/#/c/100980/2; possibly related to https://bugzilla.wikimedia.org/show_bug.cgi?id=55127
--------------------------
**Version**: core-(2.0)
**Severity**: normal",60392,-81,Needs Triage,True
-1.5009626445934763,2.1124367723466193,7.202658253563754,4.844634353212198,2.1087868324666825,2.096969076223364,2.4743924905334085,1.5336039413471294,-0.7550265045389914,-0.6410115208656713,-0.6653413003206818,0.298913751486801,-0.8483834208112242,-0.19741972020167964,-0.8584541002486992,-1.2546133208266315,-0.8677636117302195,0.08338547017715547,False,c3,1,"The site certificate is not trusted in all web browsers. Chrome for Android, for instance, shows a warning when visiting https://tools.wmflabs.org. Adding an intermediate certificate should fix this, per
https://www.sslshopper.com/ssl-checker.html#hostname=tools.wmflabs.org
--------------------------
**Version**: unspecified
**Severity**: normal",60284,-82,Needs Triage,True
6.150338387712754,-3.5837997418376997,2.9228808791763257,1.0331428027306524,-0.3028977975754152,-1.5300241977588438,0.9647248777308439,-1.5507408619260548,-1.7179092677192664,1.9343471074322762,-1.5198065406875627,-1.0305221939062983,0.8645075966364741,0.6073158984632947,2.08155349228051,0.19901629879271737,0.09905497985800271,-2.247726860806875,False,c3,1,"**Author:** `slboat`
**Description:**
i found this,is maybe a bug?
PHP Notice: Use of undefined constant CURLOPT_CONNECTTIMEOUT_MS - assumed 'CURLOPT_CONNECTTIMEOUT_MS' in w/includes/HttpFunctions.php on line 733
--------------------------
**Version**: 1.22.0
**Severity**: normal",60178,-82,Needs Triage,True
1.6573126178192017,-9.02523346730213,2.816860574293397,-1.3564347146869766,1.6817800749922558,0.2519594965183638,3.477431947367811,4.369715271397081,0.5030591502587621,1.2762114213930005,1.5050390944566145,4.633086501143055,0.7838880224410847,-0.9365387298154193,0.8963894800380015,-0.7755390742845689,-1.3153803375251378,-0.26017717804984875,False,c3,1,"https://tools.wmflabs.org is fine
http://tools.wmflabs.org is very slow (~45 seconds to load the page)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57988",59968,-83,Needs Triage,True
7.544730904187089,-0.15513376688306835,-0.319389367506437,0.6429135350238111,-4.2062186645631785,-2.105364395654904,0.8395046321477384,1.831196002928566,-2.1401911869316588,-1.1840763562882932,-3.4743472223421774,-0.5929601443158012,-0.761926862639263,-0.3829807790343427,-2.972622931619556,1.4239531436644188,0.9843747615268292,0.6664859428525964,False,c3,1,"Seen in Firefox:
http://test2.m.wikipedia.org/wiki/Main_Page or http://test2.m.wikipedia.org/wiki/Main_Page?useformat=mobile
Type 'bara' into the search box.
Barack Obama page suggestion should appear, but page says explicitly that no results are found.
Search works correctly from https: https://test2.m.wikipedia.org
Notes:
* Search works correctly on beta labs from http URL http://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page?useformat=mobile
* Search works correctly in production from http URL http://en.m.wikipedia.org
* http://test2.m.wikipedia.org redirects to https for Chrome (and search works correctly) but not for Firefox
--------------------------
**Version**: unspecified
**Severity**: normal",59934,-83,Needs Triage,True
-2.418779335595871,-3.546218583427427,-2.6965831997826246,0.9737841083993111,-5.128225657441112,0.9505367202211461,4.678039406902898,0.10376881759851286,0.34138484870895636,0.09029697329015196,-0.4392693725754291,-2.125701791943845,-1.4947747779936797,0.6106310705363835,-0.5537763112206529,1.047454713030861,0.2799249670909383,0.7942613946483827,False,c3,1,"Also, set up initial jobs for projects that already use csslint in their local-dev Gruntfile (oojs-ui and visualeditor at the moment).
--------------------------
**Version**: wmf-deployment
**Severity**: normal",59899,-83,Needs Triage,True
14.1809280007236,-5.405303165458623,0.22688720458830858,3.2604682937729637,-2.1264415663817102,-1.461709340749597,3.444620339669707,1.0717142922469893,0.7207334310719402,-0.3684304126707936,-0.9296936247000831,-1.6858073580275084,-0.5251477708026311,-0.5669515229259856,-1.3608293081035985,-0.3321271278538115,-0.04557471577623007,-1.3447809380056328,False,c3,1,"https://m.mediawiki.org/wiki/Special:UserLogin
Exception thrown by mobile.issues.beta load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:145
Error: Template not found: overlays/cleanup Error {} load.php?d
--------------------------
**Version**: unspecified
**Severity**: normal",59624,-84,Needs Triage,True
6.1547633931221934,3.889267145532237,-0.20856529013380332,-6.230477721051929,-1.7617862052230713,3.8791215489406303,0.6255539704799844,1.580399150533125,-1.0361878821624506,-0.6319279995980098,-0.2767922217378689,2.7703760492890668,-0.0723132831035267,-0.30559599050843556,0.4702729758587125,0.9211739010214645,-2.1902207476275644,-0.5232571348398334,False,c3,1,"Currently, a Google account is required to log in into Wikimetrics.
Now OAuth has been deployed for Wikimedia accounts, https://metrics.wmflabs.org/login seems a good candidate to consume it.
--------------------------
**Version**: unspecified
**Severity**: normal",59493,-84,Needs Triage,True
3.1287478323982953,0.05507289641115065,4.074044257486253,1.9835201191405742,2.2754530172944945,-1.1346505920768122,2.2398944504454645,-4.213086125268934,0.49771996157007037,-0.931656336833957,0.01118901782472248,-1.4826713230354716,-0.44360419645709115,-0.4540725908665948,-0.5447595207997251,-0.0063064724600375155,0.37098618241973447,-0.4900234730666888,False,c3,1,"Hi. We have a problem with the entrance and exit to the site.
Please correct synonyms, we are no longer able to enter the system under its
entrance
https://ce.wikipedia.org/w/index.php?title=%D0%91%D0%B5%D0%BB%D1%85%D0%B0%D0%BD:%D0%A7%D1%83%D0%B2%D0%B0%D0%BB%D0%B0%D1%80/%D1%8F%D0%BB%D0%B0%D1%80&returnto=%D0%9A%D0%BE%D1%8C%D1%80%D1%82%D0%B0+%D0%B0%D0%B3%D3%80%D0%BE
output
https://ce.wikipedia.org/w/index.php?title=%D0%91%D0%B5%D0%BB%D1%85%D0%B0%D0%BD:%D0%90%D1%80%D0%B0%D0%B2%D0%B0%D0%BB%D0%B0%D1%80/%D1%8F%D0%BB%D0%B0%D1%80&returnto=%D0%9A%D0%BE%D1%8C%D1%80%D1%82%D0%B0+%D0%B0%D0%B3%D3%80%D0%BE
Userlogin → Чудалар
Userlogout → Арадалар
--------------------------
**Version**: wmf-deployment
**Severity**: major",59410,-84,Needs Triage,True
5.207794617139095,-3.1764757190440367,10.362429944293776,2.589736321378973,-3.6452905678141767,-1.0227462219115226,1.3204355783940995,0.4693406924218888,2.1918015160668984,0.12347715606859655,-0.1981071742441669,1.0699725356875767,0.21664020549402085,-0.10518678884227661,-2.0515046316110452,0.2055886923344688,0.6611711357801464,0.39952581712789015,False,c3,1,"Unable to connect via https to https://ee-dashboard.wmflabs.org/ with Firefox and Chrome.
Firefox gives the error message: ssl_error_rx_record_too_long
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://ee-dashboard.wmflabs.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60865",59371,-84,Needs Triage,True
9.090648762294695,-6.913347478141879,7.542659873850152,1.8144844050064708,0.6795681284693473,0.8328871199708241,-0.23525189143681757,-0.7384747907793906,3.3041488435933566,-1.9455384400958127,-2.5488241074063174,-0.6091572060364006,-1.2958103261925205,0.07569656530845226,-0.5552100390240167,0.353377016857317,-0.5998124722193854,-0.9427690005216345,False,c3,1,"**Author:** `tparis.wiki`
**Description:**
Please set up an SSL cert for the UTRS project.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://utrs.wmflabs.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53175",58927,-86,Needs Triage,True
2.42270183568005,-2.445717401615214,6.880509437394554,5.364073907654558,-3.9794188396436594,-0.8264453773231479,-0.9236821411196026,-0.6214796181004636,3.863440134251314,2.245948540352429,-0.5274695132112921,1.1498528735022842,0.903335159183102,-0.963716571042391,-1.8720505119995252,-1.9709101019776916,-1.6867818823771823,0.22544611954745641,False,c3,1,"Error message
Steps to reproduce:
Click on the edit button
Observed Result:
""Error loading data from server:parsoidserver-http-bad-status:503"" shows while attempting to edit using VE
See the screenshot attached
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12683}",58584,-87,Needs Triage,True
-1.3744295235858648,-4.89874129914058,1.4313468278413843,5.1746039368845995,-1.1561735572199021,-4.3246327766497785,-0.36572133971248455,0.26712951899286197,-1.1639454588560902,1.2379755037219375,-2.0107084791133,-0.21483497035758314,1.3098751362819936,-0.641076577229259,-1.3330001222823205,0.12255641132015638,0.3490466766388207,-0.060799297353372195,False,c3,1,"The Puppet templates/labs-localsettings has
if ( array_key_exists( ""SERVER_NAME"", $_SERVER ) ) {
$wgServer = ""//"" . $_SERVER[""SERVER_NAME""];
}
Because $wgServer is not prefixed with http:, MediaWiki thinks https://servername links will work, thus several places in the code generate them, e.g. Special:UserLogin's _Use secure connection_ link and Echo notification e-mails. But most labs instances don't have working SSL, even via instance-proxy.wmflabs.org/
Project admins can't override this in orig/LocalSettings.php because these lines come after it is require_once'd.
Ideally the puppet LocalSettings would determine if https worked to the labs instance, and if not set
$wgServer= 'http://' . $_SERVER['SERVER_NAME'];
Possible workarounds include unset ($_SERVER['REQUEST_TIME'] ), overwriting $wgServer in some later config hook, and configuring SSL on the labs instance (bug 54065).
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://toro.wmflabs.org/wiki/Special:UserLogin",58389,-88,Needs Triage,True
6.185093344065162,-6.902813655759238,-10.336034546959635,3.3534672740638953,-2.612169928343214,-2.9193161516003006,-6.308026842450482,0.8109078611529189,-0.48104471727209774,-3.871618862169962,2.851689789779854,-0.5214278531160224,-2.907512094944561,-1.0434660369462518,-1.6260689077976496,-0.42068239932174767,-0.4432747950840539,-0.17652709558986834,False,c3,1,"Test script
Running <code>python setup.py install</code> while in virtualenv does not install automatically the httplib2 dependency.
```
(pywikibot)cristian@cristian-F5N:~$ python test.py ""Alessandro_Manzoni""
Traceback (most recent call last):
File ""test.py"", line 4, in <module>
import pywikibot
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/__init__.py"", line 313, in <module>
from page import Page, ImagePage, Category, Link, User, ItemPage, PropertyPage, Claim
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 16, in <module>
import pywikibot.site
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 33, in <module>
from pywikibot.data import api
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 13, in <module>
from pywikibot.comms import http
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/comms/http.py"", line 30, in <module>
from httplib2 import SSLHandshakeError
ImportError: No module named httplib2
```
`test.py` is attached.
I am using Python 2.7.3 under `virtualenv` version 1.9.1 on Ubuntu 12.10.
Furthermore installing the dependency with `pip install httplib2` cause the following bug.
```
(pywikibot)cristian@cristian-F5N:~$ python test.py ""Alessandro_Manzoni""
ERROR: Traceback (most recent call last):
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 284, in submit
body=paramstring)
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/comms/http.py"", line 123, in request
raise FatalServerError(str(request.data))
FatalServerError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Traceback (most recent call last):
File ""test.py"", line 12, in <module>
item = pywikibot.ItemPage.fromPage(wikipage)
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 2527, in fromPage
repo = page.site.data_repository()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 98, in site
return self._link.site
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 3224, in site
self.parse()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/page.py"", line 3207, in parse
if self._site.case() == 'first-letter':
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 1173, in case
return self.siteinfo['case']
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 1167, in siteinfo
self._getsiteinfo()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/site.py"", line 1100, in _getsiteinfo
sidata = sirequest.submit()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 462, in submit
self._data = super(CachedRequest, self).submit()
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/data/api.py"", line 284, in submit
body=paramstring)
File ""/home/cristian/.virtualenvs/pywikibot/local/lib/python2.7/site-packages/pywikibot/comms/http.py"", line 123, in request
raise FatalServerError(str(request.data))
pywikibot.exceptions.FatalServerError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
```
Steps to reproduce:
* download core.tar.gz and unzip
* create virtualenv
* run <code>python setup.py install</code> from <code>core</code>
* run <code>python test.py ""Alessandro_Manzoni""</code>
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**Attached**: {F12229}",58386,-88,Needs Triage,True
1.8152945026898828,1.4928591906731228,1.8248450853456255,4.688551746772832,6.4590225770883585,6.637532712262909,-1.3095856501429957,-5.156685462995609,6.177080461280536,-0.11444345355059671,-1.0206392597128215,-2.5233807706862974,-2.5848473815717536,2.1867644249420817,1.949563819207289,3.430227895049798,-1.6090799864444867,-1.595153710697662,False,c3,1,"Visit a link in an email notification for a Flow event – you'll receive an SSL error.
--------------------------
**Version**: master
**Severity**: normal",58280,-88,Needs Triage,True
0.5104585096553715,-5.886497048590359,5.125834087105851,0.4050328763911377,1.7872242093238944,-3.31124237497845,3.4190922733972675,1.6193177019833498,-3.569022840281784,2.6555199310372792,-0.9024622544835394,-0.11591521443146102,-0.8401078628334337,-0.6162789536165212,0.01846511021289654,-1.3087903346892986,-0.6543065099953398,0.07079166737218023,False,c3,1,"Some ""plain-text"" files like JS code is extremely slow to access. This has started only today. Example:
http://tools.wmflabs.org/magnustools/resources/js/bootstrap.min.js
Sometimes it works, though. Some lighttp issue?
--------------------------
**Version**: unspecified
**Severity**: normal",58244,-88,Needs Triage,True
-4.730265351570923,8.300264797790721,-2.4752754456130717,-6.498574668606427,-5.026956450538876,0.3308696629147536,1.2790740283930626,0.6366773386420744,0.3516550073340061,-0.7064607215625038,0.1335356195200914,-0.2134253550847094,0.13385684100414785,-0.7338992170856837,0.6618011444255751,0.049864821377763324,0.10823058672832175,0.04548293169617579,False,c3,1,"In facebook ( https://www.facebook.com/settings?tab=security ), one can selectively log ones self out of other current sessions, but in Mediawiki, one is helpless if one wants to log out of a session for which one no longer has access to the terminal of.
Please implement being able to log out of selected other sessions, or at least a way of logging out of everything everywhere, short of changing one's password.
From the other task:
Currently, there’s no way for me to see which sessions are valid/active for my account on Wikimedia projects – if I want to be sure that I can’t be compromised by an old session, I have to change my password. It would be useful if MediaWiki instead offered a way to list those sessions, and ideally allowed me to selectively terminate them as well.
GitHub and Twitter have such a feature, for example:
{F30311189, layout=inline} {F30311223, layout=inline}
In MediaWiki, this is currently offered by [Extension:SecureSessions](https://www.mediawiki.org/wiki/Extension:SecureSessions) (CC @Parent5446), but that extension isn’t deployed on Wikimedia wikis and also doesn’t always work, for example due to T73066; in T73066#2386198, @Anomie outlined an alternative way to track sessions. I think it might be worth adding this as a core feature.
See also:
{T55156}",58212,-88,Needs Triage,
2.967461880623255,-7.1602976622606676,-1.3501709555319277,-1.5430216036116502,0.4970599243717384,-1.2834216418082904,-2.6551343955116944,-1.176623557704212,1.8641513623754593,-0.774104753351236,0.14550509713029136,-0.4656767344628795,3.6590150767978877,0.1111854858953567,1.5939181157140583,-0.47800035485582015,0.7451075720915858,0.2742568160249761,False,c3,1,"Example[1]:
...
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate
...
Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help.
Workaround it so clone the repositories via SSH[2].
Contacted Cloudbees support[3].
They were able to reproduce the problem[4] and fix it.
1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console
2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md
3: https://cloudbees.zendesk.com/requests/14067
4: https://issues.jenkins-ci.org/browse/JENKINS-20218
--------------------------
**Version**: unspecified
**Severity**: normal",58098,-88,Needs Triage,True
-5.193568668580253,-3.113227546373734,0.20656561105282378,-1.8607024057766277,-11.934051380452019,3.4405928241816426,2.8018180787707427,1.4794108239307877,-5.455970576130375,6.790802330706169,-0.9763235820044387,-3.034164957849715,0.04913147005113583,3.412090995408885,0.2836261267792519,-0.9512292730205434,0.6303590632084066,-1.1337924493465934,False,c3,1,"'Mobile view' link always heads to https because of incorrect value in second argument of MobileContext::getMobileUrl().
--------------------------
**Version**: unspecified
**Severity**: major",57982,-89,Needs Triage,True
8.453788512069966,-5.220494493765813,-6.733988929694725,-5.363553134443972,-2.5929399834881175,3.8339021358999625,1.8660926511979676,4.201396538543292,1.7118282181471776,0.4700713702923558,0.5760834676681181,-0.655997325121048,1.163336179919058,2.1477417106306396,-0.994425521682917,-1.420055246989895,-0.37426167953917777,-1.058618508489309,False,c3,1,"So that services like these:
* http://acc.wmflabs.org
* http://parsoid.wmflabs.org
* http://cvn.wmflabs.org/api.php
.. can get proper valid HTTPS connections.
See also bug 48501 (for *.{projects}.beta.wmflabs.org, probably needs separate treatment)
--------------------------
**Version**: unspecified
**Severity**: normal",57957,-89,Needs Triage,True
3.8098603817276246,-5.946822927416514,3.9020388663499155,7.640260297694189,-3.816221632537154,-4.636378242296034,4.2186420318113464,-0.948581393097708,2.309563895151687,0.5644265654691623,0.3999157961437412,0.9534769047237257,0.060181553820259026,-1.26798369123886,-0.49235198996900564,-0.7604772173530534,-0.30566755779813914,-0.9162264504653999,False,c3,1,"**Author:** `johan.gunnarsson`
**Description:**
Can not ssh to tools-dev from tools-login:
johang@tools-login:~$ ssh tools-dev
If you are having access problems, please see: https://wikitech.wikimedia.org/wiki/Access#Accessing_public_and_private_instances
Permission denied (publickey).
--------------------------
**Version**: unspecified
**Severity**: normal",57945,-89,Needs Triage,True
12.071941939372373,5.110732489905335,1.7149152742523448,-2.441509947550959,-2.3057346190748396,0.8736148443262173,-4.071579638141848,2.4650695460926793,0.5958884327721906,5.352646602442974,-3.7093837172985777,0.20908781543978483,-0.7943385020472782,2.620595234323,-2.190011821111191,0.16855351994177875,3.0948539380412976,0.18744148369715208,False,c3,1,"seen on test2wiki Oct 17 after deploy
http://test2.wikipedia.org/wiki/Special:UserLogin?type=signup
correctly goes to the 'Create account' UI
http://test2.wikipedia.org/wiki/Special:UserLogin?type=signup
redirects to https but goes to the Login UI, not to the 'Create account' UI
Special:CreateAccount and Special:UserLogin/signup continue to function correctly
--------------------------
**Version**: unspecified
**Severity**: major",57854,-89,Needs Triage,True
-6.842342205106876,3.488259651367791,-0.443051273209111,-5.468634811585896,0.7700594399878375,-1.9941801085463498,2.5206728372506033,-3.9866786650467465,0.6781779481028343,-0.19856103386825197,0.09717901069727963,-0.3089607717394527,-1.1557459788371887,0.3370755153786158,0.3609074306031479,0.20060011896407134,2.8779004133455066,-0.8812991998047979,False,c3,1,"It looks like in beta, the apache configuration is redirecting http://login.wikimedia.org to https.
I'm not sure where those configs are stored, but can we remove that? I did that for production a while back, but it looks like the change didn't get into beta.
This will let us enable SUL2 without https support in beta.
--------------------------
**Version**: unspecified
**Severity**: normal",57804,-90,Needs Triage,True
3.6985854591024023,-5.410815247941233,-0.8455228902612753,3.0334139397094644,-3.5072532011474427,-1.0133663781136444,1.8900955980794505,0.9052658734595213,0.2875535606600189,-0.1647741413002599,-1.471897056846509,-0.46640740904252265,-0.49981172548990394,-0.11602430360851645,-1.919730254331693,0.8910221064235035,1.5991405761852178,-1.7676053904133533,False,c3,1,"cookies in Chrome
don't send forceHTTPS cookie for any beta.wmflabs.org host
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F12680}",57760,-90,Needs Triage,True
-6.366848425758185,2.0435501867489307,-6.0402437280020465,-4.291062208539201,-1.7428866991484282,-0.854365698810724,-0.7813693465586846,-2.162528414448701,-0.3881838241513632,-1.8965776375035044,-0.6638278428900306,0.06599172079148086,2.3509016406481678,1.3815134736677788,-1.0113186554075675,-0.06629355481637855,1.5216173375360997,-0.21758502995780682,False,c3,1,"Needs patches for other versions - only got 1.17 and 1.20 at the moment, so it probably needs 1.19, 1.21, and 1.22, especially as those are all of the current releases.
Uncyclomedia has the file patched for 1.21, but nobody exported an actual patch file and I'm not sure it actually works, either - seems to have worked for uncyclopedia, but testing failed for ?pedia?
(From what I understand, this is the patch to make it prevent the creation of accounts with names that folks might otherwise try to import. If I'm wrong about this someone smack me.)
--------------------------
**Version**: master
**Severity**: normal",57640,-90,Needs Triage,True
-0.7881096595312789,6.310671350334147,-0.5304069872602071,-5.333442984080937,-2.3485789316122485,-7.149365232775401,4.4001666710287966,-5.386696443123501,-1.905310871216904,-0.7926190755047497,0.12706898729445637,4.572014377268831,-0.8017542122895591,0.41651308223196004,-0.20092634202541237,0.9031072560608364,-3.029916840671812,0.03069215306274864,False,c3,1,"It only seems to be passed when you click sign up. What is stranger is if you inspect the URL of the login link it is there - it somehow gets stripped on click ing it.
Expected:
Whilst logged out click on edit button
CTA shows with login and sign up buttons
Click login
Address bar URL has campaign=mobile_editPageActionCta in it
--------------------------
**Version**: unspecified
**Severity**: normal",57474,-91,Needs Triage,True
-5.089227073978457,1.1738164380126044,2.6778622525611517,1.8255284874079827,-1.2811884651048504,-5.240298716656,1.5796226943973837,-1.3278652634197745,4.241617284415424,-0.3471495920910739,1.4899331388809034,1.007800993563867,2.763885446986367,-1.7971673725622885,4.168710606649214,0.28461796838076087,1.3786927007850924,1.0722047701723192,False,c3,1,"Hi please update login and create account buttons because the layout and look of them was changed in 1.20 when they separated them into create account and then login so please update the looks and the create account could be redirect to special request account. I am running Mediawiki 1.22 Wmf 20. I was told to file a bug here at https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Create_account_/_login_in_extension:confirmaccount
--------------------------
**Version**: unspecified
**Severity**: trivial
**Whiteboard**: aklapper-moreinfo",57468,-91,Needs Triage,True
3.7762496871859583,-11.677169090877515,-6.012983902028068,4.5642963438265465,-1.515664480466413,-1.166092518832906,1.419810419592637,0.5867290204859243,-3.5659351979724043,2.2314279440997318,4.48090173383423,0.04454549565182164,6.868390876341506,2.931569911425667,0.42851149855485104,-0.7240744651050617,0.06485555851534097,-0.31195119433594054,False,c3,1,"2013-10-06 12:01:48 mw1053 enwiki: [7b14de3f] /w/index.php?title=Special:UserLogin&action=submitlogin&type=signup&returnto=Special:UserLogin&returntoquery=article_action%3Dwatch Exception from line 109 of /usr/local/apache/common-local/php-1.22wmf19/includes/WikiPage.php: Invalid or virtual namespace -1 given.
#0 /usr/local/apache/common-local/php-1.22wmf19/includes/actions/WatchAction.php(124): WikiPage::factory(Object(Title))
#1 /usr/local/apache/common-local/php-1.22wmf19/extensions/MobileFrontend/includes/MobileFrontend.hooks.php(427): WatchAction::doWatch(Object(Title), Object(User))
#2 (): MobileFrontendHooks::onUserLoginComplete(Object(User), '<!-- do CentralAuth redirect -->')
#3 /usr/local/apache/common-local/php-1.22wmf19/includes/Hooks.php(199): call_user_func_array('MobileFrontendHooks::onUserLoginComplete', Array)
#4 /usr/local/apache/common-local/php-1.22wmf19/includes/GlobalFunctions.php(3898): Hooks::run('UserLoginComplete', Array)
#5 /usr/local/apache/common-local/php-1.22wmf19/includes/specials/SpecialUserlogin.php(926): wfRunHooks('UserLoginComplete', Array)
#6 /usr/local/apache/common-local/php-1.22wmf19/includes/specials/SpecialUserlogin.php(313): LoginForm->successfulCreation()
#7 /usr/local/apache/common-local/php-1.22wmf19/includes/specials/SpecialUserlogin.php(200): LoginForm->addNewAccount()
#8 /usr/local/apache/common-local/php-1.22wmf19/extensions/MobileFrontend/includes/specials/SpecialMobileUserlogin.php(15): LoginForm->execute(NULL)
#9 /usr/local/apache/common-local/php-1.22wmf19/includes/SpecialPage.php(631): SpecialMobileUserlogin->execute(NULL)
#10 /usr/local/apache/common-local/php-1.22wmf19/includes/SpecialPageFactory.php(489): SpecialPage->run(NULL)
#11 /usr/local/apache/common-local/php-1.22wmf19/includes/Wiki.php(291): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#12 /usr/local/apache/common-local/php-1.22wmf19/includes/Wiki.php(591): MediaWiki->performRequest()
#13 /usr/local/apache/common-local/php-1.22wmf19/includes/Wiki.php(460): MediaWiki->main()
#14 /usr/local/apache/common-local/php-1.22wmf19/index.php(55): MediaWiki->run()
#15 /usr/local/apache/common-local/w/index.php(3): require('/usr/local/apache/common-local/php-1.22wmf19/index.php')
#16 {main}
--------------------------
**Version**: unspecified
**Severity**: normal",57379,-91,Needs Triage,True
-2.6965358094509777,-0.9542191046568078,-0.49117173518635937,3.8607799747865457,-0.20919055994180952,2.1298415766043295,4.723690919562613,2.8163336591947146,-2.320689393320065,2.7333818746230394,-0.9648855983009494,1.5016929521808924,-1.8689963027818504,0.5389274704126832,1.216569233488598,-0.1243014748525566,-0.8788298098369454,0.04693811982156704,False,c3,1,"Although the ""Always use a secure connection when logged in"" check box is unchecked, de.wikipedia uses secure protocol for some users and also each explicit http page request is redirected to https.
https://de.wikipedia.org/wiki/Wikipedia:FZW#Sichere_Anmeldung
--------------------------
**Version**: wmf-deployment
**Severity**: normal",57368,-91,Needs Triage,True
5.9482525043995125,-3.363472499912737,-3.0260279307586497,1.5857293852290222,-0.6888796547752583,-2.783836607771293,-3.6222180340661083,0.03967813306134366,-1.815103015414591,-4.3365482512313145,-1.0318746121760243,-1.4611623287684128,8.724387922155984,4.708342960872336,3.1003544086079335,-1.3199228549117588,0.144123815581235,1.4239071235965055,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1136/
Reported by: Anonymous user
Created on: 2010-03-09 13:34:43
Subject: Login no longer available
Original description:
I get the following errors when using a known good user-config.py and family configurations for an SVN checkout of 2009-11-05. This is for a local wiki.
Using 2010-03-09, I get the following error on Ubuntu 9.04 \(Python 2.6.2\) and Ubuntu 8.04 \(Python 2.5.2\):
Logging into FamilyName:en as UserName via API
Error downloading data: No JSON object could be decoded
Request: en:/scriptpath/api.php?
Retrying in 1 minutes.... \(I changed line 152 of query.py to retry\_idle\_time\*0.01 so I could see the dump without growing a beard first\)
Dump output:
Error reported: No JSON object could be decoded
127.0.0.1
/hcrscript/api.php?
\{""login"":\{""result"":""Success"",""lguserid"":3,""lgusername"":""UserName"",""lgtoken"":""2b448df9379b445c225c0a5c1d3af18b"",""cookieprefix"":""DatabaseName"",""sessionid"":""3dd4cc3dd33236b57da8234d2f73e6d3""\}\}
on Ubuntu 9.04:
python version.py
Pywikipedia \[http\] trunk/pywikipedia \(r7983, 2010/03/09, 08:14:34\)
Python 2.6.2 \(release26-maint, April 19, 2009, 01:56:41\)
\[GCC 4.3.3\]
also broken on Ubuntu 8.04
python version.py
Pywikipedia \[http\] trunk/pywikipedia \(r7983, 2010/03/09, 08:14:34\)
Python 2.5.2 \(r252:60911, Jul 22 2009, 15:35:03\)
\[GCC 4.2.4 \(Ubuntu 4.2.4-1ubuntu3\)\]
But it seems to work fine on this system:
foreignhost:pywikipedia-2010-03-09 alex$ python version.py
Pywikipedia \[http\] trunk/pywikipedia \(r7983, 2010/03/09, 08:14:34\)
Python 2.5.2 \(r252:60911, Feb 22 2008, 07:57:53\)
\[GCC 4.0.1 \(Apple Computer, Inc. build 5363\)\]
Any ideas what's happening?
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1136",57285,-91,Needs Triage,True
2.24708115347998,-4.463216619852968,-2.529680523597982,1.2008114776579086,-2.932774167601081,-1.1418479567009536,-1.4957183550487203,1.3516931892992754,-1.3258892988676427,-2.928703352867459,-1.8836646786881623,-1.9113630505162764,3.887411423420921,1.3914006397060836,-1.0856434979132983,-0.9302293946126201,-0.13707039104153496,-0.20764814775357499,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1360/
Reported by: nakor-wikipedia
Created on: 2011-10-14 14:23:06
Subject: login.all always asks for password
Original description:
When calling
login.py -all -pass
the script first asks for a password and then asks for password for every sinmgle wiki site:
login.py -all -pass
Password for all accounts:
Password for user Almabot on mediawiki:mediawiki:
....
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1360",57232,-91,Needs Triage,True
3.229901906310427,-0.8985917360409665,-3.3863745548230177,6.73175330145532,-4.281926151788556,-6.893934161942432,-1.6212671459497425,-0.9467801580524643,-2.979690939400802,0.5154317717691077,-2.707788450993774,-0.08447185927762146,2.0737607266335116,1.8188081755527241,2.5263407490203464,1.9779425714866445,-1.0283309114112549,0.2447874482669523,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1488/
Reported by: reza1615
Created on: 2012-07-08 12:29:13
Subject: interwiki and login errors on en.wiki
Assigned to: xqt
Original description:
my bot \(Rezabot\) has a flag on en.wiki and it is not blocked there but it couldn't edit on there
File ""interwiki.py"", line 2296, in run
self.queryStep\(\)
File ""interwiki.py"", line 2274, in queryStep
subj.finish\(self\)
File ""interwiki.py"", line 1723, in finish
if self.replaceLinks\(page, new, bot\):
File ""interwiki.py"", line 1961, in replaceLinks
status, reason, data = page.put\(newtext, comment=mcomment\)
File ""/home/reza/pywikipedia/wikipedia.py"", line 2024, in put
newPage, self.site\(\).getToken\(sysop = sysop\), sysop = sysop, botflag=botflag, maxTries=maxTries\)
File ""/home/reza/pywikipedia/wikipedia.py"", line 2143, in \_putPage
self.site\(\).checkBlocks\(sysop = sysop\)
File ""/home/reza/pywikipedia/wikipedia.py"", line 5461, in checkBlocks
raise UserBlocked\('User is blocked in site %s' % self\)
pywikibot.exceptions.UserBlocked: User is blocked in site wikipedia:en
also my bots name is listed on \[\[Wikipedia:Bots/Status\]\] bot iterwiki code says it's name is not in the list\!
--------------------------
**Version**: compat-(1.0)
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1488",57183,-91,Needs Triage,True
1.5627401085848036,-2.127239825301709,1.7237482131985722,2.2060305982937445,-4.7412702915709435,-4.937514661358857,-3.205712455919856,0.7912028063649122,-0.4364388029613974,2.219691441756736,-1.4415322410456433,-1.0895533623627347,2.6953414173111456,0.4912178816883328,1.4566638094489557,1.1121146411705243,-0.020266309177642716,0.1358935010486524,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/
Reported by: Anonymous user
Created on: 2013-02-09 09:45:00
Subject: Can't login to wikisource.org
Original description:
I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script.
The following was outputted when I tried
family = 'wikisource'
mylang = ''
Traceback \(most recent call last\):
File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module>
import wikipedia as pywikibot
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module>
getSite\(noLogin=True\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite
\_sites\[key\] = Site\(code=code, fam=fam, user=user\)
File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper
return method\(\*\_\_args, \*\*\_\_kw\)
File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_
% \(self.\_\_code, self.\_\_family.name\)\)
NoSuchSite: Language does not exist in family wikisource
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1572",57154,-91,Needs Triage,True
0.13732386548088815,-0.8088587332420936,-0.1351564417159512,1.674612861146596,-0.4647782435134676,-1.7192598098241882,-1.9399221956416888,-1.2926045629724254,-0.47119287279669664,-2.8758232830475032,-2.4113536926293024,-1.9089165232011043,3.4318033146354927,2.229332700030489,2.12418802053274,-0.9402937292814157,0.09734204020940296,-0.2801791371258502,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1632/
Reported by: nu11zer0
Created on: 2013-05-03 05:54:46
Subject: force login after performing a sysop action
Assigned to: russblau
Original description:
After my bot performed a sysop action, then wrote to a page, the bot wrote without botflag\! It seems that the framework cached some informations and understood that the bot has no flag. My workaround is to add ""site.login\(\)"" after every sysop action. But it should be implemented in the framework. Note that now redirect.py also has this problem.
\----
Pywikibot branches/rewrite/ \(r11487, 2013/05/02, 07:59:55, ok\)
Python 2.7.3 \(default, Sep 26 2012, 21:53:58\)
\[GCC 4.7.2\]
unicode test: ok
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1632
https://bugzilla.wikimedia.org/show_bug.cgi?id=55066",57140,-91,Needs Triage,True
7.566848998351947,-6.542439722520028,7.240293012307376,2.5633149064568204,-1.7528628175568588,-1.9849634473029032,4.231711673337517,-2.5131366270278557,-0.07398908959142725,-0.45763568966474377,-1.0757278440428824,-0.617704127656972,-1.891394775288016,0.24574008243643863,-0.25004619384568105,-0.18424162762677354,0.4272509164907803,-0.4717420521691078,False,c3,1,"**Author:** `metatron`
**Description:**
HTTPS on both wmflabs-sites not possible:
http://icinga.wmflabs.org/icinga/
http://ganglia.wmflabs.org/latest/
On wikimedia-sites it works fine
https://icinga.wikimedia.org/icinga/
https://ganglia.wikimedia.org/latest/
--------------------------
**Version**: unspecified
**Severity**: enhancement",56710,-92,Needs Triage,True
0.37314431262717607,-2.8676317284323876,3.964361969305074,-3.331938225308046,-3.7908006359539916,1.9502469778627274,-4.133012889295884,1.7420691879590988,-0.6260325188051983,-3.1885872562516355,-1.7997184704434621,-3.140495340612664,3.2436858155726016,2.591252434606381,0.3464419871323017,-1.4917679799233305,-0.9271077539964044,-0.404419011303484,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/patches/621/
Reported by: gallaecio
Created on: 2013-08-03 20:30:54.056000
Subject: When loging in to a site, try the site-configured username if any
Original description:
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/patches/621",56541,-93,Needs Triage,False
-5.958197358107558,3.2875733023322056,1.8290750975905148,-0.026716029242400463,0.8995240878475599,-0.8723581588952366,2.1648347864776403,-3.5573255243522355,0.4476917047708042,-2.053977952331028,-3.0163520318101393,-1.7687740709097646,-3.2434059128955344,2.778279550811564,-1.485161747110375,-0.4706236306156407,1.5451246744992215,-1.2029108672929185,False,c3,1,"Grepping through the code shows no use of this variable outside of its declaration. It certainly doesn't remove the login link.
--------------------------
**Version**: master
**Severity**: normal",56506,-93,Needs Triage,True
-3.2021144719892827,-0.17372299830123872,3.8075641004471166,-0.6890810807320813,-4.856924113315836,-8.189427062269646,3.8403353003220664,-1.342567203629811,0.39010056442340835,0.7073541628859852,0.2212276288565005,0.7503927474541152,0.09626232451257,0.8816572006911692,-0.6849101038023946,-0.4814041472189081,-1.0608461092316648,-0.51249320909198,False,c3,1,"Please enable HTTPS on parsoid.wmflabs.org. Unsure if it needs it's own certificate or if there is one for *.wmflabs.org.
It recently had CORS enabled so users can write custom scripts to access parsoid, however they'll face mixed content blocking issues since HTTPS doesn't work yet.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://parsoid.wmflabs.org",56192,-94,Needs Triage,True
-4.5101162782788045,7.617352061584064,-0.5325537573728507,3.765643754140828,2.126814359088816,4.30701495759789,-0.014006331847904008,0.5399605921273269,-0.5715542227622237,-1.683581891834323,-2.3386996593340608,-1.1101583836212907,-1.1324694553418562,0.8183163514632517,-0.23103839020762607,0.16679851795489925,0.5896819127567026,-1.8356461007918239,False,c3,1,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.
rfc5849 - 2.3 says that:
Since the request results in the transmission of plain text
credentials in the HTTP response, the server MUST require the use of
a transport-layer mechanism such as TLS or SSL (or a secure channel
with equivalent protections).
However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.
--------------------------
**Version**: master
**Severity**: normal",56110,-94,Needs Triage,True
6.17691203435729,0.32510387831221266,0.10057421471859129,-12.108672597581227,-1.4292801850841959,-2.29621679644978,-1.542608612999878,-3.972274152712819,3.9542350966152506,1.756348863909686,1.7487277632045157,0.12249490236182026,2.025194680625113,-2.137876705946399,-0.47254960887605435,-1.6349274778332383,0.18819590459275304,0.8582007229711615,False,c3,1,"We switched to Labs hoping that it would bring us HTTPS, but apparently not.
I created an instance with this enabled:
- role::lamp::labs
- certificates::star_wmflabs_org
But Firefox says ""Unable to connect"": https://i-000008da.pmtpa-proxy.wmflabs.org
Am I missing something? What should I do to allow visitors to connect via SSL?
--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48501",56065,-94,Needs Triage,True
26.550520659744475,1.2580945778626944,-17.038750241131456,10.189331729835358,0.23612446936418774,-1.498309494039892,7.2385757996929785,-0.21667540528850726,-0.6847921503377246,-0.03457066486046578,-0.5915350075755716,4.269080481348831,-1.6377306156390778,-0.5785903321795054,0.5579619878397057,-0.1715253810889712,-0.554122064384386,-0.38344847697660245,False,c3,1,"metrics.wmflabs.org gebruikt een ongeldig beveiligingscertificaat.
Het certificaat wordt niet vertrouwd, omdat het zelfondertekend is.
Het certificaat is alleen geldig voor wikimetrics.pmtpa.wmflabs
--------------------------
**Version**: unspecified
**Severity**: normal",55892,-95,Needs Triage,True
-0.3849615273583429,2.5488511741094193,-1.98812855524889,-2.2819267948219606,-6.314328688902721,0.509583780972148,-1.8315960457147762,0.6139515079883229,-0.8661903714598987,-2.799131821740674,-2.129676132181357,-0.7217559354856915,0.26305603701841296,-0.4403036153606399,-1.9501438438234562,1.83595948351508,0.3998236099157262,0.2845865883105383,False,c3,1,"**Author:** `winne2i`
**Description:**
After recent changes in HTTP/HTTPS logging in for users there's a problem*.
Google search results point to HTTP versions of articles but users are not logged in while on HTTP. This enforces users to reload page or re-log in.
I see some solution in bug 51002 ?
*)Although this also occured before but user could login via HTTP (and optionally use a DIY script in common.js to redirect to HTTPS).
--------------------------
**Version**: unspecified
**Severity**: normal",55703,-96,Needs Triage,True
1.0100475459467089,1.4875013858745554,4.344854179120436,-7.169529598367902,-5.0203546769650735,1.1237749620686504,2.5590210460709715,3.179756760163628,1.7955362960098313,1.8231318316740603,1.974438514057105,3.6799821691261343,1.0286530435093315,1.4387852571506876,-1.9274268056526895,-2.0723077627455964,-2.0144753251141148,-2.3025924729724343,False,c3,1,"See https://tools.wmflabs.org/liangent-php/detectProtocol.php/enwiki
Feel free to move this bug to MediaWiki product if there's some reliable way to check so there while MediaWiki is unaware of it.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64627",55689,-96,Needs Triage,True
11.380398753468008,-5.786632347156631,-0.10773421188941512,1.2740201394717934,-1.650896251387112,-4.335413224263722,-13.705826803554842,0.23408189388084205,-3.202255037674388,0.02931205554092653,5.370860257405472,1.2405855581880194,-4.946497815381954,0.15173857629721166,1.434352422099277,-2.47340619283796,-0.548341931817853,0.704811863942352,False,c3,1,"https://bugzillapreview.wmflabs.org/search/query/open-tasks/ gives:
Unhandled Exception (""HTTPFutureHTTPResponseStatus"")
Unhandled Exception (""HTTPFutureHTTPResponseStatus"")
[HTTP/400] {""error"":""SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[kVa6pnbJSEyw1PlUSHyE1A][phabricator][0]: SearchParseException[[phabricator][0]: query[ConstantScore(+cache(BooleanFilter(_field_names:relationship.open.phid)))],from[-1],size[-1]: Parse Failure [Failed to parse source [{\""query\"":{\""filtered\"":{\""query\"":{\""match_all\"":{}},\""filter\"":{\""and\"":[{\""exists\"":{\""field\"":\""relationship.open.phid\""}}]}}},\""sort\"":[{\""dateCreated\"":\""desc\""}],\""from\"":0,\""si...",891,-36,Needs Triage,True
-1.3510614441380446,11.263117807868845,3.4554299952078047,2.12380543882243,1.9098337152282148,1.2238917067005668,-2.3748926609838414,-3.2026095149378873,-3.918013498290537,5.377235543664192,-0.48392760672024515,3.1046587798445584,0.025225771646280926,-2.056477916248983,2.5861943977198765,0.42458339661978894,-1.6311846330858917,2.358187688436181,False,c3,1,"In https://phabricator.wikimedia.org/auth/start/ the current button says ""MediaWiki login"" and features the MediaWiki sunflower.
Since this is in fact a Wikimedia login, it would be consistent to show ""Wikimedia"" and the [[ https://commons.wikimedia.org/wiki/File:Wikimedia-logo.svg | Wikimedia logo ]].
Proposing this task as pre-Day 1 because it is related with the ""out of the box experience"", where it is worth polishing these details.",543,-39,Needs Triage,True
7.634679151628227,9.502058572998305,7.333093404695088,-2.2885665807817483,-0.09428760286433996,5.093814802640066,-2.060261210739814,-2.9522599508262006,2.770870964207682,2.1727289420003535,0.9888739458839209,-0.9004351597189113,-2.565919968698596,1.9362105231464808,0.5712282158659567,-1.3645356607332824,-1.69452714229578,0.5193654822891796,False,c3,1,"I would like to ask, if my little project [[ https://www.mediawiki.org/wiki/Extension:GoogleLogin | GoogleLogin ]] can become a project place here in phabricator?
The Extension provides a ""Login with Google"" functionallity to MediaWiki to login into the MediaWiki account using the Google Login information.
If yes: The standard permissions looks good :)
Reference: http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077767.html",316,-50,Needs Triage,True
-12.704015817733152,-1.0639541701705433,3.1460973769862335,19.785485906041004,-2.755473928845213,-5.7054063909625645,-5.003649398784289,1.1328867466638615,6.125107036244543,10.641578594484795,9.54411666219764,2.706023986187759,-4.794797968965789,1.0741976973168237,2.880906556979558,-1.8986496423736714,-3.9666265456823924,1.1549484506342467,False,c3,1,"[] change puppet database module to add a new read-only user named ""research""",76109,-32,High,True
0.14714476065761461,1.0441444552744557,-2.217647241517625,-2.92417869027122,3.8720093990208606,0.7510204961872431,0.9726748485328303,-0.021812480579957383,-0.3232001741108971,-1.4671317741639736,-0.16774583987840108,0.6512613149141537,0.9595123459954391,-0.20989036729402422,1.1293831766956215,-0.2533277756205444,-0.32683196751303445,0.2538029915911244,False,c3,1,"**Author:** `axel+wikimedia`
**Description:**
Hi,
When trying to make a donation, after entering the amount I wanted to donate I was redirected to a server, ott9.wpstn.com.
From what I can tell, it's a WorldPay.ca (payment processor) server.
Having configured Firefox to refuse all connections using the RC4 cipher for SSL/TLS (as RC4 is deprecated and considered insecure), I was not able to establish a connection to the server (Firefox shows the “no cipher overlap” error).
An SSL test for the domain shows that it indeed offers RC4 (and nothing else):
https://www.ssllabs.com/ssltest/analyze.html?d=ott9.wpstn.com
This is bad. RC4-encrypted traffic has been likened by some infosec researchers to “no encryption” and the NSA can allegedly break it in real-time.
Here is the (very poor) list of ciphers offered by the server:
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH 571 bits (eq. 15360 bits RSA) FS 128
Furthermore, the server is still offering SSLv3. That should also be disabled, following the POODLE vulnerability published about a month ago.
The server should be offering modern encryption (forward secrecy, no SSL, strong non-deprecated ciphers).
Here is a good guide on how to do it on Apache2:
https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html
I hope this can be resolved quickly as the Wikipedia fundraising campaign is ongoing and I don't feel comfortable giving in such conditions nor recommending others do so, even if I believe it is really important they do support Wikipedia, when the payment processor's security is in such a sad state.
--------------------------
**Version**: wmf-deployment
**Severity**: major",75644,-32,High,True
6.439907215902361,1.2470393614615443,-0.9534747390414751,1.7880255123908801,-0.558153500335806,-1.4690218544702045,-0.31477422727818904,1.440478629017174,-3.2640664784229454,-2.0203439134634347,0.530581489573426,-0.14234458293393581,5.800073465074256,2.964123885757071,1.768764210141442,-0.2199677043632089,-0.04453659236053742,0.3364827993193924,False,c3,1,"**Author:** `sushant_savla`
**Description:**
Screen short showing error
----
Users unable to login in most cases, getting error 503 from varnish in return of the login form. If an incorrect password is entered, the form gracefully reloads. The issue seems quite widespread but is hard to reproduce: at least 5 users across 4 wikis.
For each affected user, the issue is often user account- and/or wiki-specific: sometimes a user is unable to access an increasingly large number of wikis; sometimes bypassing caches helps. No other pattern was detected.
Asked for some multi-week grep -c for action=submitlogin&type=login 503 errors in logs, requires shell user.
Some example timestamps: 15 Nov 2014 11:53:10 GMT, 08 Dec 2014 12:32:30 GMT, 08 Dec 2014 12:59:58 GMT, 10 Dec 2014 15:39:46 GMT, 11 Dec 2014 13:18:26 GMT.
----
When i try login in throogh Mozilla Fire fox i get error message sinc last 4 -5 days.
screen shot of error message enclosed/
Error reads
Wikimedia Foundation
Error
Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: POST http://gu.wikipedia.org/w/index.php?title=%E0%AA%B5%E0%AA%BF%E0%AA%B6%E0%AB%87%E0%AA%B7:%E0%AA%B8%E0%AA%AD%E0%AB%8D%E0%AA%AF%E0%AA%AA%E0%AB%8D%E0%AA%B0%E0%AA%B5%E0%AB%87%E0%AA%B6&action=submitlogin&type=login&returnto=%E0%AA%AE%E0%AB%81%E0%AA%96%E0%AA%AA%E0%AB%83%E0%AA%B7%E0%AB%8D%E0%AA%A0, from 10.64.0.103 via cp1055 cp1055 ([10.64.32.107]:3128), Varnish XID 3251470154
Forwarded for: 120.60.225.75, 208.80.154.77, 10.64.0.103
Error: 503, Service Unavailable at Sat, 15 Nov 2014 11:53:10 GMT
Same problem is not there in IE or Opera.
----
**Attached**: {F15399}",75462,-33,High,True
-5.65079693392186,0.9999557912190635,-4.616560673573359,-2.4215368407214752,-4.176736769435779,1.004983567876175,1.5820942244738214,-0.48914002869359785,-0.4899354203919693,-1.1434816637287586,-1.1405267739495992,0.4495358399885918,-0.4140469820511612,-0.08060933081953081,-1.0150084503118375,-0.0980481965510197,-0.001617302015834099,-0.5768661851988264,False,c3,1,"It also happens for alpha mode (yay!), i want to have a bug for this for tracking purposes.
The login page of MobileFrontend actually is provided by it's own implementation to fit the needs of mobile devices. It isn't really needed anymore, the login page customisations should be done with special css rules or in core. Actually it's difficult to overwrite the loginpage for other extensions (like GoogleLogin), if MobileFrontend loads after this extension.
--------------------------
**Version**: unspecified
**Severity**: normal",74910,-35,High,True
13.81390638379516,-8.480243399275825,9.782407166517284,0.8868734831514664,-0.6522167848748557,-2.124146238881779,0.6130758474391138,-0.5331518792991587,2.1388692201337953,-1.1231919300346624,-1.4971242430483787,-0.7188442342559913,-0.072440810823589,-2.271273820813762,0.06517630992255974,-0.8956901264641346,0.20937884510353189,-1.380700092827754,False,c3,1,"Found on https://github.com/EFForg/https-everywhere/issues/686
timmc said:
> Wikimedia [Foundation] sent me an email asking me to donate like I did last year:
>
> http://links.email.donate.wikimedia.org/ctt?kn=X&ms=XXXXXXXXXXXXX&r=XXXXXXXXXXXXXXXXX&b=X&j=XXXXXXXXXXXXX&mt=X&rt=X
Reedy said:
> ""This server could not prove that it is links.email.donate.wikimedia.org; its security certificate is from *.links.mkt41.net. This may be caused by a misconfiguration or an attacker intercepting your connection.""
Italian donor said:
> Il link riporta a questo sito: http://links.wikimedia.mkt4477.com/ctt?...............
--------------------------
**Version**: wmf-deployment
**Severity**: major
**URL**: https://links.email.donate.wikimedia.org/
**See Also**:
https://github.com/EFForg/https-everywhere/issues/686
https://bugzilla.wikimedia.org/show_bug.cgi?id=58373",74514,-36,High,True
5.580543287516715,-1.5755881424000986,-3.473030560584565,-3.119948407317076,-2.8927550653606606,0.5385723596674732,-2.485679272263763,2.0920730463846313,-0.020866416859659342,-2.3440533918424613,-0.648527645553834,-1.1540215495046742,4.67400949943334,0.6001482673827274,0.9428880552231291,0.5823103011097848,-0.43104408115543946,-0.3357936284945442,False,c3,1,"Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0.
Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6.
See also:
* http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy
* https://gerrit.wikimedia.org/r/#/c/159159/
* https://bugzilla.wikimedia.org/show_bug.cgi?id=70570
Example of HttpRequest failing on PHP 5.6:
https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342)
--------------------------
**Version**: unspecified
**Severity**: major",73729,-39,High,True
11.20876951636835,0.8543065353099024,-6.258057220906855,5.593458045173114,-1.6454180804168823,0.8314492293671449,0.7321918956595379,-1.4923857533791822,0.6275598494446811,-2.4780034644625846,-2.2062428689937317,-0.44773310399688626,0.41366764224002006,1.0085456434592635,0.6081700172748219,-0.665275000195866,0.03585644304772284,-0.20025338963171113,False,c3,1,"The wikimedia/iegreview project is using a PSR-4 autoloading scheme (just like PSR-0 except you don't have to have a bunch of empty directories in your path to define the full namespace).
The phpunit job for this repository is failing with this error:
PHP Fatal error: Call to undefined method Composer\Autoload\ClassLoader::setPsr4() in /srv/ssd/jenkins-slave/workspace/wikimedia-iegreview-phpunit/vendor/composer/autoload_real.php on line 33
PHP Stack trace:
PHP 1. {main}() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/composer/bin/phpunit:0
PHP 2. PHPUnit_TextUI_Command::main() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/composer/bin/phpunit:63
PHP 3. PHPUnit_TextUI_Command->run() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:129
PHP 4. PHPUnit_TextUI_Command->handleArguments() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:138
PHP 5. PHPUnit_TextUI_Command->handleBootstrap() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:606
PHP 6. PHPUnit_Util_Fileloader::checkAndLoad() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:778
PHP 7. PHPUnit_Util_Fileloader::load() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/PHPUnit/Util/Fileloader.php:76
PHP 8. include_once() /srv/deployment/integration/phpunit/vendor/phpunit/phpunit/PHPUnit/Util/Fileloader.php:92
PHP 9. require() /srv/ssd/jenkins-slave/workspace/wikimedia-iegreview-phpunit/tests/bootstrap.php:24
PHP 10. ComposerAutoloaderInit219a9bfa76f2ac9b53cf75ea98d99ffa::getLoader() /srv/ssd/jenkins-slave/workspace/wikimedia-iegreview-phpunit/vendor/autoload.php:7
After a lot of head scratching I figured out that this is caused by the vendor/composer/ClassLoader.php that is loaded from the integration/phpunit project to run phpunit. This older version of the \Composer\Autoload\ClassLoader class shadows the newer version present in wikimedia/iegreview/vendor/composer/ClassLoader.php.
The fix for this should be as easy as regenerating the classloader for the integration/phpunit project using a newer version of Composer that supports PSR-4 autoloaders.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",73629,-39,High,True
4.512439915548551,-3.356834850454577,4.56817290472706,0.5624550241398558,0.7544875286527948,0.7303392604449508,2.2985736807333117,-0.682265406857409,-0.9244506684780351,0.6436734851099768,2.0493564916231777,1.3031006667087788,2.442003585592742,-0.7250641719877287,0.4582469647616678,-1.0164725718675174,-0.3671756480867716,-0.1077247155038541,False,c3,1,"Reproduced on mw.org: https://www.mediawiki.org/wiki/Special:UserLogin
The logo at the top left side is missing. It is visible on all other pages.
--------------------------
**Version**: 1.25-git
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Special:UserLogin
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56257",73334,-40,High,True
3.917565030736687,-3.4459764864297373,-7.064546458865493,1.91624014079947,-1.856821560901726,-3.3398165338049965,-11.352665489551214,2.105969432363517,-1.8519091313101874,-6.348545982226106,10.735676270360713,2.1138666297211897,-8.802446041675267,-0.15258203496799183,1.201594715520919,-1.3929119769897862,0.872692969980281,0.02392346970417214,False,c3,1,"SHA1 certificates still existing in our repo (as of 2015-05-29):
Intermediary SHA1 certificates (some of these will cease use when SHA1 certs are replaced, some won't, need to note which):
[ ] - (*.planet.wikimedia.org uses this) DigiCertHighAssuranceCA-3.crt
[ ] - RapidSSL_CA.crt - all rapidssl certs in sha256 appear to use RapidSSL_SHA256_CA_-_G3.crt. Once all sha1 rapidssl are replaced, this can be removed from the repo
Completed:
[x] - civicrm T104378 (reissue complete, pending service implementation)
[x] - frdata T104378 (reissue complete, pending service implementation)
[x] - fundraising T104378 (reissue complete, pending service implementation)
[x] - payments-listener T104378 (reissue complete, pending service implementation)
[x] - RapidSSL_CA_2 - all rapidssl certs in sha256 appear to use RapidSSL_SHA256_CA_-_G3.crt. Once all sha1 rapidssl are replaced, this can be removed from the repo (this was gone before robh could get to it)
[x] - ldap-mirror.wikimedia.org.crt T105187
[x] - star.planet.wikimedia.org.crt
[x] - ganglia.wikimedia.org.crt T100825
[x] - git.wikimedia.org.crt T100827
[x] - icinga.wikimedia.org.crt T100830
[x] - librenms.wikimedia.org.crt T100831
[x] - lists.wikimedia.org.crt T100832
[x] - svn.wikimedia.org.crt - expired
[x] - tendril.wikimedia.org.crt T100835
[*] - ticket.wikimedia.org.crt T91504 T104634
[x] - star.wmflabs.crt : T104017
[x] - star.wmflabs.org.crt : T104017
[x] - wikitech.wikimedia.org.crt T92709
",73156,-41,High,True
-6.373689585097429,0.5952376217928066,-1.1278457374607243,-4.884041253494091,-5.359798955894094,-3.881913968415077,0.8195492823565811,4.353057691506568,-0.9769176985424095,-0.17573835936882443,-1.0253378737288679,-2.8511526220398764,-0.3242496284432077,0.32715138539845157,-1.163864944569596,3.0152231137320378,1.6631205605313133,-0.22396285385010128,False,c3,1,"If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out.
This is annoying and shouldn't have happened.
--------------------------
**Version**: 1.24rc
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=71066",72855,-42,High,True
-7.251885667195383,-2.018289839829439,-0.7326251325760271,3.6879980391362253,-1.5873674828507927,0.11533223841475904,1.5408443295096905,-0.2613526758658731,-1.0267717784877823,-0.6650820681921825,0.7349115979770073,-0.23031601052698125,2.47565837901308,-2.6305540875244056,0.28249282360165573,0.4662428118996561,1.8583796543509286,0.08896489678224095,False,c3,1,"If $wgCentralAuthAutoMigrate is set to true, when a user logs in and has no global account, in case all local accouns with same username match the email and/or password, create a global account and merge everything.
It was noted on https://meta.wikimedia.org/?oldid=9740729#RenameUser_announcement that this case is fairly frequent and not handled by $wgCentralAuthAutoMigrate yet. Bug 69291 should have taken care of all the unmerged accounts sharing email.
Example: https://tools.wmflabs.org/meta/stalktoy/Nemo+nonies , two local accounts with same password and no email set; I logged in for both and no global account was created.
--------------------------
**Version**: unspecified
**Severity**: enhancement",72392,-43,High,True
19.24675915405578,5.00926312259789,-10.59973567316871,-0.6046802561424737,-0.9929098216850964,-0.8520955386852851,-1.2522199915129208,-0.5855271099188178,0.4926471920992561,-0.7124861343237185,0.2619060758066172,-1.2740079305872778,0.7820819902544973,-0.6160468635555514,-0.8454560949980188,-0.1987452757702266,-0.8665870223463945,-0.32332046131735925,False,c3,1,"I'd like to get a more modern version of node installed in Tools Labs for the anon project. Right now we have v0.8.2 installed but v0.10.31 is available if we add another apt repository:
apt-add-repository ppa:chris-lea/node.js
I get an error when attempting to npm install packages (see below). I believe this error is the result of an older version of npm that comes with v0.8.2. I installed v0.10.30 locally and the problem went away. I would like to have a more modern node installed so I can use the open grid engine to manage the anon bot. Right now I have it running using a locally installed version of node in /data/project/anon/node/
Error: SSL Error: SELF_SIGNED_CERT_IN_CHAIN
npm ERR! at ClientRequest.<anonymous> (/usr/lib/nodejs/npm/node_modules/request/main.js:440:26)
npm ERR! at ClientRequest.g (events.js:185:14)
npm ERR! at ClientRequest.EventEmitter.emit (events.js:88:17)
npm ERR! at HTTPParser.parserOnIncomingClient [as onIncoming] (http.js:1445:7)
npm ERR! at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:111:23)
npm ERR! at CleartextStream.socketOnData [as ondata] (http.js:1356:20)
npm ERR! at CleartextStream.CryptoStream._push (tls.js:396:27)
npm ERR! at SecurePair.cycle (tls.js:750:20)
npm ERR! at EncryptedStream.CryptoStream.write (tls.js:131:13)
npm ERR! at Socket.ondata (stream.js:38:26)
npm ERR! [Error: SSL Error: SELF_SIGNED_CERT_IN_CHAIN]
npm ERR! You may report this log at:
npm ERR! <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR! <npm-@googlegroups.com>
npm ERR! System Linux 3.2.0-59-virtual
npm ERR! command ""nodejs"" ""/usr/bin/npm"" ""install""
npm ERR! cwd /home/edsu/Projects/anon
npm ERR! node -v v0.8.2
npm ERR! npm -v 1.1.39
npm ERR! message SSL Error: SELF_SIGNED_CERT_IN_CHAIN
npm http GET https://registry.npmjs.org/coffee-script
npm http GET https://registry.npmjs.org/ipv6
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! /home/edsu/Projects/anon/npm-debug.log
npm ERR! not ok code 0
--------------------------
**Version**: unspecified
**Severity**: critical",72120,-44,High,True
-0.2534781327624156,-1.7029923408532657,-0.9644235486459003,-3.5860767700524665,0.1475375011677812,-5.259968539627301,0.7537000247129395,-4.113369035202253,0.30424888942886497,1.7352269969292795,0.7575474907686361,0.8077532046209557,0.39413748121912695,-0.94739315641911,-1.581945441212953,1.998631398956816,0.9180312873072605,2.1334048867240307,False,c3,1,"Unable to login and reset password: ""Invalid hash given"" in all cases
Greetings!
User Yustas is having trouble with login and password reset. He hasn't been logging in for a while. Now, he tries to login, but can't. He has email entered: yustas@yustas.com. He tries to reset password and successfully receives reset email. But when he enters old and new passwords, he sees permanent ""Invalid hash given"" message (I have attached the screenshot received from him). He tried several browsers and OSes.
Please help him. You can contact him directly at the email given, or at talk page at Commons https://commons.wikimedia.org/wiki/User_talk:Yustas
--------------------------
**Version**: wmf-deployment
**Severity**: major
**Attached**: {F14304}",72098,-45,High,True
1.0849576384790924,-2.573810952861498,-2.2720971213327417,-0.6983430899848038,-0.418828649570945,-1.4282421954063238,-0.5036480627702629,0.4842616279612588,-1.537975390378314,-0.007821975504365142,1.286696441498329,-1.195877126258536,3.9461611058734167,2.2791483786031828,0.6401091199340874,0.23052569833535674,-0.07259640566410996,0.5030953382061176,False,c3,1,"I'm used to entering the URL https://<host>/wiki/Special:UserLogin to login with a different username. It would warn ""You are already logged in as S Page (WMF). Use the form below to log in as another user."" and let me do just that.
However, now when I do this on beta labs when I'm already logged in, I get a 302 redirect and then Internal error exception from http://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=921d7ed90f5b780db73c89673f1bb6d6 ""The user account logged into does not exist."" The full display is below.
The workaround is to click Log out or visit Special:Logout, then log in.
As I recall, visiting Special:UserLogin while logged in on mediawiki.org a week or so ago would just redirect me to the main page (not ideal but better than an exception); but now I'm getting the same Internal error exception except the production cluster truncates it to a pink ""[7ed77f38] 2014-08-21 08:02:15: Fatal exception of type MWException"".
Below is the full error display on beta labs:
[82d43ccf] /wiki/Special:CentralLogin/complete?token=921d7ed90f5b780db73c89673f1bb6d6 Exception from line 167 of /srv/common-local/php-master/extensions/CentralAuth/specials/SpecialCentralLogin.php: The user account logged into does not exist.
Backtrace:
#0 /srv/common-local/php-master/extensions/CentralAuth/specials/SpecialCentralLogin.php(33): SpecialCentralLogin->doLoginComplete(string)
#1 /srv/common-local/php-master/includes/specialpage/SpecialPage.php(363): SpecialCentralLogin->execute(string)
#2 /srv/common-local/php-master/includes/specialpage/SpecialPageFactory.php(516): SpecialPage->run(string)
#3 /srv/common-local/php-master/includes/MediaWiki.php(300): SpecialPageFactory::executePath(Title, RequestContext)
#4 /srv/common-local/php-master/includes/MediaWiki.php(609): MediaWiki->performRequest()
#5 /srv/common-local/php-master/includes/MediaWiki.php(460): MediaWiki->main()
#6 /srv/common-local/php-master/index.php(46): MediaWiki->run()
#7 /srv/common-local/w/index.php(3): include(string)
#8 {main}
--------------------------
**Version**: master
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69565",71834,-45,High,True
-9.737791926337344,3.606074474958632,-0.3664163286863449,1.1042727063751174,-2.301832860115457,7.458616595578509,1.2886453197086798,-1.7521665331234026,-1.2302099394302828,-0.1923057248307396,1.8060842318885313,-2.123023638066984,-1.9681647033897205,1.4744001024901516,-0.5835332110419484,0.8594979238653854,-1.6848034229992304,-0.18861454779183195,False,c3,1,"makecat has its main loop at the module level, rather than in a function main() like other scripts.
This causes a deadlock in handleArgs while trying to fetch the live API version.
--------------------------
**Version**: core-(2.0)
**Severity**: major",71781,-46,High,True
-1.2320714990049297,8.652627016175693,1.3458130781921014,2.50339163288017,-0.3362688902747602,4.989116285686861,0.45860456367252134,-2.3949606495678117,-0.21427973915923587,-0.883540407012819,-0.969467545175767,3.712321560433778,-0.7151127749671637,0.48446802412514867,0.17320944512374492,-1.3796473108377472,-1.1611706772019856,-1.9129607464231673,False,c3,1,"Comes from: https://www.mediawiki.org/wiki/User_talk:Florianschmidtwelzow#Continous_Redirect
If $wgGLreplaceMWLogin is true the user will be redirected to the Create an account page if he tries to create an account without any error message.
--------------------------
**Version**: master
**Severity**: critical",71199,-48,High,True
-3.270048526016355,-0.49318754913189444,-2.5337079988459124,-5.212725977501172,-1.927288467375714,-3.1507098903336894,2.035070209142712,5.246718072020492,4.939704394576093,1.8914866939760362,1.7656475711232589,0.2706884566645553,1.2514898109962522,1.7263469247723755,-1.851408068635588,-0.5131867527188139,0.876915580027035,2.193963864281847,False,c3,1,"Navigate to Login on Opera Mini browser – you'll see two blank fields that don't indicate where to enter your username or password. From there, navigate to create account and it's even worse – no indication of where to enter username, password, email, or CAPTCHA. Effectively, this makes creating an account impossible, and login also quite difficult.
--------------------------
**Version**: unspecified
**Severity**: normal",70758,-49,High,True
4.553908382239113,-2.427256835914646,1.1019101673977865,-6.10622564275504,0.5092413207699522,-6.431436703608473,0.4673941923056022,-2.338155487753567,2.9079119056251175,-1.834060183414688,-0.9715624193296004,1.496517907818059,-0.13934189507671668,0.07491814231154326,-1.8705056535388502,0.9971230548122068,-1.211470428528459,0.5587880465280752,False,c3,1,"Screenshot
I cannot login to Betalabs, it is showing the following error even though I have cookies enabled:
Login error
Wikipedia uses cookies to log in users. You have cookies disabled. Please enable them and try again.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63981
**Attached**: {F14355}",70044,-51,High,True
-1.943451970310766,3.8013507132857214,0.03797772539877187,-9.637706726142184,0.22892227015060507,-3.5020116255109377,-1.8736495027915296,-6.073790766363483,-2.538088523057003,1.1573560009027313,-1.2654405807249782,2.5854352209438423,-0.08915120977491586,-4.015327233759821,2.688387268531449,0.565749233700006,0.48266230560352397,0.1726589694998999,False,c3,1,"As a user who has been renamed during SUL migration
I want to login with my old name and password
So I can continue to use the wiki
As a user who has been renamed during SUL migration
I want to know that I was renamed
So I can learn my new name and/or ask for a new name
Given that I authenticate with ""username"" and ""password""
When ""password"" is not valid for ""username""
AND ""password"" is valid for ""username~<WIKI>""
Then I am logged in as ""username~<WIKI>""
AND I am redirected to the SUL account renamed page
Given that I am logged in
When I am redirected to the SUL account renamed page
Then I am told my account was renamed to NEW_NAME
AND I am asked to log in using that name in the future
AND I am told how I can get my new account renamed
AND I am told why all this happened
AND I am given a link to the page I wanted to visit
--------------------------
**Version**: master
**Severity**: enhancement",69995,-51,High,True
3.397388324326315,-7.07326079168269,-4.415942239889848,-2.966549828503381,1.722200598398297,-0.9079806131870114,0.2319296948137639,1.4129125379682943,-1.2908864523197616,0.4910924245702688,2.220440582945766,0.12004901587966743,3.2945632139958567,-1.0175523859295268,-0.6306501331102536,-0.07985634067273095,0.8521423496104876,0.9115679803498022,False,c3,1,"Originally I posted this issue under Bug 53259, but I find more and more vulnerable sites, so I think it is more appropriate to move to a new bug report.
According to SSL Labs these servers are ""vulnerable to the OpenSSL CCS vulnerability (CVE-2014-0224) and exploitable"":
* graphite.wikimedia.org
* gdash.wikimedia.org
* dumps.wikimedia.org
* noc.wikimedia.org
These are vulnerable but probably not exploitable:
* ganglia.wikimedia.org
* lists.wikimedia.org
[1] https://www.ssllabs.com/ssltest/analyze.html?d=noc.wikimedia.org
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53259
https://rt.wikimedia.org/Ticket/Display.html?id=7806",69564,-52,High,True
-6.849713049150281,6.136797507784749,4.061625684438585,2.9662644247727306,-3.3817363251209462,8.211668991682178,-1.407993538516922,0.6240419529286889,3.4104639170735185,1.324948413295668,-2.3971575786613153,-0.8022729474436114,-1.9671463024639637,0.38327965931050745,2.0976852702443267,-0.9136466362012119,1.72958098469517,-0.20469947519517495,False,c3,1,"For now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function.
--------------------------
**Version**: unspecified
**Severity**: enhancement",69413,-53,High,True
-4.940496221442807,5.815911398749076,0.1362293830277359,0.05305351716619411,-2.5209952073550106,4.0558882324228644,-2.334903151546684,-1.9074797168167081,4.888969182128469,1.5887509742914405,-0.7857623726681844,0.8453407352739732,0.4402739842896395,4.485348851960634,0.9133051785324326,-0.7800242740171621,-0.7202208851493815,-1.0169409425039275,False,c3,1,"If the user choose the login with Google he can not choose, if he want to keep the login.
possible solution #1: Try to use the ""keep login"" from login form
possible solution #2: Create a setting in Special:GoogleLogin to set this fix for the account connection
--------------------------
**Version**: unspecified
**Severity**: normal",69136,-53,High,True
2.2135175183952254,6.052774676998478,2.0752790165197723,1.6724654672237604,-4.500076944805018,1.960447290798532,0.31046520281759094,-1.9645017373635754,-1.409112154369947,-1.5254731538599544,-1.319677393831827,0.07146242544207881,1.146009608024729,0.46171827261504106,1.1337112090503672,0.45863600821220746,1.688044955701985,-0.022592481041991297,False,c3,1,"As of late, half the time I'm trying to work with the graphs, some or all of the images on the page will be broken due to Bad Gateway errors.
icinga-wm in #wikimedia-operations has also been reporting it
icinga-wm: PROBLEM - graphite.wikimedia.org on tungsten is CRITICAL: HTTP CRITICAL: HTTP/1.1 502 Bad Gateway - 525 bytes in 0.002 second response time
--------------------------
**Version**: wmf-deployment
**Severity**: critical",68765,-55,High,True
-3.504703839176712,-2.381396014256543,-5.208427551129395,-1.522552153043424,0.7019570339666585,1.0989119250953048,-0.9263797559302116,-0.5604575562769626,2.4467649062336596,-2.2949269007257023,-0.6677346442120116,-1.2004269053539658,1.1693561762646199,-0.1507005992976067,1.2366679914669225,1.2355824155196529,0.9964675057384722,0.3955624853337094,False,c3,1,"**Author:** `dan`
**Description:**
In versions 1.21 and previous versions MediaWiki:Loginprompt could be used to add useful information to the login page and we were using this in all our wikis in Moodle.
Starting with version 1.22 -> 1.23 this message is no longer displayed in the new login page and we can not find a suitable replacement to add a message there.
You can see the existing use of this:
https://github.com/wikimedia/mediawiki-core/blob/REL1_21/includes/templates/Userlogin.php#L51
--------------------------
**Version**: 1.23.0
**Severity**: normal",68574,-55,High,True
-6.306074529791562,1.6724512811354764,-1.8177520672983682,2.1086846675753432,-3.166920968929808,0.20258974833950116,1.647510219823836,0.8397279687729261,0.7176102413100436,0.07885612828280841,0.6674890926537089,1.6854838648253174,1.1351235010493186,-2.3492540982926617,0.332405210849525,3.2999462321156043,-0.06555602051939258,0.590328373610862,False,c3,1,"`requests` has been chosen as the http library for `pywikibot` v3.0 master.
There are a few cases of urllib.urlopen (and others) being used in the pywikibot library code, and a number of scripts which use other http request routines.
Multiple routines results in multiple configuration (e.g. proxy) and multiple sets of possible bugs/errors.
All http activity should be provided by utility methods in `pywikibot.comms.http`, so it is easy to test and support them, and possibly use a different http library in the future if necessary.
**See Also**: T71204",68102,-57,High,False
1.141835011283836,-10.275435845333874,-4.315637629615065,4.872026650004806,-2.447821300353885,-4.525514602817439,-4.650111418780407,-0.4353144428162644,0.21367926728922837,4.213025239936822,-3.2354796306686477,0.044085904584141744,-0.7129602740418992,0.2731556456317046,-0.8904446115639555,-0.6115357952845154,1.4361026076548977,-1.8241316008101454,False,c3,1,"Temporary HTTP errors should not cached by mw.api.getToken.
Steps to reproduce
* Load MediaWiki
* Switch browser to offline mode
* Enter
var api = new mw.Api();
api.getToken( 'foo' )
.done( function ( data ) {
console.log( 'done', data );
} )
.fail( function ( error ) {
console.log( 'fail', error );
} );
>> fail http
* Switch browser to online mode
* Enter
api.getToken( 'foo' )
.done( function ( data ) {
console.log( 'done', data );
} )
.fail( function ( error ) {
console.log( 'fail', error );
} );
>> fail fail
expected result
>> fail token-missing
--------------------------
**Version**: 1.24rc
**Severity**: normal",67268,-60,High,True
-2.1487372707644514,2.2869920896227427,2.7567197649394224,-0.5342839941513001,-4.789090650059514,-0.552665542228776,-1.9257809333384595,1.3893753003545513,-3.316707026081107,1.5524651348535716,-3.992857891632034,3.3067062844250943,-0.3996999210367891,0.16799573312628802,-3.678008144810611,0.26096956111315495,-1.9074318785552775,1.9789425405233814,False,c3,1,"On http://en.wikipedia.beta.wmflabs.org/ attempt to login
Upon logging in, the resulting URL contains ""$channel"" instead of ""beta"" and browser shows no page
result:
http://en.wikipedia.%24channel.wmflabs.org/wiki/Special:CentralLogin/complete?token=fba1899f0e1715c2a585874c3c47812d
http://en.wikipedia.$channel.wmflabs.org is also seen.
Login seems to succeed.
This prevents any automated test that logs in from running.
--------------------------
**Version**: unspecified
**Severity**: major",65780,-64,High,True
4.088835700717015,-3.1945345486390337,0.8449846537433139,-1.8906201155685163,-1.9978675575651947,-0.42980282417333027,-2.3136385491197666,1.2808441997784001,0.5917356418568428,1.6419838630942403,-1.772840342337904,2.9999727885834737,-0.48949586755597885,-1.6867893719823273,-0.06541153254180188,1.7417531964045543,-0.3527510800094107,1.1850246100249702,False,c3,1,"**Author:** `pr4tiklahoti`
**Description:**
Screenshot showing broken login and create account links
The ""Login"" and ""Create account"" links on mediawiki.org seem to be broken.
To reproduce, make sure you are not signed in. If signed in, logout and revisit http://www.mediawiki.org again
Observed: The links are broken
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Attached**: {F13773}",65563,-65,High,True
-3.5692907387240873,-3.0745211360207882,-2.9032633228746807,0.5651993801181479,-4.580058775819923,-0.9825356713987036,1.2057660032832542,2.3923161758095524,0.5282041418879271,0.7173873777513764,0.5631670615661566,-0.541664072668147,2.3701467018097615,-1.3509868703659986,-1.3389676008163844,-0.6254668183641944,0.2477530784216102,-0.43860689072246384,False,c3,1,"Please enable ssl/https support for the beta wikis again. It is missing after migration to eqiad.
Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok.
see bug 48501 for task to get real beta certs but only for limited subdomains.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68387",65538,-65,High,True
-1.887182969819474,-0.40771703878891685,-4.044581835939772,3.0745408927570113,-5.782535186646118,-4.104821736616372,-0.8910409311950431,-2.5302247859258395,0.03695631066762395,1.1670054170634403,-2.330758083993967,-1.6762215472839226,1.0362657274787956,-0.11562627779634482,0.20794459982912006,-0.8662048025984435,1.2780001875551388,-0.3407391947834486,False,c3,1,"As of late, the home directory creation for users is broken.
I got errors in two scenarios:
* Added user 'rxy' as member to the 'cvn' group.
* Him connecting to a pre-existing pmtpa instance that I (krinkle) can log in on fine, yields:
$ ssh cvn-app2.pmtpa.wmflabs
(..)
Creating directory '/home/rxy'.
Unable to create and initialize directory '/home/rxy'.
$ ssh cvn-app3.eqiad.wmflabs
(..)
* Created new instance in eqiad.
* Me connecting to this 15 minutes after its creation, I still get:
Creating directory '/home/krinkle'.
Unable to create and initialize directory '/home/krinkle'.
I've updated my .ssh/config with the most recent version of the example on https://wikitech.wikimedia.org/wiki/Help:Access#ProxyCommand, but that only made it worse (main difference is using bastion-eqiad, instance of bastion2.pmtpa).
With that config I can't even connect to it:
$ ssh cvn-app3.eqiad.wmflabs
channel 0: open failed: connect failed: Connection timed out
ssh_exchange_identification: Connection closed by remote host
Trying manually:
$ ssh -A bastion1.eqiad.wmflabs
krinkle at bastion1.eqiad.wmflabs in ~
$ ping cvn-app3
PING cvn-app3.eqiad.wmflabs (10.68.16.170) 56(84) bytes of data.
64 bytes from cvn-app3.eqiad.wmflabs (10.68.16.170): icmp_req=1 ttl=64 time=2.26
64 bytes from cvn-app3.eqiad.wmflabs (10.68.16.170): icmp_req=2 ttl=64 time=0.71
$ ssh cvn-app3
ssh: connect to host cvn-app3 port 22: Connection timed out
$ ssh cvn-app3.eqiad.wmflabsssh: connect to host cvn-app3.eqiad.wmflabs port 22: Connection timed out
--------------------------
**Version**: unspecified
**Severity**: major",64771,-68,High,True
5.3913350384185765,-0.18300404778421786,-6.07132417030151,3.783760451084021,-1.3478236461932152,-2.1058587571100587,-8.429885532412056,0.20877506526544898,0.08701111802078476,0.14884573159846237,2.943119244309536,0.09382067991950116,-2.568245414944906,0.6613510825753366,1.0398377021058272,-0.29904639264734,-1.2683854598337945,0.22747597771332528,False,c3,1,"Gopinath (via codex.galleryproject.org) reported a login csrf on Special:ChangePassword. Confirmed this in master. Note with the PoC, the victim must have an existing _session cookie on the target wiki, otherwise the login fails.
Special:ChangePassword should use a login token.
>>>>
On Sun, Mar 9, 2014 at 12:16 PM, Bharat Mediratta <bharat@menalto.com> wrote:
Hi, Wikimedia folks - Gopinath is reporting a vulnerability in Mediawiki 1.22.3 which is running on codex.galleryproject.org - can you take a look at this and decide whether it's something you want to resolve in the Mediawiki codebase?
-Bharat
On Fri, Mar 7, 2014 at 10:14 PM, Gopinath <gopiengg@gmail.com> wrote:
Hi,
Through below CSRF Code user can be logged into the attackers account, without knowledge of user.So attacker can track the user activity.
User also wont know the attacker account password .Attacker can request password reset for his account and can get the value of wpPassword parameter.
POC Code
<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action=""http://codex.galleryproject.org/Special:ChangePassword"" method=""POST"">
<input type=""hidden"" name=""returnto"" value=""Main Page"" />
<input type=""hidden"" name=""token"" value=""+\"" />
<input type=""hidden"" name=""wpDomain"" value="""" />
<input type=""hidden"" name=""wpName"" value=""Gopinath6"" />
<input type=""hidden"" name=""wpNewPassword"" value=password1234 />
<input type=""hidden"" name=""wpPassword"" value=7qbuqjjsme />
<input type=""hidden"" name=""wpRetype"" value=password1234 />
</form>
</body>
</html>
Regards
Gopinath
--------------------------
**Version**: 1.23.0
**Severity**: normal",64497,-69,High,True
-5.152246006611072,-3.1176735393650787,0.2132041142879899,-2.095700259348717,-4.297608431622731,-1.6973280341695207,3.9283660176422037,-4.625008782480478,-1.0483343137383168,0.6671421628375711,1.696498507786996,2.7946662817977437,0.7935114563229217,-2.219837899262323,0.7044254389387357,2.5676231932663733,2.6680199368608077,0.6247027038365907,False,c3,1,"Would make testing easier for me, as I run wiki over https, and all http requests are blocked.
--------------------------
**Version**: unspecified
**Severity**: normal",64201,-70,High,True
-0.399347772283805,4.748413456456419,-0.21496433685317662,-7.761657471647116,-3.76440388842572,-2.3775199327775605,-0.09330071720892263,-2.570135661962323,1.015191943553195,-1.7008281865281405,-1.0696416690969524,0.283801329306558,0.07590872461939213,-0.28268737285143164,-1.0765901522277037,0.15968680455271977,-0.7666185695612385,0.4448202555787917,False,c3,1,"I am able to stay on HTTPS on the shop *up until* the site gets to asking me to log in and *then* it sends me to HTTP.
?!
Once a user is on HTTPS, keep them there.
--------------------------
**Version**: wmf-deployment
**Severity**: major
**URL**: https://shop.wikimedia.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37790",63528,-72,High,False
8.755214001260523,0.9982089985146665,1.6050238115648234,-1.894421863774765,-0.9511191655981345,-0.4401530421813369,-2.166561820058931,-0.07923231011743098,-3.3436869522400317,-2.293568671960162,-1.4479466100589757,0.3984039116283462,3.7051978859518795,2.579735435378195,0.8645599743242212,-0.5413774550750259,-0.45607524841983316,0.08521102188384533,False,c3,1,"Original bug tilte:
Server error on http://wikimania2014.wikimedia.org/wiki/Special:MyLanguage/Main_Page
That page you are sent to by Google when searching for ""wikimania 2014"".
The page reads as follows:
Wikimedia Foundation
Error
Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: GET http://wikimania2014.wikimedia.org/wiki/Special:MyLanguage/Main_Page, from 91.198.174.67 via amssq57 amssq57 ([91.198.174.67]:3128), Varnish XID 922288847
Forwarded for: 217.186.201.65, 91.198.174.67
Error: 503, Service Unavailable at Fri, 14 Feb 2014 08:46:27 GMT
Note that https://wikimania2014.wikimedia.org/wiki/Special:MyLanguage/Main_Page
works
--------------------------
**Version**: wmf-deployment
**Severity**: major",63364,-72,High,True
15.367143298684333,-6.563230865624962,0.3004847207037251,4.019086792595849,-0.9730665952296231,-1.4026766785055598,1.3186708823439925,-0.16430769067288714,-0.6313837962614768,0.7342259695550633,0.9615328030490784,-1.416174809279347,3.2210289820774274,-1.2013639537027205,-0.0037382801042280533,-1.0683984941638205,-0.1823314379190455,-0.4162758436260181,False,c3,1,"**Author:** `jclarke`
**Description:**
For some entities using Wikidata's Special:EntityData linked data URIs return HTTP 503.
$ curl -I https://www.wikidata.org/wiki/Special:EntityData/Q30.json
HTTP/1.1 503 Service Unavailable
$ curl -I https://www.wikidata.org/wiki/Special:EntityData/Q30.nt
HTTP/1.1 503 Service Unavailable
$ curl -I https://www.wikidata.org/wiki/Special:EntityData/Q30.rdf
HTTP/1.1 503 Service Unavailable
Access via api.php works fine:
$ curl -I ""https://www.wikidata.org/w/api.php?action=wbgetentities&ids=q30&format=json""
HTTP/1.1 200 OK
Other examples:
* Q30
* Q148
* Q145
--------------------------
**Version**: unspecified
**Severity**: major
**Whiteboard**: varnish u=dev c=infrastructure p=0",62003,-77,High,True
2.292205000935794,-5.657231621917855,-2.9867842943894054,4.546922421637947,-6.308067441730138,-0.37417358053240013,2.963492193957376,-0.3878742772314193,-3.3794341066807636,0.26865526279975604,1.3611475160335629,0.22061614698547327,4.53936046596742,2.957881825235214,-0.49919529007892915,0.6682024442879522,-0.6911960433393222,-0.558194291859768,False,c3,1,"PHP Warning: http_build_query() expects at most 3 parameters, 4 given in /usr/local/apache/common-local/php-1.23wmf10/includes/libs/MultiHttpClient.php on line 182
--------------------------
**Version**: unspecified
**Severity**: minor",61880,-77,High,True
-1.6344522728088393,-1.105295340542094,-0.5324249026540695,2.462561490882317,-2.210302706912225,-4.503868436301103,-0.04329309203673404,-0.9400509472349049,0.5332389233773653,2.3182890753423626,-0.33097059313747,0.7687933525679544,2.251465603260853,-1.022349976709041,1.2802839505535442,1.5223963364766473,0.060081546884652504,0.8833572762509674,False,c3,1,"* 1.23wmf3 (e2e9b85)
Scenario:
+ en.wikipedia.org as of 2013-11-20
+ go to ""Reset Password"" page and trigger the I-forgot-my-passwort e-mail-password mail
+ come back to the login page
+ enter the temporary password
+ you are now correctly asked to change your password (=mandatory password change after login with temporary password)
+ after a successful password change you will see
Bug:
===
page title after successful password change is (still):
""Change Password""
URL is:
""https://en.wikipedia.org/w/index.php?title=Special:ChangePassword&returnto=&returntoquery=&fromhttp=1""
with unsuited information on it:
""You must be logged in to access this page directly.""
This is striclty reproducible.
--------------------------
**Version**: 1.23.0
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57098
https://bugzilla.wikimedia.org/show_bug.cgi?id=57065",59289,-85,High,True
-0.49174079610282817,8.078072155683998,-3.3722370966549633,-6.733639578065968,-4.828403558259243,3.374893469155615,2.2488064615267698,2.669014669813088,-2.645149785469206,0.5095950177306499,0.18132842629082147,3.6178594259743413,0.21735958594619387,-2.538723313307965,3.2985244627492802,-0.16393901792841703,-0.4798983306275926,-2.7880943402985854,False,c3,1,"The redirect added to CentralAuth in Ia1232ac39e8 is effectively uncacheable, since it depends on wfCanIPUseHTTPS(), which can't be varied on in Varnish. The change should probably be reverted. It's essential that /checkLoggedIn be cached if the backend request rate impact of CentralAuth is to be reduced.
--------------------------
**Version**: unspecified
**Severity**: normal",59223,-85,High,True
5.038702239900633,1.221294005352597,7.024703135255233,2.9133951158865012,3.485742825360466,0.321143270488508,0.9405043272145059,0.2773962295964584,0.6884175614659063,-1.5850329552226747,-1.2507139410497483,0.4287957555191002,-0.35833026254445866,1.0633431736935846,-1.1251956621648773,0.35478754969019655,0.9609650758259101,-0.9982968754487823,False,c3,1,"The current Parsoid unit tests (parserTests.js and friends) use Parsoid as a library directly. This means that the HTTP API code paths are not tested, leadig to issues like https://wikitech.wikimedia.org/wiki/Incident_documentation/20131104-Parsoid .
We should develop some way of unit-testing all the HTTP API endpoints.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56601",58730,-86,High,True
-1.856563099406656,5.221666445617636,7.315829988502234,3.8958586029840454,-4.0406207588652485,-1.77621068706852,4.054182867152703,-2.4640598133856386,-1.2886915900391749,-0.29287772938513434,-0.28917741270285546,-2.2109102370361926,-1.0852933636681605,0.05082941418046705,-1.2272355251108857,2.2354286833347214,2.30332062994375,1.4010791679365677,False,c3,1,"Parsoid currently tests parsing and serialiation of content. Currently, testing of the HTTP API wrappers and any issues with libraries and bugs in the endpoints relies on manual testing.
Gaps in manual testing can lead to incidents like this: https://wikitech.wikimedia.org/wiki/Incident_documentation/20131104-Parsoid
So, we need an automated test setup for our HTTP API endpoints.
--------------------------
**Version**: unspecified
**Severity**: normal",58590,-87,High,True
-7.847330674667372,-1.4822687029656247,-5.892819534118557,-0.19251670871069693,-1.379661546665755,-1.6471002918874604,5.297134788996028,2.218554887156343,-3.743203461519445,0.48099055585892714,2.0422228499043693,2.9759545632754696,3.058632942327109,1.7054344084146642,0.8737053921231999,-1.873379184632873,0.7006887042938994,0.21188610603061364,False,c3,1,"Right now tools-login provide doxygen 1.8 but other nodes only doxygen 1.7
this is not the only inconsistency other packages may have different version as well, it seems that old nodes like tools-exec-01 are using different repository.
This should be somehow resolved, for example we need doxygen 1.8 but on exec nodes we have only 1.7, and what is ever worse I am afraid that some exec nodes provide 1.7 while others provide 1.8
if that is true for other packages too, this may have critical impact for certain jobs which expect same version to exist on all execution nodes
--------------------------
**Version**: unspecified
**Severity**: critical",58326,-88,High,True
1.7068838673975644,-16.127433954373032,2.880769033622677,1.0046801632254487,-1.8306765007085601,1.9856589899702255,3.4701922060568178,-0.009616588664199677,4.614361197587154,1.614113416066739,1.3587143688455332,1.636351919186877,-0.21560079605811122,0.7760668550750589,-0.4317302644683094,0.5291458231143799,-0.549665146236134,-1.2678895792423819,False,c3,1,"see http://ganglia.wmflabs.org/latest/?c=tools&h=tools-webproxy&m=load_one&r=hour&s=by%20name&hc=4&mc=2
--------------------------
**Version**: unspecified
**Severity**: normal",58158,-88,High,True
0.5624552028619454,5.8260391098559055,5.747296052981607,-0.9565100173174186,0.20185754023596147,0.013786673706254637,1.3004229607908053,1.050060964531228,-3.7529704894527596,1.0213171184174907,-1.5437140276057866,1.72868925957773,0.027562951056248508,2.5741417344055995,-0.797798163512085,-1.4190359818621638,-0.3702381910863479,0.3553488924076962,False,c3,1,"Introduced by 1c927b1df2a (Iab2bda1ebc). Turns out PHP expects the context scheme name to be ""http"" regardless of whether the actual protocol is HTTP or HTTPS. This breaks PHPHttpRequest for all HTTPS requests since it no longer sets the stream context properly.
--------------------------
**Version**: 1.22.0
**Severity**: normal",58047,-89,High,True
-2.2171860796243865,3.406367185997947,-2.6856193562848514,-3.908204470886172,-3.9880037780292628,1.4017039726722083,-0.709357135578375,-0.8869276694222867,-1.18348296612228,-1.6936620004693563,-0.3691000536045954,0.3290923754975661,1.492200330926026,-1.6583321365386277,-0.4841410202047314,-1.0410586158710713,-0.31997811424942824,-0.21048392935434568,False,c3,1,"To replicate, go to https://m.mediawiki.org - with console open, you should see an error like:
[blocked] The page at https://m.mediawiki.org/wiki/MediaWiki ran insecure content from http://meta.m.wikimedia.org/wiki/Special:BannerRandom?uselang=en&sitename=M…roject=wikimedia&anonymous=false&bucket=1&country=US&device=android&slot=6.
I presume this makes it impossible to run CN banners on mobile devices for logged in users.
I chatted briefly with Matt Walker about this and it sounds like this is the result of how infrastructure is currently architected, though there may be an easy solution of forcing mobile URLs in CentralNotice using MobileContext::getMobileUrl() from MobileFrontend.
--------------------------
**Version**: master
**Severity**: normal",57860,-89,High,True
-5.291936030098813,5.4853839067851915,1.485247831396201,0.8339681104060348,-2.8787815906212755,-3.0319335789909925,1.04750802086863,-1.4238791645137225,-0.5794367006202018,1.090249286603413,-1.1307164699115502,1.024820762710435,-0.13005460784678746,0.7404377356262106,-0.8351696358642338,1.9331910261359289,-0.35846818246148815,2.240010974564294,False,c3,1,"Now that $wgSecureLogin defaults to true for most WMF wikis, Special:UserLogin/signup redirects account creation to https. When it does so it drops all URL parameters to signup apart from returnto and returntoquery.
As a result, we're losing campaign information, and other control over login such as &showGettingStarted=false.
To reproduce:
Browse enwiki over http, visit a random page, click Edit, if the yellowish ""You are not logged in...."" anoneditwarning bar appears, then note the http: link for "" or create an account"" contains &campaign=anoneditwarning""
But when you click it, you are redirected to
https://en.wikipedia.org/w/index.php?title=Special:UserLogin/signup&returnto=Ectoedemia_sabina&returntoquery=&fromhttp=1
with no campaign parameter.
One fix is to test for campaign and add it back to the $query, in the execute() function in includes/specials/SpecialUserlogin.php. Or, include all query string parameters in the redirect URL.
--------------------------
**Version**: 1.22.0
**Severity**: normal",57761,-90,High,True
1.1098866385770578,-8.60549001282775,0.0049664627221588376,2.18569010555349,-0.9490530294838604,-2.134940792110857,-0.958242413650833,0.5476937546813323,-0.5620302227350613,-2.4898930382703353,-1.1795030118770462,0.11541731071014838,1.4093175532818152,0.2782081683811537,-2.291699227089491,0.6932227646425639,-0.6674555137686248,-0.022691065966490287,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1657/
Reported by: valhallasw
Created on: 2013-08-22 15:14:10.237000
Subject: core hangs on killed http(s) connection
Original description:
Steps to reproduce:
>>> p = pywikibot.Page(pywikibot.getSite('nl', 'wikipedia'), 'Wikipedia')
>>> p.get()
# now kill the connection, e.g. using tcpview in windows
>>> p = pywikibot.Page(pywikibot.getSite('nl', 'wikipedia'), 'Wikipedia')
>>> p.get()
# hangs
Expected result:
pywikibot reconnects and executes the .get()
Actual result:
complete hang (deadlock?)
--------------------------
**Version**: core-(2.0)
**Severity**: major
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1657",57127,-91,High,True
-7.50773632145423,0.49091937745328984,-0.6972837131956879,2.6269982456518433,-4.387758883952919,-1.3031181436020314,2.997058736369328,3.1571859160056053,-0.9577744873364116,-0.5029932407960969,-0.28907590067786515,-0.7983658221243534,0.509978125062085,-2.4509073514700295,-0.05673761206018746,1.3862978175108511,1.0326761339204464,0.7835242745387399,False,c3,1,"In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.
--------------------------
**Version**: unspecified
**Severity**: normal",56914,-91,High,False
0.9934486542889842,3.4796794155781754,-1.6283414622007015,-6.997454017382717,4.257718309076104,-3.846125685974,0.4967725459014707,-2.6181227766825628,-3.5107149599961494,-2.024471081499353,0.5288499651105742,-3.2253924751859238,2.893123717089326,-0.4658587151640843,4.110320185658629,-1.0590622265917398,1.3152029013336788,1.2145542774810585,False,c3,1,"Forced secure connection...again...[edit]
Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)
Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)
I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)
I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)
--------------------------
**Version**: master
**Severity**: normal",56626,-92,High,True
-1.9531579603560825,0.8292004598349791,-1.5067066864072167,-2.494565583492026,3.1237335798028822,-3.7702834919469668,0.6383353332959647,-1.5801454531588117,-2.3939817651710875,-0.07176072680011991,-0.9614784570030821,-0.007397155458758409,0.42088518024053867,-0.04217203054167129,-1.9292624677198051,1.1034198809375135,-0.9010435274516169,-0.35578596072281,True,c3,1,"Copying from https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574338454#Log-in.2FLog-out.2C_Skins_problem though this seems to cover two aspects:
Upper right corner: Cologne Blue skin not showing, notice appears ""CENTRAL LOGIN. You are centrally logged in as Carrite. Reload the page to apply your user settings."" Which doesn't work. Log-out fails. Ridiculous. 24.20.128.148
When I get this message, I wait a few seconds then hard-refresh the page
(it's Ctrl+F5 in Firefox). That usually fixes it. —Redrose64
I believe loading any page would apply settings, not just reloading
the previous one, but I may be wrong. —πr2
Small guess, the JS that does the login redressing only works for
Vector and Monobook. And it seems there is a problem that every time
you visit a http address while logged in over https, you get the
'central login, you are centrally logged in as' notification for
every page view. I'm seeing this as well right now. —TheDJ
--------------------------
**Version**: master
**Severity**: normal",56513,-93,High,True
0.8002661608350272,-3.978876306097961,-4.586954182223515,-1.1245610745034644,0.6984474212665297,-0.8951113082951919,0.767454797816904,-4.164939205851588,-0.5860324706028304,0.7115767151650045,0.24118078624117611,-1.1894156837379795,0.9271160602799418,-1.1189904471125325,-0.8951059220673825,1.025956596466815,0.40867686029424655,-0.4038494230586591,True,c3,1,"This is weird, but reproducible. The *first* time you try to clone a repository in a directory with:
git clone https://git.wikimedia.org/git/mediawiki/extensions/SomeExtension.git
it fails with:
Cloning into 'SomeExtension'...
error: RPC failed; result=22, HTTP code = 405
fatal: The remote end hung up unexpectedly
The second time, it succeeds. I've reproduced it with multiple extensions (e.g. UploadWizard) on both Labs and my own machine.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: aklapper-moreinfo",56417,-93,High,True
-1.9861285604325822,0.13690933579136555,2.7448525749868686,-0.8547620918707252,6.301350986048453,-0.754357093748514,1.366665239683729,2.219178074207433,-2.444166869411858,-1.5686992337860683,-0.38689503146701254,-0.4993587101541691,0.6312709471991989,-0.028335984699754846,-2.1689260082919204,-0.4493919484604545,-0.8677815183443568,0.7926191469816712,False,c3,1,"Requesting https://commons.wikimedia.org/wiki/User:CommonsDelinker/commands?action=edit often returns
HTTP 504: Gateway Timeout.
This does not happen when requesting the page with a high frequence but if you do it e.g. once an hour. Just look at https://commons.wikimedia.org/w/index.php?title=User:Rillke/CDC_mystery&action=history where I dump the profiling report of this page using https://commons.wikimedia.org/wiki/User:Rillke/profile.js -- about every third request fails.
Other users experience this issue as well:
https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard&oldid=104206956#Extremely_slow_performance_to_open_edit_interface_of_COM:CDC
If I remember correctly, this is an issue for a long time. Updating the page via API often works without any issues (but is slow). The page is regularly queried and updated by a bot: http://toolserver.org/~delinker/helper.txt
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53577
https://bugzilla.wikimedia.org/show_bug.cgi?id=49734",56122,-94,High,True
1.6100535525994224,0.35198128012078556,-0.6256831625919492,-4.182524706130112,-2.2660400651478243,-2.970294022405736,-0.7478542033449909,0.05132305596375991,-1.6456924852421362,-0.9044153457985313,2.433837098127904,1.5204680822182814,1.645402142386517,-0.21194101016753653,0.7415788306918687,2.1111717453624683,1.1828378249190468,-0.6923236616066808,False,c3,1,"Steps I followed to reproduce:
1) Pick or produce an account registered on it.wikt (home), en.wikt, it.source, en.source; clear all cookies and start new incognito window on Chromium (27.0.1453.93 200836)
2) Visit ru.wikt
3) Login on it.wikt
4) Visit ru.wikt
I. Expected: I am logged in (account is autocreated).
II. Actual: Account is not created and I am not logged in. (Not bug 45578 comment 3 because I had visited the site.)
5) Visit en.wikt
III. Expected: I am logged in (account already exists).
IV. Actual: I am logged in.
6) Visit it.source
Same as III, IV.
7) Visit en.source
Same as III, IV.
In some previous test I was not logged in at step 7 (i.e. in other projects but same language subdomain, but not same project different language), I don't know what happen.
The messy situation at [[Special:CentralAuth/Bug 16864 test]] is due to bug 16864: if you sort by date you can spot the accounts autocreated by logging in on wikimania2013 and outreach (without any logic). I don't know how the various bugs are interacting here.
--------------------------
**Version**: master
**Severity**: major",56119,-94,High,True
-1.9654390331416232,-1.5393231727879613,-3.364136238949138,0.6995116866203333,2.6089731184219027,-2.7348200095968918,-2.449120194591586,0.7256004596106668,-2.1193654215922013,-2.301357586702001,4.714213772429973,0.2291228442987412,-3.17027277551931,0.20782167740735602,-0.8439942017943824,-1.425194927144528,-0.5591691117430101,2.761650268872235,False,c3,1,"When requesting random images from Commons' MediaWiki API and requesting a thumbnail for it, I often get a HTTP 500.
For example:
GET http://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg
HTTP 500
<html><head><title>Error generating thumbnail</title></head>
<body>
<h1>Error generating thumbnail</h1>
<p>
Error creating thumbnail:
</p>
<!-- http://commons.wikimedia.org/w/thumb_handler.php/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg -->
<!-- mw1154 -->
</body>
</html>
Usually when trying again, it just works.
I've been getting these errors in many different environments:
* When reading articles and HiDPI plugin swaps the src attributes (the larger version would fail maybe)
* When opening the VisualEditor (rendering the new DOM means we re-parse the <img>tag and thus re-request it, thus making it more likely for the error to happen again)
* When working with gadgets that render image galleries through requesting file category members and the thumbnail url.
I don't think the scenario is relevant, there is either something wrong with the thumbnail generator script that is triggered by lots of images. Or there is a few faulty servers in the upload.wikimedia.org pool that cause the errors.
--------------------------
**Version**: wmf-deployment
**Severity**: critical",56045,-95,High,True
9.171231303984614,-3.252934268233467,3.85694345396951,-0.6861987415223529,-4.119466754856658,1.967754114580431,-0.923504582329719,-0.3109721182216708,1.1287310310692873,-2.7453748700202563,-3.281360817186883,-1.7960899299337851,-0.11890343552577054,0.76215584502736,-0.22201587083372143,0.25603326882929356,-0.42158695791368594,0.30497731535416395,True,c3,1,"Mirroring RT #5011 in Bugzilla, for the sake of transparency.
https://gerrit.wikimedia.org/r/#/c/82879/
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://rt.wikimedia.org/Ticket/Display.html?id=5011",55959,-95,High,True
-5.479424268941481,10.274225234323275,-0.682616618225385,0.22362032186207825,-2.107062691497119,-0.18664428436052327,2.0157543560254565,-0.670165419281744,-2.0287336637170053,-4.413022288453205,-5.237465407175696,0.4873671696511419,-3.376674967418565,-0.5742479818909638,1.3187243325820015,-2.4191900257219325,-0.5367364646445624,2.0002046877226576,False,c3,1,"To hopefully address the situation where users are reporting issues where they are logged in on some wikis, but not others, RobLa asked that we look into re-running the SUL logic after a user is logged in with the javascript ping.
--------------------------
**Version**: master
**Severity**: enhancement",55953,-95,High,True
-7.600078678485891,-0.029653587433017492,-0.9179254980407396,0.7492739196567884,4.577785558938363,3.156035539441196,0.4741053213932691,4.771214288886634,0.5198320561454132,-1.420643609517426,-0.6748755691917365,0.8710628099026867,0.5288353100597356,0.9592939385961534,-0.7648687952553379,-0.014111801117093314,0.3451366435144616,-1.0198957319751316,False,c3,1,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.
Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",55905,-95,High,True
3.8702515959004047,-2.8226320195173358,1.1595186845366428,-1.7225125529612137,-0.9416359199570044,-3.9315842446533527,2.7484707132043438,-1.4615551121276988,2.8508727287004216,-0.24659383213310182,0.6709991712226335,-1.5954847478221827,0.36447916224291754,0.9406238847001998,1.2742931264421857,4.313356016411662,-0.6781622187509697,0.4762760485209714,False,c3,1,"They should use own messages or we run into problems even in the source language, see e.g. Change-Id: I565971a90fc383327a51d717a80013cb7a3e9c9b
--------------------------
**Version**: 1.22.0
**Severity**: normal",55655,-96,High,True
-4.397897063162175,0.5614112509549205,-1.3842033965504292,0.7974584374155289,1.8878509284116207,-1.2582350321064089,-3.3949195482125725,1.6375615709906208,0.45398836687161215,0.045312894245248536,1.5141448170185883,-1.653873117085042,-0.5992170192696253,-0.7697614349953215,-0.6984234653094203,-1.1728679104781252,-0.6544366133029031,1.2889141112776754,True,c3,1,"Going to the preview instance's /maniphest/query/advanced/ and entering
marked duplicate
in the ""Contains Words"" field, pressing ""Execute query"", I get:
Unhandled Exception (""HTTPFutureCURLResponseStatus"")
[cURL/7] (http://localhost:9200/phabricator/TASK,CMIT,MOCK,PROJ,QUES,DREV,USER,WIKI/_search) <CURLE_COULDNT_CONNECT>
The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 7) on
the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLECOULDNTCONNECT
Note the http instead of https.
Can anybody reproduce?
Not sure how much time we want to spend potentially fixing this and if that indicates a deeper problem or not, hence not setting priority on this task.",688,-37,High,True
0.8551403600762497,5.878416934122452,2.4241003246745336,-4.119676522476775,3.872783447591988,-0.16149914225510031,-5.527660944210037,-4.841417048909969,1.2893457240340878,3.270148692870624,0.43603654568787586,-2.7564325154946667,0.4230245705168434,1.5142785181693554,0.989375167840338,0.44433816748281785,1.202651339284938,3.568521237080817,False,c3,1,"After agreeing on declining {T543}, we still have a risk of confusing many Wikimedia-not-mediawiki.org with the ""LDAP"" credentials and the MediaWiki button (i.e. ""But I don't have a mediawiki.org account!"").
Can we modify the instructions in the login page to make them clearer?
>**Wikimedia and MediaWiki contributors use Phabricator to manage projects, log and fix bugs, and track progress. You can help!**
>If you have an [[ http://www.mediawiki.org/w/index.php?title=Special:UserLogin&returnto=MediaWiki&type=signup | account ]] on any Wikimedia projects, such as Wikipedia.org or Mediawiki.org you already have an account on this site. Existing Gerrit/Labs accounts can be used to create account as well,
> [[ https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account | learn more ]] about creating an account an claiming previous Bugzilla and RT activity.
",545,-39,High,True
-8.515501980818785,14.469400409965658,3.42752877698841,-5.818919870227308,-5.10868576366118,-2.0309305987436437,2.3196410842237887,2.0356451029776146,1.7235862953670396,2.931226093258414,2.7633954005437897,0.3744146403781059,0.6550164632628261,2.9954906268766006,-2.801174692162102,0.7621724923123404,-0.18775472275547123,-2.661243363218037,False,c3,1,Login to http://phabricator.wikimedia.org ends up in an ugly error message. I guess we shouldn't allow anybody to login from http in the first place? Only https (which seems to work just fine).,457,-41,High,True
0.598027175206278,1.7717040471653576,-1.1093662097888313,-0.2204297792469232,-2.775785988202373,1.834617040411435,2.6530927861177274,0.9821783342681231,-0.4762636634530485,0.0909553246215209,1.5922739074630257,-1.4792639490577497,0.6531934850978898,0.57637534095932,0.841362546437173,-0.0032585784809816554,1.125304743442107,1.8280299937395024,False,c3,1,"NOTE: [[ https://www.mediawiki.org/wiki/Phabricator/FAQ#Why_can.27t_I_login_using_my_GitHub_or_Google_account.3F | check the FAQ ]] for a summary of why we are not using GitHub, Google, or other third party authentication providers.
**TODO for Day 1:**
- WMF SUL Authentication (T314)
- Disable local user creation.
**Already ready for Day 1:**
- Claiming other accounts (SUL claiming local or vice versa)
**Post-Day 1 Possibilities**
(please open new bugs that are not blockers to this one):
- Supporting other/3rd party providers (//e.g.//: github or Persona)
Original report:
----------------
Phabricator has [[ https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/ | several options for authentication ]] including local username and password (as used on this instance), LDAP and OAuth2 integration. We could technically use any of these three methods to provide authentication for phabricator.wikimedia.org.
Our bugzilla has traditionally used local authentication, but the need to create yet another account is seen by some as a barrier to filing new bugs {{citation needed}}. We have both wikitech LDAP accounts and MediaWiki's own OAuth extension as possible replacements for local auth in the new system.
The choice of an authentication provider will have ramifications for other tasks as well so it should be undertaken early in the process. It is quite likely that preserving ownership and author attribution will be an important part of migration of issues from bugzilla to phabricator.",16,-65,High,True
8.306918173427862,-1.3585394621834102,-0.8704569333852028,-1.2168899470064622,1.3076878677143606,0.07627218886903919,-2.880889478267531,-4.325630839417447,0.5872467713902182,-2.490444154575057,-0.4281396411506573,-0.5327932301305369,3.4505176617723565,-3.7387150017334223,-2.635882591588887,1.1428648729787352,-0.21683134188569375,-4.070175734780276,False,c3,1,"**Author:** `qgil@wikimedia.org`
**Description:**
%%%Sorry for this last minute notice.%%%
%%%Can we get a CERT for old-bugzilla.wikimedia.org?%%%
%%%This is related to the Bugzilla - Phabricator migration. We had forgot this%%%
%%%little detail.%%%
%%%I can assume the cost of the CERT from the Engineering Community budget.%%%
%%%Thank you in advance.%%%
%%%--%%%
%%%Quim Gil%%%
%%%Engineering Community Manager @ Wikimedia Foundation%%%
%%%http://www.mediawiki.org/wiki/User:Qgil%%%
",84704,-32,Medium,True
-7.592004777472672,-1.8315006290724902,-0.045500954261040505,10.476965269782628,3.5032734547949675,-6.154230736444184,-1.3452861863777432,-5.123013612709097,1.8664117354188516,-2.2707422597562954,-0.12438825214670102,0.547987903076568,2.5858522729003655,-4.070795577086577,-1.114259149134818,0.08038489716708408,0.7355900457267561,-3.4513903108140154,False,c3,1,"%%%RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/%%%
%%%""anytime we delete a certificate, please make an independent core-ops ticket to%%%
%%%invalidate the certificate on the provider level, and assign said ticket to%%%
%%%me.""%%%
%%%this is that ticket for certificate:%%%
%%%virt-star.pmtpa.wmnet%%%
%%%https://gerrit.wikimedia.org/r/#/c/164696/%%%
",84568,-38,Medium,True
1.8327790555865255,-8.842207957640909,-7.116050339456727,1.6523465604199972,-1.2828374770183393,-3.58596615919933,-4.340723453455565,-0.931068305072667,-1.3029820197610187,-4.711033059995498,-0.8919181329118189,0.6773835028856245,4.742582353286825,-2.2034468556014484,-1.192453551358045,0.06402398165183859,-0.32914287094628025,-1.9837251697936629,False,c3,1,"**Author:** `@qchris
**Description:**
%%%Hi,%%%
%%%stats.wikimedia.org and datasets.wikimedia.org are unavailable (“Connection refused” [1])%%%
%%%(Initial report on Server Admin Log at 2014-10-06%%%
%%%20:08 Nemo_bis: 22.03 < Ainali> It was just noticed on svwp village pump that http://stats.wikimedia.org is down%%%
%%%)%%%
%%%Both domains are hosted on stat1001.%%%
%%%Stat1001's apache is not running, but I lack permission to look at the%%%
%%%logs.%%%
%%%Could you please have a look what's going on there?%%%
%%%Thanks,%%%
%%%Christian%%%
%%%P.S.: Tracking bug in bugzilla is at%%%
%%%https://bugzilla.wikimedia.org/show_bug.cgi?id=71686%%%
%%%[1]%%%
%%%_________________________________________________________________%%%
%%%christian@spencer // jobs: 0 // time: 02:00:02 // exit code: 0%%%
%%%cwd: ~%%%
%%%wget http://stats.wikimedia.org%%%
%%%--2014-10-06 02:00:14-- http://stats.wikimedia.org/%%%
%%%Resolving stats.wikimedia.org... 208.80.154.155%%%
%%%Connecting to stats.wikimedia.org|208.80.154.155|:80... failed: Connection refused.%%%
%%%--%%%
%%%---------------------------------------------------------------%%%
__________________________
**Bugzilla Ticket**: [[ https://old-bugzilla.wikimedia.org/show_bug.cgi?id=71686 | 71686 ]] => {T73686}
",84543,-39,Medium,False
-9.76040736058083,0.09631040344669195,-5.755124969852279,1.545226087175441,-1.6796465756634689,-2.393539193595364,0.7596915996790328,1.7245903346349634,-1.5151062797898576,-1.277617686646388,0.306721222970209,-0.9167411794446518,3.227298995448133,-3.9588057868961797,-2.067519465003885,0.5687515054906047,0.5864908184518229,-1.7389325650686502,False,c3,1,"%%%we should go through the entire files/ssl in both, public and private%%%
%%%repositories and remove certificates we don't need anymore, and also the%%%
%%%corresponding keys in the private repo%%%
%%%here are some patches starting that, but there are very likely more of them%%%
%%%https://gerrit.wikimedia.org/r/#/q/status:open+project:operations/puppet+branch:production+topic:SSL-cert-cleanup,n,z%%%
%%%also work with robh to make sure these are removed/revoked properly in other%%%
%%%places, like web interfaces of the different CAs we used for these in the past,%%%
%%%where appropriate%%%
",84536,-39,Medium,True
0.4936573418858359,14.21168032816582,1.7832413947233192,-10.05900435268304,0.4466898490453619,-1.9474091965971545,1.521250601799232,-5.1247078250428215,-0.27726011301978465,2.847349867879947,2.846921281474063,-0.9986604109985486,0.4449377320797674,2.408786951621005,-3.3015892747590496,1.04394504411068,3.1000520530949034,-3.6333074601291084,False,c3,1,"We now use SNI in a few places on the cluster, at least on misc-web and on the
Bugzilla server.
Unless I'm mistaken (correct me if I'm wrong) we don't check for those SSL
certificates yet with SNI. Let's create an Icinga check that supports this (in
Puppet).",84444,-41,Medium,True
5.535078267808576,-2.994862050559302,-3.083944798534583,1.9469036035001523,-1.8805276879911317,-1.393474046670124,-3.733839746190772,0.2334400014567059,-2.1092731487491703,-3.4826077932931643,-0.06574515337483833,0.6012101346779009,3.015779280221837,-2.882508998803791,-1.7769368835662767,-0.15461253182005413,0.4335308623883838,-2.144124782201666,False,c3,1,"%%%break out from #2517 which was about the BEAST attack (and has been fixed in%%%
%%%the past).%%%
%%%current issues left on bugzilla.wikimedia.org%%%
%%%---%%%
%%%Key RSA 1024 bits WEAK%%%
%%%RC4 cipher is used with TLS 1.1 or newer protocols, even though stronger%%%
%%%ciphers are available.%%%
%%%The server does not support Forward Secrecy with the reference browsers.%%%
%%%---%%%
%%%https://www.ssllabs.com/ssltest/analyze.html?d=bugzilla.wikimedia.org%%%
__________________________
**Bugzilla Ticket**: [[ https://old-bugzilla.wikimedia.org/show_bug.cgi?id=53259 | 53259 ]] => {T55259}
**Refers To:**
{T83471}
{T83928}
**Referred To By:**
{T80790}
{T81221}",83768,-64,Medium,True
21.177224509325125,1.1540217417630547,0.5446919108362671,-0.3899967638266788,2.2208506723558585,0.789124369180612,-5.114758659097686,-1.0530849821391666,-2.864151391391614,-4.201177370436637,-0.8974013283565099,2.4877998556130807,6.282857217758968,0.5335404637180545,1.0869698230976956,0.6433150131535303,-0.6493443068730742,-2.05623257343854,False,c3,1,"%%%gurvin 1H IN A 208.80.152.20%%%
%%%gurvin is a Wikimedia ISSLPv6 Proxy (ipv6proxy).%%%
%%%gurvin is a Wikimedia SSL Proxy (sslproxy).%%%
%%%Linux gurvin 2.6.32-47-server #109-Ubuntu SMP Tue May 7 02:17:05 UTC 2013%%%
%%%x86_64 GNU/Linux%%%
%%%Ubuntu 10.04.4 LTS%%%
%%%this is Tampa, needs to go%%%
**Referred To By:**
{T83156}
{T83191}
{T84665}",83211,-88,Medium,True
125.12864973473413,24.461032312281354,20.258054462711378,-15.368139377215654,9.419729155465951,8.923586496494865,0.5660249642391806,-0.39953809071088453,0.6528691956095768,3.4089737421423614,1.8893517820205266,0.7864180118380248,-2.4641331367967334,-0.5539055659455503,1.5844758167120787,0.15244468824303828,0.8508428236510508,0.8283642692908557,False,c3,1,https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_HTTPS_policy,75953,-32,Medium,False
-10.243208969106108,6.832883402108834,-3.3960914494827357,1.3744238248590679,4.476696655557371,4.338152774855891,0.2857099333093682,5.41980165988125,-1.0971912087922973,0.0021387524261893276,0.9842339175770181,0.40533971138436065,1.6094483508826634,-0.5459802028160796,0.1734306290049119,-0.6173764689104358,-0.888742613921755,-0.27315620586698297,False,c3,1,"The current MediaWiki behavior, when requesting a thumbnail directly (i.e. by constructing a thumbnail URL, not via the API) is as follows:
* if the size is smaller than the original image size, the thumbnail is served (assuming the wiki is configured to resize images of that type at all)
* if the size is larger than the original, a HTTP 500 is returned (except for vector images, where ""original size"" is a pretty vague concept)
* if the size equals the original, and the thumbnail would be significantly different from the original (more specifically, when mustRender() returns true for that file - e.g. files with EXIF rotations, or files which need to be converted to a different format for browser compatibility), the thumbnail is served
* if the size equals the original, and the thumbnail would be essentially the same as the original, a HTTP 500 is returned.
The last step is presumably done to avoid wasting storage space on thumbnails when the original file would be just as good (which might or might not be a good idea, see T67383), but it is very confusing from a client point of view and makes it hard to construct a reliable thumbnail URL without having very detailed knowledge of the file. (The API can always be used to retrieve the correct URL, but that has a nontrivial time overhead.) See T70320 for an example of problems caused by this.
A better solution would be to return a HTTP 302 to the original file instead, so that the original is still used instead of a superfluous thumbnail when possible, but requests which do not need to fail don't.",75935,-32,Medium,
-2.1366234278550102,-1.4143699589043486,-3.3936265929667577,3.1146845641170433,-0.4115382969675933,-2.8212621303214025,-2.066249739775072,-0.6320288627703523,1.5260129469637915,-0.1777461116014205,0.521309988141287,-0.4697433387077439,1.4889464350228736,-0.7111394669350846,-1.4371800084399622,-1.3142402827038442,0.5094879022431253,-0.01835335591428966,False,c3,1,"This issue has been biting us a lot recently (where ""this issue"" == ""people's browsers requesting https: beta address and it failing""). Let's fix this finally.
**Proposal:**
//(feel free to edit this description with clarifications/additions)//
1. buy real certs (T50501 and https://rt.wikimedia.org/Ticket/Display.html?id=6116)
* Still needs cost approval, @greg can work on that
* glorious future of letsencrypt.org would reduce this cost to $0, but we shouldn't wait on that (""Arriving Summer 2015"")
2. make new labs project, restrict access a lot
3. just ssl terminate there, proxy back to regular deployment-prep setup
**This gets us:**
* Lets us set the config like prod (https by default for login etc)
* No self-signed certs!
** no breaking browser tests (though that's fixable)
** no annoying users with cryptic warnings
* Members of the Beta Cluster project can have sudo without access to the private certs (see T71269)
* Resolves:
** {T70387}
** {T72145}
",75919,-32,Medium,False
-1.1694252133260985,-6.140044236587141,-0.27474586729768546,0.5111057485484467,-0.008026306941459005,-3.3947246369409347,-3.1134639485265474,1.9934700668951457,-0.5282140319708568,0.9405896182284099,-0.6128516581415511,0.3511203067502253,-0.18800234896692736,-0.49295007942108526,-1.081140686858948,2.0443652600302253,0.5577825300631305,-0.8978823574881614,False,c3,1,"The login has many error codes which are unhandled.
http://www.wikia.com/api.php?format=jsonfm&modules=login&action=paraminfo
Bug 73533 will handle the most critical ones, however the others need to be handled, and that will require more detailed analysis.
For example, 'Blocked', found in 1.19 paraminfo.
The API allows blocked users to login, but prevents them from editing, etc. Therefore, API login error code 'Blocked' may not needed in modern API usage.
--------------------------
**Version**: core-(2.0)
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=73533",75539,-33,Medium,False
4.258125026588333,-1.2523918318855891,-0.9915559302596098,0.9991823863155274,0.30142807123069426,2.586318340546306,-1.1290387557641504,1.0360889483418343,-1.9097618061875343,-0.6563934443244586,-1.339392356049905,0.2719832183373563,1.768483599456291,-0.7603525936563216,-0.21587108845371628,2.088551240097255,-0.06440012840948572,-1.036796098336829,False,c3,1,"Symptom: With a fresh MediaWiki-Vagrant with the https role, the resources (JS+CSS) are not loaded over HTTPS because the $wgServer variable is set to WebRequest::detectServer() in /vagrant/settings.d/wiki/CommonSettings.php (see bug 66399).
Explaination: The HTTPS is performed using nginx as a reverse proxy, and the function WebRequest::detectServer() assume in this case the HTTPS port is standard (443) instead of 4430 in MediaWiki-Vagrant ($wgServer = 'https://127.0.0.1').
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70964",75510,-33,Medium,True
-0.8119629392751686,1.6137094963617429,-2.8677944031195164,-3.6404526281939886,-0.42749778101399977,-2.5957327879576964,1.1015636741949253,-0.45744913084179517,1.7550242458439078,-0.9647700904833569,0.38720343476756813,0.7263251957456687,1.4135037212468213,-1.5951465679537198,1.0697042604964508,-0.21424472550662477,0.6222446938473045,-0.24405229737113654,False,c3,1,"When I activated $wgInstantCommons on my fresh computer without php-curl (so MW used PhpHttpRequest to download data from Commons), it didn’t work until I specified the caInfo option in PhpHttpRequest (to /etc/ssl/certs, Ubuntu 14.04).
(Then I experienced bug 73199 but this is not directly linked.)
It would be nice if this piece of code could automatically find the certificate repository file or directory. Perhaps some magic value make PHP automatically find the default cert repo of the system or perhaps it works on some couple (PHP version, Operating System).
Else I don’t see other solutions than specifing default cert repo for major OS (I know, it would be a pain to maintain it). Or another option would be to even remove all HTTPS-related code in PhpHttpRequest and require CURL for HTTPS.
Before changing anything, it would be great to see this is bug is widely experienced on various platforms (PHP+OS) or if it is only an isolated case.
--------------------------
**Version**: 1.25-git
**Severity**: normal",75203,-34,Medium,True
5.104005820877655,-6.889198125279633,-4.547035737060659,3.657247357807976,-1.056827805075218,-4.638294525669455,-7.233750218452162,-0.9885346841851753,-1.4383276431359644,5.745450284352829,-4.597643168585606,-1.1442801997505083,2.2722885941712714,-0.45403344727835115,1.0577939859096954,-0.6271785820724091,-2.7947547795701793,0.873926291258184,False,c3,1,"I just tried to upload
http://tools.wikimedia.pl/~odder/whitehouse/41d5129de542285b6c62.webm
using https://commons.wikimedia.org/wiki/Special:Upload as well as via API
(I have ""upload_by_url"" userright enabled).
Request URL:
https://commons.wikimedia.org/w/api.php?action=upload&format=json
POST data from API sandbox:
filename=Test%20test.webm&comment=Test%20bug%2072897&url=http%3A%2F%2Ftools.wikimedia.pl%2F~odder%2Fwhitehouse%2F41d5129de542285b6c62.webm&token=d27ea41fb633146835d1a2d1e962f37e545f9bd9%2B%5C
Result:
{
""servedby"": ""mw1139"",
""error"": {
""code"": ""http-bad-status"",
""info"": ""Error fetching file from remote source"",
""0"": ""403"",
""1"": ""Forbidden"",
""*"": ""See https://commons.wikimedia.org/w/api.php for API usage""
}
}
Log entry on the tools.wikimedia.pl server:
tools.wikimedia.pl 208.80.xxx.yyy - - [09/Nov/2014:18:03:30 +0100] ""GET /~odder/whitehouse/41d5129de542285b6c62.webm HTTP/1.1"" 200 932365538 ""-"" ""MediaWiki/1.25wmf6""
so MediaWiki gets 200 from the origin server
--------------------------
**Version**: 1.25-git
**Severity**: normal
**URL**: https://commons.wikimedia.org/w/api.php?action=upload&format=json",75200,-34,Medium,True
1.0762783701396637,1.9285788050964179,-5.80148915356202,1.7695951163690817,1.5583768079956424,1.712672603384011,-1.335481989695407,1.4562783415225504,-2.5125742711106396,1.1132935235339003,-2.5832093804095417,1.1182927070459654,0.49291851718166724,-0.7307863785398432,-0.2823726541033551,0.9207500370633266,0.31793665865110565,-1.6195462979113817,False,c3,1,"In the class PhpHttpRequest (file includes/HttpFunctions.php, used when CURL is not installed), the option 'sslVerifyHost' is translated by checking the 'CN' x509 attribute against the host, which is now deprecated with x509 certificate v3 with subjectAltName and this avoid the operation although it was correct.
In particular, this can be observed with `$wgInstantCommons = true' on an HTTPS wiki without php-curl installed, because the commons.wikimedia.org certificate has a CN attribute *.wikipedia.org and commons.wikimedia.org is only in the subjectAltName attribute.
--------------------------
**Version**: 1.25-git
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68581",75199,-34,Medium,True
4.0415918097292085,-0.8579440205098336,6.523150033557645,4.907070022963556,5.482905411518059,1.522171052091794,1.8865913571634412,-3.4369454964218633,-1.5855074380840755,-0.5465308763291024,0.9795564852498031,1.0785920150998936,-0.9643218738555444,-0.44970507126378667,-0.36002800123326306,0.6100835218489329,1.2912990761409253,-0.06019634111002925,False,c3,1,"**Author:** `tim.schenk`
**Description:**
The link supplied by the mobile page redirects to :
http://wiki.firstconsulting.nl/Speciaal:Aanmelden <-- dutch
This is the default login page and not the special GoogleLogin page.
In my LocalSetting.php I have:
$wgGLReplaceMWLogin = true;
Is this a GoogleLogin bug, or a MobileFrontend bug?
--------------------------
**Version**: master
**Severity**: normal",74909,-35,Medium,True
-5.203985659838038,-0.5767668200476468,-3.2921178757928047,4.648810289251208,0.21905084626843085,0.24650271026135195,-4.606577738095436,0.730427758580013,-1.151646666713051,-3.4829935480060987,3.1858325137521635,0.3023219066200735,-2.7471516352133944,-1.1114918169380417,-1.644741599314436,-1.18725942219519,0.07430768813700772,0.48211787271787254,False,c3,1,"[[wikitech:Special:UserLogin/signup]] contains the following text:
----
<loginstart>
By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org.
[...]
If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell.
<loginend>
----
The <loginstart> and <loginend> placeholders should not be visible.
--------------------------
**Version**: unspecified
**Severity**: trivial",74849,-35,Medium,True
2.6139731355275964,-2.1180229067260132,4.507386835194406,0.21286630811283525,-0.9696734670284104,2.7168671744418846,0.2985704473239448,1.491747918624959,2.211458588729486,0.8245187017858173,0.3609910960654803,0.3981185693943572,1.3564127726651285,2.3964585365128572,-2.033281367809744,-1.3312042819163223,1.4447476050833277,-2.2379185287581977,False,c3,1,"https://datasets.wikimedia.org/public-datasets gives a 404 (meaning that people on SSL can't access any data available at this URL). See https://twitter.com/wrought/status/528059346995802112
--------------------------
**Version**: unspecified
**Severity**: normal",74805,-35,Medium,True
-4.074269047119004,2.2341041032106084,-0.887006813781154,-1.0506871189949631,-3.9319486042459637,-0.13374047365526776,0.21644746578647567,-0.8930710669784544,-0.8854749641553451,-1.4669629085164422,-0.6345009534195301,1.5449698314421216,-0.48211209508592123,-0.539511875202785,-1.3087369655403558,1.657804969427788,-0.5077486940717074,-0.709356996333145,False,c3,1,"Every page of action=help (e.g. https://www.mediawiki.org/w/api.php) makes calls to lots of Special:CentralAuthLogin on different wikis, and shows a message:
Central login
You are centrally logged in as <User>. Reload the page to apply your user settings.
And if you reload the page or load any other action=help page, just the same happens.
This is probably due to the fact that action=help treats you as logged-out, while CentralAuth has cookies to detect you should be logged in.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/api.php",74174,-37,Medium,True
5.4771094195539,7.589215868209177,4.001761260447491,2.907284384206256,0.2942529222359205,0.5968948754959111,0.7602006276276736,1.6968685922000906,-2.9296039679395047,2.126685632439769,0.24687080477399803,1.6555371542028527,2.3236287259390647,1.44115343554647,1.8346114779346214,1.4602888362502189,-0.5672117915486645,1.689303808934359,False,c3,1,"It is hard to tell if this is an actual bug or an artifact of the beta cluster test environment, but in recently time the browser tests for MMV in Chrome have been encountering sporadic errors on well-known test images ""Error: Could not load image data. http""
Examples:
16 October: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/229/testReport/junit/(root)/Navigation/Browsing_back_to_close_MMV_restores_the_scroll_position/
6 October: https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/208/
5 October: https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/206/testReport/junit/(root)/Basic%20Multimedia%20Viewer%20navigation/Multimedia_Viewer__MMV_/",74162,-37,Medium,False
10.12907976111891,5.21890389092022,-2.2411597521370368,-7.469170723718958,-2.201021916915847,2.7721979670456722,-0.5472563462919418,2.2631217449859973,0.5842444522530414,-1.0425487642779179,-0.19026142304264226,3.2596626235597066,2.3453136046201233,1.8528719570629688,1.412007197315762,-2.0876764887114856,0.6744701505229529,1.769716111432522,False,c3,1,"This POODLE bites: exploiting the SSL 3.0 fallback: http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html
https://www.openssl.org/~bodo/ssl-poodle.pdf
The only workaround now is to disable SSL 3.0, but this will make IE6 users unable to access over HTTPS. If supporting IE6 is needed, how about we disable it for now and re-enable SSL 3.0 after TLS_FALLBACK_SCSV is available?
--------------------------
**Version**: wmf-deployment
**Severity**: normal",74072,-38,Medium,True
-5.640912654436473,3.1763247774865313,-1.1802610376745513,3.2404546447600753,1.3351640648800456,0.9728550145872548,0.4806705353789509,3.39153929906406,-1.9890257373958011,2.7402014505180317,-0.5671165366990243,0.05186044618126573,0.4417661747044881,1.2727760867828586,-2.667424133926045,0.08764161670369189,1.4044045952602808,-0.8238084641197192,False,c3,1,"**Author:** `bugzillawiki`
**Description:**
So looks like there's a bug if a mediawiki site has https enabled but doesn't want https anywhere other than login. So if the client comes via non-secure and goes to login with a secured wiki, then proceeds to login (and hasn't chosen to force SSL), the site continues to be in SSL.
Expected behavior: If a client logs in from non-ssl and the wiki has SSL enabled, and the client has not set ""force ssl"", the client should return to the non-secure wiki.
This patch should fix that behavior since the 'fromhttp' parameter wasn't being sent back to the post page properly:
https://gerrit.wikimedia.org/r/#/c/164882/
--------------------------
**Version**: 1.23.5
**Severity**: normal",73716,-39,Medium,True
1.47028029091372,0.2971464521729139,4.196904872923625,2.068141757932954,2.9107037124164328,-0.37646052167512933,0.8680086614811167,-1.897800286830905,-0.032075868991044865,-1.8528013305032776,-1.0350893468020232,1.2150219172058068,0.008167178480475101,0.2520032927440701,-0.7905599441738946,-0.3451201460787503,-0.2993826750257509,0.09494626922518212,False,c3,1,"Bug 70672 (T72672) fixes the security hole of allowing Javascript in CSS in the Mediawiki namespace. It does this by breaking the functionality of loading CSS when on the Special:UserLogin and Special:Preferences pages. Unfortunately this means that any custom styles are not loaded. To the end user it causes momentarily confusion that they may have been maliciously redirected to a different site to enter their username and password. This is an undesirable side effect for the user interface.
I have created an example extension that will prevent saving any custom CSS that contains Javascript imports.
https://github.com/Alexia/Bug70672
Example error output:
http://imgur.com/a/TnsTY#0
Original bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70672
--------------------------
**Version**: 1.23.5
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70672",73621,-39,Medium,True
-2.9948344033037393,3.5709677806748417,-1.5815989227654406,-1.6113016222905485,0.994322561769442,1.1357853222207093,-0.05387897724329882,1.1013142513421181,-0.50431218006399,-0.830411211838511,1.5110585706784811,1.2205725061087305,1.7076755493266065,-0.8305092959205904,1.419382348289587,0.6188153537466162,-0.7372300774042786,0.1792297505820939,True,c3,1,"Flow uses a synchronous XMLHttpRequest. These should be avoided since it blocks waiting for a network response, and can create a bad UX.
For this reason, it's been actively deprecated in recent Firefox (30+), when used on the main thread (https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest), and will log a warning.
It is used in mw.flow.parsoid.convert. This in turn is called twice, both from ext.flow.editor.js:
1. mw.flow.editor.load - https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FFlow/a4eda372ccbd733ff741d3e1369c25a1e561fcf0/modules%2Feditor%2Fext.flow.editor.js#L88 - This is using promises already, so it should be straightforward to use an async call here.
2. mw.flow.editor.getContent - https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FFlow/a4eda372ccbd733ff741d3e1369c25a1e561fcf0/modules%2Feditor%2Fext.flow.editor.js#L88 - This is synchronous, and used by FlowBoardComponent.UI.events.globalApiPreHandlers.prepareEditor. For this one, it also seems like it would be better to do the HTML->wikitext conversion on the server if possible, rather than round-trip a XHR call then post.
--------------------------
**Version**: master
**Severity**: normal",73474,-40,Medium,True
-6.544733758918353,3.355244740691841,-0.8286383887506652,-1.8918976938620364,-0.04268973200543946,-2.932437282533534,-1.736115839466649,-0.8880062923834371,1.3246162941742183,-0.10277196939545075,0.9465214165575664,-3.0357272539370808,1.289049208398204,-0.9717876898784095,0.6977137375217906,1.3467272197504858,0.4777193669246178,-1.0385792558858018,False,c3,1,"1. Try logging in 3-4 times and eventually decide to reset your password.
2. Log in with the e-mailed temporary password.
3. Observe it serves Special:ChangePassword in response to the login with the temp password, prompting me to change it.
4. Enter a new password
5. Submit ""Set password and log in""
Expected:
I'm now logged in and back on the page I was at before this (returnto)
Actual:
I'm back on the ChangePassword page, this time with a rather strange error:
""You have made too many recent login attempts. Please wait 5 minutes before trying again.""
Strange, because I didn't make a log in attempt this time, and even if the one the system did for me was counted as a login attempt, it couldn't have been a failed attempt, so why would it be rejected?
For the record, my login attempts in step #1 before I reset the password did not result in any error or block (at least not visible to the user).
Possibly related:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53655
--------------------------
**Version**: unspecified
**Severity**: normal",73272,-40,Medium,
-1.1625514912421546,-1.2891888336973345,6.32069510532023,6.485262594470497,1.6914793773652077,2.560306577801116,4.006340511724754,0.5835525391384639,1.2771618863891676,1.1878136286357153,0.8531182388672192,1.6974553791573121,-1.1429854334105318,1.267610687806866,0.33807394134303426,-0.9517962320501323,0.8022495295080543,-1.3072612855151913,False,c3,1,"The certificate chain is incomplete because ganglia.wikimedia.org server does not send the intermediary certificate of RapidSSL CA. Some browsers might display a warning to users.
https://www.ssllabs.com/ssltest/analyze.html?d=ganglia.wikimedia.org
--------------------------
**Version**: wmf-deployment
**Severity**: normal",72326,-44,Medium,True
-1.9622083335965979,-0.9821489212341046,-0.19448964430133842,1.472131868168073,-1.381144519257508,-3.6720416294672287,-0.2737483982317812,1.6532833069513009,3.0393890183054326,1.2353742356539188,1.4743637688442468,-0.9693868865500964,0.7082917688147523,0.10881853819637755,-1.0606936736934873,-0.09086139631422324,0.6071938472120906,0.036253633356367,False,c3,1,"I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure.
Steps to repro:
1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.
2. Go to login page and enter username/pw. Tap login.
You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :(
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",72145,-44,Medium,
-4.087960597367493,2.456291463733386,-3.011599449320366,0.2793444296021117,2.6945938131934506,0.7305820291547487,-1.8101114757008965,1.7279926227215503,-2.7805915309756486,0.5975705981529531,-0.4736758035821551,1.946721000623209,1.3310139241989036,1.6027176465945843,0.3351672613705343,-1.7004968172707833,-0.4300909547899461,-0.04137992393605283,False,c3,1,"Seen in labs when running a MediaWiki-Vagrant configured wiki behind yuviproxy. Configuration sets `$wgServer = WebRequest::detectServer()` which works great when HTTP_X_FORWARDED_PROTO is unset or http. When it is https, detectServer() adds "":80"" to the generated url (eg ""https://sulfinalization.wmflabs.org:80"").
This is caused by a mismatch between the standard port for https (443) and the active SERVER_PORT reported by Apache (80). detectServer() calls IP::combineHostAndPort( $host, $port=80, $stdPort=443 ) which leads to a return value of $host:80 since the active port and the default port do not match.
I think naively that this could be fixed by choosing to set $port = $stdPort when $_SERVER['HTTP_X_FORWARDED_PROTO'] is set to 'https' and assume the upstream ssl proxy is running on the standard port 443.
Can anyone think of a realistic deployment scenario where this would be the wrong behavior?
--------------------------
**Version**: 1.24rc
**Severity**: normal",72021,-45,Medium,True
-4.629756889386161,-0.5780119299218693,-3.098499079853948,2.705024309813832,-0.8150202457802525,-0.9387381966437401,-0.6534961267128816,-2.2836986667566053,-0.4586423990847215,-0.4309392345116585,-1.6059096553019978,1.178424315038401,1.3313886408434574,-0.3429796690310578,0.6495567785325944,-0.9069807439237083,-0.7266214771275565,-0.9816232679113626,False,c3,1,"I noticed 'acct' generates log files under /var/log/account/ which is on a 2GB partition. It is log rotated via a daily cron /etc/cron.daily/acct , keeping the last day uncompressed.
On deployment-bastion.eqiad.wmflabs that is 542MB currently, or a quarter of /var/ available disk space.
/etc/default/acct has an option to change the number of day to be kept:
# Amount of days that the logs are kept.
ACCT_LOGGING=""30""
Maybe we can reduce it to 15 days?
--------------------------
**Version**: unspecified
**Severity**: normal",71604,-46,Medium,True
-8.276385238535259,14.009146599663648,5.878562129918173,-1.5399184213564205,-12.460952399151898,0.29104474190998175,0.6795956950320319,-1.067367883031753,6.12239517983331,2.6043223615214224,3.43944986300281,4.639887704677017,2.144435917294619,-1.200212412812442,0.6354493527724028,0.3313614964398621,-0.8353418473918034,-0.37216982824946765,False,c3,1,"I need a login widget I can show the user to login without leaving the current page. This kind of widget can be used in many places, for example in Special:Translate to recover from expired session or log in on other pages to be able to make changes.
Because there might be captchas, rate limiting etc. I think that such widget should exist in MediaWiki core.
",71596,-46,Medium,False
-0.1138780971873925,-7.995795780347989,1.0583477978250073,-5.10367400759213,3.5963265974514367,2.7282187093723484,-1.1040502061477682,-3.1342567465984517,-0.5559876961458572,-1.1509598737363915,2.6654562730781177,3.512377750976487,-0.5066990057967846,0.5839529878870549,-1.8661756200080286,0.6548859999995489,-0.43904475929956543,-2.0176311706355357,False,c3,1,"See https://gerrit.wikimedia.org/r/#/c/148333/ for a sample. I guess there are some more.
--------------------------
**Version**: core-(2.0)
**Severity**: normal",71369,-47,Medium,True
0.18936168998039227,-3.2455284683458565,-4.0597869465519505,-3.938243763645434,-3.2241229216355753,-4.052078361644995,-14.025918102580341,2.1678676920840645,-4.544172571900443,-6.330804978726514,15.551183137359054,-0.08033623296288495,-11.524748007354564,0.023387826648301413,-0.2929197245215365,-1.1553636332354056,0.33412925692819173,-1.0075848737142958,False,c3,1,"`curl -vs blog.wikimedia.org 2>&1 >/dev/null | fgrep X-hacker`
> X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
We should recruit for WMF instead of automattic. :-D
This currently is served on:
- [x] ~~blog.wikimedia.org~~ diff.wikimedia.org
- [x] soundlogo.wikimedia.org
- [x] wikimediafoundation.org
- [x] wikimediaendowment.org
- [x] techblog.wikimedia.org
See also <https://wpvip.com/documentation/x-hacker-and-x-powered-by-http-headers/>
Add this to the them functions.php to remove:
```
/**
* Filter X-hacker output.
*/
add_filter( 'wp_headers', function( $headers ) {
if ( isset( $headers['X-hacker'] ) ) {
unset( $headers['X-hacker'] );
}
return $headers;
}, 999 );
```",70982,-48,Medium,False
4.559028029957336,1.1790579615634353,9.19217495918647,-0.26544177963142324,-0.6606068526397849,-1.7610663694859459,-2.760236051577612,1.0633705986949722,-0.5593288801483154,-1.1536402143980702,1.6802836617036925,-1.3527340780748003,-0.25456384746451555,2.5619648678464575,-0.07405646062512083,-0.9171296602329897,-0.12689881459742636,0.15385655164234335,False,c3,1,"**Author:** `cometstyles`
**Description:**
When trying to upload an image from flickr to commons via [[Special UploadWizard/Flickr]] using http, when we add the image link to the ""Get from Flickr"", it goes to the next step but the image just keeps on loading (in a loop).... it doesn't go any further ..only affects http version, not the https one..
The web console for the browser shows this:
GET https://api.flickr.com/services/rest/ [HTTP/1.1 200 OK 3453ms]
GET https://api.flickr.com/services/rest/ [HTTP/1.1 200 OK 1282ms]
GET http://commons.wikimedia.org/w/api.php [HTTP/1.1 200 OK 2064ms]
GET https://api.flickr.com/services/rest/ [HTTP/1.1 200 OK 547ms]
GET http://commons.wikimedia.org/w/api.php [HTTP/1.1 200 OK 985ms]
POST http://commons.wikimedia.org/w/api.php [HTTP/1.1 504 Gateway Time-out 10433ms]
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows Vista
**Platform**: PC",70981,-48,Medium,False
0.8601206829825299,-6.214003094544108,10.894299065485257,1.3904781425218742,-1.393859394398351,0.8741865640628512,1.7878956381040139,0.3915977242734695,1.0313602551552272,-0.10293221081302217,-0.451815211035409,0.10008491649134776,-0.5216174539990766,1.1707801421026094,-1.8004082890089723,0.18692257594178704,-1.0929525577492896,-0.8123285904722117,False,c3,1,"Looks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=73199",70581,-49,Medium,
-4.091011447153433,3.853938509589412,1.1691349664098887,0.9014698917434325,-5.348768080171171,1.8042082759721725,1.735240202165583,1.028631853998219,2.349185674826014,0.7783691466606042,1.3461490036057815,-1.6531254846192804,1.2914346923757463,1.9170700096561522,-0.24122284869953425,-0.3564787080273166,-0.8916778906204085,-1.019867331903358,False,c3,1,"http://stream.wikimedia.org - currently 404
https://stream.wikimedia.org - currently cert error
for good measure redirect them to the docs at
https://wikitech.wikimedia.org/wiki/Stream.wikimedia.org
because people do try to open this in a browser
--------------------------
**Version**: unspecified
**Severity**: normal",70528,-49,Medium,False
-1.7238949324304957,6.43702869303339,-0.7718550360853058,3.5538124289990485,-0.5789113287024663,-0.774927708910493,-0.5470483110883775,0.6750129652432892,2.6247423426184318,-0.12762736849997758,-2.5944898840145334,0.083219835020923,-0.9758439914195458,-1.510940305272222,1.4927101303808383,0.6214273590137132,-0.4021704358790379,-1.089332780680428,False,c3,1,"When the user hit enter to send his login data on the login form in a wiki using GoogleLogin, he will be redirected to the GoogleLogin authentication prompt, if the login data was incorrectm, instead of show the ""login failed"" screen.
-> Check in AuthPlugin, if username and password is set, and if so, don't use GoogleLogin.
--------------------------
**Version**: master
**Severity**: normal",70143,-50,Medium,True
5.977060145906208,-0.8538554700974501,-3.607446596361468,-0.4707946442368178,-0.29345619418034397,-1.6804142277706595,-1.6749008295886894,-1.532294799327866,-0.30855537740108974,-1.8028063730739419,0.5634856455829866,-0.871255715202689,0.5407939027769904,-1.3508262991276778,-2.224646492877902,0.07436192716531631,-0.13801254812235508,-0.5222535843752618,False,c3,1,"I'm not happy about how the (still relatively new) added feature for autologin works.
The new JS-based procedure replaces old the in-between page and its `<img>` loads.
This is a reminder to perform a back-to-back audit of it and clean or refactor it. ~~Perhaps we can walk through it this September when I'm visiting the office.~~
It currently performs upto 55 network requests to get things set up:F or each of the entry points CA tries to hit (listed below) multiplied by the number of wiki projects (wikipedia, wikibooks, wiktionary, etc.)
- Special:CentralAutoLogin/start,
- Special:CentralAutoLogin/checkLoggedIn
- Special:CentralAutoLogin/createSession
- Special:CentralAutoLogin/validateSession
- Special:CentralAutoLogin/setCookies
##### See also
* Introduced in <https://gerrit.wikimedia.org/r/58924> / 7a03ac9ac6c28
* Duplicate: {T91196}
* Duplicate: {T130935}
* Bug: {T202028}
* Prior perf work: {T56195}",68828,-54,Medium,False
-2.936380880681102,-3.10558548625192,-2.5557696158964482,2.626938683217036,-0.32002748713465523,-6.161682709881071,-3.3167535142462405,1.4813949134316142,-2.1140648657834458,0.12639977252606283,-2.805229931771371,1.110859366688956,2.030714430716056,1.000316139465009,0.9589076402926029,-1.200135403499594,0.3031969876302387,-0.7077192046195793,False,c3,1,"For every request, lighttpd/1.4.31 was logging the following to error.log:
2014-06-18 10:13:56: (request.c.1148) POST-request, but content-length missing -> 411
While these POST requests for every page view seem to be caused by bug 66225, it still seems wrong that a POST request is sent but its content-length is missing.
I've come across at least two other projects where this was fixed:
* https://core.trac.wordpress.org/ticket/8605
* http://bitten.edgewall.org/ticket/667
Can this be fixed in MediaWiki as well?
./includes/libs/MultiHttpClient.php does contain:
-------------------------------------------------
} elseif ( $req['method'] === 'POST' ) {
curl_setopt( $ch, CURLOPT_POST, 1 );
curl_setopt( $ch, CURLOPT_POSTFIELDS, $req['body'] );
} else {
if ( is_resource( $req['body'] ) || $req['body'] !== '' ) {
throw new Exception( ""HTTP body specified for a non PUT/POST request."" );
}
$req['headers']['content-length'] = 0;
-------------------------------------------------
So, ""content-length"" is indeed set, but I don't know how to get a call chain to see if this method is really used here.
--------------------------
**Version**: 1.23.0
**Severity**: normal",68769,-55,Medium,
-6.660772219208061,0.714201561995873,-4.11957937575211,1.1790854810575624,-0.8922217320535373,-4.192545481358738,-0.3028503017844777,3.7335623934296955,-3.4008343784677697,-1.2422737868394433,-1.9184587837332172,3.2851173959724154,-1.129054565377345,-0.9448471737767807,-1.334970246602606,-0.8254333413274662,-0.8687062309385373,-1.1789032824012167,False,c3,1,"Bug T46113 claims to address this very statement which now reads
if ( $this->proxy || !$this->noProxy ) {
return;
To break this out:
if ( # if
$this->proxy # the proxy is already set
|| # or
!$this->noProxy # noProxy is not set
) {
return;
Instead, it should read ""If the proxy is already set or noProxy is set"":
if ( $this->proxy || $this->noProxy ) {
return;",68757,-55,Medium,
-6.221167167287752,2.1329617491855295,-2.9870797173108574,-0.632047031872484,-3.074647849087238,-0.7313136261886977,-1.1876783009673408,0.690064474081681,0.1568110262996923,-1.1202370001170774,-1.365275620445506,-0.8083961751522624,2.030926330071901,-0.1714164848070059,-0.07461050004436043,1.8710994149178228,-0.9357846295403555,-0.7190422836634314,False,c3,1,"Scheduled: This is scheduled for this Tuesday (2016-08-16) during the 15:00 UTC SWAT window.
**Author:** `swalling`
**Description:**
Previously, we were required to remember a user's session information for no longer than 30 days on Wikimedia sites. The new privacy policy (https://meta.wikimedia.org/wiki/Privacy_policy) does not require such a limitation, and in fact explicitly calls out remembering logins as a use case: ""...such as by using cookies to maintain your session when you log in or to remember your username in the login field.""
As such, if a user checks the ""keep me logged in option"" on the login form, cookie expiry should be set to one year.
In practice, this will often be shorter, since users often travel across many browsers or devices, and may clear their cookies. At the very least, users who opt in to being remembered should have their sessions remembered for longer than the arbitrary 30 day limit.
--------------------------
**See Also**:
{T69512}",68699,-55,Medium,False
-7.4484890286473036,-6.2670014624430905,2.7697368878142683,10.188369435014495,-7.568661324960937,-3.140398035436929,7.563906950418887,2.058276529265099,-0.3416254673718718,1.8315943104762447,1.9788262185758483,1.617491686619603,1.4422169062101862,-2.2883846252343636,4.087716845307452,-1.5891768411534921,0.2508752163220933,-2.7275804172357105,True,c3,1,"performance increase would possibly be realized if https/secure link icon svg was swapped with wikifont icon character for https/secure link
--------------------------
**Version**: 1.24rc
**Severity**: normal",68219,-56,Medium,False
1.2588774005462064,-4.596652126541647,0.6216728635520568,1.1451515127497722,-1.0838452407233434,-0.07314510099922056,-1.57432867976451,2.41801048451229,4.316440308974407,-0.35614492041695645,0.5530675071467921,0.956640545328739,2.7461502626729244,-1.1068941418721203,-1.6563970782380606,0.3544739000877972,-0.11440333989100293,0.2644188754506194,False,c3,1,"**Author:** `ab.zachaeus`
**Description:**
Background: Grow tired of not being able to edit massive (41k+) watchlist by normal means (clicky-clicky or raw) (see bug T41510). Manually whittle watchlist down to 39k+ entries. Dig out https://commons.wikimedia.org/w/api.php?action=query&generator=watchlistraw&gwrlimit=max and hand-craft a list of watchlist entries to be kept after a watchlist purge.
The act: go to https://commons.wikimedia.org/wiki/Special:EditWatchlist/clear and click the button. Watch nothing happen. Get following error message:
```
Request: POST http://commons.wikimedia.org/wiki/Special:EditWatchlist/clear, from 10.64.0.104 via cp1055 cp1055 ([10.64.32.107]:3128), Varnish XID 3575162694
Forwarded for: 84.250.106.149, 91.198.174.103, 208.80.154.134, 10.64.0.104
Error: 503, Service Unavailable at Thu, 05 Jun 2014 19:07:13 GMT
```
--------------------------
**Version**: 1.24rc
**Severity**: normal
**See Also**:
{T41510}
{T66074}",68212,-56,Medium,False
-6.315398060720518,7.030497017125505,-4.560048860365173,-2.4870011640118053,-3.23656450025732,-0.9257632185382125,0.5452200486811298,-0.7668126354479863,-2.080389052750144,-1.1416973572758873,-0.33874983948670767,-0.5331760129149297,1.6007688536399978,0.8405909998201162,-1.7097065593933944,-0.17599823239054513,0.0643226535689001,0.027995381817469633,False,c3,1,"Whenever user has forceHTTPS cookie, any request that comes in via HTTP is automatically redirected to HTTPS. This behaviour is ok for most of the usecases, but it causes countless grievances in the zero-land for the following scenario:
User logs in (or obtains forceHTTPS cookie via some other means) while browsing *.wikipedia.org on WiFi or mobile network. At some point, they discover that their carrier offers wikipedia for free via *.zero.wikipedia.org. They try to navigate there, only to discover that they get an error screen due to using HTTPS (which is not supported by zero most of the time). They report it to the carrier, carrier, complains to us, and we have to explain to them that the only way for the user to use us ever since they got tainted by the ""forceHTTPS"" is to clear their browser's cookie storage.
In order to prevent the unnesesary grievance by many users (and we have heard a lot of this scenario), Zero extension needs to intercept http->https redirect. This redirect happens before most of the code, hence a new hook is needed, as implemented in Change-Id: If04c83066c5d4.
The redirect will be canceled only for the case of valid traffic from Zero partner , exclusivelly to *.zero. subdomain.
Please note that we are not breaking existing functionality here since zero hasn't had a valid SSL certificate until a week ago, and regardless, we do not currently support authentication or editing via zero subdomain.
--------------------------
**Version**: 1.24rc
**Severity**: normal",67567,-59,Medium,True
-7.539651607402941,2.22331136311276,-3.777195498174038,-3.6068733071346655,-2.834309418301293,-1.535011191990152,-1.1340894927268712,-0.19420484970153687,-2.556347253316871,5.615730367613423,1.1941722159017352,-1.477433409755342,2.4623091150600733,4.079814159917282,0.4906793247835637,-0.6164775420839242,0.9783518381757752,-0.8113500391440929,False,c3,1,"If you have HTTPS configured to run on a non-standard port (eg 4430 rather than 443) and you have $wgSecureLogin enabled, clicking on the 'login' link does not work.
This is problematic particularly for the 'https' role in mediawiki-vagrant (https://gerrit.wikimedia.org/r/#/c/132702/) since with vagrant, you cannot forward ports < 1024.
--------------------------
**Version**: 1.24rc
**Severity**: normal",67184,-60,Medium,True
3.74913580738284,-15.248321855319285,3.0017692344796316,-3.2508274542431947,0.22303256080306688,0.4114913620795526,0.8714964530126448,2.4538201240635624,3.109841784207674,-0.15232150453283566,-0.07188618387875678,-0.44977501379622664,0.5382480131694543,-0.3977752539608286,-1.490841432785036,0.31895838311062435,-1.1334059177938043,-1.0728043573593835,False,c3,1,"
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62181",66977,-61,Medium,True
-6.093304541847269,-0.07236557243845354,-1.64696399641711,-0.004311505684857497,5.004932481769865,-0.22808066269683092,-0.2502574416032255,1.2367023263786097,-4.104387248722423,-0.7791005865585525,-0.4363793363059312,1.3501035947141464,-1.383177460700332,-0.09925804355321866,-1.1003050020094882,1.4136638610450405,-1.852951206480963,-1.7360753530285264,False,c3,1,"When registering as a new user, the name you choose is checked as soon as you leave the name-textfield. If you choose a name that's actively in use, you get the warning:
""Username entered already in use. Please choose a different name.""
This should also catch registered usernames that are inactive (have no edits?). Currently those aren't caught until the form is submitted.
In those cases, you get a different error after submission:
""[...] the requested username is already taken in the unified login system""
(This is on most WM wikis. Some have checks for name-similarity which evaluate first.)
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70058",66728,-61,Medium,False
2.719481977315231,-3.9888013857213345,3.931503278676484,3.981515597090132,-4.697242538931274,-2.87101424446674,-1.309470968992497,0.34066422683476005,0.9501039812338785,-1.7759367341018573,0.881238657903761,-0.8641763095375627,1.8142783516129009,1.1458935299881992,1.334711775229609,-0.3873865759378795,0.31550954528318864,-0.37240279946123533,False,c3,1,"+++ This bug was initially created as a clone of Bug #59926 +++
lighttpd redirects URLs of directories without a trailing slash from https to http, i. e.:
| [tim@passepartout ~]$ curl -I https://tools.wmflabs.org/matthewrbowker/cnrd
| HTTP/1.1 301 Moved Permanently
| Server: nginx/1.5.0
| Date: Tue, 29 Apr 2014 22:07:20 GMT
| Connection: keep-alive
| Location: http://tools.wmflabs.org/matthewrbowker/cnrd/
| [tim@passepartout ~]$
So we'll need to teach lighttpd about https (or rewrite redirects in nginx?). From bug #59926, comment #8:
> [...] The proxy provides an X-FORWARDED-PROTO header which can
> be used by the application to construct URIs if it really must redirect
> between protocols.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53689",66627,-62,Medium,True
4.434636244553106,-0.1980488009463155,-1.282126222911705,3.234781542708272,1.288346954949272,1.7924744695043444,-1.8483083497880148,-0.9194362372050106,0.9623374182507858,-1.1251949868817257,-0.3078038339344422,-1.052657227238359,1.9479100340694893,0.7172239072118707,0.6042704778986216,-0.27138834342415497,0.1911448970066152,-0.5560962978843114,False,c3,1,"[16:00 UTC] cvn-apache5.eqiad.wmflabs$ bin/update
+ curl https://noc.wikimedia.org/conf/all.dblist
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a ""bundle""
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",66484,-62,Medium,True
5.342919101922636,3.8786879124129214,7.730494386625672,-1.1158405326664642,2.2648222653875494,-1.0904379290130815,0.6161098268645118,3.5731173695976213,-1.601030126030665,-0.6740124537564718,-3.7324236278989464,-3.51770970774637,-1.7674244325790207,0.7505585206371448,-0.12519433506925726,-1.1533806235879136,1.2605898143995342,1.9813585476532831,False,c3,1,"Recent switchover to HTTPS protocol for Flickr is throwing errors not only for FlickreviewR bot but also for Special:Upload (and possibly UploadWizard but I haven't checked yet). Specifically when inputting an HTTPS URL into the ""Original source"" field this error pops up:
The source must be a URL pointing to the image description at Flickr.
--------------------------
**Version**: 1.23.0
**Severity**: enhancement
**URL**: https://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=fromflickr",65254,-66,Medium,False
0.1352740423993155,-5.6817996513485145,2.377498918524143,-4.034955866168286,2.6041576225612895,-6.374199499474151,1.6530741937638629,0.11044615487706899,5.75247724737944,-0.0975165668491389,-0.5858502679451347,2.3691931439672196,-1.1557953978180207,0.6414054891995757,0.6142568265388748,1.153129274494738,0.8515644418009776,-0.8032637785321,False,c3,1,"I don't know what it should be, but the following is not very clear:
Error loading data from server: error. Would you like to retry?
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39057
https://bugzilla.wikimedia.org/show_bug.cgi?id=43147",65149,-67,Medium,True
-2.915208857172182,3.3576897895824445,-4.186122699778421,-1.6520510597640208,0.570594074587506,0.9320254022286181,0.8372091968125046,2.8056948998074307,-1.2772888663676294,-1.0996386139159071,-0.17607300908404566,-4.248281208741355,1.2388067694802283,-1.7364833437528708,-1.4149060186384474,-0.10152636725859054,0.7325945315549733,0.8341364625689021,False,c3,1,"Kraken's pageview definitions never properly addressed the fact that
we log SSL requests twice (Once for the request at the SSL terminator,
and once for the request from the SSL terminator to the caches).
Up to recently, this peculiarity was not an issue for Zero, as we
were not having SSL traffic in zero. That however changed now.
Currently, Kraken is still doing the correct thing (throwing away the
log line from the SSL terminator, and counting only the request from
the SSL terminator to the caches), but only due to the fact that SSL
terminators do not set a MIME type—which is more than just brittle.
So kraken is doing the correct thing more as a side-effect than by
proper design. This issue becomes more and more relevant, as we're
seeing more and more SSL traffic.
We should teach kraken to properly detect requests from SSL
terminators and consequently filter them.
--------------------------
**Version**: unspecified
**Severity**: normal",64980,-67,Medium,False
15.784487955958362,-2.8701703181218736,2.5175345919129484,-1.474444796801119,7.112976979207689,-0.09303804165376228,0.7853611313715048,1.127577305361184,-3.013757085938413,3.7667018795710874,-1.9118975694709106,2.487836116539885,-1.6619970989676105,0.9593878218261471,-0.25661963592871917,0.9843255371096646,1.912888315856682,-1.1096853159743505,False,c3,1,"Accessing http://wikimania2012.wikimedia.org/wiki/MediaWiki:Gadget-popups.js gives me a notification:
> Central login
> You are centrally logged in. Reload
> the page to apply your user settings
But the user portlet stays unchanged. Console shows:
XMLHttpRequest cannot load https://wikimania2012.wikimedia.org/wiki/Special:CentralAutoLogin/toolslist?returnto=MediaWiki%3AGadget-popups.js&returntoquery=. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://wikimania2012.wikimedia.org' is therefore not allowed access.
--------------------------
**Version**: unspecified
**Severity**: normal",64880,-67,Medium,False
0.6428294564387644,8.80155391203122,0.36553912635196895,-0.8275861482617352,-0.12191364504334279,4.717347963248927,-0.6329377040873512,0.939698140841532,-0.9429408439448812,-0.8433087429536936,1.2475439193045594,3.3582100969596214,-1.097862479563223,0.8773546705494617,-0.455989223173594,-0.049792774983568544,0.3828750671821448,-0.4208208565067677,False,c3,1,"**Author:** `carlb613`
**Description:**
SquidPurgeClient.php seems hard-coded so content delivery network (CDN) nodes are presumed to be Squid, compatible with HTTP PURGE sent from a trusted IP address.
This works if the cache acts like a Squid (Varnish is configurable to do this) but is problematic when dealing with commercial content delivery networks.
Services like CloudFlare (or Amazon AWS) expect the origin server to invoke their specific proprietary API to signal that a page or file has been superseded with updated content.
HTTP PURGE likely doesn't even reach them as the long list of IPv4 / IPv6 ranges is normally handled with [[mw:extension:TrustedXFF]] or a proprietary module (like mod_cloudflare for Apache). Even if it were possible to list the entire CDN in $wgSquidServers, those servers would ignore a Squid-style PURGE message.
The end result is that plenty of outdated content is served as the CDN has no way to know a new version exists until the original version expires from cache.
There needs to be a way to replace the stock SquidPurgeClient with an extension which provides a function to purge CDN files, but I see no hooks in the code to allow this. There are [[mw:Manual:CloudFlare#HTTP_purge]] extensions for WordPress, Drupal and the like but nothing for MediaWiki as the hook to add such an extension does not exist.
--------------------------
**Version**: 1.23.0
**Severity**: normal",64356,-69,Medium,False
-6.109482056083099,3.4957717520213443,-2.018215797489354,-1.3423050137623769,-2.493546786425293,0.3486864163760295,-1.6756187218948932,0.6420213123850829,-1.0791843376964247,-0.07844464341093449,-0.34268925155984853,0.2989583299504539,0.8247187195575392,-1.1004308583753173,-1.5076474581983401,0.3891115350919509,-1.357599875268662,-0.7426083012777291,False,c3,1,"Seen in fairly recent times, particularly for Internet Explorer:
Seen particularly in browser tests, which move quickly from logging in to a particular URL:
It seems that the browser readyState is moved from ""loading"" to either ""interactive"" or ""complete"" before the login process finishes. I believe this because I see automated tests that log in, then navigate to a URL to perform some action only to get an error message that the user is not logged in.
I got around this by adding some code to the shared login method here to check for complete login before the tests proceed: https://github.com/wikimedia/mediawiki-selenium/commit/a1d7fda4af531773a748f990e294fa5adf0b0628
However, this causes problems for tests for the Language teams because every aspect of the user-specific signs of being logged in (Logout link, Preferences, etc.) is localized, making it difficult or impossible to identify a generic way to confirm login.
It would be better to control the browser readyState properly.
--------------------------
**Version**: 1.23.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62244",64001,-70,Medium,False
3.15148704352402,-2.763331372979996,-4.861662938644326,0.9393175013753505,0.32864885155366264,-1.42364098324431,-0.3886526635362948,1.1668255710516235,0.08128620737080822,-2.503391779556211,-0.8029529995890536,-1.7307811088503602,2.2551262294531553,0.1297424538656271,1.1360281485483945,-1.4992132663573041,0.4294852629594508,0.6575766107696215,False,c3,1,"Last working job:
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-npm/942/console
- Feb 16, 2014
- Building remotely on integration-slave01
- node v0.10.22
- npm v1.1.38
First failing job:
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-npm/943/console
- Feb 18, 2014
- Building remotely on integration-slave02
- node v0.8.2
- npm v1.1.39
16:23:41 npm ERR! Error: SSL Error: CERT_UNTRUSTED
16:23:41 npm ERR! at ClientRequest.<anonymous>
16:23:41 npm ERR! at Socket.ondata (stream.js:38:26)
16:23:41 npm ERR! [Error: SSL Error: CERT_UNTRUSTED]
Server log:
https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=99596&oldid=99549
- February 17
- 16:15 hashar: Jenkins deleting slave integration-slave01
- 16:14 hashar: Jenkins added two labs slaves with 4 CPU: integration-slave02 and integration-slave03
- 08:46 hashar: Upgrading Jenkins, half an hour downtime
So npm was upgraded one minor version, and nodejs was downgraded *2 major versions*, and (possibly unrelated) it seems to be unable to verify the certificate properly.
According to existing bug reports, this is related to it being a self-signed certificate, however this shouldn't be a problem since a validation mechanism for their official certificate ships with the npm package. Upstream recommends upgrading to the most recent minor version, but that doesn't seem to be the problem considering the bug started happening for us overnight (no certificate change upstream) when we went from v1.1.38 to v1.1.39 (not down).
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://github.com/npm/npm/issues/4838",63508,-72,Medium,True
3.384288751488612,-0.6239914844689096,-2.8240351026827497,-1.358691465391885,-2.8578526764299585,5.475373932032512,-0.7708245544675343,0.4086010788354839,0.27005474478927605,-2.3866820271943903,-2.5022212907601107,2.3726327708110713,0.3220622672988118,2.208974373728558,1.6854555858712361,0.9347849341909608,-0.24553702713489423,-0.26550277419585955,False,c3,1,"The links in bug #60112, comment #8 are mangled:
- http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-7106.html
- http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-7107.html
- http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-7108.html
This seems to come from wikimedia/bugzilla/modifications:extensions/Wikimedia/Extension.pm's $replacerCVE. There probably needs to be a look-behind assertion in front of the \b.
--------------------------
**Version**: unspecified
**Severity**: normal",63328,-72,Medium,True
12.301747600298286,-2.1746203709847656,-16.359151570065062,6.419762314906985,-1.1622983660013304,-1.3465924111665377,-2.2378563417837958,-0.29638674321384,-0.5769457799859636,-3.881355749365603,1.3108214486205614,-0.7344841960802718,-2.495704338379955,-1.4859914775753515,-1.5426168732928902,-0.6722021747524569,-0.47180774448474105,-0.1453328534248295,False,c3,1,"**Author:** `nels.n.nelson`
**Description:**
www.wikipedia.com uses an invalid security certificate.
The certificate is only valid for the following names:
*.wikipedia.org , wikipedia.org , m.wikipedia.org , *.m.wikipedia.org , wikibooks.org , m.wikibooks.org , *.wikibooks.org , *.m.wikibooks.org , wikidata.org , m.wikidata.org , *.wikidata.org , *.m.wikidata.org , wikimedia.org , m.wikimedia.org , *.wikimedia.org , *.m.wikimedia.org , wikimediafoundation.org , m.wikimediafoundation.org , *.wikimediafoundation.org , *.m.wikimediafoundation.org , wikinews.org , m.wikinews.org , *.wikinews.org , *.m.wikinews.org , wikiquote.org , m.wikiquote.org , *.wikiquote.org , *.m.wikiquote.org , wikisource.org , m.wikisource.org , *.wikisource.org , *.m.wikisource.org , wikiversity.org , m.wikiversity.org , *.wikiversity.org , *.m.wikiversity.org , wikivoyage.org , m.wikivoyage.org , *.wikivoyage.org , *.m.wikivoyage.org , wiktionary.org , m.wiktionary.org , *.wiktionary.org , *.m.wiktionary.org , mediawiki.org , *.mediawiki.org , m.mediawiki.org , *.m.mediawiki.org (Error code: ssl_error_bad_cert_domain)
This prevents users from accessing wikipedia.com and being successfully redirected to wikipedia.org without approving a security override in their browser.
--------------------------
**Version**: wmf-deployment
**Severity**: minor
**URL**: https://www.wikipedia.com/",63228,-73,Medium,True
-3.2022880714272097,1.2360830090107893,0.6583399457060857,-1.1473799914403997,0.8624479122515183,-1.5129734089361635,0.8155030147798437,1.3721201002517858,0.992628695749348,1.1415276274449209,0.9296575810570684,-1.0235930148309227,1.622266639336336,-1.094049711043839,-0.6302234451384487,-0.5921468857221611,0.3201710395517392,-0.07522709279028583,False,c3,1,"Intention:
MediaWiki shows padlock icons next to HTTPS links because a plone developer back in 2003 thought they were cute. Nowadays more and more websites are going HTTPS entirely, and this link decoration is unnecessary clutter. I discussed this here, to figure out why this happens and how to switch them off on my own wikis: https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Padlock_icons_on_HTTPS_links._Why%3F_and_how_to_switch_off%3F ...but with this bug I humbly suggest that the default should maybe be changed.
Steps to Reproduce:
put a HTTPS URL on a wiki page e.g. https://twitter.com/harry_wood and preview/save the page to see how it renders
Actual Results:
On the default mediawiki vector skin you get a small yellow padlock icon to the right of the link. This is quite visually cluttering, making for unnecessarily ugly wiki pages (and with no security advantage that I can see)
Expected Results:
The normal 'external link' icon would be better. Or at least we could phase-out the padlock, moving to a more subtle blue padlock as used on wikimedia sites
Reproducible: Didn't try
--------------------------
**Version**: 1.23.0
**URL**: https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Padlock_icons_on_HTTPS_links._Why%3F_and_how_to_switch_off%3F
**See Also**:
{T61893}
{T32682}",63178,-73,Medium,True
0.2771551968549266,-3.1596112649247257,-1.4731175652371409,3.297806847879528,1.0088982886685744,-3.9600725102927274,-1.9013490430247835,2.0539467954857678,-2.068320919727119,-0.543508223069832,-2.7518685880531017,0.8079861015577261,3.2720151305362832,2.44010580329679,-0.06972540119615989,-0.5413225631227372,-0.15751131859213596,-0.9721641487578796,False,c3,1,"WikiPage::newFromID( 0 ) actually queries the 'page' DB table to look up article ID 0. But MW code assumes that page_id == 0 means the page does not exist, e.g. Title sets mArticleId to 0 if article not found. So newFromID() could return null early if ( $id == 0 ).
One caller of this is ApiBase::getTitleOrPageId() , as a result API clients that pass pageid=0 hit the database, some even querying 'fromdbmaster'. AFTv5 is one example (bug 61164).
--------------------------
**Version**: 1.23.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61164",63166,-73,Medium,True
-5.263202158017271,6.27211238464869,-3.1044986626035644,-0.6546414250434252,1.7707384547032383,-3.16037984102865,1.6525247328743013,2.540029270741888,-3.187380135411848,-2.1850206880966296,-3.2229138337887995,2.2299157835271926,-0.9800828943067232,-0.710620794236104,0.3001434346172882,-0.3029164006525752,-0.30105550226723343,-0.7743573515195714,False,c3,1,"While testing another preferences patch, I found that stock mediawiki is no longer respecting the preference to disable https after login when wgSecureLogin is set.
* User is redirected to https when they click login, and the url parameter ""fromhttp=1"" is added.
* User logs in (doesn't seem to matter if remember me is selected or not)
* User is logged in, and cookies are set *for encrypted connections only*
* User does *not* get a forceHTTPS cookie
* User is redirected to the https version of the page where they clicked login
Obviously, if the user types in an http:// url, they are no longer logged into the site since the cookie are set for https calls only.
CentralAuth correctly handles the preference, so most users on WMF wikis are not affected. But we should get this fixed.
--------------------------
**Version**: 1.24rc
**Severity**: normal",63048,-73,Medium,False
2.949068338327287,1.2902595203555123,1.0142327921546475,-5.237698265773374,-0.24980341495631309,-0.5370319981139398,2.8720229691329697,5.387366541205821,-0.3415357661635799,0.13197948478539523,-0.5629570185731172,-5.068893112951363,-0.7121936844835748,0.11742138308855754,-0.7811104287734443,-1.5960282213759374,0.3062446849126772,-1.2961932605299515,False,c3,1,"Previously, the edit pencil didn't errantly show on Wikipedia Zero due to the current lack of HTTPS support. Now it is showing again.
--------------------------
**Version**: unspecified
**Severity**: normal",62774,-74,Medium,False
0.20664831114478188,-0.588937982283122,-3.256613572056837,-1.4688766259567418,-2.1355186617961475,1.7561174845059153,-3.995823362424451,-1.56638677516962,1.237460807477821,-1.6247756307768908,-0.28344195188082955,-1.242802041074652,1.6223683699336822,-0.3082085389139637,-1.095711506910935,-1.0352550165535066,-1.5415839750346139,-0.12176194354135506,False,c3,1,"If I visit action=watch logged out, I get:
----
You must be <a href=""/wiki/Special:UserLogin"" title=""Special:UserLogin"">logged in</a> to modify your watchlist.
Return to <a href=""/wiki/MediaWiki"" title=""MediaWiki"">MediaWiki</a>.
----
The Special:UserLogin URL should include a returnto parameter so that after logging in/registering the user can at least get back to the original page.
--------------------------
**Version**: 1.23.0
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Requests_for_comment/Performance_standards_for_new_features?action=watch",62594,-75,Medium,True
-9.967341211026326,6.4755395453328575,0.40218291020242347,1.7573344120173346,-1.8022059486852144,3.9783561328290897,-2.7648912592058896,-0.9773144259215361,0.904619992966949,-2.8255018309943725,-1.662357801127216,0.926738108632071,2.349450937603536,-1.6325517801749148,3.1615732211780747,-0.4764677527964315,1.6890743726339583,-2.6682007148834006,False,c3,1,"Before gerrit 94406 it was possible to confirm a email code without the need of login to (any) user account. This was changed and produced bug 60433.
In my opinion the old behaviour should be restored.
If not, the logged in user should be checked against the user which gets confirmed, because that can differ at the moment.
--------------------------
**Version**: 1.23.0
**Severity**: normal",62434,-75,Medium,False
-5.594911151608654,-7.354517982024683,-3.822995075438575,11.931805240881049,-1.3082410264744244,-6.544216205157136,-0.41243268269661915,-0.90685792721293,-0.5435603854435267,-2.1554463249446663,-0.7783779339955093,-0.24384365553660725,2.310839490064102,-1.4629205033528612,-1.0070828004440031,0.013517320148489165,-0.24899108721086982,-1.0254884608358288,False,c3,1,"Although requests from ssl terminators are visible in the udp2log
stream when consuming directly, and also in the edit tsvs [1], none
are visible in the sampled-1000 tsv [2] or the mobile-sampled-100
tsvs [3].
Due to the numbers exposed by the edit tsv we'd expect >1000 lines/day
from ssl terminators in the sampled-1000 tsvs, and >500 lines/day in
the mobile-sampled-100 tsvs due to the edit requests alone.
Are those two streams suffering the same problem as edit tsvs suffered
before 2014-01-14 (bug 60314)?
Let's get the ssl requests into the sampled-1000 and
mobile-sampled-100 tsvs!
(I've been told sampled-1000 is collected independently on two
different hosts. Is the one that does not get mirrored to stat1002
also affected? Not sure which those hosts are. The udp2log filters
live in
https://git.wikimedia.org/tree/operations%2Fpuppet/production/templates%2Fudp2log
)
[1]
___________________________________________________________
qchris@stat1002 // 0 // 00:36:41
cwd: ~
zgrep -c '^ssl' /a/squid/archive/edits/edits.tsv.log-20140121.gz
1358968
[2]
___________________________________________________________
qchris@stat1002 // 0 // 22:14:02
cwd: ~
zgrep -c '^ssl' /a/squid/archive/sampled/sampled-1000.tsv.log-201401*.gz
/a/squid/archive/sampled/sampled-1000.tsv.log-20140101.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140102.gz:0
[...]
/a/squid/archive/sampled/sampled-1000.tsv.log-20140113.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140114.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140115.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140116.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140117.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140118.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140119.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140120.gz:0
/a/squid/archive/sampled/sampled-1000.tsv.log-20140121.gz:0
[3]
___________________________________________________________
qchris@stat1002 // 0 // 22:47:06
cwd: ~
zgrep -c '^ssl' /a/squid/archive/mobile/mobile-sampled-100.tsv.log-201401*.gz
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140101.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140102.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140103.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140104.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140105.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140107.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140108.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140109.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140110.gz:1
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140111.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140112.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140113.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140114.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140115.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140116.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140117.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140118.gz:0
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140119.gz:1
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140120.gz:2
/a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140121.gz:0
The four matches from the 201401{10,19,20} files are artifacts from an
ssl terminator request line being too long and getting messed up with
a subsequent mobile request line.
--------------------------
**Version**: unspecified
**Severity**: normal",62315,-76,Medium,False
-4.543685280811126,-4.212282568769092,-5.19825979703827,4.319798967055683,-2.5921409716004504,-3.903565763229672,-1.9219742974923966,0.01294273299076798,-1.984046914582369,-2.39510660311448,1.571357903415898,-1.0701044250449039,3.3404651240781886,-0.010934246235509093,0.47650256950238035,-0.3295712086498386,-0.26132974303533074,-0.48696757198987517,False,c3,1,"It seems fixing bug 58876 made the logged requests from ssl
terminators jump from ~50/day to 1.3M/day [1] ... which is actually good.
As the ~1.3M/day seems more plausible than ~50/day ... Did some of the
(maybe) relevant changes
https://gerrit.wikimedia.org/r/#/c/105449/
https://gerrit.wikimedia.org/r/#/c/105450/
https://gerrit.wikimedia.org/r/#/c/105451/
really unbreak edit.tsv writing for ssl terminators as a side-effect?
If so, how could they have unbroken storing requests from ssl
terminators ... should not x-encoded requests have gotten logged
nonetheless?
(They for sure were in the stream before, as I checked before writing
the changes above, and some are visible in the edit tsvs for the
previous dates.)
Was there some network issue beforehand?
Was udp-filter (see [4] for its invocation) misbehaving?
Once we understand what went on, would we need fixes elsewhere?
Is the 1.3M/day now finally about correct?
Some more pointers:
* The above gerrit changes got deployed to ssl1001 on 2014-01-14
~18:56 [2].
* Heavy ssl traffic in the edit tsvs starts on 2014-01-14T18:59:11.634
and is limited to ssl1001 at first. On 2014-01-14T19:06:23.209 other
machines kick in.
* There was a deployment window on 2014-01-14 19:00-21:00 upgrading
group1 1.23wmf9->1.23wmf10 [3], but it looks unrelated, as we're
seeing ssl requests pour in for unaffected wikis.
[1]
___________________________________________________________
qchris@stat1002 // 0 // 22:13:50
cwd: ~
zgrep -c '^ssl' /a/squid/archive/edits/edits.tsv.log-201401*.gz
[...]
/a/squid/archive/edits/edits.tsv.log-20140112.gz:47
/a/squid/archive/edits/edits.tsv.log-20140113.gz:18
/a/squid/archive/edits/edits.tsv.log-20140114.gz:17
/a/squid/archive/edits/edits.tsv.log-20140115.gz:557830
/a/squid/archive/edits/edits.tsv.log-20140116.gz:1307081
/a/squid/archive/edits/edits.tsv.log-20140117.gz:1336017
/a/squid/archive/edits/edits.tsv.log-20140118.gz:1345793
/a/squid/archive/edits/edits.tsv.log-20140119.gz:1379590
/a/squid/archive/edits/edits.tsv.log-20140120.gz:1343811
/a/squid/archive/edits/edits.tsv.log-20140121.gz:1358968
[2] See
http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-operations/20140114.txt
around 18:54, look for ottomata & qchris.
[3] https://wikitech.wikimedia.org/wiki/Deployments/Archive/2014
[4] https://git.wikimedia.org/blob/operations%2Fpuppet/aa4f6383ac7fc8dc5515d8466574368658f959ed/templates%2Fudp2log%2Ffilters.oxygen.erb#L13
--------------------------
**Version**: unspecified
**Severity**: normal",62314,-76,Medium,False
0.3391264639915157,-2.380023725455315,1.3437392220049276,-3.2365140391092635,1.4101987994436116,-3.262139764862799,4.045736162284856,0.26133311593208763,-1.19142347566586,-1.004343603795797,-0.7369128197608661,-1.630919238032051,-1.1017316880751498,0.5901914191249489,-1.3843096714305076,0.7454780968177017,-0.7605038626946922,-0.3624647005513757,False,c3,1,"Just noticed that Icinga apparently has httpauth on, so it's not accessible for me (the public).
Is there a security issue or other reason that forced this?
also http://status.wikimedia.org/ reports it as down for several days.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://icinga.wikimedia.org/icinga
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54713
https://rt.wikimedia.org/Ticket/Display.html?id=6838",62112,-77,Medium,False
1.0677401699809734,5.012769341452181,5.376231201995019,5.455483861394937,1.8523753036517205,4.0329693641676325,1.0851355062379673,-2.6763395431103687,2.5587676932868915,-0.239145288054603,0.8899232159013817,-2.783303089743337,0.8401279030291868,1.9282389238202748,1.8112519662974433,-0.6564068865250808,-0.34846423941838256,1.1860654044030638,False,c3,1,"Gerrit change 17952 changed Special:UserLogin to return a Status object from the account creation function, passing it a RawMessage which breaks the expectation of the API's dieStatus method that it can get a sane key from the message object's getKey method.
But then Gerrit change 47821 broke things worse by changing Special:UserLogin to pass a raw string rather than a Message object or message key as Status::newFatal expects.
--------------------------
**Version**: 1.23.0
**Severity**: normal",62008,-77,Medium,True
-3.3410447169810285,-3.852367353752898,-1.8304871364405884,-0.4829599247719706,-1.2589663075260045,-3.7059158036588995,-1.585226464831612,-0.832707499725698,4.423569630996306,-1.3296956160599533,1.0271264713515937,0.4498081420712492,0.12791060192013326,-1.075026233986157,-1.203088650814279,0.12279889610807482,0.09929264478878763,-0.8958587424107824,False,c3,1,"Hey,
it would be really nice if you guys would enable the possibility to change ones preferences on login.wikimedia.org.
Currently that's not possible, but as a steward I sometimes use the wiki to run checks and I'd like to change the skin to monobook and I could imagine that some folks would also like to change their language.
Thanks!
[[m:User:Barras]]
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://login.wikimedia.org",61692,-78,Medium,True
-4.671415124287301,-1.8407775199408665,-4.011044606223027,5.086847897680366,-3.122127776813776,-0.9831443932453411,-2.455258114547085,-0.6167382259103054,-3.1450503069249747,-3.147116293021927,0.34916973618660974,0.04101646877311782,5.30300164023361,2.1492149257264233,0.7921835314295524,-0.8168071568232336,0.5552125499729252,-0.6732911124069259,False,c3,1,"Since 2013-12-10 we're seeing between 15-40 lines per day in the
sampled-1000 cache logs that have “nan” in the “Request service time”
column [1].
For the mobile-sampled-100 cache logs it is 10-30 such lines per day [2].
The zero logs do not show any affected lines up to now.
The affected lines come with “-/” for the “Request status / HTTP
status code” column, and “Reply size” is “-”.
[1] The first occurrence for the sampled-1000 stream can be obtained by
running
zgrep 49094481570 /a/squid/archive/sampled/sampled-1000.tsv.log-20131210.gz
on stat1002. That line is for cp1050.eqiad.wmnet on
2013-12-10T03:36:04.
[2] The first occurrence for the mobile-sampled-100 stream can be
obtained by running
zgrep 9650126710 /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20131210.gz
on stat1002. That line is for cp1047.eqiad.wmnet on
2013-12-10T02:01:24.
--------------------------
**Version**: unspecified
**Severity**: normal",61645,-78,Medium,True
-2.6051814355880123,2.1070150221599455,-0.01131940407771026,-4.008576399757089,3.588115958287895,-0.42291297522415483,-1.7758150658559861,-0.07716809935125887,1.5861478296736515,1.34117124908438,1.2339666479985385,2.592464893262748,0.5982908608403252,-0.15603783350059697,-1.1575704282048944,-0.06541742161685937,-0.14090979137455295,0.3874359114290862,False,c3,1,"This may need to be split out to separate bug reports.
The annual fundraising e-mail contains this text:
---
You are receiving this email as a valued donor of the Wikimedia Foundation. If you do not wish to receive any future emails from the Wikimedia Foundation, unsubscribe instantly.
---
""unsubscribe instantly"" is a link to <https://links.email.donate.wikimedia.org/>. This domain doesn't have a valid SSL certificate, so the browser throws a terrifying warning. This is bad.
If the user chooses to proceed, he or she is presented with an awful form (so much for instantly unsubscribing...):
---
Opt-out Email Confirmation
Enter Email: [ ]
[No, I do NOT wish to Unsubscribe] [Yes, Unsubscribe me]
---
Requiring the user to re-enter his or her e-mail address is a pretty dickish move.
And finally, ""No, I do NOT wish to Unsubscribe"" is abominable language. The only way the user can figure out what that button does is by reading the other button and realizing it's the ""Yes"" button that he or she wants.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72514",60373,-81,Medium,True
-3.058074433419409,-5.39865886290435,-5.120641716064579,-7.054455630275215,-4.172255488236223,-1.93296653710073,4.8648892535048835,-3.761538254665606,-0.4493464598044687,4.926706809240159,1.9839159788250638,-1.94816096096234,-0.3205417766330365,-1.0879747831583821,2.0625259076861653,0.725185217703957,-1.267113996657998,0.4048441234492255,False,c3,1,"I imagine it might be additionally useful for .sig files, but just in general ""because we can"", right?
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0.tar.gz
--------------------------
**Version**: wmf-deployment
**Severity**: normal",60292,-82,Medium,True
1.620969385522622,-0.4476270539870182,1.4191063027867195,5.33527902478112,4.161743099277988,1.0040177208193655,-3.981548098264891,-0.6840299439807271,1.1275550327240247,4.862905055945159,-6.103358046228745,0.10453045041280995,-3.3234353665540963,1.8332729501789924,-0.285554668587503,-0.7451031093098672,2.5222137936670475,-2.3080642854299946,False,c3,1,"The login page showing no 'Forgot Password' link
The gerrit login page doesn't have an option 'Forgot password' or 'reset password' so as to reset the password, if lost.
This is an essential feature, which almost all login pages should have.
https://gerrit.wikimedia.org/r/login/
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**Attached**: {F12520}",60205,-82,Medium,False
4.788933099976935,1.5348092941905147,1.4828708989876027,-0.7461652934298959,-1.5783426046474083,0.8124663210756482,1.005180115757656,-2.4376036782512296,1.7326712124708286,0.23666020852377123,0.281101632578991,1.0551081617401554,-0.24730735756851185,1.0777576338277033,-1.8535245344805347,0.2695427813440115,-0.1268246180511572,-1.4842631900301868,False,c3,1,"**Author:** `jaredflores2000`
**Description:**
Shows effect of different fonts used to generate CAPTCHA
The CAPTCHA on the login/signup page in Special:UserLogin overflows the container because it doesn't have any specified size parameter to constrain it.
--------------------------
**Version**: unspecified
**Severity**: trivial
**Attached**: {F12591}",59821,-83,Medium,False
-1.7164926704383463,2.399580310014578,-1.2227662412334332,-4.354453661186282,-2.884201265901859,1.8320590116715005,0.32318491663246096,-2.6339343789059257,-0.22537695967302973,0.8880798055161945,0.23783214843349754,-0.38317976975402024,1.069993241146301,-0.514567586185156,-0.13741898030779964,-1.238703187087037,-0.6433597615225257,-1.690167926456646,False,c3,1,"make SpecialChangePassword form text depending on login status of $wgUser
During development of Extension:OpenID I found, that I have to apply a small patch to ChangePassword for the case that I want the pre-login user to enter their temporary password.
During development of E:OpenID, I found that the SpecialChangePassword shows the ""Temporary password"" text only if I apply this patch.
https://gerrit.wikimedia.org/r/#/c/96651/
I suppose, but I am not sure, that this was a design mistake (in the old version of ChangePassword) to check against the passed parameter $user instead of (new version) to check against $wgUser.
This is a request for comments.
Chris answered on Patch Set 4: Code-Review-1:
> This seems like the wrong way to accomplish this, and seems like it relies on another bug that might disappear.
> I'd rather see this use a parameter to showForm(), or use a flag in the class to indicate what wording you want, and then have your code set that.
I still think, that originally $wgUser was meant, perhaps you can ask around.
For my extension OpenID, which calls under certain conditions ChangePassword, an additional parameter would be fine, in order to trigger the correct label text ""temporary password"".
--------------------------
**Version**: 1.23.0
**Severity**: normal",59731,-83,Medium,
1.3264295736439418,0.6469070030175956,4.570533795598493,1.9840990305632946,-1.06930979674363,3.6948280340870605,0.5618503233612708,-0.497075308034127,-3.8644323676062875,-1.9283063502295725,-1.3109569744513383,0.20521131157394334,2.1156427365758437,3.129268355912256,0.7391738263355965,-1.7174180402382797,0.17989057663129904,-0.6725624457769075,False,c3,1,"Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture:
https://commons.wikimedia.org/wiki/File:Haubitzenbatterie_mittleren_Rheinbr%C3%BCcke_-_CH-BAR_-_3237358.tif
--------------------------
**Version**: 1.23.0
**Severity**: major",59717,-83,Medium,False
-6.300290432171359,5.4951833165147335,0.7964206020008433,2.225746434019874,1.018745148441187,0.44498685608142385,-0.22112475131111786,2.318326744734561,0.5746919632414152,-3.101097172667047,-2.494639726159561,-1.3056065287274126,-2.065942310288789,0.21186469753676818,-0.047644582937843794,0.14903087509756957,-0.7555360028868555,0.40422581761053844,False,c3,1,"$wgPersonaLoginAnywhere turns on having the Persona login button on every page in the Personal URLs section, rather than just having a button on the login page.
However, when $wgSecureLogin is enabled, all logins must be over HTTPS. Right now this is handled poorly: if the user is on HTTP and clicks the Persona login button, they go through the whole login process just to get an API error.
Unfortunately, there's really no way to make it work completely, but there are a couple of options:
1) Throw a configuration error if a sysadmin tries to have $wgSecureLogin turned on, $wgPersonaLoginAnywhere turned on, and $wgServer with non-HTTPS as the scheme
2) Automatically redirect all users to HTTPS (probably the less friendly option)
--------------------------
**Version**: unspecified
**Severity**: enhancement",59635,-84,Medium,False
-1.8100476890300135,-2.9157611150515166,0.8042235810059495,0.2579479352221201,-3.056666634743974,1.0958218653705185,1.8837653040331581,0.8810324938221606,-0.2239218725813064,6.588606441675852,2.4061741808183235,1.2792019734331916,1.3214979941708864,-2.5633056501739966,2.013554299325218,0.2078214821426232,-2.568905618110253,0.2709563127863446,False,c3,1,"semantic-mediawiki.org offers https access. Thus it will be nice if the link for the existing interwiki prefix ""semantic-mw"" could be changed to ""https://www.semantic-mediawiki.org/wiki/$1"". Many thanks in advance!
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://semantic-mediawiki.org/wiki/Semantic_MediaWiki",59513,-84,Medium,True
-1.730534693004028,0.27046605881206354,-3.4934883777252033,-2.237416858163662,3.739659426934552,-1.3832781145714979,0.25810903101508575,1.5607542694304057,1.358376291797024,-0.008369277416528043,-0.5898513096552445,1.5631764166467523,-1.5583667606424516,1.7674879450657022,-2.4507791042160405,2.011238122024596,5.143628247628261,-0.5701046460302397,False,c3,1,"Spam BlackList doesn't block links which doesn't have http or https or // (at the first)
for example I could add www.atbriders.com to the text which is listed in https://en.wikipedia.org/wiki/MediaWiki:Spam-blacklist
see
https://en.wikipedia.org/wiki/User:Yamaha5/Spam-blacklist
it should block also URLs which doesn't have http: or https: or // (at the first)
--------------------------
**Version**: unspecified
**Severity**: enhancement",58932,-86,Medium,True
0.6161909181503011,2.464581633826132,-2.1481719840848594,-0.2624986183109389,-2.971772151751929,-1.1334952114480126,-3.7619886869048735,2.5039394924572105,0.35369574962151873,-0.9539712504762901,-0.02430270056819328,-0.44154648502356,-2.220302473039636,-0.37707039630124317,-0.47285026118926865,-1.2134742872488553,0.16700074610159588,-0.10567344099213094,False,c3,1,"The ConfirmEdit extension allows for local wikis to whitelist links using [[MediaWiki:Captcha-addurl-whitelist]]. But this only allows for whitelisting http and https links, even though the extension will trigger a captcha for any protocol.
The question here is twofold:
1. Should ConfirmEdit trigger captchas for other types of links in the first place?
2. If so, how can we extend [[MediaWiki:Captcha-addurl-whitelist]] to allow these to be whitelisted?
Personally, I'm inclined to answer ""yes"" and ""Perhaps add flags like in [[MediaWiki:TitleBlacklist]], one of which would indicate that this line should not be prefixed with /^https?:\/\/+[a-z0-9_\-.]*/""
--------------------------
**Version**: master
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Contains_external_links",58485,-87,Medium,True
6.524286992446125,-2.6466808868496035,-3.7508812513945156,-2.038122632014045,-2.329003597927403,1.1117942555555766,-6.050201782665526,0.5192007105069631,-0.68802872834384,4.656682741802072,-5.6753346615626485,0.8343264312227714,-0.6224294982717131,-0.8782929064250409,-0.21960210870104913,-0.19264130865564255,1.7651592462501589,-1.839271366031864,False,c3,1,"User signup during wikimedia installation -> Field is 'Real Name'
While installing medaiawiki 1.21.2, in the sign up Page, The Feild 'Real Name' value is taken up by the Mediawiki server as 'username' and is used to login after the installation.
The feild 'Real Name' should be changed to 'username' during installation step.e
--------------------------
**Version**: 1.21.x
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56551
**Attached**: {F11933}",58235,-88,Medium,True
-1.7469035857907698,4.3505041987210475,2.528639471098849,-1.6057916854466847,-0.8260764246449666,-0.7362837491389124,-5.246195554456012,1.608459798695153,2.308992118730063,1.966854797273239,-1.6681858774157565,1.8900791384003666,-1.4318483720451924,-0.5186364735291669,0.4562101144909416,3.661894716685825,-1.9486786343273539,0.5793051030974044,True,c3,1,"On https://en.m.wikipedia.org/wiki/Special:UserLogin and https://en.wikipedia.org/wiki/Special:UserLogin
When a user is logged in we should add a greeting above the login fields that says
""Hello, $username!"" to show the user they are already logged in.
The [Sign in] in button should say [Switch Account] and create account should say ""log out""
--------------------------
**Version**: unspecified
**Severity**: normal",58023,-89,Medium,True
3.5733961750626153,-4.088705314230678,-2.1420643244745587,0.03254564648845393,1.2818369346475906,-0.3653644251931165,-1.6533203495910174,-1.0936621078104714,-0.7936812558744107,-2.1088365410909944,1.0751908346397,-1.0880581708431951,1.9973048769338835,-0.46641434782934876,-0.026193818164038873,-0.25747484281530864,-0.35967241365984726,0.3269424199633304,False,c3,1,"**Author:** `kudu`
**Description:**
Log showing incorrect behavior for a non-*.orain.org wiki
Demo:
1. Log in on any wiki on orain.org (e.g. meta.orain.org).
2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat).
I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.
Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61
Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2
We're running CentralAuth 1.22wmf22 (3756064).
--------------------------
**Version**: master
**Severity**: major
**Attached**: {F12201}",57978,-89,Medium,True
-0.25403651155549767,-6.066841296452155,-2.118056969670196,-2.7543850616923677,-0.3560359897797273,-0.9026158152804008,-0.711123703509676,-1.550067115639131,-3.816077329503111,-3.2199971893261665,-2.3388640975815997,2.736249009697673,-1.567870706895362,-2.066456758029247,-0.24749076995962493,-2.1882568671025027,0.08682296156589975,-0.5322045617440254,False,c3,1,"```lang=bash
<~/pywikibot>git clone --recursive ssh://multichill@gerrit.wikimedia.org:29418/pywikibot/core.git
Cloning into 'core'...
Warning: Permanently added the RSA host key for IP address '[208.80.154.81]:29418' to the list of known hosts.
Enter passphrase for key 'key':
remote: Counting objects: 10842, done
remote: Finding sources: 100% (10842/10842)
remote: Getting sizes: 100% (1495/1495)
remote: Compressing objects: 100% (2292733/2292733)
remote: Total 10842 (delta 7190), reused 10548 (delta 7165)
Receiving objects: 100% (10842/10842), 23.42 MiB | 326 KiB/s, done.
Resolving deltas: 100% (7337/7337), done.
Submodule 'externals/httplib2' (https://gerrit.wikimedia.org/r/p/pywikibot/externals/httplib2.git) registered for path 'externals/httplib2'
Submodule 'i18n' (https://gerrit.wikimedia.org/r/p/pywikibot/i18n.git) registered for path 'scripts/i18n'
Cloning into 'externals/httplib2'...
error: SSL certificate problem: self signed certificate in certificate chain while accessing https://gerrit.wikimedia.org/r/p/pywikibot/externals/httplib2.git/info/refs?service=git-upload-pack
fatal: HTTP request failed
Clone of 'https://gerrit.wikimedia.org/r/p/pywikibot/externals/httplib2.git' into submodule path 'externals/httplib2' failed
```
I'm cloning over ssh. Why are the submodules being loaded over https?
--------------------------
**Version**: core-(2.0)
**Severity**: normal",57654,-90,Medium,False
-2.865304251686181,-6.253991580425513,0.9681674523562016,8.231532176549,8.296476189997486,0.6564815436040934,0.05067791326094717,0.12548747025459833,8.55429207063551,-1.7491053409020072,-4.395684339645955,1.6099323982163274,-4.864626268207513,4.60145339591104,0.394079243022162,2.2051878854780345,3.6140349283953848,0.33373622906754163,False,c3,1,"Add the login help page, so the login form doesn't have a redlink
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",57425,-91,Medium,False
-4.359812713616321,0.6256654750012025,2.475523103954263,-2.349641708753558,3.3217750841467355,-0.3667769710630261,1.1979939160694437,-1.7321366117596875,-0.9507705737260869,-2.3013053410642743,-1.6496628391975015,3.8406962680315697,-0.21245090521898646,1.7198038890008283,3.269738715506622,0.7740267799287512,0.6462658269632715,-0.5694668288510958,False,c3,1,"Hi
When I run parsoid linked to a wiki which is https only, it doesn't work. This can be reproduced in any installation.
I set port 80 to be a redirect to port 443, and the parsoid URL is https://wiki.name/api.php in localsettings.js
--------------------------
**Version**: unspecified
**Severity**: enhancement",57369,-91,Medium,True
-5.068726435531736,0.3290396531216242,-0.39512935793746173,-3.4616756024411077,0.9054074338869063,1.3706837764652213,2.169874144057034,0.9162788649945403,-1.6332559275400096,-0.1832366834132264,1.411469149769514,3.7823028908335843,1.8326583675603767,-2.5530903495737918,2.6900249749373915,-3.3417350850892,-1.5006439304405488,1.0677087772866167,True,c3,1,"UDP logging for search is currently disabled. However, it would be good to be able to track the main errors. An example of one that seems important (which I was receiving earlier tonight) is:
An error has occurred while searching: HTTP request timed out
--------------------------
**Version**: unspecified
**Severity**: normal",56865,-92,Medium,True
4.622046395222393,-3.2660977876874604,-1.8015324825382635,-1.9020543445503733,5.6782175713734535,4.01069704510894,1.515973978995489,-2.5254530396959094,2.043094731754227,-1.266513881985567,-0.5520960093982326,0.060437259479589445,-1.4208023666726755,0.026282668034768975,1.157293228810322,-1.443002331104299,-0.2820244312584248,0.9231763218573248,False,c3,1,"https://login.wikimedia.org/wiki/Special:CentralAutoLogin/deleteCookies?type=icon - this is using a Wikipedia logo currently. Can we use a Wikimedia logo at least?
--------------------------
**Version**: wmf-deployment
**Severity**: normal",56500,-93,Medium,True
-0.8979465878542623,3.5765569326227045,1.9779321217206771,-1.906478673432221,3.3856040179966307,5.572757893202964,2.1463886591093564,2.5989752966128936,-3.4497219648317357,1.1816498703543719,2.4473291474714443,-2.0724055739552742,0.12559331801577844,-0.3125761300218617,-1.443966222115404,0.6892889846727382,0.3204187889451995,2.4592703985843727,False,c3,1,"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.
When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected.
--------------------------
**Version**: unspecified
**Severity**: normal",56468,-93,Medium,True
-4.167328230963918,0.944343477792021,-5.630487697311558,-0.8803020005168496,1.359375993994989,0.24511353675931735,-0.389265194205751,-0.14638895592031315,1.1340773068275252,-1.582339299295096,-0.504141325138912,-3.750247953230229,1.2466857937154354,-4.27745526508747,1.2417453375363117,-1.2231615468608537,0.6534709318782259,-0.7576825795156059,False,c3,1,"DGarry (WMF) was hitting a bug today where he logged into enwiki, and SUL logged him into most of the other projects. But, his account wasn't attached on commons, and so that autologin attempt failed, with an error in the header saying the user didn't have an attached account.
When he logged in directly on commons, the account was autocreated correctly.
We should be autocreating the accounts, like used to happen with the old AutoLogin.
--------------------------
**Version**: master
**Severity**: normal",56292,-94,Medium,True
13.054734696180482,3.0837791021550203,1.3320643122994653,-0.9438489257033892,-0.17184314314658505,-3.523041333807191,0.08135373174360883,0.06572028615122094,-1.7311418650357435,-0.4644955102143138,-0.5340728036253015,1.6736719792419084,2.211244109179715,1.1632078722769688,-0.03036287341394317,-0.14505613112219484,0.05677568059303262,-0.7103506020349375,False,c3,1,"Ops pointed out that almost 60% of the apache traffic is calls to Special:CentralAutoLogin. About half of that traffic is to /start, so it looks like Special:CentralAutoLogin/start is still not cached, even though we don't disable client caching in the output page. MediaWiki is sending Cache-Control private.
csteipp@linux-hv06:~> curl -Ik 'https://en.wikipedia.org/wiki/index.php?title=Special:CentralAutoLogin/start&type=script&returnto=One&returntoquery=' | grep Cache-Control
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
It seems like that is because OutputPage checks to see if $this->mSquidMaxage != 0, otherwise it sends out the private header. On my dev system, I added $this->getOutput()->setSquidMaxage( 3600 ), and I then get
csteipp@linux-hv06:~> curl -Ik 'https://127.0.0.1/wiki_port83/de/index.php?title=Special:CentralAutoLogin/start&type=script&returnto=One&returntoquery='
HTTP/1.1 302 Found
Date: Mon, 16 Sep 2013 23:32:21 GMT
Server: Apache/2.2.22 (Linux/SUSE)
X-Powered-By: PHP/5.3.17
X-Content-Type-Options: nosniff
P3P: CP=""This is not a P3P policy! See http://127.0.0.1/wiki_port83/de/index.php?title=Special:CentralAutoLogin/P3P for more info.""
Vary: Accept-Encoding,Cookie
Cache-Control: s-maxage=3600, must-revalidate, max-age=0
Location: https://127.0.0.1/wiki_port83/pool/index.php?title=Special:CentralAutoLogin/checkLoggedIn&wikiid=dewiki83&proto=https&type=script&returnto=One&returntoquery=
Content-Type: text/html; charset=utf-8
Is that enough to have varnish cache these, but logged in users will always bypass the cache?
--------------------------
**Version**: master
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52206",56195,-94,Medium,True
-6.200682750557084,-1.0642495207295166,-7.097534131465682,-4.3251966760965495,-0.605851593011476,-1.8827537198321722,-0.7630753677906474,-4.611348945173739,0.5448260993004413,-1.0875367508240146,0.5171354092090041,-0.3164396663643594,0.5302886729056668,-1.3374876609029456,1.2585825679819171,-0.09036695190238136,-0.7939520589276176,1.6412145623419432,False,c3,1,"helplogin-url is shown in a very prominent place by default and it should point to an existing page to avoid confusing users with links to nonexisting pages, similarly to bug 53862.
We have [[mw:Help:Logging in]], which given the author I assume ok and that can be made translatable when we are comfortable about the quality of its content (it had some ""manual"" translations on Meta). Linking it will help improve it, but it's already better than the default red link.
--------------------------
**Version**: 1.22.0
**Severity**: enhancement",55888,-95,Medium,True
-1.6077650622670598,-3.459691089579769,-5.4906653210246095,0.08571723391036334,-3.7363627571373454,-1.4715819968040733,-2.769550925680437,0.3553257151193262,0.12037584830684195,5.03481492231316,0.8803471673838832,-0.9738061309988235,-0.8339293660663234,-1.1814720742638545,1.0165644732199217,-0.20522051562739818,0.6794467398570851,-1.55862465908042,False,c3,1,"**Author:** `Thehelpfulonewiki`
**Description:**
In bug 23231 a number of private wikis had wgBlockDisablesLogin set as true. Since then we've had some more private wikis created (such as IEGCom Wiki, Transition Team wiki etc). Instead of requesting this setting to be set on a individual wiki basis, can we just set it to be true for all private wikis? i.e. Add
'private' => 'true',
to 'wgBlockDisablesLogin' => array(
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55871,-95,Medium,True
-7.2686172901432595,4.91931531488401,9.43867318091683,8.644871468450408,-1.4546657530393952,-0.46353535634981047,-0.7035986435888715,2.302477896145019,-3.376678932636346,-2.158870039709485,1.1414428905075424,-5.9035886533095026,8.163192232778625,4.82666444140985,2.854180610120843,-0.5742847732216481,5.395776745317419,2.330448275250844,False,c3,1,"Bugzilla bugs 71716, 61048, or maybe all of the larger issues unaddressed from https://www.mediawiki.org/wiki/Requests_for_comment/Login_security",1279,-33,Medium,True
-2.4451483350303613,6.728726542280082,-1.305501170983371,-1.796899581311688,2.220671260442547,-0.04423558424959517,1.6503742684891343,1.5133343450396852,1.340170429424475,0.562954664337175,1.41000985287917,1.4366241350452233,0.9553651254621447,-0.35132233342722863,0.8099783605903665,-0.4517804846287248,-0.7022203697564099,0.1797271814934287,False,c3,1,"Wikimedia Phabricator allows users to log in using Wikimedia SUL (MediaWiki OAuth plugin, good for 99,9% of Wikimedia users) and Wikitech/Labs/Gerrit (LDAP login, good for 0.1% of Wikimedia users, and a good backup just in case OAuth is down).
By default, Phabricator will feature a full-fledged LDAP form first, adding the MediaWiki button underneath. This is confusing users, who enter their Wikimedia credentials in the LDAP form. They have no clue what LDAP is, and they simply see the familiar shape of a login form.
This problem would be solved if we find a way to hide that form behind a text link. Such link doesn't even need to be prominent, it can be placed in the text description (preferred) or be just a floating text label. This would give to the MediaWiki button the prominence it requires, even hesitant users would click it due to the lack of apparent choices, and most of the login problems would be gone.
@mmodell, whenever you have time, could you post an initial assessment of the realistic options here, please? I'm happy to submit requests upstream if needed, although I'm not sure what would be upstreameable here. Having LDAP login behind a button is a possibility too, if this would be indeed something that upstream would be happier to integrate.",963,-36,Medium,False
1.2731371118876882,-1.8276870285468263,19.804914567503204,8.457172887531815,8.957262868028947,0.2970959694062427,-4.335727760025156,-1.2728542701988106,-3.659185539867795,3.7106901953325018,3.988351124886942,4.479455078918644,-2.5790027116577594,-2.4177363060292336,3.1046411245387437,0.593851340676055,-1.2657670133350354,-1.0540830667002452,False,c3,1,">>! In T541#8313, @liangent wrote:
> Note that current links appear double percent-encoded so they're broken for user names containing non-""basic"" characters. See https://phabricator.wikimedia.org/p/Fan/ as an example.
The link displayed is https://www.mediawiki.org/w/index.php?title=User%3A%25E8%258C%2583 , which produces a [[ https://www.mediawiki.org/w/index.php?title=User%3A%25E8%258C%2583 | ""Bad title"" page in mediawiki.org ]].
The correct URL would be https://www.mediawiki.org/wiki/User:%E8%8C%83",547,-39,Medium,True
-6.944433708019689,17.26808761582441,4.18151423964591,0.7487144850564509,13.064955669154925,1.2876481895640597,-0.5104092394143169,0.42640012487732115,1.7561777662498643,-2.8465372556144914,-1.1985101887826788,-1.927328514276846,-1.656434448042969,0.9374034127771527,3.47057653330027,0.39544261768400296,-3.13427524723304,-0.8939583498556318,False,c3,1,"The GoogleID connected with the user is a setting, so maybe move it to preferences.",325,-49,Medium,True
4.6907650675003065,-2.2056822646355467,-4.921103537176327,3.8500549261537076,12.399292468225148,2.7674143202148507,3.244333469264455,7.448200367517659,-0.01293049921561823,1.8943750690197065,3.5045967425618687,-7.9233139546607765,1.6263346563041825,-0.8871162487765574,-2.0855667388067674,-0.6766402259731858,1.1599957886890733,-2.871882279172387,False,c3,1,"{F15728}
not the openid logo :)",296,-50,Medium,True
-6.49440923338606,14.478084851933861,5.34236672261353,1.788163983154163,3.5807694426116714,8.111504852217273,2.106042924175255,-0.7925351660336525,-5.116710207237653,-0.628914118337919,0.35213357450495675,5.36143410805801,-0.3624378762515237,-0.2814350014745237,0.31009490428876774,-0.8369355976614368,0.9516627690485919,-0.7909082162088972,False,c3,1,"The login screen has an option now to login with MediaWiki.org credentials. The logo for this is shown as Amazon.com.
This is due to the login options all sharing a CSS icon sprite, but no offset has been provided for MediaWiki, so it defaults to top left corner of the sprite, which is Amazon.com",232,-56,Medium,True
-2.4508950887483834,5.126620678767246,3.5382920019922324,-2.4642543781642816,-0.2169032601119576,-2.7262609687188766,-0.12120143380711212,1.3852835909706078,3.232333163758055,1.3917913642148108,0.2166537909930657,-0.1816103752314423,0.4830681996380619,-0.857901098506872,-1.2218707540485898,-1.5562435951770506,-2.740685716937228,3.475202337265059,False,c3,1,"When creating a Phabricator hosted repository, and trying to serve it over http (even for ""Read only""), Phabricator warns that:
NOTE: The configuration setting diffusion.allow-http-auth is currently disabled. You must enable it to activate authenticated access to repositories over HTTP.
When going ahead nonetheless, and saving the changes, the repository status says:
Missing Binary git-http-backend Unable to find this binary in the webserver's PATH. You may need to configure environment.append-paths.",123,-63,Medium,True
10.142538096295228,-3.658703238508263,5.374187101870891,5.896559884402727,-1.0583162885518167,-3.0012585675204484,-0.12784076466028704,0.5492282565124847,-0.714301510081043,-0.5419036972646802,0.7378778430657102,-1.3632367537930141,-0.32578943867403787,1.0677428959847326,0.25146307339531937,-1.3459109103735512,0.5010834832303106,0.013943704044472094,False,c3,1,"For example with:
https://kn.wikipedia.org/wiki/%E0%B2%9A%E0%B2%BF%E0%B2%A4%E0%B3%8D%E0%B2%B0:End-of-the-world-Stephen-Hawking-god-particle-Higgs-boson-508102.jpg
Calling this URL:
http://upload.wikimedia.org/wikipedia/kn/thumb/0/0e/End-of-the-world-Stephen-Hawking-god-particle-Higgs-boson-508102.jpg/230px-End-of-the-world-Stephen-Hawking-god-particle-Higgs-boson-508102.jpg
Generate a HTTP 500 error with message:
Error generating thumbnail
ಮುನ್ನೋಟ ಚಿತ್ರವನ್ನು ಸೃಷ್ಟಿಸುವಲ್ಲಿ ದೋಷ: convert: Fractional sampling not implemented yet `/tmp/localcopy_1924ad5185f8-1.jpg' @ error/jpeg.c/EmitMessage/242.
convert: missing an image filename `/tmp/transform_b82067d9cc5c-1.jpg' @ error/convert.c/ConvertImageCommand/3011.
Error code: 1
--------------------------
**Version**: unspecified
**Severity**: normal",74511,-36,Low,
-2.0266579690306536,-2.848310783509529,-0.5276316356790414,-0.5861566612803872,4.092597460847296,-0.9664341550766045,-0.6023206912969483,-2.16874858857646,-0.9192669633609201,-1.745921968427539,-0.3734154948648367,0.38409832541545885,1.4614274905097657,-1.3502846120274303,-2.605807720322044,0.7031080442662334,-0.38807293185273917,-0.9536885726626969,False,c3,1,"Trying to click the login button with a fundraising banner in my way
The image speaks by itself.
Yes, if I know there is a register/login button I can move the cursor away and then back, but this doesn't help anything.
P.s.: Yes, the banner as a whole takes more space than is available for the article (T108256). I guess that's a milestone too.
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
**Attached**: {F15045}",74013,-38,Low,False
-4.300329073148523,2.8244084795384445,2.3086815992937986,3.9448873204536996,3.8622961865238943,3.433585719066068,0.22800013885668946,-0.796849668795006,-0.018947996233617703,0.15969084635630626,1.159565455313475,0.1990910154302301,-0.9010841294794538,0.9539539936391037,0.6663332638180846,3.4770423668314643,0.09335369152679229,1.434224567131672,False,c3,1,"The help for action=login says
""Log in and get the authentication tokens. In the event of a successful log-in, a cookie will be attached to your session. ...""
In fact, the first API result contains ONE token, and then if you provide this token and login is successful, you get a sessionid back in the API response, and the HTTP response header sets three cookies:
<cookieprefix>UserID
<cookieprefix>UserName
<cookieprefix>Token, set to the sessionid in the API result
these all expire in a month, none is a session cookie.
A better description for includes/api/ApiLogin.php might be
Log in and get sessionid and browser cookies.
A successful login returns a session ID and its HTTP response header sets wiki cookies identifying the user.
...
Even this might vary with wiki configuration.
--------------------------
**Version**: unspecified
**Severity**: trivial",73638,-39,Low,True
-0.8437816434603773,3.107203690024445,0.6232005635914852,-2.055490153545296,-2.402705130064963,-3.236021070290704,-1.5440404011202578,-3.8683962365528246,-0.7790830418868296,1.3211107675209695,-0.391001351198597,1.9980810143327108,-0.246651815762168,-1.0501937341847505,-0.502247496202374,1.1340220256264293,-0.24550961217538103,-0.6145264714668788,False,c3,1,"Many tests follow ""I am logged in"" with ""visit FlowPage"", ""I navigate to Upload Wizard"", ""I visit the User page of Selenium_user2"", etc. In these cases Special:UserLogin's default behavior of loading the Main_Page upon successful login is a waste of precious time.
MediaWiki has already solved this for human beings. Clients can pass ?returnto=Some_wiki_page to Special:UserLogin so that upon successful login the user is redirected to Some_wiki_page. It's what the _Log in_ link on every wiki page does, as you can see if you hover over it and note its URL.
For example, http://en.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin?returnto=Talk:Flow_QA
We could expose this as
Given I am logged in to <PAGE>
in tests. mediawiki_selenium/step_definitions/login_steps.rb would need to recognize the presence of this optional parameter and append ?returnto=URLEncode(pageName) to LoginPage
I would prototype this but I don't know where the visit() function is defined or documented in our webdriver-selenium-watir-cheezy-cucumber stack.
Is using
on(APIPage).client.log_in(ENV[""MEDIAWIKI_USER""], ENV[""MEDIAWIKI_PASSWORD""])
another alternative?
--------------------------
**Version**: unspecified
**Severity**: enhancement",73635,-39,Low,False
5.208116256895922,-8.99388727383301,-3.9644416580246133,6.396974980826493,-2.9309225009458366,-3.4283051560593263,-5.913995887852728,-1.1108607495171567,-2.221341983231633,-5.681477333397342,3.248779538461513,-1.0745142670868308,0.6126582568974861,3.7669978765192216,2.8322917330494173,-1.6141017783005662,-0.06069164594933185,1.3344671277639202,False,c3,1,"Seeing a flood of these errors in fluorine:/a/mw-log/apache2.log:
Sep 30 22:24:17 mw1018: [proxy_fcgi:error] [pid 12557] [client 10.64.0.103:5054] AH01070: Error parsing script headers, referer: https://es.wikipedia.org/wiki/Estadio_Coloso_del_Ruca_Quimey
Sep 30 22:24:16 mw1019: [proxy_fcgi:error] [pid 30172] [client 10.64.0.105:52919] AH01068: Got bogus version 1, referer: https://commons.wikimedia.org/wiki/File:Bibliotheque_de_Toulouse_-_Pic_d-Aneto_(pd).jpg
Sep 30 22:24:16 mw1019: [proxy_fcgi:error] [pid 30172] (22)Invalid argument: [client 10.64.0.105:52919] AH01075: Error dispatching request to :, referer: https://commons.wikimedia.org/wiki/File:Bibliotheque_de_Toulouse_-_Pic_d-Aneto_(pd).jpg
--------------------------
**Version**: wmf-deployment
**Severity**: normal",73487,-40,Low,False
-5.405717066711739,1.6488859655999093,0.5836044454507565,-0.7498179758993715,2.302025960420061,-0.3563761460320981,2.096265453951937,-0.45085450381016334,2.0814587569615854,1.2801102676798308,2.564379529954994,-0.7164201240869306,1.415530454178651,0.1493918459182444,-2.207492746291893,-0.8202462434915434,-0.13977144325146384,-0.5003493161534636,False,c3,1,"When attempting to test mediawiki oauth against a test instance of mediawiki vagrant, something is stripping the auth headers from the https request. I think it's related to the nginx reverse proxy but I couldn't find anything wrong with the nginx config or anything else that looked like an obvious problem.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=73510",72964,-42,Low,
2.909534659483455,-1.859687593161036,-8.335112934323694,6.329584227486696,1.6853316121683992,-1.4025754421900851,-2.000975006572964,0.5886137749528195,0.5199824882836124,-2.3963478559313236,-1.2237622214595392,0.978468682616161,1.4609501721370117,-1.6382948844941958,-2.0703121078947575,-0.08012367905898227,-0.10239712805890533,-0.5655876718907809,False,c3,1,"**Author:** `metatron`
**Description:**
When loading a gagdget or custom script from eg. meta/mediawiki/enwiki with
-mw.loader.load('//meta.wikimedia.org/w/index.php?title=...&action=raw&ctype=...')
the responded cache-control directive is
- private, s-maxage=0, max-age=0, must-revalidate
which prevents these scripts from being cached properly and causes a lag (40-500ms) on each call.
(IMHO JS pages should have a reasonable default > 0)
Example with requested cache:
```
Remote Address:xx.xx.xx.xx:443
Request URL:https://meta.wikimedia.org/w/index.php?title=User:Hedonil/Test/XTools.js&action=raw&ctype=text/javascript&maxage=86400&smaxage=86400
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en,no;q=0.8,nb;q=0.6,vi;q=0.4,nl;q=0.2,zh;q=0.2,ru;q=0.2,en-US;q=0.2,zh-CN;q=0.2,zh-TW;q=0.2
Connection:keep-alive
metawikiUserID=..centralauth_User..
Host:meta.wikimedia.org
If-Modified-Since:Wed, 13 Aug 2014 04:18:39 GMT
Referer:https://en.wikipedia.org/wiki/Charles_Schild
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
title:User:Hedonil/Test/XTools.js
action:raw
ctype:text/javascript
maxage:86400
smaxage:86400
Response Headersview source
Accept-Ranges:bytes
Age:0
Cache-Control:private, s-maxage=0, max-age=0, must-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/javascript; charset=UTF-8
Date:Wed, 13 Aug 2014 07:55:42 GMT
Last-modified:Wed, 13 Aug 2014 04:18:39 GMT
Server:nginx/1.1.19
Vary:Accept-Encoding
Via:1.1 varnish, 1.1 varnish, 1.1 varnish
X-Cache:cp1065 miss (0), amssq50 miss (0), amssq31 frontend miss (0)
X-Content-Type-Options:nosniff
X-Varnish:948365503, 2378009697, 4022640906
ConsoleSearchEmulationRendering
```
Example without requested directive:
```
Remote Address:xx.xx.xx.xx:443
Request URL:https://en.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-HotCat.js%2Flocal_defaults&action=raw&ctype=text/javascript
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en,no;q=0.8,nb;q=0.6,vi;q=0.4,nl;q=0.2,zh;q=0.2,ru;q=0.2,en-US;q=0.2,zh-CN;q=0.2,zh-TW;q=0.2
Connection:keep-alive
Cookie:enwikiSession=..centralauth_User=...
Host:en.wikipedia.org
If-Modified-Since:Mon, 23 Jun 2014 19:15:43 GMT
Referer:https://en.wikipedia.org/wiki/Charles_Schild
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
title:MediaWiki:Gadget-HotCat.js/local_defaults
action:raw
ctype:text/javascript
Response Headersview source
Accept-Ranges:bytes
Age:0
Cache-Control:private, s-maxage=0, max-age=0, must-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/javascript; charset=UTF-8
Date:Wed, 13 Aug 2014 07:55:42 GMT
Last-modified:Mon, 23 Jun 2014 19:15:43 GMT
Server:nginx/1.1.19
Vary:Accept-Encoding
Via:1.1 varnish, 1.1 varnish, 1.1 varnish
X-Cache:cp1053 miss (0), amssq55 miss (0), amssq54 frontend miss (0)
X-Content-Type-Options:nosniff
X-Varnish:2605122819, 917135542, 2533692991
```",71460,-47,Low,False
3.3959843334945483,1.6131711178898467,3.043857857866996,-5.677982297960009,2.240251585296307,2.5166863717625763,1.3177352155933724,-4.1917023274640535,-2.5243159564001756,-1.7024703780151311,-1.2101801131206393,2.7680266526194046,-1.0799488666974488,0.20056378705250655,-1.5441324838418602,-2.0436327956025635,1.75108430370099,2.186567563378712,False,c3,1,"I am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails.
--------------------------
**Version**: unspecified
**Severity**: normal",71289,-47,Low,False
-1.3915869493779716,-2.120317279871413,-2.1869186554601914,2.6493478958355756,-0.05471364266930301,-2.0639270694984573,2.29151197658956,3.993336026889857,-0.13070418742976755,-1.3217944248125888,-1.6828686171218838,-0.790894134087474,-0.3843984343826552,-1.113612307631933,-0.8890744010232732,0.6068273537131746,1.3747879947357207,0.25034394987258346,False,c3,1,"social sharing links above comments/categories/tags and below post body on the page for an individual post should all use HTTPS (or at least protorel)
now only google+ is HTTPS
https://blog.wikimedia.org/2014/07/31/introducing-the-new-blog/ says:
> <div class=""socials"">
> <span class=""label"">Share</span>
> <a href=""http://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fblog.wikimedia.org%2F2014%2F07%2F31%2Fintroducing-the-new-blog%2F"" class=""fb"" target=""_blank"">facebook</a>
> <a href=""https://plus.google.com/share?url=https%3A%2F%2Fblog.wikimedia.org%2F2014%2F07%2F31%2Fintroducing-the-new-blog%2F"" class=""gp"" target=""_blank"">google plus</a>
> <a href=""http://twitter.com/intent/tweet?text=Introducing+the+new+blog%3A+a+place+for+movement%26nbsp%3Bnews+-+https%3A%2F%2Fblog.wikimedia.org%2F2014%2F07%2F31%2Fintroducing-the-new-blog%2F"" class=""tw"" target=""_blank"">twitter</a>
> </div>
Also, the more generic links (upper right corner of the page; that don't vary from post to post and they appear on the root path too) all should be made HTTPS as well. (none are now, not even google+)
Twitter on individual blog comments should be removed or made HTTPS.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",70983,-48,Low,True
20.063652925945412,-4.177250289916756,-14.007470399069156,4.036054718691525,-0.695077819963883,-2.695481079164774,-4.0576718727299825,-0.39742766552912645,-2.459322292335038,-4.908597058011336,-0.8783305743464851,-1.076773031967712,9.896519107972182,6.096712163094557,3.212477249778277,-0.37196919260505745,-0.038973348423508414,0.08211232368668964,False,c3,1,"Notice: Undefined index: HTTP_USER_AGENT in /srv/vagrant/mediawiki/extensions/SecureSessions/SecureSessions.hooks.php on line 205
Call Stack:
0.0007 253272 1. {main}() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:0
21.8136 50828840 2. MediaWikiPHPUnitCommand::main() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:160
21.8136 50841328 3. PHPUnit_TextUI_Command->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiPHPUnitCommand.php:42
105.9377 272526968 4. PHPUnit_TextUI_TestRunner->doRun() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:176
105.9637 272844320 5. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php:350
106.4795 272846576 6. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
2089.9649 470147104 7. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
2097.2738 471151880 8. PHPUnit_Framework_TestSuite->runTest() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:749
2097.2738 471151880 9. MediaWikiTestCase->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:779
2097.2825 471151544 10. PHPUnit_Framework_TestCase->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiTestCase.php:133
2097.2826 471151544 11. PHPUnit_Framework_TestResult->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:783
2097.2828 471152496 12. PHPUnit_Framework_TestCase->runBare() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestResult.php:648
2097.2828 471169216 13. ApiParseTest->setUp() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:835
2100.8517 471540208 14. ApiTestCase->doLogin() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiParseTest.php:14
2100.8704 471658024 15. ApiTestCase->doApiRequest() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiTestCase.php:168
2100.8712 471761776 16. ApiMain->execute() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiTestCase.php:99
2100.8712 471761840 17. ApiMain->executeAction() /srv/vagrant/mediawiki/includes/api/ApiMain.php:332
2100.8821 471767936 18. ApiLogin->execute() /srv/vagrant/mediawiki/includes/api/ApiMain.php:907
2100.8891 471776752 19. User->setCookies() /srv/vagrant/mediawiki/includes/api/ApiLogin.php:87
2100.8891 471778352 20. wfRunHooks() /srv/vagrant/mediawiki/includes/User.php:3349
2100.8891 471778400 21. Hooks::run() /srv/vagrant/mediawiki/includes/GlobalFunctions.php:4031
2100.8891 471780392 22. call_user_func_array() /srv/vagrant/mediawiki/includes/Hooks.php:207
2100.8891 471780912 23. SecureSessions->onUserSetCookies() /srv/vagrant/mediawiki/includes/Hooks.php:207
--------------------------
**Version**: master
**Severity**: normal",70739,-49,Low,False
20.296176923529764,-4.353366555287904,-15.058613471247941,3.0846660872222076,-0.6287409499218702,-1.949085116854579,-4.097451997955284,-0.23084375080096667,-1.8391407396219965,-4.705885492880759,-1.105037924109526,-1.187290414185114,9.295697311887285,5.156025736217,2.6024503536100907,-0.2828746144898904,-0.046137640717822004,0.0661334357476504,False,c3,1,"Master and defaults.
Fatal error: Call to undefined method GoogleLoginAuth::connect() in /srv/vagrant/mediawiki/extensions/OpenStackManager/nova/OpenStackNovaLdapConnection.php on line 21
Call Stack:
0.0006 253272 1. {main}() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:0
19.6050 51193712 2. MediaWikiPHPUnitCommand::main() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:160
19.6050 51206200 3. PHPUnit_TextUI_Command->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiPHPUnitCommand.php:42
127.4282 273527048 4. PHPUnit_TextUI_TestRunner->doRun() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:176
127.4901 273844016 5. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php:350
128.2664 273846256 6. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
1755.9192 482218944 7. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
1756.7843 484017912 8. PHPUnit_Framework_TestSuite->runTest() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:749
1756.7843 484017912 9. MediaWikiTestCase->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:779
1756.7912 484018080 10. PHPUnit_Framework_TestCase->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiTestCase.php:133
1756.7913 484018080 11. PHPUnit_Framework_TestResult->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:783
1756.7915 484019024 12. PHPUnit_Framework_TestCase->runBare() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestResult.php:648
1756.9257 484499320 13. PHPUnit_Framework_TestCase->runTest() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:838
1756.9258 484500112 14. ReflectionMethod->invokeArgs() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:988
1756.9258 484500448 15. ApiOptionsTest->testReset() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:988
1756.9259 484505640 16. ApiOptionsTest->executeQuery() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiOptionsTest.php:233
1756.9260 484505904 17. ApiOptions->execute() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiOptionsTest.php:151
1756.9545 484513320 18. Preferences::getPreferences() /srv/vagrant/mediawiki/includes/api/ApiOptions.php:75
1760.1648 485029280 19. wfRunHooks() /srv/vagrant/mediawiki/includes/Preferences.php:99
1760.1648 485029344 20. Hooks::run() /srv/vagrant/mediawiki/includes/GlobalFunctions.php:4031
1765.5002 486711944 21. call_user_func_array() /srv/vagrant/mediawiki/includes/Hooks.php:207
1765.5002 486712528 22. OpenStackNovaUser::novaUserPreferences() /srv/vagrant/mediawiki/includes/Hooks.php:207
1765.5102 486714152 23. OpenStackNovaUser->__construct() /srv/vagrant/mediawiki/extensions/OpenStackManager/nova/OpenStackNovaUser.php:698
1765.5188 486718968 24. OpenStackNovaLdapConnection::connect() /srv/vagrant/mediawiki/extensions/OpenStackManager/nova/OpenStackNovaUser.php:21
--------------------------
**Version**: master
**Severity**: normal",70718,-49,Low,False
-1.6070831454336092,6.035379410829755,1.6306991513635616,-7.048450118345921,-0.6615284945543812,-3.073281322727069,2.7313901240286294,5.142860670209377,1.427318594540097,-1.6013339371065798,-1.546633745130362,-8.0818793812078,-1.876817466231162,1.0896424103739513,-0.18558813280913267,-0.9985561705304742,-1.5055048833000164,-0.007643131486252841,False,c3,1,"https://en.wikipedia.beta.wmflabs.org/ no longer responds at all.
While we have never had a valid cert for beta, we did in the past answer HTTPS URLS, forcing the user to proceed manually over a security warning. As of sometime fairly recently, we no longer listen on HTTPS at all.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48501
https://bugzilla.wikimedia.org/show_bug.cgi?id=63538",70387,-50,Low,False
3.1158456105133294,1.0231053101188774,-5.399229818683512,-10.55677692531529,-5.338692114046452,-1.8350373949094119,1.0112057273643051,3.2228048041151474,4.106724268000845,-0.7785620242759137,-3.1983042343900134,0.05938616142116615,-2.9197196035677146,3.7397833954210586,-2.0914510488116687,-3.2946275595095598,1.3660770834524072,0.5688607589767651,False,c3,1,"Now that we don't have to deal with Cloudbees, investigate using HTTP::Persistent again to help performance.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",70115,-51,Low,True
6.349210754299628,-3.0801444086248875,-9.035033568871754,4.019687060150125,-1.188861831598183,-1.2987856569279628,-4.790383417308063,0.43064410698200273,-2.980543529317055,-4.288626250969019,3.1381426421058944,-2.7642331772053206,8.620906970936202,5.655656470413035,5.280058072748271,-1.3024118741858786,0.3515785234509865,0.6972535568734182,False,c3,1,"I think this is a race condition of some kind:
2014-07-14 23:44:02 mw1209 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username])
2014-07-14 23:44:02 mw1049 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username])
2014-07-14 23:44:02 mw1049 loginwiki: CentralAuthHooks::attemptAddUser: failed with message Username entered already in use.
Please choose a different name.
For some reason, there were two simultaneous autocreation attempts, one succeeded, and the other of course failed. Here's a scarier one:
2014-07-14 23:44:53 mw1150 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username2])
2014-07-14 23:44:53 mw1062 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username2])
2014-07-14 23:44:53 mw1174 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username2])
2014-07-14 23:44:53 mw1019 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username2])
2014-07-14 23:44:53 mw1187 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username2])
2014-07-14 23:44:53 mw1174 loginwiki: CentralAuthHooks::attemptAddUser: failed with message Username entered already in use.
Please choose a different name.
2014-07-14 23:44:53 mw1062 loginwiki: CentralAuthHooks::attemptAddUser: failed with message Username entered already in use.
Please choose a different name.
2014-07-14 23:44:53 mw1187 loginwiki: CentralAuthHooks::attemptAddUser: failed with message Username entered already in use.
Please choose a different name.
2014-07-14 23:44:53 mw1019 loginwiki: CentralAuthHooks::attemptAddUser: failed with message Username entered already in use.
Please choose a different name.
2014-07-14 23:44:53 mw1038 loginwiki: CentralAuthHooks::attemptAddUser: creating new user ([username2])
2014-07-14 23:44:53 mw1038 loginwiki: CentralAuthHooks::attemptAddUser: failed with message Username entered already in use.
Please choose a different name.
This one has 6! attempts, 5 of which fail.
--------------------------
**Version**: unspecified
**Severity**: normal",70012,-51,Low,False
2.439927306382651,-0.08021635775140545,2.5246572119430404,-5.057354458996707,-2.7358742328077064,-1.0157776635857252,-0.3832926048757228,-0.8005309853960785,0.09540962933210606,1.292216883735069,-1.9263156212531156,0.5464861528737475,-0.1026223684041856,0.9462103074621648,-0.9443026850062548,0.02823878259789886,1.2906651098082895,0.9231172791220945,True,c3,1,"Request from https://bugzilla.wikimedia.org/show_bug.cgi?id=66699#c34 (by Martin von Gagern):
> Is asking for year-long concurrent sessions on multiple devices on-topic here, is there a separate bug for this, should I file one or ask on Village Pump?
The idea is to allow multiple simultaneous ""remember me"" sessions.
I'm not sure if this applies to core, CentralAuth, or both, but putting in core for now.
--------------------------
**Version**: 1.24rc
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66699",69512,-52,Low,False
-4.488174862127298,0.1628598132791801,-2.3878779378031343,3.6144220480426252,0.09900715901004442,-0.9991089278538738,1.9797572808705581,3.2290913428984944,1.5694230598451757,0.0531858547735542,0.5841963814503424,1.680722676038603,1.1763921974353555,-1.7209302103337794,-0.7340117470785934,0.8011396372826063,2.1655285821015138,-0.5697849167661626,False,c3,1,"memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.
Until the issue surfaces again, we will not be able to analyze this further.
flourine $ grep memcache /a/mw-log/zero.log
Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.
--------------------------
**Version**: unspecified
**Severity**: normal",67867,-58,Low,False
-0.3066147404661539,-0.6189231788870391,-7.599627906061947,-0.06637307089197142,-1.3297274270822779,1.538860772100165,-3.1510845534839875,2.1129098306092167,-1.2523605582951913,-2.6676504760228887,-1.7312688911015055,1.9215379620894482,0.797065769193309,-2.567405727201138,-1.2829818943145952,-0.4905811372570179,-1.6799755654220194,0.02324315364635754,False,c3,1,"Because by replacing this to empty, ""//"" in URLs gets stripped, causing any URLs that get processed by the whitelist to fail matching against the blacklist.
Repro: xlx.to is blacklisted in [[m:Spam blacklist]] using \bxlx\.to\b, thus http://foobar.xlx.to/ is expected to be blocked. However on enwiki there's whitelist entry saying \bonion\.com\b, so http://onion.com.xlx.to/ (which is a xlx.to subdomain) can pass the filter on enwiki.
--------------------------
**Version**: unspecified
**Severity**: normal",67848,-58,Low,
1.702178438229574,-2.1023889183975513,4.638640097072582,3.2201689068655623,1.5448578681066398,-3.517650096635065,1.680100657158472,-5.928166683829718,0.7853533229355585,-1.7702112004779798,-0.8966183112799073,-0.19292197843178194,-0.11357941250621018,-1.1211668167424027,0.7687858973203827,0.18240827193383893,0.8794367212293077,0.5269021700698302,False,c3,1,"**Author:** `ryancarr10`
**Description:**
I will get a lot errors due to either the skin or the wiki iteself. I am not sure which one it is coming from.
Link for log
http://pastie.org/private/h7qw8lu8bmwm1fksukopzw
--------------------------
**Version**: 1.22.5
**Severity**: normal
**OS**: Linux
**Whiteboard**: aklapper-moreinfo",66220,-63,Low,True
0.5957513138870509,1.9792326928947404,0.6055050887590454,-5.112490865562,-4.615804308825355,3.25061707093114,-0.9012965491159708,0.682166210511752,0.8672642390106056,-0.6202842459196383,1.2867011280705616,2.4591469098055976,0.6469861256879015,0.8427147894480713,1.2329561595783165,-3.0324119824600118,-0.8761931174654842,-1.9755744127496067,False,c3,1,"A user reported that https access to wikipedia.org has been available for China since November 2013. Let's run some tests to see if this is true for most users.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T55739}",66207,-63,Low,True
1.2234321219173565,0.657708036708236,2.7352397191534266,-2.987857885369661,-0.4336739796070387,1.5390968172160122,-0.07560546657325151,-0.20654508466297192,4.673190879639555,-0.4446495960801,0.13390600754336734,-1.4268175415751043,-0.2092944461305386,-0.8019602196968982,0.8270203797179505,0.7321586666059067,-0.05223107944836314,-1.3002082926393879,False,c3,1,"We should support MediaWiki APIs with self-signed SSL certs. We can do so by converting the current optional proxy parameter in setInterwiki into an options object which can contain the cert-related options. Those can then be used in ApiRequest if set.
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70761",66003,-64,Low,False
-0.23411094320074533,-0.9297170353914161,5.651574483926261,1.8319811943400808,-5.609209525295904,0.5156786852263899,0.46785273031576313,0.8737866376451052,-0.6319960049256097,-3.070465399506225,-4.16084583378709,-0.661070673308465,-1.2526878483642667,0.8292592635903695,1.2901623051053726,1.5867459691399983,0.8600406170255293,-1.1037036926562802,False,c3,1,"With preferhttps option enabled by logged in users
http://de.wikipedia.org/wiki/Spezial:Weblinksuche/http://wikimedia.org
gets redirected to
https://de.wikipedia.org/wiki/Spezial:Weblinksuche/https://wikimedia.org
instead of
https://de.wikipedia.org/wiki/Spezial:Weblinksuche/http://wikimedia.org
The protocol part of the search url argument must not be rewritten.
--------------------------
**Version**: 1.23.0
**Severity**: normal
**URL**: http://de.wikipedia.org/wiki/Spezial:Weblinksuche/http://wikimedia.org",65573,-65,Low,True
-4.625848761299865,-1.069264299382878,-3.693833934291133,-3.561214762533595,3.5962889338205453,0.728108249476241,-0.44591016582458387,0.027195562837306952,1.2221398411931792,-1.2412753090146347,0.39271132689990695,0.0574933067272716,1.433600038042195,-1.8669819791620381,-0.7263474173845825,0.13459607916756794,0.2985289112590954,-1.2939520789722543,False,c3,1,"**Author:** `jweberhofer`
**Description:**
To log in, I have to use my full name instead of the username; that's a bit confusing, as the dialog is asking for the Username.
It would also be great to find a link to reset the password. After searching, I found https://wikitech.wikimedia.org/wiki/Special:PasswordReset which is possibly the right way; but again - the username can not be found; I have not tried with the full-name.
--------------------------
**Version**: unspecified
**Severity**: normal",64317,-69,Low,False
11.165662951103196,-3.776229325772926,-0.645570423393961,-4.61430721350088,4.1247633098186025,-0.6858602432380392,-0.5819039086074689,-2.3740699294985697,-0.14223308080522787,-1.2332394144640229,-1.0723795232370714,0.6432754203569213,0.8982400070178169,-0.4281825657317402,-0.06741848953208862,0.6830742648791672,0.2224203822788613,0.3172711492761293,False,c3,1,"**Author:** `popeno2003`
**Description:**
Hi I just randomly get to enter this address:
https://www.fa.wikipedia.org/
and I get ""This Connection is Untrusted"" alert.
I have tried the same with English Wikipedia and get the same result.
so I think it is a problem with all
https://www.[ln-code].wiki[pedia|source|...].org
connections.
Is it intentional or just a bug?
Browsers tested with:
- Firefox 27.0.1 Linux Ubuntu 12.4
- Chromium 32.0.1700.107 Linux Ubuntu 12.04
Best Regards
Pouyan
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64977",64181,-70,Low,True
-3.485925752946593,7.197844141813306,-0.613203043407955,-1.4622418871842195,-0.23723138371055663,0.6891784510016075,3.2995993867648545,-1.413139448121337,-2.332429893117273,-1.0693186143296503,0.14698956039950595,-6.102215544243702,-0.24632797906373938,2.1078151941117946,0.1410222907078218,1.2922664717415477,-2.368482665097212,-0.42564824605289364,False,c3,1,"As of late, when logging in to Jenkins I get a 503 error from Varnish in return (the green wmerror page, much like our php/wmerror one).
https://integration.wikimedia.org/ci/login?from=%2Fci%2F
It only does that for a successful login though, with a wrong password it just shows the login form again with the relevant error message.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",63710,-71,Low,False
-4.85834337683648,-0.5411876951628471,-0.8169014262970062,0.5832587322730705,-6.994984874480316,5.0852482177716105,1.0841055516979745,1.9694581613929856,0.11430367509175648,5.670803477263579,2.286617190288706,-1.1147725937691406,1.596983505387377,-0.3724940068845344,-1.6335875817489378,-1.4003342459899109,-1.5231020005980376,0.7768654111758762,False,c3,1,"Trying to log in with the PhpHttpRequest class rather than curl causes the error ""ssl certificate problem: unable to get local issuer certificate"".
--------------------------
**Version**: unspecified
**Severity**: normal",63093,-73,Low,False
0.25066323843875216,-4.829795419100071,-0.5684934712473098,2.6971674442731435,-3.074099566337177,-0.7669935883838315,-0.1974677887775993,-1.5086236758840057,3.064836967935486,0.09097741700821782,-0.6884760254058051,1.415834396087824,0.14079807302895286,-1.124119250643461,-0.45508315900896257,0.6427933987803363,-1.057159632780845,-0.9230857584776904,False,c3,1,"**Author:** `jonesey95`
**Description:**
This is a grammar fix.
In many locations in this extension, the noun ""login"" is used as a verb. It needs to be changed to the verb phrase ""log in"". Examples:
MediaWiki:mobile-frontend-donate-image-login-action (Login to share your media.)
MediaWiki:mobile-frontend-edit-login-action (Login to edit.)
MediaWiki:mobile-frontend-generic-login-action (Login to contribute.)
MediaWiki:mobile-frontend-photo-upload-anon (Please login to add an image to this page.)
MediaWiki:mobile-frontend-user-cta (Please login or sign up to see your notifications.)
MediaWiki:mobile-frontend-watchlist-cta-button-login (Login)
MediaWiki:mobile-frontend-watchlist-login-action (Login to see it.)
Discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Mobile_interface_contains_bad_English
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=6138",62426,-75,Low,True
-6.736191005081716,6.331337871860619,-3.881545184535673,-3.6697889973148627,-5.074389547939578,-3.260510129169826,1.0701053945681922,0.4115346207220443,5.174461287201991,-0.2550405336818278,-1.7302051838492551,0.7529260083217892,-1.6978522344107585,3.6441611865080716,0.10608041650197197,-1.4242349956611104,-0.22254457885688228,-1.3407365889397131,False,c3,1,"Currently, its not possible to push to gerrit using https method.
Since people with internet on which port 29418 is blocked can't access it through ssh, it makes a hard time to contribute, so it would better to have an alternative.
Also git review doesn't work with https.
--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",61865,-77,Low,True
-4.360632998183298,-1.9742940759814083,-2.7510434618762716,3.0379614447418914,1.6474959312870112,0.15157134577067866,-3.7692080156440797,1.5284008096590505,-3.1969926679471135,-1.395585436491113,-2.9497318125311,0.7372684809188552,-0.04320630468160758,-0.25799904872641655,0.07885938489050126,-0.26202608062566823,-1.131197903956759,0.1711297756111707,False,c3,1,"The ""this page has been deleted"" message should be served as HTTP 404 (note: not HTTP 410, as in WONTFIXed bug {T14345}, which implies that the resource will never come back - that is not necessarily true for deleted pages).
Related: the 2014 discussion [[https://en.wikipedia.org/w/index.php?title=Wikipedia:Biographies_of_living_persons/Noticeboard&oldid=589460695#Does_the_statement_.22A_page_with_this_title_has_previously_been_deleted.22_create_a_BLP_problem.3F|Wikipedia:Biographies of living persons/Noticeboard#Does the statement ""A page with this title has previously been deleted"" create a BLP problem?]], regarding potential consequences of the ""this page has been deleted"" message appearing in search results for living persons.
--------------------------
**Version**: 1.23.0
**Severity**: minor",61733,-78,Low,
15.068066078188433,-1.6342406734683887,-5.327647318750284,-7.201328178945908,-2.160730504736353,1.577806809867268,0.8123224371387874,5.69203091375234,-1.0343085967330747,-0.5440619382454592,-0.6522335882667925,0.4026502818198612,1.0864827809592335,-1.4518433171579748,-1.8017014161344496,-0.1145014894460219,-0.5204980942962453,-1.7739086649343858,False,c3,1,"https://login.wikimedia.org/wiki/Special:Version
https://vote.wikimedia.org/wiki/Special:Version
Lots of installed extensions on loginwiki/votewiki... not sure most are needed.
--------------------------
**See Also**: {T61701}",61702,-78,Low,
-9.033925965609575,7.494274918545571,3.2297459694249433,3.4627265746117954,2.25904958936775,4.601334282582405,-1.222488846646404,-2.7560720921804918,1.2664279308646653,-3.9035490278975007,-3.547228087839426,-0.7695095994475368,-2.0021157752201706,-1.2185086574335533,2.753558591207118,-0.5901872621689672,1.0761564809660358,-2.483335181040115,False,c3,1,"At some point a regression was introduced in the login path. The app used to redirect the user to the URL they initial specified before they were redirected to the login screen. The user seems to always be redirected to the default page now.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",60558,-81,Low,True
-0.8841596331999981,-2.238732008686304,1.8382108296675987,5.667242812655673,-0.5837482980433756,1.6795847909537815,3.7844525571150163,0.8787752160961441,0.32601580220544,1.013280149173097,0.7478195479474214,1.9583078890659806,0.002588306956416986,-0.927735616761622,0.5350421886219214,-0.7495801544521705,0.39515623800344746,-0.11167797174069904,False,c3,1,"For old svn commits giblit provides a link to mediawiki.org/wiki/Special:Code, but that link is always http, please provide a https link.
If possible, this link should be clickable.
Thanks.
Example on:
https://git.wikimedia.org/commit/mediawiki%2Fcore/96906d6cd38ba7c1c5af81e05a30105e6a29414f
--------------------------
**Version**: wmf-deployment
**Severity**: trivial",58953,-86,Low,False
0.8247908933633421,-4.399871334384255,4.792314505571316,6.086278276738216,-6.205472560221352,-1.5905170578972694,2.642421202708543,-0.18298106703247524,-0.47443935181600677,0.3199101919546523,0.6180327066249216,-0.8976733869820482,1.5471679602066275,-1.1174209931362302,-1.228858311178242,1.1515489727667076,-0.7691123031282611,-1.1118621406169937,False,c3,1,"Login captcha (in Polish)
Login captcha shown after too many incorrect attempts to log in looks ugly, compared to the nicely styles create account form captcha.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**Whiteboard**: gci2013
**URL**: https://en.wikipedia.org/wiki/Special:UserLogin
**Attached**: {F12184}",58370,-88,Low,True
-2.777394317222268,-0.9693276936678146,-1.3451321175297437,-4.8079417806312605,-0.11428422145762962,-2.0499784736754085,0.7774487274266617,-3.55331385406913,-0.4640691319724209,-1.116495372334311,-0.057095928431290854,-0.7002182750655455,-0.14489110278005324,-1.0817609262404604,-0.5592735265186572,0.5157725462729859,-0.057635919663343804,-1.1678897085505728,False,c3,1,"**Author:** `swalling`
**Description:**
Desktop screenshot
On the desktop sight, if I visit Special:UserLogin (such as through a link in a help page), but I'm already logged in, I now get a helpful message telling me that I am already authenticated. [See screenshot attached]
On mobile, I am given the normal login form, and no indication that I don't need to log in again. It would be nice if you just displayed the same warning message that gets displayed on desktop.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**Attached**: {F12150}",58359,-88,Low,True
-2.1726972529508535,-2.187761407894193,3.770828914730572,-7.8748233850623635,5.048168052571601,-5.331016172527391,0.890413974308153,1.5800636703473603,1.545151729814349,3.143018811857176,-0.41749807865367794,-0.8907222038313782,-0.9838582045887305,-1.2670687873658304,3.1674713329400292,1.8504121632715305,0.5910627908229753,0.7970467073614051,False,c3,1,"There is URL in 'Source' column here http://toolserver.org/~erfgoed/api/api.php?action=search&format=html&srcountry=ua&srlang=uk&srid=61-212-0002&props=image|name|address|municipality|lat|lon|id|country|source|monument_article|registrant_url , but there is no A tags there, and I cannot go directly by link. I should copypaste it. It will be more useful if add A tags there.
--------------------------
**Version**: unspecified
**Severity**: normal",57657,-90,Low,True
7.525026412986234,-10.567996697169225,2.7401601508639857,-3.3810738767750976,-5.351822819723662,5.996085052234484,3.0134636830644554,-0.9276232968220158,-0.519434619159356,0.8839385602108223,0.1464673581437017,-1.5322935839999308,-0.6902090804728331,-0.1377003515481645,-0.4055333893897286,-0.8638119038715233,0.5768483718141784,-0.25426230424157037,False,c3,1,"From Jared
--------------------------
**Version**: unspecified
**Severity**: normal",57575,-90,Low,True
-3.1796470768868885,5.088272220338428,1.7845637545917867,7.892074884680682,-0.43954027066681,-0.5968080563563447,1.4923139205145457,1.113038065949525,-1.2412804627814853,0.557317579303632,-0.02989941977792565,-0.24074020954272257,1.9122813698301546,1.0986837057574084,0.29870811768736427,0.13740493507771268,-0.8081091818509373,-0.4729994822188861,False,c3,1,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1475/
Reported by: jaclayiii
Created on: 2012-06-26 04:52:22
Subject: *-login.data can have case discrepency on Linux host
Original description:
Pywikipedia \[http\] trunk/pywikipedia \(r10401, 2012/06/21, 06:18:43\)
Python 2.7.2+ \(default, Oct 4 2011, 20:06:09\)
\[GCC 4.6.1\]
config-settings:
use\_api = True
use\_api\_login = True
unicode test: ok
Summary: the \*-login.data file maybe saved with an uppercase username but when load cookies tries to find it on a Linux host, the case of the username maybe lower. This has the unintended consequence of not allowing bots to login on private wikis that have anonymous read api rights disabled.
If a user connects to a wiki that has LDAP or some other form of ""add-on"" authentication, the user name returned may vary in case from what is in the user-config.py file. The reason this matters is that the <wikifamily>-<language>-<username>-login.data file may be saved with an upper case letter in the username. Thus if the user-config.py file contained:
users\[""mywiki""\]\[""en""\]=""james""
but the LDAP authenticator returned back ""James"" as the username, then the \*-login.data file would be mywiki-en-James-login.data, but when \_loadcookies goes to look for such a file on line 5572:
if os.path.exists\(localPA\)
localPA is /~some/path/to/mywiki-en-james-login.data
Notice that the James is now lower case in the file above.
As Linux is case sensitive, it cannot find the login data and thus prevents access to wikis the do not allow anonymous access to api's. A temporary work around requires setting user name to the appropriate case \(even if the username is case insensitive in the LDAP authentication scheme\), for example:
users\[""mywiki""\]\[""en""\]=""James""
keywords: SSL, Login failure, https login failure, https linux login, https pywikipedia, https pywikipedia linux
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://sourceforge.net/p/pywikipediabot/bugs/1475",57190,-91,Low,False
-0.8883560932814651,10.274815744425485,3.155388318461256,2.2463371435715254,-0.3461184810307866,1.4725184400622846,-0.2852583282079397,1.4507127887512414,-1.753327724771616,-2.716148028918495,-2.3094751204569595,-0.9489718788770817,0.14170551276606602,1.7799788833071446,-1.4617008286621163,0.42181462223766003,-0.6009097309449986,1.1819145220241964,False,c3,1,"Special:OpenIDXRDS returns URLs based on $wgCanonicalServer. But when it attempts to redirect the user to these URLs, the forceHTTPS cookie kicks in and triggers a redirect to the corresponding https URL, which then fails due to loss of POST data.
Chris suggests this be worked around somehow in OpenID rather than having core use a 307 redirect instead of a 302.
--------------------------
**Version**: master
**Severity**: normal",56512,-93,Low,False
28.68800933170505,-6.3928977563385585,1.8730778756720667,0.4771457317731027,0.18160069830712378,1.5489387041938418,0.1517169967406744,-1.5955032236054616,0.28921496430008575,-1.9975944179014182,-0.06854232459300036,-0.3970069518291748,-2.039920546736326,1.7365516291115473,1.8578411489309392,-0.36074489395222464,0.4890376288195786,0.3397516026093028,False,c3,1,"URL: https://zh.wikibooks.org/w/index.php?title=Special:用户登录&returnto=Wikibooks%3A首页&returntoquery=&fromhttp=1
Browser: Google Chrome 29.0.1547.66
OS: Microsoft Windows XP [5.1.2600]
--------------------------
**Version**: wmf-deployment
**Severity**: normal",56457,-93,Low,True
3.1683443454439577,-0.8658472096929657,-4.372643667737707,0.20174382524991463,-0.04538204137695567,0.20015382086781952,-5.716539861605225,-0.8737964024671724,-2.180103234981356,3.300388357785369,-2.8981375084650165,-1.3697768122300487,-0.310720687413756,-3.1393508573054643,2.0280542990315844,0.5472831483744928,-0.47876365755757977,1.2390731206421022,True,c3,1,"1. There is a ""Wikimedia > SSL related"" component in Bugzilla.
It feels wrong as ""SSL related"" is not an ""isolatable"" part of the codebase.
For example bug 39676 should be under ""Wikimedia > Email"" instead.
2. Tracking bug 27946 had the name ""Secure Server (tracking)"" and refered to the secure.wikimedia.org URL. At some point people (ab)used it for general SSL issues and renamed to ""SSL related (tracking)"".
Maybe both should be killed and turned into a ""ssl"" keyword.
--------------------------
**Version**: wmf-deployment
**Severity**: normal",55999,-95,Low,True
5.716670540598503,-4.869423010229237,-6.8944668437737935,-0.23809558292839939,-1.769428185766652,-1.2808226696825669,-5.825609515740132,-0.018287906792082503,-2.316924219064842,4.987178553047867,-4.253314661762388,-0.9412202240411645,-1.0681532345822244,-1.9561152673785713,-0.6987668424270463,-0.39631391690920215,0.8684240661816627,-2.008051680613424,False,c3,1,"It was reported by users that HTTPS block in China was only for Wikipedia, thus the following change is proposed, given the current policy of having the best security while trying to keep access for logged-in users in China.
'wmgHTTPSBlacklistCountries' => array(
'default' => array(
'IR', // Iran
),
'wikipedia' => array(
'CN', // China
'IR', // Iran
),
),
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
{T54846}
{T66207}",55739,-96,Low,True
2.2972510058274795,0.7145093438612449,1.5352922121879793,1.0272284763694164,3.351312319603095,-0.48463599313991235,-0.41707152426271854,-0.7933862022649125,-1.850597847570191,-0.15859643910099575,0.5965105943801623,1.3281129766766508,2.1880773576450805,2.229275447333059,-0.06819234137568664,1.2553348846125827,-0.592827935816764,-0.3011125050086072,False,c3,1,"Use a mobile web browser. I used ""User-Agent: Opera/9.80 (Android; Opera Mini/7.5.33361/30.3793; U; sv) Presto/2.8.119 Version/11.10"".
Steps to reproduce:
1: Delete all cookies.
2: Log in to Wikipedia. You should now see the mobile site as you are using a mobile web browser.
3: At the bottom of the page, click on the link to the desktop version.
4: Elsewhere on the Internet, find a link which points to Wikipedia's desktop HTTP edition, and click on the link. Alternatively, type in a URL yourself.
Actual result: The browser shows the mobile HTTPS edition of Wikipedia.
Expected result: The browser shows the desktop HTTPS edition of Wikipedia.
IMPORTANT: You must perform steps 2 and 3 in the order indicated above! If you perform them in the opposite order, then the result is different (due to bug 43771).
== Explanation ==
Steps 2-3 should give you two cookies:
Set-Cookie: enwikiforceHTTPS=true; expires=Mon, 30-Sep-2013 23:24:04 GMT; path=/; httponly
Set-Cookie: stopMobileRedirect=true; expires=Mon, 30-Sep-2013 23:15:06 GMT; path=/; domain=.wikipedia.org; secure
When you request the Wikipedia article (say, http://en.wikipedia.org/wiki/A), the following happens:
1. Browser sends ""GET /wiki/A HTTP/1.1"" to en.wikipedia.org. As the connection is insecure, the stopMobileRedirect=true cookie isn't sent, but enwikiforceHTTPS=true is sent:
Cookie: enwikiforceHTTPS=1
2. Server detects a mobile user agent, so you are redirected (302 Moved Temporarily) to http://en.m.wikipedia.org/wiki/A (still no HTTPS).
3. Browser sends ""GET /wiki/A HTTP/1.1"" en.m.wikipedia.org. As it is still insecure, stopMobileRedirect=true isn't sent:
Cookie: enwikiforceHTTPS=true; enwikiforceHTTPS=1
4. Server detects enwikiforceHTTPS=true and enwikiforceHTTPS=1 (no idea why the browser has two cookies with the same name) and you are redirected (302 Found) to https://en.m.wikipedia.org/wiki/A.
5. Browser switches on SSL and sends ""GET /wiki/A HTTP/1.1"". Now all cookies are sent, including stopMobileRedirect=true (private information removed):
Cookie: enwikiSession=REMOVED; centralauth_User=Stefan2; centralauth_Token=REMOVED; centralauth_Session=REMOVED; enwikiUserID=808814; enwikiUserName=Stefan2; enwikiforceHTTPS=true; enwikiforceHTTPS=1; stopMobileRedirect=true
6. You see the mobile website.
Problem: As the redirect to HTTPS happens after the redirect to the mobile site, the stopMobileRedirect=true cookie is sent too late and the server won't know that you wish to stay on the desktop website.
--------------------------
**Version**: unspecified
**Severity**: minor",55667,-96,Low,True
-7.9644493031395385,9.318934290209036,-3.543946234807793,6.310817312003005,-5.384428261629177,7.32683615169127,0.3210199541029759,2.0749251968458564,8.298151165294183,2.196407984924485,4.287832573921319,2.800105922001225,-2.344682736305889,3.6717649916652917,0.09988635253319167,1.6248378269117099,1.5324002096544216,0.7051522108929158,True,c3,1,post SUL finalization the wikimedia.org/wikipedia.org/wikiquote.org/wikibooks.org/etc. front page should have the ability for users to log in and create accounts similar to the way that actual wikis do.,1382,-32,Low,False
3.237778511313459,4.442291471616137,4.961082016315583,0.8505598731634876,3.160322209250517,9.19302455809592,-0.04419688472047767,1.0224881151104324,-2.561142038741277,5.864201316717375,2.0166706937613816,1.8308851057807247,1.0620359508651451,-1.7836386725468305,1.111705427292649,-1.989945004575571,-0.5807905609810052,1.6587788467844071,True,c3,1,"Upstream: https://secure.phabricator.com/T6564
The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login.
If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1248,-34,Low,True
-5.307638724531737,5.639013968401304,-1.340392792713308,-3.6234212158744232,1.3161443469843823,0.31548984055614904,-0.940526135041333,-0.0544438382684648,1.92825922060278,-1.0449112641985145,-0.8460202423698648,2.3720194983964538,-0.03832608571998808,0.6226922237207848,-1.103081843180946,-0.027730055674587917,1.171973434783663,-1.195115542034326,True,c3,1,"Let's improve https://phabricator.wikimedia.org/auth/start/
* The LDAP login form is the most prominent element, but in fact most users can't use it, or have no idea what LDAP is, and just confuse it with a Wikimedia login.
* The position of the MediaWiki login down there is too secondary. Many users have no clue that THIS is what you need to click.
* The text at the top could be put to better use. (Currently `You can use your unified Wikimedia account or your Labs/LDAP user to login.`)
Jared has volunteered to work on a mockup. We will need to agree on its feasibility. Phabricator doesn't offer any configuration of this page out of the box.",862,-36,Low,False
-0.3272170791985798,11.077454135225167,0.6812602980048368,-6.525021999672657,-0.6142999536946085,-4.366080883541945,1.4894973682387942,-2.5217567011117494,-1.7974744204731956,-1.7983299129874086,-0.2500977163727076,3.191847209761148,0.048380359080995916,-0.19924439937758098,-1.104539511328059,0.3691421793964748,-2.039779693228218,-1.6624063773064195,True,c3,1,"Phabricator has a feature to watch a repository hosted elsewhere, which is being used here for testing with several repos (e.g. rMW). Several of these use https URLs (e.g. rMW has https://github.com/wikimedia/mediawiki-core, rMMV has https://gerrit.wikimedia.org/r/mediawiki/extensions/MultimediaViewer).
I tried to use https://git.wikimedia.org/git/mediawiki/extensions/GettingStarted.git (which I think is controlled by GitBlit) for GettingStarted. However, it refused to clone it (see rGETTINGSTARTED). I wonder if it's getting confused because of the .git suffix.",155,-62,Low,True
-6.154209327472675,-0.5877600279219948,1.6504451019371587,0.8616925137233702,-3.684310033515622,3.8521716175421883,1.141648583187843,0.9645591404206667,-2.141663886759272,-2.2713095997010857,-2.8008952286169815,0.804998584359141,-0.5721079458569234,2.4709832923052177,2.034750852756874,2.1988129193744714,-1.9292835233881678,-0.7713892190353131,False,c3,1,"As title says: If a width larger than the original is called, return original image instead of error.
--------------------------
**Version**: 1.22.12
**Severity**: enhancement",74328,-37,Lowest,
8.341537848266487,2.452816881572417,3.386871005949729,-0.6847252138384611,-3.0882943493835215,0.971464429634332,5.129085313555453,-2.4703721214321517,-3.5599452273608074,0.37964740393626606,0.27448352895556605,3.6889704799729968,-0.6206819499140153,-0.003738644181312978,1.2679027063627357,0.44723064231653104,2.269022782135904,1.031248158073644,False,c3,1,"Form Iran and China Https access is difficult so these two countries use Http for mediawiki projects.
Pdf which is generated by Collection extension has Https link on their internal Link
http://fa.wikipedia.org/wiki/%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1:Yamaha5/bug_of_pdf
I connected to wiki with http but the pdf's links are in https
--------------------------
**Version**: unspecified
**Severity**: normal",73590,-39,Lowest,False
-8.068352606643689,-1.8009913173085028,-4.226631149337225,-3.592619681451075,3.8467727880981175,0.9992420256730716,3.253845791701578,1.5842312448442812,-1.363429717796469,1.601677592429688,1.7157781603053928,3.6504894236346495,-1.7060433900392695,2.343119041284255,3.8381188611518278,-1.3101190603113022,-1.0973793399194496,0.18063246704569758,False,c3,1,"When visit [1] the notification about ""central login"" is shown, but the autologin does not work, because it is not a wmf page (so no security problem).
But it is scary to read such notification. It is possible to disable the autologin notification, when the autologin is not possible?
[1] http://www.systranet.com/turl/?systranbanner=1&systrangui=WebUI&systranuid=aHR0cC1kZS53aWtpcGVkaWEub3JnL3dpa2kvV2lraXBlZGlhOkhhdXB0c2VpdGUvZW5fZXM%3D
--------------------------
**Version**: unspecified
**Severity**: normal",72487,-43,Lowest,False
-6.572089272075605,2.7949711975349025,1.8784981669038494,4.3331847162857215,2.5528348348167484,-0.06058765061327209,0.2792925175477121,-1.5191792812921818,2.5259629652301188,-2.397403633800828,-1.9291879898167115,1.1713731978663626,-0.7829696089689779,0.19236937365020257,-0.15258015559935068,-0.4964391242926256,0.6162865349518014,0.19720557768161506,False,c3,1,"**Author:** `ttguy1`
**Description:**
If you use the EmbedVideo extension to embed a youtube video eg {{#ev:youtube|dMH0bHeiRNg}} then the html created delivers the youtube content over http. If the wiki running the EmbedVideo extension is delivering content over https then the resulting page is detected by modern browsers as containing mixed content and the youtube embeded video is blocked.
Users can unblock the content but they might not know that they can do this. I did not know at first.
The solution would be for the extension to deliver the content from youtube over https - youtube can do this. I guess the extension should some how detect if the wiki is using http or https and send youtube data in the matching format.
--------------------------
**Version**: REL1_20-branch
**Severity**: normal
**URL**: https://userbase.kde.org/Kdenlive/Manual/Effects/Blur_and_hide/Auto_Mask",71454,-47,Lowest,True
-10.465931122555384,6.342919072059079,-5.161918496213923,-4.035634487268201,-1.267168907459901,-3.230325256457916,2.6701453866335862,-1.8617155230561768,-2.5365212814802227,2.0913587652511936,-0.5575345388484934,-1.2876268006070408,-0.1890194237862861,1.5028189827361755,0.26197177529157933,-1.8123429747136712,1.0920717358669683,-1.05439542685012,False,c3,1,"**Author:** `cometstyles`
**Description:**
I generally use wikimedia wikis on the non-secured http format so over the last 2 years, whenever i end up on a wiki where the ""Always use a secure connection when logged in"" is checked (by default), i'm forced into https which also forces my other wikis including the major ones into https, which can only be fixed via logging out multiple times on each wiki. I'm a filemover on commons which means when i rename i file, i'm auto-logged into all the wikis the files is on to replace them but because i'm randomly logged out of most of them wikis due to this irritating 'bug', I'm unable to replace the files on those wikis, I'm lucky if i even get 2 wikis done...
so please allow a global option to ""uncheck"" 'Always use a secure connection when logged in' at https://login.wikimedia.org/wiki/Special:Preferences to allow users like me to keep our http option instead of randomly getting logged out of wikis. currently the 'check' option is greyed out...
Https is slow and does not cache, and I'm on a somewhat slow internet access with limited data so being forced to cache scripts everytime i refresh just wastes away my data and I'm not the only one, all 3rd world countries have users on slow internet connection, they are probably affected in the same way..when i was on dialup on enwiki between 2006-2010, i was fast and that time there was no https option, now even on a slightly faster speed (7mbps connection), it feels worse than dial up at times when i end up on https ...
--------------------------
**Version**: unspecified
**Severity**: enhancement",71319,-47,Lowest,True
4.063232508765179,-8.949742215607131,0.6739711890757825,1.6669666796974907,-6.259695188435343,2.3859720575191252,2.3928736931082133,-1.705736616280452,-0.04754258205081824,-1.5205778664092775,-2.782897082822338,-1.6297044700251808,-2.08983069751993,-0.5830785395007885,0.48022375059456124,2.743005562172915,-0.5956127834630661,-0.3477578035879081,False,c3,1,"In master.
--------------------------
**Version**: master
**Severity**: major",70962,-48,Lowest,True
18.76050224957414,-4.768280765928946,-15.239385298519506,3.1608952882504884,-0.4069802787340573,-2.4130220931224153,-4.461905651353043,-0.35557017970451676,-2.6669928674644607,-4.898545292192399,-1.2063299291347933,-0.8655228001601647,9.867252389699814,5.574098548610216,2.4045207732612495,-0.654556701019589,-0.2837504332310301,0.6023143178682362,False,c3,1,"Warning: Invalid parameter for message ""stalkerlog-log-login"": a:1:{s:3:"raw";N;} in /srv/vagrant/mediawiki/includes/Message.php on line 934
Call Stack:
0.0006 253272 1. {main}() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:0
19.6050 51193712 2. MediaWikiPHPUnitCommand::main() /srv/vagrant/mediawiki/tests/phpunit/phpunit.php:160
19.6050 51206200 3. PHPUnit_TextUI_Command->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiPHPUnitCommand.php:42
127.4282 273527048 4. PHPUnit_TextUI_TestRunner->doRun() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:176
127.4901 273844016 5. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php:350
128.2664 273846256 6. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
1692.9132 488462368 7. PHPUnit_Framework_TestSuite->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:709
1708.7517 476635896 8. PHPUnit_Framework_TestSuite->runTest() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:749
1708.7517 476635896 9. MediaWikiTestCase->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php:779
1708.7552 476635552 10. PHPUnit_Framework_TestCase->run() /srv/vagrant/mediawiki/tests/phpunit/MediaWikiTestCase.php:133
1708.7553 476635552 11. PHPUnit_Framework_TestResult->run() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:783
1708.7554 476636496 12. PHPUnit_Framework_TestCase->runBare() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestResult.php:648
1713.1958 477058840 13. PHPUnit_Framework_TestCase->runTest() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:838
1713.1958 477059600 14. ReflectionMethod->invokeArgs() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:988
1713.1958 477059872 15. ApiLoginTest->testRunLogin() /srv/vagrant/mediawiki/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php:988
1713.2243 477182720 16. ApiTestCase->doApiRequest() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiLoginTest.php:173
1713.2255 477303800 17. ApiMain->execute() /srv/vagrant/mediawiki/tests/phpunit/includes/api/ApiTestCase.php:99
1713.2255 477303864 18. ApiMain->executeAction() /srv/vagrant/mediawiki/includes/api/ApiMain.php:332
1713.2372 477310864 19. ApiLogin->execute() /srv/vagrant/mediawiki/includes/api/ApiMain.php:907
1713.2576 477324664 20. wfRunHooks() /srv/vagrant/mediawiki/includes/api/ApiLogin.php:95
1713.2576 477324720 21. Hooks::run() /srv/vagrant/mediawiki/includes/GlobalFunctions.php:4031
1715.5685 477329808 22. call_user_func_array() /srv/vagrant/mediawiki/includes/Hooks.php:207
1715.5685 477330344 23. wfStalkerLogin() /srv/vagrant/mediawiki/includes/Hooks.php:207
1715.5686 477331968 24. LogPage->addEntry() /srv/vagrant/mediawiki/extensions/StalkerLog/StalkerLog.php:44
1715.8277 477364768 25. LogFormatter->getIRCActionText() /srv/vagrant/mediawiki/includes/logging/LogPage.php:493
1715.8277 477364880 26. LogFormatter->getPlainActionText() /srv/vagrant/mediawiki/includes/logging/LogFormatter.php:329
1715.8277 477364880 27. LogFormatter->getActionText() /srv/vagrant/mediawiki/includes/logging/LogFormatter.php:156
1715.8277 477364880 28. LegacyLogFormatter->getActionMessage() /srv/vagrant/mediawiki/includes/logging/LogFormatter.php:344
1715.8278 477365320 29. LogPage::actionText() /srv/vagrant/mediawiki/includes/logging/LogFormatter.php:724
1715.8278 477367504 30. Message->escaped() /srv/vagrant/mediawiki/includes/logging/LogPage.php:326
1715.8279 477367592 31. Message->toString() /srv/vagrant/mediawiki/includes/Message.php:766
1715.8382 477368216 32. Message->replaceParameters() /srv/vagrant/mediawiki/includes/Message.php:673
1715.8383 477368664 33. Message->extractParam() /srv/vagrant/mediawiki/includes/Message.php:895
1715.8383 477368960 34. trigger_error() /srv/vagrant/mediawiki/includes/Message.php:934
--------------------------
**Version**: master
**Severity**: normal",70717,-49,Lowest,True
-7.239014299236537,-1.6369632077573026,-0.3549770717092091,0.8402446561430745,6.853479717204152,2.8752866440879004,2.4114492729623693,3.742815804080964,-2.041109472956981,4.839778866770766,2.2473841391878566,-0.48045438729834977,0.8944715938133743,2.2620935610681396,-1.8410381244832994,-0.716707933346874,1.4788753552508143,-0.7328756706804651,False,c3,1,"`.mw-ui-vform > div label` specifies an explicit dark color. On dark skins this means the contrast becomes low and in the worst case (the skin isn't using an absolute black) becomes illegible.
This case isn't fixed by simply applying an explicit color somewhere so we'll probably have to create a new 'dark' common/skinning module.
--------------------------
**Version**: 1.24rc
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70351",66734,-61,Lowest,False
11.293601484549002,-1.2508098329115427,-0.6965541359657212,0.49164935822485933,0.05481462562990602,-1.4530394482250943,0.4818554323775386,0.4398193124195736,-1.0745248068646132,0.8021346772310212,1.44849724147296,0.26169535304289404,2.6308119530712646,0.7673753379700639,1.0757249862329612,-0.39818310293346504,-1.1540002914413188,-0.35323849686239694,False,c3,1,"Fiddler trace (ZIP archive with a funny name)
Your extension seems to give some rather odd HTTP responses. Namely:
HTTP/1.1 200 OK
Server: Apache
X-Powered-By: PHP/5.3.10-1ubuntu3.9+wmf1
X-Content-Type-Options: nosniff
Cache-control: private
MediaWiki-API-Error: unknownerror
X-Frame-Options: DENY
Vary: Accept-Encoding
X-Vary-Options: Accept-Encoding;list-contains=gzip
Content-Type: text/xml; charset=utf-8
X-Varnish: 675837389, 1807899246
Via: 1.1 varnish, 1.1 varnish
Content-Length: 129
Accept-Ranges: bytes
Date: Fri, 21 Feb 2014 05:16:39 GMT
Age: 0
Connection: keep-alive
X-Cache: cp1053 miss (0), cp1055 frontend miss (0)
<?xml version=""1.0""?><api servedby=""mw1135""><error code=""unknownerror"" info=""Unknown error: "tpt-target-page""" /></api>
This was for an attempt to save ""MediaWiki 1.21/wmf5/el"" on www.mediawiki.org.
(Raw request/response pair attached in Fiddler's ZIP-based format; would be easiest to open in Fiddler, but anything else that understands raw HTTP request/response pairs should be able to make sense of the data.)
I'm assuming it's from this extension because it only happens on pages that, when edited from normal UI, open in your fancy translation tool.
I have two questions:
1. Why is this a ""200 OK""? Things are clearly not OK; it should probably be a 500, or possibly a 403.
2. Why is the error so non-specific?
--------------------------
**Version**: unspecified
**Severity**: normal
**Attached**: {F13127}",63736,-71,Lowest,True
-0.878502643465509,-13.577886321605023,-0.5652889747474106,1.3258269153144369,3.252479311016884,4.958670778354824,4.018094107600807,1.3575634449972305,0.45832245828179563,1.5452973684020703,2.159682577017287,-3.640102112237427,0.14456179970782035,-0.20248221775861452,-0.09844276649852368,-0.44016606953188464,-1.338539626739888,-0.2775353468599546,False,c3,1,"A very popular event calendar.
--------------------------
**Version**: unspecified
**Severity**: normal",62888,-74,Lowest,False
-0.681372199911622,-9.361654066466123,-2.096887446117485,-6.198004816891916,4.416478724205913,4.042192988959705,0.39028463763147503,4.527959983257141,-0.376911258235855,-2.2294570923068306,-1.8160522668715728,3.3513330557435665,0.4886189081506602,-0.42035670884796517,3.227918328340313,-2.3588833841438483,-0.6556260312424517,-1.3292147919725825,False,c3,1,"This is basically a followup to bug 57866, where such options were discussed.
Is this possible?
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T47469}",62607,-74,Lowest,False
3.517092031896017,-8.660969097934913,19.151372339031113,6.312986648386698,1.7324266572962719,-5.658839150843262,5.6268849263623,4.036520762735775,0.6046251922936519,3.339339362836297,4.43786744493136,-1.9401647347365027,2.243183280855927,-2.440495244738855,-1.2238543692794188,-0.38983280874153114,0.9023525361540605,0.009601460816322183,False,c3,1,"https://login.wikimedia.org/wiki/Special:ListGroupRights
Some pretty weird (non-default) user groups and user rights here. Example:
`Use the VIPS scaling test interface Special:VipsTest (vipsscaler-test)`
For all users? Weird. Account creators user group? Really? Weird.
--------------------------
**URL**: https://login.wikimedia.org/wiki/Special:ListGroupRights
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59702",61701,-78,Lowest,True
1.4246276072219763,-0.5888659421793516,4.126392831460333,1.5104923167336608,0.727722907309855,1.1601071658844757,0.18594591669867633,3.5404098373844843,-2.540226814197861,6.8520233390124545,2.0065105669337844,-0.9824547089267639,2.3360828250332952,-0.1201107228033731,-1.479152213584726,-0.9394389708639692,-0.30511115839926806,-0.6165721043797148,False,c3,1,"Other sites have ""Login with Facebook"".
Wikipedia should too!
At least leave this open as a long term goal 'LATER'.
----
**Pros**
* Facebook has over a billion registered users, including many/most current Wikimedians
* No need for yet another username/password
**Cons**
* Facebook is evil",61631,-78,Lowest,False
-1.6236737098075653,-2.526149744790944,-1.8166251061021157,0.453985515814771,5.16006401499566,5.331767910806982,0.31634567750866793,3.318556753673623,4.369324820609812,1.075559681793183,2.3604518377443893,1.062939752651279,1.666727775318431,-0.3584373888059842,-1.474668901188159,-1.8569355461869081,-1.5912586073287869,1.2750504939911347,False,c3,1,"See https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:I-00000601&action=history
eg. when trying to restart the bot or read something, finding a seemingly blank page like this https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:I-00000601&oldid=87399 is a bit annoying.
--------------------------
**Version**: unspecified
**Severity**: normal",58316,-88,Lowest,True
-0.5949196643854533,3.4076993924076575,1.8724918238222017,-6.99964019150029,4.067535680414148,-2.911299512660592,1.9105034819943896,-2.4684961859341072,-4.650419945516139,-1.6478778561293366,-0.6338896950491595,1.3773677830060882,-0.43323886726986416,-1.6245626633288284,2.2357963664454195,-0.04925442824220122,-0.7057888243454705,-1.856899375411238,False,c3,1,"**Author:** `salisria`
**Description:**
I had originally filed this as a reopening of bug 54626 (comment 9 https://bugzilla.wikimedia.org/show_bug.cgi?id=54626#c9 ) as I was uncertain what had triggered it. Now I know. When I translate a wikipage with Google, that is when the forceHTTPS cookies are being set despite that breaking my preferences.
In case this affects things, at the time I do that, I am not signed in to Google, but I am signed in to Wikipedia. When I translate the webpage on Goggle that is when I first get the popup message:
""Central login
You are centrally logged in as <username>. Reload the page to apply your user settings.""
That also is likely when the fifteen unwanted cookies are placed.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57081",57887,-89,Lowest,True
-0.36973190494815267,-7.115034881508149,-7.775161762075273,-4.138554852225999,-1.5351664053088543,-0.1928284260764901,-3.1008025970172355,1.670752476485105,2.351151210040819,1.3237705792733774,-0.644114733408311,2.129116897685318,2.2646218364182804,-2.1713703234143455,-1.6493429583382095,-0.006208803929847906,-0.37164332325997296,-2.174124048484932,False,c3,1,"You must log in to view other pages.
Return to Main Page.
This is because:
// Make sure the user is logged in
if ( !$user->isLoggedIn() ) {
// If not, let them know they need to
$out->loginToUse();
// Continue
return;
}
OutputPage::loginToUse: throw new PermissionsError( 'read' );
which may not be applicable...
--------------------------
**Version**: unspecified
**Severity**: normal",57394,-91,Lowest,False
0.9455404182520897,-1.2829118600042246,-0.08582909307373754,-3.8885800629032765,-3.652913845148712,-4.123183271725228,3.33231415083823,3.332007886624552,-1.9830069148965768,-2.111861307816353,-2.904550294645406,2.1743673095100196,-1.6532200552043061,0.5534536904195821,-0.32586100789841677,0.9959624490442645,-3.0452355264042197,-0.3482561605697594,False,c3,1,"To be more exact, it seems that Explorer only keeps track of history for as long as max-age allows.
IE users are annoyed... :D
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53636",55681,-96,Lowest,False
-8.564994680035149,7.808932293603021,11.470072345356595,3.870934976358331,-8.38307757860504,-7.1068262291496085,7.645327954683997,10.60934466353891,-6.378306027139253,-0.05619406677265282,-1.1608521254512076,-4.748931597892611,-1.2377042690968523,-2.4121191189299753,1.2442317262368219,2.696440046406943,-0.764932009787145,-1.907293505885142,False,c3,1,"http://web.archive.org/web/20141010155312/https://phabricator.wikimedia.org/p/Nemo_bis/ not nice, especially as that URL is linked from tasks by default for unregistered users as well (example: http://web.archive.org/web/20141010155432/https://phabricator.wikimedia.org/T638 ).",639,-38,Lowest,True
0.2856311651538501,-0.33180482995279803,15.955134418797613,-5.648765267163345,18.64099079381855,-17.03160702398372,7.129525626926196,2.930481439772424,-0.13530446319702077,-3.841703174790517,-1.869113162028463,-13.80960114297205,-3.5123912499213965,-4.330119735087156,6.866896995024365,-11.802357127142605,-4.407626327328152,-4.169046913704669,False,c3,1,"When I registered, phabricator linked mediawiki.org:/ Why the port syntax?",623,-38,Lowest,False
5.2409688934832435,11.595736893896952,1.3620080092078624,-5.443125909161013,-4.304650787735914,1.013791280576975,-2.3440397199408785,-0.5565640889190249,-4.21377953551463,3.580597707857276,-1.7853230382975793,-0.742890818320096,-2.410090765723961,-1.1456967427067593,1.961368124414423,-0.8219548828924719,-3.2664600658733116,0.06362031263110812,False,c3,1,"Some improvements to the Wikimedia SUL dialog:
* ""MediaWiki"" User
* ""[[ https://www.mediawiki.org/wiki/User:Qgil-WMF | Qgil-WMF ]]"" (as suggested in T541 as well)
Proposing this pre-Day, since it is part of the ""out of the box experience"", where it is worth to pay attention to these details. Unless it is really complicated to change MediaWiki for Wikimedia.
{M2}",542,-39,Lowest,False
-12.175970745348414,8.708144040307364,-0.2127963661241683,-2.308140916878791,-3.6422988870080397,0.6489672481091087,4.458054838048759,-2.141253005037247,-1.6370091006769487,2.29951796470662,4.72969102019408,0.8948957524638683,1.3392904878859984,-0.004598058110865111,1.1927688763320328,-1.5952011747715966,-0.0745334429667257,-0.4767167182348404,False,c3,1,"When I try to click one of the countless buttons in the left sidebar of the main page, most of the stuff is private (requires login). Everything must be public by default unless there is a reason (and separate decision) for it to be private.
Update: Since we created this task, upstream has fixed basically all our reported problems with information not visible to anonymous users... except user profiles, and they seem to have [[ https://secure.phabricator.com/T4830#58706 | a strong opinion about it ]].",57,-63,Lowest,True
-3.209337485077049,1.6846354190242963,-5.151252163953421,-4.4047497638291375,3.6481293221099462,-2.633641600236113,1.5569550260444593,-3.2391049556328917,-0.9060069360310571,-1.0056985491008423,1.9073263329404155,2.3642385785202835,0.7866482666706114,-2.4522370178622572,0.3905406104150879,-2.157958509658619,0.7083862044796059,-1.553885527266417,False,c3,3,"We've been having the occasional alert flap on the LVS HTTPS IPv6 on mobile-lb.eqiad alert, which has even caused some opsens to completely ignore it. This is something that we should fix ASAP, as a) i's highly probable it's a real problem, b) it conditions us to ignore pages.
I realized that despite his happening often, I have never been awake and/or present when this was happening. This made me go look at my IRC logs, which show this:
```
--- Day changed Tue Sep 08 2015
04:06 < icinga-wm> PROBLEM - LVS HTTP IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
04:10 < icinga-wm> RECOVERY - LVS HTTP IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 301 TLS Redirect - 505 bytes in 0.010 second response time
--- Day changed Wed Sep 09 2015
--- Day changed Thu Sep 10 2015
--- Day changed Fri Sep 11 2015
05:07 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
05:09 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10770 bytes in 0.137 second response time
--- Day changed Sat Sep 12 2015
--- Day changed Sun Sep 13 2015
--- Day changed Mon Sep 14 2015
00:08 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
00:10 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10772 bytes in 0.334 second response time
--- Day changed Tue Sep 15 2015
--- Day changed Wed Sep 16 2015
04:38 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
04:40 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10693 bytes in 0.114 second response time
04:48 < icinga-wm> PROBLEM - LVS HTTP IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
04:55 < icinga-wm> RECOVERY - LVS HTTP IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 301 TLS Redirect - 505 bytes in 1.008 second response time
05:16 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
05:19 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10693 bytes in 0.103 second response time
--- Day changed Thu Sep 17 2015
05:28 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
05:30 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10693 bytes in 1.079 second response time
05:50 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
05:51 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10693 bytes in 0.079 second response time
--- Day changed Fri Sep 18 2015
04:45 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
04:46 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10514 bytes in 1.105 second response time
06:04 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
06:06 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10514 bytes in 0.096 second response time
--- Day changed Sat Sep 19 2015
04:02 < icinga-wm> PROBLEM - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
04:04 < icinga-wm> RECOVERY - LVS HTTPS IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 200 OK - 10512 bytes in 0.121 second response time
04:19 < icinga-wm> PROBLEM - LVS HTTP IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
04:20 < icinga-wm> RECOVERY - LVS HTTP IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is OK: HTTP OK: HTTP/1.1 301 TLS Redirect - 503 bytes in 1.003 second response time
04:42 < icinga-wm> PROBLEM - LVS HTTP IPv6 on mobile-lb.eqiad.wikimedia.org_ipv6 is CRITICAL: Connection timed out
```
(hours are UTC+3)
Apparently there is //some// correlation with times of the day; this could be related to traffic levels or some other periodic tasks (IPsec session renewal?).",113154,11,Unbreak Now!,True
-4.786218986410711,5.489816505887017,-1.2247529965958108,8.482587319953577,1.8208951296417002,0.5154897520294333,0.3152317545556329,1.8499985518664013,-7.12932837130192,-3.341769920926432,0.21257590257224512,1.3056737696010245,7.987643384737421,2.333245485074202,7.0836974341389025,-1.4589358444134153,2.5579075311858004,-2.8211820422813796,False,c3,3,"tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy.
",112608,10,Unbreak Now!,True
-0.1491777211106804,9.530698688281369,-0.3288182849464292,-15.309586525174943,-5.294556286606216,-0.7487070229423383,1.1876075423958596,-1.8020565489517448,4.132587072911496,3.2393675885082454,5.698738504372679,4.242946101187135,3.0574767861069847,-0.3398532259240872,-0.6265152103570966,-3.8040451030101727,-0.5103291553310907,-1.7726545889710759,False,c3,3,"When I try to translate to be-tarask.wikipedia.org, I get `parsoidserver-http: HTTP 404` when I publish.
I can publish to other languages.
This may have something to do with the recent renaming of be-x-old to be-tarask (T11823).",111818,9,Unbreak Now!,True
12.79911506948211,4.790718292619005,5.435091803667497,-1.499623966972109,-9.998351830690792,-0.7806266216471649,-5.23968296328912,-1.0744985898618893,-4.932927796323834,-4.436657329907529,-1.1438474578731852,-0.9915990541055195,3.2266072570300364,0.8698237893191303,-1.779842984953587,-1.3444864710162199,-0.6947002926949792,3.1767084784257733,False,c3,3,"Starting with 20150903195826, publishing for Content Translation fails with Error: parsoidserver-http: HTTP 404.
In log,
```
{""servedby"":""mw1146"",""error"":{""code"":""parsoidserver"",""info"":""parsoidserver-http:
HTTP 404"",""*"":""See https://fa.wikipedia.org/w/api.php for API usage""}}
```
etc",111490,9,Unbreak Now!,True
2.3099460732900305,1.1890281946770749,4.158887576128283,0.28361327975548667,3.919182444880349,-7.061924601784292,0.3771917952727799,-0.9421780258730179,-4.656802682221177,0.31724824529126483,-1.9522513866730264,-1.3706230026171022,1.6645383799229174,1.7883897064588608,0.2767727588060689,-1.134037165105189,-2.504958249112586,1.6425562949515327,False,c3,3,"multichill@tools-bastion-01:~/queries/wikidata$ ls
(nothing happens)
>ssh tools-login.wmflabs.org
(just times out)
Web service on http://tools.wmflabs.org/ also broken. It gives 500 Internal Server Error (currently replaced by a ""Our servers are currently experiencing a technical problem. "" placeholder)",110827,8,Unbreak Now!,True
-2.371551852971851,6.98936255978516,-3.0409245692454956,1.970030952607821,-0.5265574404307233,3.1324287789055436,-3.275292763007449,-2.2677281308933916,-0.3492090130324791,-2.1618321314295974,0.29090515504166836,-3.1467727033104214,4.9884801090895605,0.7741807997230055,0.7984768890551486,2.680952985495291,-0.48214734948491544,0.8338169591874378,False,c3,3,"A request to Special:MyPage/ccvhjhdkjvkvkhjhkvkjvdh appears in the pagecounts as a visit to User:Xavier_Combelle/ccvhjhdkjvkvkhjhkvkjvdh by making a browser calling such a special page, (for example via an iframe or an embedded image or an ajax call) and by afterwards consulting the pagecounts an external site can know that my login is Xavier_Combelle and eventually correlate it with the ip or any personal information it has on me.
As I thought about a way to the best way to solve this issue would be to make a soft redirect instead of an hard one.
---
**patches: **
* master: {F2879417} + {F2977061}
* 1.23 - included in {F3112777}
* 1.24 - included in {F3113508}
* 1.25 - included in {F3110764}
* 1.26 - included in {F3110761}
**CVE:** CVE-2015-8628",109724,7,Unbreak Now!,False
6.687092527235343,7.348986734807941,9.872021806908052,5.661685063395423,-2.747524739192862,-8.10610432772737,3.659999407021634,-2.860729915169232,0.03265139699450076,0.22368175719482597,-0.30908922618750223,-0.347303176368694,-0.6297754750957498,-1.038023910792698,-0.9992529034254458,0.4275613756578442,3.1878413643490653,-0.7003723407999312,True,c3,3,"I'm not able to read any Wikimedia website on Firefox (no problem with Chromium).
Error message : Invalid OCSP signing certificate in OCSP response. (Error code: sec_error_ocsp_invalid_signing_cert).
WereSpielChequers has raised this bug too, and reported it on wikimania-l.",109712,7,Unbreak Now!,True
-4.5013942040799915,4.042001850204105,2.256813502988969,6.770922335493358,11.606475021140323,-10.604639491295954,5.850364893630364,6.6375762395580375,0.2751283205670061,-0.09977564293695806,-0.8060578958550217,2.5189485730395464,-2.2620039690568614,2.890262580340485,-1.9314433885311924,2.2789288535454553,3.5120461495835444,-1.2392170410872874,False,c3,3,"Run bundle exec cucumber features/editor_wikitext_nosave.feature locally
For some reason this test fails locally. It seems the login step doesn't work and then the anonymous editor workflow is unexpectedly entered.",109593,6,Unbreak Now!,True
-5.104155037689598,4.095529626121774,1.3822063742911048,-1.6429696856632752,2.335499261840638,-9.147080781022815,0.8058422437855732,3.2099298666525087,5.132272180811499,-0.13235645694264342,0.40480209624386676,0.5483595900891629,1.9669234506290856,1.3262404471521698,1.2285920573147902,-0.3555325396779373,2.58778864745838,-1.8695658059472753,False,c3,3,"the trusty webgrid queue has been overloaded for > 12 hours now. Andrew and I can't figure out how to get the host configured correctly. Please fix asap.
my attempts: please see https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL",109412,6,Unbreak Now!,True
0.34878481287345586,6.339064375803019,-1.4462755200266653,-6.28552845147971,-1.6754112718672773,-5.317152761061274,-0.24054022750471926,0.30727311946956704,-1.4573109150664723,-1.7586980989184804,-0.8264308133046203,0.10878123530605643,0.5723049205003599,-2.696494378571916,1.4644591699877898,-1.200968525905849,1.7013149581844231,-1.0454066789418779,False,c3,3,"People are reporting that they are unable to log into wikidata.org and being redirected even though they're not logged in. Clearing all cookies fixes the issue.
Reports:
* https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Cannot_log_in
* {T108999} (probably incorrectly duped)
* https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#InterWiki
* Lydia said some people also reported this via Twitter.
* @aude said she couldn't log in until she cleared her cookies on IRC
Possible cause could be {0275738d2d10544b474ea1aaa8a5080912323407}?",109038,6,Unbreak Now!,True
-7.4881026763050205,5.141124847356743,0.7683095675920306,2.381936665231587,-1.964430055217172,-3.699874572370394,3.7445406913099246,0.701609972700132,-4.155271374519299,-0.5206727291748683,0.20112584745280193,-2.3957886334642358,-0.2846619978334246,-1.340624466405902,-1.3381609434052608,-1.645362878211901,1.9143107560027752,2.146960192751293,False,c3,3,"https://phabricator.wikimedia.org/T102991 highlighted that we had cached objects lasting longer than 30 days, which was both problematic and unexpected. That specific issue has been fixed: https://gerrit.wikimedia.org/r/#/c/229714/ , but in researching this I realized there are actually a lot of problems with how we're handling cache TTLs, especially with how they're handled across layers and tiers of caching. The key issues here are:
1) We're limiting frontends to 120s object lifetimes in the common case - reduces front hitrate, and also explains hitrate anomalies on cache size increase during earlier experimentation here: https://phabricator.wikimedia.org/P969
2) We're not really communicating TTLs properly from Tier1 backends to Tier2 backends, or from either tier's backend to frontends in general, which is a strong blocker for simply lifting the 120s limitation on the front caches naively....",108612,5,Unbreak Now!,True
19.44765802020522,12.001370631587374,0.7370236593503208,-14.51067313750891,1.8306025542614628,-2.1523121885611376,-2.510366692897129,-4.596401249951326,-4.552605236746629,6.175186121056411,-0.31798255363282246,2.0693550795017313,1.7658216230883563,4.426662937083538,-2.2442381479735825,-4.300317489609103,0.19774450629534956,3.7698022133196805,False,c3,3,"Beta Cluster works, but when I'm trying to login, I get the ""Wikimedia Foundation Error"" Screen, since more than two hours.",107288,3,Unbreak Now!,True
14.927072610885258,-3.492038223064961,3.1110672108563584,9.12742263536619,-0.9276784147385069,-6.7087578743657295,-0.9607951528773677,-1.1470238383020344,-0.8853769566104649,-3.307130221693079,0.2965979851575762,-0.565562070684816,4.522288466697678,2.83486686359392,3.0930159997289026,-0.5662217234900621,0.3342866805638487,0.27396022098178263,False,c3,3,"I downloaded [[ https://github.com/huggle/huggle3-qt-lx/releases/download/3.1.14/huggle_3.1.14.dmg | Huggle 3.1.14 for Mac OS X from GitHub ]] today and received the following error while attempting to login. Repeated attempts produced the same error.
System log
==================
Sun Jul 19 17:47:01 2015: Loaded in 219ms
Sun Jul 19 17:47:01 2015: Extensions: 4
Sun Jul 19 17:47:01 2015: Successfully loaded: /Applications/huggle.app/Contents/MacOS/../PlugIns/libhuggle_thanks.dylib
Sun Jul 19 17:47:01 2015: Successfully loaded: /Applications/huggle.app/Contents/MacOS/../PlugIns/libhuggle_sh.dylib
Sun Jul 19 17:47:01 2015: Successfully loaded: /Applications/huggle.app/Contents/MacOS/../PlugIns/libhuggle_md.dylib
Sun Jul 19 17:47:01 2015: Successfully loaded: /Applications/huggle.app/Contents/MacOS/../PlugIns/libhuggle_en.dylib
Sun Jul 19 17:47:01 2015: Loading plugins in /Applications/huggle.app/Contents/MacOS/../PlugIns and /Users/mj94/Library/Application Support/Wikimedia/Huggle/extensions/
Sun Jul 19 17:47:01 2015: Home: /Users/mj94/Library/Application Support/Wikimedia/Huggle
Sun Jul 19 17:47:01 2015: Loading configuration
Sun Jul 19 17:47:01 2015: Huggle 3 QT-LX, version 3.1.13 build: 2597 3.1.14
Exception details
===========================
Error code: 2
Reason: There is no data to be processed
Source: void Huggle::ApiQueryResult::Process()@/Users/petanb/Documents/huggle3-qt-lx/huggle/apiqueryresult.cpp:89
Stack trace:
Stack trace not available for this OS
",106309,2,Unbreak Now!,True
-2.9971699223340154,-0.351729755800525,-1.5990951385095187,-6.012833595283501,2.255187648916708,-7.573219543550621,5.135563543473837,-9.529056834075861,0.582649428856564,0.5878655672004376,3.3526811349971726,0.4202602882527262,0.507085634105239,-1.6507667371765984,0.07600832412216274,1.1402597824508147,3.297764057351398,3.742916093005147,False,c3,2,"I cant login with my account to beta cluster it keeps telling me :
Central user login:
The provided authentication token is either expired or invalid.
{F184967}",104212,-1,Unbreak Now!,True
24.4687455569592,10.499421380914864,6.333903345518262,-3.7481574100017787,-3.9725901592402724,3.809726591323118,0.3548023190838263,-0.6004089450011147,-0.20953742690225563,0.09603876654964871,-0.15829222079122252,0.7536675471598979,0.6300707397530956,-1.1122408040389704,0.6267715807450331,-0.2109952774886733,2.4592631859240326,2.3552725914976715,False,c3,2,"do a traffic analysis for Catalan, Chinese, English, Hebrew, Italian, and Uyghur versions of Wikipedia. Lila is asking for a traffic report. Chinese & Uyghur Wikipedia transition was on Tuesday. Catalan, Chinese, Hebrew, and Italian yesterday. English at 2AM today. We also need to know traffic impact on English Wikipedia geolocated to China.
",102431,-3,Unbreak Now!,False
3.5109934710605653,13.041667307979168,15.402391850878576,1.5200436279851575,3.677040818767846,1.7561810564125102,-0.6580647773748929,0.6425283667581303,-3.4326271983406045,-0.13664707585537972,-1.0981708657532843,-2.4426861838875187,0.05718938235704929,0.07964467107880235,2.049446365751499,2.4298097794018627,-3.2950948252090217,-0.017819764962929918,False,c3,1,"The ""https://creativecommons.org/choose/"" iframe is hardcoded as HTTPS. This becomes a problem when a user is installer MediaWiki on an HTTP server.
Urls like https://creativecommons.org/choose/?partner=MediaWiki&exit_url=http%3A%2F%2F...&stylesheet=http%3A%2F%2Fmediawiki.dev%2Fw%2Fmw-config%2Fconfig-cc.css
Results in the following in Chrome 45:
> Mixed Content: The page at 'https://creativecommons.org/choose/?partner=MediaWiki&exit_url=http%3A%2F%2…t=http%3A%2F%2Fmediawiki%2Fw%2Fmw-config%2Fconfig-cc.css' was loaded over HTTPS, but requested an insecure stylesheet 'http://mediawiki.dev/w/mw-config/config-cc.css'. This request has been blocked; the content must be served over HTTPS.
We should load creativecommons over HTTP instead of HTTPS. Most likely by using a protocol relative url.",100146,-6,Unbreak Now!,True
-3.3214670977582976,9.36521910515511,5.518549832324187,8.114816143459961,-3.0182001337157196,1.5227483452442032,-0.6656952718549158,-0.4128491325445296,-2.543434710308313,-2.349400293608246,-1.2199927922269507,-3.062669683494482,2.5328368355054396,0.8096659430954194,-2.546372230899681,-2.382509981090525,0.8698899862960798,-0.07388388940360247,False,c3,1,"Loading any page on a beta wiki fills the console up with 403 errors for all kinds of static resources
```
http://bits.beta.wmflabs.org/static/master/extensions/FlaggedRevs/frontend/modules/img/arrow-down.png
Failed to load resource: the server responded with a status of 403 (Forbidden)
http://bits.beta.wmflabs.org/static/master/resources/assets/poweredby_mediawiki_176x62.png
Failed to load resource: the server responded with a status of 403 (Forbidden)
http://bits.beta.wmflabs.org/static/master/extensions/FlaggedRevs/frontend/modules/img/doc-magnify.png
Failed to load resource: the server responded with a status of 403 (Forbidden)
http://bits.beta.wmflabs.org/static/master/resources/assets/poweredby_mediawiki_176x62.png
Failed to load resource: the server responded with a status of 403 (Forbidden)
http://bits.beta.wmflabs.org/static/master/extensions/FlaggedRevs/frontend/modules/img/arrow-down.png
Failed to load resource: the server responded with a status of 403 (Forbidden)
http://bits.beta.wmflabs.org/static/master/extensions/ImageMetrics/resources/non-cors-test.js?_=0.8168604637030512
Failed to load resource: the server responded with a status of 403 (Forbidden)
Main_Page:1
Script from origin 'http://bits.beta.wmflabs.org' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://en.wikipedia.beta.wmflabs.org' is therefore not allowed access. The response had HTTP status code 403.
http://bits.beta.wmflabs.org/static/master/extensions/ImageMetrics/resources/cors-test.js?_=0.15045604505576193
Failed to load resource: the server responded with a status of 403 (Forbidden)
```
Possibly related:
* {T72445}",98046,-9,Unbreak Now!,True
-5.235953902650024,2.966962561681644,-2.2195912103751922,0.3502794734718111,1.8795123266236091,-3.75255215316409,-0.26841527653224784,-4.733285309692878,-2.66370739196621,1.626610651354249,-0.13595276209641227,1.172629198558224,0.49677902398502916,0.556949914610918,-2.270266833382067,1.9233273765749643,1.2452344889753155,0.47790174503774696,False,c3,3,"I have an internal wiki using https, mediawiki verison 1.25.2.
The server is hosted on https://my.domain/wiki and there is an apache vhost entry redirecting http to that.
Given the documentation[1] I expect I need to set the following in LocalSettings.php to get emails to contain https:// links.
$wgServer = '//my.domain';
$wgCanonicalServer = 'https://my.domain';
However this results in canonical name resolving to http:https://my.domain/wiki/Page_name in emails and also for the magic word: {{canonicalurl:page name}}
We've tried many combinations but the only thing that works for us is:
$wgServer = '//my.domain';
$wgCanonicalServer = '//my.domain';
This produces http:// links in emails but the vhost redirects to the real page. This configuration contradicts the documentation wich says ""Server name with protocol"".
I dug around in and there's a scary looking bit of code in wfParseUrl() that prepends http: onto the URL if it think it's protocol relative and strips it later, but I can't spot any means by which it would do that in my case.
I have a working wiki now, but I think there's something wrong here.
[1] https://www.mediawiki.org/wiki/Manual:$wgServerName and https://www.mediawiki.org/wiki/Manual:$wgCanonicalServer
",114243,12,Needs Triage,False
-4.563341631981143,7.189632796687633,3.1310934401385033,-7.756176927879943,1.576231750990802,-7.824137610547398,2.2135785123423526,3.8285018137831397,-3.7457938243161255,-1.0875692234951395,-2.9357295491638467,-3.23326733015414,-1.4153741279201437,0.4263459319917713,-3.2278473436266104,-4.252903106596509,3.580266281592361,-0.02386962721944008,False,c3,3,"I'm not sure why we're hardcoding HTTPS, not varying based on whether the site is set to HTTPS or not... So this would actually break stuff for sites with no HTTPS...
```
private string Server
{
get { return ""https://"" + new Uri(URL).Host; }
}
private string ExpandRelativeUrls(string html)
{
// wikilinks
html = html.Replace(@"" href=""""/wiki/"", @"" href="""""" + Server + @""/wiki/"");
// relative links (to images, scripts etc.)
html = html.Replace(@"" href=""""//"", @"" href=""""https://"");
return html.Replace(@"" src=""""//"", @"" src=""""https://"");
}
```",113551,11,Needs Triage,False
0.5477423746403542,1.7245214759589835,10.429918553466312,3.4501229819502877,1.5876078625855783,-7.268496415393696,2.2702560228227346,-2.591744680436395,-0.029712859074805364,0.3846919850416288,1.1572493452005888,-0.032186751287871296,0.17180732101482032,-0.350854843764453,-1.426999975587802,-3.867728639717273,1.3637237963407924,0.6814286091601118,False,c3,3,"When moving from the threading module to multiprocessing, I noticed [[ https://github.com/jdloft/bot24 | my project ]]'s `clean_sandbox.py` script wouldn't finish executing because of line 104 which is `self.site.login()`. I'm not sure what's different between the multiprocessing module and threading that would make the Pywikibot login script break.
Commit: https://github.com/jdloft/bot24/commit/bbc4fffb47543805296d03d9efe3e4a4f426ce5b (multiprocessing branch)
Main script: https://github.com/jdloft/bot24/blob/multiprocessing/main.py
Clean_sandbox: https://github.com/jdloft/bot24/blob/multiprocessing/scripts/clean_sandbox.py#L104",113329,11,Needs Triage,False
-1.5308691418804992,10.456625243635248,7.501559182297612,1.4599740641964667,-5.635568349679062,5.23203769829053,5.660133203363965,-0.9571190619387157,-3.497611235646122,6.232755969458644,6.902349734630818,0.7497533432583934,3.4786304944231334,-0.5699978336906861,-3.199598684104023,-3.168589568597553,1.6800935329102982,-1.9557534054424734,False,c3,3,"I've the feeling of seeing more and more cases of external links between double square brackets with an uppercase H for http.
https://fr.wikipedia.org/w/index.php?title=Chuzelles&type=revision&diff=118800735&oldid=114011228
https://fr.wikipedia.org/w/index.php?title=Sabine_Huynh&diff=prev&oldid=118802299
https://fr.wikipedia.org/w/index.php?title=Cerizay&type=revision&diff=118828198&oldid=117504304
Please, fix VE so that all those strange links are correct.",113259,11,Needs Triage,True
-10.373567043072248,2.240317379643514,2.475191937437881,6.904191623546365,10.90393933413295,2.3096209816450406,3.4947543628837012,5.2016228335222685,-0.20331863168165623,-0.8796139800921576,-0.0838312991215231,7.843001044962704,-1.6352958838539813,0.9073736568643218,3.0969181048402215,1.9277338385674603,-2.488611408315183,-1.0826545549513504,False,c3,3,"self.check_user_exists calls self.site.allusers which requires paraminfo to be loaded.
A direct API request should be used instead (the function already catches the readapidenied error)",112578,10,Needs Triage,
-13.08862857552326,7.6801663448564135,-1.964712252466951,2.40970689776855,7.375794952815816,-6.113165978959043,-1.491501740716271,-6.236600994043599,2.511837015501899,-2.175668822973169,1.8278551200024817,3.8865560685828564,-0.5365580663262577,-3.419750469500954,1.8616145648618971,-1.664739023217309,5.371193187569551,3.4517235445985097,False,c3,3,"the wmfusercontent.org certificate expired recently, and it should have been on our tracking calendar.
I've created this task to track auditing the existing certificates and ensuring all are on the calendar.",112542,10,Needs Triage,True
-8.229316833384775,5.233215953746605,-4.822860915474971,-3.131882932596016,4.594665571739908,-3.5340233293707186,-0.7627443597278649,0.7258293265894641,0.7607283622443524,-1.7881678708298838,-0.82171119684934,-1.5444647100131195,0.8532406921732982,0.2148854148032795,-1.1097387824838671,2.0718431767208787,-0.6569225338796717,1.2759905058069616,False,c3,3,"Sometimes we try to save changes we did using VisualEditor but instead get a pop-up with a ""Parsoidserver-http: HTTP 400"" error. This was once experienced by me, one of the students in our education program as well as by her teacher who leads the course, so the problem occurs quite widely.
The only chance is to go back to the VE and try to save again but this typically displays the same pop-up. In the end, you lose your edit and have to write it again. ",112496,10,Needs Triage,True
5.019103150830205,7.774659131817813,9.511875238650582,7.767009161727161,-15.633818434432872,-2.4230870300594427,1.2520630123664285,-0.43774159805267127,-4.574406532790043,5.495511646773728,0.5983674852099075,-2.9869125805225245,4.732489001380776,2.485949744875855,1.6252181992472758,0.46167290386062443,1.088798404388552,-1.8516951233275616,False,c3,3,Notice: First alias 'SocialLogin' for SocialLogin conflicts with canonical alias for sociallogin [Called from SpecialPageFactory::getAliasList in /vagrant/mediawiki/includes/specialpage/SpecialPageFactory.php at line 310] in /vagrant/mediawiki/includes/debug/MWDebug.php on line 300,112410,10,Needs Triage,False
-3.0289813841964404,4.371273730671998,4.949227717755814,3.6033849430801466,2.297408207054799,-5.220519619801518,-0.8415929122141677,6.22023609387326,3.0037082043973315,-3.5215164070080274,-3.0400772817786423,4.832594180069906,0.9421976498802804,-4.602575796030626,3.32377952906677,-2.5636156773601866,1.6158538511369531,-4.44381629353479,False,c3,3,"These are not smoke tests so were broken by the change to use core login. Please ensure nothing got broken.
https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce/806/",111489,9,Needs Triage,True
-5.1713215196156685,2.853404115730253,-1.9838528501771364,-1.8598503464634484,0.5289198845684753,-1.1698505237746426,0.7284909504754475,0.11172211607528693,2.5511606048301694,0.31801930773880915,2.05120424817189,0.012613850918639313,2.633809641355028,-2.0199020435465256,1.536117869482493,1.2184159368909389,1.043273754441733,0.7242006216803232,False,c3,3,"We recently installed WikiMedia 1.25. Around the same time, a sister project added a wiki. Both projects failed to enable wgSecureLogin and wgCookieSecure, and plain text passwords were used in subsequent logins.
According to documentation, the wiki installer is supposed to make a copy of DefaultSettings.php and provide them LocalSettings.php. We can edit LocalSettings.php, but we are not supposed to modify DefaultSettings.php (https://www.mediawiki.org/wiki/Manual:Configuration_Settings and https://www.mediawiki.org/wiki/Manual:LocalSettings.php).
However, LocalSettings.php did not have wgSecureLogin, wgCookieHttpOnly and wgCookieSecure configuration settings that were present in DefaultSettings.php.
I can't help but feel if the installer copied the settings, then it would have alerted me (and the sister project's administrator) to tune the configuration. In their absence, I (and the sister project's administrator) incorrectly assumed MediaWiki did the right thing and had a secure default.
To be clear, folks who run an HTTPS server expect something like the following to be secure and consistent with best practices:
$wgSecureLogin = true;
$wgCookieHttpOnly = true;
$wgCookieSecure = detect;
It would probably be a very good idea to ensure wgSecureLogin, wgCookieHttpOnly and wgCookieSecure are present in LocalSetttings.php created in the field, with appropriate comments stating when to change `wgSecureLogin = false` to `wgSecureLogin = true`.",111135,8,Needs Triage,
-5.1713215196156685,2.853404115730253,-1.9838528501771364,-1.8598503464634484,0.5289198845684753,-1.1698505237746426,0.7284909504754475,0.11172211607528693,2.5511606048301694,0.31801930773880915,2.05120424817189,0.012613850918639313,2.633809641355028,-2.0199020435465256,1.536117869482493,1.2184159368909389,1.043273754441733,0.7242006216803232,False,c3,3,"We recently installed WikiMedia 1.25. Around the same time, a sister project added a wiki. Both projects failed to enable wgSecureLogin and wgCookieSecure, and plain text passwords were used in subsequent logins.
According to documentation, the wiki installer is supposed to make a copy of DefaultSettings.php and provide them LocalSettings.php. We can edit LocalSettings.php, but we are not supposed to modify DefaultSettings.php (https://www.mediawiki.org/wiki/Manual:Configuration_Settings and https://www.mediawiki.org/wiki/Manual:LocalSettings.php).
However, LocalSettings.php did not have wgSecureLogin, wgCookieHttpOnly and wgCookieSecure configuration settings that were present in DefaultSettings.php.
I can't help but feel if the installer copied the settings, then it would have alerted me (and the sister project's administrator) to tune the configuration. In their absence, I (and the sister project's administrator) incorrectly assumed MediaWiki did the right thing and had a secure default.
To be clear, folks who run an HTTPS server expect something like the following to be secure and consistent with best practices:
$wgSecureLogin = true;
$wgCookieHttpOnly = true;
$wgCookieSecure = detect;
It would probably be a very good idea to ensure wgSecureLogin, wgCookieHttpOnly and wgCookieSecure are present in LocalSetttings.php created in the field, with appropriate comments stating when to change `wgSecureLogin = false` to `wgSecureLogin = true`.",111135,8,Needs Triage,
-12.856399277251185,14.89171641452026,14.836945353538741,18.144356919364178,13.50882376236729,6.648991491113687,-2.1578378250328294,-6.4212195773976095,-2.245677555830458,-3.6576021948941113,-1.9629338984572418,0.4785804468591288,-0.7402250698928308,2.751401808681532,-4.919358218688915,-3.5684587275910977,-3.235986349849137,5.846743892906206,False,c3,3,Restarting nslcd on an instance resolves the issue.,110891,8,Needs Triage,True
2.317621026672643,19.436239900371547,2.2242571874443087,-0.3588388490978087,-7.4455866781566655,1.0819233004004667,-0.39328684254423063,1.039986332054578,-1.000875743265143,-1.552175294389289,-1.4096924194801452,0.5176445924767643,0.9367505892334917,1.873065248550584,-0.9819056895944982,-0.6513668268377484,-0.6698108153523316,0.2060967713385684,False,c3,3,"Similar to the two domains (download.wiki[mp]edia.org) in T107575, https://sitemap.wikimedia.org/ also uses the cert of dumps.wikimedia.org, since sitemap is a CNAME to dumps.
So sitemap.wikimedia.org needs to point to text-lb and set it to redirect to https://dumps.wikimedia.org/.",110511,8,Needs Triage,True
2.6198661768227587,-2.2354470512314677,14.562562407818678,0.06996437731400906,3.0231897323442243,-1.4133458620175763,-5.641330929530731,1.6314376417209577,2.721564238436927,-2.662040283024148,-0.900557878187171,7.764262489293324,4.778258357151539,-0.026751204551056063,2.291098359318317,7.1286720482369414,-0.14224194836828397,0.848443796835199,False,c3,3,"See parent task and T110414#1578206.
Calls $wgAuth->allowPasswordChange(). Should be rewritten as a PrimaryAuthenticationProvider.",110470,8,Needs Triage,False
-0.34289656448214023,12.279616016225237,2.8665476910915544,-2.5495152375740053,6.916630052688419,5.177612886480139,-5.97517623075578,1.9029739194606607,-0.6977069967309146,7.516714386986973,-2.9825142639292634,1.274718375837964,-0.3264337321080637,2.9234014940887967,1.1606753034139379,-0.10013134661406653,3.95887001227549,1.3038326024623224,False,c3,3,"See parent task and T110414#1578206.
The 'AbortLogin' and 'UserLoadFromSession' hooks are both deprecated. You probably want a SessionProvider similar to the one used by the OAuth extension, and maybe a SecondaryAuthenticationProvider to reject the login if that turns out to still be necessary.",110468,8,Needs Triage,False
-3.7472245775929007,19.123346600689025,8.166134560359552,-6.043291106729525,-10.11979520329091,-0.26475327206760246,-1.6615215959633005,5.337163794217361,3.969372356284384,-1.0182322436487095,-1.147596140381736,1.626285273891802,0.03677920062347173,-1.9281026867486264,1.7582731516762866,-0.28045539359111704,-1.5034766677800682,1.9655776983188205,False,c3,3,Needs to be redone to be based on the APIs provided by MediaWiki core instead of reinventing everything in its own API module. The existing code will not continue to reliably work with AuthManager.,110299,7,Needs Triage,False
5.130489802355029,-6.123102184773529,-6.972922587854082,2.3846707648515375,3.19198059630939,-3.9475677501209834,-5.728267580850567,1.6276602466055277,-2.0692334178231806,5.311877808759295,0.7950724132666327,0.04156934963046388,1.1234984552738179,1.0554511200855474,0.6319383821891238,-1.1446310719330755,0.593833569205011,0.06270605849614408,False,c3,3,"The following PHP code used to work:
$ch = curl_init(""http://he.wikisource.org/w/api.php"");
curl_setopt($ch, CURLOPT_HTTPGET, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERAGENT, 'ErelBot/1.0 (erelsgl@gmail.com)');
$result = curl_exec($ch);
print ""<p>---$result---</p>\n"";
But not it doesn't work - the returned ""$result"" is empty.
What happened?",110167,7,Needs Triage,True
-3.453900426403095,3.987430851501607,0.7375480729969901,-0.5233626100998396,6.505319803764499,1.2373196187136635,2.256128069469601,4.4450494117235,-3.7940354682837416,-0.32642820812747697,1.4978991783054227,4.101198304545706,2.3860951488701634,-0.7313109537489781,1.1866377165129673,-2.5904307115908236,-1.5516033364479103,-0.26785188516555625,False,c3,3,"`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests).
There are multiple places where this needs to be fixed:
* when `User::pingLimiter` returns false
* when the `attempt-failures` memcached key hits the limit
* when PoolCounter refuses to take the job (can that happen?)",110109,7,Needs Triage,True
4.268888065268378,0.19428022121446276,-2.3006016402408758,6.729290914061279,-2.253894150642595,-4.936832634994752,-1.8428274964258868,-1.4869899229616115,-1.8425669910161055,-3.302610497351712,0.4061818257217129,0.7069159909287226,1.3101137142715693,0.4522873332490738,1.5852496672187684,0.027355391731458956,-0.47036887359160806,0.2060738013565968,False,c3,3,"When logging in to pywikibot on toollabs, I am getting a looping login, and it is new (for me) in the past couple of days
tools.wikisource-bot@tools-bastion-01:~$ python pwb.py login -user:wikisource-bot -debug -verbose
The base directory is /data/project/wikisource-bot/.pywikibot
Pywikibot rb1d2cc30c317fed7cfb8db4cc70c04f8913eb94b
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2]
Found 1 wikisource:en processes running, including this one.
Password for user Wikisource-bot on wikisource:en (no characters will be shown):
Logging in to wikisource:en as Wikisource-bot
Should be logged in now
Password for user Wikisource-bot on wikisource:en (no characters will be shown):
...
It is not a failed password error as that spits out a failed password error.
Version gives me ...
tools.wikisource-bot@tools-bastion-01:~$ python pwb.py version -user:wikisource-bot
Pywikibot: [https] r-pywikibot-core.git (e7e56d5, g3, 2015/08/15, 21:49:51, OUTDATED)
Release version: 2.0b3
requests version: 2.2.1
cacerts: /etc/ssl/certs/ca-certificates.crt
certificate test: ok
Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2]
PYWIKIBOT2_DIR: /data/project/wikisource-bot/.pywikibot
PYWIKIBOT2_DIR_PWB:
PYWIKIBOT2_NO_USER_CONFIG: Not set
Config base dir: /data/project/wikisource-bot/.pywikibot
Usernames for family ""wikisource"":
el: wikisource-bot (no sysop configured)
...
",109215,6,Needs Triage,True
6.142500058218667,5.640230611839382,5.985953725225301,2.486859794267227,8.91103977942665,-5.102968946263723,0.24820052536897919,2.121432812892261,-1.4447696417195537,-0.23627149222148436,-1.9976515419128666,2.35895626636853,0.03739763521820638,2.059469795242972,1.5814067837905812,1.3807978744342073,-0.524618874204279,-1.1889264270661861,False,c3,3,"Chrome on OS X 10.11 (""El Capitan"") does not trust our certificates, because the certificate chain contains the GlobalSign Root CA certificate, which uses a SHA-1 signature algorithm.
{F1488205} {F1488208}
OS X 10.11 is currently released as a developer preview. A public release date has not yet been set, but it is widely expected to occur sometime this fall.",109029,6,Needs Triage,True
16.2572901928064,9.43397825880814,7.994521780350446,-2.7256979987848142,-1.0792441304880889,-1.8765598633822627,1.6826686445916392,4.147048149576655,-3.9362650218620194,-3.0984359476953083,-4.326792417552722,3.7456288197412446,-1.8011451472692386,-1.301905818142111,0.38751826449042426,-3.701336401710295,0.0660725516448486,0.4436992328779745,False,c3,3,"OAuth mechanism of Pywikibot works well on HTTP sites, but ValueError is raised when enabling OAuth authentication on HTTPS sites.
https://travis-ci.org/VcamX/pywikibot-core/jobs/74350129#L379
```
Test a Page instance as parameter using ASCII chars. ... ERROR: Traceback (most recent call last):
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/data/api.py"", line 1912, in submit
body=body, headers=headers)
File ""/home/travis/build/VcamX/pywikibot-core/tests/utils.py"", line 414, in request
result = self.__wrapper._old_http.request(*args, **kwargs)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/tools/__init__.py"", line 1245, in wrapper
return obj(*__args, **__kw)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/comms/http.py"", line 243, in request
r = fetch(baseuri, method, body, headers, **kwargs)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/comms/http.py"", line 393, in fetch
error_handling_callback(request)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/comms/http.py"", line 310, in error_handling_callback
raise request.data
ValueError: GET/HEAD requests should not include body.
```
### Workaround
The workaround is not to use GET when OAuth enabled. This is fixed since PS17 for T102602.",108182,5,Needs Triage,True
-4.796706829766412,7.233740616837803,-0.4456437363956187,1.272942580112106,4.884026106908095,8.314619896827764,4.163069836936745,0.7362300919263577,-0.49432460558563285,2.4113165412386097,3.6191099871071466,0.9565410300910575,-0.013663660820860457,1.943860255669592,-0.9513986573713051,0.7251308299611421,-0.036268699728319476,1.3614006160170666,False,c3,3,"The production proxy, `url-downloader.wikimedia.org` has got a public DNS record and IP, and advertises as such to its internal users. Beta's proxy, on the other hand, has got an internal IP, which may create subtle discrepancies in application behaviour. The motivation for this are applications that want to check whether they are about to do an internal or external request, which then see the connecting peer always with an internal IP.",107866,4,Needs Triage,True
-5.168778928075158,5.146168268072731,1.3325909089139607,4.07933400826208,3.234205662401234,-0.9779970492111665,-2.051961922008851,3.6132788915867264,4.527607387073787,-1.1423806052738685,1.9872256044124073,1.2302570232920498,0.8015489713390789,-0.09752892473600827,-0.5462209202387154,-0.3382846335557623,-1.192290298838575,1.9655325549670992,False,c3,3,"Took me a while to track this down today...
Steps to reproduce:
1. Install GoogleLogin plugin
2. Attempt to create a new account, using a username that is not taken, but has a lowercase letter as the first letter.
3. Plugin returns googlelogin-form-choosename-existerror instead of silently accepting username and just capitalizing the first letter...
Patch will be submitted shortly. ",107806,4,Needs Triage,True
0.950382382940528,7.9413146294522505,1.34048169925655,7.378830407342914,8.34741309791014,-5.781462727714555,1.6778591954496322,4.777753893854439,-1.29411136002878,-0.5577331294696526,-3.3286482942527402,7.000921590095925,-1.6891157257191702,0.8249988478013748,-3.672537024013363,0.5692629227598703,9.450270881947391,5.368948936983743,False,c3,3,"https://download.wikipedia.org/ and https://download.wikimedia.org/ are using the certificate of dumps.wikimedia.org, which doesn't match download.wikipedia.org or download.wikimedia.org. ",107575,4,Needs Triage,True
-6.759667706367414,6.601131679760101,-3.3766783396530204,1.0119275061240351,1.6772833334182513,1.2101623349376827,0.06132988727901534,2.1768807356678375,0.9415750656729767,0.7890373983066228,0.546079926927173,0.26634114057228286,0.9744113600462541,-0.3786112507338002,-1.2031146103444996,-0.2631995523625883,-1.396637881342792,0.20272674887107,False,c3,3,"After a user logged in with a non-linked Google account, it should be possible to link this account with an already existing wiki user, instead of just the possibility to create a new wiki user.
Background: It is, so far, difficult to explain/understand, why a user needs to be logged in to connect the user account with a Google account. It's more intuitive to just login and link the google account with a (new or already registered) wiki user.
Possible workflow:
- user go to Special:UserLogin
- user clicks Login eith Google
- the, that this google account isn't linked with any wiki user so far, appears
- user selects ""I have a wiki account already"" and clicks ""Next""
- user will be redirected to Special:UserLogin with the warning message, that he has to login to merge the user
- after login the user get's the success message, that the google and wiki account is linked together
Maybe there is an intermediate step before the success message, asking if you really want to link the accounts. Or a good and short explanation how to unlink the accounts.",106606,2,Needs Triage,True
-1.4720384091071277,8.52575101048842,-0.04794856264246761,-2.2585502871925582,-0.511392181113185,-0.06739851014658504,-0.142816230279875,2.6374357636773915,-0.13590725294138403,-1.51555911711967,-0.3668963925719222,0.4875674222413833,1.4202904356572432,-4.112982594368012,1.7441538774835808,1.290618894376566,0.5220768237073001,-0.9995049021532457,False,c3,3,"Previously on the login page we would show a project identifier to users to indicate that they were not being phished and were logged in to a mediawiki project.
This is now missing in stable (enwiki, BC, localhost master) and the culprit seems to be I1b09e7ba80d18dc8c19b2aa475c4d269dffc295e
Before:
{F201710}
After:
{F201709}",106352,2,Needs Triage,True
0.8534553586890392,11.717838746507397,4.707962686612603,-13.918898856834197,2.7264248382098577,-3.383526560154823,1.6180989716841836,-5.76864789538726,-4.191320497681464,-0.8472446489311238,1.3576410720942849,-1.1315683826938807,-2.4618686121022026,2.730788978026057,-2.4050866692654314,-3.2477491255351403,1.4589391142354973,-3.0793800635834727,False,c3,3,"If I login at Beta-Cluster, after a short time I get redirected to [[ https://login.wikimedia.beta.wmflabs.org/wiki/Special:CentralLogin/start?token= | https://login.wikimedia.beta.wmflabs.org/wiki/Special:CentralLogin/start?token=<A Token> ]]. At this point, I get a connection error, I think because https, which doens't work at Beta. No matter how I try, I can't go to the http version of the page, why I have to login at every single Beta-Wiki seperately, which is really annoying.
If I log out, I haven't got any problems like this.",106035,2,Needs Triage,True
-2.6626251937376035,0.7026394273144714,-1.3640736949677024,-6.524560776534371,6.215144503589668,-7.958175287258568,0.36913483147430437,0.5333866283637817,0.2044200903386919,0.4490523091494367,-2.0307359515142798,0.7936072000398706,-0.44141588760323547,1.4361860234033497,1.64921275990402,1.6181582885183634,-2.5947275894000237,-1.9309686897716545,False,c3,3,"`python pwb.py login` fails to generate `user-config.py` when it has not already been created as the source below indicates it should.
https://www.mediawiki.org/wiki/Manual:Pywikibot/Basic_use
Instead it gives the following:
$ python pwb.py login
NOTE: 'user-config.py' was not found!
Please follow the prompts to create it:
Unknown arguments: login",105821,1,Needs Triage,True
8.403046630320473,1.0219563180504636,16.28751626935371,1.865070324375825,3.839621846501172,-1.6107332404219976,-3.3675750247902707,1.9701632616624334,4.730702801100676,-2.0361637754876787,-1.3778206920529958,-2.197029310420433,0.7808493466384645,-1.712211382522565,-1.6896356985126744,-1.998087308385001,-2.4657118890359095,3.2849414700625834,False,c3,3,"Installing ndg-httpsclient on Python2.7 can cause a TypeError
https://travis-ci.org/VcamX/pywikibot-core/jobs/70758871
```
======================================================================
ERROR: test_https_cert_error (tests.http_tests.HttpsCertificateTestCase)
Test http.request fails on invalid omegawiki SSL certificate.
----------------------------------------------------------------------
Traceback (most recent call last):
File ""/home/travis/build/VcamX/pywikibot-core/tests/http_tests.py"", line 92, in test_https_cert_error
uri='https://www.omegawiki.org/')
File ""/opt/python/2.7.9/lib/python2.7/unittest/case.py"", line 473, in assertRaises
callableObj(*args, **kwargs)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/tools/__init__.py"", line 1227, in wrapper
return obj(*__args, **__kw)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/comms/http.py"", line 230, in request
r = fetch(uri, method, body, headers, **kwargs)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/comms/http.py"", line 363, in fetch
error_handling_callback(request)
File ""/home/travis/build/VcamX/pywikibot-core/pywikibot/comms/http.py"", line 280, in error_handling_callback
raise request.data
TypeError: __str__ returned non-string (type Error)
```",105767,1,Needs Triage,False
11.21611181677186,-8.322370542650976,-0.4196890721656743,5.371494336734663,-2.2845634514536926,-3.6534715719041486,-4.126347831980949,-0.8166522230569815,-1.5983234035036336,-3.871872623171995,3.2442090081874295,-0.6554406536073966,0.9224720207036188,1.7912334395176561,1.4141846084606557,-1.3307812662421012,0.01870038324370582,0.8368736062353073,False,c3,3,"**description**:
**workaround**:
--------------------------
<table><tr><th>Exception:</th><td>`ApiErrorException`</td></tr>
<tr><th>Message:</th><td>`API returned the following error: 'The login module requires a POST request'`</td></tr>
<tr><th>Call stack:</th><td><pre> at WikiFunctions.API.ApiEdit.CheckForErrors(String xml, String action)
at WikiFunctions.API.ApiEdit.Login(String username, String password, String domain)
at WikiFunctions.Profiles.AWBProfilesForm.PerformLogin(String username, String password)</pre></td></tr>
</table>
**OS**: Microsoft Windows NT 6.1.7601 Service Pack 1
**version**: AutoWikiBrowser (5.6.0.0), WikiFunctions (5.6.0.0), revision 11138 (2015-06-13 14:30:28)
**net**: 2.0.50727.5420
**duplicate**:
**site**: http://camphalfblood.wikia.com
",105160,0,Needs Triage,False
125.12864973473413,24.461032312281354,20.258054462711378,-15.368139377215654,9.419729155465951,8.923586496494865,0.5660249642391806,-0.39953809071088453,0.6528691956095768,3.4089737421423614,1.8893517820205266,0.7864180118380248,-2.4641331367967334,-0.5539055659455503,1.5844758167120787,0.15244468824303828,0.8508428236510508,0.8283642692908557,False,c3,3,https://www.google.com/design/spec/components/text-fields.html#,105099,0,Needs Triage,True
-9.56842214956682,7.19937365165843,-2.234246232725356,2.2226271156092623,5.4300963487063125,1.6834028450426317,1.7902755258008067,0.2890183813483178,3.4570402690020803,0.9357942048614483,3.556282163084165,-0.13303148092080685,2.5169207773922366,-2.04970001565663,2.9247525701292405,-1.1420386055077785,-1.4619352902519733,1.2301921927121493,False,c3,3,"https://www.meta.wikimedia.org/ gives a ssl_error_bad_cert_domain error.
(To clarify, if this redirect to meta.wikimedia.org were to be removed entirely, my own personal mourning period would be a rather brief one involving only a limited amount of tears, but a while ago people seem to have thought it would be a good idea: {T3698}, and I just saw someone using such a link in an internal document.)",105098,0,Needs Triage,True
-3.4296606432931185,3.529556107739314,-2.5586422043419983,-4.298779149515495,-0.5672164791792408,-1.178570292705528,-0.5424923022451136,3.09327871548665,1.949430349875947,-0.4649258108818568,-0.8674026288086765,3.0227315942055775,0.621341909672569,-0.9793082101241404,-0.11726388164574342,1.0050846306845818,-0.8723667996661268,-1.002275483095193,False,c3,3,"Steps to reproduce:
# register a new account on enwiki
# go to https://tools.wmflabs.org/oauth-hello-world/
# click ""Authorize this application""
Expected result: you get the OAuth dialog
Actual result: you need to log in first
This is because users are globally logged in when they log in, but not when they register. This is apparently somewhat intentional to avoid account creation spam (T18864). The OAuth central wiki will be spammed anyway due to the autocreation job that was put in place because of T74469, so there is no reason not to autologin there, and it would make the OAuth workflow smoother.
-----
See also T94885",104932,0,Needs Triage,False
3.684888200257101,5.612534547363552,17.071733220529055,7.208997836112385,-3.6123037377845866,-4.859294054002957,-0.15283501705779834,-0.26989569437824174,-5.165648083163853,-1.2097049436726675,-1.4402670495839531,5.1303411684772,-4.199925695598195,0.11960696071402221,0.6438849962100779,3.784643082124548,-0.06753646024068427,1.115941688143227,False,c3,3,"add HTTPS variants for wmfblog in <rss> feed whitelist.
`<rss max=""6"">https://blog.wikimedia.org/feed/</rss>` yields:
Extension:RSS -- Error: Error: ""https://blog.wikimedia.org/feed/"" is not in the whitelist of allowed feeds. The allowed feeds are as follows: http://blog.wikimedia.org/feed/, http://blog.wikimedia.org/c/our-wikis/wikimediacommons/feed/ and http://blog.wikimedia.org/c/communications/picture-of-the-day/feed/. ",104727,0,Needs Triage,True
-5.545190430989101,19.23241116980583,8.312147880225073,-0.29701883845962274,-8.82519889385931,3.6529179521979254,1.5202431677584958,2.15122421368175,5.145241527569442,3.864157224358703,4.744779815020779,6.339824855431175,2.3268006700144497,2.635539938713972,-1.959361318187033,0.4650175507545748,-2.9993712677818447,-3.3164721881090773,False,c3,3,As of https://gerrit.wikimedia.org/r/222272 we have HTTP checks in place to ensure each of the RESTBase nodes responds to simple queries. The Services team would need to be able to receive mails when such checks fail to ensure a prompt response.,104656,0,Needs Triage,True
-4.256891543931941,10.475599303214903,-4.017051508130622,-8.38194279749695,-4.138258371848652,-3.937534649660451,0.2638964646928059,9.13656543705735,2.2188968719104114,-2.8205150800500824,-2.4117918848499755,0.808462476461294,0.8093282715144188,-7.8962970431702155,7.888779789596758,-6.138616046724772,2.4831127000174043,-5.262306821222174,False,c3,2,"ssh login was blocked, even on hosts that did not have /home on NFS. This was mostly solved by reboots. It would be good to figure out why this happened.",104327,-1,Needs Triage,False
5.989576030732353,5.730605337480281,1.4783728696458063,-4.2652724637295325,2.884687783719458,-1.1240426067406,2.0792014632275917,4.6290498792474954,-2.4905278456922897,-0.13783739212387847,-1.0613553492363437,0.48669169913173316,0.15810953289782503,1.448666804280963,0.21625763107169949,-0.5370351457839536,1.848979575930404,-1.9697937855479521,False,c3,2,"The referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage
* http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterCreate&returntoquery=&warning=requiredlogintext
* http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterManage&returntoquery=&warning=requiredlogintext
Although for Special:Newsletters a (different) notice is displayed:
* http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletters&returntoquery=&warning=exception-nologin-text
Probably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.",104128,-1,Needs Triage,True
11.35993225836444,-3.833504665269645,12.16205081764723,2.2154779994866067,2.143358123381399,1.8909333584741395,0.9370370668585748,-1.3004663057618906,-2.4140063812334294,1.6198768413213243,2.8578215496244,0.5195160867006772,2.5468178217911754,-1.3293024705430532,-3.302928075684971,0.24939079767642625,-1.217368312717326,-0.8762380847063369,False,c3,2,"HTTP: {F183621}
HTTPS: {F183620}
Seems like a simple font CORS issue:
```
gtisza@GergoTisza:~$ curl -so /dev/null -D- https://etherpad.wikimedia.org/static/font/fontawesome-etherpad.woff
HTTP/1.1 200 OK
Server: nginx/1.9.2
Date: Fri, 26 Jun 2015 01:19:22 GMT
Content-Type: application/octet-stream
Content-Length: 10724
Connection: keep-alive
X-Powered-By: Express
last-modified: Thu, 16 Apr 2015 21:06:58 GMT
expires: Fri, 26 Jun 2015 07:19:22 GMT
cache-control: max-age=21600
set-cookie: express_sid=s%3AXOow_zj_WMcm5I99SGN1QVlTagzt1s6r.jIDPLGD8bLsjThDORaHI4MNBtCKRJSFL%2F1JiKP23l08; Path=/; HttpOnly
Via: 1.0 etherpad.wikimedia.org, 1.1 varnish
Accept-Ranges: bytes
X-Varnish: 284252639
Age: 0
X-Cache: cp1044 miss (0)
```",103940,-1,Needs Triage,True
-6.870120296884793,14.142277210686334,0.780607375347504,-14.227110802126045,-1.6457467190258777,-22.34356114180281,8.246469968000092,-12.797694888787655,5.33145765226252,0.1102480688264933,3.3957508894556683,5.084448142297581,-1.3934694736973654,4.949676740355663,-2.6070122081793023,-3.816629980564042,-4.002002213053543,-2.7945796788137423,False,c3,2,We need to know what percentage of our traffic uses SPDY so we know how to optimize our content delivery.,103899,-1,Needs Triage,True
-4.42226058118595,-0.3267190361568577,-8.871386735690178,-10.603934707599421,4.163393914029442,-8.936547711999479,1.8487668195385556,-0.2717069542514276,0.19012079427404716,2.6539127603920614,-0.2581780813437353,-1.4989485898761565,-0.4300366933103845,-0.5503257200111156,0.6142710290546818,-0.33705658505993086,1.3027857839630046,-2.681604133160291,False,c3,2,"Using e.g. google cache:
http://webcache.googleusercontent.com/search?q=cache:https://en.wikipedia.org/%3Ftitle%3DMs.+
It pops up ""You are centrally logged in. Reload the page to apply your user settings."" every time but this is obviously not true. I don't know what it did, but it didn't establish an meaningful session.
I don't know if it is feasible to prevent the auto-login attempt when it isn't useful. But at least we shouldn't report that it succeeded when it didn't.
'
Possibly related:
* {T100413}",103883,-1,Needs Triage,False
16.93794504574151,-3.3689726794325416,-0.17733669027821186,10.283482476952033,-1.3762909642116354,-7.1522444005793195,-1.2619810537425087,-0.5739919869560274,-1.985835837241236,-4.402007569921223,-0.39989274968406674,-0.9606856336750611,10.688872359647782,9.030591321485268,7.6143942316587685,-0.7347232876629741,0.5650993893305614,1.2036020715538485,False,c3,2,"Unfortunately Huggle has crashed. Please submit the following information together with details of what were you doing to https://phabricator.wikimedia.org/maniphest/task/create/?projects=Huggle
System log
==================
qui jun 25 08:23:17 2015: Loaded in 137ms
qui jun 25 08:23:17 2015: Extensions: 4
qui jun 25 08:23:17 2015: Successfully loaded: C:\Program Files\Huggle\extensions\huggle_thanks.dll
qui jun 25 08:23:17 2015: Successfully loaded: C:\Program Files\Huggle\extensions\huggle_sh.dll
qui jun 25 08:23:17 2015: Successfully loaded: C:\Program Files\Huggle\extensions\huggle_md.dll
qui jun 25 08:23:17 2015: Successfully loaded: C:\Program Files\Huggle\extensions\huggle_en.dll
qui jun 25 08:23:16 2015: Loading plugins in C:\Program Files\Huggle\extensions and C:\Users\wrodriguez.TI014\AppData\Local\Wikimedia\Huggle\extensions\
qui jun 25 08:23:16 2015: Home: C:/Users/wrodriguez.TI014/AppData/Local/Wikimedia/Huggle
qui jun 25 08:23:16 2015: Loading configuration
qui jun 25 08:23:16 2015: Huggle 3 QT-LX, version 3.1.12 build: 2563 3.1.12-1-ga0be145
Exception details
===========================
Error code: 2
Reason: There is no data to be processed
Source:void __cdecl Huggle::ApiQueryResult::Process(void)@C:\Users\petr.bena\Documents\huggle3-qt-lx\huggle\apiqueryresult.cpp:89
Stack trace:
25 unknown symbol 0x0
24 unknown symbol 0x0
23 unknown symbol 0x0
22 unknown symbol 0x0
21 unknown symbol 0x0
20 QMetaObject::activate 0x633519f0
19 QNetworkReply::writeData 0x61152c00
18 QNetworkReply::uploadProgress 0x611c7770
17 QObject::event 0x63356530
16 QApplicationPrivate::notify_helper 0x61545bb0
15 QApplication::notify 0x61543290
14 QApplication::notify 0x61543290
13 QCoreApplication::notifyInternal 0x63330df0
12 QCoreApplicationPrivate::sendPostedEvents 0x633327d0
11 QCoreApplicationPrivate::sendPostedEvents 0x633327d0
10 QEventDispatcherWin32::processEvents 0x63376fc0
9 TranslateMessageEx 0x77b09930
8 TranslateMessage 0x77b096f0
7 QEventDispatcherWin32::processEvents 0x63376fc0
6 QEventDispatcherWin32::processEvents 0x63376fc0
5 QEventLoop::exec 0x6332dce0
4 QCoreApplication::exec 0x6332ff60
3 QCoreApplication::exec 0x6332ff60
2 QCoreApplication::exec 0x6332ff60
1 BaseThreadInitThunk 0x779e59c0
0 RtlUserThreadStart 0x77c1b960
",103825,-1,Needs Triage,True
6.401052974484861,-1.011393788324309,1.7356085940242494,0.3238914014006309,0.8228721248616939,0.38834044763856257,-2.829762835614573,0.6357957213502886,-1.6777607836887436,0.3052531536172465,-1.2036657175761734,0.42306703047966887,0.9914518926609786,1.233707548231811,0.9500915243209365,0.7750868786383784,-0.08806355431093205,0.8198689687151723,False,c3,2,"Not quite sure if the content negotiation is part of the extension or the site setup. I think it happen after the first hit on the Special:EntityData, and therefore is part of the extension.
During negotiation between the external client (as in web browser) and the repo the sequence is now HTTP 301 (secure connection) - HTTP 303 (address resolution) - HTTP 303 (content negotiation) - HTTP 200 (content delivery).
The response code for address resolution should be HTTP 303 See other (correct impl., [[ http://www.w3.org/TR/cooluris/ | Cool URIs for the Semantic Web ]]) while content negotiation should be HTTP 302 Found (wrong impl., [[ http://www.w3.org/2001/tag/doc/alternatives-discovery-20061101.html | On Linking Alternative Representations To Enable Discovery And Publishing ]]).
There are a lot of sites that use ""HTTP 301 Moved permanently"" and ""HTTP 303 See other"" for content negotiation, but ""HTTP 302 Found"" (also called ""HTTP 302 Moved temporarily"") is the correct one. See also [[ http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html | HTTP/1.1: Status Code Definitions ]].
**Server responses**
```
john@heimdal:~/tmp$ wget -S www.wikidata.org/entity/Q36661
--2015-06-25 10:59:13-- http://www.wikidata.org/entity/Q36661
Slår opp vertsnavn www.wikidata.org (www.wikidata.org) … 91.198.174.192, 2620:0:862:ed1a::1
Kobler til www.wikidata.org (www.wikidata.org)|91.198.174.192|:80 … tilkoblet.
HTTP forespørsel sendt. Venter på svar …
HTTP/1.1 301 TLS Redirect
Server: Varnish
Location: https://www.wikidata.org/entity/Q36661
Content-Length: 0
Accept-Ranges: bytes
Date: Thu, 25 Jun 2015 08:59:14 GMT
X-Varnish: 1438332533
Age: 0
Via: 1.1 varnish
Connection: close
X-Cache: cp3008 frontend miss (0)
Set-Cookie: GeoIP=NO:11:Lillehammer:61.1333:10.5000:v4; Path=/; Domain=.wikidata.org
Set-Cookie: WMF-Last-Access=25-Jun-2015;Path=/;HttpOnly;Expires=Mon, 27 Jul 2015 00:00:00 GMT
Plassering: https://www.wikidata.org/entity/Q36661 [følgende]
--2015-06-25 10:59:14-- https://www.wikidata.org/entity/Q36661
Kobler til www.wikidata.org (www.wikidata.org)|91.198.174.192|:443 … tilkoblet.
HTTP forespørsel sendt. Venter på svar …
HTTP/1.1 303 See Other
Server: nginx/1.9.2
Date: Thu, 25 Jun 2015 08:59:14 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 262
Connection: keep-alive
X-Powered-By: HHVM/3.3.0-static
Location: https://www.wikidata.org/wiki/Special:EntityData/Q36661
X-Varnish: 2371060664, 1854837344, 134795471
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 0
X-Cache: cp1053 miss (0), cp3041 miss (0), cp3041 frontend miss (0)
Strict-Transport-Security: max-age=1209600
X-Analytics: https=1;WMF-Last-Access=25-Jun-2015
Plassering: https://www.wikidata.org/wiki/Special:EntityData/Q36661 [følgende]
--2015-06-25 10:59:15-- https://www.wikidata.org/wiki/Special:EntityData/Q36661
Bruker etablert tilkobling til www.wikidata.org:443 på nytt.
HTTP forespørsel sendt. Venter på svar …
HTTP/1.1 303 See Other <<== WRONG CODE
Server: nginx/1.9.2
Date: Thu, 25 Jun 2015 08:59:15 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: HHVM/3.6.1
X-Content-Type-Options: nosniff
Vary: Accept-Encoding,X-Forwarded-Proto,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: https://www.wikidata.org/wiki/Special:EntityData/Q36661.json
Last-Modified: Thu, 25 Jun 2015 08:59:15 GMT
X-Varnish: 2436456097, 3983484236, 134797070
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Age: 0
X-Cache: cp1067 miss (0), cp3005 miss (0), cp3041 frontend miss (0)
Strict-Transport-Security: max-age=1209600
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
X-Analytics: https=1;WMF-Last-Access=25-Jun-2015
Plassering: https://www.wikidata.org/wiki/Special:EntityData/Q36661.json [følgende]
--2015-06-25 10:59:15-- https://www.wikidata.org/wiki/Special:EntityData/Q36661.json
Bruker etablert tilkobling til www.wikidata.org:443 på nytt.
HTTP forespørsel sendt. Venter på svar …
HTTP/1.1 200 OK
Server: nginx/1.9.2
Date: Thu, 25 Jun 2015 08:59:15 GMT
Content-Type: application/json; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Content-Type-Options: nosniff
X-Powered-By: HHVM/3.6.1
Access-Control-Allow-Origin: *
X-Frame-Options: DENY
Vary: Accept-Encoding
Last-Modified: Sat, 13 Jun 2015 14:37:25 GMT
X-Varnish: 2033080611, 3336853391, 134798470 125619796
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Age: 1890
X-Cache: cp1066 miss (0), cp3008 miss (0), cp3041 frontend hit (2)
Strict-Transport-Security: max-age=1209600
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
X-Analytics: https=1;WMF-Last-Access=25-Jun-2015
Lengde: ikke angitt [application/json]
Lagrer til: «Q36661»
```",103807,-1,Needs Triage,True
0.7845367977327391,2.4727373742190295,-3.0586403403163125,5.354113908224585,7.008300125611962,6.826290672605771,2.654920478710083,-0.32959792555469325,-0.9441613254710782,-1.4104568428625286,-1.4604433718186882,8.78040694125441,-0.17684214801314102,3.6462555798604424,5.756964340151616,3.8023104235095375,4.980109104806064,6.6783610264670665,False,c3,2,"https://wiki.musicbrainz.org is MW 1.19.2 and uses http authentication, and would be a good addition to the test suite.",103783,-1,Needs Triage,True
125.12864973473413,24.461032312281354,20.258054462711378,-15.368139377215654,9.419729155465951,8.923586496494865,0.5660249642391806,-0.39953809071088453,0.6528691956095768,3.4089737421423614,1.8893517820205266,0.7864180118380248,-2.4641331367967334,-0.5539055659455503,1.5844758167120787,0.15244468824303828,0.8508428236510508,0.8283642692908557,False,c3,2,https://wikitech.wikimedia.org/wiki/User:Dzahn/misc-web-https,103773,-1,Needs Triage,True
3.71108361042802,26.22029085746823,11.58167309126145,-2.9570367170991685,-16.564808950758938,-1.8646601951399733,-0.8117893284251716,5.944527093969798,-1.9877819288643706,0.39359790250750315,-5.584550637314682,0.45266448021471306,-2.518050968874472,4.5287255311722205,-4.8974296772392565,-2.6885667472924895,8.428047216338747,-4.868385888313499,False,c3,2,This doesn't allow for logins to WT on mobile with TOTP codes.,103771,-1,Needs Triage,True
-9.182998999974505,9.594749698818589,6.8362726680863055,7.41083213891482,-4.048936252821846,0.841738652806262,-0.46331210867268613,1.0851895237347198,5.051106320239252,0.8945265195030929,3.627688258961354,2.391248173721836,0.5330193692863894,-2.7566205330868536,3.517973760236708,0.04387637661717886,-0.8832428646462124,-2.156292824352496,False,c3,2,"The OpenStack utilities installed on nodepool can be configured via env variable to pass the tenant, user, password etc. It would be rather convenient to have the env variable to be loaded in the nodepool user profile.
At a minimum:
```
lang=bash
OS_USERNAME=nodepoolmanager
OS_PASSWORD=
OS_TENANT_ID=contintcloud
OS_AUTH_URL=http://labcontrol1001.wikimedia.org:35357/v2.0/
```
Will let us run `openstack server list` among others.",103673,-2,Needs Triage,True
-2.260505159807745,5.326503328600296,1.8864623044721718,-0.19494336662960832,7.160475543714449,-0.15411623059967716,-0.13688664525916572,1.23149043273298,0.7454981226267523,-1.9722021376366214,-0.38233223855863097,0.5036692220228098,0.5057016048310103,-2.513163727320706,0.4031071970060838,-0.5419902059112829,-0.07993278693835393,1.9074818325993756,False,c3,2,"When trying to ssh to sylvester I get the following:
```
$ ssh -A jkroll@sylvester.eqiad.wmflabs
If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances
Permission denied (publickey).
```
The catgraph service which should be running there is not reachable either (connection refused).
Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change.
I can ssh to other instances in the same project normally, and the services are running there as well.
Could this be an NFS problem?",103354,-2,Needs Triage,True
1.9891735445413663,5.887982767109715,-5.4311708536817225,-5.125031951785507,1.7678324238155252,-2.1068168408003487,-1.8399832676359713,7.635004833517872,2.0078310705031743,-2.5694095909379278,-2.4004177978524863,2.154844159705518,0.7192090225040899,1.5019365551049564,-3.882187425531151,-1.4560355356567471,-0.4213985232063979,-0.9079078067400517,False,c3,2,"With T102566 a bunch of wikis will have InstantCommons broken, and will probably try to find out from the error logs what's wrong. MWHttpRequest does not seem to do any error logging whatsoever, though.
There are two cases that users will encounter due to T102566 and where we should provide a helpful error message:
* MWHttpRequest refuses to follow a HTTP->HTTPS redirect
* MWHttpRequest cannot verify the Wikimedia cert (note that while Commons has been reverted to HTTPS, upload.wikimedia.org has not, so this is happening right now)
Note that this does not affect InstantCommons which does not use MWHttpRequest directly.",103043,-2,Needs Triage,True
-7.317343673831598,7.464812041531811,-0.04219746892200149,6.986997007662422,-2.2888988321029515,-1.0558079012589963,2.72740699385898,-1.0426366769645197,-1.7710167286401173,-0.7862072789337464,1.3267420717793095,1.3233075421010707,-1.1234343839839172,0.9947179417153444,-4.2923750512371885,-3.918833390895663,-0.06662760103277132,4.563533240535331,False,c3,2,"Having $wgSecureLogin=true enables code that handles redirecting the user to https for sensitive pages (login page, etc), allows opting out of https by setting cookies insecure, and sets the forceHTTPS cookie so the application can redirect users who only have cookies set securely.
Turning this to false on WMF wikis will remove the extra overhead.",103021,-2,Needs Triage,True
-0.68141641028586,3.344857799920838,0.47080449608290564,-0.23279782946882743,1.329741796721259,0.0006528053586432048,-1.5922237262856838,-0.0014243290985678225,1.9419201900765957,-0.8579711179352243,0.33940156836408786,0.6806403415812623,2.0259850506135177,-1.2415849715560356,-2.040263303951199,2.614231851833669,0.37841603531343404,0.7748830697129001,False,c3,2,"(this may be a duplicate)
`formatversion=2` in API requests gets a cleaner better response. It's the recommended future, so we should show it in all API requests, both on-wiki and in generated `getExamplesMessages()`. Related, ApiSandbox needs to support formatversion (T98083) and default it to on.
Similarly, Wikimedia wikis are transitioning to only supporting https, including api.php, so all sample API URLs that show `http:` as the scheme should switch to `http`**s**`:`. The {{ApiEx}} wiki template and generated `getExamplesMessages()` don't show the scheme.
(We also should have shown `continue=` in all examples to encourage the improved continue format, but that will become the default in July 2015.)",103015,-2,Needs Triage,
-4.852550565167678,10.726271132779367,5.087044653207187,6.7890053215212935,8.894481392990613,-2.597053591190372,0.5245574227315242,6.620872010125475,-3.9035694068604005,-4.434870737977997,-1.8762083806050973,2.822945301161636,-3.540072682637982,-0.805003464611838,0.8433606322972054,2.4433760304421166,1.4888871956469727,1.1537656323939618,False,c3,2,"autosigner.py automatically signs labs puppet and salt CSRs.
This can instead be done via https://docs.puppetlabs.com/puppet/latest/reference/ssl_autosign.html and https://docs.saltstack.com/en/latest/ref/configuration/master.html#auto-accept along with a nova plugin maybe that deletes the key when an instance is deleted.",102504,-3,Needs Triage,True
-13.09619928948787,11.32934510551943,4.613263661844645,10.4388783134108,7.623871971791727,3.2939650634141397,-4.95473271570784,1.7710660792209714,-1.8414052850067606,-4.8875214192135665,-0.4816706848110792,2.2437350497173085,-1.3276554689655056,-0.4171550751222455,2.1055557218554215,2.1502251710071656,0.998497042120331,-1.8110705010945678,False,c3,2,"The `-pass` parameter (in both variants) is ignored and the buffered password in the login script is never used again.
[[https://gerrit.wikimedia.org/r/#/c/181582/|Gerrit 181582]] is a patch which would build the basis for the script to pass the password along.",102477,-3,Needs Triage,False
-2.954416526705224,4.82477908919299,-0.7037889155730923,2.137195727734339,5.238440870465006,-2.2023631918049125,-1.2905643128897575,1.828582181837504,0.2638568988663036,-3.4356737939313198,-1.4070290532665395,2.59264783502797,0.2567204660537925,-0.5868134681208161,-1.0495459319033502,-0.7477672280109893,-0.06100584370091067,0.22556311821619857,False,c3,2,"Wikimedia sites are apparently going https only, which means that any code using http:// may break.
The [[https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/| announcement ]] is very light on details.
https://meta.wikimedia.org/wiki/HTTPS#2015
Both core and compat support using https, however they both have instances where a URL is created manually (not via Family methods), and that URL has a http:// protocol/schema.
I suspect that the servers will still forward http:// URLs to https:// , but that needs to be confirmed.
In any case, we should fix any instances where the code is using the Family methods to create a URL.
Here is one regex to see some examples of the problem
```
git grep '^[^#@]*http:\/\/.*wiki.*\.org'
```",102315,-3,Needs Triage,False
4.863169045107426,-12.927921783796853,9.312774066277111,4.310912976583843,0.3759474399554057,-5.495519209854509,-2.533477930167448,-1.8897944267464797,0.10285248645763562,-2.8525600651607266,-2.0462235367669326,0.24790889433554741,2.292168471265775,-4.078068617985466,-3.0954235032892576,0.23212211313224715,-0.7308760088513965,-1.219934679652385,False,c3,2,"```
$ curl -v https://stream.wikimedia.org/rcstream_status
* Trying 2620:0:861:ed1a::3:15...
* connect to 2620:0:861:ed1a::3:15 port 443 failed: Network is unreachable
* Trying 208.80.154.249...
* Connected to stream.wikimedia.org (208.80.154.249) port 443 (#0)
* found 180 certificates in /etc/ssl/certs/ca-certificates.crt
* found 724 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: An unexpected TLS packet was received.
* Closing connection 0
curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received.
$ curl -v http://stream.wikimedia.org:443/rcstream_status
* Trying 2620:0:861:ed1a::3:15...
* connect to 2620:0:861:ed1a::3:15 port 443 failed: Network is unreachable
* Trying 208.80.154.249...
* Connected to stream.wikimedia.org (208.80.154.249) port 443 (#0)
> GET /rcstream_status HTTP/1.1
> Host: stream.wikimedia.org:443
> User-Agent: curl/7.42.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.4.6 (Ubuntu)
< Date: Sat, 13 Jun 2015 01:02:16 GMT
< Content-Type: application/json
< Content-Length: 41
< Connection: keep-alive
<
* Connection #0 to host stream.wikimedia.org left intact
{""connected_clients"": 1, ""queue_size"": 0}
```",102313,-3,Needs Triage,True
-3.182728976159915,-0.8424007455681686,4.806165577680751,7.929776696121513,9.434362484896887,1.3758287215150913,3.1871398657157934,-6.1969936240226,-2.149528591251187,-0.09339158904598932,1.7961424640934323,1.8550631687200132,-0.1446312813983246,1.8294015262353263,-2.8577785790285506,-0.011325907581936523,-0.9673455438044889,-1.2362574467075422,False,c3,1,"I have created a new Jessie instance integration-lightslave-jessie-1002 which points to a self puppet master. The puppet conf has:
```
lang=ini
[agent]
server = integration-puppetmaster.eqiad.wmflabs
certname = i-00000cdb.eqiad.wmflabs
```
Running puppet I am yield:
```
Warning: Server hostname 'integration-puppetmaster.eqiad.wmflabs' did not match server certificate;
expected one of
i-00000a4c.integration.eqiad.wmflabs,
DNS:i-00000a4c.integration.eqiad.wmflabs,
DNS:integration-puppetmaster.integration.eqiad.wmflabs,
DNS:puppet,
DNS:puppet.integration.eqiad.wmflabs
```
/etc/resolv.conf has:
```
domain integration.eqiad.wmflabs
search integration.eqiad.wmflabs eqiad.wmflabs
nameserver 208.80.154.20
options timeout:5 ndots:2
```
[[ https://wikitech.wikimedia.org/wiki/Hiera:Integration | Hiera:integration ]] has:
```
lang=yaml
classes:
- role::puppet::self
""role::puppet::self::master"": integration-puppetmaster
""role::puppet::self::enc"": yaml+ldap
```",102108,-3,Needs Triage,True
-5.755140263102163,0.22817505332291077,-5.7916850000756686,3.6283021417948067,2.820184845283788,-0.0659983038199099,-3.9642876370087157,3.8287518741735145,-2.275595731138452,-2.301662190401152,7.472989947521695,-0.020261107571524217,-1.1248179888633052,0.053546957557692565,1.9129459815138636,-1.9637118782614813,-0.6167695596058399,-1.0403593870860388,False,c3,1,"We just had an ldap outage because the ldap cert setup is... unexpected.
[4:55pm] paravoid: this is pretty broken in general
[4:55pm] Coren: paravoid: What was the issue?
[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA
[4:55pm] paravoid: which is pretty broken
[4:55pm] paravoid: that's a single intermediate CA, not a certificate store
[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root
[4:56pm] paravoid: also quite broken
...
paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",101317,-5,Needs Triage,True
-10.529842058081048,5.904264582856623,-0.900726555464793,6.4972537572383535,2.870673874726061,0.8649698706398021,6.129492191502535,-2.4174395806085216,-1.9139094175882678,-3.3088517698878777,-4.139696782848869,-2.2494036009035745,-5.638493701523953,3.704122617734102,-0.5542725809148807,-2.6243693156200494,-0.17306492943946084,0.08475088000045905,False,c3,1,"I get lots of this error when using the centralauth vagrant role, during actions which involve redirection to the login wiki (e.g. login, registration).",101193,-5,Needs Triage,True
-1.4993446131110857,1.0505047744561296,-5.715107193136319,-12.0387431809855,14.31112711716234,-15.392787152150467,5.952401291503201,-7.901065989311984,7.814487520356993,4.410194067208868,5.9699620052924445,-1.5942252078666872,-0.9912359138555997,2.4308769677080315,1.8583435524994387,-0.5244930918817537,0.4131726707192378,-3.6182491325640487,False,c3,1,When we change cert names the ENC might break -- we should make sure it won't.,101124,-5,Needs Triage,True
-1.79649533637524,9.333561340224854,5.541884556620879,-1.9267082808302463,1.828541160781267,-0.4578900120563828,-2.2547892756032586,2.2726323641056343,0.7559127660422662,-2.369809157073835,-0.3037318169451986,1.6236780534186261,1.0857632993798938,-0.131737169820072,1.0723282676200219,0.5579997488573678,-1.5576906426547514,-0.33221001249417026,False,c3,1,"Here is how to reproduce the bug:
1. Go to a specific query page on Quarry, say http://quarry.wmflabs.org/query/3654
2. Click on the Login link up top
3. Pass the OAuth step successfully.
Expected behavior: you should be redirected back to http://quarry.wmflabs.org/query/3654 after login.
Current behavior: you are redirected to http://quarry.wmflabs.org/ instead.
I assume this can be fixed by keeping the referring URL in a query string or a cookie.",100162,-6,Needs Triage,True
39.11459409800839,-1.5448160060070517,-4.140591773743207,-5.776674800184113,2.685999903809305,2.2327603573209887,-3.7642072973000165,-0.27174456986123524,-0.020180286464937747,-2.0744960963465315,-1.4353236567605396,-0.5226290245826486,2.0307954495506437,-3.4014549171348136,-3.1344533348452397,0.1853757515247733,-0.6321229316527616,-0.9673903808616144,False,c3,1,{F168490},100136,-6,Needs Triage,True
-3.883981602808974,8.23669247620073,4.221742107834899,-9.239423949987732,-6.367472155984522,0.4630338649449095,1.135301069961991,-3.160301225544823,-2.8718435496615475,-1.6596641014111508,-1.2901313933082867,0.8318467672323064,0.3112367019407709,-4.328106970356063,2.824427024271146,-2.092456229899287,-0.149054438988232,-0.785715050260299,False,c3,1,"Updating https://ogvjs-testing.wmflabs.org I found I was unable to log in, with errors about cookies being disabled. Usually this indicates something about the session serialization if cookies themselves are present.
Worked around by disabling these lines in /vagrant/LocalSettings.php:
```
// Avoid user request serialization and other slowness
-$wgSessionCacheType = 'redis';
-$wgSessionsInObjectCache = true;
+#$wgSessionCacheType = 'redis';
+#$wgSessionsInObjectCache = true;
```",100068,-6,Needs Triage,True
-4.773413980849549,17.74921156523915,-1.206538856864439,-11.166031060706226,-6.269446786244449,-0.19967261397228975,-3.465780329446253,11.848600241864292,-0.7839566902261303,-2.5783257054281314,-4.673684598020531,-1.7323877584888414,-0.422438768028659,2.7070810854310228,-6.508130797389913,3.0165796319046985,3.9721485041119076,2.253917630982425,False,c3,1,"This doesn't make any sense at all. After logging in and get redirected to Special:UserLogout, the user gets automatically logged out and have to log in again. ",100022,-6,Needs Triage,True
14.600719841776709,0.33547837260031343,-5.225145631483073,-0.9910015729568693,-0.4955208753213519,0.5538327897432667,-4.176428575202578,0.8257251615480347,0.24332901126555617,-2.4163374512568687,0.7599134799178029,-0.6988132733382355,4.328456276209408,0.6012455241117296,-0.9063591227182863,0.4400513875916503,0.34290023663738745,0.12240702650186575,False,c3,1,"//[[https://en.wikipedia.org/wiki/User:Thaejas|Thaejas]] ([[https://en.wikipedia.org/wiki/User talk:Thaejas|talk]]) 00:27, 11 May 2010 (UTC) wrote://
In Login screen, when clicked on any headings of the list (ID, Username, Password saved, etc), the list disappears and AWB stops responding to close. I need to restart the AWB.
----
**Duplicate:** Open AWB and click on Login/Profiles, then click on any heading in the list.
**OS:** Windows XP
**.NET:** 2.0
**Version:** 5.0.2.2, SVN 6518
**Workaround:** Restart AWB",99297,-7,Needs Triage,True
-6.190356790990858,13.043645632199027,0.22251333114638427,-7.034779380694948,1.65669613639648,2.0635654118956417,-1.071607318894463,2.28364896373605,1.4804952165945302,-0.5408432544007677,0.6245078128410415,-1.2831049564780632,1.0514932613164465,-1.2961887344716962,0.15244820179299712,-2.1125259426117173,0.4944722690209302,0.5130990540215004,False,c3,1,"The Wikidata UI keeps flaking out on me in a manner consistent with Firefox having reached the limit for the number of concurrent requests it is willing to make. This would presumably be alleviated by the use of HTTP/2. (And by the time you get this implemented, maybe the Iceweasel I'm actually using will even support HTTP/2. ;-)
(Maybe it would be better to figure out why some of the requests might be blocking for excessively long, though.)",98527,-8,Needs Triage,True
24.94397023943295,-6.498743501391136,10.95084217218541,1.4671074610555328,1.8307151707670442,-3.2530478575550648,-1.8179944646789785,-1.6517077129253308,0.2474325302233189,-1.7822711983133428,-1.3791819109726133,0.3552605254250616,1.4367260286660173,-3.4418864417481294,-2.251745655899536,0.19310904538499246,-0.4556428322519537,-0.8576611138445303,False,c3,1,"{F161118}
https://en.m.wikipedia.org/wiki/Special:UserLogin?returnto=2002_Pacific_typhoon_season&campaign=gather&returntoquery=article_action%3Dadd_to_collection&warning=gather-purpose-login-action
",98292,-9,Needs Triage,True
-10.99497762960595,9.436222514302138,1.706372796228866,-0.7620808496390933,2.7040590502254327,-1.7197377617306053,-0.603370609836885,-4.424347886705549,1.3923341416979267,1.0038148440674437,1.565099163334542,-0.11570049865755538,1.1309895837755133,0.5356702547973278,-3.7101225164218157,3.358616659988135,3.798445378727653,4.9725652204348005,False,c3,1,"I'm trying to create a bot and log in for the first time. I've generated the family and user files, and then navigated to the pywikibot folder to access login.py, but I keep getting an error message as follows:
```
Don'tNeedToKnow@Imamadmad /cygdrive/c/core/pywikibot
$ python login.py
Traceback (most recent call last):
File ""login.py"", line 20, in <module>
import pywikibot
ImportError: No module named pywikibot
```
I haven't touched any files at all apart from running generate_family_file.py and generate_user_files.py. The version of pywikibot is the one from http://tools.wmflabs.org/pywikibot/ last updated on May 4th, but this has been happening for almost a week now. It was about a week ago that I first tried installing the software. I don't know what exactly the problem is. The above error message is all I've got. I can post further if there are more things you can tell me to do to expose the cause of the problem.
Edit: I am using Python 2.7.8 if that's of any help.
To give full list of what files are available and where, from where they've been placed by default:
```
Don'tNeedToKnow@Imamadmad /cygdrive/c/core
$ ls
ChangeLog logs setup.py
CREDITS pwb.py tests
externals pywikibot tox.ini
ez_setup.py README.rst user-config.py
generate_family_file.py README-conversion.txt user-config.py.sample
generate_user_files.py requirements.txt
LICENSE scripts
Don'tNeedToKnow@Imamadmad /cygdrive/c/core
$ cd pywikibot
Don'tNeedToKnow@Imamadmad /cygdrive/c/core/pywikibot
$ ls
__init__.py config2.pyc exceptions.pyc login.pyc throttle.py
__init__.pyc data families page.py throttle.pyc
backports.py date.py family.py page.pyc titletranslate.py
backports.pyc diff.py family.pyc pagegenerators.py tools
bot.py diff.pyc fixes.py plural.py userinterfaces
bot.pyc echo.py i18n.py plural.pyc version
botirc.py echo.pyc i18n.pyc site.py version.py
comms editor.py interwiki_graph.py site.pyc version.pyc
compat epydoc.cfg logentries.py textlib.py weblib.py
config2.py exceptions.py login.py textlib.pyc xmlreader.py
```",97992,-9,Needs Triage,True
-0.6193815556883955,6.571445152715679,4.02669011248263,4.256184654878383,1.4066780183272662,-0.7854499878821496,2.016924200577498,-2.0255648211343433,1.2358218534645347,3.513591401324799,-0.10452947770140408,-1.996015079997835,-1.0891923376903083,3.7329590408379456,0.733137446039315,0.6999101717073624,0.07852508408252756,0.007278485909785859,False,c3,1,"Firefix 37.0.2
page of the site does not open
https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2015-April/001162.html and other from a site lists.wikimedia.org
{F159941}
""Firefox cannot guarantee the safety of your data on lists.wikimedia.org because it uses SSLv3, a broken security protocol. Advanced info: ssl_error_unsupported_version""
https://support.mozilla.org/en-US/kb/what-do-sslv3-error-messages-mean-firefox",97927,-9,Needs Triage,True
29.136440137685554,8.664133146272086,2.387083126103864,-6.8167889672406385,1.3025773203560223,0.8717443375453173,-1.680897059846325,-1.6602234645190856,0.6974291836705355,-1.2525403812049665,-0.8153985722657446,0.0988914746944749,0.6526250516732843,-1.6761331523104959,-1.775752334138049,-0.6967842204944508,0.8501553199416014,-0.7786128727443566,False,c3,3,"With the unplanned expiration of a couple of SSL certificates, T112542 was generated. Since then, we've listed all of the domains we purchased certificates from.
Now we need to decide if we are going to put in icinga checks for all of them, or just some, and how to differentiate.
>>! In T112542#1640176, @BBlack wrote:
> We only have that icinga check on the primary unified cert, which covers the production endpoints for:
>
> - wikipedia.org
> - mediawiki.org
> - wikibooks.org
> - wikidata.org
> - wikimediafoundation.org
> - wikimedia.org
> - wikinews.org
> - wikiquote.org
> - wikisource.org
> - wikiversity.org
> - wikivoyage.org
> - wiktionary.org
>
> ... and all of their mobile subdomains and whatnot. It's a pretty verbose check, validates functional SSL for all of the SAN domains, checks the cert expiry, etc.
>
> But we don't have any kind of checking in place for the various other misc certs we own that are deployed for smaller or one-off services, or deployed to third parties (or in some cases, rare today but important later - not deployed at all but still critical). Just looking at puppet's files/ssl/ today, that list is something like:
>
>
> archiva.wikimedia.org.crt
> blog.wikimedia.org.crt
> dumps.wikimedia.org.crt
> ecc-star.wmfusercontent.org.crt
> eventdonations.wikimedia.org.crt
> ganglia.wikimedia.org.crt
> gerrit.wikimedia.org.crt
> icinga.wikimedia.org.crt
> labvirt-star.eqiad.wmnet.crt
> ldap-codfw.wikimedia.org.crt
> ldap-eqiad.wikimedia.org.crt
> ldap-mirror.wikimedia.org.crt
> librenms.wikimedia.org.crt
> lists.wikimedia.org.crt
> policy.wikimedia.org.crt
> rt.wikimedia.org.crt
> star.planet.wikimedia.org.crt
> star.wmflabs.org.crt
> star.wmfusercontent.org.crt
> stream.wikimedia.org.crt
> tendril.wikimedia.org.crt
> ticket.wikimedia.org.crt
> toolserver.org.crt
> virt-star.eqiad.wmnet.crt
> wikitech.wikimedia.org.crt
>
>
> Of those, I can see in our icinga config direct expiry checks only for:
>
> lists.wikimedia.org
> ticket.wikimedia.org
> ldap-codfw.wikimedia.org
> ldap-eqiad.wikimedia.org
>
Additionally: https://docs.google.com/a/wikimedia.org/spreadsheets/d/1yT5rvoEEUHhNeJAQRVamr8ECqN3TLsMaO8N_At4Ki3I/edit?usp=sharing lists all the certificates and expiry info.
We need to determine which of these will get icinga checks.
",114059,12,High,False
4.452781746471441,1.4547715772916856,-6.937023622880044,-13.394377492738224,1.5333365002211368,1.580212697814077,0.36807510794647325,-7.29064574161612,-3.9364025447563407,0.542441030231104,4.204506397183518,1.8358120366651651,4.601897382062106,-1.2877537164206707,-6.2481995156435275,-1.031163578463875,1.3713664981638163,-4.537847194724702,False,c3,3,"```krenair@deployment-logstash2:~$ sudo puppet agent -tv
Exiting; no certificate found and waitforcert is disabled```
```root@deployment-puppetmaster:~# find /var/lib/puppet/server/ssl/ca -name deployment-logstash*
/var/lib/puppet/server/ssl/ca/requests/deployment-logstash2.eqiad.wmflabs.pem
/var/lib/puppet/server/ssl/ca/signed/deployment-logstash2.deployment-prep.eqiad.wmflabs.pem
root@deployment-puppetmaster:~# ```
I imagine @bd808 knows something about this.",112537,10,High,True
1.8098798410460906,4.495207621320851,-0.3340483998228905,5.150203201092126,3.355467064300702,-1.3177058839368216,-0.557723177165995,0.3327912084125725,0.6792265633781519,-1.1084948737991112,-0.12560154748214503,-1.6667999200047638,2.1206879408766826,0.7359065156115996,-0.8688577443747878,-1.5574593895967848,0.29200962029701016,0.2751020102847035,False,c3,3,"The static server often returns HTTP 403 Forbidden for files recently updated from Git. This seems to be an NFS issue based on discussion with valhallasw in #wikimedia-labs.
**Known facts:**
* This happens even if I break the symlink from `~/www/static` to the git repository before updating.
* This happens very reliably, but only for modified files. (Updating the repository doesn't break files that didn't change.)
* The 403 seems to be cached on the server; after renaming the file, the new name works fine but the old name keeps returning 403 (even though it's not there anymore).
* This seems to last for quite a while (5+ hours) until it starts the serving the file.
* Remounting the NFS share on the static server solves the problem temporarily (including preventing further occurrences), but it eventually started happening again.
When I renamed an affected file (so both names below should return 'no such file'), valhallasw noticed this behaviour from the static server accessing the NFS share:
valhallasw@tools-web-static-01:/data/project/meta/www/static/scripts/edge$ cat pathoschild.regexeditor.css
cat: pathoschild.regexeditor.css: Permission denied
valhallasw@tools-web-static-01:/data/project/meta/www/static/scripts/edge$ cat pathoschild.regexeditor.csss
cat: pathoschild.regexeditor.csss: No such file or directory
**Repro steps:**
# Become a Tool Labs project.
# Clone [a git repository containing CSS/JS files](https://github.com/Pathoschild/Wikimedia-contrib) to `~/git/<repo>`.
# Symlink `~/www/static/<repo>` to `~/git/<repo>`.
# View one of the files via `tools-static.wmflabs.org/<project name>/<repo>/<filename>` (you should get HTTP 200 OK).
# Perform an upstream change to one of the files.
# Update the git repo (`git pull`).
# View the same file via tools-static.wmflabs.org (you should get HTTP 403 Forbidden).",112388,10,High,False
3.388475403517868,12.727231594234656,2.3866374933882177,3.3576902178181935,-2.329008549302361,1.2086172134274193,1.6614943420777566,-1.9580289511213333,-3.4720998301536783,-1.1321869902902364,-0.39656291201723093,-1.2210632847362357,0.4855883393514637,-3.0600247967536047,0.17127499673930835,-0.06869652496087542,-0.6114206758037177,1.0378240267947276,False,c3,3,"The cert renewal is already in-progress, pending on GlobalSign. Original hack was for phab.wikivoyage.org, but now it's been switched to phab.wikidata.org.
The commits from the initial wikivoyage hack:
https://gerrit.wikimedia.org/r/237913
https://gerrit.wikimedia.org/r/237914
https://gerrit.wikimedia.org/r/237912
Commits from the switch to wikidata:
https://gerrit.wikimedia.org/r/#/c/237920/
https://gerrit.wikimedia.org/r/#/c/237919/
After switching back phab itself on iridium, the phabricator.wikimedia.org hostname needs purging in the misc_web cache cluster.",112381,10,High,True
1.3212652570370813,8.353645581425518,2.245666936676365,-6.137506985648041,-0.3604234671450266,-4.519340123955282,0.6137131047697917,-3.307883623900513,4.081446849227228,0.2922622287111638,3.373324157358946,-0.8157240062248954,3.3757316653347913,-0.4635504732093789,2.424671206222568,1.2996980891718173,0.33863398768344144,1.3278996295473908,False,c3,3,"Did we change a password and forget to update it on our builds?
Several of the MobileFrontend tests are now failing with unexpected HTTP response (403) (MediawikiApi::HttpError)
e.g. https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/256/
",112118,10,High,True
-2.1675140387213263,10.522400402256132,5.790193825344236,2.18557537082373,-2.379717621814292,2.0301124222834384,1.7173935699491825,-0.8578244115568852,2.8599376660497704,1.121458471365706,1.956038911687441,-0.4376869340106023,0.6521673360571878,-0.822343825151985,0.17391421650087224,-0.9394440120351046,1.9876022899539352,-0.6532086472810543,False,c3,3,"Login form below fold on Wiktionary and possibly other projects. That suggests this may decrease login rates (it did when the submit button dropped below the fold for Special:Mobileoptions)
Visit https://en.wiktionary.org/wiki/Special:UserLogin?mobileaction=beta&useformat=mobile which forces the use of the core login form to see this.
{F2538485}
On the short term we should hide this big chunk of text on mobile screens (either in UserMerge extension or MobileFrontend).
On long term UserMerge will need to be a bit more clever with its placement.",111460,9,High,True
-7.878186119094977,8.992025447455205,4.554741303254662,-0.9310636119633176,-9.100099472514056,-0.9707676967237607,-2.5093312330590654,1.4408060788415646,-3.6210993306665724,-3.5404369801160285,-4.3188999755582795,10.989598092899488,0.8293446060199918,-1.3979049563500703,-2.9821166732648345,-2.997663025205497,0.6051595099333948,-2.2082737378669277,False,c3,3,"Jobs that happen to be deployed on this host fail with:
```
Job 416426 caused action: Job 416426 set to ERROR
User = tools.veblenbot
Queue = webgrid-lighttpd@tools-webgrid-lighttpd-1411.tools.eqiad.wmflabs
Start Time = <unknown>
End Time = <unknown>
failed assumedly before job:can't get password entry for user ""tools.veblenbot"". Either the user does not exist or NIS error!
```
I can't `ssh` to that host either:
```
[tim@passepartout ~]$ ssh tools-webgrid-lighttpd-1411.tools.eqiad.wmflabs
Permission denied (publickey,hostbased).
[tim@passepartout ~]$
```
(which makes sense in view of the ""can't get password entries"" error above). I have disabled the queue `webgrid-lighttpd@tools-webgrid-lighttpd-1411.tools.eqiad.wmflabs`.",110783,8,High,True
-4.141694204514701,14.212952462236952,14.408808819380848,-5.175033407897052,-9.967969297922437,10.604262053303046,-2.3653983046732856,-1.1306625150283027,-7.949608044524892,0.5026056686499372,0.8758226079213824,-2.091858422359537,2.1873209639172217,0.3027105620550099,-4.65187463008729,4.5830735113700385,-2.555926590482755,-1.2680914217089492,False,c3,3,"With an entry like follows in `user-config.py`
```
usernames['wikipedia']['*'] = 'JVbot-test'
```
`login.py` emits a error
```
$ python pwb.py login -all
Logged in on wikipedia:test as JVbot-test.
*.wikipedia is not a valid site, please remove it from your config
```",110411,7,High,
-6.609164523745163,5.147762943218694,0.5080760666411201,1.286354030021815,4.739773797576621,1.2383844516033935,3.4333736053168336,4.089108501364433,-2.1387259915253125,0.5798029541890157,2.168260339938317,-0.7493260206934127,1.4628834868766534,-0.819570205549268,0.6598073123249151,1.0294309298512143,0.652876563785511,1.560696152867502,False,c3,3,"Have a look on this wonderful login page for dewiki:
{F2399139}
It's alpha and beta only (where we have core login page) on an emulated Nexus 5. That looks terrible and the languagelinks should be hidden for now (and maybe replaced with a nicer language selection, maybe a dropdown?
The list is created here:
https://github.com/wikimedia/mediawiki/blob/d1fb1a2d0e1878aac70b3767c58ef6b3a1aa065f/includes/specials/SpecialUserlogin.php#L1649-L1666
And is a simply mediawiki message key and needs to be enabled with $wgLoginLanguageSelector (for local testing e.g.).",110403,7,High,False
-6.247385916669874,7.392455406047279,2.70038800524274,4.020497536871142,-4.453067445992218,3.5639553755284235,2.371755292260617,0.25096399203300557,-1.372640133163842,-0.24753611807807907,0.039796599446125125,-0.7039582467743933,0.7786490280290375,2.6922099137432074,0.5438929023271211,2.741191254389013,1.2142606351255119,0.628956946715707,False,c3,3,"Cassandra supports TLS encryption of traffic between the nodes of a cluster. We do not currently encrypt inter-node traffic, but in the interest of security, must as a prerequisite to a multi-DC configuration.
//Current status (2015-09-24): `internode_encryption: dc`, (encryption between the eqiad and codfw data-centers) is in place. `internode_encryption: all` (encryption between nodes in each of eqiad and codfw) remains to be done.//
See also: T111113",108953,6,High,False
-7.089150075302816,13.93725392558525,0.3711261428010104,-4.808911701051007,4.21946148754318,-5.155926884420797,1.8435743851998678,-8.122977608138896,1.3368739502651281,-1.1430101882982378,0.9949307107427123,-1.0425184167760309,-0.7803289872983292,-0.44656603083124047,0.9369875496509072,1.867925366757113,-3.4095379245666715,-0.34067982982848277,False,c3,3,"If you click the Login link on an article page and login using your username and password, you will be redirected to the article from where you started the login process automatically. If you use GoogleLogin instead, you get redirected to the main page. You should be redirected to the article, too, if you use GoogleLogin.",108473,5,High,True
22.76671192245109,-7.160157409099066,2.7276905979504598,-3.8581684513826997,0.843930067231319,0.27852311026561183,-5.5574011183279035,3.60849891120796,1.620674002111734,0.07114019602114485,8.583351974085847,4.500156271006471,1.6417178963686059,-1.4856713564841941,3.3701413217167895,0.07122934512352919,0.2009354504293137,-1.0635956686618744,False,c3,3,"1. View https://commons.m.wikimedia.org/wiki/Main_Page
2. Open web console
> GET https://www.m.mediawiki.org/wiki/Special:CentralAutoLogin/start?type=1x1&from=commonswiki&mobile=1 DNS net::ERR_NAME_NOT_RESOLVED
> GET https://www.m.wikidata.org/wiki/Special:CentralAutoLogin/start?type=1x1&from=commonswiki&mobile=1 DNS net::ERR_NAME_NOT_RESOLVED
May be related:
* {T45123}",108201,5,High,False
-7.669299939732213,9.368941982107508,0.6731615473937609,0.19756587812489412,-0.8903356843115151,0.7095664523865028,0.9467541133096873,-2.7083314412992934,-1.547887430448028,-0.4049110734332384,0.7709246793751094,-1.8020546874761998,-0.8330614270241572,0.11469211288962189,0.028738150618933922,0.37785147109183526,-1.4018797700403238,-1.1557182872835174,False,c3,3,"Create an opt-in email notification when a user logs in for a new device. This is for admins and active editors who are worried about getting hacked.
The notification is off by default, opt-in under the Notifications tab.
Definition of ""new device"" is the same as LoginNotify. There's a cookie per device, which lasts for 90 days since the last time you logged in with that device.
Email:
Someone (probably you) recently logged in to your account from a new device. If this was you, then you can disregard this message. If it wasn't you, then it's recommended that you change your password, and check your account activity.
Help information: <https://mediawiki.org/wiki/Help:Login_notifications?markasread=60>
Change password: <http://core.local/index.php/Special:ChangePassword>
----
original ticket:
Most large sites (Facebook, Google etc.) offer some kind of alert when someone logs in to an account from a new machine - it's a good way of protecting against account theft:
{F305280}
{F305286}
{F2546774}
I wonder if something like that would make sense for MediaWiki? Ie.
* put the one.way hashed username in a cookie with very long expiration
* after a successful login check for the presence of the cookie
* if it's there, update the expiration date
* if it's not there, and the user requested alerts, send an email with the IP and other details of the login.",107707,4,High,False
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c3,3,nan,107577,4,High,True
0.3389083789490681,8.771386960195183,7.463902044247128,3.9873080219847274,4.939533228776414,1.4038504713758775,-3.523170313646419,-2.101945487612506,0.6513443315617754,2.723786598256786,-1.4329560159773291,1.2495159949965327,0.2671434408121378,0.0616283604254404,-1.2363063634718996,0.10594594591256459,-0.5339893828622372,-0.785055025569992,False,c3,3,"On `tools-webgrid-lighttpd-1408`, Puppet fails with:
```
scfc@tools-webgrid-lighttpd-1408:~$ sudo puppet agent -tv
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/physicalcorecount.rb
Info: Loading facts in /var/lib/puppet/lib/facter/ganeti.rb
Info: Loading facts in /var/lib/puppet/lib/facter/labsproject.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/initsystem.rb
Info: Loading facts in /var/lib/puppet/lib/facter/apt.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_config_dir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/lldp.rb
Info: Loading facts in /var/lib/puppet/lib/facter/ec2id.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to determined $::labsproject at /etc/puppet/manifests/realm.pp:14 on node tools-webgrid-lighttpd-1408.tools.eqiad.wmflabs
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
Error: Could not run command from postrun_command: Cannot allocate memory - fork(2)
scfc@tools-webgrid-lighttpd-1408:~$ free -m
total used free shared buffers cached
Mem: 7985 7763 221 444 142 6255
-/+ buffers/cache: 1365 6619
Swap: 487 0 487
scfc@tools-webgrid-lighttpd-1408:~$
```
The ""SERVER:"" prefix makes me think that this could be a memory shortage on the Labs puppet master and not a local problem.",107350,3,High,True
2.113610229761092,5.429092360903269,-5.258468378532523,-2.8377855500058526,1.2235654468429118,2.478255522882881,-0.18091088833720104,-0.4875944860501835,0.22933034876767744,-0.32118391703590277,1.222458599193923,0.9907435931384174,1.8956376493425129,-1.433424423018831,-2.1301153178749646,-0.34934462711977643,0.161869107250026,1.098901846545848,True,c3,3,"Major Gifts is setting up a new event invitation and payment processing tool through Trilogy Interactive (see related tasks for more info: T101191, T104357).
Trilogy is helping to set up new pages for us at events.wikimedia.org and eventdonations.wikimedia.org, and want to know who they should contact about an SSL certificate. The donate.wikimedia.org has a wildcard SSL cert, so we could conceivably use that for the events site, but want to confirm this with Ops.
**EDIT: We are fine with WMF purchashing a new cert as well. The domain is eventdonations.wikimedia.org**
",107059,3,High,True
-4.951386155386583,10.284915335579871,2.1767235005587295,2.7389262271862798,-1.8304759601302707,3.145089981315059,3.8087534498172912,0.8084771456789791,-4.88098307123187,0.8596367609625517,2.3920570916339954,-1.416726395475793,1.9581119720988558,-4.5683540660653765,1.2757087861948841,0.4723124007860976,1.5334512390437627,-2.150242678312113,False,c3,3,"T106895 exposed a large hole in thumbnail monitoring. Even though this page was filled with broken thumbnails, no SMS or IRC spam was sent by any bots. In general, if that happens, it indicates a pretty serious problem with upload or new thumbnails.",106937,3,High,
-2.7761001695050664,4.569969913452081,-5.15195895336932,-2.027391730200318,-2.186380468694856,-2.4448525104998065,3.5190649197647774,4.072858046001726,-3.822703049012767,-1.2931843151548228,-0.9810046985969016,-0.060249535550310096,0.8725600244471248,-0.9241231980535081,4.320904444704845,3.113686232035744,-0.8850118149854697,-0.911309110796924,False,c3,3,"Fatal error: Call to undefined function curl_strerror() in /srv/mediawiki/php-1.26wmf15/includes/libs/MultiHttpClient.php on line 232
The error was introduced in {db2d4b670983df43686c4c1a671369d8ebcaaf82}
curl_strerror was added in php 5.5, and it appears to be supported in hhvm as well, so I'm really not sure why this is an undefined function.
",106579,2,High,True
-3.0861673367354356,13.090756752483944,3.5420509282771633,1.1519894180047716,0.2552937859883748,4.868092230086389,-0.9894068388666097,0.29524950012817885,-1.7297956020473153,-1.82470830361268,-1.7861510854704563,2.1014923618183783,0.21571403820309332,0.9404857534256328,-1.0925517878489437,-2.77846174794956,-0.738141851347498,-0.6882001280497345,False,c3,3,"Trying to run a script on cron for the HostBot project. Script works as expected when manually run from the command line, fails on JSUB. This is using a virtualenv with the dev version of mwclient, since the version on labs is an older one without support for setting a user-agent.
Looks like it's using an instance of Python that can't import `_ssl`. Is this expected behavior? Can that Python be updated? Any help appreciated :)
cron job:
```
*/5 * * * * jsub -N matchbotenwiki /data/project/hostbot/matchbot/bin/python /data/project/hostbot/bot/matchbot/matchbot/matchbot.py /data/project/hostbot/bot/matchbot/matchbot/
```
Stack trace:
```
Traceback (most recent call last):
File ""/data/project/hostbot/bot/matchbot/matchbot/matchbot.py"", line 34, in <module>
import mwclient
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/mwclient/__init__.py"", line 27, in <module>
from client import Site, __ver__
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/mwclient/client.py"", line 22, in <module>
import requests
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/__init__.py"", line 58, in <module>
from . import utils
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/utils.py"", line 26, in <module>
from .compat import parse_http_list as _parse_list_header
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/compat.py"", line 7, in <module>
from .packages import chardet
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/packages/__init__.py"", line 3, in <module>
from . import urllib3
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/packages/urllib3/__init__.py"", line 10, in <module>
from .connectionpool import (
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py"", line 31, in <module>
from .connection import (
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/packages/urllib3/connection.py"", line 45, in <module>
from .util.ssl_ import (
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/packages/urllib3/util/__init__.py"", line 5, in <module>
from .ssl_ import (
File ""/data/project/hostbot/matchbot/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py"", line 12, in <module>
import ssl
File ""/usr/lib/python2.7/ssl.py"", line 60, in <module>
import _ssl # if we can't import it, let the error propagate
ImportError: No module named _ssl
```",105403,1,High,True
-2.807440322947028,6.781494982141762,4.592250706415491,-4.528640947174571,-8.786092834239462,8.679133387781711,-0.12710934892796377,-2.992539164771789,-1.6643352620712704,-1.3469747980967273,-1.617996523016337,-1.3402390075860033,0.1605656990408999,1.6694753337368624,2.4001437212236345,1.8805073719891474,0.2388182508852077,1.8371071857726922,False,c3,3,"After authorizing on commons (with Extension:OAuth, as oauth provider), on the commonsarchive (with Extension:OAuthAuthentication, as oauth client):
```
Exception encountered, of type ""Exception""
[03fd090a] /wiki/Special:OAuthLogin/finish?oauth_verifier=****bc69825860215462c4f5ef74****&oauth_token=75551e721a597bd39098dd26159e768d Exception from line 220 of /srv/mediawiki/extensions/OAuthAuthentication/libs/mwoauth-php/MWOAuthClient.php: Curl error:
Backtrace:
#0 /srv/mediawiki/extensions/OAuthAuthentication/libs/mwoauth-php/MWOAuthClient.php(188): MWOAuthClient->makeCurlCall(string, string, boolean, boolean, MWOAuthClientConfig)
#1 /srv/mediawiki/extensions/OAuthAuthentication/libs/mwoauth-php/MWOAuthClient.php(129): MWOAuthClient->makeOAuthCall(OAuthToken, string)
#2 /srv/mediawiki/extensions/OAuthAuthentication/handlers/OAuth1Handler.php(47): MWOAuthClient->identify(OAuthToken)
#3 /srv/mediawiki/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php(66): MediaWiki\Extensions\OAuthAuthentication\OAuth1Handler->identify(OAuthToken, MWOAuthClient)
#4 /srv/mediawiki/includes/specialpage/SpecialPage.php(384): MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute(string)
#5 /srv/mediawiki/includes/specialpage/SpecialPageFactory.php(582): SpecialPage->run(string)
#6 /srv/mediawiki/includes/MediaWiki.php(267): SpecialPageFactory::executePath(Title, RequestContext)
#7 /srv/mediawiki/includes/MediaWiki.php(566): MediaWiki->performRequest()
#8 /srv/mediawiki/includes/MediaWiki.php(414): MediaWiki->main()
#9 /srv/mediawiki/index.php(41): MediaWiki->run()
#10 {main}
```
Further investigation shows the curl post to https://commons.wikimedia.org/w/index.php?title=Special:OAuth/identify encountered a 301 (as a result of 155d555b83eca640), and Extension:OAuthAuthentication is unable to handle it.",105375,1,High,True
0.5998533302745686,9.148637256311588,-2.224755848016752,1.3271719553190517,-0.7857053950220321,0.6595921411897272,-1.0764826641813947,4.267110481590689,5.881344711724932,0.3421102969285341,1.3967190209941198,2.2570561866315275,0.7803645461444111,-0.539508063094515,0.007284369611628705,-0.4853047010378553,1.743392189727062,-0.5149628720801649,False,c3,3,"This will be the tracking task to replace the SHA1 certificate for ldap-mirror.wikimedia.org to SHA256.
[ ] - reissue certificate in SHA256 & create patchset containing the new certificate
[ ] - merge into puppet and ensure ldap gets the updated information
FYI: I recall that previously, puppet alone didn't force LDAP to use the new certificate; further manual commands were required within ldap.",105187,0,High,True
7.5113069422582495,-11.985103785748322,6.474741305025535,-8.240999090448582,1.9154584651709792,-4.737754172374173,-9.24851040213402,7.110592534001347,2.430799060124494,-4.112577154252807,2.887270824148936,-1.1659246213998955,-2.206658076178708,-2.925168265049299,-0.15356825881593306,5.729542784553752,-2.9781388836992138,0.15417769807059556,False,c3,3,"```
// Use http for image path, there is no need for https
return wfExpandUrl( $iconUrl, PROTO_HTTP );
```
Should use PROTO_CANONICAL instead.
",104835,0,High,True
10.652750708330322,5.864425762472479,-6.686785339657039,5.2026647049560495,-6.702647011712971,-2.371276222703374,-0.8406446501085441,1.466196241731288,-4.063384124758687,-3.0679978449632106,0.6069682757680415,-2.173275681577292,2.807602441960544,1.3199772290638734,0.5281550074998353,-0.37607082456790253,0.566638956262066,-1.1873845670806644,False,c3,3,"This happened for croptool on 5 jul 2015:
Last lines in error.log:
```
[2015-07-05 03:34:03] exiftool.INFO: Exiftool executes command /data/project/croptool/vendor/phpexiftool/exiftool/exiftool -overwrite_original -quiet -TagsFromFile '/data/project/croptool/public_html//files/c1ba468a60b8a2fdbe02cdd36721d9fedf2f8835.jpg' -all:all '/data/project/croptool/public_html//files/c1ba468a60b8a2fdbe02cdd36721d9fedf2f8835_cropped.jpg' [] []
2015-07-05 11:48:57: (server.c.1398) [note] sockets disabled, connection limit reached
```
Last lines in access.log:
```
10.68.17.145 tools.wmflabs.org - [05/Jul/2015:07:10:04 +0000] ""GET /croptool/backend.php?action=exists&site=commons.wikimedia.org&title=Florazolam%20(cropped).jpg HTTP/1.1"" 200 62 ""https://tools.wmflabs.org/croptool/?title=Florazolam.jpg"" ""Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.7.0""
10.68.17.145 tools.wmflabs.org - [05/Jul/2015:07:12:38 +0000] ""HEAD /croptool/ HTTP/1.1"" 200 0 ""-"" ""Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)""
10.68.17.145 tools.wmflabs.org - [05/Jul/2015:07:16:45 +0000] ""GET /croptool/ HTTP/1.1"" 200 21933 ""-"" ""Domain Re-Animator Bot (http://domainreanimator.com) - support@domainreanimator.com""
10.68.17.145 tools.wmflabs.org - [05/Jul/2015:07:17:38 +0000] ""HEAD /croptool/ HTTP/1.1"" 200 0 ""-"" ""Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)""
10.68.17.145 tools.wmflabs.org - [05/Jul/2015:07:22:38 +0000] ""HEAD /croptool/ HTTP/1.1"" 200 0 ""-"" ""Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)""
```
Note that the 'connection limit reached' message is way later than any requests in access.log.
There's a whole set of connections to the proxy open:
```
tcp 1 0 tools-webgrid-lighttpd-1210.tools.eqiad.wmflabs:56235 tools-webproxy-02.tools.eqiad.wmflabs:41828 CLOSE_WAIT tools.croptool 17100020
tcp 1 0 tools-webgrid-lighttpd-1210.tools.eqiad.wmflabs:56235 tools-webproxy-02.tools.eqiad.wmflabs:56003 CLOSE_WAIT tools.croptool 17135240
tcp 1 0 tools-webgrid-lighttpd-1210.tools.eqiad.wmflabs:56235 tools-webproxy-02.tools.eqiad.wmflabs:33872 CLOSE_WAIT tools.croptool 17084311
tcp 1 0 tools-webgrid-lighttpd-1210.tools.eqiad.wmflabs:56235 tools-webproxy-02.tools.eqiad.wmflabs:54753 CLOSE_WAIT tools.croptool 17150293
tcp 1 0 tools-webgrid-lighttpd-1210.tools.eqiad.wmflabs:56235 tools-webproxy-02.tools.eqiad.wmflabs:44893 CLOSE_WAIT tools.croptool 17129109
```
So this suggests either someone keeping the connection open, or the webproxy misbehaving and doing that.
```
$ sudo netstat -e -v -W 2>/dev/null | grep croptool | grep proxy | cut -b146- > croptools-inodes
$ for i in `cat croptools-inodes`; do sudo find /proc/6703/fd -lname ""socket:\[$i\]"" -printf %A@; echo; done > croptools-timestamps
$ for i in `cat croptools-timestamps`; do date ""+%d/%b/%Y:%H:%M:%S"" --date=""@$i""; done > croptools-formatteddates
```
Strangely enough, most of the connections seem to be later than the last access.log entry, /and/ they seem to be batched:
```
$ cat croptools-formatteddates | sort | uniq -c
1 04/Jul/2015:23:09:01
15 05/Jul/2015:07:39:01
31 05/Jul/2015:08:09:01
66 05/Jul/2015:09:09:01
54 05/Jul/2015:10:09:01
38 05/Jul/2015:10:39:01
37 05/Jul/2015:11:09:01
35 05/Jul/2015:11:39:01
22 05/Jul/2015:11:58:34
```
with a whole batch of connections every half-hour.
Tools-webproxy-02 doesn't seem to see this connection, though, so I'm a bit at a loss to what's happening here.
Restarting the webservice solved the issue.
Using
```
#!/bin/bash
for i in `qconf -sel | grep webgrid`
do
echo $i
echo --------------------
ssh $i ""sudo netstat -e -v -W 2>/dev/null | grep CLOSE_WAIT | sed -e 's/.*CLOSE_WAIT\s*//' | cut -d' ' -f1 | sort | uniq -c""
echo --------------------
echo
done
```
we see a few servers have a few (<=5) connections open, which is probably just actual traffic. However, two tools have large amounts of open connections:""
```
tools-webgrid-lighttpd-1402.eqiad.wmflabs
--------------------
103 tools.blockcalc
--------------------
(...)
tools-webgrid-lighttpd-1408.eqiad.wmflabs
--------------------
150 tools.geohack
--------------------
```",104799,0,High,False
-2.2122918466548978,3.638673622732089,6.820290811345799,-5.5885975777073185,-8.610715887237482,-3.4332294701451405,1.915893860714207,1.242060228785102,0.0847413250250727,5.317538658631861,1.7427183233078547,3.952627011058145,0.8913607141618507,-0.3042177104685502,-0.6047852461645675,2.78499123079651,-3.590293954580166,3.033456540476587,False,c3,3,"When logging in from https://wikitech.wikimedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page, expected: login successful
Actual results: ""Login error Wikitech uses cookies to log in users. You have cookies disabled. Please enable them and try again""
Logging in to other production wikis are fine. ",104759,0,High,True
7.015663755771726,7.2628467068580775,13.27806902885806,17.638604156239843,-6.240901938945857,-14.886000755901387,8.322687916857891,2.877009620439538,0.3115097422411981,-1.6591129395467727,-3.330846374408529,-4.324520983324397,-3.0346139357644653,-1.7550760648645958,1.3586333410760467,-4.435517116281748,-1.6690181107952393,-1.5681256649621287,False,c3,3,"blog rss feed links to HTTP (cleartext) blog posts even when feed fetched over HTTPS.
https://blog.wikimedia.org/feed/",104726,0,High,False
-7.579869483875541,15.818015092079548,-3.7857298520852964,-5.295696190908145,-4.088111007241519,-4.695964348053481,1.7079183468765624,1.1368562943379894,-4.858893128492832,-4.028065173853194,-3.6285433661810895,-4.862710099974118,-0.5503899686960656,-3.437825343814992,0.7153682843349465,0.4513962066460733,2.5209471434876045,2.824240011563811,False,c3,2,"There are still redirects to it from inside wikis, and the certificate just expired.",104211,-1,High,True
-5.116296689910019,10.818964484578409,-5.793471602846269,8.404872062523312,0.08450360167414295,2.9063020895128506,-0.013418050212152366,-2.5631835504166025,1.207017102489115,-3.52134164079181,-3.700531951902137,-2.3344961704060943,-2.014678808717531,-1.2479847317323904,0.3892951502520088,5.289066985965812,4.030322881243188,1.7162208742706364,False,c3,2,"*.wmflabs.org is currently served with a sha1 hashed certificate. This task will track the reissue in sha256 and the revocation and deletion of the sha1 cert/config in our side (and on rapidssl).
",104017,-1,High,True
-2.173638498592214,2.5042323331114176,1.8449159149893042,2.6603957611013653,2.377928946652161,-3.715668728523527,0.8427756046638031,-1.390215638504595,-1.5230173212804006,3.3974585163999436,1.618179900447807,1.3331640244958949,-0.029181298005874545,-0.17315070597323867,-2.135383152408657,2.2095609789455524,0.8435704452604245,1.3379397116385874,False,c3,2,"https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link.
In VisualEditor, these appear identically.
- external link ""arrow"" icon
- click on them and the link popup shows https://wikitech...
- click Edit in the link popup and it shows an ""External link"" https://wikitech..
All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!
If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way?
Expected result: VisualEditor should present existing interwiki links as interwiki links.
{T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",103920,-1,High,True
-1.5961888097820787,6.838930438689157,7.528082372182656,3.55518907860029,-1.1116120893714259,-1.0613625477692148,3.110462703054364,-2.013061352077496,1.4306311779890548,3.89151963598891,5.488526478181001,0.9529510186527432,4.4227823012244745,1.094650942778979,1.752617122366714,-0.626787555795806,2.874312717740729,-1.2417973586851634,False,c3,2,"The change to https broke a couple of bots,
the change to continue behavior due 30 June to 2 July will break more.
I think these API changes should be communicated on MediaWiki main page, API main page, and probably other channels I'm unaware of.",102997,-2,High,True
-1.650583478337339,4.544567134485305,0.09423720323153972,0.18163153831653944,-2.8217462470506174,-4.710033888182342,-0.4930500436357912,-1.7960491821460662,0.7376651279950879,-0.5464411278676868,0.30382006550386853,1.321315420449516,-0.9499595849313245,-1.0085224774197519,-0.36844426569956656,1.5581295960233636,-1.7354477119133875,-0.989347045486641,False,c3,2,"InstantCommons has been broken by the switch to HTTPS-only mode - see e.g. [[ http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page | beta enwiki ]]. Fixed in master, needs backport to supported branches. HTTPS redirect has been temporarily disabled on Commons to give users time to upgrade.
Patch for people running older versions of MediaWiki: [[ https://git.wikimedia.org/patch/mediawiki%2Fcore/8517b3cb2276878d11004e2b8bd0a41ce8876134 | 8517b3 ]]
Alternatively, you can put this code snippet in your `LocalSettings.php`:
```
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'wikimediacommons',
'apibase' => 'https://commons.wikimedia.org/w/api.php',
'hashLevels' => 2,
'fetchDescription' => true,
'descriptionCacheExpiry' => 43200,
'apiThumbCacheExpiry' => 86400,
);
```
If that does not help, the root certificate bundle of your server might be missing the certificate authority used by Wikimedia (GlobalSign), in which case it is probably badly outdated and you should update it. If you have shell access, you can check with this command (look at the ""Server certificate"" block):
> curl -vso /dev/null 'https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png' && echo success || echo failed",102566,-3,High,False
14.805556776180278,2.5908459986533074,-9.193190606042206,-0.22932785690028534,-4.888505451126493,-6.064100991332805,-8.685265331826965,7.345072807603659,1.3909817198148562,-5.5814983561418225,5.781614915951369,-2.3421602325824464,-2.627424377297153,4.42267920679045,2.442902811765797,-0.9981542275184627,1.1448208051465458,-0.5597831702754517,False,c3,2,"Per ccc6aa122bcd39e0f4f29bbcfce4edf0abfe8f2b .
17.25 <@paravoid> https://gerrit.wikimedia.org/r/217844 will probably get merged today
",102245,-3,High,True
6.865639164845712,7.69054305287273,8.683590335437202,7.33916602496878,-7.76076634318332,-2.6757962321268223,-1.590186087090256,-0.5215422508994602,3.044157128641145,-1.941399866115269,-1.9424910430620685,0.3150101786264672,0.8705889148555293,-3.111291528691082,-1.9163895021107717,0.831269582812278,0.11058615348975431,1.8348622745676704,False,c3,1,"LDAP TLS failing in some hosts with error:
```sudo: ldap_start_tls_s(): Connect error\nphab-pup.eqiad.wmflabs```
This is output of `sudo hostname -f`. ",101377,-4,High,True
-7.502989926233994,12.40814241377647,4.041227741998632,-5.034157794933596,5.216793128936292,-1.1148159418424894,2.436048936869997,2.6795369247318503,0.6987944803878934,1.1859029404558754,-0.6560188742634532,-0.8901830547796752,-2.673570141060046,2.4419241972087997,2.0742172984562455,-1.1557854771424076,1.9104068691537168,-2.256296820942398,False,c3,1,"The `tests.http_tests.HttpsCertificateTestCase.test_https_ignore_cert_error` can't fail anymore because the website tested is using a valid certificate: https://www.ssllabs.com/ssltest/analyze.html?d=en.vikidia.org
With the requests change in T98439 it might be that we don't support connections to invalid certificates anymore.",101138,-5,High,True
-2.080442460885031,3.8802133230129208,-4.875529840043958,-0.18256560458044524,7.416302279435605,12.269298448404765,-0.09550580530973374,3.246983097828325,2.8036527190004454,2.9114156218527354,4.592672092650531,-0.04106558821751172,2.1754478157992843,-0.1891648373676711,0.11715664976014573,0.46710837414143636,-0.798522831791641,-0.5976318840517245,False,c3,1,"If an automatic login to a private (read denied) is attempted twice, the first action will raise NoUsername, but the second login will raise APIError.",100965,-5,High,False
2.956824881545097,11.318922872342075,17.916906012751205,2.527013568211429,1.3000360139880025,3.665797895406766,-7.391197076010995,-0.16505517597479336,-3.7200327807386806,-4.988947954701342,0.34954372672100087,5.592319437848663,0.9639516303131392,-1.2805458089561892,5.85919321562825,-2.5327415563187072,4.043078724835581,-3.067955321599478,False,c3,1,"Visit <https://en.m.wikipedia.org/wiki/Clebsch%E2%80%93Gordan_coefficients>
At the bottom of the page is `<li>Mobile</li><li><a id=""mw-mf-display-toggle"" href=""http://en.wikipedia.org/w/index.php?title=Clebsch%E2%80%93Gordan_coefficients&mobileaction=toggle_view_desktop"">Desktop</a></li>`
This was reported via OTRS ticket #2015050410022502.",99343,-7,High,True
-2.494148217434322,5.069413178005785,0.6530015596860643,-6.091289461987385,-4.304500075615822,-4.329298542082877,-9.89939979133541,-0.1746179542123586,1.7935673916203683,8.00928011768078,-0.9388113459267102,1.5262345635260008,0.8859668177602833,4.529694091870674,1.5050129133483203,3.4641675936879746,2.2920670587052863,-2.3866459427510414,False,c3,1,"Steps to reproduce:
1. Visit http://en.m.wikipedia.beta.wmflabs.org/wiki/Golden_Gate_Bridge
2. Make sure you're logged out
3. Click on the 'Edit' icon
4. Click on 'Log in' or 'Sign up' buttons in the overlay that appears
5. You may click as many times as you want, you'll never be taken to the login/signup page ;)",99154,-7,High,True
-7.180505370408474,4.525841830564872,-0.6522281518727411,1.2974376955657085,10.499138876983078,-1.933289403920221,0.32257793679968216,8.773356130287087,5.415536442339482,-0.07150820249934942,-1.4995295518176068,6.071307679277781,-2.0163712659395028,4.968077671898314,-2.9199198530584485,-0.05217345117964867,3.789573057019245,0.5323638019784032,False,c3,3,"DonationInterface tests the referrer to block certain (don't list here) URL patterns which basically guarantee that the transaction is fraud. Keep that test, but never log or store the referrer.",114148,12,Medium,False
-1.909469848715879,9.073830959799462,-0.82132938304518,-2.8728453461442975,-1.165429164296727,-2.653826980626607,3.307486190634118,-2.3302505159851608,0.8008986681878008,1.4981761224900012,3.2888828859843176,0.6285235521504475,-0.2690374351036473,-0.08971469767181528,0.45384574673992706,0.04874383267746907,-0.12464071377358477,0.013181114721457554,False,c3,3,"Currently (intrudced with [[ https://gerrit.wikimedia.org/r/#/c/240306/3 | this change ]]), ConfirmEdit uses a hardcoded tabindex for it's CAPTCHA field on Special:UserLogin (8). It would be better to replace this with a generic or self counting tabIndex, so we don't need to adjust it, whenever there are new fields added to the Login form (e.g. by core itself or other extensions).",113866,12,Medium,False
-3.4203118820857563,5.181528251209848,7.021583619299967,-6.659864569790228,9.772909639659764,-6.064010125076116,5.979293168077121,-5.505798490776233,-1.7979095593505818,2.5311457679719194,4.947010645865994,-2.8749218776675667,0.26907494575876845,-1.3253498848286758,2.4608014538246534,-0.33498366143175895,2.3880224186172914,-2.0456878757864034,False,c3,3,"I have recently created a nova instance few minutes ago, but I can't login into it. It said I was denied because of the wrong public key.
The target instance is https://wikitech.wikimedia.org/wiki/Nova_Resource:Vm-test1.nginx.eqiad.wmflabs.
Here's the full log: http://pastebin.com/4D6ZbTA2",113451,11,Medium,False
-4.16367083965954,9.54609228203585,2.483896259531459,-0.918136246515735,2.0259203119197498,0.6179724937965481,-1.4808346963841768,4.615861431372693,4.5757629021368516,-2.0755780334928495,-1.6513277940413815,-2.7844604591973825,-0.2571107237609018,-0.5207548608293786,-0.9991270117567055,-1.63364178342629,-1.0362383585639425,4.651561808766071,False,c3,3,Authenticating via the API to satisfy test preconditions should be more reliable and faster than driving the browser. It also has the added benefit of not exposing credentials in the Selenium logs (see {T89353}).,112908,11,Medium,True
-7.054440634337602,4.444843157000477,2.6777059346583947,0.1511099384611514,2.8319092004387416,-3.382563501679684,2.1604906481456956,1.241938346915357,1.7209728193922322,4.512921370202026,-0.7087804917866505,2.0591543728517356,-2.327425352649179,3.9862038188468887,-1.2293188667486161,0.02465047214525201,0.8822813364030406,-1.869449163740784,False,c3,3,"Certain errors (unhandled exceptions, I guess) don't result in the usual WMF error page. See the description of T110878:
> What is interesting is that on WMF sites, this doesn't show the usual ""Wikimedia Foundation error"" page, but instead shows a quasi-plain text response of a kind that I have never seen before: https://www.mediawiki.org/wiki/Special:WhatLinksHere/Media:Wiki.png The HTML source of the returned page is exactly the following:
> ```MediaWiki internal error.<br />
><br />
>Exception caught inside exception handler.<br />
><br />
>Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br />```
This error is unhelpful to non-developers, because it uses highly technical jargon like ""exception caught inside exception handler"", and doesn't tell users where to report the error. It doesn't even show the skin interface, which may make some users worry that they have ""broken the site""!",112845,11,Medium,False
-9.182879404671455,10.615837331487405,-2.5581498916431897,-3.940557525751216,3.9902321891092867,-4.3511928815564405,3.1574333231384193,-3.302320377083509,4.857666828417183,0.5121257029947239,2.713070901321641,-1.0462161325457222,-0.32777299249380576,1.696665697531036,-0.2923368311144081,1.3078056652568826,-0.8850030634570852,-1.1647636777290438,False,c3,3,"We have support for using WPT script language today so we can login a user (or do whatever funky things we want). However right now they hold the login/passwords in the files and that will not be so good since we want to keep the version controlled in Git.
Lets see if we can find a standard (easy) solution to just add whatever placeholder we want at inject the values. ",112733,10,Medium,True
-0.3990838341760514,16.83202344604663,4.634772429749283,-5.18947355612886,-6.7765421399609735,-3.070382083721558,-0.2015117496974712,-2.852313943920991,-3.0152622564082776,1.4262391185485876,-2.0153995452518365,-1.859757791342695,-0.599002229642827,-1.548268509351575,-0.44048135635627794,-0.07050231137990892,0.7776985171909436,0.8158404612885153,False,c3,3,"If I log in using this link (https://www.mediawiki.org/w/index.php?title=Special:UserLogin&returnto=Special:OAuth/authorize&returntoquery=oauth_token%3Df97d76d6ec67bde6719952217d5ab80e%26oauth_consumer_key%3Dd5aa23a6b7a6d61e21ba1bb725c212fe) on my iPad mini to log in and authorise the Wikidata Game on toollabs access to my account (Vidar?) I'm taken to this site (screenshot below; https://m.mediawiki.org/wiki/Special:CentralLogin/complete?token=39880826259b573205f3c40ad7ae8570) after logging in, instead of the ""Allow-dialog"" which is visable on desktop.
{F2608859}",112730,10,Medium,False
-11.696155969577017,10.266870951300863,3.321283254800665,0.8713011533025306,3.028965480638167,-0.8890185335924683,2.3045994654093347,4.054686070360767,-5.808490392212967,0.7653772771223508,-1.9802382761458517,2.648126224325197,-1.1115227891585784,0.8140157599393545,-1.2475964685056615,-0.1656599117040441,0.917142000680877,-1.9324816218883347,False,c3,3,"Moving comments from now closed T99213 as this is really another ticket.
So the reason that keys don't get deleted from salt via this script when the instance is deleted is that (some of) them stay around in ldap. Is that intentional? Example: https://wikitech.wikimedia.org/wiki/Nova_Resource:Kilotest115.testlabs.eqiad.wmflabs
Additionally, old-style keys without the project name don't get removed by the script because that hostname is in the ""associated domain"" field and hence gets found during an ldap lookup. Do we want that?",112524,10,Medium,False
-9.64889186800531,3.5414096096305485,-5.698861226527844,-3.377249727789682,-0.8723230335501106,-3.483819093267617,2.142382605195233,-2.192866962621087,-1.2894857384957559,0.048491181668855354,3.5222230086837016,-1.7724985279573429,0.5742649172877985,-1.959697423859938,-0.7174445567681946,-0.7327058418625632,0.1714268937290484,-1.5421258103250524,False,c3,3,"1. Our current GlobalSign certs are generally configured with a single individual's email address to notify us on expiry.
2. Even if that's fixed, we shouldn't be relying on them to notify us. We should have our own tracking.
We have check_sslxNN in icinga which is checking at least the critical unified cert, which (in addition to other things) tracks cert expiry, but we haven't actually extended that kind of checking to every cert we're using (notably, we missed the impending loss of wmfusercontent.org). We have several smaller certs like that, some of which are even hosted in 3rd party services as well. Should we monitor the 3rd parties in these cases as well?
It might make more sense if we had some generic system in place for tracking long-term expiration events in general, so that we could enter every cert we purchase into that system when it's purchased. Such a system could be useful for other purposes as well (warranties, contracts, etc?). Is there an existing thing like this available already?",112521,10,Medium,False
39.38515394993278,-6.066707706884207,84.7908938050608,-18.949774708856445,18.928825344226492,-22.855168548490102,9.2907775944601,26.447799423519378,-2.9400135422638423,-0.7563481888859265,-3.9829250310201827,-17.04473771631562,-8.202817880602897,2.075279468809917,5.620734678804628,-2.902412725030023,-3.8544567658711397,5.122821892792495,False,c3,3,Mostly https://www.percona.com/doc/percona-monitoring-plugins/1.1/nagios/pmp-check-mysql-processlist.html#pmp-check-mysql-processlist,112473,10,Medium,False
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c3,3,nan,112436,10,Medium,True
1.3021556983621125,4.106998813972325,-0.193510550789469,-8.307847301745594,4.419080763991424,-9.287516269426558,3.999732525148766,0.9297615355757244,-2.5756660894312944,-2.429664334534672,0.005216858696619031,4.105181495190753,-2.7690846245056226,-1.7601827216743762,3.8438472670436967,2.9560310802993475,0.551633003495444,-0.49278873679871427,False,c3,3,"MariaDB replication flows are currently not encrypted. They should be, as sometimes they cross datacenter boundaries. I think [[ https://dev.mysql.com/doc/refman/5.1/en/replication-solutions-ssl.html | TLS is supported by MySQL/MariaDB ]] and it would probably be the easiest way forward for this.",111654,9,Medium,False
-7.748832378197845,3.9816294169510584,11.088834139038589,5.640350061882524,11.07597282718954,-12.247060685651316,2.251013951493367,6.15044029843335,8.99123267875193,0.5510682249843857,-0.8413900521870619,1.7098130651891073,-2.4175612908955806,2.286793552388138,1.7801640426887255,2.3144185270815747,2.489555515236943,-1.662769746327817,False,c3,3,See parent task and T110431#1604967. Might well be a no-op now that it doesn't replace the login form.,111483,9,Medium,False
-12.214264938458065,19.08497854530183,6.3948188491124505,2.8667970112672725,-13.866444195318005,0.24372967547520896,-0.2461485014882987,-2.0993633439135633,7.768938470033097,0.21590611238959134,-0.4413985290400797,3.3789540828015348,-0.580339291181363,3.2228598138971183,-2.206611168784719,-3.818547896909252,0.1504021897472687,-3.543558962145498,False,c3,3,Review login / signup designs by some major sites / frameworks so that we have a use case list of sorts by which to judge solutions to T110278.,111255,8,Medium,False
-2.9098345683882054,5.547355028716584,6.096945996417887,7.9239053879960455,5.916550464609989,-3.4265173819985177,0.23572808890230768,-0.7281843159269369,-1.0743533171535593,-2.840986742413345,-2.551667065003633,1.1627683154679709,-0.5368451325024814,-2.4565012371425774,-0.21183518209368657,-1.5090400545860758,0.37620208633769026,0.04988056516986128,False,c3,3,"Getting this from cronjobs today, as we've expanded the pool of cache cluster machines which are fetching the Zero-rating JSON data. Can a limit be increased substantially somewhere?
```
Exception: API login phase2 gave result Throttled, expected ""Success""
```",111045,8,Medium,False
8.80956031684621,3.670476478660511,11.604834270831926,1.2859605634316376,0.9863898329494094,6.964483674996031,-1.608142336727152,-0.3853486687765343,1.4206346710853615,1.9701436243402233,3.4902431841241506,-1.858001258825274,3.11068677657257,-2.093166292665702,-2.6052992962964834,-2.0576228271554324,0.40702850426911086,0.34147294258649086,False,c3,3,"URLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error:
```
Original exception: [2e097b64] /wiki/index.php/Special:WhatLinksHere/Media:Shellfish.jpg MWException from line 56 of C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php: MWNamespace::getTalk does not make any sense for given namespace -2
Backtrace:
#0 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php(109): MWNamespace::isMethodValidFor(integer, string)
#1 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\Title.php(1332): MWNamespace::getTalk(integer)
#2 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(247): Title->getTalkPage()
#3 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(172): Skin->preloadExistence()
#4 C:\Users\Alan\Documents\Programming\MediaWiki\Vector\SkinVector.php(47): Skin->initPage(OutputPage)
#5 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\SkinTemplate.php(233): SkinVector->initPage(OutputPage)
#6 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\OutputPage.php(2318): SkinTemplate->outputPage()
#7 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(685): OutputPage->output()
#8 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(474): MediaWiki->main()
#9 C:\Users\Alan\Documents\Programming\MediaWiki\core\index.php(41): MediaWiki->run()
#10 {main}
```
Was fixed in rSVN103450 (November 2011) but has regressed.
What is interesting is that on WMF sites, this doesn't show the usual ""Wikimedia Foundation error"" page, but instead shows a quasi-plain text response of a kind that I have never seen before: https://www.mediawiki.org/wiki/Special:WhatLinksHere/Media:Wiki.png The HTML source of the returned page is exactly the following:
```
MediaWiki internal error.<br />
<br />
Exception caught inside exception handler.<br />
<br />
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br />
```",110878,8,Medium,True
3.6885218510515094,0.4718483912772182,3.2638211660618097,4.935005911593845,-1.3773997263349578,1.4733952149639669,4.17962589344956,3.017899524999732,-6.408058496361453,3.1339996595902013,9.41712006394224,3.1605744046131496,0.18721156431764108,-2.9539408560989084,-0.8151365638159973,-0.5123569953368187,1.7735776284656886,2.8409361020263066,False,c3,3,"This affects page parses and some special pages. Requiring the master DB just for parsing is bad for HA and blocks active/active multi-DC use.
```
[GET] Expectation (masterConns <= 0) by MediaWiki::main not met:
[connect to 10.64.32.28 (wikidatawiki)]
TransactionProfiler.php line 307 calls wfBacktrace()
TransactionProfiler.php line 146 calls TransactionProfiler->reportExpectationViolated()
LoadBalancer.php line 545 calls TransactionProfiler->recordConnection()
DBAccessBase.php line 61 calls LoadBalancer->getConnection()
WikiPageEntityMetaDataLookup.php line 161 calls DBAccessBase->getConnection()
WikiPageEntityMetaDataLookup.php line 70 calls Wikibase\Lib\Store\Sql\WikiPageEntityMetaDataLookup->selectRevisionInformationMultiple()
PrefetchingWikiPageEntityMetaDataAccessor.php line 148 calls Wikibase\Lib\Store\Sql\WikiPageEntityMetaDataLookup->loadRevisionInformation()
WikiPageEntityRevisionLookup.php line 78 calls Wikibase\Lib\Store\Sql\PrefetchingWikiPageEntityMetaDataAccessor->loadRevisionInformation()
SpecialWikibaseRepoPage.php line 163 calls Wikibase\Lib\Store\WikiPageEntityRevisionLookup->getEntityRevision()
SpecialModifyEntity.php line 127 calls Wikibase\Repo\Specials\SpecialWikibaseRepoPage->loadEntity()
SpecialSetSiteLink.php line 103 calls Wikibase\Repo\Specials\SpecialModifyEntity->prepareArguments()
SpecialModifyEntity.php line 76 calls Wikibase\Repo\Specials\SpecialSetSiteLink->prepareArguments()
SpecialPage.php line 384 calls Wikibase\Repo\Specials\SpecialModifyEntity->execute()
SpecialPageFactory.php line 553 calls SpecialPage->run()
MediaWiki.php line 249 calls SpecialPageFactory::executePath()
MediaWiki.php line 683 calls MediaWiki->performRequest()
MediaWiki.php line 474 calls MediaWiki->main()
index.php line 41 calls MediaWiki->run()
index.php line 3 calls include()
```
```
Expectation (masterConns <= 0) by MediaWiki::main not met:
[connect to 10.64.16.144 (wikidatawiki)]
TransactionProfiler.php line 311 calls wfBacktrace()
TransactionProfiler.php line 146 calls TransactionProfiler->reportExpectationViolated()
LoadBalancer.php line 576 calls TransactionProfiler->recordConnection()
DBAccessBase.php line 61 calls LoadBalancer->getConnection()
WikiPageEntityMetaDataLookup.php line 160 calls DBAccessBase->getConnection()
WikiPageEntityMetaDataLookup.php line 69 calls Wikibase\Lib\Store\Sql\WikiPageEntityMetaDataLookup->selectRevisionInformationMultiple()
PrefetchingWikiPageEntityMetaDataAccessor.php line 193 calls Wikibase\Lib\Store\Sql\WikiPageEntityMetaDataLookup->loadRevisionInformation()
PrefetchingWikiPageEntityMetaDataAccessor.php line 162 calls Wikibase\Lib\Store\Sql\PrefetchingWikiPageEntityMetaDataAccessor->doFetch()
WikiPageEntityRevisionLookup.php line 81 calls Wikibase\Lib\Store\Sql\PrefetchingWikiPageEntityMetaDataAccessor->loadRevisionInformation()
CachingEntityRevisionLookup.php line 149 calls Wikibase\Lib\Store\WikiPageEntityRevisionLookup->getEntityRevision()
CachingEntityRevisionLookup.php line 132 calls Wikibase\Lib\Store\CachingEntityRevisionLookup->fetchEntityRevision()
CachingEntityRevisionLookup.php line 149 calls Wikibase\Lib\Store\CachingEntityRevisionLookup->getEntityRevision()
CachingEntityRevisionLookup.php line 132 calls Wikibase\Lib\Store\CachingEntityRevisionLookup->fetchEntityRevision()
RevisionBasedEntityLookup.php line 44 calls Wikibase\Lib\Store\CachingEntityRevisionLookup->getEntityRevision()
RedirectResolvingEntityLookup.php line 51 calls Wikibase\Lib\Store\RevisionBasedEntityLookup->getEntity()
EntityRetrievingTermLookup.php line 131 calls Wikibase\DataModel\Services\Lookup\RedirectResolvingEntityLookup->getEntity()
EntityRetrievingTermLookup.php line 116 calls Wikibase\DataModel\Services\Lookup\EntityRetrievingTermLookup->fetchFingerprint()
EntityRetrievingTermLookup.php line 64 calls Wikibase\DataModel\Services\Lookup\EntityRetrievingTermLookup->getFingerprint()
UsageTrackingTermLookup.php line 64 calls Wikibase\DataModel\Services\Lookup\EntityRetrievingTermLookup->getLabels()
LanguageFallbackLabelDescriptionLookup.php line 55 calls Wikibase\Client\Usage\UsageTrackingTermLookup->getLabels()
WikibaseLuaBindings.php line 138 calls Wikibase\Lib\Store\LanguageFallbackLabelDescriptionLookup->getLabel()
Scribunto_LuaWikibaseLibrary.php line 364 calls Wikibase\Client\DataAccess\Scribunto\WikibaseLuaBindings->getLabel()
Engine.php line 407 calls Wikibase\Client\DataAccess\Scribunto\Scribunto_LuaWikibaseLibrary->getLabel()
- line - calls Scribunto_LuaSandboxCallback->__call()
Engine.php line 319 calls LuaSandboxFunction->call()
LuaCommon.php line 243 calls Scribunto_LuaSandboxInterpreter->callFunction()
LuaCommon.php line 887 calls Scribunto_LuaEngine->executeModule()
Hooks.php line 121 calls Scribunto_LuaModule->invoke()
Parser.php line 3347 calls ScribuntoHooks::invokeHook()
Parser.php line 3082 calls Parser->callParserFunction()
Preprocessor_Hash.php line 1075 calls Parser->braceSubstitution()
Parser.php line 3224 calls PPFrame_Hash->expand()
Preprocessor_Hash.php line 1075 calls Parser->braceSubstitution()
Parser.php line 2896 calls PPFrame_Hash->expand()
Parser.php line 1259 calls Parser->replaceVariables()
Parser.php line 439 calls Parser->internalParse()
WikitextContent.php line 331 calls Parser->parse()
AbstractContent.php line 497 calls WikitextContent->fillParserOutput()
PoolWorkArticleView.php line 140 calls AbstractContent->getParserOutput()
PoolCounterWork.php line 123 calls PoolWorkArticleView->doWork()
Article.php line 666 calls PoolCounterWork->execute()
ViewAction.php line 44 calls Article->view()
MediaWiki.php line 504 calls ViewAction->show()
MediaWiki.php line 288 calls MediaWiki->performAction()
MediaWiki.php line 746 calls MediaWiki->performRequest()
MediaWiki.php line 520 calls MediaWiki->main()
index.php line 43 calls MediaWiki->run()
index.php line 3 calls include()
```
Entries in kibana are found via <<+channel:DBPerformance +message:*WikiPageEntityMetaDataLookup*>>",110399,7,Medium,False
8.533256080444064,14.43827660333124,0.6107139199510776,-3.8533629231436426,-17.1986490454968,1.182730708525032,-3.9752495840129023,-0.1292915906732554,-5.311891654639221,-2.8710336267832326,-0.7702591930539961,-3.033339996443066,-0.8714697731470933,-2.827802612798716,-1.1058966768380278,6.383787658628455,-1.9020555009608828,-1.123923430039174,False,c3,3,"I run ""pwb.py login -all"", and everything seems ok:
>>pwb.py login -all
Password for user MalafayaBot on wiktionary:el (no characters will be shown)
Logging in to wiktionary:el as MalafayaBot
Logged in on wiktionary:el as MalafayaBot.
Logged in on wiktionary:en as MalafayaBot.
Logged in on wiktionary:zh as MalafayaBot.
Logged in on wiktionary:ca as MalafayaBot.
Logged in on wiktionary:vo as MalafayaBot.
Logged in on wiktionary:io as MalafayaBot.
Logged in on wiktionary:ia as MalafayaBot.
Logged in on wiktionary:gl as MalafayaBot.
Logged in on wiktionary:es as MalafayaBot.
Logged in on wiktionary:az as MalafayaBot.
Logged in on wiktionary:nl as MalafayaBot.
Logged in on wiktionary:nn as MalafayaBot.
Logged in on wiktionary:no as MalafayaBot.
Logged in on wiktionary:tr as MalafayaBot.
Logged in on wiktionary:li as MalafayaBot.
Logged in on wiktionary:lt as MalafayaBot.
Logged in on wiktionary:vec as MalafayaBot.
Logged in on wiktionary:ro as MalafayaBot.
Logged in on wiktionary:is as MalafayaBot.
Logged in on wiktionary:fr as MalafayaBot.
Logged in on wiktionary:bg as MalafayaBot.
Logged in on wiktionary:uk as MalafayaBot.
Logged in on wiktionary:de as MalafayaBot.
Logged in on wiktionary:mg as MalafayaBot.
Logged in on wiktionary:da as MalafayaBot.
Logged in on wiktionary:br as MalafayaBot.
Logged in on wiktionary:bs as MalafayaBot.
Logged in on wiktionary:fi as MalafayaBot.
Logged in on wiktionary:hu as MalafayaBot.
Logged in on wiktionary:ka as MalafayaBot.
Logged in on wiktionary:pt as MalafayaBot.
Logged in on wiktionary:oc as MalafayaBot.
Logged in on wiktionary:sv as MalafayaBot.
Logged in on wiktionary:ku as MalafayaBot.
Logged in on wiktionary:nds as MalafayaBot.
First odd thing: file pywikibot.lwp has been changed but it's contents is simply one line:
#LWP-Cookies-2.0
I then run interwiki for example:
>>pwb.py interwiki pt:Categoria:Arquitetura
Password for user MalafayaBot on wiktionary:pt (no characters will be shown):
Logging in to wiktionary:pt as MalafayaBot
Retrieving 1 pages from wiktionary:pt.
[[pt:Categoria:Arquitetura]]: [[pt:Categoria:Arquitetura]] gives new interwiki [
[ast:Categoría:Arquitectura]]
[[pt:Categoria:Arquitetura]]: [[pt:Categoria:Arquitetura]] gives new interwiki [
[az:Kateqoriya:Memarlıq]]
[......]
Again, it asked for credentials. For each new run, I have to enter credentials.
If you intend to reproduce this issue, it's probably best to delete your pywikibot.lwp file first.",110354,7,Medium,True
-2.814746905151327,9.368668756976536,-0.8738668174891089,-9.932803094993005,-1.8761929113435476,-2.596532052490536,3.1428467249910996,6.867163631636113,4.799780387197811,2.329873091955802,3.911700609650962,-3.8084818073065634,0.9454460250890069,-1.8765964695537218,2.5933938110946704,1.9300393762447556,-2.182709450362934,1.7262582130130923,False,c3,3,"This should likely be redone as a PrimaryAuthenticationProvider, where it can now integrate with Special:UserLogin instead of having to do its own special page and such.
",110294,7,Medium,False
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c3,3,nan,110277,7,Medium,False
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c3,3,nan,110276,7,Medium,False
4.3253572496829555,3.2649694668023166,6.417536609245179,2.115916634094401,2.2125875970562734,-3.1481429528882447,-0.7276875603894561,5.690012395369962,1.9869595635315684,-2.681778165272105,-2.372773629785439,3.8983801275137644,0.6236410890030286,-4.048479561867907,1.8611272913681036,-1.6039373358530238,1.136134324519862,-1.9368917383085045,False,c3,3,"To be considered:
* (includes/http) `Http`, `MWHttpRequest`, `CurlHttpRequest`
* (libs) HttpAcceptParser, HttpAcceptNegotiator
* (libs) MultiHttpClient
* (libs) HttpStatus
----
This would mean that said library could be used by https://github.com/addwiki/mediawiki-api-base which is required by https://github.com/addwiki/wikibase-api.
https://github.com/addwiki/wikibase-api could then easily be used by the WikibaseClient potentially helping to resolve T48556
Not only that, but this code is also perfect for a library....",110022,7,Medium,
-14.399837861575872,15.867529166865921,3.1845964750153506,0.6268511662725973,-8.288730284190718,-3.1030530297398027,-2.4671720299061652,2.4096635631989716,6.12303489276842,-2.3342190554033833,-2.15171637043331,11.596269092366267,0.5162291158975805,0.0224463660841403,0.11361773232310224,-2.2525749976506084,-1.208570632413565,-2.6035698223754884,False,c3,3,"So to make https requests to etcd, you need access to the puppet ca client certificate, since that's the https certificate being used. However, since that is owned by root, this means you need to be root to make https calls to etcd. This should be relaxed to allow everyone to make calls to etcd...",110020,7,Medium,False
-3.4093582674786655,13.095194727992041,-0.4361442519234835,-5.304077606517656,-0.3003605392108229,-0.791019539623161,-1.3045216819805363,1.559473538967476,-2.57654936235647,2.8864874416704325,-1.2225599865270274,6.545921228846589,0.43471899375648526,-0.19613356582378838,-1.3173106264987053,3.951651363271763,1.0892806081510897,-0.6037067669444995,False,c3,3,"E.g. https://en.m.wikipedia.org/wiki/Special:Uploads/Jimbo_Wales : ""Please log in to view the uploads page."" There is no reason to require login for this, and I understand from @Jdlrobson that this behavior isn't intentional. Probably comes from https://en.m.wikipedia.org/wiki/Special:Uploads , which shows the user's own uploads and hence needs them to be logged in.",109894,7,Medium,False
-11.014392625799056,11.66391737180734,-0.6405924677912367,1.0573800200548185,-2.9216902072267663,-4.918353724879362,3.690146537432507,4.949315674780598,-1.7063545343695883,-1.3929161498373008,-1.4584532088217952,0.5619192576837944,-0.5569858591413315,0.7748295966597336,-0.829818243945283,0.2564322255898936,0.39897287879171106,2.269778737641464,False,c3,3,"When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",109737,7,Medium,True
-5.070456952175397,6.234475784521138,-1.3242715827829734,-1.564152290187383,-1.8610739026889371,0.7660553801740608,2.917688313376307,3.144017481725216,0.22495944551306224,1.258049790592242,3.1427180837241484,-1.4855262513365477,0.46361968169470513,-0.23808175964276757,0.1405774508681512,0.12374009184466106,0.6801976609776188,1.5049298711605974,False,c3,3,"We need the ability for varnish backends to make outbound HTTPS connections in at least two scenarios:
1) For tier-1 cross-DC applayer traffic (e.g. cp2001.codfw.wmnet -> appservers.svc.eqiad.wmnet) - we don't have any known other solution to secure this traffic on inter-DC links at this time.
2) For inter-tier varnish-be->varnish-be traffic: IPSec is currently protecting this, but HTTPS has the potential to be operationally-better and make the current IPSec deployment less-critical, or open us to ditching the current host-based IPSec and waiting on tunnels of some kind.
Known options for making this happen:
1) Deploy an stunnel configuration locally on the varnish machines.
- The idea here would be to deploy stunnel with a separately-configured tunnel instance for each defined varnish backend.
- Instead of simply backending to appservers.svc.eqiad.wmnet:80 today, it would backend to localhost:12345 (unique port assignment), which is an stunnel configured to connect to appservers.svc.eqiad.wmnet:443.
- There could be other alternatives similar to stunnel, but stunnel looks like a legit/default option here.
- Significant Con: Yet another piece of software in the request flow for reliability/debugging woes.
2) Patch varnish3 ourselves for outbound HTTPS
- Possibly using Amazon's s2n library, as it could be much simpler than using OpenSSL directly.
- Would deepen the amount of source-level customization we're doing with Varnish3 today, which is already a long-term problem for maintainability and tech debt.
- Patch would probably be significantly difficult. This is not lightweight patchwork. There are risks we could make varnish less stable, make a security-affecting mistake in the code, and/or make it much more difficult to continue merging in upstream 3.0.x fixes.
3) Upgrade to Varnish4, and then create our own custom director module for outbound HTTPS
- Varnish4 does this already in the commercial Plus variant, but not open source. We could do the same, as open source.
- It's sad to redundantly re-do the upstream closed-source work here, but as a module in varnish4 it would be significantly cleaner than hacking it into varnish3.
- Depends on Varnish4 upgrade, which is significantly difficult and off in the Future for now, and may not ever happen if we find an alternative first.
4) Upgrade to something non-Varnish that supports outbound TLS out of the box:
- e.g. ATS: T96853
- As with the above, this is neither near-term nor easy",109325,6,Medium,False
-5.949422751266065,6.831302485796055,-1.1664026479583356,1.5564650558216684,0.4696435482193315,2.0986239731804233,1.601487335706687,0.45944879983349707,-0.611389683068422,0.5159908443631078,2.153112673964815,-0.8135322994748695,0.11850023297891621,0.12288977208440333,-0.46658374170902217,-0.3014239115037993,0.9163552546479419,0.732636563000211,False,c3,3,"Essentially, this task is about making https://appservers.svc.eqiad.wmnet/ and similar work internally. Ideally we do this for all internal service endpoints eventually, but MediaWiki is the biggest target to go after for the initial work of sorting this out. Host: headers can still be used to make requests to e.g. en.wikipedia.org over these TLS connections, but the cert should match the hostname used for the TCP connection in this case, IMHO.
In certificate terms, we need to create keys and issue certs (signed by the internal WMF CA that we already trust) for the virtual service hostnames. Probably the first step there is to come up with a definitive list of which clusters need which service hostnames (e.g. should the same broad pool of mw* machines have a SAN cert that covers both appservers.svc and api.svc? etc).
There are two basic obvious approaches to configuring the TLS listener:
1) We could deploy the puppetized tlsproxy nginx configuration (with slight ammendments) as an inbound TLS proxy that talks to apache. The advantage here is simplicity of a known-good solution in configuration terms. The downside is it adds another layer to the overall request-processing stack, which reduces uptime and complicates debugging, etc.
2) We could configure the TLS listening part in the appservers' current apache instance. This is much better in terms of runtime/debugging complexity, but I'm not yet sure how difficult it would be to implement in apache terms (having TLS with a cert matching the virtual service hostname, which applies to all of the (~70?) VirtualHost declarations in the current apache-level configuration.
Eventually we'll want to use TLS Client Auth with this as well, but we could do that as a second step after the initial one-way auth. Even without client auth, we're gaining significant resistance to passive snooping.",109315,6,Medium,False
4.863169045107426,-12.927921783796853,9.312774066277111,4.310912976583843,0.3759474399554057,-5.495519209854509,-2.533477930167448,-1.8897944267464797,0.10285248645763562,-2.8525600651607266,-2.0462235367669326,0.24790889433554741,2.292168471265775,-4.078068617985466,-3.0954235032892576,0.23212211313224715,-0.7308760088513965,-1.219934679652385,False,c3,3,"```
2015-08-15 19:18:15 translatewiki.net translatewiki_net-bw_: [c1d4f49b]
/w/i.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Special:UserLogin&returntoquery=type%3Dsignup
ErrorException from line 1070 of /srv/mediawiki/tags/2015-08-15_15:50:02/includes/specials/SpecialUserlogin.php: PHP
Warning: Invalid operand type was used: Invalid type used as key
2015-08-15 19:18:15 translatewiki.net translatewiki_net-bw_: [2cefad9b]
/w/i.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Special:UserLogin&returntoquery=type%3Dsignup
ErrorException from line 1070 of /srv/mediawiki/tags/2015-08-15_15:50:02/includes/specials/SpecialUserlogin.php: PHP
Notice: Undefined index:
```",109193,6,Medium,True
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,True,c3,3,nan,109031,6,Medium,False
-1.4030330268735436,4.4884373234155674,-2.253319788655947,-3.230624932153548,-0.0465133622319136,-2.0468744741389635,1.3887917985825142,-0.12436020575635226,0.7211205609364264,-0.18366262084024232,2.4141967493980663,-0.8621063744663222,-0.5371777620702103,-0.30048709355338854,-0.5230514563914825,0.7839626123725177,0.9203126708324982,2.6961606077997615,False,c3,3,"[[ https://en.wikipedia.org/wiki/TCP_Fast_Open | TCP Fast Open ]] has the potential to further reduce latency for at least some TLS connections. With TLS there's also no idempotency concerns like there are for using it with plain HTTP, as the fastopen-sent data would just be the TLS ClientHello. Our current cache cluster kernels and nginx builds support it, requiring sysctl adjustments and an nginx config change. Various concerns/work that need addressing before trying to really enable it:
1. Is client-side adoption percentage high enough to matter yet? Right now probably fairly low, but growing. Linux+Chrom(e|ium) can do it by default on newer kernels, and Android 5 can do it. El Capitan Macs (Safari? Chrome?) may start trying it in the fall.
2. How do we appropriately tune the limit for the outstanding fastopen queue per socket? (in nginx terms, this is the `N` in the `fastopen=N` parameter). Too high has DoS implications both for us and as a potential reflector. Too low and we may miss legit TFO due to our high SYN concurrency.
3. Is LVS a factor here for TFO compatibility, and does it (or should it) pay attention to the cookies?
4. We'd need to synchronize the TFO cookie key across machines in a cluster and rotate them periodically, or rely on client source IP hashing and only periodically regenerate locally per-machine. This is somewhat similar to the issues with RFC5077 secrets but considerably less security-critical; leaking it opens us to easier DoS, but does not affect TLS security of legitimate client traffic. We'd need to generate a random key and distribute it securely and periodically, etc. Everything about this is dependent on answering the LVS question above too.",108827,5,Medium,False
2.3608257492016302,-2.512559181967527,-6.250807108327159,-14.236776279825122,12.038913753188952,-15.96310644593019,9.962859185106172,12.808296447781325,-1.1470569954523477,0.63091167346969,1.6368613131144154,-2.3196686983166988,-2.2168377990640664,3.8991154031239823,-2.5553681321676533,0.5985287061516484,-4.734233487134021,5.836419276212145,True,c3,3,"https://citoid.wikimedia.org/ works great, but unfortunately so does http://citoid.wikimedia.org/ when really it should redirect.",108632,5,Medium,False
-7.4255352800219345,9.185470397093614,0.7386842171342813,2.2875226556274733,-3.429553187780121,-0.7046211908995945,1.9495812836248758,1.3616926210238924,2.013928384493169,1.0805695390943786,1.8407455285925374,-1.0439345431536817,0.3908234119982521,0.5899027531196532,0.7851006897123263,-0.30586102146000327,1.4844167436137783,-0.044554755297501414,False,c3,3,"Eventually we'll want all HTTP traffic on internal networks converted to HTTPS. We should ideally be using client certificate auth with this access as well, so that link traffic injection into supposedly-private service endpoints isn't so easy.
The most critical cases are traffic that's currently crossing inter-datacenter WAN links, or will be soon. However, it's simpler and more-secure in the long run if we just aim to do this for everything regardless of the locality of the traffic sources.
Key cases to work on first:
1. Tier-2->Tier-1 varnish cache traffic - Currently secured by IPSec, but we could drop IPSec in favor of an HTTPS solution and keep things simpler and more standardized. This is also a relatively-easy target to work out a lot of implementation and puppetization issues before moving on to other cases.
2. Tier-1 -> *.svc.(codfw|eqiad).wmnet - We'll likely have the ability and desire to put user and cache-backhaul traffic through the codfw cache clusters well ahead of when we're ready for multi-DC at the application layer. This implies codfw cache clusters backending to eqiad service addresses. The IPSec solution currently used for inter-tier varnish traffic above doesn't work for this case, as the service traffic routes through LVS, but HTTPS would work fine here.
In certificate terms, we'll want to use a new local CA to issue certificates within wmnet. The idea would be to create SAN-based certs per cluster for the service hostnames offered by that cluster. For example, mw[0-9]+.eqiad.wmnet machines might share a cert with SAN elements for e.g. appservers.svc.eqiad.wmnet and api.svc.eqiad.wmnet, and the sca cluster machines might have SANs for citoid.svc.eqiad.wmnet, graphoid.svc.eqiad.wmnet, etc...
In case 1, the server-side HTTPS termination can be the same nginx instance used for production frontend traffic, with some additional configuration and/or listeners defined.
In case 2, the server-side HTTPS termination would probably be easiest with a separate inbound TLS proxy (probably a simple variant on the cache clusters' nginx tlsproxy puppet module), so that we don't have to integrate it with all of the server/alias stanzas in the apache configs for now.
In both cases, the primary (most important for the moment, anyways) client traffic source is the varnish instances on the cache clusters. These don't do outbound HTTPS natively, but I think we can address that by using a local proxy on each machine like [[ https://www.stunnel.org/ | STunnel ]]. For example, instead of varnish defining the appservers backend as direct access to appservers.svc.eqiad.wmnet:443, it would define it as connecting to localhost:12345, which is an stunnel daemon configured to connect to appservers.svc.eqiad.wmnet:443 for it.
Client cert auth would be based on per-machine certificates. e.g. cp1065.eqiad.wmnet would have a cert for its own hostname for the toubound stunnel proxy to use, and we'd need a local CA that the appservers trust for client certs. The easiest path for this would be to re-use the puppet machine certs and CA for this, but one issue there is that the last time we re-did the puppet cert infrastructure we inexplicably upgraded them to 4K RSA, which could be too much perf impact for this kind of scenario. 2K would have been better. If we're going to re-use puppet certs as client certs, it would be best to first to fix the 4K problem.",108580,5,Medium,False
-4.700047980462109,1.0150010877815347,3.085858499515286,-0.9910678939432873,5.6458077016675325,3.593167345377597,1.9197911114185873,2.8987146240974013,-12.57315666369736,-2.888361348998523,-1.238358597761638,16.249882876901555,1.959079117574178,-6.7509205064424505,2.0476647764064806,-2.314620842644995,2.7632610101772306,-5.24222402618345,False,c3,3,These have been obsoleted by https://gerrit.wikimedia.org/r/#/c/230034/ (which is deployed next week).,108386,5,Medium,True
3.8722965213345213,6.746965257939362,7.578639832558615,4.510896853430199,-1.8453752904577274,2.1572286258413653,2.2473677591343497,3.4797966131740155,-1.5104292357548024,2.126783316929755,6.006698616457374,-1.3742853391613634,-0.5013159533824743,0.8916752874776721,-0.8215022836374501,-0.5757874626747809,0.08442016577016243,2.1505164346107,False,c3,3,"There is a lot of mixed GET/POST back and forth among domains on login in a short time period. The sticky DC cookie will not work cross-domains easily. Options include:
a) Making login tokens and other sensitive cache/stash access use the BagOStuff READ_LATEST flag
b) Locking those tokens to use a unified BagOStuff config pointing to a single set of servers in one DC
c) Ugly VCL rules to treat CentralAuth login URLs like POST (not preferred)",108253,5,Medium,True
-4.268561452119956,1.188861949287995,-5.949957285150566,-0.3528749270748003,-3.1282858509542293,0.44651883571789086,0.4091917147170987,1.3441153284936354,1.1501777778665423,-1.3368605850147097,-0.23779298757923328,-2.1629804298251196,2.2601863582516106,0.4073018949282172,-1.3198461264522185,-0.960313805456843,0.9274480319479881,3.1767927149378528,False,c3,3,"Our current nginx config uses a separate HTTP/1.0 TCP connection for each request from nginx->varnish. Theses happen over the loopback interface so there's virtually zero latency impact from the handshakes, but it would be more efficient in general to use HTTP/1.1 keepalives, and reduce the bloat of TIME_WAIT sockets on the servers.
Typical socket states for nginx->varnish local connections currently (cp1065 has 32 worker threads, and each would have at most one connection established at any given moment, constantly breaking and re-making it):
```
root@cp1065:~# netstat -an|grep '10.64.0.102:80[ ]*10.64.0.102'|awk '{print $6}'|sort|uniq -c
32 ESTABLISHED
9 FIN_WAIT2
63688 TIME_WAIT
```
With keepalive patch manually applied (each of the 32 worker processes spawns parallel keepalive connections as necessary, with a maximum of 4x idle keepalive connections per process before it starts pruning them - so we'd expect 128 ESTABLISHED minimum at all times, and far fewer TIME_WAIT):
```
root@cp1065:~# netstat -an|grep '10.64.0.102:80[ ]*10.64.0.102'|awk '{print $6}'|sort|uniq -c
144 ESTABLISHED
2 FIN_WAIT2
2053 TIME_WAIT
```",107749,4,Medium,False
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c3,3,nan,107627,4,Medium,False
-7.408220513503254,1.7421847649713378,-2.73505261215438,2.2909821572809363,-4.929003800299117,-2.1746548513911854,-2.081310077827216,2.492597625564727,0.30045888610845206,0.7132583956799365,2.1266590929306806,-0.7386200702029505,-1.621950903139382,-0.3398502811789035,1.9057608772135346,-1.168231834485658,-1.2306409814068653,-1.2155668734777398,False,c3,3,"Instead of setting $wgSecureLogin=false on sites that are https only (e.g., T103021 for the WMF), make the option more efficient so that it can be maintained as a backup control in case http->https redirection at the pre-application layer is broken.
[X] Don't show user preference to ""use insecure connection"" for https-only sites - https://gerrit.wikimedia.org/r/#/c/217856/
[] Force all cookies to be set secure, reguardless of user preference, on https-only sites
[] Decrease the size of the forceHTTPS=1 cookie (iirc, facebook used ""_s=1"" when they converted to https) to minimize overhead",107604,4,Medium,False
-6.9410865050675135,7.46186750168949,-2.2188578006282214,5.597375517213745,-1.8834292197922922,1.994058052524916,1.0442706088129672,1.5524038765719808,-4.31816519400552,-0.49348447230951553,1.2699517149632435,4.351510706528236,2.0551196171229873,-1.752018365777456,-2.417675212386172,2.5044292611656727,4.415322714863375,1.7618629605365814,False,c3,3,"logstash100[1-3] has been re-imaged with jessie and nfs-common got installed, which starts rpc.statd. There's nothing in the package dependencies which would explain that (no reverse Recommends or Depends on nfs-common) and puppet only installs nfs-common for labstore and the dataset NFS servers, so this must be caused by something in tasksel or other parts of the d-i.",107412,4,Medium,False
13.578402099813818,-5.007347230546014,-0.9007600860994085,10.230574114515681,-0.8730100605235409,-5.7534206697616765,0.6725306302351584,-1.1713867015178563,-1.7746560021644204,-0.05048135780895535,0.26667295983232586,-0.08585395265935003,6.021481531269403,4.5478490888480625,3.3750650766629784,-0.27895825183113354,-0.010958747547367365,1.3016206094098977,False,c3,3,"Probably due to the thumb size < original size rule. Those should give HTTP 412 or something, and then the job can return ""true"" in run() for such cases, rather than logging and retrying two more times (and logging).
2015-07-23 08:31:09 mw1010 commonswiki runJobs ERROR: ThumbnailRender File:Silene_otites_002.JPG transformParams={""width"":""640""} (uuid=fbfbc971ef4745f39f4c1dae81c87570,timestamp=1437640260,QueuePartition=rdb1) t=8620 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:08 mw1004 commonswiki runJobs ERROR: ThumbnailRender File:Capitaine_de_vaisseau-IMG_9252.JPG transformParams={""width"":""1280""} (uuid=e10f0d79ba4e4e6d820d0ccc4a162c66,timestamp=1437640319,QueuePartition=rdb1) t=8224 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:08 mw1007 commonswiki runJobs ERROR: ThumbnailRender File:Capitaine_de_vaisseau-IMG_9252.JPG transformParams={""width"":""800""} (uuid=b01d5e67754b40c2bca5149b4ff10470,timestamp=1437640319,QueuePartition=rdb1) t=8227 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:08 mw1004 commonswiki runJobs ERROR: ThumbnailRender File:Capitaine_de_vaisseau-IMG_9252.JPG transformParams={""width"":""1024""} (uuid=cdd28d7220054f02a9bd1138f65865ab,timestamp=1437640319,QueuePartition=rdb1) t=8257 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:08 mw1002 commonswiki runJobs ERROR: ThumbnailRender File:Capitaine_de_vaisseau-IMG_9252.JPG transformParams={""width"":""320""} (uuid=7f0ca2623ed24392ad8ca7c1ee8b1a96,timestamp=1437640319,QueuePartition=rdb1) t=8184 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:08 mw1002 commonswiki runJobs ERROR: ThumbnailRender File:Capitaine_de_vaisseau-IMG_9252.JPG transformParams={""width"":""640""} (uuid=5ccea45bd1254be0a30d2c2072a07d9f,timestamp=1437640319,QueuePartition=rdb1) t=8199 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:42 mw1002 commonswiki runJobs ERROR: ThumbnailRender File:Silene_otites_003.JPG transformParams={""width"":""800""} (uuid=eeec2978013c4ce588e53ab76a8eb425,timestamp=1437640353,QueuePartition=rdb2) t=8156 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:42 mw1002 commonswiki runJobs ERROR: ThumbnailRender File:Silene_otites_003.JPG transformParams={""width"":""640""} (uuid=a9975fc34238417eaf9620758c433f0f,timestamp=1437640353,QueuePartition=rdb2) t=8203 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:32:42 mw1001 commonswiki runJobs ERROR: ThumbnailRender File:Silene_otites_003.JPG transformParams={""width"":""320""} (uuid=36dceb3042354b7aa0605367e9092190,timestamp=1437640353,QueuePartition=rdb2) t=8232 error=ThumbnailRenderJob::run: incorrect HTTP status 500
2015-07-23 08:33:18 mw1016 commonswiki runJobs ERROR: ThumbnailRender File:Contre-amiral-IMG_9154.JPG transformParams={""width"":""2560""} (uuid=0e65942249454dadae5888e6cfb9dd38,timestamp=1437640389,QueuePartition=rdb1) t=8219 error=ThumbnailRenderJob::run: incorrect HTTP status 500",106740,3,Medium,False
-8.162394704190902,13.72444227917335,5.314854107852025,-0.7291482147244002,-4.870704538255696,-1.8357152280768563,-0.4346594217419941,-2.069163876226053,6.045895575269509,0.5684431078271475,1.7120020860823826,3.103829764535302,1.2700361938697502,-0.6976342300026426,-0.1869525918249746,-1.2190162318359556,0.3177808819334238,2.765140319433068,False,c3,3,Hi @Ashley could you add support for loging by hovering over the login button like you can http://social-tools.wmflabs.org/wiki/Main_Page?useskin=bluesky here. That skin looks really nice. It should be the default on Wikimedia. But I would like to allow users to hover over the login button and login. Same goes for create account there should be a button that loads up the create form without having to leave page.,106688,3,Medium,
-1.562833477526674,2.143569758450692,-1.4010352561269226,-2.524960055086769,-2.3347508515041078,-5.4737821758294825,-1.7941426240334062,0.8692255548093887,-1.221688043484983,-2.351923607678379,3.51238646765534,-1.5532360831866234,-2.214413536207428,-0.4520612354681832,-1.4873305134350225,-1.815506678820634,-0.11141846372713182,-0.4649874898981585,False,c3,3,"Now that we've [[ https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/ | switched production to HTTPS-only ]], it would be great if our blog followed suit.
Initially it made sense to keep the blog on HTTP, so that the message could get through even to users that were having issues with HTTPS; however, now sufficient time has passed and we should actually move this forward.
The blog already works fine over HTTPS, with a certificate of our own.
Switching to HTTPS-only involves asking Automattic (our blog hoster) to do the following:
[x] Make sure embedded resources to http:// URLs within the page are https (I don't currently see any, but someone should double-check)
[x] Switch <link rel=canonical> to HTTPS; right now it's forced to http://, which means that search engines always point to our blog over HTTP. Same but less important for <link rel=shortlink>.
[x] Permanently redirect (301) all URLs (/.*) to their HTTPS equivalent.
[x] Set Strict-Transport-Security header to `max-age=31536000; includeSubDomains; preload`",105905,1,Medium,False
-3.5477117718964073,5.2656773191948645,-1.0910596657474834,-3.277629293594733,-3.0267812123082,-0.9901707538942541,-0.5800448711397435,-0.5316080026482195,2.4279322507685563,-0.2194066302757971,2.5758568000186313,-0.5391932282344096,-0.14702490066154628,-0.46004922106512414,-0.5170115394572461,1.539771770709329,2.102631928424846,4.1044421703219625,False,c3,3,"Per T102566#1449713 and beyond, and T103043#1381527 and the reply...our current behavior of `$followRedirects` in MWHttpRequest and children is problematic and renders it basically useless. It's an all-or-none proposition, with no sorts of verifications along the way to make sure we're doing safe things.
We should do the following:
# Always allow redirects from HTTP -> HTTPS versions of the same URL (or domain?)
# Never allow redirects from HTTPS -> HTTP unless the URL (or domain?) matches.
# Remove the flag for enabling/disabling redirection after (1) and (2) are done.
Allowing us to always redirect in safe cases and never redirect in unsafe cases allows this to behave in a way that will actually make it useful and help things like HTTP -> HTTPS transitions much easier on our users.",105765,1,Medium,
-6.895833996497421,18.30674802771263,0.18493579016398343,-4.1050551463212575,-5.86208079475319,0.03276260246663987,2.438702746254097,-3.7608410045000595,-2.5527919320755013,-1.2679935797647897,-0.4011064233323616,1.9861430065043824,-0.41740844728304705,-0.13154137253541087,-0.45598005993944835,-0.9428388311822327,0.25029029820129356,-0.06943585311853395,False,c3,3,"Wes has asked me to work on some basic data analysis around the information coming out of our web request logs around Iran. Specifically, we want to understand why there was a dramatic drop in pageviews after the HTTPS switchover, and whether this is replicated in search events.
https://github.com/wikimedia-research/ayatollahsong",105512,1,Medium,True
2.4725431520242975,-6.0678555784663075,5.8046133721036846,-5.758386177183186,-9.852405208363583,4.350808972127069,-2.6816773561745846,-1.9413953632422567,-1.7705055806549312,-4.456982989788452,-6.287822663227483,-2.692084027185814,-2.388199456773944,-1.4035536491626908,0.1841283118806647,6.011224201049419,-1.2577644021417282,-0.45085321093933595,False,c3,3,"Spotted in production:
```
1 Warning: API call failed to login with token: status=There was a problem during the HTTP request: 503 Service Unavailable, query={""action"":""login"",""lgname"":""zerowiki"",""lgpassword"":""***"",""lgtoken"":
""e0cd4e78e51dbac91bf9dc19b8d07315""} [Called from JsonConfig\JCUtils::warn in /srv/mediawiki/php-1.26wmf12/extensions/JsonConfig/includes/JCUtils.php at line 50] in /srv/mediawiki/php-1.26wmf12/includes/de
bug/MWDebug.php on line 300
```",105370,1,Medium,False
7.94805413097715,3.6247081668847123,-7.490252620079696,3.3229765104000437,-5.9786092901081,-4.454327402969711,-3.9320882190930093,2.3139362092631517,-3.1746758464841847,-0.48213867243639985,4.440256184765227,-0.5497175787725875,-2.3410483940315645,1.5768864032541376,-0.2904048963302399,-0.6374621768336899,-0.9919531923191687,-0.07945135189328645,False,c3,3,"Basically, we need:
[x] maps cache cluster in eqiad
- standard 2layer setup like ""upload"", with fresh/minimal VCL
- can reuse the recently decommed cp104[34] machines for now
- backend is kartotherian.svc.codfw.wmnet:4000 (LVS service)
[x] maps.wikimedia.org LVS/DNS setup into new IP for maps cache cluster
",105076,0,Medium,True
-3.0801166123651127,6.195974947211404,-3.216881917588031,-5.113497768010562,-3.650428331064211,-5.756595731044887,1.9106830658044487,-1.7851692810111857,-2.959765570186627,-1.6230207044852611,-0.018429950565980846,0.861761696455474,0.19384034588318855,-1.3682130934391443,-0.6277662784045184,0.12993711721044787,-0.11796200584226124,-0.37940799150811144,False,c3,3,"In addition to `$lang.m.wikipedia.org` and `$lang.zero.wikipedia.org` (which are fine!), we also have `$lang.wap.wikipedia.org` and `$lang.mobile.wikipedia.org`. These latter two seem to be apache-level rewrites (rather than redirects) to `$lang.m.wikipedia.org` at https://github.com/wikimedia/operations-puppet/blob/production/modules/mediawiki/files/apache/sites/redirects/redirects.dat#L484 . From my desktop browser they appear equivalent to `.m.`, but perhaps there are still hacks in place for WAP on special user-agents?
These subdomains are not compatible with our TLS certs, so it's a problem that blocks HSTS-preload for wikipedia.org indirectly. My understanding is they're intended to be deprecated going forward, in which case perhaps we can just hurry up plans for their demise?",104942,0,Medium,True
-6.662218875470854,5.823662673491832,-2.406173085156926,0.05176221576750062,-4.310290064014376,-5.6475605733086605,-2.414677028679368,6.376460380161612,-0.025266868573691315,8.520814710079643,-5.158648944231384,0.42859445864726475,-2.3654597848099073,-0.22462108962088312,3.076191229204011,0.2564869700165508,-3.045204611690699,-0.07358161065410074,False,c3,3,"This makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"".
""npm"", for example, is installed. Would be nice to have composer as well.",104789,0,Medium,False
1.9956565351771691,3.0677536750580607,-0.43096231450252276,0.14676265708324077,-0.5560562863418631,-1.3734243017624834,0.9128527509397735,-0.5629347705694763,-1.5313633379067717,-0.6085076182199867,2.106822267721238,0.3108967953142592,0.5954749859528738,-1.3588831129669252,-0.48817709399987397,-0.253666006400874,1.3628091360053765,-0.36370260860165904,False,c3,3,"Some of the information out there about where we are and where we're going is a bit disparate and lost in the noise of many separate Tasks and impending gerrit commits. This is an attempt to bring together a coherent view of the current state of things, the next upcoming steps, etc. If you know information that isn't here (missing Task refs, etc) please feel free to correct it! The Description here will evolve as we go, use comments to discuss, etc.
- **Definitions**
- Canonical domains: wikipedia.org, wikimedia.org, wiktionary.org, wikiquote.org, wikibooks.org, wikisource.org, wikinews.org, wikiversity.org, wikidata.org, wikivoyage.org, wikimediafoundation.org, mediawiki.org, wmfusercontent.org, w.wiki.
- Non-canonical domains: Anything not in the list above. These are generally redirect-only domains such as `wikimedia.ee`, `wikizpravy.cz`, `wikimediacommons.jp.net`, etc
- Traffic Clusters: These are the `text`, `upload`, and `misc` traffic clusters which do standardized TLS termination for the bulk of all our HTTP[S] traffic to all of our domainnames.
- One-off Services: These are individual internet-facing HTTP[S] services which are **not** terminated by one of the standard traffic clusters above and run their own independently-configured internet-facing server software (e.g. nginx or apache). They are in our control and hosted in our datacenters.
- Third-party: These are HTTPS[S] service hostnames in our canonical domains which are hosted by a 3rd-party service for us.
- **Current State of Affairs - HTTPS, Redirects, and HSTS**
- Our desired state is:
- Modern TLS (v1.2, FS/AEAD ciphers enabled, sane ordering, no publicly-known TLS flaws)
- HTTP: 301 redirect of GET/HEAD to HTTPS, 403 denial of other methods.
- HSTS with 1yr duration, preload, includeSub
- All canonical domains (not individual service hostnames) submitted to the Chromium preload lists
- Outstanding Exceptions:
- Non-canonical domains (all are currently serviced by our Traffic Clusters): No valid certificates. Task to move these to a separate service with LetsEncrypt certs: T133548
- Third-party: store.wikimedia.org HSTS issues - T128559
- ** Current State of Affairs - Crypto Compatibility vs Security Tradeoffs **
- Dashboard for negotiated ciphers: https://grafana.wikimedia.org/#/dashboard/db/tls-ciphers
- As a general rule, none of our HTTPS endpoints should support SSLv2 or SSLv3. I don't believe there are any exceptions to this today. The only client browser anyone cares much about which lacks TLSv1.0 (or higher) support and is blocked by this is IE6 on Windows XP (which, due to our redirects and lack of SSLv3 support, cannot access our HTTPS-redirected sites at all anymore).
- We maintain [[ https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/wmflib/lib/puppet/parser/functions/ssl_ciphersuite.rb | explicit ciphersuite lists in our puppet repo ]] that are intended to be shared by all TLS termination software for all cases. There are three choices a site/service can choose from at this time: strong, mid, and compat.
See that file for the evolving details",104681,0,Medium,False
-11.684159811412613,5.382904638593956,1.3692529620610756,3.819106241272774,-6.226648469224958,4.133733049893017,0.9183393918535261,2.8353188229791533,8.619394716482901,-0.8190571692050304,-2.3888248470531837,-0.48510445083741927,-2.704643930109003,1.7152043223028475,0.23210619346383066,-2.2880815876628544,4.156911746593534,5.481917828229144,False,c3,3,"Probably 2hrs of investigation / and updating the code to provide further information will shed light on this issue.
",104594,0,Medium,False
-2.2638071036332135,2.2565578513916797,0.0434265301658634,4.048947748619804,-3.9138861821782416,-2.9127818882767986,0.7939863143246875,2.2420322979232794,-0.6312357786300072,-2.014487856101754,-1.1365384456397158,-1.2438137460438932,1.28726490338516,-1.9011782378404525,0.5533748142002093,-1.1912104981901346,0.21600390993515295,0.6029775647051754,False,c3,2,"In order to better understand how well ResourceLoader is performing, and to measure the impact of deployments and trends over time, I'd like to request we continuously aggregate metrics for load.php requests.
Specifically, requests and responses from Varnish to `/w/load.php` on all wiki domains (e.g. `en.wikipedia.org/w/load.php?...`).
* Total count of load.php requests per minute.
* Broken down by label(s):
* Response http status code (e.g. HTTP 200, 304, or 500).
* Whether request had a If-None-Match header.
* Response byte size of HTTP 200 responses (Content-Length).
Use case is to be able to continuously answer the below questions. (e.g. in Grafana or elsewhere, showing trends and correlation to deployment events.)
* How many (absolute number) requests were there to load.php globally per minute at any given time? (req.all.count)
* How is the average response size per request changing? (resp.content-length)
* What percentage of clients actually had a local cache for the request? (req.if-none-match.count)
* What was the ratio between responses being cache hits and cache misses? (resp.http-200.count, resp.http-304.count)",104277,-1,Medium,True
-3.1455738912987017,6.42172680242216,-3.808644581408963,-3.6941328077231748,-2.960902928312188,-2.658917762117998,0.7532095801469492,-1.0149077471494894,-0.10646021994433616,-0.5953485463497694,1.306288868766575,-2.3511746001975973,1.1336623681487796,0.4485742755634261,-0.7339641437377553,-0.2193489233148418,1.7400254660516181,0.22433426747404828,False,c3,2,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN.
It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment.
Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:
- **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
- **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:
1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue.
2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",104143,-1,Medium,True
-11.230746940725725,13.28481394580167,-3.9732972641684814,-2.8608436946415257,2.2215397481547914,-0.14470245627939438,1.3123639528579751,3.8677374217100917,6.418899437926117,1.6056423757964735,3.7920269362503434,-2.81338745429334,1.3334310912669984,-0.09394535136782345,-0.025843340511255697,3.498289619856058,-0.268215565655918,-1.6997767968667863,False,c3,2,"all the services listed as not currently redirecting in T103773
check if there are real reasons not to let them enforce https, if possible let them all redirect
then we could do this centrally in the varnish layer and remove all the individual Apache configs in the backends
",103919,-1,Medium,False
-1.1026857351181953,14.981816057710049,6.060418290253736,-8.559329637163568,-5.384199488297675,3.623382808419114,-1.293977662093126,-4.468477229192826,0.09727224586004335,-0.551399692875365,0.4705793974706576,1.0655948153600276,0.64900404079548,-0.12490378045620965,-0.9747589018400413,-1.2626025897298738,1.0424279617809142,-0.44335581231239884,False,c3,2,"For https://phabricator.wikimedia.org/T100673, I would like to investigate the possibility of retrieving the data directly from the HTTP request logs.
It sounds like this data is available in HDFS (via stat1002), sourced from Varnish logs. Can I get access to this?",103872,-1,Medium,True
0.49066377004824613,7.0238104103044385,5.815329338580945,-2.586441443777481,1.3881064761882171,-3.7641829595205243,0.7509601691589411,2.3161886302722556,-1.7504542467425772,-3.4056263111197866,-3.529438082697291,-0.3905160458162944,-0.33778281756962425,2.2801770122133114,0.2352988249054473,-0.38448376121692207,-0.1787831811253615,2.8331887205976223,False,c3,2,"Is it just GETting / or something? Couldn't find the config... Production icinga checks /_info
Example of probes failing on labs against the beta cluster:
http://shinken.wmflabs.org/service/deployment-mathoid/Mathoid
http://shinken.wmflabs.org/service/deployment-sca02/Mathoid
Started falling 6 days ago.
On prod the probe seems to be work since at least 8 days:
https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=sca1001&service=mathoid
https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=sca1002&service=mathoid
So maybe it is a regression in mathoid :-)",103595,-2,Medium,True
12.706170669866445,-0.8003542123555931,-4.362941434211082,6.070012481845859,-5.965312376410994,-2.8102133684241837,-0.6856092550987523,-0.12125494381033325,-5.1291902460360665,-2.19331426792075,1.6492676621304159,-1.0074581613908098,11.48904402368304,7.864099519852095,4.398143558013785,0.8863473594369323,-0.08829244426221794,0.3620057096886182,False,c3,2,"hosts: nembus, neptunium
services: ldap-codfw, ldap-eqiad
SSL CRITICAL - Certificate ldap-codfw.wikimedia.org valid until 2015-09-20 19:36:03 +0000 (expires in 88 days)
SSL CRITICAL - Certificate ldap-eqiad.wikimedia.org valid until 2015-09-20 19:41:02 +0000 (expires in 88 days)
https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=nembus&service=Certificate+expiration
https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=neptunium&service=Certificate+expiration
refs: T84751 , rOPUP4d22373aa41d4ceb9535a495dc167e5e55124cb8, rOPUP0ec73b9075e29b5b9b92abe31a576c23dbd556c0",103590,-2,Medium,False
-4.157435462112936,15.770113709550511,5.967813330998393,10.571018178353492,9.578864828503688,2.107095598557727,-0.14811778701410017,-1.0518083693614009,-1.0589853593457172,-3.3986225550729765,-2.1595735705497168,1.716518674484188,-0.659979173428952,-1.4177849608437874,-1.3347711269398932,-2.561709677878548,3.1567060573657617,4.484647553593795,False,c3,2,"This is to increase the likelihood of the user reading the privacy policy. App stores generally already link to the privacy policy, but this is giving the user another chance before entering their credentials into the Login or Create Account fields.",103201,-2,Medium,True
-4.652432085166771,3.6554304894290794,-3.235049348319219,-3.418426687128353,-0.07432070778159416,-6.110366227652238,0.05579731642135588,-1.3858909430235484,0.2549409016173275,-1.2980314538648727,0.7998819377554032,-1.5666051399134326,1.1938797771029406,-1.1091250903312377,-1.276060182289707,2.699431777360006,3.1243255551467817,0.6819930833922354,False,c3,2,"In most of our domains, we have generically templated in hostnames for both `donate.$domain` and `www.donate.$domain`. The former works fine with TLS, but the latter is an insecure redirect in all cases that I checked. We should probably remove the www's, as otherwise we'd have to increase our cert count/costs by ~50% to get either `www.donate.$domain` or `*.donate.$domain` for all of our project domains.
Related but probably much more complex, we have this in the wikimedia.org zone:
```
wikimedia.org:bounce.email.donate 1H IN A 74.121.50.42
wikimedia.org:bounce.email.donate 1H IN MX 5 bounce.email.donate
wikimedia.org:bounce.email.donate 1H IN TXT ""v=spf1 ip4:74.121.51.111 ip4:208.80.155.11 -all""
wikimedia.org:email.donate 600 IN DYNA geoip!text-addrs-v4/eqiad
wikimedia.org:email.donate 1H IN MX 10 reply.email.donate
wikimedia.org:email.donate 1H IN MX 20 mail3880.email.donate
wikimedia.org:email.donate 1H IN TXT ""v=spf1 ip4:74.121.51.111 ip4:208.80.155.11 -all""
wikimedia.org:mail3880.email.donate 1H IN A 74.121.51.111
wikimedia.org:mail3880.email.donate 1H IN MX 5 mail3880.email.donate
wikimedia.org:mail3880.email.donate 1H IN TXT ""v=spf1 ip4:74.121.51.111 ip4:208.80.155.11 -all""
wikimedia.org:reply.email.donate 1H IN A 74.121.50.42
wikimedia.org:reply.email.donate 1H IN MX 5 reply.email.donate
wikimedia.org:reply.email.donate 1H IN TXT ""v=spf1 ip4:74.121.51.111 ip4:208.80.155.11 -all""
wikimedia.org:links.email.donate 1H IN CNAME recp.mkt41.net.
wikimedia.org:open.email.donate 1H IN CNAME open.mkt41.net.
wikimedia.org:www.email.donate 1H IN CNAME wikimedia.org.
```
I'm not sure what to make of all of those. They mostly seem to be hosted with http://www.silverpop.com/ (via mkt41.net ), but `www.email.donate` is ours and doesn't match TLS certs either.",102827,-3,Medium,False
-13.010317116977081,14.221963258517814,2.716483687114291,3.3484082246673195,-6.576563989999194,2.415025461276361,4.2233847106721205,2.8625389590598997,0.3730964830646758,3.154687414203022,4.126815370874663,0.39712867622885306,1.8487958941602907,0.49456205915691154,-2.0042035574391157,-3.950592829253521,1.4250380407799834,-1.7225771935728513,False,c3,2,"This is a meta-task to collect up all of the related tasks for dealing with various cases of legitimate, functional domainname endpoints that browsers can hit for insecure redirects currently, which do not match our SSL certs.",102824,-3,Medium,False
-5.630670167040952,12.844099393213611,1.4487813721563967,-1.6747471040380266,-0.9836359638166904,1.2461470791499554,4.181458825903241,0.82642743000492,-4.5146466339551035,-0.3556829112640134,-0.11369909891541674,1.9032320317283629,-0.30311028867291423,0.8466555978867678,0.14621107332864458,-3.2426136100549474,0.14498050501979365,-0.18574687618270747,False,c3,2,"Per request from Faidon: we'd like to know how much, if any, of the performance regression that is currently indicated by the weekly graphs on https://performance.wikimedia.org is attributable to 301 redirects from HTTP to HTTPS. This is another way of asking: how much of the performance impact is real, and how much is a temporary consequence of the migration process?
If these metrics include time spent following redirects, so much the better, because redirects should become much less frequent as HTTPS rel=canonical propagate through the caches and as search engines spider our site.
The Navigation Timing API provides absolute, not relative, timestamps. We compute duration by subtracting `navigationStart` from each measure. `navigationStart` is the start of navigation from the user's perspective, so redirects are included. What I am not sure about is whether measures like `responseStart` necessarily refer to the last response from the server, or if the redirect counts.
We can determine this by comparing the distribution of `responseStart` values where `redirectCount` is 0 vs. values where it is nonzero.",102732,-3,Medium,True
-5.371067775304325,8.448138386177774,4.760008362736574,0.7549130448519714,4.240307201318608,-4.445202166505265,3.2711042558880044,-1.755107835044766,0.7303760884492798,0.09014513176326489,0.6887073661918737,1.5762875354436623,-1.0200396006392358,0.8951701369977005,-0.13467927699116888,-0.5731803502779069,1.4592978962143384,-2.531253935852805,False,c3,2,"After the https switch, the page http://www.wikidata.org/wiki/Special:EntityData/Q1.ttl?flavor=dump redirects to https://www.wikidata.org/wiki/Special:EntityData/Q1.ttl?flavor=dump - which produces this prefix:
```
@prefix wdata: <https://www.wikidata.org/wiki/Special:EntityData/> .
```
Which doesn't seem right since our URLs are defined as http:// canonically. Should we change the definition or (my preference) fix the output so it displays http:// even if current page is https. Data should not depend on the transfer protocol IMO.",102717,-3,Medium,True
2.4725431520242975,-6.0678555784663075,5.8046133721036846,-5.758386177183186,-9.852405208363583,4.350808972127069,-2.6816773561745846,-1.9413953632422567,-1.7705055806549312,-4.456982989788452,-6.287822663227483,-2.692084027185814,-2.388199456773944,-1.4035536491626908,0.1841283118806647,6.011224201049419,-1.2577644021417282,-0.45085321093933595,False,c3,2,"Spotted in production:
```
1 Undefined index: HTTP_USER_AGENT in /srv/mediawiki/php-1.26wmf9/includes/resourceloader/ResourceLoader.php on line 668
```",102624,-3,Medium,True
-9.372654137556223,7.7551741507242085,-0.9897825677578318,-0.2195314809246499,4.968393281754469,-0.2912603480997915,1.7110219419923745,4.047310670421565,-7.32487080319151,-1.9764600163135952,-1.0161889158457504,0.017202889919522013,-4.937432136102026,1.879926765393435,-0.6426671744974,-1.2780679398440868,2.6300771115993813,1.5636681762839066,False,c3,2,"Since we're not (yet) focusing on editors in the app, the login onboarding activity is kind of a distraction, and isn't adding much value.
[] Make sure there are no dependencies re. the Editing workflow.",102482,-3,Medium,True
1.9392148670910818,1.3920315140116806,-1.1921692718823387,-4.232380179674561,3.6658587394268642,-6.0083227119208,-1.959027012223336,-6.203386052412835,0.3127939685964728,1.640081416294091,-1.7532212774054503,-3.0432462271210934,0.3581251241495824,-4.587141581876586,2.2787327449323938,0.07724389134864468,0.2445165695867042,2.7541292221147984,False,c3,2,"Hi someusers are reporting when registering for an account using MediaWiki OAuth.
They have said the following.
I just tried to report it on Phabricator. From the home page, I clicked ""Report a problem"", and it took me to a login screen. I clicked the ""Mediawiki"" button, and it took me to the MediaWiki's OAuth screen. After I clicked ""Allow"", it came back to Phabricator, and the message, ""Login Failure. Login cookie was set correctly, but your login session is not valid. Try clearing cookies and logging in again.""
",102276,-3,Medium,True
21.828197804941347,0.6509145069008557,20.214500145673334,-14.379420543629648,-4.131113913847722,2.544057658540998,1.6930677392324016,7.650500053172533,-4.188803439133365,2.822655484015681,2.9586748580743527,-6.770395785237849,2.3963038414298596,-2.2843794553332257,-2.0795239053692125,-2.5155105343047177,-0.8143327660745417,0.18663417931380066,False,c3,1,"From Fatalmonitor: `Unknown HTTP status code 200 OK in /srv/mediawiki/php-1.26wmf9/includes/libs/HttpStatus.php on line 100`
Unknown, really?",102028,-4,Medium,True
6.552204212714335,-7.186437017840859,0.7518796378903154,4.722957013329735,0.6094446686697554,-3.7393801634412993,-6.182730745567977,1.2965363866223183,-3.689949710268057,-2.5686186219041827,10.758780035665893,0.9022035946376101,-7.917745767719301,-0.6194913204380157,0.38442413649872087,-1.1187613784991866,0.8563273983336768,-0.5549691828413648,False,c3,1,"hasSlaveScripts should also be available on labs slaves, not only production slaves. It seems the scripts are there but the slaves are not tagged that way. Perhaps the solution is to remove the tag if every slave has them.
To find all such jobs:
ssh gallium.wikimedia.org 'grep -l hasSlaveScripts /var/lib/jenkins/jobs/*/config.xml|cut -d\/ -f6'
That is all the -jslint jobs and:
[X] erblint-HEAD https://gerrit.wikimedia.org/r/222283
[X] jshint - https://gerrit.wikimedia.org/r/222115
[X] jsonlint - https://gerrit.wikimedia.org/r/222115
[X] *-jslint - https://gerrit.wikimedia.org/r/222115
[X] mediawiki-core-jslint https://gerrit.wikimedia.org/r/222281
[X] mediawiki-core-phpcs **unused** dropped by https://gerrit.wikimedia.org/r/222282
[X] mediawiki-core-whitespaces https://gerrit.wikimedia.org/r/222280
[X] mwext-CirrusSearch-whitespaces https://gerrit.wikimedia.org/r/222280
[X] mediawiki-core-phpcs-HEAD https://gerrit.wikimedia.org/r/222123
[X] mwext-.*-phpcs-HEAD https://gerrit.wikimedia.org/r/222123
[X] operations-puppet-pep8 https://gerrit.wikimedia.org/r/217249
[X] operations-puppet-test https://gerrit.wikimedia.org/r/217249
[X] parsoidsvc-php-parsertests https://gerrit.wikimedia.org/r/222577
[X] perllint https://gerrit.wikimedia.org/r/217503
[X] pplint-HEAD https://gerrit.wikimedia.org/r/217504",101966,-4,Medium,True
-9.559499095016475,2.842694686713415,-4.45723456115676,-2.316201279218986,0.8527130851574463,0.7928717149457543,0.6398872029563023,-0.47293295126619606,1.2816921499386713,0.9101509572573931,1.7667010531339176,-0.10706472819119339,1.8558392862718676,-0.9874491535184933,-1.187817991440551,-0.2361135643408716,-0.5007382995559997,0.8016559143015238,False,c3,1,"I argue that the principal challenge we face in monitoring for the foreseeable future is basic coverage: representing the state of every important service using metrics which are clear, concise, representative, understandable, well-defined, and actionable. This is a big job and it will take us a while to get there. In the interim, we should be ruthless about eliminating metrics which are vague, overspecialized, or redundant. Eliminating them will not only relieve pressure on our monitoring infrastructure, but also aid in discoverability by reducing the amount of clutter one has to wade through to get to the essential metrics.
I propose we blackhole the following metrics in Graphite:
* `*.sum_sq` (sum of squares) -- too specialized
* `*.stddev` (standard deviation) -- too specialized
* `*.upper` -- too vague
* `*.lower` -- too vague
When considering this proposal, please resist the temptation to think to yourself ""I am a smart person and know how to use standard deviation!"". Instead, consider if any of the dashboards you have created display this metric, and take that as an indicator of the utility of this measure.",101759,-4,Medium,True
7.842348389919476,4.535194187653307,11.394603867668781,2.1716937490933925,0.2910218225059563,-1.4748493952169799,-2.2195212073338424,-4.821322528596171,-4.067220967586977,-1.9739145776818492,3.987097679634664,1.2430585211329974,-2.0901789065228797,-0.6774062887537653,-3.1657613479956126,-2.4978395858183515,2.035710038536859,0.08879757915818831,False,c3,1,"I keep getting the following warning on Firefox's console:
> This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.
https://developer.mozilla.org/en-US/docs/Web/Security/Weak_Signature_Algorithm
https://developer.mozilla.org/en/docs/Tools/Web_Console#Security_warnings_and_errors
This happens for each
> GET https://labels.wmflabs.org/auth/whoami/
call from [[https://meta.wikimedia.org/wiki/Wiki_labels|Wiki labels]].",101618,-4,Medium,False
3.8004010721664456,3.041785128747083,-1.8051436263410565,2.6521528071537683,6.21700108081474,-7.605601332390123,3.019241518955954,9.866490720223663,-3.257140719278202,-4.480494209044284,-4.869783224119498,-3.290852243878981,-1.722318296330375,-2.6280690826782784,1.4969372121638056,-1.31529487913339,1.0171294430692266,-2.6162537807111557,False,c3,1," RT moved behind misc-web (I71315c476262e6) so the certificate is not needed anymore.
",101571,-4,Medium,True
-9.558531273911532,11.679929699505774,12.128674669928522,7.405255241789924,-4.051524917336705,-0.9022320070222589,4.482630926211509,4.208261611359207,-4.473622587166311,0.3092701364448107,0.03960828300374786,2.7211185013135637,-0.06656611087848052,-1.5787798498364163,0.8119415175980249,1.4989401359466998,-1.2699395229637134,-2.6767730318885787,False,c3,1,"For non-logged-in users show login page instead of nosuchspecialpage if the URL has campaign parameter. After login the user should be taken to Special:CX again with all query parameters.
This is important for campaigns like email campaigns. When user click the user may not be logged in. Showing nosuchspecialpage is a bad idea in that case.",101489,-4,Medium,True
-1.8600103314727545,10.143226753503672,2.977764371197928,3.442145707166783,3.207587511792003,1.2795291762337493,-0.5490951253034533,2.326738542405405,3.438750713882081,-2.3181934802162605,-1.6945256964129942,-4.388257731176315,-0.5957584495080175,-0.1141763857329261,0.6693492144589923,-0.58485733657653,-3.777071549041172,1.4754545012640048,False,c3,1,"When receiving an email, none of the three wikimedia mail servers (lead, polonium and sodium) support STARTTLS for reception.
Expected:
They should offer the STARTTLS, after which should present a valid certificate making possible to establish a TLS connection with a PFS cipher.
Like T101451, the email should also be protected when arriving to WMF servers, as well as when reentering wikimedia.org quoted in a reply.",101452,-4,Medium,True
8.207100241336015,-2.8750592112394315,-5.917107388338284,8.269444503756603,-2.1502098932743183,-5.908450744515297,-4.374642042010532,0.5676400709840987,-0.8330478554464699,0.09591460113599126,0.674350365069246,-0.45671328778515075,-1.373267308580301,-0.4460452165040891,0.88690039009267,-0.024663699654960958,-0.9504515140368961,-0.2603144848900707,False,c3,1,"Output follows. Looks like it is expecting some python scripts to be in place.
mah@flynn: HitCounters$ git review -d 202629
Traceback (most recent call last):
File ""/usr/local/bin/git-review"", line 11, in <module>
sys.exit(main())
File ""/usr/local/lib/python2.7/dist-packages/git_review/cmd.py"", line 1180, in main
local_branch = fetch_review(options.changeidentifier, branch, remote)
File ""/usr/local/lib/python2.7/dist-packages/git_review/cmd.py"", line 886, in fetch_review
parse_exc=ReviewInformationNotFound)
File ""/usr/local/lib/python2.7/dist-packages/git_review/cmd.py"", line 416, in query_reviews
parse_exc=parse_exc)
File ""/usr/local/lib/python2.7/dist-packages/git_review/cmd.py"", line 434, in query_reviews_over_http
request = run_http_exc(exception, url)
File ""/usr/local/lib/python2.7/dist-packages/git_review/cmd.py"", line 175, in run_http_exc
raise klazz(255, str(err), ('GET', url), env)
git_review.cmd.CannotQueryPatchSet: Cannot query patchset information
The following command failed with exit code 255
""GET https://gerrit.wikimedia.org/changes/?q=202629&o=CURRENT_REVISION""
-----------------------
Cannot query patchset information
The following command failed with exit code 104
""GET https://gerrit.wikimedia.org/changes/?q=202629&o=CURRENT_REVISION""
-----------------------
<!DOCTYPE HTML PUBLIC ""-//IETF//DTD HTML 2.0//EN"">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /changes/ was not found on this server.</p>
</body></html>
-----------------------
-----------------------
mah@flynn: HitCounters$ ",100987,-5,Medium,True
1.9463233158320032,6.730889190735397,-3.3344142102694008,0.35316156766000084,-1.1056802479532153,5.20240146554033,1.4710097668060467,2.4849618098250548,1.0048258370093786,0.48746862707544203,0.48995987679099073,-0.7997262861739329,0.06298808677613987,1.3181789514277629,-2.721643362176993,-1.2910984454613357,0.02140036745001961,1.9418228471259178,False,c3,1,"MediaWiki contains a dozen of variations on how to set the HTTP status code.
```lang=php
WebResponse->header( ""HTTP/1.1 $code $message"" );
WebResponse->header( ""HTTP/1.1 302 "" . HttpStatus::getMessage( 302 ) );
WebResponse->header( ""HTTP/1.1 $code $message"", true, $code );
WebResponse->header( ""HTTP/1.1 403 $message"", true, 403 );
header( ""Status: $code $message"", true, $code );
header( ""Status: "" . $this->mResponseCode, true, (int)$n );
header( ""Status: {$this->httpCode} {$httpMessage}"", true, $this->httpCode );
```
.. and many more.",100984,-5,Medium,True
-2.7381612001332174,0.8793118673809719,-6.2741675276359015,8.329581462261599,-12.109720464769625,-4.778006537645519,-6.5963451934072275,2.883504895044653,2.6865520938574354,-2.103352656630355,12.146697523241624,3.2460599647820363,-8.209141846137754,1.1045126771193292,0.036020684112805235,0.14307844117964638,-1.0845307073687904,0.8819562269692345,False,c3,1,"Tracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps:
[x] - reissue certificate in sha256
[x] - update configuration to use new certificate
[x] - push changes live
[ ] - revoke old sha1 certificate",100835,-5,Medium,True
-4.324017260004105,-0.039681203574446045,-5.162777403604158,8.791725861773665,-12.52136038028323,-5.5847285022405,-8.854661352817567,3.1101465341878307,1.6921940694655169,-2.992735665319885,15.220606833620625,3.288591689670172,-10.888759395278278,1.5221542821189606,0.6119000313864023,-0.11228335059480404,-0.9139611102554396,1.0400184514223343,False,c3,1,"Tracking task to replace list.wikimedia.org's sha1 cert with sha256, in multiple steps:
[x] - reissue certificate in sha256
[x] - update configuration to use new certificate
[x] - push changes live
[x] - revoke old sha1 certificate",100832,-5,Medium,True
-2.7369722320352734,0.8775653974053697,-6.272020179820874,8.327201187336351,-12.106397267560881,-4.780155525636477,-6.605796810615676,2.8793169242873407,2.6899508462323602,-2.1009923732369957,12.146851227468149,3.2453113476195545,-8.20830748421379,1.0960754353326427,0.027439028606308646,0.15395480509808476,-1.0911042194847198,0.8717998973876366,False,c3,1,"Tracking task to replace librenms's sha1 cert with sha256, in multiple steps:
[x] - reissue certificate in sha256
[x] - update configuration to use new certificate
[x] - push changes live
[ ] - revoke old sha1 certificate",100831,-5,Medium,True
-2.7367893138663586,0.8772967097168145,-6.271689818618562,8.326834991194007,-12.105886006451843,-4.780486139173548,-6.6072509055708215,2.8786726210939078,2.6904737312131175,-2.10062925271494,12.14687487427223,3.2451961757484034,-8.208179120840871,1.0947773981346902,0.026118773913001547,0.15562809185476761,-1.0921155290410167,0.8702373851443135,False,c3,1,"Tracking task to replace icinga's sha1 cert with sha256, in multiple steps:
[x] - reissue certificate in sha256
[x] - update configuration to use new certificate
[x] - push changes live
[ ] - revoke old sha1 certificate",100830,-5,Medium,True
-3.81677810458584,1.2473105916694038,-5.302260773543775,8.850139668376544,-13.26248929542829,-5.187927184602091,-8.1439292956821,2.830250767803248,1.079607375036593,-2.910825049763308,14.400440094197897,2.7951580931926605,-10.477348239168208,1.3687566165985272,0.4147732885229045,-0.21953065909549718,-0.8796478638479418,0.9563942695127376,False,c3,1,"Tracking task to replace git's sha1 cert with sha256, in multiple steps:
[x] - reissue certificate in sha256
[x] - update configuration of ganglia to use new certificate
[x] - push changes live
[x] - revoke old sha1 certificate",100827,-5,Medium,True
-4.8663010619705656,1.2178385099281819,-3.6874665793713266,9.623818573456962,-13.00410418842645,-5.34401453764767,-5.5663774305084175,2.3611880005439265,2.109171407109632,-1.9806284371790968,11.331617140712174,2.90714319360704,-7.890194304258393,0.9396846605650291,-0.01041138527402996,0.032235269866550675,-1.0158827030867927,0.8218769116653502,False,c3,1,"Tracking task to replace ganglia's sha1 cert with sha256, in multiple steps:
[x] - reissue certificate in sha256
[x] - update configuration of ganglia to use new certificate
[x] - push changes live
[ ] - revoke old sha1 certificate",100825,-5,Medium,True
-3.051831929403798,-4.682560347843443,3.9763145170874523,0.4182143961904623,12.595163592381821,-6.028298703994612,3.8379544798629253,-0.23954622471309395,-2.735343514264711,-0.39594887805573453,1.805022754816632,-0.9893965921767183,0.43249967566100755,0.7437531269400024,-3.315474258473356,3.00803790813216,0.5305861655261703,2.055612968058008,False,c3,1,"Almost every login:
```
PHP Notice: Undefined variable: status in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53
PHP Stack trace:
PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0
PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46
PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435
PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584
PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275
PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584
PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363
PHP Fatal error: Call to a member function isGood() on a non-object in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53
PHP Stack trace:
PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0
PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46
PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435
PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584
PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275
PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584
PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363
```
Not a big issue, but it floods log files.",100020,-6,Medium,True
54.72351061279767,5.349512424632604,24.26784948128371,-4.815704508508934,8.884193692097238,-4.1882323852406325,3.841450925543003,-1.6962141206462111,-6.055322676318163,0.7257884611802918,0.31113426585749604,13.607991670904296,-0.6343346439873319,6.393090160804906,-9.525363958009505,3.8728815956513007,-3.5881769527741048,-2.965686559806818,False,c3,1,"Username is @Meno25
See https://en.wikipedia.org/w/index.php?title=User_talk:Josve05a&oldid=663230168#Phabricator",99455,-7,Medium,True
9.896103192324182,9.807041128083924,7.947301021254493,-2.968175283255181,-1.1774998194923434,3.857905635918054,-4.716058179612784,-1.4280234299820673,-1.9489372764692918,0.0035799560880089842,-2.6761950643868038,0.824764631640148,0.7431382249465011,-1.872895629078842,-1.777633671640229,-1.6057478959238394,-2.107837375828891,1.6749246239415985,False,c3,1,"On an upload of ""File:Scanwings, OH-BCX, Beechcraft C90 King Air (17512831479).jpg"" to Commons:
Using HEAD, upload fail with a loophole of
```
ERROR: Traceback (most recent call last):
File ""/data/project/yifeibot/pywikibot/pywikibot/data/api.py"", line 1555, in submit
body=body, headers=headers)
File ""/data/project/yifeibot/pywikibot/pywikibot/tools/__init__.py"", line 950, in wrapper
return obj(*__args, **__kw)
File ""/data/project/yifeibot/pywikibot/pywikibot/comms/http.py"", line 269, in request
r = fetch(baseuri, method, body, headers, **kwargs)
File ""/data/project/yifeibot/pywikibot/pywikibot/comms/http.py"", line 370, in fetch
error_handling_callback(request)
File ""/data/project/yifeibot/pywikibot/pywikibot/comms/http.py"", line 287, in error_handling_callback
raise request.data
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 1872: ordinal not in range(128)
WARNING: Waiting 5 seconds before retrying.
```
After debugging, I found all versions after 1e54a7d6886d56a21101900025038e25bab5ad03 has the same error, while version before raises an (expected) exception that is handled in botscript:
```
KeyError: u'bad-prefix'
```
(raised in https://github.com/wikimedia/mediawiki/blob/84899f991ff44f36b7359f0bbf8de2955b81a904/includes/upload/UploadBase.php#L1834)
I agree that some errors should be prevented from uploading. But why is there a UnicodeDecodeError leading to a loophole?",99366,-7,Medium,False
8.43993804761116,7.064316125847668,-2.565988579417267,-5.150735164564883,1.8989007906830406,2.5445492379054,-5.004579269326209,1.2805444370909522,2.053342236642921,-0.050758995328834544,-3.0372726482880523,2.3166265633475582,0.20153804980904244,-1.2279508388632032,0.8211164561743818,2.0118063871860645,-0.7770015593252565,-0.12356635741389965,False,c3,1,"The OAuth Server Application has to be activated in Phabricator. Once activated Phragile needs to be registered as an OAuth application. There are two fields to fill out when creating a new OAuth application. ""Name"" should be ""Phragile"" and ""Redirect URL"" should be ""http://our-phragile-domain/login"" (we don't know yet what the domain will be but it can be changed later on anyway). This will generate an OAuth Client ID and an OAuth Client Secret which Phragile needs in order for the OAuth login mechanism to work.
See discussion in T90489
(we need this solved before the hackathon in Lyon) - thanks.",98954,-8,Medium,True
-7.300239030620769,12.761673266026268,21.508640685540797,11.155245914949916,-5.183673763034221,-3.7872081775427198,0.9321777757778129,1.416673997352417,-0.8002178753028142,-3.2962002879561068,-3.9393137227435018,-6.957838570569429,-1.3111837793892098,-1.5703878655594945,-2.472052387188813,-5.51425821496219,-0.5857967658488699,4.500861017181558,False,c3,1,Properly. With templates for generating the output config file.,98441,-8,Medium,True
-9.48471487286606,5.264032091633048,6.452055837073985,5.974226590916065,1.9159828645346422,-5.9592961296621585,4.110187802143948,0.9551927131693493,-3.4647140343112675,-1.6806190345910137,-0.80998953420504,8.18795820281159,-0.16643271685335748,-3.6490616607052653,3.583558269872957,4.7159432089607485,2.5269471754938975,-0.6768522424978254,False,c3,1,"Some css rules appear in common.less but are only used on the mobile custom login page. They should be moved.
",98399,-9,Medium,True
-5.278901134322013,5.2020075773094945,-0.32954788231024423,-3.6993945215930983,3.186585955786841,-2.285400835198799,0.8228210926480068,-4.9857313905757055,-0.31848763660927887,-0.23206251040044013,1.7333426143301094,-0.3477738516619677,1.437083564297398,-0.5776035705316973,-1.3683681754372374,1.6345149518649031,-0.36441016887782385,-0.40085362453115403,False,c3,1,"Quite often, on Wikipedia and other sites, a banner invites me — again and again — to vote for something.
Quite often, this ends up in an over-complicated process full of jargon, trapped with bugs and wrong directions and dead ends. Last time, I gave up voting.
The vote today is nicer. :-) But it is still buggy and not user-friendly.
On Wikipedia, a banner invites me to vote.
I go to this vote.
I get the page that starts with a little explanation: please make your votes here, all your votes are neutral by default, you may set your votes now and come back later and change them.
Fine.
I click the link for the presentation of a candidate, I come back to the voting page, I set my vote.
I do the same for another candidate...
I click other links too.
I go to other Web sites too.
I go back to the page of my votes.
I expect to find the same page as before, with my votes kept as promised.
Instead, I find a barrier. A page says that I must log in. But how? There is a little link “Log in” at the top right. See this screen photo:
{F160349, alt=""Barrier. The page says that I must log in. But how? There is a little link “Log in” at the top right.""}
I click the link “Log in”. I try to log in.
I expect the auth to work and I expect to land on the page for voting, with my votes kept as promised.
Instead, I find a dead end. A page gives me an insult message: login error, no user “Nnemo”. The page asks me to log in. This turns the dead end into an infinite loop. ;-) See this screen photo:
{F160364, alt=""Dead end. The page gives me an insult message: login error, no user “Nnemo”. The page asks me to log in. This turns the dead end into an infinite loop. ;-) ""}
...
Finally, after circumventing the traps, I get back the voting page. I expect the voting page to have my votes kept, as promised. Instead, my votes are lost and the votes are all neutral.
It would be nice to fix and improve that.
Thank you.
I have Safari on iOS 8 on an iPad.
Nnemo
",98013,-9,Medium,
-5.263838951866189,7.65687903553161,2.616475362716578,3.000039992828313,2.408225920066333,-4.332659220854688,-1.2733598848613044,-4.756695300202567,-0.6420244555149077,-3.32745801671656,-0.2848055049426179,3.2131864727375072,-0.010646439401674535,-0.41481447414524997,0.47418491491732695,-1.163969978637274,-0.125275903807885,-0.2187635230949616,False,c3,3,"The login form (Special:UserLogin) should display a warning message when it detects that the user is typing his or her password with caps lock on.
This could be accomplished, say, with [[ http://stackoverflow.com/q/348792/1757964 | one of these methods ]].",112160,10,Low,
5.951551159386849,9.989711464327392,2.4829536085555617,-1.4555923449870622,-1.8714331781000157,4.85549285989279,-0.505669352541978,1.3427743379553054,-0.2703809533552782,1.0446775983722176,0.9991149844276284,-2.2329898022932353,0.5719131320672961,-1.427685951242978,-0.30522221253765913,1.47088044549667,0.1576989485436795,0.20115681782077766,False,c3,3,"From a recent WP:VPT discussion, it was suggested to have the following added as an automatic ""general fix"" in AWB: changing the protocol for certain external links from HTTP to HTTPS, although only within citation templates. For now, this should include a number of Google services (e.g. Google Books, Google News, YouTube) and the Internet Archive (i.e. Wayback Machine). In essence, this should probably be some sort of RegEx feature that looks for `|url=http://books.google.[com|co.uk|ca|de|it|es|...]` and replaces it with `|url=https://books.google.com` (yes, the top-level domain switch is intentional here, since Google redirects from `.com` to a specific country version, and we should keep the links general). The same for Google News, YouTube as well as `http://archive.org` and `http://web.archive.org/` links. (For the latter, of course, the RegEx would have to find `|archiveurl=http://[web|wayback].archive.org/`)",111693,9,Low,
-3.9346625482999547,-0.21066856303973758,1.0403647729434375,-8.221276988830724,9.6898471208881,-5.3934525071870265,2.819712451820883,5.817951301779501,-2.8451970394596655,-1.8404719209888634,0.2512627492547348,-8.787305605577187,0.21933177815195393,-0.20378268745506478,-2.6118432996255003,-2.171466418496029,-0.37886611673943915,-0.7877762357926019,False,c3,3,"Sometimes (lately, more frequently) I get these errors on the console:
```
ERROR: Traceback (most recent call last):
File ""D:\Work\pywikipedia\pywikibot\data\api.py"", line 1932, in submit
body=body, headers=headers)
File ""D:\Work\pywikipedia\pywikibot\tools\__init__.py"", line 1267, in wrapper
return obj(*__args, **__kw)
File ""D:\Work\pywikipedia\pywikibot\comms\http.py"", line 245, in request
r = fetch(baseuri, method, body, headers, **kwargs)
File ""D:\Work\pywikipedia\pywikibot\comms\http.py"", line 401, in fetch
error_handling_callback(request)
File ""D:\Work\pywikipedia\pywikibot\comms\http.py"", line 318, in error_handlin
g_callback
raise request.data
TypeError: __str__ returned non-string (type SysCallError)
```
The error is not fatal, and the request is usually retried after some seconds.
This is not the usual ""read timed out"" which happens sometimes.
```
>pwb.py version
Pywikibot: [https] r-pywikibot-core.git (0e2a436, g6351, 2015/09/05, 10:08:04, ok)
Release version: 2.0b3
requests version: 2.7.0
cacerts: C:\Program Files\Python\lib\site-packages\requests\cacert.pem
certificate test: ok
Python: 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)]
PYWIKIBOT2_DIR: Not set
PYWIKIBOT2_DIR_PWB: D:\Work\pywikipedia
PYWIKIBOT2_NO_USER_CONFIG: Not set
Config base dir: D:\Work\pywikipedia
```",111617,9,Low,False
5.234271744302296,7.249638960448102,4.8869589048630395,-6.270199870576589,-0.5449215198981165,-4.53832439109133,2.472932868524631,4.9614858619419415,5.874183344478068,1.945372581226886,3.1166737134933418,-1.6540142980079908,0.8766529574957502,-1.9213769795968765,1.367191356583528,4.264752435204477,0.7438667249617879,3.629659457750458,False,c3,3,"See parent task and T110431#1604967.
This should likely be redone as a PrimaryAuthenticationProvider, where it can now integrate with Special:UserLogin and Special:CreateAccount instead of having to do its own special page and such.",111485,9,Low,False
-1.5390915906061962,11.440621690658048,4.619876516761639,5.821963962357096,1.0464749596165646,6.011557113269267,3.681104855571026,2.929337412209436,-3.3624829873447517,2.296860210216561,3.34370512344741,0.7146298869446177,1.8091311440302817,-2.0702300248989687,-0.33443146331138074,-1.0941199035500122,1.597291168964689,0.40042216020281685,False,c3,3,"The `https` role uses `WebRequest::detectServer()` so the predefined server/port overrides the actual one. This is a problem for vagrant boxes which should both be reachable from `127.0.0.1:4430` (for convenient manual testing) and from `<guest ip>:443` (for use with another vagrant box, e.g. for testing InstantCommons backend changes).",110853,8,Low,
-14.821269721550696,17.471553321539044,3.804155960423916,-3.176205823101013,0.2441743419891791,-1.8329450281336097,-0.06927153490066207,6.323911631300303,4.38158290675005,-1.1118670770161785,0.6678179187344484,-0.22731884161252025,2.1046872192378987,5.634792179613433,0.12174691627915113,0.2366970355195871,-7.5743534766357685,-0.27035140471776886,False,c3,3,Currently it just checks to see if the process is running. Have an additional way for people to check for a 200 status code as well.,109719,7,Low,False
-7.367833979486393,5.873072438918445,-1.0998922240556155,-1.4420870524440548,6.4360993779336635,-1.632395938273132,-1.2845455015519036,0.7992037393433672,0.39339151849060583,-1.8850316712877095,0.25802990937974357,1.044692672279998,-0.21580077099968875,0.6012635282898078,0.07046165451900777,-0.13127232798929817,0.07921789561221182,-2.9860899249645976,False,c3,3,"When I tell users to login in https://phabricator.wikimedia.org, they systematically get lost; success rate is very close to 0 %. We know the reasons: T87552, T963. To work around the former I link directly https://phabricator.wikimedia.org/auth/start/ , but the stupid login form can't be worked around: I need a direct link which brings the user to a familiar place where they know what to do.
The button doesn't provide an <a> element with a link that can be copied, instead it forwards to an URL like https://www.mediawiki.org/w/index.php?title=Special:UserLogin&returnto=Special%3AOAuth%2Fauthorize&returntoquery=oauth_token%3D********************************%26oauth_consumer_key%3D******************************** which can't be shared.
Whatever logic is behind the button forward (the form /auth/login/mediawiki:mediawiki/ with some hidden value) should be exposed via another phabricator URL that we can then share.",109330,6,Low,False
-0.9232658221543568,17.565872904657372,-2.0447552851997326,-11.82964140416448,-7.594605293033553,-1.7716176594389244,-5.09018292852308,-8.10840028410309,-0.7191809227022032,2.9133422966549745,-2.6100400559082435,-2.7656366903873444,-0.5017874260318278,0.12882560743627547,-1.3125334736675507,7.501070568512063,-4.0797172877586485,-0.011956910952996891,False,c3,3,"As a logged in user, https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=google:foo will redirect you to a Google search for ""foo"".
And if you're not logged in, it will redirect you to Google after you finish logging in.
Discovered by @valhallasw.",109140,6,Low,False
1.05070691413195,12.032895421384222,2.573325211217341,2.014123043255759,7.112641027929609,3.4925592733991078,-6.7245484686950805,-4.799790090974915,8.98737304588966,0.18593959658187753,-0.05188475814310278,-0.8063388405336638,1.401761129735473,-0.21697451406982804,-3.009024417759883,1.675226564770133,3.8898377939603526,1.4722763266116574,False,c3,3,"Visit http://en.m.wikipedia.beta.wmflabs.org/wiki/New_page?mobileaction=beta#/editor/0 and you'll see the formatting toolbar at the bottom of the screen.
{F1495360}",109107,6,Low,False
-3.958675578189,1.1768354145943611,-2.435861763725258,-2.014000431688087,-2.3891116639832912,-3.1575003552698444,-0.8063967819576563,-1.733176142587114,0.3181994235105875,-0.20874123312004755,-0.8200154820729941,0.6068226963566807,0.5850769904359896,-0.7442590266065556,0.13244098477980515,1.2808774489055619,0.006628405404152771,0.7352483102086842,False,c3,3,"Introduction
--
According to ""pwb.py login -help"":
-force Ignores if the user is already logged in, and tries to log in.
-pass Useful in combination with -all when you have accounts for
several sites and use the same password for all of them.
Asks you for the password, then logs in on all given sites.
-pass:XXXX Uses XXXX as password. Be careful if you use this
parameter because your password will be shown on your
screen, and will probably be saved in your command line
history. This is NOT RECOMMENDED for use on computers
where others have either physical or remote access.
Use -pass instead.
but using ""pwb.py login -all -force -pass:xxxxxx"", yields:
To force a re-login, please delete the revelant lines from '******\pywikibot.lwp' (or the entire file) and try again.
Password for user MalafayaBot on wikiquote:ka (no characters will be shown):
That is, neither it did a ""-force"" (apparently, I have to do it manually by deleting the file) nor it assumed the password I passed in the command line (it's asking me for it).
**These unsupported options should be removed completely**
What to do?
--
- remove `-force` and `-pass` options from documentation string
- remove them from option handling in `main` function
- remove warnin about unsupported `-pass` Option
Important hints
--
- refer [[https://www.mediawiki.org/wiki/Manual:Pywikibot/Development#Guidelines | our Coding Convention Guidlines]]",108848,5,Low,False
-6.508883923131824,7.223734219397372,2.7842577432690305,-2.2783852242103015,5.504312366171472,-1.5105083981251302,-1.3621699344806055,-6.367938969603903,1.3413692058811322,4.601137949017723,2.2991316119159024,-2.576488519105856,2.1532088469308674,0.8728134794827502,1.3644338404228407,-1.1848804258252394,-0.8097226934101913,-1.6687916217362164,False,c3,3,"We've had a surge of 5xx lately, investigating it I found a bunch of 501s (""method not implemented"") for truncated URLs from an external referer
```
{
""hostname"": ""cp4014.ulsfo.wmnet"",
""sequence"": 6204195515,
""dt"": ""2015-07-22T12:34:33"",
""time_firstbyte"": 0.078635931,
""ip"": ""10.128.0.114"",
""cache_status"": ""miss"",
""http_status"": ""501"",
""response_size"": 235,
""http_method"": ""GET"",
""uri_host"": ""upload.wikimedia.org"",
""uri_path"": ""/wikipedia/th/thumb/3/36/%E0%B9%82%E0%B8%A5%E0%B9%82%E0%B8%81%E0%B9%89%E0%B8%AA%E0%B9%82%E0%B8%A1%E0%B8%AA%E0%B8%A3%E0%B8%9F%E0%B8%B8%E0%B8%95%E0%B8%9A%E0%B8%AD%E0%B8%A5%E0%B8%AD%E0%B8%B2%E0%B8%A3%E0%B9%8C%E0%B8%A1%E0%B8%B5%E0%B9%88_%E0%B8%A2%E0%B8%B9%E0%B9%84%E0%B8%99%E0%B9%80%E0%B8%95%E0%B9%87%E0%B8%94.jpg/250px-%E0%B9%82%E0%B8%A5%E0%B9%82%E0%B8%81%E0%B9%89%E0%B8%AA%E0%B9%82%E0%B8%A1%E0%B8%AA%E0%B8%A3%E0%B8%9F%E0%B8%B8%E0%B8%95%E0%B8%9A%E0%B8%AD%E0%B8%A5%E0%B8%AD%E0%B8%B2%E0%B8%A3%E0%B9%"",
""uri_query"": """",
""content_type"": ""text/html; charset=UTF-8"",
""referer"": ""http://www.xn--72c0as5bd1c5b2byj.com/"",
""x_forwarded_for"": ""171.96.167.13"",
""user_agent"": ""Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.134 Safari/537.36"",
""accept_language"": ""en-US,en;q=0.8"",
""x_analytics"": ""-"",
""range"": ""-"",
""x_cache"": ""cp1050 miss (0), cp4014 miss (0), cp4014 frontend miss (0)""
}
```
The correct behaviour would've been to issue a 404 I think.",106517,2,Low,False
34.8136539814241,8.482645007449516,2.068604940508628,-3.5658735298061037,-4.28118094537321,0.8516081616592628,-3.803856427522763,0.6044749406378563,5.316142611299385,-0.9676686873419267,-1.2239757956326867,1.5846822557316218,1.4443355688485386,-2.4774480681314253,-3.239975056426816,-3.6040775135861187,-0.9973821748429879,5.17064316029153,False,c3,3,"add HTTP monitoring for bromine (Icinga)
https://wikitech.wikimedia.org/wiki/Bromine
https://icinga.wikimedia.org/cgi-bin/icinga/status.cgi?host=bromine&nostatusheader",104948,0,Low,True
3.066161423153075,11.710768579647837,-1.3770085084712047,-6.8019148566422905,4.726206845455549,-5.5071324875696845,-0.47171016842092595,-3.969535586874373,5.644164811215368,0.5329356031111052,3.3699851594430767,3.0618666636956666,-1.2799881967746387,3.1629443389451097,-2.0044909736430694,3.4067202353018167,2.1529614171233833,0.43885843402976765,False,c3,3,"This domain doesn't currently have any HTTP response. Let's either redirect it to www.wikimedia.org, or at least have it respond with the default Apache doc root that indicates it points to a Wikimedia Foundation server.",104735,0,Low,False
5.559797573620287,9.609786274713638,-1.7388857461144216,6.5150057713384015,5.245909661274771,-6.9325153294252075,6.022747384709986,2.1039424878806496,-1.5317103893350712,-0.8194671658613775,-0.40801665255222686,0.8443210155557452,-1.7728604737962552,1.8729030845800692,-1.7694961678780285,-1.2290983342352257,-1.3240131176120724,-0.9161538888039706,False,c3,3,"https://wikimediafoundation.org/wiki/Home#Recent_Wikimedia_blog_posts
make blog links from wmfwiki front page use HTTPS links.
should we also make the blog force HTTPS too now that the wikis are?",104728,0,Low,False
0.4605217636593766,9.682032330381961,0.545506234407366,4.273383938167542,4.905586225640356,2.1395801817338747,-2.328970028754556,-0.5200509235901816,-2.9990266573570317,1.6402975056409819,-1.1408615577900496,1.5873244045359576,-0.7441917952133172,1.8284449123801965,-3.653836646270197,-0.17228830237578063,0.9030266943096754,-1.426930136665701,False,c3,2,"The embedded map on nlwiki (e.g. https://nl.wikipedia.org/wiki/Amsterdam, click on 'kaart' next to the coordinates) uses
https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=nl&uselang=nl¶ms=52_22_0_N_4_54_0_E_type:city(743027)_region:NL&pagename=Amsterdam
which loads tiles from
http://a.tiles.wmflabs.org/osm-no-labels/12/2105/1346.png
which causes a Mixed Content warning. For me, the map does load, but a [[ https://nl.wikipedia.org/w/index.php?title=Wikipedia:De_kroeg&diff=44393416&oldid=44392002 | report at the nlwiki village pump ]] suggests this is not true for everyone.
",103801,-1,Low,False
2.252297917645674,5.988341377428128,6.414725400482997,3.0439867445937727,-4.7656355906011,-6.834043908872625,3.7240112544913933,-3.140377587294213,4.2074481444508125,1.0089635034485482,1.9696755941281041,0.7239504842962565,0.6225200057274676,-1.3332672973377382,2.0021204885141826,-0.9025605328752002,-1.096334315708488,-1.1736389385520773,True,c3,2,"| {F5352772 width=200} | {F5352763 width=200}
| Reset password | Set new password |
Would be helpful to enable users who forgot their passwords to be able to retrieve it for log in through the app.
----
==Related ticket==
https://phabricator.wikimedia.org/T150985
==Prototype==
https://wikimedia.invisionapp.com/share/7J9FKPNPW
==Zeplin==
https://zpl.io/Z21KiN7
Tags: Reset password
==User stories==
//Users with accounts//
As a user with a Wikipedia account I would like to be able to log in to my account on the iOS app, even if I have 2FA enabled. When I forget my password, I would like to be able to reset my password through the app
==Design details==
//Reset password email confirmation (system message)//
| ** Action ** | **Message** | **Color**|
| User resets their password | Temporary password sent via email | Green",103373,-2,Low,False
2.3023657108629174,-5.530303141672057,16.257232376222007,8.453148525837845,-6.151667504876158,-7.319219797334278,-1.7910126949062501,-2.4342612316870467,-1.5930202154214161,-3.3335829264025434,-2.1242165413711738,-0.6137053964755653,5.027597190178649,0.9167356079324289,0.6206705201992353,-0.6650578255233892,0.3642729488798162,-0.6085527400305044,False,c3,2,"For example:
https://tools.wmflabs.org/magnustools/resources/js/common.js line 45
```
function httpsAlert ( id , b4 ) {
if ( window.location.href.match ( /^https:/ ) ) {
var url = window.location.href.replace ( /^https:/ , 'http:' ) ;
var h = '<div id=""https_alert"" class=""alert""><strong>Caveat :</strong> Using https on this page does not work in all browsers, due to downstream http dependencies. ' ;
h += '<a href=""' + url + '"">Use http instead</a>.<a class=""close"" data-dismiss=""alert"" href=""#"">×</a></div>' ;
if ( b4 ) $('#'+id).before ( h ) ;
else $('#'+id).after ( h ) ;
$('#https_alert').alert() ;
}
}
```
",102457,-3,Low,False
-8.664042669506886,13.908630464281849,1.0776254555076576,-14.01861813005741,-18.63039748603289,1.7536581912573632,-2.9734982959452343,12.568798884662064,3.061359869487462,-0.42736616591337473,-1.2364049568838456,-0.7864934589932495,2.497778962782866,-4.038733000524711,0.9947733904193035,-1.8267788038756048,-2.726023447580118,3.332165334183914,False,c3,2,"In line with switching over everything else.
Should be fairly simple to do. ",102367,-3,Low,False
-4.00961649688947,11.526485784413449,-1.3072773122578933,-6.02897926948261,-10.795749816277091,-0.2544918158761472,-0.8180515955710606,-2.290906112168719,12.42937432640524,4.125082364545936,3.323731392021363,5.411861438375161,1.2801152546673817,0.7824359503586802,2.2556520017655215,-2.2416841881371767,-2.151190211520017,-0.6841748770866289,False,c3,2,To facilitate abuse management it'd be good if you could consider allowing **a single script** to work on loginwiki. Jump to: T102254#2193501.,102254,-3,Low,False
-3.466785593276918,1.2076108325400732,1.5238163447522055,0.27392565748799624,0.20468352612360496,-1.8975444473353815,3.1940955646630487,7.132959530784146,-2.7314876718378702,0.43126959975720336,1.0565351530830536,4.47031787257081,1.8015170625132915,-1.8652668344231782,-0.7908686733828718,2.3758422543292887,-0.15537127489732772,-0.19921804275317356,False,c3,1,"Current webservice allows php overrides via
```
if [ ! -r $home/.lighttpd.conf ] || [[ ! $(cat ""$home/.lighttpd.conf"" | grep -P '^(?:[ \t]*fastcgi.server[ \t\+\(=]+"".php""|#no-default-php)') ]]; then
```
This is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.",101998,-4,Low,False
36.60523397190822,3.1934279397854297,2.4208983813467597,-4.55654585003231,3.132173775818505,0.925640173423038,-1.507582407900946,-1.572289425193035,-0.30832282460085936,-1.3781743688821475,-0.7167552238693182,-0.5621271328785645,1.0872516544049309,-2.211741479908208,-1.502004386714959,-0.14965112105082046,-0.022545000394538217,-0.9487808911187263,False,c3,1,"After update from 1.24 series to 1.25, I started having this error on certain pages. Currently the error shows up when I click Upload at the File Upload page (which is Dosya Yükle in Turkish translation), among others.
I did follow documentation on the release notes; MediaWiki was first installed from tarball, then I tried the git-compose install/update method. The psr directory exists in $IP/vendor.
> MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components.MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components.
I can reproduce the error. Mediawiki error report:
> ( ! ) Fatal error: include(): Cannot redeclare class psr\log\loggerinterface in
> /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php on line 412
> Call Stack
> # Time Memory Function Location
> 1 0.0001 241112 {main}( ) ../index.php:0
> 2 2.9770 2424544 MediaWiki->run( ) ../index.php:41
> 3 2.9770 2425104 MediaWiki->main( ) ../MediaWiki.php:414
> 4 3.0107 3203232 MediaWiki->performRequest( ) ../MediaWiki.php:566
> 5 3.0343 3415968 SpecialPageFactory::executePath( ) ../MediaWiki.php:267
> 6 3.0433 3966400 SpecialPage->run( ) ../SpecialPageFactory.php:582
> 7 3.0434 3966496 SpecialUpload->execute( ) ../SpecialPage.php:384
> 8 3.1018 5433712 SpecialUpload->processUpload( ) ../SpecialUpload.php:195
> 9 4.3216 7132504 SpecialUpload->showUploadWarning( ) ../SpecialUpload.php:458
> 10 4.3406 7381440 SpecialUpload->getDupeWarning( ) ../SpecialUpload.php:368
> 11 4.3538 7501392 TraditionalImageGallery->toHTML( ) ../SpecialUpload.php:748
> 12 4.3599 7838880 Linker::processResponsiveImages( ) ../TraditionalImageGallery.php:136
> 13 4.3625 7842584 File->transform( ) ../Linker.php:895
> 14 4.3644 7858520 File->generateAndSaveThumb( ) ../File.php:1079
> 15 4.3647 7860640 TransformationalImageHandler->doTransform( ) ../File.php:1112
> 16 4.3658 7866960 BitmapHandler->transformImageMagick( ) ../TransformationalImageHandler.php:244
> 17 4.3658 7868760 TransformationalImageHandler->getMagickVersion( ) ../Bitmap.php:91
> 18 4.3659 7869648 wfDebug( ) ../TransformationalImageHandler.php:517
> 19 4.3659 7870024 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1055
> 20 4.3659 7870120 interface_exists ( ) ../LoggerFactory.php:97
> 21 4.3659 7870440 Composer\Autoload\ClassLoader->loadClass( ) ../LoggerFactory.php:0
> 22 4.3659 7870440 Composer\Autoload\includeFile( ) ../ClassLoader.php:301
> MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components.MediaWiki requires the PSR-3 logging library to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see mediawiki.org for help on installing the required components.
> ( ! ) Fatal error: MediaWiki requires the <a href=""https://github.com/php-fig/log"">PSR-3 logging library</a> to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user. Please see <a href=""https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries"">mediawiki.org</a> for help on installing the required components. in /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php on line 107
> Call Stack
> # Time Memory Function Location
> 1 0.0001 241112 {main}( ) ../index.php:0
> 2 2.9770 2424544 MediaWiki->run( ) ../index.php:41
> 3 2.9770 2425104 MediaWiki->main( ) ../MediaWiki.php:414
> 4 3.0107 3203232 MediaWiki->performRequest( ) ../MediaWiki.php:566
> 5 3.0343 3415968 SpecialPageFactory::executePath( ) ../MediaWiki.php:267
> 6 3.0433 3966400 SpecialPage->run( ) ../SpecialPageFactory.php:582
> 7 3.0434 3966496 SpecialUpload->execute( ) ../SpecialPage.php:384
> 8 3.1018 5433712 SpecialUpload->processUpload( ) ../SpecialUpload.php:195
> 9 4.3216 7132504 SpecialUpload->showUploadWarning( ) ../SpecialUpload.php:458
> 10 4.3406 7381440 SpecialUpload->getDupeWarning( ) ../SpecialUpload.php:368
> 11 4.3538 7501392 TraditionalImageGallery->toHTML( ) ../SpecialUpload.php:748
> 12 4.3599 7838880 Linker::processResponsiveImages( ) ../TraditionalImageGallery.php:136
> 13 4.3625 7842584 File->transform( ) ../Linker.php:895
> 14 4.3644 7858520 File->generateAndSaveThumb( ) ../File.php:1079
> 15 4.3647 7860640 TransformationalImageHandler->doTransform( ) ../File.php:1112
> 16 4.3658 7866960 BitmapHandler->transformImageMagick( ) ../TransformationalImageHandler.php:244
> 17 4.3658 7868760 TransformationalImageHandler->getMagickVersion( ) ../Bitmap.php:91
> 18 4.3659 7869648 wfDebug( ) ../TransformationalImageHandler.php:517
> 19 4.3659 7870024 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1055
> 20 4.3659 7870120 interface_exists ( ) ../LoggerFactory.php:97
> 21 4.3659 7870440 Composer\Autoload\ClassLoader->loadClass( ) ../LoggerFactory.php:0
> 22 4.3659 7870440 Composer\Autoload\includeFile( ) ../ClassLoader.php:301
> 23 4.3676 7880328 MWExceptionHandler::handleFatalError( ) ../MWExceptionHandler.php:0
> 24 4.3676 7866992 MWExceptionHandler::logError( ) ../MWExceptionHandler.php:265
> 25 4.3678 7869072 wfDebugLog( ) ../MWExceptionHandler.php:507
> 26 4.3678 7869608 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1155
> 27 4.3678 7870160 trigger_error ( ) ../LoggerFactory.php:107
> 28 4.3678 7871592 MWExceptionHandler::handleError( ) ../LoggerFactory.php:107
> 29 4.3679 7883192 MWExceptionHandler::logError( ) ../MWExceptionHandler.php:222
> 30 4.3680 7886192 wfDebugLog( ) ../MWExceptionHandler.php:507
> 31 4.3680 7887656 MediaWiki\Logger\LoggerFactory::getInstance( ) ../GlobalFunctions.php:1155
> 32 4.3680 7888208 trigger_error ( ) ../LoggerFactory.php:107
>
And Apache error when I try/refresh the relevant page(s):
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Fatal error: include(): Cannot redeclare class
> psr\\log\\loggerinterface in /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php on line 412, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Stack trace:, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 1. {main}() /srv/www/mywiki.mydomain.com/index.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 2. MediaWiki->run() /srv/www/mywiki.mydomain.com/index.php:41, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 3. MediaWiki->main() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:414, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 4. MediaWiki->performRequest() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:566, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 5. SpecialPageFactory::executePath() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:267, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 6. SpecialPage->run() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPageFactory.php:582, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 7. SpecialVersion->execute() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPage.php:384, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 8. SpecialVersion->getExtensionCredits() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:129, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 9. SpecialVersion->getExtensionCategory() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:463, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 10. SpecialVersion->getCreditsForExtension() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:637, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 11. GitInfo->getHeadCommitDate() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:743, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 12. wfShellExec() /srv/www/mywiki.mydomain.com/includes/GitInfo.php:218, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 13. wfDebug() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:2802, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 14. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1055, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 15. interface_exists() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:97, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 16. Composer\\Autoload\\ClassLoader->loadClass() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 17. Composer\\Autoload\\includeFile() /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php:301, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Fatal error: MediaWiki requires the <a href=""https://github.com/php-fig/log"">PSR-3 logging library</a> to be present. This library is not embedded directly in MediaWiki's git repository and must be installed separately by the end user.\n\nPlease see <a href=""https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries"">mediawiki.org</a> for help on installing the required components. in /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php on line 107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP Stack trace:, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 1. {main}() /srv/www/mywiki.mydomain.com/index.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 2. MediaWiki->run() /srv/www/mywiki.mydomain.com/index.php:41, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 3. MediaWiki->main() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:414, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 4. MediaWiki->performRequest() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:566, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 5. SpecialPageFactory::executePath() /srv/www/mywiki.mydomain.com/includes/MediaWiki.php:267, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 6. SpecialPage->run() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPageFactory.php:582, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 7. SpecialVersion->execute() /srv/www/mywiki.mydomain.com/includes/specialpage/SpecialPage.php:384, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 8. SpecialVersion->getExtensionCredits() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:129, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 9. SpecialVersion->getExtensionCategory() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:463, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 10. SpecialVersion->getCreditsForExtension() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:637, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 11. GitInfo->getHeadCommitDate() /srv/www/mywiki.mydomain.com/includes/specials/SpecialVersion.php:743, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 12. wfShellExec() /srv/www/mywiki.mydomain.com/includes/GitInfo.php:218, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 13. wfDebug() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:2802, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 14. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1055, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 15. interface_exists() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:97, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 16. Composer\\Autoload\\ClassLoader->loadClass() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 17. Composer\\Autoload\\includeFile() /srv/www/mywiki.mydomain.com/vendor/composer/ClassLoader.php:301, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 18. MWExceptionHandler::handleFatalError() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:0, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 19. MWExceptionHandler::logError() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:265, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 20. wfDebugLog() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:507, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 21. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1155, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 22. trigger_error() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 23. MWExceptionHandler::handleError() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 24. MWExceptionHandler::logError() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:222, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 25. wfDebugLog() /srv/www/mywiki.mydomain.com/includes/exception/MWExceptionHandler.php:507, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 26. MediaWiki\\Logger\\LoggerFactory::getInstance() /srv/www/mywiki.mydomain.com/includes/GlobalFunctions.php:1155, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
> [Thu May 28 06:55:06 2015] [error] [client 192.168.1.1] PHP 27. trigger_error() /srv/www/mywiki.mydomain.com/includes/debug/logger/LoggerFactory.php:107, referer: http://mywiki.mydomain.com/index.php/%C3%96zel:%C3%96zelSayfalar
>
",101814,-4,Low,False
-0.12556444272351275,-5.710308051458378,5.613336873254859,0.03916337921810009,10.042621619029282,-5.030292786369061,-2.5537177975539653,-11.96232073023349,2.2982843252004654,-3.233464216848667,0.8048878037432519,-4.544205998841606,2.7185598366907553,-6.8498856440833995,0.3771774570396875,-4.10347058656029,1.2685367711993896,1.323410066440453,False,c3,1,"I got the following error:
```
======================================================================
ERROR: test_follow_redirects (tests.http_tests.TestHttpStatus)
Test follow 301 redirects after an exception works correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File ""/home/xzise/Programms/pywikibot/core/tests/http_tests.py"", line 185, in test_follow_redirects
http.session.redirect_cache.get('http://en.wikipedia.org/wiki/Main%20Page'))
File ""/home/xzise/.pyenv/versions/3.4.3/lib/python3.4/unittest/case.py"", line 1053, in assertIn
if member not in container:
TypeError: argument of type 'NoneType' is not iterable
```",101601,-4,Low,True
-1.0044179098635997,14.600005487295856,-2.176173718315228,-1.1839996753607929,-1.0727740096288105,0.7305294488138645,1.2335739758615025,3.7746793207735934,-3.121195984966591,-2.1297591162373646,-1.7437947362565713,0.9407725925128181,0.03868363799665442,-2.1352725924053515,1.559301182460831,-1.963970579148325,-0.7767794604430641,-2.508752180213752,False,c3,1,"user_config.authenticate was a #pywikibot-compat feature, recently re-implemented in core T89417. With the switch to requests, this has been unimplemented again.
The fallback is to use netrc to specify the basic auth credentials instead of user_config.
http://docs.python-requests.org/en/latest/user/authentication/#netrc-authentication
I am not sure if/how that works on Windows.",101494,-4,Low,True
-3.527824930651844,9.659633528257086,5.551887933487976,1.7688729325815564,4.4409815666021615,6.970752652917402,-3.82918315480585,1.451542294510125,1.2096191035693091,-1.2099574699936904,0.0059719242179139265,-2.0303656094504703,1.5436236413549929,0.4273823368745209,-4.290384141851584,-2.5806327632837256,0.32712387170296764,0.27747634594616977,False,c3,1,"After T98671, the following occurs:
```
C:\pwb\core>pwb.py redirect double -moves -total:10 -always -lang:pa
ImportError: No module named requests
Python module requests is required.
Try running 'pip install requests'.
```
Not a good idea to break the bot without any hint!",101228,-5,Low,False
-5.162843613187012,5.697985525008221,-1.2841184274978925,-6.896603850269689,2.167683518974736,-4.150361107214305,-0.6711910799610754,4.110298623437665,-1.2837147542690692,1.6142549886424753,3.8112939817145253,0.6295809969413673,-2.1935476625438994,0.7304500135818133,-0.7712389292762323,-1.5960668059649463,-3.3170085136484264,-2.6854271239254635,False,c3,1,"http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&type=signup
says
""This wiki does not share accounts with normal Wikimedia infrastructure. It is also not secure. When registering, please create a UNIQUE password for this site only. Consider if you feel safe if everyone in the world knew this password, because it might be easily intercepted. <loginstart> ""
",100800,-5,Low,True
4.083363901643715,7.861872803721656,14.753485798222908,0.13222300089703398,11.831722681583612,1.9185979381688634,1.2684865079412333,-5.302582412981535,2.8537080484574133,1.838464008256767,4.687613580699303,-1.7964953821536436,0.8778830881171866,1.2714456541662287,-0.8908586718451383,2.1097317887819846,-1.8836007108030506,-3.0020781577519564,True,c3,1,"It shows the Wikimedia Foundation logo on the MediaWiki.org login screen. It should show the MediaWiki.org logo (https://www.mediawiki.org/static/images/project-logos/mediawikiwiki.png, maybe without the text).",100633,-5,Low,True
-14.04649398378736,12.993193409510447,9.350700003078046,12.511389860312557,7.645375209766158,8.232794066993796,-1.4854232104623097,-2.9453766017665703,5.1124878019650195,-3.266138865115346,-3.5339063568289344,5.905035396561125,-3.681178818260567,2.8911075253954586,2.065560546629561,-3.3699806857362926,3.7431068769093576,-2.3477565896294608,False,c3,1,The create account screen has the option to display the password entered. This task is to duplicate that functionality for the login screen.,99680,-7,Low,True
4.863169045107426,-12.927921783796853,9.312774066277111,4.310912976583843,0.3759474399554057,-5.495519209854509,-2.533477930167448,-1.8897944267464797,0.10285248645763562,-2.8525600651607266,-2.0462235367669326,0.24790889433554741,2.292168471265775,-4.078068617985466,-3.0954235032892576,0.23212211313224715,-0.7308760088513965,-1.219934679652385,False,c3,1,"```
>>> import pywikibot
Error: Python module httplib2 >= 0.6.0 is required.
>>>
```",99370,-7,Low,True
15.282848845752302,-8.259701447049348,-12.485474480227452,1.1919166027171366,-0.48977028744276646,-1.6594041612939459,-6.036677137193071,-0.566415791008772,-2.424149775387849,-5.925687815589758,-1.284771242264759,-1.4140312678407998,8.961298630259467,5.762656339864735,3.1292655477913973,-0.4147628835496938,0.07286638635622333,0.1509324355401691,False,c3,1,"//[[https://en.wikipedia.org/wiki/Special:Contributions/92.137.107.192|92.137.107.192]] ([[ https://en.wikipedia.org/wiki/User talk:92.137.107.192|talk]]) 15:24, 17 June 2013 (UTC) wrote://
**Exception:**
```
ApiErrorException
```
**Message:**
```
Bot API returned the following error: 'The login module requires a POST request'
```
**Call stack:**
```
à WikiFunctions.API.ApiEdit.CheckForErrors(String xml, String action)
à WikiFunctions.API.ApiEdit.Login(String username, String password, String domain)
à WikiFunctions.Profiles.AWBProfilesForm.PerformLogin(String username, String password)
```
----
**OS:** Microsoft Windows NT 6.2.9200.0
**Version:** AutoWikiBrowser (5.5.0.2), WikiFunctions (5.5.0.2), revision 9117 (2013-04-30 20:44:43)<br>AutoWikiBrowser (5.5.5.0), WikiFunctions (5.5.5.0), revision 10470 (2014-09-22 01:51:36)
**NET:** 2.0.50727.6400
**Site:** http://dc-comics.wikia.com",99270,-7,Low,True
-3.1025711796448743,3.7082307926695464,6.417433995226862,1.9076976874139229,2.015363164113174,-4.810504930103088,1.364843941259914,4.656023458442167,0.06906033855798682,-1.443824393859508,-0.8037848998472232,1.0788541069206763,-1.3141888091630483,-1.636272866214191,1.5162076817445955,3.619860137130688,-0.12366589775014569,0.873797969019902,False,c3,1,"HTTP->HTTPS redirects need to unconditional send Vary header instead of only sending it in the redirect case.
E.g. operations/puppet.git/templates/apache/sites/gdash.wikimedia.org.erb
Has: `Header always merge Vary X-Forwarded-Proto env=ProtoRedirect`
But should instead be: `Header always merge Vary X-Forwarded-Proto` (and `,E=ProtoRedirect` from the rewrite rule can be dropped)
Otherwise requesting https://gdash.wikimedia.org will populate the varnish cache also for http://gdash.wikimedia.org which then won't serve the redirect until it is refreshed.
There are probably more instances of this error.",98990,-8,Low,False
-13.70132388942175,11.951003089458705,2.479778887127452,1.7881576081302697,-8.13214793956221,-5.919668058987367,1.7054921243916352,2.5573250051828196,3.215786573691701,0.43381224792915507,-0.5425379536640755,0.6402579067400858,0.06638937234196973,0.35772576009040513,-1.2783280616623083,-1.0080273334742715,2.9864342962080705,-1.6609287251779963,False,c3,1,"Is suggested for use by people who don't want lighttpd to load up php by default. We should just migrate these folks to more specific-to-their-toolset servers, or provide a no-php variant of lighttpd. ",98818,-8,Low,False
-4.366233861124087,4.996612891003167,1.8910894165850145,-0.8997588863731918,-1.069789513778157,-0.6152505911478703,-0.5620142631339817,-2.4684669237477985,0.7639189387709442,1.0586639852163922,0.7309224115679274,0.5187968013202839,2.1779220281033673,-3.2706707591922086,1.2225683257707622,-2.337149957025409,1.4887353184107577,-0.29630223228204233,False,c3,3,"It took me 10 minutes to find where to login. I almost gave up. I scrolled up and down the Phabricator task page I happened to be on. I went to the Phabricator home page. I clicked many buttons and links on the page. Finally, I clicked the arrow at the top right, and was able to login. None of the icons at the top of Phabricator pages have tooltips. See related task: T95233 ""Most of the VE editing toolbar buttons are unlabeled icons, which can reduce usability. Some are without tooltips, too."" ",113927,12,Lowest,False
-7.767816349774032,9.288811664071961,0.24621018739077272,-11.384660676535468,4.248497661941949,-5.517832488519577,3.0977290642928788,-3.399800982433312,-1.309454329183649,-1.1027963575810213,1.322683100142093,-1.396865774834682,0.176936371541367,0.7821424642231376,0.8378909014553946,-0.9004513539883634,-0.9761328425131754,-1.4683001725550318,False,c3,3,"Hello,
every few weeks I get an “ssl_error_inappropriate_fallback_alert” when I try to connect to a Wikipedia. If I reload, the error is gone. So my guess is that one of the servers is not in sync with the others, but it might be something else.
Unfortunately I’m not able to debug it, because I have no further information than the error-page.
Maybe someone else encounters something similar, then he/she can add to this bug.
",108579,5,Lowest,False
1.5608400850230404,2.404713287994383,1.2143247504252912,0.1697844515287863,-1.9260889498179388,-0.021068722253237304,-1.7032959536462773,0.7043868995427467,-1.0175922440987664,-2.5270814467366223,-0.2599194796384663,3.4396901644868736,1.9033752681831588,0.547115409702263,0.2504947008126983,-1.920130306228495,0.15202445044261914,0.8181233079490562,False,c3,3,"# What is wrong
{F191197}
Window 1
{F191195}
Window 2
{F191192}
Window 3
There is no publisher (Swedish: //Utgivare//) designated when installing Huggle. It says Unknown (Swedish: //Okänd//) This is causing Windows SmartScreen (or whatever it is called) to try to put up a fight when installing this file.
# How to fix
[ ] Someone need to purchase a certificate for this purpose from certification authority that is trusted by Microsoft by default (around $600 for 3 years or $1000 (better variant))
[ ] Once the certificate in .pfx format is available to people trusted with Huggle releases and distribution (see https://github.com/orgs/huggle/teams/release-managers) use this guide to sign the .exe files: https://stackoverflow.com/questions/84847/how-do-i-create-a-self-signed-certificate-for-code-signing-on-windows
# Resources
* https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate",105560,1,Lowest,
-0.3388144382023892,0.6870592325033833,-7.1442673537065,4.1004599187478075,1.6218422818373628,4.9400748670865156,1.414431619877221,2.504528230215373,0.9270125315606565,0.1464734969809376,0.9726770604662636,-0.655442294762557,1.539448391736434,-3.2572222541067912,-0.11102828618461924,-4.231346901923951,-0.8164271596012607,1.2302640706817998,False,c3,1,"/usr/local/bin/lighttpd-starter allows overriding the php configuration, by only inserting the standard config if:
```
if [ ! -r $home/.lighttpd.conf ] || [[ ! $(cat ""$home/.lighttpd.conf"" | grep -P '^(?:[ \t]*fastcgi.server[ \t\+\(=]+"".php""|#no-default-php)') ]]; then
```
This should be documented.",101994,-4,Lowest,False
5.221375549611826,7.010458623904842,17.505413477515695,-1.0030158828634588,-6.271490426746741,-3.2732893163571584,-1.3678779638754657,2.5162494814437117,-1.0446614317821057,-2.4157505077583683,-3.1018862676872074,1.16390079336224,-0.18379819133811282,-1.1278638881673184,-3.1796450715947797,0.01609883559701608,-1.3241736385846077,1.9973695431975862,False,c3,1,"Going to http://tools.wmflabs.org/xtools redirects to http://tools.wmflabs.org/xtools/articleinfo/? which gives
```
301 Moved Permanently
This tool has moved to a new location. You will be redirected to tools.wmflabs.org/xtools-articleinfo/index.php? shortly.
```
http://tools.wmflabs.org/xtools should redirect to http://tools.wmflabs.org/xtools-articleinfo/index.php instead.",100015,-6,Lowest,False
14.736222500329035,14.665141371928488,12.90856355444199,-1.991533398848005,-6.686393223592535,-1.047809378393625,-1.6767615854569282,0.4620908050473549,-0.5055344938588843,-2.1817927908810413,-1.313471835165139,-4.9067345167648115,-1.7630497093087003,-1.3851630149424565,0.11250603941411974,-0.030582621556691558,-0.633125305190669,0.2753107415413212,False,c3,1,"Successfully setup LanguageTool HTTP server on Labs.
1. Place request for a Labs instance.
Set up a server on Tools for now. Will relocate it to Labs as and when required.
Server : http://tools.wmflabs.org/languageproofing/
UI for testing : http://tools.wmflabs.org/languageproofing-ui/",99218,-7,Lowest,True
3.3353655960025086,8.544206712597383,0.735021113104871,-3.2997889268025555,-0.5530501478565631,3.7303508491184907,-1.2193642158512832,-3.858862515660444,1.565113839472527,-1.1313872831455667,0.3077281950421362,-2.6913552607611937,1.122756771550987,-1.0139059395245469,0.5655055764965624,-1.4417964520653752,0.507976237229103,-1.148335958937619,False,c3,1,"I created a new user in our LDAP server since updating to the most recent MediaWiki. I use the ldapauthentication extension. But when the user tried to login, I got
**PHP Fatal error: Call to a member function toString() on a non-object in /var/www/html/includes/User.php on line 3493**
which turned out to be
```
'user_password' => $this->mPassword->toString(),
```
Adding in a check to see if the string is in fact empty, solved the issue:
```
'user_password' => ($this->mPassword === """" ? """" : $this->mPassword->toString()),
```
Please integrate this into MediaWiki. Thanks!",98600,-8,Lowest,False
-5.354672992622065,-2.5235127101490793,0.43816437182579193,0.23362255156516865,6.846760539945299,-6.223025925793796,1.1868606087709717,9.156844856011043,-3.483935773353145,-1.4209136230704158,-2.018875882964291,7.333423639718112,1.8748540259481472,-1.2358462398836139,2.663263079572057,3.8110929349051643,4.47499355606063,1.7433853667537222,False,c3,1,"``` # Trustworthy enough
# Only necessary on precise hosts, trusty has its own mariadb package
if $::lsbdistcodename == 'precise' {
apt::repository { 'mariadb':
uri => 'http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu',
dist => $::lsbdistcodename,
components => 'main',
source => false,
keyfile => 'puppet:///modules/toollabs/mariadb.gpg',
}
file { '/etc/apt/trusted.gpg.d/mariadb.gpg':
ensure => absent,
}
}```
This code is in toollabs/init.pp, and is probably unsafe and should be killed (the URL doesn't even support https)",98575,-8,Lowest,False
1.0297955303986766,-1.7679637846262377,-5.415872525396917,-3.058591815047671,2.42728335003028,-7.625185808783244,1.5096043480394332,3.239540035450745,2.9283979557289816,-0.8183427148397464,0.815082590761429,0.3870783688520849,2.4835225884823577,0.24046198443669464,-0.7979084736464257,-0.4104564786484777,-1.7302458938629846,-2.2308498296140673,False,c3,1,"`ssl` module may need strict checking:
````
m> env PATH= /usr/local/bin/python2.7 version.py
Retreving commit log from https://tools.wmflabs.org/pywikibot/gitlog.txt
Traceback (most recent call last):
File ""version.py"", line 20, in <module>
pywikibot.output('Pywikibot: %s' % getversion())
File ""/home/saper/wikipedia/compat/pywikibot/version.py"", line 46, in getversion
data = dict(getversiondict()) # copy dict to prevent changes in 'chache'
File ""/home/saper/wikipedia/compat/pywikibot/version.py"", line 70, in getversiondict
(tag, rev, date, hsh) = getversion_git(_program_dir)
File ""/home/saper/wikipedia/compat/pywikibot/version.py"", line 192, in getversion_git
rev, date = getversion_git_windows(hsh, path)
File ""/home/saper/wikipedia/compat/pywikibot/version.py"", line 111, in getversion_git_windows
ff = urllib2.urlopen(url).read().splitlines()
File ""/usr/local/lib/python2.7/urllib2.py"", line 154, in urlopen
return opener.open(url, data, timeout)
File ""/usr/local/lib/python2.7/urllib2.py"", line 431, in open
response = self._open(req, data)
File ""/usr/local/lib/python2.7/urllib2.py"", line 449, in _open
'_open', req)
File ""/usr/local/lib/python2.7/urllib2.py"", line 409, in _call_chain
result = func(*args)
File ""/usr/local/lib/python2.7/urllib2.py"", line 1240, in https_open
context=self._context)
File ""/usr/local/lib/python2.7/urllib2.py"", line 1197, in do_open
raise URLError(err)
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>
````
Workaround: [list of certificate authorities you trust](http://curl.haxx.se/ca/cacert.pem) `SSL_CERT_FILE`
I think SSL certificates could/should be supplied attached to the family files, not sure where else do we connect to (tools.wmflabs.org, anything else?...)",98104,-9,Lowest,False
2.442468708498384,-7.01085877818671,9.11656504728428,2.772112489643872,-5.826800608214802,-4.232665597214984,-5.565407495474521,-1.002617876513877,-2.7516315692825017,-4.104674545098278,0.9979440660160255,-1.2136329871256204,-1.2606520201937732,-3.778519715437044,-1.7173869923253817,3.285907804531036,-1.299099932892205,-1.087283675760537,False,c3,1,"In specialuserlogin.php:
```
$u = User::newFromName( $this->mUsername );
// Give extensions a way to indicate the username has been updated,
// rather than telling the user the account doesn't exist.
if ( !Hooks::run( 'LoginUserMigrated', array( $u, &$msg ) ) ) {
$this->mAbortLoginErrorMsg = $msg;
return self::USER_MIGRATED;
}
if ( !( $u instanceof User ) || !User::isUsableName( $u->getName() ) ) {
return self::ILLEGAL;
}
```
Hook immediately calls `$centralUser = CentralAuthUser::getInstance( $user );`.",96145,-12,Unbreak Now!,True
-10.896472642929332,8.30172861209888,-4.18008456307585,-4.999019172250456,2.818828593232413,-4.177257301040555,-1.4081988365745373,-0.7360016695425446,0.5191097144371832,-2.069442874952454,-2.2874840872174493,-2.6678654716244274,0.11163169921449789,-2.3907277368859456,-0.597332313328593,0.1939332594926645,1.3600253378696692,2.6312540419743886,False,c3,1,"Basically if citoid isn't running, and you try to insert a url, the dialog stays pending indefinitely and the cancel button doesn't work.
So, previously I dealt with this bug by stopping the dialog pending directly in the error case of the request, even though it was also in always. The ""always"" case doesn't seem to be working here.
I remember in code review though we took that out (because it was in always and should have been working) and I seem to remember testing it at the time and not finding a problem, but I might have been mistaken.
Ed, any ideas? I'll probably patch this in the meantime by putting the push pending back in the error condition, but it seems hacky. ",88897,-21,Unbreak Now!,True
31.42209458053639,8.758816647738026,19.321670209256176,0.28552970570392877,7.311898564562451,4.1538932427461175,-2.244195215427404,-2.7411138033903875,-2.590860941588857,-1.427889991247275,-1.1598926450005786,1.823550077875691,-0.2702302526604372,-0.06593228103886695,-3.439688043848208,-0.6240951302877095,2.1494381665204445,-1.6981297136293139,False,c3,1,"For these URLs, Citoid ignores the HTTP errors:
http://www.google.com/soyouthinkthispagereallyexistsright?
http://example.com/404
http://httpstat.us/403",88884,-21,Unbreak Now!,True
8.362349767535466,-7.240603328745458,8.379196360653893,-0.6312129560108428,2.5725598489023866,-4.533600132725917,-13.615658474022673,1.2525585098213727,-4.598783697733955,-5.115422442335411,15.215895305252417,0.8206150357819786,-6.043824868456729,4.209381900808367,4.870591874174996,-1.4116271358213475,2.083637622839851,0.20199494198482326,False,c3,1,"The following servers don't send the intermediate certificate: RapidSSL SHA256 CA - G3. It can be downloaded from http://gv.symcb.com/gv.crt.
[X] rt.wikimedia.org
[X] wikitech-static.wikimedia.org
[X] etherpad.wikimedia.org
[1] https://www.ssllabs.com/ssltest/analyze.html?d=rt.wikimedia.org
[2] https://www.ssllabs.com/ssltest/analyze.html?d=wikitech-static.wikimedia.org
[3] https://www.ssllabs.com/ssltest/analyze.html?d=etherpad.wikimedia.org",88507,-22,Unbreak Now!,True
6.99593512952047,9.02926629369049,7.079944689563426,7.5691484585827595,-8.208772244420217,-2.4093513654556817,-2.4019912377326333,-1.2560223224283162,0.3713503059294354,-3.375089482341152,-2.173520415834391,-0.47013968350655067,4.523982261475881,1.228758901472835,0.41570281314926927,-3.6822183409816396,0.37755537941275175,2.2525137060412606,False,c3,1,"Getting this error while trying to load any page in Betalabs
Error loading data from server: 503: parsoidserver-http: HTTP 503
{F28851}",86951,-24,Unbreak Now!,True
5.08643347991859,1.7967159517410103,0.4024940899090943,2.785294943008677,-4.699011079690132,-3.014698099565524,-4.127095641145296,-1.0314592333050436,-2.0602880255595357,3.639597215233362,-3.150025918344151,1.7373331832245438,-0.18365175028852843,2.464809932125359,0.8616132922191513,-1.065148504542144,1.8806888029605526,1.8240539977035175,False,c3,1,"Somteimes, MobileFrontens qunit job fails due to the following error:
20:11:02 ERROR: Failed to archive artifacts: log/*
20:11:02 java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: request to write '2315' bytes exceeds size in header of '2262' bytes for entry 'log/mw-debug-www.log'
Examples:
https://integration.wikimedia.org/ci/job/mwext-MobileFrontend-qunit-mobile/8100/consoleFull
https://integration.wikimedia.org/ci/job/mwext-MobileFrontend-qunit-mobile/8078/consoleFull
https://integration.wikimedia.org/ci/job/mwext-MobileFrontend-qunit-mobile/8076/consoleFull
Jenkins is voting -2 and prevent from merging changes :( It seems to be not a problem of MobileFrontends codebase, or?",78590,-29,Unbreak Now!,True
18.60645350678072,11.03169559991581,12.085418477040179,-4.078675848623785,-4.30738729167148,-0.4680025311496169,-4.669334336279722,-2.3386301849816338,3.787636391334262,1.1821604827224172,-1.3609918869682924,0.6559477231801158,1.2365730066929643,-0.4527249888035403,-0.5791637364463078,-0.0948138982746215,0.12333392122141107,1.4313867774892037,False,c3,1,"How to reproduce:
# Log out of WM Phab and your SUL WM account.
# Navigate to https://phabricator.wikimedia.org
# Press the button ""Login or Register (MediaWiki)""
Result:
After about 15s, an error page with the following contents appears:
> WIKIMEDIA FOUNDATION
> Error
> Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
> If you report this error to the Wikimedia System Administrators, please include the details below.
> Request: POST http://phabricator.wikimedia.org/auth/login/mediawiki:mediawiki/, from 10.64.0.172 via cp1044 cp1044 ([10.64.0.172]:80), Varnish XID 1595403262
> Forwarded for: <redacted>, 10.64.0.172
> Error: 503, Service Unavailable at Thu, 11 Dec 2014 01:11:25 GMT
Expected: Request to log me in into MediaWiki.org",78223,-29,Unbreak Now!,True
-5.1713215196156685,2.853404115730253,-1.9838528501771364,-1.8598503464634484,0.5289198845684753,-1.1698505237746426,0.7284909504754475,0.11172211607528693,2.5511606048301694,0.31801930773880915,2.05120424817189,0.012613850918639313,2.633809641355028,-2.0199020435465256,1.536117869482493,1.2184159368909389,1.043273754441733,0.7242006216803232,False,c3,3,"We recently installed MediaWiki 1.25. Around the same time, a sister project added a wiki. Both projects failed to enable wgSecureLogin and wgCookieSecure, and plain text passwords were used in subsequent logins.
According to documentation, the wiki installer is supposed to make a copy of DefaultSettings.php and provide them LocalSettings.php. We can edit LocalSettings.php, but we are not supposed to modify DefaultSettings.php (https://www.mediawiki.org/wiki/Manual:Configuration_Settings and https://www.mediawiki.org/wiki/Manual:LocalSettings.php).
However, LocalSettings.php did not have wgSecureLogin, wgCookieHttpOnly and wgCookieSecure configuration settings that were present in DefaultSettings.php.
I can't help but feel if the installer copied the settings, then it would have alerted me (and the sister project's administrator) to tune the configuration. In their absence, I (and the sister project's administrator) incorrectly assumed MediaWiki did the right thing and had a secure default.
To be clear, folks who run an HTTPS server expect something like the following to be secure and consistent with best practices:
$wgSecureLogin = true;
$wgCookieHttpOnly = true;
$wgCookieSecure = detect;
It would probably be a very good idea to ensure wgSecureLogin, wgCookieHttpOnly and wgCookieSecure are present in LocalSetttings.php created in the field, with appropriate comments stating when to change `wgSecureLogin = false` to `wgSecureLogin = true`.",111135,8,Needs Triage,
-5.1713215196156685,2.853404115730253,-1.9838528501771364,-1.8598503464634484,0.5289198845684753,-1.1698505237746426,0.7284909504754475,0.11172211607528693,2.5511606048301694,0.31801930773880915,2.05120424817189,0.012613850918639313,2.633809641355028,-2.0199020435465256,1.536117869482493,1.2184159368909389,1.043273754441733,0.7242006216803232,False,c3,3,"We recently installed MediaWiki 1.25. Around the same time, a sister project added a wiki. Both projects failed to enable wgSecureLogin and wgCookieSecure, and plain text passwords were used in subsequent logins.
According to documentation, the wiki installer is supposed to make a copy of DefaultSettings.php and provide them LocalSettings.php. We can edit LocalSettings.php, but we are not supposed to modify DefaultSettings.php (https://www.mediawiki.org/wiki/Manual:Configuration_Settings and https://www.mediawiki.org/wiki/Manual:LocalSettings.php).
However, LocalSettings.php did not have wgSecureLogin, wgCookieHttpOnly and wgCookieSecure configuration settings that were present in DefaultSettings.php.
I can't help but feel if the installer copied the settings, then it would have alerted me (and the sister project's administrator) to tune the configuration. In their absence, I (and the sister project's administrator) incorrectly assumed MediaWiki did the right thing and had a secure default.
To be clear, folks who run an HTTPS server expect something like the following to be secure and consistent with best practices:
$wgSecureLogin = true;
$wgCookieHttpOnly = true;
$wgCookieSecure = detect;
It would probably be a very good idea to ensure wgSecureLogin, wgCookieHttpOnly and wgCookieSecure are present in LocalSetttings.php created in the field, with appropriate comments stating when to change `wgSecureLogin = false` to `wgSecureLogin = true`.",111135,8,Needs Triage,
5.834174479673335,6.496101399272071,4.4786476843866865,-2.3078148674517203,0.2221719131114569,-4.851831477200155,4.585991144851083,-1.6388696789983763,-2.2972501249865083,1.723823870522895,2.2359858012004,0.8777527308943116,0.39766720248583187,1.582326523241404,-2.504232408468879,-0.6372872550149652,0.05468944562281575,-1.270695281766462,False,c3,1,"I used SauceLabs to test a feature in IE7 on Windows XP. Although Resource Loader does not support this browser, anonymous browsing of regular wiki pages works fine. When I visit http://en.wikipedia.org/w/index.php?title=Special:UserLogin , it fails with IE7's generic error page
> **Internet Explorer cannot display the webpage**
> Most likely causes:
> - You are not connected to the Internet.
> - ...
I also get this generic error page I try to visit https://en.wikipedia.org/wiki/Sheep and the login page redirects to https, so maybe it's actually an https issue. IE7 doesn't show what net error it receives.
I can visit other https sites in the same SauceLabs browser setup, so I'm not sure why login and https fail on Wikimedia sites. IE8 on WIndows XP on SauceLabs, which RL does support, fails the same way, while IE8 on Windows 7 on SauceLabs is fine.",97701,-9,Needs Triage,False
12.233514446953597,5.091343891125373,13.79642536940985,2.5246053716267314,3.0188988427029555,4.106048211028325,-2.323228753205973,0.8826658264162696,-2.249594798996419,-0.10035927718120785,6.266716823748732,0.3654526668664766,-0.38351921176401405,-1.2844556926457096,2.518111184433452,-3.786469234226797,-1.6640463655649291,1.2048741616885306,False,c3,1,"On http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow, intermittent errors are displayed when trying to save a Flow entry other than a plain text.
Request url --- http://en.wikipedia.beta.wmflabs.org/w/api.php
http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow
[ec2ce41c] Exception Caught: Failed contacting Parsoid: There was a problem during the HTTP request: 503 Service Unavailable ",97491,-10,Needs Triage,True
-4.109766157493158,8.438113900464216,19.86984762524007,12.242367357705534,3.865409467771849,-4.98533002412757,-0.8226989466350609,-1.5119866220509603,5.04267137606984,0.9768033325443781,-1.410850757092479,-1.3986356559757578,-1.455227941930663,1.0454154246701108,0.0236763191004421,1.4184282083185036,-0.30796893465900443,-2.11691763754592,False,c3,1,"These steps now fail as a result of T95065
* Create failure messages.Create account password mismatch message
* Then I should see a message box at the top of the login page'
https://integration.wikimedia.org/ci/view/BrowserTests/view/MobileFrontend/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/629/testReport/junit/(root)/Login/Not_logged_in/
https://integration.wikimedia.org/ci/view/BrowserTests/view/MobileFrontend/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/629/testReport/junit/(root)/Menus%20open%20correct%20page%20for%20anonymous%20users/Watchlist_URL_is_set_correctly/
",97460,-10,Needs Triage,True
-5.3063627796750925,12.09875989567843,14.51546967415241,14.514249014540882,4.043594262235976,4.0060712624507895,-3.156544340709342,-2.621744618728656,2.8626595202413654,-2.721855628280567,-1.8744880572069977,-0.6710948294505628,-0.07973096065442409,-3.271750301807436,2.1728338307169137,1.5622967278205495,-1.8747869963577366,-0.35220492456183483,False,c3,1,"On a http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow, type a link in the link inspector starting with https.
The lock icon will be displayed:
{F157847}",97337,-10,Needs Triage,True
-6.472968126629816,10.195776133936434,1.416946228385072,-2.518793025420809,6.692758289652888,0.19427058333444802,3.592895446851828,1.8076904684818507,-3.460790100059402,0.27770381300907854,1.7737995733176883,3.8640209294263768,0.592754808231609,1.4024571232084693,-2.705924059016434,-2.6180060338559614,1.823853051102643,-4.334711335941777,False,c3,1,"I have received some informal complaints that indicate that the login page at the shop, is not secure. This should probably redirect to HTTPS.",96749,-11,Needs Triage,False
1.034605895432842,2.056111323855962,-5.979764611050067,3.840257515314887,1.437143475220446,-0.24002291671113896,-0.47584543641932964,-2.4799537754472682,-0.9319315881746585,-1.617256970486499,-0.8527515919528765,0.20177377095007665,1.4788897946382278,-0.6734005635331819,-3.0133983624797906,1.067475834287571,0.36875381920131445,-1.8532497807176407,False,c3,1,"On virt10xx, libvirtd uses a WMF CA-signed wildcard cert for virt*.eqiad.wmnet.
As part of the renaming from virt* to labvirt* we need a new cert for labvirt*.eqiad.wmnet.
https://gerrit.wikimedia.org/r/#/c/204279/ is an attempt to do this, but that cert is self-signed and we need one signed with the WMF CA.
In the meantime, libvirtd.log has sad, repeated notices:
error : virNetTLSContextCheckCertPair:495 : Our own certificate /etc/ssl/localcerts/labvirt-star.eqiad.wmnet.crt failed validation against /etc/ssl/certs/wmf-ca.pem: The certificate hasn't got a known issuer.",96291,-11,Needs Triage,True
5.4341737256398925,6.966532721808964,-0.6484171803249357,-4.179205706748027,0.3111113384565911,-0.822954475501139,2.1752171454721756,1.2711680021220406,1.7056090211418053,1.5798832057622567,3.0845605529075715,4.580646972469122,1.6974978771834524,-2.703604253318854,2.74477620099504,-0.4449739622681531,-2.5017052264012825,0.7953537207863735,False,c3,1,"Currently only custom error messages are possible. It should be possible to customise the message based on the thing you are trying to access
e.g.
http://localhost:8888/w/index.php?title=Special:UserLogin{F113543}
{F113540}
vs
http://localhost:8888/w/index.php?title=Special:UserLogin&returnto=Special:Watchlist
http://localhost:8888/w/index.php?title=Special:UserLogin&returnto=Headings&returntoquery=article_action=watch
{F113547}",96191,-12,Needs Triage,True
-5.7553028526196615,9.763350700384024,-2.9360272138593686,-9.622987759728078,0.11080411621239472,0.7584170815987514,-0.7488039815369119,5.958140146416109,-1.9523764405179362,8.286068911112316,1.0519068853523081,-2.4068801033510265,0.3552290138391916,1.313513844955989,-1.076361321312274,-0.7110339824467338,0.91681751118963,-2.7631565953736557,False,c3,1,"Currently it's possible for the hook to pass ""false"" in for $user, which caused T96145. That doesn't seem very useful.",96174,-12,Needs Triage,True
-5.284287647568862,10.387533881857955,0.8618622476277871,-0.9365622839765726,-1.2408263408564757,-2.1755417266004793,-2.684644517745623,-3.4957776712901385,3.6575915572249684,0.1435950120954983,2.1013359440406894,2.03346590056728,1.0983938185581446,2.0516513209342646,-1.446305551204473,-1.2051963636081937,-0.8658245625414734,0.3609959275809287,False,c3,1,"I believe the issue is that we [redirect](https://github.com/wikimedia/mediawiki-extensions-OAuth/blob/master/frontend/specialpages/SpecialMWOAuth.php#L93-L101) users requesting HTTP to HTTPS, but many frameworks will simply follow the redirect without realising that they need to update their signature.
How to reproduce:
1. Update the testClient.php script to use a consumer token / secret registered on mediawiki.org
2. Change the baseUrl in testClient.php to 'http://www.mediawiki.org/w/index.php?title=Special:OAuth'
3. Run the testClient, and observe that you get the following response:
```
If all worked well, you should have a JSON object with two keys: key, secret.
You got:
string(35) ""{""error"":""mwoauth-oauth-exception""}""
```
4. Change the baseUrl to use HTTPS, and run again. Output becomes:
```
You got:
string(94) ""{""key"":""8491f49a7943741349105701c6a813ac"",""secret"":""77b0d138fdd3c1b6e046639a99ee99ede2e46f10""}""
```
Extract from logs on Fluorine:
```
2015-04-14 07:53:01 mw1171 mediawikiwiki: MediaWiki\Extensions\OAuth\OAuthSignatureMethod_HMAC_SHA1::build_signature: Base string: 'GET&https%3A%2F%2Fwww.mediawiki.org%2Fw%2Findex.php&format%3Djson%26oauth_consumer_key%3D<snip>%26oauth_nonce%3D<snip>%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1428997980%26oauth_token%3D<snip>%26oauth_verifier%3D<snip>%26oauth_version%3D1.0%26title%3DSpecial%253AOAuth%252Ftoken'
2015-04-14 07:53:47 mw1176 mediawikiwiki: MediaWiki\Extensions\OAuth\OAuthSignatureMethod_HMAC_SHA1::build_signature: Base string: 'GET&https%3A%2F%2Fwww.mediawiki.org%2Fw%2Findex.php&format%3Djson%26oauth_consumer_key%3D<snip>%26oauth_nonce%3D<snip>%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1428998025%26oauth_token%3D<snip>%26oauth_verifier%3D<snip>%26oauth_version%3D1.0%26title%3DSpecial%253AOAuth%252Ftoken'
```
Note that in both cases, the ""base URL"" begins with `https`.",95998,-12,Needs Triage,False
-3.949831281524648,9.415304686701969,0.06135658832346991,-4.808592463509521,-5.535432241202605,-4.86926532762225,-4.195201029115342,-2.3723867288135074,7.138663447434417,3.437972635089926,0.1075275658431023,5.601935862061834,2.28823258276855,1.426942223111551,0.3151257457399552,0.0003926861567336015,-1.7424201069677476,1.9416548393886857,False,c3,1,"http://localhost:8888/w/index.php?title=Special:UserLogin&type=signup&returnto=Special%3AWatchlist
shows message:
""A watchlist helps you bookmark pages and keep track of changes to them.
Sign up to start one now.""
It should be possible without updating MobileFrontend to customise this message.
",95903,-12,Needs Triage,True
8.221875824427928,8.96479004909066,5.4398002206357,-1.8091415829791089,-2.213409658009815,0.6980296877123646,2.309970952730663,-0.7145319335328026,-5.434467800171298,-1.0048476925930672,0.14702957078857404,5.589022056467366,-2.2831892527078868,1.3658963125611994,-1.7969673727489197,1.2651701753811282,0.5053822241067405,0.5244310874836817,False,c3,1,"MobileFrontend [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/ec875fc9e27efe76ea7643f84c092f0319dac0d3/includes/MobileFrontend.hooks.php#L582-L605 | creates it's own ]] Userlogin and UserCreate templates. These templates inherits QuickTemplate while core templates inherits BaseTemplate. If another extension (which is included _after_ MobileFrontend in LocalSettings.php) requires functions from BaseTemplate in it's UserLoginFrom or UserCreateForm hook handler (which is legitim, because UserCreateTemplate is the expected class), php ends with a fatal error. MobileFrontend should also inherit BaseTemplate instead of QuickTemplate to prevent these problems.
Encountered with installed MobileFrontend and GoogleLogin extension.",95820,-12,Needs Triage,True
-6.582875952581321,13.91657195937757,1.3756908177769738,-5.003750797248422,-4.468720297711501,-0.15444602014614905,-5.180039826240729,0.5501327003405486,8.913096639592753,-1.8999263450607966,-0.3575904811189199,3.5819629424134254,0.06357840962370087,0.317053380615663,0.036937229513501535,1.240050063377775,-0.885554417540777,0.43684661660318747,True,c3,1,"This page is triggered when an anon click on the CTA to login after clicking on a watchstar
{F111080}
The text should be replaced
A watchlist helps you bookmark pages and keep track of changes to them.
Log in to see it.
---> Now you can group pages into collections to share with friends or save for later.
Login to try.",95729,-12,Needs Triage,True
-5.226835610732746,9.982059142208819,4.86738516561061,-2.483313911981601,0.38945702250651104,-4.967920497198987,0.8733367977991948,-1.1336191605641819,-2.387777742437347,-3.3420132476115696,-2.3664558194523555,0.295430213935304,-0.8435564205748314,-1.0106252850597777,-0.011488624869262054,-0.5562826274070332,-2.0603110042523483,-1.998641645884594,False,c3,1,"When a httplib2.RedirectLimit (maybe also with others) occurred on `pywikibot.comms.http.fetch` it hangs:
```
>>> import pywikibot.comms.http
>>> pywikibot.comms.http.fetch('http://www.tvtropes.org/api.php')
Traceback (most recent call last):
File ""/home/xzise/.pyenv/versions/3.4.3/lib/python3.4/threading.py"", line 920, in _bootstrap_inner
self.run()
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 549, in run
item.data = self.http.request(*item.args, **item.kwargs)
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 260, in request
uri, method, body, headers, response, content, max_redirects)
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 307, in _follow_redirect
max_redirects=max_redirects - 1)
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 260, in request
uri, method, body, headers, response, content, max_redirects)
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 311, in _follow_redirect
response, content)
httplib2.RedirectLimit: Redirected more times than redirection_limit allows.
^CTraceback (most recent call last):
File ""<stdin>"", line 1, in <module>
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/http.py"", line 364, in fetch
error_handling_callback(request)
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/http.py"", line 274, in error_handling_callback
if isinstance(request.data, SSLHandshakeError):
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 392, in data
self._join()
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 386, in _join
self.lock.acquire(True)
File ""/home/xzise/Programms/pywikibot/core/pywikibot/comms/threadedhttp.py"", line 323, in acquire
return super(S, self).acquire(blocking)
File ""/home/xzise/.pyenv/versions/3.4.3/lib/python3.4/threading.py"", line 421, in acquire
self._cond.wait(timeout)
File ""/home/xzise/.pyenv/versions/3.4.3/lib/python3.4/threading.py"", line 290, in wait
waiter.acquire()
KeyboardInterrupt
```
From what I could tell it's not releasing the semaphore correctly (although when looking at the code it should and it does actually call that) and when it then tries to check for errors it tries to acquire it and waits then on it.
try:
# inside of that it crashes
item.data = self.http.request(*item.args, **item.kwargs)
finally:
if item.lock:
# this line is called
item.lock.release()
I tried to determine where it acquires the lock but only find the one place in `fetch` and then one when it tries to get the data in `error_handling_callback`.
(//Note: The line numbers are bit off as I try to debug that one//)",94993,-13,Needs Triage,True
6.0698225368208,-1.7223257449456302,1.7842182571673462,-2.561632095333562,4.80736527130272,-1.2117826267861533,-1.2032339314990441,3.234850726080366,6.550073047620364,1.3983190815142406,3.0603642068001613,3.2549979936974927,2.443056385124799,1.1679223454412444,-3.247845999436212,1.0336225677536819,-2.5879300526297664,-1.054282660353984,False,c3,1,"- Open an incognito/private window
- Visit http://en.m.wikipedia.beta.wmflabs.org/wiki/Cat_senses?mobileaction=beta
- Click watchstar
- You should see the login/signup CTA drawer
- Click the bottom arrow to dismiss modal {F107694}
- Try to click watchstar again
- **Nothing happens**
Expected:
- login/signup CTA opens back up",94682,-14,Needs Triage,True
2.031122215923682,-3.818092477217837,4.002994369276511,-1.103065838992028,-5.051571479182222,-1.0555361896807496,2.7985488864058494,2.8154042906176233,0.16821157776369422,-1.8845818073189502,-3.410144487229171,2.6681790254493354,-2.1361570717178253,-1.5176801853252844,2.1624524177182156,0.6904041092847413,3.504503647782161,0.9801037347587338,False,c3,1,"```
@wd <query string>
```
should point to https://tools.wmflabs.org/cluestuff/wd/query.cgi?q=<query string> but was never changed. Current implementation suffers from M$/unix translation issues.",94499,-14,Needs Triage,False
1.357767156455632,2.6113491569860585,-2.624924192686608,2.232336397194718,-1.3309000669630007,-0.6734958559600835,0.5739060068135808,5.593338743800973,-0.0980308840815953,-0.726512316107276,0.019512887813355917,0.9907417652600297,3.866118945638828,1.4778844570287317,2.9889857816538585,0.8983041651065498,1.944146728312793,0.8571812105405179,False,c3,1,"iPad mini iOS 8.2 with Beta 4.0.7.8
1. Install Beta 4.0.7.8
2. Open the apps and log in - after entering username/password, click Done.
The error msg is displayed briefly: The operation could not be completed(NSURLErrorDomain error code -999)
There is no noticeable implications after that
- logging in is successful and quick
- subsequent log out/log in won't display such error.
{F103685}",93789,-15,Needs Triage,True
-2.7268905444660243,8.908038887371703,-1.6940122102251252,-8.736267359385092,7.925971589629684,-5.892272739043671,2.0929303916168545,-5.516689802661614,-2.814891600040327,3.6024806865423713,1.4693309899672475,-1.3739254610866425,-0.43229503604999486,0.6779866660329512,-1.6408820560123623,3.0819502927219045,4.712632809902741,1.6064061619467072,False,c3,1,"@eevans has reported he can't login on graphite but he already is in the WMF LDAP group, @Coren and I both confirmed that.
Also, the login works for him on Icinga which uses the same groups, and finally, i can't login on Graphite myself either it seems. I simply get a ""wrong password"" reply but i'm using the same credentials as on Icinga which works fine.",93158,-15,Needs Triage,True
-1.410989693556782,19.854892401917652,26.42696373596663,-12.614035711612493,-11.633761697365985,-6.176788269154169,-1.3200199745627819,-4.356854862013937,4.304604388114121,-1.4973050395912693,-0.8832683150089093,-4.545514521591421,0.033821968372139466,-3.218415721525205,1.125794288546162,-11.459777139578605,1.7357447139149185,1.361231235808421,False,c3,1,For example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,93021,-16,Needs Triage,True
4.515822418290783,0.6840849875260702,0.6845077826204466,-1.0487958445637124,1.292123750708777,-3.885054455608108,4.1865686873991335,0.6113122626075359,-3.776787319995207,-0.3876155585317633,0.8414176897198944,1.30675442320424,1.6976759499802494,1.260924263510045,0.8410548687446564,-0.7433727603094942,-0.5787559322375373,-0.7951653637872995,False,c3,1,"Since we moved to app compat 22 several button visibility issues have occurred on my 2.3 device (DroidX).
The most important that's still outstanding is the buttons in Login/create account/captcha are not visible anymore.
Login:
{F95492}
Create account:
{F95495}
CAPTCHA:
{F95497}",92850,-16,Needs Triage,True
17.976058537757623,6.187973660837422,3.098994259051082,-3.72889572444564,-0.9824676259558602,-0.3220788403584901,-15.32253703606435,0.4630337396513552,1.651148225767776,17.82297516893731,-9.13443784169755,1.2288138591102455,-2.312377395356738,0.8732610177355982,-0.4605834342608386,-2.5827194198702927,7.310735569593806,-4.838109103707119,False,c3,1,Things like 'Halfak (WMF)' will trigger this,92772,-16,Needs Triage,False
-1.4492320315505607,-1.2083643557671166,-3.295193876949366,-12.702405215750577,13.431408087296843,4.733673795130939,-9.181319639414488,5.717124179194661,3.9835083523253214,-4.511591384354825,-1.3727698161390898,26.219644793394558,4.31964909981726,-4.393208424379178,-1.5162192548367779,-9.986915058399765,0.10461676390231234,8.375909594694498,False,c3,1,This is gonna hurt.,92671,-16,Needs Triage,True
-13.680692885958942,11.614763630214913,2.9556145289802735,1.036017499604978,-4.671369135336036,3.3455035994294784,4.084012983769953,9.822669603843888,2.1452721430180732,1.907289915190475,1.7661517343269426,0.14318622017720783,0.06580823523934587,-0.39367101865187415,2.637940659360514,-2.542595919192149,0.5721841076391476,0.4667373529194794,False,c3,1,"In an effort to not require any manual effort at all for mass new creations, self hosted puppetmasters should be able to autosign certs.
This is already happening for the labs puppetmaster...",92606,-16,Needs Triage,True
-5.293986240801143,9.167970818683042,3.6648490746378357,-3.2772207610990947,1.2672008007342224,-3.052850120940544,0.2524741760213143,-6.373005218109635,-2.2882731255966857,-0.45404418397696755,0.7966656168237738,1.5437069288804162,0.12434437233477613,1.6995136223180722,-0.8221311927532344,-1.4098979907143039,-1.3536668105198806,-0.32232115848404597,False,c3,1,"I am trying to get Recent Changes RSS feeds to work from a wiki that requires login for access to most pages (some are whitelisted). I use tinytinyRSS, a web based feed aggregator. It's set up so that clicking on an RSS feed link generates a new feed. When I click on the recent changes RSS link in wikipedia, it creates a working link. When I click the same button in our password protected mediawiki it gives me an error:
No feeds found in http://ccmdb.kuality.ca/api.php?hidebots=1&days=7&limit=50&action=feedrecentchanges&feedformat=rss
When I look at the feed from a different browser (crome) that is not set up to push rss links into tinyRSS I get:
* When I am logged in, something that looks like an RSS feed
* When I log out I get the API instructions with <error code=""readapidenied"" info=""You need read permission to use this module"" xml:space=""preserve"">
When I look at the error in TinyRSS it says ""LibXML error 5 at line 3217 (column 1): Extra content at the end of the document""
When I copy and paste the API response into Notepad++ to count lines it only seems to have 3206.
TinyRSS allows me to access feeds with a login; using my login for this wiki makes no difference for this.
Am I going at this the wrong way? Thanks!",92469,-16,Needs Triage,False
0.5386087569448637,-8.741102327805567,31.11561450831001,32.12594634118738,-2.463621076324252,-21.344534987168068,4.864664714845529,-4.811876693572463,-0.6615536105398863,-3.6429834811791446,-0.5095336930270054,2.412251420475209,9.747458773353006,10.842288258900739,12.144529813954005,-1.5413755312199175,0.8382135276556719,1.7110577857580396,False,c3,1,request #2 ib https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=8172705,92256,-17,Needs Triage,True
2.9764579462164806,-3.0333531664793973,-0.08227468776264146,4.098686205570056,-3.5362830516249257,-6.0994531917745745,-2.9987420948712407,-1.8065386697254109,0.12068951610524958,-3.3972234785116515,2.797205518844948,0.2853602438035465,-3.3781662403799606,-1.3542223215761053,0.158659189034708,-0.20928657883814383,-0.30554122127186956,-1.6168142753666377,False,c3,1,"Per [Bug 66699](https://bugzilla.wikimedia.org/show_bug.cgi?id=66699)
**User story**: as a registered user, I wanted to have my login session remembered, so that I don't have to repeatedly log in.
**Specification**: the login sessions for users who choose to be remembered should be set to one year expiry.
==== TODO ====
* [] Review [141248](https://gerrit.wikimedia.org/r/#/c/141248/) - Configure logged in session length independently
* [] Review [141394](https://gerrit.wikimedia.org/r/#/c/141394/) - CentralAuth
* [] mediawiki-config change
--------------------------
**Trello card**: [[ https://trello.com/c/CuOVnYcZ/522-extend-login-sessions | CuOVnYcZ ]]
* column: Needs Review/QA
* labels: Feature (green)
",92180,-17,Needs Triage,True
5.069504094345621,-1.5300016032869586,1.4154080173367518,3.079256407239365,1.5510266200409362,-7.309567678475576,0.9921097303150646,4.728763012755489,0.16674512754397774,-0.7022231035173006,-0.03340351731803359,-1.2886796147315092,-0.5581731990175873,-2.8844261954177637,-0.3490416383242767,-0.022975009772084,1.340545095742787,1.157362803951336,False,c3,1,"We unintentionally left some cruft in when removing the old login and create account forms.
Specifically, loginstart, loginend, signupstart, signupend (and possibly others) were removed from use, but not removed entirely. This also needs to be documented at https://www.mediawiki.org/wiki/Account_creation_user_experience/Strings#Removed_old_messages
See also {T58455}
--------------------------
**Trello card**: [[ https://trello.com/c/fPSXLKrn/218-cleanup-and-document-login-and-create-messages-left-from-vform-work | fPSXLKrn ]]
* column: Bucket o' Mess
* labels: Technical Debt & Refactoring (orange)
",92110,-17,Needs Triage,False
-0.2302783222587914,-1.1922600019434118,4.058330874588371,6.069130078843335,-3.2032523654915797,-4.74374286634587,-2.3141246609704424,1.2820974584457812,-0.8732765109217714,-0.16140656329468328,5.543094593173944,-0.29090854019685597,-3.844026372939399,0.28147041148015894,-0.9098959685004964,0.5704767187673108,-0.186317196903939,-0.3333979140803198,False,c3,1,"Lots of good ideas we didn't include in initial launch
==== Ideas ====
* [] Eliminate labels, only use placeholder text (depends on improving placeholder support in supported browsers, e.g. https://bugzilla.wikimedia.org/48918)
* [] If user fills in username and password on Create account form, attempt to login with them
* [] Make primary button less dominating
* [] Reintroduce Login button on Create account form?
* [] Improve Username help/policy, e.g. display tipsy help when username field has focus.
* [] On Login form, position the ""Don't have an account? [Join TheWiki]"" CTA to right if there's space, like Create account's benefits.
* [] Client-side validation in Create account
* [] Hide skin elements, e.g. the top-right navigation link to the form you're already on.
* [] Rename the skin's [Special page] tab to include the name of the form, and eliminate the H1 heading
* [] Garbled HTML in Titleblacklist error, https://bugzilla.wikimedia.org/38894
--------------------------
**Trello card**: [[ https://trello.com/c/5xRitMcR/177-login-create-account-form-improvements | 5xRitMcR ]]
* column: Bucket o' Mess
* labels: Research (blue)
",92109,-17,Needs Triage,False
3.12048539542296,-1.6289876019287046,-0.9439403144423544,4.184678278614143,-0.7622561062608212,-2.3784971459549524,-1.4232921760562638,1.239121604615371,-1.3680033232498183,-0.9701474868797573,3.623063147230648,0.12323061853663608,0.530403221058088,-1.1690388071162343,-0.3253394159435983,0.8020389240241561,1.0642721612559967,0.201502406971225,False,c3,1,"List of TODOs on non-Vector skins. This is lower priority because the only way to view these is to either force the skin or be already logged in. Of all alternate skins, Monobook is the one that really matters, but we can note any feedback on other skins here too.
==== Outstanding items ====
* [] In Monobook, new form inherits grey background
* [] In Monobook, the 100%-wide form items hit the edge of the gray background and input focus halo protrudes
* [] Should the form border vanish in all skins, or just Vector?
* [] Should the margin and padding be 0 in all skins, or just Vector?
* [] SimpleCaptcha wraps onto new line, https://gerrit.wikimedia.org/r/71102
--------------------------
**Trello card**: [[ https://trello.com/c/lmY261Rx/144-non-vector-optimization-for-login-create-account-redesign | lmY261Rx ]]
* column: Bucket o' Mess
* labels: Technical Debt & Refactoring (orange)
- Attachments
- [[ https://trello-attachments.s3.amazonaws.com/5032806a85f7309c527929de/514ca928c073528f5d00061a/aab428c6b94b2b1d300c1224e2321b3c/Screen_Shot_2013-03-22_at_11.58.03_AM.png | Screen Shot 2013-03-22 at 11.58.03 AM.png ]] (cover image)
",92108,-17,Needs Triage,False
6.256894237528581,-3.5390872498047585,9.512995555236742,13.525546247086888,-3.4014710500039587,-10.395014131044071,0.4490929588116783,0.7437632492207512,-2.260554374759054,-0.3070974239344162,5.4206566450567095,0.7319311517341791,-4.191472925184876,-0.10110734609857275,-0.5373041784989487,0.737337614787807,1.1015426044494896,1.4160698793993054,False,c3,1,"[Bug 47883](https://bugzilla.wikimedia.org/show_bug.cgi?id=47883)
==== Checklist ====
* [] Blank loginstart and loginend on WMF wikis
* [] Add back to core as blank by default messages
--------------------------
**Trello card**: [[ https://trello.com/c/9tfRp42H/271-bug-47883-reinstate-loginstart-and-loginend-and-blank-on-wmf-wikis | 9tfRp42H ]]
* column: Bucket o' Mess
* labels: Technical Debt & Refactoring (orange)
",92105,-17,Needs Triage,True
-6.994971009251211,3.8501609792159144,-6.107180847292518,2.788862928294952,1.2168757216159574,-1.6423662765229687,-1.620830208239445,-2.9813131088640965,1.5945312988485711,-0.742121547591573,-0.03979719933026393,0.6053073072630692,2.495089198217026,-1.9581798132520394,-0.6171739460734758,-0.5730906110402325,0.967595840464823,-0.8117537982227983,False,c3,1,"this is a ticket to revoke the SSL cert:
etherpad.wikimedia.org
- revoke with the CA / vendor
- ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195303/
- ~~delete the matching .key from private repo~~ done by dzahn
- ~~rm/shred cert and key on servers it is installed on~~ done by dzahn
(once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/
""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")
so this is intended to include that and the other steps, i will strike out what i have done. ",92045,-17,Needs Triage,True
-6.255873335450251,3.8544266468663118,-5.358784219546342,3.6683820909476426,1.029809218065562,-2.040382099961404,-1.3619447887298417,-2.4850980338339665,0.8995239329601685,-1.0818863251502018,-0.6265905479027669,0.22079341719799794,2.1844933338290784,-1.9736261021376555,-0.6633083199985874,-0.6332842023632852,0.7833535373581804,-0.6774941786653732,False,c3,1,"this is a ticket to revoke the SSL cert:
bugzilla.wikimedia.org
bug-attachment.wikimedia.org
- revoke with the CA / vendor
- ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195307/ , https://gerrit.wikimedia.org/r/#/c/195804/
- ~~delete the matching .key from private repo~~ done by dzahn
- ~~rm/shred cert and key on servers it is installed on~~ done by dzahn
(once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/
""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")
so this is intended to include that and the other steps, i will strike out what i have done. ",92041,-17,Needs Triage,True
-6.138129413242513,2.9552966101214864,-6.738713254210058,2.892165169991919,2.0978881978246235,-2.066057620861277,-1.614605463044751,-1.8394068122993161,1.1786488241499367,-1.2223856845420382,-0.6439600545829895,0.46350045260322004,2.3070644707454284,-2.3401040546432603,-0.23397340090909147,-0.5567727102275857,0.8101684993005194,-0.8494985317883388,False,c3,1,"this is a ticket to revoke the SSL cert:
techblog.wikimedia.org
- revoke with the CA / vendor
- ~~delete cert from public repo~~ (done, https://gerrit.wikimedia.org/r/#/c/195308/)
- ~~delete the matching .key from private repo~~ (done by dzahn)
- ~~rm/shred cert and key on servers it is installed on~~ (server was already gone)
(once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/
""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")
so this is intended to include that and the other steps, i will strike out what i have done. ",92021,-17,Needs Triage,True
4.284227258334603,11.058642760496681,1.6315698076884644,4.342687108244547,-10.466390721796303,2.794630492551841,-1.2088880394078938,-2.6552535883326054,-0.9062927874442008,-2.6534577508456314,-4.865778129476745,-3.11053202341719,-1.1050391456270026,-1.1053580875830757,-2.7858631723140705,-2.2709571405454723,0.29415790912757855,2.896426006673037,False,c3,1,"Python 3.4.3 win32 while using IDLE and an up-to-date version of pywikibot:
```
>>> import pywikibot as pwb
>>> pwb.Site('fa').login()
Traceback (most recent call last):
File ""<pyshell#1>"", line 1, in <module>
pwb.Site('fa').login()
File ""E:\core\pywikibot\site.py"", line 1676, in login
if loginMan.login(retry=True):
File ""E:\core\pywikibot\login.py"", line 232, in login
password=True)
File ""E:\core\pywikibot\bot.py"", line 540, in input
data = ui.input(question, password)
File ""E:\core\pywikibot\userinterfaces\terminal_interface_base.py"", line 212, in input
self.output(question + ' ')
File ""E:\core\pywikibot\userinterfaces\terminal_interface_base.py"", line 191, in output
self._print(text, targetStream)
File ""E:\core\pywikibot\userinterfaces\terminal_interface_base.py"", line 132, in _print
self.printColorized(text, targetStream)
File ""E:\core\pywikibot\userinterfaces\terminal_interface_win32.py"", line 91, in printColorized
targetStream.write(text.encode(self.encoding, 'replace'))
File ""C:\Python34\lib\idlelib\PyShell.py"", line 1344, in write
raise TypeError('must be str, not ' + type(s).__name__)
TypeError: must be str, not bytes
>>>
```",91921,-17,Needs Triage,True
-7.383705131388451,15.217120289752842,13.263162280520767,7.3478034176641,-21.091490806698978,-5.1542751576298675,1.2401887029107428,3.31653924814105,2.1798215160662737,8.210108135684504,-1.115960370875732,-0.15431759825070146,-0.4286956552465906,-0.6094831803550189,0.05160708304623629,-4.326445157448358,-4.135758111476458,2.2527964793963795,False,c3,1,"HTTP error with message ""unable to set cookie"" in response when trying to scrape http://www.tandfonline.com/ urls (like http://www.tandfonline.com/doi/abs/10.1080/13534645.2011.605573) with native scraper.",91875,-17,Needs Triage,True
6.652057765277961,8.847537630501456,0.4061777858458555,1.4729252725111,-3.18942868471165,2.059365522331979,2.2591829857573638,7.182058614840318,3.6061266255198445,4.847469109115439,3.6393542488262107,-3.5638221099582115,1.1560107894326328,0.011202723960732186,-0.1889539322199827,3.021963391740652,1.1759399877667926,-2.992085903515476,False,c3,1,"In an ideal world, unregistered users wouldn't need to load Special:CentralAutoLogin/checkLoggedIn on every single page view (e.g. `https://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?type=script&wikiid=itwikiquote&proto=https`). ",91196,-18,Needs Triage,False
-9.486186133735334,12.459180123239623,8.484037180520499,8.533574459006651,2.0482321309510305,-1.5876279441678323,-3.7479413300541027,-0.7643238677922778,0.5353548197790481,1.0088974536551936,-2.129752210164539,-1.7321663287385751,-2.2584388114431864,1.377422997508054,-2.3220169058402145,1.6613526437739141,-0.801064560697354,2.40626782140627,True,c3,1,"When not logged in and the user clicks login / sign up through the CTA they see a message above the login ""Add articles to a list for sharing or tracking changes""
[[ https://trello.com/c/S4C18bTS/71-login-page-should-show-collections-specific-message | name ]]",91085,-18,Needs Triage,True
8.019753810099195,-6.727702383208937,10.897493251725773,15.674333604553388,-0.700426251741445,-13.887670999681106,-1.110219829426402,-3.902282901185997,2.2747184792801507,-2.7692825427929177,5.367526571821621,1.681906064676258,-3.2243826222264804,0.06292445754840958,2.356396941108147,0.2433608351537975,-0.3120219008716252,-0.29674192009036093,False,c3,1,"
==== Acceptance Criteria ====
--------------------------
**Trello card**: [[ https://trello.com/c/CdD1LGxi/2-a-loggedout-user-attempting-to-add-to-a-collection-is-referred-to-login-or-create-account-so-that-they-can-login | CdD1LGxi ]]
* column: Must have
",91005,-18,Needs Triage,True
11.905252173711734,7.715118292846654,11.538527357121815,-5.088386705377524,-4.17756020187602,-4.555927459099918,-0.36057595365959827,-3.480120335052406,-0.7562693470926538,-0.8461099701726909,1.276497451613945,2.279784033110184,0.14294074728298867,0.9037158411207455,-0.3184894395796851,-1.6992753472619588,-0.6419462246641781,-0.39408480576508054,False,c3,1,"Since Russian Wikimedia projects are HTTPS only and have HSTS enabled, we should set its wgCanonicalServer to HTTPS, so that Bing will update the links to HTTPS.
[1] https://www.bing.com/search?q=site%3aru.wikipedia.org
>>! In T91352#1103471, @Eloquence wrote:
> A Russian Wikipedia community member implemented a JavaScript redirect to send Russian Wikipedia traffic to HTTPS in August 2014, so most Russian Wikipedia traffic has been going over HTTPS since last year. A similar hack was in place in Russian Wikinews. The resulting configuration was vulnerable to man-in-the-middle attacks, as it depended on users first loading the insecure version. It also caused a major performance hit for users due to the double-loading. In consultation with Russian Wikimedia community members, consistent with our long term HTTPS rollout objectives, and consistent with the pre-existing request to participate in the HTTPS beta, we superseded the hack with a server-side redirect and HSTS as a secure and consistent default configuration for all Russian language projects.
",90527,-19,Needs Triage,True
125.12864973473413,24.461032312281354,20.258054462711378,-15.368139377215654,9.419729155465951,8.923586496494865,0.5660249642391806,-0.39953809071088453,0.6528691956095768,3.4089737421423614,1.8893517820205266,0.7864180118380248,-2.4641331367967334,-0.5539055659455503,1.5844758167120787,0.15244468824303828,0.8508428236510508,0.8283642692908557,False,c3,1,https://github.com/wikimedia/mediawiki-extensions-GuidedTour/blob/fd80f6e7a3/modules/ext.guidedTour.lib/ext.guidedTour.lib.main.js#L124,90330,-19,Needs Triage,True
125.12864973473413,24.461032312281354,20.258054462711378,-15.368139377215654,9.419729155465951,8.923586496494865,0.5660249642391806,-0.39953809071088453,0.6528691956095768,3.4089737421423614,1.8893517820205266,0.7864180118380248,-2.4641331367967334,-0.5539055659455503,1.5844758167120787,0.15244468824303828,0.8508428236510508,0.8283642692908557,False,c3,1,https://github.com/wikimedia/mediawiki-extensions-FlaggedRevs/blob/bcdb67067d/frontend/modules/ext.flaggedRevs.review.js#L406,90329,-19,Needs Triage,False
-10.764157596906783,11.525226940396252,-0.4115001632508779,-1.0887801822392638,-0.6497568224497479,-1.9479814481443523,-1.3868933697727304,-2.024570354298991,4.771927244103588,0.14950777080824107,2.2720758111906147,-2.662713147808218,3.924186459082754,3.060596884439555,1.6708745005979218,-1.684594853559195,0.371925926795988,-1.38741775338266,False,c3,1,"The icinga-admin.wikimedia.org certificate expires on 2015-02-26.
Since we locked down icinga.wikimedia.org, I'd like to propose we simply remove the icinga-admin url support entirely, rather than maintaining an unneeded secondary certificate.
If this need changes in the future, then we can re-evaluate a purchase at that time.",90002,-19,Needs Triage,True
10.14224616088819,10.70849519800122,-0.8898419085152671,3.996009914991732,-9.640537033337107,-2.2828504746034906,0.5718513943344776,3.268727834040991,-3.917262864477258,0.8317467747443619,3.608339647411374,0.11039647118988083,-3.1983379428616665,1.2950092254538657,-2.8843208139688192,2.7933795573791644,1.8063889922564254,-2.3939270170420097,False,c3,1,"pwb doesn't use info from `authenticate['en.wikipedia.org'] = ('user','pa55w0rd')` for HTTP basic auth acces, as [described in Manual:Pywikibot/Use_on_third-party_wikis](https://www.mediawiki.org/wiki/Manual:Pywikibot/Use_on_third-party_wikis#Bot_.26_HTTP_auth)
threadedhttp.py sends no basic auth headers (verified by logfile)",89417,-20,Needs Triage,True
-10.690562770219005,11.414300837946175,-3.62570086806846,-14.369096631486348,-3.612531658900619,-6.1876675309562446,1.4785347481646447,-5.76751902956923,-0.509655562991696,-3.623178561743111,-2.4751684079572014,-0.05001591878961631,-1.6007496093312827,-0.6482341164612899,0.013069235146742741,-2.0712829335029106,4.115619050559249,1.8262995782495823,False,c3,1,"Research is not actively working on this, but wanted to bring this to your attention before we archive it:
https://trello.com/c/NIUZkYG0/652-header-research-for-berkely-people
",89415,-20,Needs Triage,False
1.5328855501718395,0.4714773681909463,0.15980934532279534,2.5493662351068345,0.14366204115960712,-0.7420599262704308,-1.511239173030675,1.1186955340272418,1.8887282122152718,-1.1414541250930736,0.5878027770004617,1.8763433700957897,0.1861298561386029,-1.2521549451594396,0.3042240788894741,-0.6985493907483915,-1.0635992323890051,-0.9920745510144705,False,c3,1,"To allow client-side JavaScript applications to fetch information from MediaWiki APIs, please add the following header to API responses, allowing the response to be read by an application running on a different domain:
Access-Control-Allow-Origin: *
========
https://www.mediawiki.org/wiki/API:Cross-site_requests
In the current documentation for CORS usage in cross-site requests, it states:
""If the CORS origin check passes, MediaWiki will include the Access-Control-Allow-Credentials: true header in the response, so authentication cookies may be sent.""
What it should also say -- once this is implemented -- is that if the CORS origin check **doesn't** pass, MediaWiki will **not** include the Access-Control-Allow-Credentials: true header in the response, so authentication cookies may **not** be sent, but MediaWiki will still include the Access-Control-Allow-Origin: * header so that **unauthenticated** requests can be accessed from any origin.
========
Notes:
- JSONP, which is currently enabled, is an old, less secure workaround for the problem that CORS now solves correctly.
- [[ https://phabricator.wikimedia.org/T62835 | A previous request, that was declined for invalid reasons. ]]
- [[ https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/API_Future/CORS_and_third-party_web_apps | A related API roadmap discussion ]]
- Users trying to access a MediaWiki API and expecting CORS to be enabled: [[ https://stackoverflow.com/questions/3873636/no-response-from-mediawiki-api-using-jquery | 1 ]], [[ https://stackoverflow.com/questions/23952045/wikipedia-api-cross-origin-requests | 2 ]]
",88532,-22,Needs Triage,True
-6.546507781744028,5.302619806487932,-2.428167837825976,-3.3000677727343493,1.01774106269095,0.43704366696667596,1.599534885651967,-0.6873950692221841,-1.5133995916418248,-0.9569984518619812,0.3530189741278398,1.188955406587638,1.3877400900690855,0.04922343874043289,0.41723815460617253,-2.4186408319586974,0.817467137645443,0.05733017015880715,False,c3,1,"When Tim reviewed the HTTPS support detection survey in 2013, he identified several issues with the instrumentation that made us doubt the quality of the results:
{P239}
Since Erik would like us to re-run this test, I have revised the instrumentation code to address these issues.
* The requests are now for //performance.wikimedia.org, which is not likely to have an open connection.
* The order of the two tests is randomized.
* Both tests are set to time out after 5s, but we never log before 6 seconds have elapsed. This ensures that if the user navigates away from the page before both tests have had 5 full seconds to succeed, we don't log anything at all. This should control for systemic error resulting from different performance characteristics of HTTP and HTTPS.
The original instrumentation code is available here:
https://raw.githubusercontent.com/wikimedia/mediawiki-extensions-WikimediaEvents/433cd6874b6f16a0d6940d19ffe01b75acd80580/modules/ext.coreEvents.httpsSupport.js
The diff containing my proposed changes is available here:
{F34553}
At Erik's request, I am keeping this private. I am obviously aware that the code from the previous round of data collection is publicly available, and that the changes will be public too if and when we start serving them to clients.",88361,-22,Needs Triage,True
-10.572049702150734,1.4221014857015515,2.6028905843609245,11.495033026197142,3.7131625867057747,-4.4516005561377945,1.1771400424837068,0.941959637854285,-0.21880844298997432,-2.813799792754982,-0.3416716145637855,3.548175609330256,-0.535381523648736,-0.1252448027097648,0.8415684902548524,2.6081954926676785,2.7004536085751507,3.224537409993653,False,c3,1,"Tool error and access log files (~sometool/error.log, ~sometool/access.log) are currently updated apparently in fixed intervals, so information appears in the logs a few minutes after errors happen. This makes debugging web programming stuff or lighttpd configuration problems a pain.
Either the update interval (or buffering limit, or whatever causes it) should be decreased, or there should be some way to access the tool error log directly.",87562,-23,Needs Triage,True
6.4943604439414475,4.049661930090647,1.3246914045530929,-2.0559020688486265,0.41808489051549924,-0.7822314086488649,-3.108444983801995,0.5554636728758496,-2.6370118604812545,-2.183133909935552,-0.2822332323385206,-1.4897679010446072,4.955548853970978,2.225621849136875,1.1904726587926948,-0.5322547156704943,0.7237019573088206,0.8172225599615872,False,c3,1,"https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%A4%D0%BE%D1%80%D1%83%D0%BC/%D0%A2%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9#.D0.9F.D1.80.D0.BE.D0.B1.D0.BB.D0.B5.D0.BC.D0.B0_.D0.BF.D1.80.D0.B8_.D1.81.D0.BC.D0.B5.D0.BD.D0.B5_.D0.BF.D0.B0.D1.80.D0.BE.D0.BB.D1.8F
- After clicking on the ""Login"" button and enter the password, the system offers me to change your password
- I change password
- after pressing the ""Set password and log"" the following 503 error.
So for several days.
Prior to that, in Wikipedia have not worked from 2013, but now decided to try.
Username: kisvadim
Tried different browsers, different computers, and under Linux and under Windows. All the same. Something happened to see with account
---
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: POST http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%A1%D0%BC%D0%B5%D0%BD%D0%B8%D1%82%D1%8C_%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8C, from 10.20.0.146 via cp1066 cp1066 ([10.64.0.103]:3128), Varnish XID 3254153861
Forwarded for: 195.130.209.78, 91.198.174.65, 91.198.174.65, 10.20.0.146
Error: 503, Service Unavailable at Sun, 18 Jan 2015 06:01:56 GMT
---
Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: POST http://www.wikidata.org/wiki/Special:ChangePassword, from 91.198.174.61 via cp1053 cp1053 ([10.64.32.105]:3128), Varnish XID 2385829888
Forwarded for: 5.164.222.248, 10.20.0.146, 10.20.0.146, 91.198.174.61
Error: 503, Service Unavailable at Mon, 19 Jan 2015 18:30:08 GMT
---
Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: POST http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%A1%D0%BC%D0%B5%D0%BD%D0%B8%D1%82%D1%8C_%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8C, from 91.198.174.82 via :: cp3012 cp3012 ([91.198.174.82]:3128), Varnish XID 3303621316
Forwarded for: 5.164.222.248, 91.198.174.82, 91.198.174.82
Error: 503, Service Unavailable at Mon, 19 Jan 2015 18:43:53 GMT
---
almost like a https://phabricator.wikimedia.org/T75462 but it is already fixed",87305,-24,Needs Triage,True
2.0245198714015644,5.840845430919902,1.3465882453675349,-8.652379233382849,-2.7170171472735136,-1.0624505766412389,-2.386646296874694,2.4488913351260018,-1.9332098707763266,-1.7459696181107756,0.9693995507595159,0.6788085044676531,1.563974068092287,-1.2715597283734361,0.13769645349710835,3.023462757544165,0.9999155223224052,-0.9346819922398151,False,c3,1,"If I log out of all the WMF sites (or just delete all my cookies), and then log into http://en.m.wikipedia.org, I am automatically logged into the other desktop and mobile Wikipedias, but not the other projects (Commons, Wiktionary, etc.).
Steps to reproduce:
1. Open a totally fresh browser (or delete cookies)
2. Go to https://en.m.wikipedia.org/wiki/Main_Page
3. Log in
4. Go to https://commons.m.wikimedia.org/wiki/Main_Page
Expected result: You are also logged in on Commons
Actual result: You are not logged in on Commons
This only happens on the Main Pages as appears to be caused by CentralAuth's 1x1 images not loading on those pages.
Expected result: You should be logged in.
Actual result: You are not logged in.",87290,-24,Needs Triage,True
-9.571261230294478,14.53578650314817,1.9565987997533547,7.374141696080246,1.7914262193254982,3.2348158549577706,-1.0650440864028425,0.219991248869902,2.5402828787465825,-1.3537933444794383,-0.32020453933799464,0.31739483317467987,0.47123762237012823,-2.864139899008293,1.6239412887935822,0.48366004105045357,-0.9378253612410714,1.7380642800742094,False,c3,1,"In alpha on the minerva skin (mobile) the following should be present before the login form:
{F30271}
The grey box should only appear when there are no errors/warnings for submitting the form.
It should be possible to do this via a hook on the existing login form or as a change in core.
",87261,-24,Needs Triage,True
-9.877518714802369,5.399905567767046,1.2538979448336,-4.004057515771534,5.138143533332116,-9.92070225187184,4.078141099069431,-8.96351562330194,3.8393246355483726,0.2988705088995731,3.7054169986844028,4.114209538234124,0.9440469535424731,0.2582199387448938,-0.647683072026922,-1.0839264650175076,-3.7407951905546506,-1.4094110262609834,False,c3,1,"I know why. it's related to an upstream change. another reason we should be using core code. Fix on way.
",87260,-24,Needs Triage,True
-7.174739153489041,13.047200306053973,3.3996271932097386,4.33211981837446,-4.234371296272541,-3.9984256699516623,-1.3208425357325497,-1.9781526110330896,0.8163834935805907,-2.9738968013592713,-0.07719612883284244,-1.6283820027235212,-2.036333013277728,-0.9558448113850968,0.0648180259196538,2.6085649296777937,0.31392403013350445,0.22553919826137014,False,c3,1,".mw-createacct-benefits-container looks out of place and badly designed on Special:UserLogin in the alpha mode of the site.
Let's simply hide it for the time being.",87257,-24,Needs Triage,True
1.628867398577801,4.542554875724591,1.8072429890258874,1.2361214958796851,-1.7039438074722955,1.6848431703972475,0.42313588104212396,2.287418334649809,-0.5297108479586862,0.8834603384389412,3.186802645848599,-1.5365821925885013,0.5545772735734276,-0.7837224708279997,-2.2100573248712507,0.8672879233114934,-0.128676351727814,0.43053543496470836,False,c3,1,"wfHttpError() is meant for simple server responses to calls from non-user facing entry points (e.g. `thumb.php`).
It circumvents OutputPage and Skin and leaves the user unable to navigate elsewhere. As general rule of thumb, any url reachable by a regular page link (or any page generated by OutputPage/Skin) should result in response powered by OutputPage. Not cut short by `wfHttpError`.
Should probably output a page querying the user for input. Similar to Special:FilePath, Special:CategoryTree, Special:CentralAuth, Special:JavaScriptTest, etc. do when accessed without parameters.
Alternatively, if you don't want to create any such landing page or form, at least output the the current error message wrapped in a Special page using a simple `class=errorbox` element.
{F37183}",86007,-26,Needs Triage,True
0.9985693786564336,-4.818376099704043,0.5142948453355309,5.978571688035258,-1.3745889774439823,-4.098057581549162,-5.947155204332119,-2.1430945390431337,-5.014460449550409,8.966999360352863,-3.6726369354221666,-0.3851285698292326,2.17485790440864,2.3680940757446205,0.8151752994720933,-1.7571745034330148,1.703892761904098,-1.3372736150140176,False,c3,1,"The patch ""varnish: Route requests with 'X-Wikimedia-Debug=1' to test_wikipedia backend"" https://gerrit.wikimedia.org/r/#/c/183171/ has been applied on beta cluster but has some syntax errors preventing the VCL from loading:
deployment-cache-mobile03:
Expected ')' got '='
(program line 73), at
('mobile-frontend.inc.vcl' Line 102 Pos 40)
if (req.http.X-Wikimedia-Debug = ""1"") {
---------------------------------------#-------
deployment-cache-text02:
Expected ')' got '='
(program line 73), at
('text-backend.inc.vcl' Line 20 Pos 40)
if (req.http.X-Wikimedia-Debug = ""1"") {
---------------------------------------#-------
I have removed the patch from the puppetmaster.
",85993,-26,Needs Triage,True
4.878900154849635,2.2488379692791476,3.30083278628193,-2.6791400749085916,-4.651051826792527,-3.1470347957953226,-3.419427607188214,3.261445764839306,-2.1348302577877254,-0.8584300621683809,9.728421340009046,-0.8519662993799031,-3.9863672068980245,0.1477275090623822,-0.08035820572184971,-2.2936723187263883,0.9557079619761615,-0.5472942101428986,False,c3,1,"Let's convert MW core login/create account templates to Codex. Splitting this off from T74715. Let's do this after T12317 is fixed.
Open issues (Feb 2019):
[x] Error message not properly styled clear enough T145674
[] Captcha's misaligned, especially on mobile
[] Labels added on mobile
[] Required indicators probably better off hidden on this specific forms",85853,-26,Needs Triage,False
-5.002679989843136,3.185821081984912,-2.4039621970822047,4.616756974111223,-0.22877548680156234,0.7464177143673214,-3.5676917892205884,-0.16674330126713321,0.673091019197951,3.2212891113210063,-0.964251330539069,-1.6553854071442402,0.270947014777958,1.076655095350091,1.280798227391835,0.7356614669034438,-2.0792170679749162,0.829729572745354,False,c3,1,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading.
I suggest the following behavior:
* HttpError::isLoggable should return false if $this->httpCode < 500.
* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400
Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",85795,-26,Needs Triage,True
15.522827559208217,-6.726950349144524,10.945104115858825,8.336050485590958,1.7484952465047963,-7.468391446634716,0.46957087501077144,-1.7848714466020508,0.9650886298169408,-1.0362300180959805,-1.1353893021589172,0.9841063591811923,1.5478252463464255,-5.099847972499421,-2.4279052831046104,5.0323623128906725,6.387467619324737,7.555665219748492,False,c3,1,"https://github.com/jcgregorio/httplib2/issues/205
https://github.com/jcgregorio/httplib2/issues/86
(and others)",85750,-26,Needs Triage,True
-10.014283108413387,6.686899319492252,2.0291539035741195,4.418823143005587,2.150694458848985,1.1835145531396345,-0.14757026270189044,3.4454570157529303,0.8178553376088697,2.128804270962199,0.8576005069351811,-1.2600632043820994,-0.16375137978277543,0.07758231256411285,-0.9222372649150081,-1.4595268070564371,0.48222429163033476,0.30375204991116056,False,c3,1,"Go to the account creation form when already logged in - the label for the checkbox 'Use a temporary random password and send it to the specified email address' has too much line spacing when spanning multiple lines.
{F24985}
Given the size of the checkbox, the correct behaviour would probably be something like
{F24988}
This appears to be due to mw-ui's stying, and occurs regardless of browser.",85241,-28,Needs Triage,True
14.533617067720918,-0.6996134812478338,0.49437695947685967,2.446602947789443,-4.926486228666182,-1.8726945804807438,-0.8571295819514377,-0.2605987562371992,-0.4476673793233483,-1.8417948505785602,0.05882753349640568,-0.6822602356100549,2.208412823565418,0.18417761893548334,-0.8104054778943386,-1.2365272979446846,0.07529111745128181,0.11309199272002046,False,c3,1,"From https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Local_Login_no_longer_works_after_upgrade_from_1.18.1_to_1.23.5
Local Login no longer works after upgrade from 1.18.1 to 1.23.5
System upgraded from 1.18.1 to 1.23.5.
Local login works on identical wiki install from 1.23.5 - no upgrade and restore from backup MW1.18.1.
Use LDAP Auth Extension.
Localsettings.php has line:
$wgLDAPUseLocal = true;
Error Message:
Login error
Incorrect password entered.
Please try again.
Start request POST /mediawiki-xxxx/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page
HTTP HEADERS:
HOST: alb-wit-wiki.xxxx.x.x.x
CONNECTION: keep-alive
CONTENT-LENGTH: 114
CACHE-CONTROL: max-age=0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
ORIGIN: http://alb-wit-wiki.xxxx.x.x.x
USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
CONTENT-TYPE: application/x-www-form-urlencoded
REFERER: http://alb-wit-wiki.xxxx.x.x.x/mediawiki-xxxx/index.php?title=Special:UserLogin&returnto=Main+Page
ACCEPT-ENCODING: gzip, deflate
ACCEPT-LANGUAGE: en-US,en;q=0.8
COOKIE: wikixxxx_session=ei3vnrfjk9alekhk635aihak662snsv6i9ltq4ev0oll69k9kk20
[caches] main: APCBagOStuff, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreDB
Unstubbing $wgParser on call of $wgParser::setHook from registerEmbedDocumentHandler
Parser: using preprocessor: Preprocessor_DOM
Fully initialised
Connected to database 0 at 127.0.0.1:3306
IP: 10.1.x.x
MessageCache::load: Loading en... got from global cache
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
User: cache miss for user 176
User: loading options for user 176 from database.
",78692,-29,Needs Triage,False
-13.848944676772117,15.30878793338864,0.9984808400473746,-5.454728712981499,-0.832374092384079,-8.196978218054445,2.6094662784530476,7.104506569676267,-1.9981423562931206,-3.4465833100191654,-3.5549098955023823,0.8411333903913027,-2.2585630916021167,0.06742183391688528,1.0554138247460303,6.316761770350702,-0.5614211558312588,3.338189652100798,False,c3,1,"Currently they maually have a list of chiphers, and need to be manually kept in sync.",77987,-30,Needs Triage,True
3.0342082605107668,6.7834008142529,17.05956024919056,13.524377806422345,5.792967254899532,-0.7092425499727747,2.0761559129039755,-2.3610168097012307,0.025782859642654532,-2.5033781740368886,-3.162673342708225,-2.2484329530408536,-2.839150683386374,0.2960412346759549,0.22010631425472038,0.32905363254686093,3.592228156914831,1.444826962048302,False,c3,1,"The merging of https://gerrit.wikimedia.org/r/#/c/175465/ changed the SSL setup of the caches, and makes
webstatscollector's C implementation count SSL requests twice.",76390,-31,Needs Triage,True
-13.285612095898738,14.679856398204997,-4.808945182192678,-16.688422507672808,8.264510883665212,-9.737857909130204,0.81969433089475,3.767903433074359,7.626020953447921,-2.5333474250965105,-0.6424210300554356,-2.0994818227261973,-2.6756150690091234,4.371647962441504,-0.09620160791871069,-2.491392167255525,-4.458614143188919,-1.8036175247092863,False,c3,3,It should only need to do that when you actually navigate to the route....,114411,13,High,False
-6.197135663467549,10.990084161970763,4.93562459962039,-0.8417953231499371,-0.4393364862974474,0.5655103532343106,-3.7011467856955007,0.7843895671705731,1.951626519358611,4.449657334695171,-0.4739484738049198,-0.1387481117473588,1.9420448191732285,-0.03410284112305817,0.3906550798032278,-1.4561611381012631,-1.328905690223739,2.755850245435166,False,c3,1,"The app should respond with a specific error message when the user name or password is wrong while trying to log in.
We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"".
See https://www.mediawiki.org/wiki/API:Login#Errors.
According to @bd808 we should treat both error codes as the same.
",97477,-10,High,True
-5.748488416161377,6.7158137064770855,-0.23470808266993792,-0.5645315591881506,-0.9405487169145604,-1.4617379881830201,4.131840084058873,2.2610167485855777,-0.09798452478688174,1.079149645634324,2.4200264870957073,-2.608229615413863,0.2591682854477022,0.7447972863776062,0.9355021953803542,0.17958751118415073,1.3044077961139522,1.6170748575018636,False,c3,1,"[Note the ticket has morphed a bit, and older comments at the top may not be very relevant anymore!]
We should support HTTP2, as this is the true standard that replaces the experimental SPDY and brings mostly the same benefits we've enjoyed so far with SPDY. Note that our current production TLS terminators already support ALPN w/ SPDY, so ALPN-vs-NPN isn't an issue anymore.
Our current termination software is nginx 1.9.4 with a few extra local patches in support of parallel RSA+ECDSA certs. Upstream nginx introduced HTTP2 support with their release of version 1.9.5. However, they made an implementation decision to **replace** SPDY/3 support with HTTP2 support, rather than support both protocols side-by-side. We believe that was a very poor decision, as it would have been easy to support both in the patches, and client statistics indicate the real world still has a fair number of clients out there which are SPDY- but not HTTP2- capable.
Our preliminary stats from sampling live TLS ClientHello data from our traffic (this was a fairly small sample, but I wouldn't expect too much change from a larger one) were:
| none | 48.312%
| spdy+h2 | 25.426%
| spdy-only | 24.913%
| h2-only | 01.350%
On a practical level, SPDY/3 and HTTP2 are both doing the same job in terms of effects on client and server performance and such. If the stats above are broadly-accurate and we dropped SPDY/3 support for HTTP2 support today, we'd fall from ~50% of client connections on SPDY to only ~27% of client connections on HTTP2.
For an extra kick, this now also blocks us from upgrading to nginx 1.9.5 or higher in general, should we want to do so to apply fixes and improvements to other unrelated things. We have a few basic categorical options here:
1. Re-work nginx's HTTP2 patch such that it doesn't remove SPDY/3 support, and then sort out making that into a reasonable diff against current nginx 1.9.x code. Not completely trivial, but not all that difficult either given the patch history / diffs available at http://nginx.org/patches/http2/ . Kind of awful in the sense of moving further away from upstream and having to deal with more local code maintenance burden.
2. Convince upstream nginx to do something similar on their own.
3. Do all the work of option 1 ourselves, and submit the patches and get them included in upstream, removing the latter half of the problem in option 1.
4. Move to a different TLS termination software altogether, which ideally supports SPDY/3 + HTTP2, or at least supports SPDY/3 and has future plans to introduce HTTP2 alongside it (so that at least we can continue tracking upstream on unrelated bugs/improvements, unlike the situation with nginx today). Apache might be an option here, but there are probably others that fit the bill as well. Some googling and evaluating is in order.",96848,-11,High,False
-6.847887995117704,11.833330118676738,3.222736120623569,7.135795096372307,3.3241114310082085,7.716500061247699,1.0925376357010057,2.4967261335848345,1.7638163286800774,0.18292594932115058,0.2865987844304847,0.20240813800503865,-0.9744525536984145,0.29493843829702815,1.4319497041168754,2.525679887014545,1.9040815435723408,0.06477047958676763,False,c3,1,"In latest Google Chrome, the store throws a warning for insecure interactions on the page.
> Mixed Content: The page at '<https://store.wikimedia.org/>' was loaded over a secure connection, but contains a form which targets an insecure endpoint '<http://wikimediafoundation.us4.list-manage2.com/subscribe/post?u=438f0ff3a0fa6a75eeaea7498&id=906a788d5c>'.
This endpoint should be made available over a secure connection, or the footer should be changed to not embed a form but merely link to the external form page by anchor link.",96818,-11,High,False
8.38878199813639,-0.04034970904296031,-5.26445350437187,3.5841506928916598,-1.4261075526407554,-6.626399958170191,-3.5661936687221947,-3.782326208519886,-1.3235691650459884,0.9801701417605759,0.8684152405662751,-0.07880579096368256,-1.4946010234434715,-1.6686722559349914,-0.04598416584085552,-1.5119075531866644,-0.7070605957389401,-0.6191711566467275,False,c3,1,"At https://www.mediawiki.org/wiki/Talk:Sandbox this was at the top of my webconsole. I'm not sure what it means.
""[FLOW] "" ""Failed to load topics: http"" load.php:163:22
FlowComponent.prototype.debug() load.php:163
flowBoardComponentLoadMoreFeatureJumpTo/<() load.php:239
jQuery.Callbacks/fire() load.php:45
jQuery.Callbacks/self.fireWith() load.php:46
.Deferred/</deferred[tuple[0]]() load.php:47
mw.Api.prototype.ajax/xhr<() load.php:28
jQuery.Callbacks/fire() load.php:45",94068,-14,High,False
4.619774448061026,-2.652947116400231,13.382147933403427,10.110876901894851,2.1885693466860974,-0.9917840282533285,0.4513265515905065,0.4286798361463401,-0.9244857415826087,2.7695995053609455,9.18388947127956,1.2857811395497685,0.2012433523668422,2.5682437115587673,1.638252868889647,-0.21756792463992058,-0.5568849017204015,-0.2212609023862422,False,c3,1,"https://shop.wikimedia.org/
a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure.
* GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms]
* Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org
* GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]",93959,-15,High,False
-6.64267231784349,2.3294429219199877,14.544667519310437,10.015762818139255,0.7974148125539071,0.23548476697944287,5.681449572411526,5.747208198484697,4.590668293869133,5.8065253956325,7.053160381257335,-4.011090139233801,1.649138513442376,-0.6418387275238757,2.286667299338319,4.944608304868838,-4.07094667771251,-0.7991954098319516,True,c3,1,Otherwise HTTPS clients will abort with a mixed-mode access error.,92891,-16,High,True
4.284013601534236,11.551671793701047,0.30416124077653706,-0.8619114507029804,9.76316656353834,0.9601171680719653,0.04716347194434256,2.8257771351279377,-1.2909512582401852,-1.8526506944606926,-0.1369673785623453,0.4133073289994995,0.8969424393434204,1.6630485658738783,0.589786758375122,3.6701375203457287,-0.12107150564634916,2.3239178286213455,False,c3,1,"`thumb.php` ignores the return status of `MediaTransformOutput::streamFile()` and/or `FileRepo::streamFile()` and returns a normal HTTP status even if the file could not be streamed, which results in Varnish caching the error. It should return 503 instead.",92545,-16,High,True
-8.049918096508557,14.776016319939849,2.183023024461967,-7.196748914688529,-2.035927134290299,-7.544829329221174,-2.2106097324593805,2.858130117282808,-0.08254009109973981,0.9621192029928087,-2.6075338820214338,-0.377128183370134,-2.806820746788108,3.301270811972529,-0.6500619296194614,-0.018301854151316466,2.4655224490339744,-3.932136096369443,False,c3,1,"Couldn't figure out why core didn't work on my wiki with LDAP login. After some debugging I found out that lgdomain doesn't seem to be set anywhere at all. See https://www.mediawiki.org/w/api.php?action=help&modules=login|query+info
If I just hardcode login_request[""lgdomain""] = ""mydomain"" in api.py, it magically works. The login logic should look in the family file if self.ldapDomain is set and if that's the case include it in the request. Compat doesn't have this problem.
",90149,-19,High,False
1.73072781065339,7.002148128721732,0.545396932480589,-7.777016602204448,-5.7835280380109,-2.427015407149778,2.363605682851772,-3.8854999908174093,-4.204672444775501,-0.9361739154714352,0.851400780173988,-0.8017207642537247,-0.26048831818463736,-1.6444537412770526,-0.8719944868004799,0.4521769299758118,-1.1544473826089647,0.8850365494232959,False,c3,1,"Wikimedia DC has an SSL certificate from Gandi. Jeremyb knows more about it.
Since we own it, why not use it? I am mostly interested in using it for Stripe payment processing, which will handle the actual payment processing (including PCI compliance) as long as we use SSL on our end. But there are other uses, such as having login / logged in users handled by HTTPS, like with Wikimedia projects. Thoughts?
[Update] In light of recent events (e.g. https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/) I am suggesting that we use HTTPS for all of Wikimedia DC's web properties. I am also bumping this up to High priority",89080,-21,High,False
43.573542870108405,-0.7554092211783896,9.861760531377982,-2.8195860894149494,3.229563130936849,-0.19877977306206018,-1.8857355399681817,-1.1836583563292127,0.2195426371612187,-1.0241120581831051,-0.8711474773421086,0.2580342088907228,0.9543801687259852,-2.976712955070863,-1.808731635514409,0.1693231934101158,-0.2648662927295491,-0.5891669968751039,False,c3,1,"> svn.wikimedia.org
> Issued by: RapidSSL CA
> Expired: Saturday 31 January 2015
{F37611}",88731,-21,High,True
-8.104189174416689,4.40704992183089,-1.9804502529018535,-4.838159785975822,0.6036494364912768,-1.1198575443745145,7.014044063886307,-3.6656558482365496,-1.783764239192193,3.777372640798731,4.698277585548247,1.9247301283945732,0.4405474628485142,-0.22058728071974976,0.7372640009680369,1.9422694669716505,3.354516639460094,0.8143616134812597,False,c3,1,"This tracks the replacement of dumps.wikimedia.org sha1 cert with sha256 cert.
I'll link in the patchset, but I am not sure if we should simply push without announcement? Dumps are their own particular service, and interrupting any current downloads seems mean.",88497,-22,High,True
-4.534869215478604,10.56388766974743,-4.535345728293898,-3.4679636550150983,-13.847738272880562,-4.880931763349595,-1.299846631142752,-6.392956823270029,-7.127165330590546,-4.80519091017966,-2.618178222192257,0.0671683609526248,4.881634262196865,-2.078449938566836,1.810840714355571,4.331055099868001,-2.0432629273367935,2.046082989054714,False,c3,1,"%7C in my querystrings are turning in to %257C
```
$ curl -I ""http://office.wikimedia.org/w/api.php?format=json&action=query&meta=siteinfo&siprop=namespaces%7Cnamespacealiases%7Cmagicwords%7Cfunctionhooks%7Cextensiontags%7Cgeneral%7Cinterwikimap%7Clanguages%7Cprotocols""
HTTP/1.1 301 Moved Permanently
Server: Apache
X-Powered-By: HHVM/3.3.0-static
Location: https://office.wikimedia.org/w/api.php?format=json&action=query&meta=siteinfo&siprop=namespaces%257Cnamespacealiases%257Cmagicwords%257Cfunctionhooks%257Cextensiontags%257Cgeneral%257Cinterwikimap%257Clanguages%257Cprotocols
Content-Type: text/html; charset=iso-8859-1
[...]
```",88359,-22,High,True
-0.5494842258628072,4.041545361793723,4.800237195078168,5.8499552804085075,2.1365687996852327,0.37797261637646695,-5.449405651626375,-0.6498759172475583,-0.15970680461359743,-3.0021670126036186,7.87434002112129,0.8494875111264559,-4.699785094762281,0.4496692155310962,3.430825258835136,-2.9229161961254406,-0.8549008685279693,-0.5482062618723142,False,c3,1,"https://phab-01.wmflabs.org is down.
HTTPFutureCURLResponseStatus
[cURL/7] (http://localhost:9200/phabricator/_status/) <CURLE_COULDNT_CONNECT> The cURL library raised an error while making a request. You
may be able to find more information about this error (error code: 7) on the cURL site:
http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLECOULDNTCONNECT",88272,-22,High,True
-9.980446277666521,6.366635811208717,-2.9372711570489436,-9.708296147833158,-0.034886782648702486,-9.30833451301056,2.420017249749102,10.442481638653941,5.637989225871832,-0.37983513498109023,0.48449595329020845,-4.78875055015126,0.26833597889277394,-3.264581547906712,3.9725820879137563,5.491011656742604,2.0956441439272293,1.5898903264851756,False,c3,1,"They can already login to pretty much every host in prod, and can get themselves added to any project. Should just be automatic instead.",87094,-24,High,False
11.72278775797668,8.459906335115303,6.211996263696474,-5.351621014385793,-7.52917668735263,-5.428609463269361,-0.422023724290189,9.491777552797402,2.458659476767915,-2.216235205877294,-3.634103887263756,-4.932746444049425,-0.6803164605338559,-0.1365168261796601,-2.1406272405102937,-2.385751126802242,-0.537550561578781,-0.25238696604089617,False,c3,1,"On Special:ContentTranslation page,
```
Mixed Content: The page at 'https://es.wikipedia.org/wiki/Especial:ContentTranslation' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://cxserver.wikimedia.org/languagepairs'. This request has been blocked; the content must be served over HTTPS.
```
ContentTranslation likely to not work without https here.",86847,-25,High,True
-2.0135384664724585,9.689558845198224,2.4345510503837424,0.9313517301050513,-7.589685400627696,4.047546981127235,2.444898396408333,-0.514451719069344,-1.5336633929621064,1.1027635811629004,1.621107224255765,-3.058653122321293,1.1627307948498715,1.5457741578882542,-0.18201431037406923,-0.6653024489521485,2.4505195716241506,1.1985902386702028,False,c3,1,"We'll soon need:
- Extra resources, mainly CPU for all of our HTTP frontend (Varnish, nginx) clusters, due to an increased use of HTTPS & IPsec
- Clusters for codfw
As HTTPS scalability is one of the quarterly goals for FY Q3 2015 and there's a lead time for procurement and site installation (plus an extra delay for esams which needs an upgrade the most, due to not having a dedicated field tech), we'll need to do this procurement very soon.
The current blocker for this is testing of our new target platform (post- T86648 & T81543) as to have more accurate figures for proceeding with procurement. Current agreement on planning suggests:
- 2nd week of January + 2-3 first weeks of February for limited performance testing
- Late February/early March for proceeding with procurement in parallel to reinstallation of the current systems
- Rest of March: setup & install of the new servers",86663,-25,High,True
-11.516591441947092,6.059691447465152,-5.49969321200957,-5.754477485659282,0.9946796921537475,-5.34856763227933,3.3055607862643877,-2.176610886596562,0.39645290494818897,0.5516806529051879,0.9233661811425873,-0.6911733285288606,0.3548889403041118,0.10045316221730793,0.5461286540177337,-0.9739923060009938,0.7255430893576615,3.785008808254026,False,c3,1,"Our nginx TLS terminators are currently patched with a custom-written patch that adds udp2log logging support.
This is unmaintained, buggy (e.g. with regards to sequence number generation) and needs porting to each newer nginx version (and requires us to ship custom packages).
I remember hacking on it and fixing some bugs my second week at the foundation and people telling me to let it go as it was going away ""soon"". Almost three years ago have passed and we still have it, for reasons that still aren't clear to many people including myself.
We're moving to a much newer nginx version (1.6.x looks like) very soon, so it'd be nice to either deprecate the stream entirely, or falling to do that, properly architecture it and assign it a maintainer. This conversation is a blocker for a couple of quarterly goals for #ops so we should figure this out very soon.",86656,-25,High,True
-1.6710394940102935,6.980019108645099,-1.9245645981037,-0.198800977684224,-7.448185086549609,1.3089984220578728,-2.3013216037836477,0.02687912096842371,-1.4054768290741573,-0.9671861205104091,4.496944306750764,0.3880887196532412,-1.2344009432614902,1.1022847005615208,-0.27280362120939383,-0.6509718782321229,1.2654661977238162,-0.9338070726386689,False,c3,1,"Our current HTTP frontend fleet (frontend & backend Varnishes for routing & caching, nginx for SSL termination) runs on Ubuntu 12.04 (precise).
Mainly motivated by HTTPS improvements (newer libssl, nginx) and IPsec rollouts, we need to start moving our fleet to a newer platform. Debian jessie is a good candidate for this, as this is the next Wikimedia OS. This work is expected to happen by the end of FY Q3 2015.
For this we'll need to:
[x] Prepare infrastructure for jessie boxes (already done as part of a separate goal)
[x] Upgrade one canary box to jessie (cp1008)
[x] Rebuild custom-made packages for jessie, notably Varnish 3 (jessie ships with 4), varnishkafka; port upstart service files to systemd
[x] Reinstall one server of each type role (text, mobile, upload, bits) in production for live testing
[x] Make sure that everything works, new kernel in particular.
[x] Reinstall all servers across all datacenters
Note that related to this, we'll also need the availability of jessie images for Labs so that we can perform tests and so that Beta can keep up with production. For this, the availability of jessie images in Labs, T75592, is a blocker.",86648,-25,High,True
-2.0871453035359293,13.200815058738502,5.501613639983159,-4.5543002127509995,-1.456832690745824,-2.462117260628696,-2.6448139555544214,-2.744221982076482,6.167341609435948,-0.14688918285851837,0.07516820777152056,-1.6453635570837344,0.49982230558211604,0.12711410494240472,-0.20298321783569406,-1.76686635467748,1.431195755904566,-0.9020182560040308,False,c3,1,"As part of T1147, I requested:
> On an unrelated note, we also need a couple of new tags for HTTPS-related work: #HTTPS as a simple (yellow) tag to tag all HTTPS-related issues (whether ops-related or not) and another one for an HTTPS-by-default milestone #HTTPS-by-default. It could be argued that this can be a simple tag as well, a ""release"" tag or a ""sprint""; personally I think release fits best, but I don't care all that much.
@aklapper (rightfully) requested to bring this into a different task:
> HTTPS brought up by Faidon: Could we tackle the needs of HTTPS in a separate task? Simply because it's messy already (T29946 and Wikimedia-SSL-related exist from Bugzilla) and I'd like to see it less messy / sort that out in a dedicated task.
So here goes :) I'd like to ask to prioritize this a bit: TechOps has a quartery goal for HTTPS and we'd like to properly use Phabricator for tracking our tasks (for a change :)).",86063,-26,High,True
-2.900371399163892,8.625929789655196,2.3571649571362308,3.825024875257947,2.203249593983299,0.803193753205923,-0.12334065039640496,-0.7215517040682146,-0.8286464793631692,-1.5724101723939237,0.14192741536900222,0.36166750303621775,1.1083740666847168,-0.9714734369911557,-1.7692196462882719,-1.9254536061168603,0.21418610428082574,-0.19629984308798143,False,c3,1,"During an attempted GWToolset upload last year I encountered a problem when trying to upload some larger images 730Mb. The problem I encounter is that I get a HTTP timeout reply already at the second stage of the upload process.
@Dan-nl has also tried debugging this one for a while and concluded that there seems to be something wrong with the http-request that uses curl to discover the headers of the item which for some reason times out even though it's only requesting headers and not the file.
For testing the relevant xml is {F26865}, the mapping is at [[ http://commons.wikimedia.beta.wmflabs.org/wiki/GWToolset:Metadata_Mappings/Lokal_Profil/KB-maps.json | GWToolset:Metadata Mappings/Lokal Profil/KB-maps.json ]] and an example image for further testing can be found at https://data.kb.se/datasets/2014/06/kartor/2882568_53_Skargardskriget_hagelsta.tif",86024,-26,High,False
-2.2412092957986958,26.46489317501934,23.21217653479075,0.6834095169205037,-18.351457296020204,-0.7774545821115686,0.4512266684300972,-8.046761306388952,-5.547480726092394,-1.9771668246212637,-2.89567428371254,-2.58902934273386,-1.3012097042429938,-0.18367642670634332,-3.031306085524852,0.6310467786040816,-0.34684712764808245,1.7059611105618433,False,c3,1,the POST-answer after logging in with HTTPS via https://shinken.wmflabs.org/user/login redirects one to HTTP.,85326,-27,High,False
-5.1103407988925875,6.618686212021835,-4.778055151698446,-3.1405535548482146,2.4653677101556672,5.406949636796391,0.468949304583659,5.988200479641517,-1.5460004609557916,-2.3715032337658557,-2.6496553240653338,2.7003337911438985,-1.3592989380709506,0.8742542994831526,-0.8221485841699288,-1.0271366388452938,1.767440365912888,-0.7383775125687153,False,c3,1,"```
>>> http.fetch(uri='http://getstatuscode.com/301')
Exception in thread Thread-1:
Traceback (most recent call last):
File ""/usr/lib64/python2.7/threading.py"", line 811, in __bootstrap_inner
self.run()
File ""pywikibot/comms/threadedhttp.py"", line 486, in run
item.data = self.http.request(*item.args, **item.kwargs)
File ""pywikibot/comms/threadedhttp.py"", line 254, in request
uri, method, body, headers, response, content, max_redirects)
File ""pywikibot/comms/threadedhttp.py"", line 273, in _follow_redirect
response, content)
RedirectMissingLocation: Redirected but the response is missing a Location: header.
```
And the main thread doesnt return.
This exception is thrown by threadedhttp, whereas threadedhttp normally returns the exception to be passed back to the main thread.",78123,-30,High,True
12.791138821818834,13.254144513824315,10.199759362644329,7.007824924498676,-3.665430784748583,0.9982495691593212,-0.5044415205883332,-2.691016576404608,-2.522071756243477,-1.9953780406259671,-2.611829704028004,0.3442819628771674,-0.44871178385253163,-0.08131216206541048,-3.9580465880458213,-1.3775112280508905,1.797710074252601,-1.8694687678015334,False,c3,1,"on the login screen,
https://metrics.wmflabs.org/login
add this text from labs Terms of Use (TOS)
https://wikitech.wikimedia.org/wiki/Wikitech:Labs_Terms_of_use#If_my_tools_collect_Private_Information...
",76826,-30,High,True
12.963797452332827,-11.475102106271057,34.759522946744354,9.696565357086905,1.3492303009823325,-9.907712278938408,0.9364907152632229,-3.5208573474666482,0.5226903892647409,-0.955311198930592,-1.0199433887987768,1.6738316220805254,0.3289837583075732,-3.2640385906036458,-0.6398394840885482,0.14360108634508936,-0.025080037451755466,-0.4747017565048204,False,c3,1,"Chrome:
> The identity of this website has been verified by RapidSSL CA but it does not have public audit records.
> The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it.
{F18152}",76562,-31,High,True
0.4750710871384056,-4.350923730486645,2.803258025041494,-19.632053146816425,13.56157570538266,-24.797626703496793,0.20035984211683022,12.468889306359968,2.2583889637249213,-0.2834684231243596,4.385009186251278,-5.719295025239159,-9.046430088002374,7.905455552858536,-2.6167759119559997,0.9544088977133615,4.5742044681937575,-5.340101902579845,False,c3,1,https://gerrit.wikimedia.org/r/#/c/197341/ <- so I don't forget again!,97316,-10,Medium,True
8.20576823324411,20.14843636228911,-0.6358813518169377,-6.440690761925609,-19.637114118261515,3.9000528655154394,-2.0667486778490893,2.0004740929288016,-11.132970389403212,-4.320532138265926,-5.801871924120614,3.7215111707699853,0.08769308053399616,-5.598899624943899,1.111152480917161,10.322448108573733,-2.5556647525689735,-2.6509684159164304,True,c3,1,"https://wikitech.wikimedia.org/wiki/HTTPS is outdated.
...as pointed out by @BBlack in https://phabricator.wikimedia.org/T96676#1225820",96844,-11,Medium,False
-0.09792130495145202,12.659218629915049,10.121033492311081,10.056451223385801,4.12094042575343,2.6617513324492412,0.8917036462797219,-1.7280368466424716,-3.8680658664189655,-2.2123730808284403,-1.9513581238004483,1.0137050708128712,-0.8525785310579286,0.4493084202484079,-2.7486896752631753,-3.6513143046891825,-1.2625577148760303,-1.9274037147276284,False,c3,1,"When Nodepool spawns a Trusty image, the instance stall on boot while doing the puppet certificate work:
```
Info: Creating a new SSL key for i-00000b80.eqiad.wmflabs
Info: Caching certificate for ca
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for i-00000b80.eqiad.wmflabs
Info: Certificate Request fingerprint (SHA256): 24:DD:BF:BC:FA:B4:42:BC:E5:3D:58:F5:15:9F:51:D1:DE:7B:11:E1:F1:99:6A:D8:3A:CB:6F:B2:D4:E0:F6:BB
Info: Caching certificate for ca
Notice: Did not receive certificate
Notice: Did not receive certificate
Notice: Did not receive certificate
```
On Wikitech, the Nova_Resource page shows that it is missing a few fields injected by OpenStackManager. Compared to the [[ https://wikitech.wikimedia.org/wiki/Nova_Resource:I-00000b7b.eqiad.wmflabs | an instance manually created]], the instance spawned by Nodepool one is missing the fields:
```
Resource type
instance
Image Id
ubuntu-14.04-trusty
FQDN
i-00000b7b.eqiad.wmflabs
Puppet Class
base, role::labs::instance
Puppet Var
realm=labs, use_dnsmasq=true, instanceproject=contintcloud, instancename=trusty-manual
```
Looking at `firstboot.sh`, the script does a LDAP search to grab puppet vars:
```
$ ldapsearch -x -D 'cn=proxyagent,ou=profile,dc=wikimedia,dc=org' -w '###########' -b 'ou=hosts,dc=wikimedia,dc=org' 'dc=i-00000b7b.eqiad.wmflabs'|grep puppetVar
puppetVar: realm=labs
puppetVar: use_dnsmasq=true
puppetVar: instanceproject=contintcloud
puppetVar: instancename=trusty-manual
```
The same query yields nothing for the NodePool instance since that is injected by OpenStack manager.",96670,-11,Medium,True
-8.03127269099452,4.881600007728526,2.653340566038704,6.318951336121757,6.340237519290504,-5.981024909072511,5.850962399551219,3.6011654015266505,-3.5112209890947668,-0.08516999212579268,3.2652301984304946,2.1570318329235105,-2.5565035388399338,1.6724656937238338,-0.5617731718323311,-2.259978830132554,-1.8155928670954706,-1.230077338143281,False,c3,1,Instances that use the new naming scheme <instance>.<project>.eqiad.wmflabs should no longer need the ec2id. Stamp out its use for any case where use_dnsmasq is false.,95480,-13,Medium,True
10.743152671082525,4.1344712575413425,18.886067706436187,3.9656645660813794,2.2846587641200093,3.270127485083467,-4.171816365138152,-3.2728056811299946,-0.6530602227732323,-2.5048460019496264,-1.6429143445230259,-3.3887725147440433,0.8918165410066492,-3.7560956483469248,-1.1915060040747951,2.822926940081601,-3.81070662928479,3.3385685093390842,False,c3,1,"Accessing a url https://integration.wikimedia.org/cover/cdb
Result in
```
https://integration.wikimedia.org/cover/cdb
Remote port: 443
301 Moved Permanently
Location: http://integration.wikimedia.org/cover/cdb/
http://integration.wikimedia.org/cover/cdb/
Remote port: 80
301 Moved Permanently
Location: https://integration.wikimedia.org/cover/cdb/
https://integration.wikimedia.org/cover/cdb/
Remote port: 443
200 OK
```",95164,-13,Medium,False
-1.9235177266121137,0.3519177694611688,1.2796777252685594,-4.502148957104589,9.997942427631498,-8.69326493005441,1.6991093277972187,0.8586082380974064,-0.5029943303746722,1.9946737483341375,-0.7263390764462265,1.580642472099728,-1.1300412386800014,-0.740021272672271,1.6846663085396587,2.1598875285903585,-0.01500298650746279,-1.1982363779059475,False,c3,1,"Moritz has just been onboarded. His labs/LDAP user is ""jmm""
```
dn: uid=jmm,ou=people,dc=wikimedia,dc=org
uid: jmm
cn: Moritz Mühlenhoff
```
the Apache config for Icinga says:
```
44 AuthLDAPBindDN cn=proxyagent,ou=profile,dc=wikimedia,dc=org
46 AuthLDAPURL ""ldaps://ldap-eqiad.wikimedia.org ldap-codfw.wikimedia.org/ou=people,dc=wikimedia,dc=org?cn""
47 Require ldap-group cn=ops,ou=groups,dc=wikimedia,dc=org
48 Require ldap-group cn=wmf,ou=groups,dc=wikimedia,dc=org
49 Require ldap-group cn=nda,ou=groups,dc=wikimedia,dc=org
```
He is member in ops and wmf:
```
[terbium:~] $ ldaplist -l group ops | grep jmm
member: uid=jmm,ou=people,dc=wikimedia,dc=org
[terbium:~] $ ldaplist -l group wmf | grep jmm
member: uid=jmm,ou=people,dc=wikimedia,dc=org
```
but he reports he still can't login. He also can't login on graphite which should use the same auth method.
Why? Is the German umlaut in his name a problem?",94729,-14,Medium,True
0.6024750579800044,-1.7310847166087235,5.681754114932975,16.384376950611255,0.20966813487402314,-4.246211460244222,0.26592676541732985,-2.3222268219700952,-0.5816698472138684,-2.4067805154938244,1.4259272812954644,-1.6506127601716232,1.0670002759697068,-0.9413865570371236,2.7625242899180824,0.7622315321495687,0.36444551688781335,-1.7321972706506104,False,c3,1,"In the Tools project, the private key for the SSL certificate was stored in `/etc/ssl/private/star.wmflabs.org.key`.
@faidon's https://gerrit.wikimedia.org/r/#/c/197337/ removed the key file:
```
Mar 18 01:40:09 tools-webproxy-02 puppet-agent[9237]: Sleeping for 16 seconds (splay is enabled)
Mar 18 01:40:25 tools-webproxy-02 puppet-agent[9237]: Retrieving plugin
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/physicalcorecount.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/initsystem.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/apt.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/puppet_config_dir.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/lldp.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/ec2id.rb
Mar 18 01:40:29 tools-webproxy-02 puppet-agent[9237]: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Mar 18 01:40:35 tools-webproxy-02 puppet-agent[9237]: Caching catalog for i-000008b8.eqiad.wmflabs
Mar 18 01:40:36 tools-webproxy-02 puppet-agent[9237]: Applying configuration version '1426642569'
Mar 18 01:40:39 tools-webproxy-02 puppet-agent[9237]: instanceproject: tools
Mar 18 01:40:39 tools-webproxy-02 puppet-agent[9237]: (/Stage[main]/Role::Labs::Instance/Notify[instanceproject: tools]/message) defined 'message' as 'instanceproject: tools'
Mar 18 01:40:42 tools-webproxy-02 puppet-agent[9237]: hostname: tools-webproxy-02
Mar 18 01:40:42 tools-webproxy-02 puppet-agent[9237]: (/Stage[main]/Role::Labs::Instance/Notify[hostname: tools-webproxy-02]/message) defined 'message' as 'hostname: tools-webproxy-02'
Mar 18 01:40:53 tools-webproxy-02 puppet-agent[9237]: (/Stage[main]/Toollabs::Proxy/Install_certificate[star.wmflabs.org]/Sslcert::Certificate[star.wmflabs.org]/File[/etc/ssl/private/star.wmflabs.org.key]) Filebucketed /etc/ssl/private/star.wmflabs.org.key to puppet with sum 5e8a34bb0d41cedc7a8cce93e6af777e
Mar 18 01:40:53 tools-webproxy-02 puppet-agent[9237]: (/Stage[main]/Toollabs::Proxy/Install_certificate[star.wmflabs.org]/Sslcert::Certificate[star.wmflabs.org]/File[/etc/ssl/private/star.wmflabs.org.key]/ensure) removed
Mar 18 01:40:53 tools-webproxy-02 puppet-agent[9237]: (/Stage[main]/Toollabs::Proxy/Install_certificate[star.wmflabs.org]/Sslcert::Certificate[star.wmflabs.org]/File[/etc/ssl/localcerts/star.wmflabs.org.crt]/group) group changed 'ssl-cert' to 'root'
Mar 18 01:40:54 tools-webproxy-02 puppet-agent[9237]: Finished catalog run in 18.07 seconds
```
In outfactoring, `manifests/certs.pp`'s `ensure => present` became `modules/sslcert/manifests/certificate.pp`'s `ensure => absent` when `$privatekey` is `false`.
The key files are preserved by Puppet in the filebucket, but at the moment noone should reboot the proxies :-).
Looking at `operations/puppet` (there may be additional private puppetmasters), this affects `manifests/role/labsproxy.pp`, `manifests/role/protoproxy.pp`, `modules/toollabs/manifests/proxy.pp` and `modules/toollabs/manifests/static.pp`.",93212,-15,Medium,True
30.532185667145853,-5.150244450575244,16.583488996700552,1.4590661409229715,2.368917494038906,-3.487749437601697,-1.1851657694346,-1.9015982791591575,0.28587805206197103,-1.228966691323342,-1.0538584571164407,0.6444012685282525,0.9447362517111646,-3.18246422240951,-1.638811263855584,0.16025051711902083,-0.24939326285458852,-0.6246735785321789,False,c3,1,"> The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it.
{F90708}",92709,-16,Medium,True
-6.6978087588707815,9.004025445074213,1.5033291874282,-0.5677187305083271,-4.664142571038635,-0.5209760770212856,3.0701078087539218,-0.15172343896177642,0.1953793419542844,1.770929166858215,2.965498633414073,2.5337437691871854,0.7965169285988898,-0.864003147797316,1.3306206593533485,-0.6316940311180838,0.6294258316753576,0.9334658089345858,False,c3,1,"Most of MediaWiki was written with the assumption that MediaWiki and its data stores are collocated and connected via reliable, low-latency network links. Until recently, MediaWiki had minimal facilities for maintaining consistency and partition tolerance across wide-area network links. As a result, although the Wikimedia Foundation operates data centers in multiple locations, we only run MediaWiki in one location at any one time.
This has several practical consequences: first, we are not as fault-tolerant as we'd like to be. We have a secondary data center with enough capacity to serve our traffic in case our primary datacenter goes down, but it is in cold standby, meaning it takes some time (and some manual effort) to get it running. Second, site performance is poor for logged-in users that are geographically remote from Ashburn, Virginia, due to the time it takes to transmit and receive data across long-distance links. Thirdly, in some basic cases, like parsing pages, the master database must be up, leading to a SPOF.
It's going to take a lot of work to fix this completely, but we are getting closer to being able to serve some traffic from secondary datacenter. Specifically, we would like to serve ""reads"" -- requests that don't require a master database connection -- from a secondary datacenter.
In order to serve reads from a different datacenter, we need to be able to predict which incoming requests will modify data, so that we can route them accordingly. We need to be able to make this determination at the edge -- i.e., the outermost layers of the infrastructure, so it cannot be complicated or slow.
The solution we have is to use the HTTP request method (T91820): GETs/HEADs are read-only, while POSTs are not. This was already true for most cases, but there is a long tail of actions with side-effects that are done via GET, such as purge, rollback, markpatrolled.
This task mostly involves fixing DBPerformance log warnings. Warnings can be dealt with be:
a) Changing DB master reads to use DB slaves
b) Moving the database updates to POST requests, the jobqueue, or at least to post-send updates via DeferredUpdates
c) Disabling warnings for a few exceptional cases like CentralAuth.
See +channel:DBPerformance on logstash.wikimedia.org
Most of these warnings are writes or master queries on HTTP GET requests, which would be cross DC in active-active setup for some user. Ideally we could eventually get these to zero.",92357,-17,Medium,
-4.987281090801795,-3.9048443519479683,1.83363442218646,1.6707493547817163,2.913643422946977,1.679339990051292,5.396387912406813,2.8617083231885823,-5.517457451121062,1.4256435851321516,2.151984448400954,2.049804575098876,1.003952278584595,-1.0294540989196093,-1.436768936000555,-0.30785626673634825,-2.0622310366649472,3.204359029951008,False,c3,1,"When RESTBase makes external requests that fail, the resulting (wrapped) exception is void of useful context, and less helpful as a result.
Example:
```
Error: ETIMEDOUT
at null._onTimeout (/srv/deployment/restbase/deploy/node_modules/request/request.js:909:15)
at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
```
",92356,-17,Medium,True
-9.20133572536457,5.707302521725229,-2.1893401728918587,-0.7545844422999284,-1.8853296021185129,-1.7301013640883376,3.251704027154063,1.8142286114387627,0.009075488826899847,0.7933595110534482,1.6384814464539867,0.41139610601013077,-0.2669624831540469,-0.5411103810341267,0.3261672944363756,0.5730098376507117,0.943221251616553,0.4652915573062415,False,c3,1,"There have been a number of (possibly still theoretical) attacks to HTTPS during which an adversary can guess which pages are being visited merely by looking at the response length. This has been mitigated by other websites in various ways, e.g. Twitter profile pictures are put into certain specific size buckets.
We are particularly affected as our pages' content is a) all public and explorable via dumps, making it easier for the attacker to experiment and precompute, b) static and identical in most cases (anonymous users), b) text, assets, images are split into separate IPs and hence different TLS sessions, which both removes a randomized factor and creates even more unique combinations of traffic patterns.
To mitigate this kind of an attack we have to pad our responses up to certain (unguessable) sizes. There's a number of considerations that need to explored before doing so:
- As @csteipp points out, even a bucket classification won't be enough, as there are still enough bits of information there to make educated guesses based on click path behavior.
- Padding the HTML with e.g. zeros will be ineffective, as gzip compression will remove most of it from there. We could pad the HTML with random garbage, though, that wouldn't be defeated by gzip.
- Padding the HTML means that we'd have to pad other resources separately, some of which aren't even being served from MediaWiki (e.g. images/Swift).
- Padding to specific bucket sizes removes the precomputation-from-dumps factor but does not insert any randomness into the process. A padded text page + its associated, padded, images could still provide enough bits of information to figure out the page visited.
- Padding obviously increases the content size and comes with obvious performance issues; it's essentially a security/performance tradeoff. Depending on which piece of infrastructure it actually happens, it might also increase storage and/or cache size needed.
So far, it seems more likely that something that we could apply on the edge (either Varnish or nginx) and, potentially make it both bucket-based but with random placement, per request, would be the best strategy. It remains unknown if a) it's possible to pad a gzip response with zeros or garbage but still have it being parsed properly by UAs, b) if it's feasible to pad with HTTP headers and how many/lengthy these should be.",92298,-17,Medium,
-8.288218176767602,2.7296743618742774,-5.629996166203943,3.4298020813484174,1.1310180357710586,-3.114346049929293,-3.7017070405269474,-2.397042835910224,1.2822785205544691,-1.646149331808271,2.7629642863161767,0.7643800493749939,-0.8963246509522733,-2.0195762414309444,-0.4026453520557647,-0.6670182189747829,0.8509311777344866,-0.6360090259437272,False,c3,1,"this is a ticket to revoke the SSL cert:
metrics.wikimedia.org
[ ] - revoke with the CA / vendor
[x] -delete cert from public repo
[x] - delete the matching .key from private repo
[x] - rm/shred cert and key on servers it is installed on
(once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/
""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")
so this is intended to include that and the other steps, i will strike out what i have done. ",92044,-17,Medium,True
-8.215112045480526,2.4877775259812545,-5.571342884214916,3.7699434107080947,1.0075767875645882,-2.5284752995935573,-3.336560753694403,-1.9361881622888313,0.8798927418964992,-1.4362800394919981,2.507796247062289,0.6588850909980444,-0.5420547528000803,-2.1169159893656655,-0.6085904566138645,-0.6992746586508931,0.7747290546452386,-0.6439060397138507,False,c3,1,"this is a ticket to revoke the SSL cert:
stats.wikimedia.org
[ ] - revoke with the CA / vendor
[x] - delete cert from public repo
[x] - delete the matching .key from private repo
[x] - rm/shred cert and key on servers it is installed on
(once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/
""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")
so this is intended to include that and the other steps, i will strike out what i have done. ",92043,-17,Medium,True
0.15216049329180947,0.2074553747487755,5.4179118951843215,-0.10336646701144825,0.11456560410159777,-8.065168430538916,2.073271235061436,10.407063100847706,0.3871714308578824,-0.5359241703506674,-2.2225777940233806,-6.01998245580957,-0.3003861537151753,-4.1975417168524825,1.9894453998114612,-1.8341737499002,2.915812096142232,-1.4096693037685075,False,c3,1,"```
Request: POST http://phabricator.wikimedia.org/auth/login/ldap:self/, from 10.64.0.172 via cp1044 cp1044 ([10.64.0.172]:80), Varnish XID 1060355216
Forwarded for: [my IP], 10.64.0.172
Error: 503, Service Unavailable at Mon, 09 Mar 2015 11:45:02 GMT
```
Was getting this last week as well (didn't try again until today). Login via OAuth works. ",91960,-17,Medium,True
2.4069119214676618,0.8183463454826381,1.4552194055223673,0.8417067305973234,-0.2184335509323816,0.02816788132810233,1.9555664377040562,1.8943074078528994,-0.37817950671076395,1.9986201760685214,2.075600271045816,1.8649947066603667,-0.052569233391415615,0.6017665815103959,-0.8980322874705848,-0.44202019970844086,0.3945627773157554,-0.19746007258295162,False,c3,1,"CDN routing logic should be:
# If HTTP POST => master DC.
** Reason: This will perform writes to the primary database which should be done locally.
# If cookie ""UseDC=master"" is present => master DC.
** Reason: The user has recently made writes (database, session). To ensure the user sees their own actions reflected, and to minimise chances of needing to do synchronous waits, the user is ""stickied"" to the primary DC for a few seconds until we're confident cross-dc DB and session replication has completed.
** This also ensures we don't need a multi-dc aware ChronologyProtector, per T254634.
# If URL param ""cpPosIndex="" is present => master DC.
** Reason: The user has recently made writes (database, session) and is now being redirected to a cross-wiki domain. To ensure the user sees their own actions reflected, and to minimise chances of needing to do synchronous waits, the user is ""stickied"" to the primary DC for a few seconds until we're confident cross-dc DB and session replication has completed.
** This also ensures we don't need a multi-dc aware ChronologyProtector, per T254634.
# Requests that perform database writes over GET (like HTTP POST)
** GET index.php action=rollback => master DC (per T88044).
*** Reason: This is a user action that for legacy reason cannot yet use form submissions.
** GET login.wikimedia.org Special:CentralAutoLogin => master DC.
*** Reason: This auto-creates local accounts and cross-domain login sessions through a chain of redirects and hence can't use POST. In addition to sometimes performing db writes, it also needs access to the latest user sessions and ChronologyProtector, per T254634#6211514. Note that the `Special:CentralAutoLogin` url is never localised to make this easy.
# Cache/stash write optimisations => master DC
** GET/POST api.php action=centralauthtoken or centralauthtoken=, or an Authorization header which starts with CentralAuthToken (T267270)
*** Reason: Foreign API tokens need to be set and then immediately consumed. Latency will probably be reduced by routing these requests at the CDN layer rather using mcrouter to do cross-DC memcached requests.
# Anything else, e.g. HTTP GET/HEAD/OPTION => local DC.
# HTTP POST with `Promise-Non-Write-API-Action: true` header => local DC (exception to rule 1).
** Reason: These are AJAX POST requests that only fetch data. They use POST due to the limited payload size that GET requests allow.
See also:
* <https://www.mediawiki.org/wiki/Requests_for_comment/Master_%26_slave_datacenter_strategy_for_MediaWiki#Request_routing>",91820,-17,Medium,False
0.4937646002334022,5.578104489263957,-5.089709085160022,-3.716649960883367,4.229446492835814,3.1062255397898664,0.407020033592314,4.114293755747267,-2.704758762836094,-0.9658126304043315,0.250021876874444,-0.6168119823337073,1.1623776840026383,-1.948592051954436,-0.5467416484518282,1.5020344872998312,-1.2624440460298354,-0.5432969310656486,False,c3,1,"The SSL-config of the OTRS (ticket.wikimedia.org) is outdated. No PFS, weak key-options and the MAC of the certificate still use SHA1 (the later is not that urgent and can be fixed during the next cert-renewing).
Because the OTRS contains sensitive data, a SSL-setup that is at least as secure as the SSL-config for Wikipedia is needed.
Maybe it would be a good idea to config DNSSEC for that domain too (and if you REALLY in the mood: DANE too).",91504,-18,Medium,False
-10.18126617486114,11.825614689771367,2.363272147443773,-4.123571870084458,-10.212191099650186,-0.8636049790920988,-7.50955863092686,8.555695656284799,15.114063776561144,-1.1498764185534593,-1.2219973696541748,7.718844727562968,2.4522859086481406,-1.204310046959268,-0.18493020233785007,-1.1703948070355763,4.107328117676019,1.080342192637857,False,c3,1,"Monitor for logins to succeed. Any of keystone, wikitech, or ldap being down will cause this to fail.",91226,-18,Medium,False
15.285507340587706,4.188302011030423,3.094724568780123,3.0760488982819405,17.372346447970404,7.270015529187879,-2.402023777587506,3.253475602250136,5.677013254617487,1.1332114449679134,3.3610084212430738,-3.1525813440930035,1.9495182172299832,-1.412940537455715,-0.9003187672247668,2.787044619120768,2.7378482514110907,2.326874879573232,False,c3,1,"No PFS, old MAC (Sha1) and the ciphers could use an update too.",90351,-19,Medium,True
125.12864973473413,24.461032312281354,20.258054462711378,-15.368139377215654,9.419729155465951,8.923586496494865,0.5660249642391806,-0.39953809071088453,0.6528691956095768,3.4089737421423614,1.8893517820205266,0.7864180118380248,-2.4641331367967334,-0.5539055659455503,1.5844758167120787,0.15244468824303828,0.8508428236510508,0.8283642692908557,False,c3,1,https://github.com/wikimedia/mediawiki-extensions-PageTriage/blob/ccaae01d5763f0a443c04838e206b82bae3dc930/modules/ext.pageTriage.util/ext.pageTriage.viewUtil.js#L52,90328,-19,Medium,False
-6.450054657823781,6.753478631583018,0.6033047932757647,-2.8073768821638487,-0.16387444911748134,0.0007951942360457931,4.702570644169506,1.2839554900590353,-5.004848786849602,-0.9159911641765146,-0.20747086760744882,2.9655668974337175,-0.10182524092673617,0.7711083421736884,2.418673979270233,0.6766508371876936,-0.5451142915758532,-0.1802187173988512,False,c3,1,"It's been discouraged since its inception, but has now officially been deprecated as of Chrome 40 and Firefox 30.
> Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.
http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
For the web's integrity, it's unlikely the features will be removed. Though new features are requirement to not allow use of these (e.g. XHR2 features only work asynchronous). While the deprecation reasons (performance( are reason enough, having these in our code base is an additional blocker for improvements of the lower level interfaces.",90327,-19,Medium,
8.055910286244687,-4.140309915149912,-3.67354509991436,3.581307895879858,1.459491159370439,-3.0787841170041474,-0.2624755350360397,0.23764694614211546,0.03556001923492691,-3.26355565372417,-2.7928740568242785,0.8291341019495191,2.1364903618884687,3.8173827280305375,0.5082962517634142,0.48397113592087015,0.8364931998391725,-0.4888548837706175,False,c3,1,"this very well might be a duplicate but can't find it now...
/wiki/Special:EntityData/Q13529975.json HttpError from line 359 of /srv/mediawiki/php-1.25wmf17/extensions/Wikidata/extensions/Wikibase/repo/includes/LinkedData/EntityDataRequestHandler.php: Failed to load entity Q13529975.
#0 /srv/mediawiki/php-1.25wmf17/extensions/Wikidata/extensions/Wikibase/repo/includes/LinkedData/EntityDataRequestHandler.php(378): Wikibase\Repo\LinkedData\EntityDataRequestHandler->getEntityRevision()
#1 /srv/mediawiki/php-1.25wmf17/extensions/Wikidata/extensions/Wikibase/repo/includes/LinkedData/EntityDataRequestHandler.php(227): Wikibase\Repo\LinkedData\EntityDataRequestHandler->showData()
#2 /srv/mediawiki/php-1.25wmf17/extensions/Wikidata/extensions/Wikibase/repo/includes/specials/SpecialEntityData.php(153): Wikibase\Repo\LinkedData\EntityDataRequestHandler->handleRequest()
#3 /srv/mediawiki/php-1.25wmf17/includes/specialpage/SpecialPage.php(383): Wikibase\Repo\Specials\SpecialEntityData->execute()
#4 /srv/mediawiki/php-1.25wmf17/includes/specialpage/SpecialPageFactory.php(581): SpecialPage->run()
#5 /srv/mediawiki/php-1.25wmf17/includes/MediaWiki.php(270): SpecialPageFactory::executePath()
#6 /srv/mediawiki/php-1.25wmf17/includes/MediaWiki.php(560): MediaWiki->performRequest()
#7 /srv/mediawiki/php-1.25wmf17/includes/MediaWiki.php(424): MediaWiki->main()
#8 /srv/mediawiki/php-1.25wmf17/index.php(46): MediaWiki->run()
if the entity does not exist, then don't think this is such an exceptional condition or error in the software. I don't think this should go in the exception logs, together with other exception log entries.",90270,-19,Medium,True
-10.623659184079909,3.464564804053815,0.4536913472287729,2.985269892445446,-5.442560505064421,-8.187806978860921,3.0771466226089244,6.313004859335654,0.6177908441726334,-0.6643633031850857,1.5761617889502486,-2.149972781890136,0.4710394333445689,-0.9334410346983328,0.7811779989621241,0.6893894839533685,-0.9001813814309719,2.1653025731744755,False,c3,1,"We should have default and informative 404 and 5xx pages automatically used by all tool web configs unless specified otherwise.
These pages should explain to visitors what is happening/where to get help etc as best as possible. (list maintainers ?)",89864,-20,Medium,False
10.870756464144508,-6.768742328452307,-8.761555700888998,-1.4622558346888237,3.5176185003926963,-3.621611205013042,-5.776774444932466,9.142805871045091,-2.2108714287100684,26.43127285476219,-2.2374080856967598,2.4849645413299086,0.570076094068515,-5.886558991970926,7.864967548840601,0.7934511444588875,-1.4268212267569158,8.04228421816387,True,c3,1,"""Join Wikipedia"" should be quiet, and not ""large"" style ",89860,-20,Medium,False
3.146841056495107,6.370950515706369,2.343997340882783,-8.287542177150245,6.7573451601378665,-2.169605705588026,3.9900334992777777,2.1038783528779166,-6.872707736578421,1.307153072612799,0.34967861829594993,-0.003969368491855363,-0.8664915279648389,0.019619997039139747,-1.0903853361000664,-0.5390558878730197,0.35358124203946284,0.3604623347252811,False,c3,1,"When accessing URLs over HTTPS from my IPv6 connection, I get the following header:
> Set-Cookie: GeoIP=NL::52.3667:4.9000:v4; Path=/; Domain=.wikinews.org
I'm obviously not in the Netherlands — this is geolocating esams' IPs (the cookie was introduced in https://gerrit.wikimedia.org/r/#/c/119014/ ).
Non-HTTPS hits do not exhibit the same issue, nor are non-IPv6. This explains why this has gone undetected for as long as it has.",89688,-20,Medium,False
-5.164426845046266,0.8703490481287535,2.1338782139846657,2.7434559508905636,5.701822646382972,-2.766054585616047,0.2560534612954788,8.185857472025852,4.536658431187257,-0.6567257637911492,0.2679236353307539,5.449607540623652,1.2827211918705976,-1.0385727317325402,-0.2683088973874739,0.9079571571204983,1.9811313081591775,-3.094028083388882,False,c3,1,"This code:
```
in_array( $request->getFullRequestURL(), $requestTitle->getSquidURLs() )
```
is used to determine whether the current URL is cacheable. But for HTTPS views, `getFullRequestURL()` returns an HTTPS URL while `getSquidURLs()` returns an array of HTTP URLs, so the `in_array()` call will never return true and the request will never be considered cacheable.
This means cache misses from HTTPS users are never used to populate the cache :(",89673,-20,Medium,True
-4.756174177113107,4.728517469489976,5.9670005871894745,-5.56196079361168,7.795927483195996,-6.283938605041226,0.9039058319641784,-1.3161624922968351,-2.771193269466795,-3.3427199127251654,-1.7593002044416528,-2.891547278026671,-0.6101027434734592,-1.0637243958868994,0.27596613699799555,-0.8392380209293582,-2.7763142720523626,-0.3006068736884069,False,c3,1,"https://integration.wikimedia.org/ci/job/UploadWizard-api-commons.wikimedia.beta.wmflabs.org/buildTimeTrend
The error is
```
error: username and password required. Pass these values with the corresponding flags or set the env variables: MEDIAWIKI_USER and MEDIAWIKI_PASSWORD or MEDIAWIKI_PASSWORD_VARIABLE (points to env var with password value)
```
They also take a lot longer recently than they used to.
",89272,-21,Medium,False
4.9852035606304135,2.556920673882235,8.816409725417984,4.5629819018496525,2.4447290231092826,-0.2567212730276839,-1.9391601977106268,-3.165533307537457,-3.6146579628600835,-2.7406961576656244,-3.001190509935219,1.725021471257447,0.4793835206192769,-0.6431312585991851,-5.745082243348885,-4.129027788530825,-2.437047243692183,1.980237059864607,False,c3,1,"The browser tests https://integration.wikimedia.org/ci/job/browsertests-UniversalLanguageSelector-sandbox.translatewiki.net-linux-firefox-sauce/ keeps failing because:
```
mw-api-siteinfo.py http://sandbox.translatewiki.net/w/api.php git_branch
requests.exceptions.SSLError: hostname 'sandbox.translatewiki.net' doesn't match 'translatewiki.net'
```
",89244,-21,Medium,True
-10.102135839283132,2.63578047477057,1.0298421947010539,3.47912276629257,-2.4665583133832505,-5.938948643752977,4.083921182865837,3.1618410199702063,-0.7524598513347176,0.30681157182358554,2.3806754518467623,0.2344756147097884,4.431226545778202,2.052334997498658,0.8534668772861949,-2.53398267617547,-2.182163047347352,0.2026127611838089,False,c3,1,"hi,
see also T88412 for more context, it seems bogus captchaid yield http 500 back to the client whereas returning some flavor of http 400 would be more correct:
```
erbium:~$ grep miss/50 /a/log/webrequest/sampled-1000.tsv.log | grep Captcha | uniq -f2 -w16 -c | awk '{print $1 "" "" $4 "" "" $9 "" "" $10}'
1 2015-02-09T06:43:25 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=1821936605
4 2015-02-09T07:10:19 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=399458500
1 2015-02-09T07:25:45 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=950331796
1 2015-02-09T07:30:36 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=457819367
2 2015-02-09T08:36:32 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=1787180145
2 2015-02-09T08:53:15 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=675749755
2 2015-02-09T09:01:54 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=1360792335
2 2015-02-09T09:14:31 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=1274562332
1 2015-02-09T09:29:18 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=394009108
1 2015-02-09T09:36:44 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=2111699485
1 2015-02-09T09:47:19 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=2118419926
1 2015-02-09T09:54:15 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=477299702
2 2015-02-09T10:11:54 GET http://de.wikipedia.org/w/index.php?title=Spezial%3ACaptcha%2Fimage&wpCaptchaId=1263614379
```",88970,-21,Medium,True
4.943323202402759,-4.962717348479751,0.98777416724581,5.356702742555871,0.08162931568276677,-7.246386563507991,-4.658496462915628,-1.1733254223950835,-3.846946801351984,-2.17832955711001,-0.23932426515128213,-0.8879903050999862,13.64500533887432,11.236262523752002,8.284665543269107,-1.3032304938968873,0.5406003356944449,1.279576839779253,False,c3,1,"looking at the sampled logs on erbium it seems we're throwing http 500s regularly when generating thumbs, most errors seem due to the wrong size being requested that would result in upscaling the image.
I'm sure this is known already but it'd seem more logical for such errors to return a 400 to the client since it isn't strictly the server's fault, what do you think?
```
erbium:~$ grep miss/50 /a/log/webrequest/sampled-1000.tsv.log | uniq -f2 -w16 -c | awk '{print $1 "" "" $4 "" "" $9 "" "" $10}'
6 2015-02-03T06:26:29 GET http://upload.wikimedia.org/wikipedia/el/thumb/9/9e/%CE%A0%CE%B1%CF%81%CE%B1%CE%BC%CE%B5%CE%BB%CE%B7%CE%BC%CE%AD%CE%BD%CE%B7_%CE%9F%CF%85%CF%81%CE%B9%CE%BA%CE%AE_%CE%B1%CF%81%CE%B8%CF%81%CE%AF%CF%84%CE%B9%CF%82_%CE%A7%CE%B5%CF%81%CE%B9%CF%8E%CE%BD.JPG/1032px-%CE%A0%CE%B1%CF%81%CE%B1%CE%BC%CE%B5%CE%BB%CE%B7%CE%BC%CE%AD%CE%BD%CE%B7_%CE%9F%CF%85%CF%81%CE%B9%CE%BA%CE%AE_%CE%B1%CF%81%CE%B8%CF%81%CE%AF%CF%84%CE%B9%CF%82_%CE%A7%CE%B5%CF%81%CE%B9%CF%8E%CE%BD.JPG
19 2015-02-03T06:30:14 GET http://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Commons-logo.svg/36px-Commons-logo.svg.png%202x""%20data-file-width=""1024""%20data-file-height=""1376""%20/></a>%20<b><span%20class=""plainlinks""><a%20class=""external%20text""%20href=""http:/lookup-api.apple.com.edgesuite.net/commons.wikimedia.org/wiki/?uselang=it"">Commons</a></span></b>
7 2015-02-03T06:40:19 GET http://upload.wikimedia.org/wikipedia/en/thumb/6/6f/Vathikuchi.jpg/402px-Vathikuchi.jpg
10 2015-02-03T06:51:42 GET http://upload.wikimedia.org/wikipedia/commons/thumb/8/86/Valencia01_11-2-03.JPG/794px-Valencia01_11-2-03.JPG
7 2015-02-03T07:00:14 GET http://upload.wikimedia.org/wikipedia/en/thumb/9/9e/Koli_tree_near_Panamaram_fort_site.JPG/1024px-Koli_tree_near_Panamaram_fort_site.JPG
13 2015-02-03T07:10:25 GET http://upload.wikimedia.org/wikipedia/ja/thumb/9/95/%E3%83%88%E3%82%B3%E3%82%B8%E3%83%A9%E3%83%9F_%E6%8A%9C%E3%81%91%E6%AE%BB.JPG/640px-%E3%83%88%E3%82%B3%E3%82%B8%E3%83%A9%E3%83%9F_%E6%8A%9C%E3%81%91%E6%AE%BB.JPG
14 2015-02-03T07:21:22 GET http://upload.wikimedia.org/wikipedia/commons/thumb/6/61/Opentail_g.svg/8px-Opentail_g.svg.png""%20width=""8""%20height=""14""%20srcset=""http:/lookup-api.apple.com.edgesuite.net/upload.wikimedia.org/wikipedia/commons/thumb/6/61/Opentail_g.svg/12px-Opentail_g.svg.png%201.5x,%20http:/lookup-api.apple.com.edgesuite.net/upload.wikimedia.org/wikipedia/commons/thumb/6/61/Opentail_g.svg/16px-Opentail_g.svg.png%202x""%20data-file-width=""115""%20data-file-height=""196""%20/></a>
10 2015-02-03T07:30:50 GET http://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Flag_of_the_People%27s_Republic_of_China.svg/35px-Flag_of_the_People%27s_Republic_of_China.svg.png%201.5x,%20http:/lookup-api.apple.com.edgesuite.net/upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Flag_of_the_People%27s_Republic_of_China.svg/45px-Flag_of_the_People%27s_Republic_of_China.svg.png%202x""%20data-file-width=""900""%20data-file-height=""600""%20/>&
11 2015-02-03T07:40:05 GET http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Casino_slots2.jpg/
18 2015-02-03T07:50:32 GET http://upload.wikimedia.org/wikipedia/commons/thumb/c/c9/Laos.Visa.JPG/1005px-Laos.Visa.JPG
15 2015-02-03T08:00:36 GET http://upload.wikimedia.org/wikipedia/commons/thumb/a/a0/Fairytale_bookmark_silver.svg/21px-Fairytale_bookmark_silver.svg.png%201.5x,%20http:/lookup-api.apple.com.edgesuite.net/upload.wikimedia.org/wikipedia/commons/thumb/a/a0/Fairytale_bookmark_silver.svg/28px-Fairytale_bookmark_silver.svg.png%202x""%20data-file-width=""100""%20data-file-height=""100""%20/></span>%20<i><a%20href=""/wiki/L%27Illusion_comique_(t%C3%A9l%C3%A9film)""%20title=""L
9 2015-02-03T08:11:23 GET http://upload.wikimedia.org/wikipedia/commons/thumb/8/88/WIN31SOD.JPG/816px-WIN31SOD.JPG
11 2015-02-03T08:20:25 GET http://upload.wikimedia.org/wikipedia/commons/thumb/9/9d/Warszawa%2C_Pa%C5%82ac_Kultury_i_Nauki_-_26.11.2009_r..JPG/728px-Warszawa%2C_Pa%C5%82ac_Kultury_i_Nauki_-_26.11.2009_r..JPG
15 2015-02-03T08:30:00 GET http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Torre_de_Belem_1.JPG/1024px-Torre_de_Belem_1.JPG
20 2015-02-03T08:40:03 GET http://upload.wikimedia.org/wikipedia/commons/thumb/0/0e/TRON_9-9145.gif/16px-TRON_9-9145.gif
22 2015-02-03T08:50:08 GET http://it.wikipedia.org/w/index.php?title=Speciale:Captcha/image&wpCaptchaId=160756292
18 2015-02-03T09:01:52 GET http://upload.wikimedia.org/wikipedia/en/thumb/6/6f/Vathikuchi.jpg/402px-Vathikuchi.jpg
23 2015-02-03T09:11:18 GET http://upload.wikimedia.org/wikipedia/commons/thumb/b/b3/2005_Pebble_Beach_Concours_Bertone.PNG/466px-2005_Pebble_Beach_Concours_Bertone.PNG
19 2015-02-03T09:20:28 GET http://upload.wikimedia.org/wikipedia/en/thumb/4/49/ImamRezaHospital.JPG/800px-ImamRezaHospital.JPG
10 2015-02-03T09:30:18 GET http://upload.wikimedia.org/wikipedia/en/thumb/2/2e/Wine_TV.PNG/96px-Wine_TV.PNG
",88412,-22,Medium,True
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c3,1,nan,88139,-22,Medium,True
-6.156394721705956,9.578032614757962,0.08305481544586968,-9.224308020207673,-0.35517931658302526,-1.5367629671653387,3.4465301869471476,-1.1889726273144268,-3.874374708501109,1.0242426504798114,1.2806622692258745,-2.388288239485753,-1.620140401125128,0.9580683674845334,0.1305407428568639,0.2363646047271567,0.8812166994814967,-1.9890300253507485,False,c3,1,"I have recently observed that, whenever I visit ru.wikiquote, I'm not logged in, while I'm logged in in dozens other Wikiquote subdomains (even never visited before) in the same Chromium window.
The only difference I can spot is that the console is full of deprecation errors, probably due to the recent deprecation galore and the following scripts:
```
https://ru.wikiquote.org/w/index.php?title=MediaWiki:Wikificator.js&action=raw&ctype=text/javascript
https://ru.wikiquote.org/w/index.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript
https://ru.wikiquote.org/w/index.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript
```
Such deprecation errors have already put the entire JavaScript codebase of other wikis KO before, cf. {T86142}, so they might as well cause a failure of the CentralAuth JavaScript.
For instance, at https://ru.wikiquote.org/w/index.php?title=%D0%95%D0%B2%D1%80%D0%B8%D0%BF%D0%B8%D0%B4&action=edit&debug=true I get:
```
Use of ""wgCanonicalNamespace"" is deprecated. Use mw.config instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getload.php?debug=true&lang=ru&modules=site&only=scripts&skin=vector&*:120 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""wgAction"" is deprecated. Use mw.config instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getload.php?debug=true&lang=ru&modules=site&only=scripts&skin=vector&*:121 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""addOnloadHook"" is deprecated. Use jQuery instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getload.php?debug=true&lang=ru&modules=site&only=scripts&skin=vector&*:122 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""addOnloadHook"" is deprecated. Use jQuery instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getload.php?debug=true&lang=ru&modules=site&only=scripts&skin=vector&*:123 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""addOnloadHook"" is deprecated. Use jQuery instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getload.php?debug=true&lang=ru&modules=site&only=scripts&skin=vector&*:124 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""wgAction"" is deprecated. Use mw.config instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getload.php?debug=true&lang=ru&modules=site&only=scripts&skin=vector&*:126 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:7 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""addOnloadHook"" is deprecated. Use jQuery instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:23 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""appendCSS"" is deprecated. Use mediawiki.util instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:67 summaryButtonsindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:79 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""wgNamespaceNumber"" is deprecated. Use mw.config instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:85 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""wgNamespaceNumber"" is deprecated. Use mw.config instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:85 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""wgAction"" is deprecated. Use mw.config instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:112 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:2 addCustomButtonindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:5 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:2 addCustomButtonindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:6 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:2 addCustomButtonindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:7 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:2 addCustomButtonindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:8 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:2 addCustomButtonindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:9 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:2 addCustomButtonindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:11 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:14 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:3143 fireload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:3189 self.addload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:3423 jQuery.fn.readyload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:2863 jQuery.fn.initload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:73 jQueryindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:13 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:17 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""appendCSS"" is deprecated. Use mediawiki.util instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:ToolbarOld.js&action=raw&ctype=text/javascript:20 (anonymous function)
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:28 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:29 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:29 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:29 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:29 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:29 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:29 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10956 Use of ""mwCustomEditButtons"" is deprecated. Use mw.toolbar instead.
load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 console.trace()load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10958 mw.log.log.warnload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:10982 Object.defineProperty.getindex.php?title=MediaWiki:Editpage.js&action=raw&ctype=text/javascript:29 (anonymous function)wikibits.js:87 (anonymous function)load.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4665 jQuery.event.dispatchload.php?debug=true&lang=ru&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150113T19…:4333 elemData.handle
```",87741,-23,Medium,True
-6.245455906652428,8.823048630654782,5.660260739481444,4.355240820668946,1.029241131348976,-0.033900101611300526,-3.0774989356113807,2.360221087900078,11.446779952631298,2.8709024554491585,-1.2258080883115983,3.711813796543338,-1.526492071119617,2.7943449774473317,1.7861221487475776,1.301752424219499,-1.9351555272907015,-1.7416128887386608,False,c3,1,"If GoogleLogin replaces the MediaWiki login form, the user can not select ""keep login"" to hold his session for a longer time. There should be a config option, to handle the default value of keep login (e.g. enable keep login for all logins).
See: https://www.mediawiki.org/wiki/Thread:Extension_talk:GoogleLogin/Sessions_are_extremely_short-lived",87675,-23,Medium,True
-6.763279706077123,12.15347300081272,2.514856734511344,0.13082229119741418,0.5576585727409817,0.21664694172005983,0.11120034574304949,1.4892791153995142,7.059713530287333,0.7412946810319481,1.988223299998889,3.548012651146488,0.6322932725604584,0.11676365671863209,1.3874618955545799,-0.12144267270420195,-2.298956944167405,-0.9698549583372271,False,c3,1,"NavigationTiming is an important schema that can reveal problems quicker. For example, Russian Wikipedia added an https redirect in their Common.js and their page load time increased dramatically.
Write a SQL query that grabs data which could be used to show this problem, then graph it so the information is easy to consume. Use this exercise as a way to brainstorm how to work with NavigationTiming in the future and how to make the useful data it gathers more easy to consume.",87604,-23,Medium,False
-3.2269733403804866,10.983883244051771,-1.3417748029907326,-4.545765699665676,-4.0662614195707505,-0.4326809375354036,0.28419810354313135,-2.7568422929632037,2.995365495959491,-0.149659526022079,0.6951953524541548,0.10739917881716421,0.5767522850572524,-2.307881816116408,1.998998741569614,-0.5023077172536202,0.15983335131837717,0.24964798108759978,False,c3,1,"As an English Wikipedia bot operator, I am using Parsoid to retrieve parsed HTML versions of Wikipedia articles as part of the operation of my bot. As I'm trying to be a good citizen and not cause the nice people in WMF's analytics department any particular headaches, I thought it might be sensible to set a custom User-Agent string for my requests.
I can only do this by overriding the string set manually in lib/mediawiki.ApiRequest.js - making it so that this can be overridden from the localsettings.js would be quite useful for bot operators who are using Parsoid to retrieve parsed copies of content from MediaWiki installations.
(I may be able to prepare a patch, but filing the issue first in case I don't get around to it.)",87513,-23,Medium,True
-7.374017918836403,11.634012024250104,12.430343844219287,-1.2842314419061998,-5.209867855315576,-8.007809195251113,1.125083584625088,-11.785621724101892,1.0648473850539255,-1.3816750509007987,0.603002098773064,0.5456049226872259,-0.088211133402746,-1.09337989289964,-0.47235758122682725,2.822159200348372,1.8755593584345445,-2.653814212445979,False,c3,1,"For example try this page:
http://parsoid-lb.eqiad.wikimedia.org/dewikivoyage/Via_Jutlandica/Gpx
In my case, it runs without any end.",87266,-24,Medium,False
38.978108781983686,-2.8536767175229087,24.769377736224563,2.0884597305394412,3.1178387517235717,-4.092927615938343,-0.010367084307365104,-2.327582345207313,0.44461624407010747,-0.342131054656984,-0.5497511809331534,1.0959971119138523,0.12064137298127697,-2.776460251828296,-0.6845415571724853,0.15183517303813768,0.02664093829401315,-0.3207363767146345,False,c3,1,">>! In T72705#976450, @Kabhi2104 wrote:
> {F28605} Uploaded provision.log here too for future reference and this is the link of new paste https://phabricator.wikimedia.org/P216
",86787,-25,Medium,False
-11.63256814938255,14.359139144982176,-2.323780101050831,0.3360543202255011,-1.4421012957597354,3.3324573427802893,3.5933596319040655,-8.49277846329268,-0.6301815055087365,3.2687227937682053,6.707095011116236,-0.9291818684326824,2.6378942883644916,0.3961235994067822,-2.9272565729150157,-0.38260838958671184,0.004546202883824568,-0.07460167057135836,False,c3,1,"As we have migrated to the new globalsign certificates for the main wiki-cluster, we need to revoke the exisiting digicert certs.",86689,-25,Medium,True
-1.695014316934398,1.8332455037068165,-4.860151881472358,-3.020174823200386,-7.088435618347246,-6.402709638136955,2.569598333342671,-4.521856335156061,7.554683107517908,-0.5334161229679832,-0.009365265729205596,1.542133255657596,-0.0458065153949736,3.2438045912346976,2.010390420519812,0.3241190631503056,2.1021005733990137,2.095066945081318,False,c3,1,We should use nginx's newly-supported feature (plus scripts we should write) to perform staggered master encryption key rollovers for RFC 5077 session tickers.,86671,-25,Medium,False
2.7721918226868367,4.482841223234825,2.631756401616421,0.6298107325024356,-5.482899411138721,-1.5889878459422646,-3.858085241846505,2.4128378464712767,-1.8665985118812636,-2.5241030538550033,4.9611057030802606,-0.8788111872106976,-3.2667597939361883,-0.33427047819737776,-0.0436983521225498,-1.8190484108168046,0.06101019698493615,-0.5178651818055673,False,c3,1,"As part of our HTTPS scalability efforts, we should work towards improving the performance hit that HTTPS users incur right now.
More specifically:
[x] SNI, as to be able to send smaller, targeted certificates to users. Rolled out in Nov/Dec 2014.
[x] ECDSA Hybrid certificates (tracked separately, T86654)
[x] Enable ~~ALPN~~/NPN, without SPDY. This will signal UAs to use TLS False Start.
[x] Tune to smaller TLS record sizes, ~~potentially dynamic~~
[x] OCSP stapling
[ ] Session cache tuning (check for hit ratio, increase cache, rollovers)
SPDY, although related, is not on-topic for this. There's T35890 tracking progress for that one.
All of the above are for the most part on a newer platform, cf. T86648.",86666,-25,Medium,True
-3.387962272736183,-0.8102956672751507,-5.551022846483898,-5.751823211995387,2.2038868986496016,-9.948328898893184,2.0885496705537614,-0.8495020544788067,2.875117584685719,-0.253686008671675,0.6892413650066875,-2.552667161406399,0.9218658810663682,-1.552990619411886,-1.7383580331144577,1.207201090080204,3.303027175944816,2.0684770087095288,False,c3,1,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards).
We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",86664,-25,Medium,True
-0.12774612367693727,7.698386169917612,-0.21488642469084773,-6.32275048127696,0.2756418400325822,-4.888162465668912,2.7896106972458243,-5.175168728126126,-0.5234960468695808,0.9897875510101972,2.2460391846165675,-3.127263534839189,1.1756909952659895,-1.8208673599177017,0.2862006600851803,0.22327620575005316,2.1834508659099647,-0.808369648553591,False,c3,1,"For performance reasons, we should switch to ECDSA Hybrid (= signed by an RSA CA) certificates for our projects. This will bring us performance benefits, both in terms of RTTs and CPU usage.
Since we now do SNI and the set of browsers that support SNI & ECDSA is the same (which we should double-check), we can safely do this with a wide UA impact and without hurting any non-compatible UAs, as long as we keep our fallback ""unified"" certificate RSA.
This is blocked on availability of those certificates, as most CAs do not sell them yet. Our new CA provider, GlobalSign, had previously gave us a Q1 2015 ETA for these, right before we picked them. I asked our representative last Tuesday (and again today) to confirm that they're still on track for this.",86654,-25,Medium,True
20.421602724172143,-10.897222550212055,9.744606360939336,-4.3577922466809,1.233577909403618,2.545360438835184,0.5701722886330876,0.4406997821067702,-1.6584411949435858,2.925652123703146,4.608398058510716,-0.5790028519954804,4.247096989430985,-3.8215775329944783,-2.559504411499613,-0.40332314923730594,-0.42091618929329155,-0.9445866997767776,False,c3,1,"D:\Py\rewrite>`pwb.py interwiki -async -cleanup -whenneeded:5 -family:wiktionary -untranslated -lang:ast -subcats:Llingües -array:300`
```
ERROR: Traceback (most recent call last):
File ""D:\Py\rewrite\pywikibot\data\api.py"", line 937, in submit
headers=headers, body=body)
File ""D:\Py\rewrite\pywikibot\tools.py"", line 679, in wrapper
return obj(*__args, **__kw)
File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 256, in request
r = fetch(baseuri, *args, **kwargs)
File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 353, in fetch
request._join() # wait for it
AttributeError: 'HttpRequest' object has no attribute '_join'
WARNING: Waiting 5 seconds before retrying.
```
after replacing bot with latest nightly:
```
ERROR: Traceback (most recent call last):
File ""D:\Py\rewrite\pywikibot\data\api.py"", line 983, in submit
headers=headers, body=body)
File ""D:\Py\rewrite\pywikibot\tools.py"", line 711, in wrapper
return obj(*__args, **__kw)
File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 248, in request
baseuri = site.base_url(uri)
File ""D:\Py\rewrite\pywikibot\site.py"", line 641, in __getattr__
% (self.__class__.__name__, attr))
AttributeError: APISite instance has no attribute 'base_url'
WARNING: Waiting 5 seconds before retrying.
```",86621,-25,Medium,True
26.75943447021164,-0.8788957977871465,10.134285718454596,-3.4806835434947683,9.202566576836825,0.17577775487274638,3.956405766505603,5.284031488504586,-5.5319980352426965,0.9690652647737119,1.7318259706426011,5.359039571170066,1.1117479017226217,-3.421529310017874,1.522988940880726,-2.0990856054653175,0.6414496433538737,-0.7273634794265669,False,c3,1,">>! In T72145#730119, @csteipp wrote:
> On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https.
>
> The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.
This is still annoying people :)",86601,-25,Medium,
-5.8021864781153925,7.974740844992432,-0.19311497844880776,1.1893350714747783,-2.0957418734943003,-4.423676465836551,1.7789143550714837,-3.3480428234703594,-0.5760421831321446,-1.8010582151167882,0.4006519834530571,1.081414206014016,-1.7354116381798184,-0.8931249775124028,0.783547469204585,-0.5748194420116437,0.20586230767313474,-1.570375176275209,False,c3,1,"wfHttpError assumes, that $wgOut is an instance of OutputPage and runs ->disable() on it:
https://github.com/wikimedia/mediawiki/blob/74faccfa264fca219e08ae9cfb60a355ec2fac39/includes/GlobalFunctions.php#L2078
I had some fatal errors in my error_log of my production server, so i tracked the problem down, and it seems, that wfHttpError can be called, before wgOut is set, here a stack trace (because i can't reproduce this error myself, because it seems to occur only on api calls and only specific times (always, when the mysql user exceeded the max_user_connection limit, which is another problem. So i had to workaround to get a stack trace, because it's only a webspace hoster, no possibility to enable anything to log fatal error stack traces):
```
#0 and #1 are catching functions (called when wgOut isn't an instance of OutputPage in wfHttpError) to log the stack trace
#2 {wikiroot}/includes/exception/MWException.php(228): wfHttpError(500, 'Internal Server Error', 'DB connection error
')
#3 {wikiroot}/includes/exception/MWExceptionHandler.php(59): MWException->report()
#4 {wikiroot}/includes/exception/MWExceptionHandler.php(159): MWExceptionHandler->report(DBConnectionError::__set_state(array(
'error' => 'User \'{user}\' has exceeded the \'max_user_connections\' resource (current value: 15) (127.0.0.1)',
'db' =>
DatabaseMysqli::__set_state(array(
'lastKnownSlavePos' => NULL,
'mFakeSlaveLag' => NULL,
'mFakeMaster' => false,
'serverVersion' => NULL,
'mLastQuery' => '',
'mDoneWrites' => false,
'mPHPError' => 'mysqli::real_connect(): (42000/1226): User \'{user}\' has exceeded the \'max_user_connections\' resource (current value: 15)',
'mServer' => '127.0.0.1',
'mUser' => '{user}',
'mPassword' => '{pass}',
'mDBname' => '{db}',
'mConn' => false,
'mOpened' => false,
'mTrxIdleCallbacks' =>
array (
),
'mTrxPreCommitCallbacks' =>
array (
),
'mTablePrefix' => '',
'mSchema' => NULL,
'mFlags' => 24,
'mForeign' => false,
'mErrorCount' => 0,
'mLBInfo' =>
array (
'host' => '127.0.0.1',
'user' => '{user}',
'password' => '{pass}',
'dbname' => '{db}',
'type' => 'mysql',
'load' => 1,
'flags' => 16,
'serverIndex' => 0,
),
'mDefaultBigSelects' => NULL,
'mSchemaVars' => false,
'preparedArgs' => NULL,
'htmlErrors' => '',
'delimiter' => ';',
'mTrxLevel' => 0,
'mTrxShortId' => '',
'mTrxTimestamp' => NULL,
'mTrxFname' => NULL,
'mTrxDoneWrites' => false,
'mTrxAutomatic' => false,
'mTrxAtomicLevels' =>
SplStack::__set_state(array(
)),
'mTrxAutomaticAtomic' => false,
'fileHandle' => NULL,
'allViews' => NULL,
)),
'message' => 'DB connection error: User \'{user}\' has exceeded the \'max_user_connections\' resource (current value: 15) (127.0.0.1)',
'string' => '',
'code' => 0,
'file' => '{wikiroot}/includes/db/Database.php',
'line' => 1016,
'trace' =>
array (
0 =>
array (
'file' => '{wikiroot}/includes/db/LoadBalancer.php',
'line' => 783,
'function' => 'reportConnectionError',
'class' => 'DatabaseBase',
'type' => '->',
'args' =>
array (
0 => 'Unknown error (127.0.0.1)',
),
),
1 =>
array (
'file' => '{wikiroot}/includes/db/LoadBalancer.php',
'line' => 494,
'function' => 'reportConnectionError',
'class' => 'LoadBalancer',
'type' => '->',
'args' =>
array (
),
),
2 =>
array (
'file' => '{wikiroot}/includes/GlobalFunctions.php',
'line' => 3567,
'function' => 'getConnection',
'class' => 'LoadBalancer',
'type' => '->',
'args' =>
array (
0 => -1,
1 =>
array (
),
2 => false,
),
),
3 =>
array (
'file' => '{wikiroot}/includes/cache/LocalisationCache.php',
'line' => 1175,
'function' => 'wfGetDB',
'args' =>
array (
0 => -1,
),
),
4 =>
array (
'file' => '{wikiroot}/includes/cache/LocalisationCache.php',
'line' => 405,
'function' => 'get',
'class' => 'LCStoreDB',
'type' => '->',
'args' =>
array (
0 => 'de',
1 => 'deps',
),
),
5 =>
array (
'file' => '{wikiroot}/includes/cache/LocalisationCache.php',
'line' => 451,
'function' => 'isExpired',
'class' => 'LocalisationCache',
'type' => '->',
'args' =>
array (
0 => 'de',
),
),
6 =>
array (
'file' => '{wikiroot}/includes/cache/LocalisationCache.php',
'line' => 327,
'function' => 'initLanguage',
'class' => 'LocalisationCache',
'type' => '->',
'args' =>
array (
0 => 'de',
),
),
7 =>
array (
'file' => '{wikiroot}/includes/cache/LocalisationCache.php',
'line' => 261,
'function' => 'loadItem',
'class' => 'LocalisationCache',
'type' => '->',
'args' =>
array (
0 => 'de',
1 => 'fallback',
),
),
8 =>
array (
'file' => '{wikiroot}/languages/Language.php',
'line' => 4320,
'function' => 'getItem',
'class' => 'LocalisationCache',
'type' => '->',
'args' =>
array (
0 => 'de',
1 => 'fallback',
),
),
9 =>
array (
'file' => '{wikiroot}/languages/Language.php',
'line' => 208,
'function' => 'getFallbacksFor',
'class' => 'Language',
'type' => '::',
'args' =>
array (
0 => 'de',
),
),
10 =>
array (
'file' => '{wikiroot}/languages/Language.php',
'line' => 167,
'function' => 'newFromCode',
'class' => 'Language',
'type' => '::',
'args' =>
array (
0 => 'de',
),
),
11 =>
array (
'file' => '{wikiroot}/includes/Setup.php',
'line' => 608,
'function' => 'factory',
'class' => 'Language',
'type' => '::',
'args' =>
array (
0 => 'de',
),
),
12 =>
array (
'file' => '{wikiroot}/includes/WebStart.php',
'line' => 121,
'args' =>
array (
0 => '{wikiroot}/includes/Setup.php',
),
'function' => 'require_once',
),
13 =>
array (
'file' => '{wikiroot}/api.php',
'line' => 43,
'args' =>
array (
0 => '{wikiroot}/includes/WebStart.php',
),
'function' => 'require',
),
),
'previous' => NULL,
)))
```
Called URL. /api.php?hidebots=1&days=7&limit=50&action=feedrecentchanges&feedformat=atom
In Setup.php, wgContLang is set ([[ https://github.com/wikimedia/mediawiki/blob/74faccfa264fca219e08ae9cfb60a355ec2fac39/includes/Setup.php#L608 | L608 ]]) before wgOut is set ([[ https://github.com/wikimedia/mediawiki/blob/74faccfa264fca219e08ae9cfb60a355ec2fac39/includes/Setup.php#L628 | L628 ]]), which results in Fatal errors in some special cases.",86398,-25,Medium,True
-1.7898146654426075,1.336379600921008,5.042562965887658,6.883251284047056,-0.6189241644944864,-3.5279476072575893,4.226412137960639,2.8954519174805493,-4.126309567592084,0.03840724870821255,0.9461296127171672,8.471424626147272,3.1396939744357786,0.8394629202239461,2.0529892822675455,5.721289228705832,5.069104070173586,4.799336663129191,False,c3,1,"Graphics on the login and create account forms are not SVG. And that's terrible.
There are four large-ish drawings and one tiny icons in `resources/src/mediawiki.special/images` that are used in login form or account creation form.",86225,-25,Medium,
-10.091772337953476,3.7026030491043365,-0.5938965277259207,3.9458466938150316,10.637609340704637,0.7509138086621876,-0.43771418923175887,5.384715844582666,-1.4398824923963094,-5.3858860187617825,-5.288503995379326,0.4648828981637545,-2.273307401777762,-0.9815658599326684,0.14597056592570468,-4.012956845012143,-1.3611192403258172,0.2005281158124037,False,c3,1,"Given the following code:
```
$wrapper
.click( function() {
// Log the clickthrough
mw.echo.logInteraction( 'notification-link-click', 'flyout', +data.id, data.type );
} );
```
```
logInteraction: function ( action, context, eventId, eventType, mobile ) {
/* .. */
mw.loader.using( 'ext.eventLogging', function() {
mw.eventLog.logEvent( 'EchoInteraction', myEvt );
} );
},
```
While `eventLog.logEvent` is able to asynchronously send a message (using synchronous XHR or sendBeacon), because that method itself is asynchronously loaded via `mw.loader.using`, the event will not be logged on links because the script execution is terminated when the browser navigates away.",85968,-26,Medium,False
7.48374376818561,9.485699860475279,8.74573738494433,4.788885947354509,-7.784653648672412,-1.4202819335685177,5.464140858503451,3.9109903288885404,-0.40925994006079824,3.1701664461980776,2.925631909383371,1.1885791778785555,0.970450799429738,0.542425039549995,-2.434802690932386,-1.9940644523134656,1.0696512885512501,-1.2578059369624734,False,c3,1,Set secure_proxy_ssl_header=true for Hue after CDH upgrade. This will make hue redirect to https:// urls properly.,85834,-26,Medium,True
-0.38672885727901685,9.175863156297723,6.6327138424639465,-4.20351945572744,-4.625897325617313,-2.9756754297300976,0.7150372245680163,4.6162624857499175,5.599622206014364,1.2649671716762825,1.9918757268615574,-0.6041488089920561,1.0948490866534448,0.7726487563513986,-1.4137799133007078,0.2852499636582484,-1.3907313966722796,-1.664080362903801,False,c3,1,"With the relative URLs we have right now MediaWiki (Http::get) will default to http which in turn will break for https only hosts (like ruwikinews).
See also: https://www.wikidata.org/wiki/Wikidata:Project_chat#Bug_when_adding_links_to_Wikinews",85754,-26,Medium,True
-5.056669524020405,10.56481735181292,3.570863989510869,0.6610463201166283,-1.6557165370076863,-1.4928100078312765,2.255456655112263,9.24597145931849,-2.0446940060353107,-0.9350446209217682,-1.3356661932072873,-3.222769125874472,-0.38208284899291556,-1.0830146171669996,-0.43471563533329594,3.969055499807045,0.6941660641293412,-1.9428970014365994,False,c3,1,"(Apologize if duplicate)
For some time now, the spammers in small wikis are not logged in loginwiki. As a result, checkusers could not easily check those accounts.
For example, most of the locally created account below are spambots, and not logged in loginwiki
https://id.wikisource.org/wiki/Istimewa:Catatan/newusers?uselang=en
https://id.wikisource.org/w/index.php?namespace=2&tagfilter=&title=Istimewa%3APerubahan+terbaru",85703,-26,Medium,True
3.1102723898619753,-4.065882077794045,-4.349230213555806,-0.11971752399891822,0.1629230371325584,-4.824925197185425,-5.694732406513265,-0.8193268585453557,-1.2057925821879443,-3.2480584990139487,2.283235197868644,-0.3781030942585325,-1.9209652135873334,-0.929741143169402,-1.0864732364994953,-2.119795964411685,1.046929845579949,-0.5725677397836364,False,c3,1,"I don't think we're actually planning on using them so this is probably very low priority for us, but I found that searching for only the ""Initiative"" document type (which appears like these: https://secure.phabricator.com/I1 https://secure.phabricator.com/I2) returns this error:
HTTPFutureHTTPResponseStatus
[HTTP/400]
{""error"":""SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[i5bA3UBCTgC2Bmr1Px8aYQ][phabricatormain][0]: RemoteTransportException[[elastic1031][inet[/10.64.48.55:9300]][search/phase/query]]; nested: SearchParseException[[phabricatormain][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\""sort\"":[{\""dateCreated\"":\""desc\""}],\""from\"":0,\""size\"":101}]]]; nested: SearchParseException[[phabricatormain][0]: from[-1],size[-1]: Parse Failure [No mapping ...
",85505,-27,Medium,True
-14.806016832345795,12.439507620361965,13.506815443208929,18.484679278506526,5.230650115959765,0.9283200541578667,3.9301719075767485,-2.3033072412593274,1.304922984649996,0.245251873168999,-0.2883263566745442,5.465953351835869,-2.414516000421311,2.0208388836813347,2.0107659170615495,-1.5037097325886937,1.0032883382761921,-2.5030544170692726,False,c3,1,"On the desktop login form password reset is above the password input
On mobile the password reset form is below the form
On the desktop login form the account creation button is a neutral mw-ui-button
On the mobile login form the account creation button is a link
Let's consolidate these so that mobile doesn't have to hijack the login page.
",85189,-28,Medium,True
-6.56313761153162,6.8767512601348315,0.260151399516765,-5.513198234768201,2.3545481149199188,-2.334581581953332,1.730422163303186,-2.0295061770579066,-1.7003985714913645,0.4398580280299571,3.5853574116960254,0.24991757207211274,2.4165233839783005,-0.7023456454683545,0.7453883433874315,-0.6511641083256411,1.410038855534548,1.1336012833649074,False,c3,1,"In https://phabricator.wikimedia.org/T85166 it turns out some redirects got lost. We probably still have quite a few incoming links to toolserver.org . Would be nice to have statistics for at least (and maybe more)
* 404 - Someone is hitting an url that doesn't exist. Missing redirect?
* 302/301 - Someone is hitting a redirect. If we have the referer and it's within the Wikimedia universe we can probably correct it
At some point such statistics were available at http://tools.wmflabs.org/awstats/cgi-bin/awstats.pl but then they disappeared for no known reason.",85167,-28,Medium,False
28.30553648035767,15.236822433622617,25.34541922738127,0.7470154316654094,-1.9882505146129685,5.364399650282234,-6.780506499495658,-2.735662574291877,-2.250502191970396,-2.2746180773980775,3.573860520147623,-3.1528049406849314,-4.669087806569423,-0.029773583132844728,-0.15240131475796304,-0.7742910768620839,-0.24556455240185016,-0.732698902405182,False,c3,1,"From a [PR discussion](https://github.com/wikimedia/restbase/pull/79/files#r21990035), via https://github.com/wikimedia/restbase/issues/88:
> There is some similar code in [server.js](https://github.com/wikimedia/restbase/blob/master/lib/server.js#L158). I'd like to move more towards raising [HTTPErrors](https://github.com/wikimedia/restbase/blob/master/lib/rbUtil.js#L250) for responses with a status >= 400, as that often cleans up the https://github.com/wikimedia/restbase/issues/88https://github.com/wikimedia/restbase/issues/88control flow & ensures that all error cases are handled.
>
> As for detecting the precise error type: Using `isinstance HTTPError` would require access to the constructor, which is not always easy since some of these might come from preq & some might be generated inside of restbase. A slightly more precise alternative could be to use `err.name === HTTPError`.",78837,-29,Medium,True
0.06507663128519603,11.509030219411638,4.8026812815887325,-0.9999150054865736,4.825085643201115,3.0424295391557434,-1.3813213757801304,2.8447322238691553,-2.785074138699107,4.274709591543589,-0.6736432043393736,-1.4323989516035938,-0.13484927298845228,-0.021847523942558844,-0.8972844380206828,0.9132374985869514,-1.0445327818395598,0.669281474315081,False,c3,1,"In Hebrew the lines ""Wikipedia"" and ""The Free Encyclopedia"" overlap a bit because of letters that go above and below the line height.
This probably happens also in other languages.
The lines should be further from each other.
It also makes sense to use the official SVG logos of each language.
{F20909}",78350,-29,Medium,True
7.187103561912055,16.357242412047118,12.642113453566264,-2.621572115199829,-5.946391339056156,0.42025087714663245,-1.1864040638156297,4.8343190531926625,-1.1033765905848472,-1.7672116833710354,-3.167783118164125,3.2621726641604702,-0.1826859882371874,0.15683039737041593,-1.3793952897292332,-0.5825853771349594,0.7938527240603037,-2.9076035819067485,False,c3,1,"https://payments.wikimedia.org is not up to date with the TLS settings used.
See: T55259#593938",78160,-30,Medium,True
21.33655473508076,-1.1082643711081257,-2.534341953815254,0.879249910630669,-0.8980152773287288,-1.4058747327186034,-3.3617702185256455,0.12554426850904066,-2.0489677841568152,-3.695613717625383,-1.2376058883804095,-1.236943652143085,7.225558339911865,3.7763442801817426,1.4659593158371846,-0.6266083394737014,-0.6059278015371211,1.13099087740059,False,c3,1,"After successful upgrade from MediaWiki 1.24.6, logging in as a new MediaWiki user using LDAP credentials hangs on login.
PHP Error logs shows the following:
```
PHP Fatal error: Call to a member function toString() on a non-object in /var/www/mediawiki-1.24.0/includes/User.php on line 3493
```
Workaround: Adding member through MySQL user table manually allows user to then login cleanly using LDAP User Credentials
Environment:
------------
CentOS release 6.5 (Final)
Linux www 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31 17:20:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
MediaWiki 1.24.0
PHP 5.5.15 (apache2handler)
MySQL 5.1.73
Extensions:
------------
ImageMap –
ParserFunctions 1.6.0
SyntaxHighlight 1.0.8.11-wmf1
LDAP Authentication Plugin 1.2e
Lockdown –
WikiEditor 0.4.0
",78108,-30,Medium,False
-0.9514736431441362,4.592831773768367,4.391596079815816,3.715066316978623,10.356317047275999,-7.7183175272786455,2.502062236375802,-3.145851909118143,6.74818747357899,0.621886768410719,3.085211026568921,1.3626966795320261,-0.08084631773562911,1.3472736092870266,-0.4286199169769569,3.220491083929595,0.4181710136247849,0.9179335767742882,False,c3,1,Our current restbase-cassandra tests exercise db directly & bypass the HTTP interface. We should switch the tests to use the HTTP (style) interface instead.,76734,-30,Medium,False
1.9690190571045298,12.261839190076312,4.420781903163768,3.9048362766124685,0.243151259441041,1.8920028554036545,-0.13445685107357708,-1.4121349928462088,-2.1137825812167206,-0.7856358460267336,-0.3263934737211591,-0.31771050277346125,1.755349072081232,-1.851972294230309,2.3570189044049883,-2.0585855063627934,3.079330999512539,-3.905492316756498,False,c3,1,"I tried to move the parsoidsvc-php-parsertests tests over to UbuntuTrusty (node 0.10) in https://gerrit.wikimedia.org/r/174031
This is the result: https://integration.wikimedia.org/ci/job/parsoidsvc-php-parsertests/3043/console
The PHP parser tests failed because various image-processing tools weren't installed on the contintLabsSlave host.",76661,-31,Medium,True
72.72892274632727,28.26215699163602,-52.466963103477305,23.682430507973315,-0.2446438579975307,-3.4555993606487885,10.53815218440452,0.38571113938144264,5.504546996341004,0.6480314432278478,-0.3769578497030812,-0.7100801466866358,-3.013059667009532,0.012420097978043998,-0.14273628835381746,-0.09049544516175873,-1.2826296926713665,-1.3108557985457057,False,c3,1,nan,76626,-31,Medium,True
5.803441323263579,12.939780730755821,0.6592849713124131,-4.532885656212258,-8.491419591837765,-5.831570823081681,2.6476442012955124,13.627247205958758,7.553356672790648,1.3407776078649363,0.3356845422624395,4.7538703795960435,0.19690565362781776,0.1901769324170024,1.3323455846269514,-5.259216716098461,-3.150940909640946,4.2780457618709855,False,c3,3,SPARQL queries tend to get very long so support of HTTP POST would be nice to avoid bloating logfiles.,114405,13,Low,True
-6.018492870622918,-2.016478282371704,7.665475618328159,9.12166653694242,3.9705643306917016,1.0714756615002992,1.0421431366768,1.9160521615342998,3.7385403447664123,3.7405373742337673,8.964504105796983,6.216379720932416,1.8977642326951365,-2.0542952601936983,0.31722446496298673,-0.4307086781526147,0.3438336122274459,3.561858206097101,False,c3,1,"The http tests use getstatuscode.com , and a few other sites to produce known http responses. Using http://httpbin.org/ would be better.",97242,-10,Low,True
-5.858668278283997,6.929499872738102,-1.031148621416797,-1.5354945575225285,-3.1640790936914387,0.13635581423974608,2.416066997412451,3.079389422904221,-2.8007251056174525,1.2966292281473821,1.310951167878534,0.4595377154893934,1.1031768648793823,-1.556669942816526,-0.05247297635922443,-1.3918061847230943,1.124391096121321,-1.101325478411511,False,c3,1,"Neither of these are currently in jessie's stable package set. However, both are desirable sometime this year, enough that we will probably bite the bullet on using a backports package and/or rolling our own that we have to maintain security on.
The driver for openssl 1.0.2 is ALPN support (which isn't important until we get HTTP/2)
The drivers for nginx 1.9.2:
* lots of non-sec bugfixes for ""newer"" features that we are using are simply not backported to 1.6.x (several already for SPDY, OCSP Stapling, etc)
* general background on nginx mainline-vs-stable: http://nginx.com/blog/nginx-1-6-1-7-released/
* SO_REUSEPORT support
This will all be interrelated with HTTP/2 support as well, but that may not land in nginx until some later version.
Note that for ALPN, the updated nginx package has to have been compiled against headers from the updated openssl package.",96850,-11,Low,True
-0.6223132431717939,4.1802578932408885,0.1307532679132315,-1.6231603697099843,1.310849781088172,-0.6614227732590846,-1.442407595525916,-2.377891473496123,-0.9868594969778619,-0.5899872287379138,1.3924589855918241,-1.9454526458482888,0.6607572937417583,-2.16185787498113,0.0473858725319074,0.11739254621546164,1.4069266196740775,0.5775826941157105,False,c3,1,"On my 2013 Moto X running Android 4.4 and Chrome, I tried to log in to Phabricator, I think for the first time. On phabricator.wikimedia.org I clicked the [Login or Register MediaWiki] button, and after 8 attempts at the mediawiki.org Special:Login page (typnig on phone keygoard is hard) I successfully logged into mediawiki.org as ""SPage (WMF)"".
Upon doing so, the page
https://m.mediawiki.org/wiki/Special:CentralLogin/complete?token=a1cblahblah appeared displaying a confusing pink error message
**Central user log in**
No active login attempt is in progress for your session.
I don't know what this means. It's not helpful and I have no idea what to do next.
I expect to see the usual OAuth ""phabricator-production would like to have basic access..."" dialog.
I tried going to a random page on mw.org and that worked, but still no OAuth dialog.
I pressed the back button repeatedly and eventually the OAuth dialog appeared on top of a grayed out page. (The dialog was positioned off-screen, but that's a separate bug T95216.)
The situation sounds like {T53789} but that's a complaint about mobile on desktop. There are other bugs in Phabricator mentioning this ""No active login attempt is in progress for your session."" message.
----
I had additional difficulty but it's probably unrelated. I spent time filing this bug report before clicking the OAuth [Allow] button. That resulted in a red warning in the OAuth dialog
Sorry something went wrong connecting this application. Go back and try to connect your account again, or contact the application author.
OAuth token not found, E004
Clicking [Allow] again displayed the same warning.
So I backed out all the way to the Phabricator login page, clicked it [Login or Register MediaWiki] button, got the OAuth dialog right away, clicked [Allow], and was back in Phabricator logged in. I think the moral is don't spend 15 minutes filing a bug report in the middle of trying to log in with OAuth :)",95221,-13,Low,False
3.11077132406063,6.725303211794024,4.105039826849183,-6.406685512879571,-0.879430210395888,-2.0360187281341955,-3.2565645487938397,1.1581345346621599,1.6262080200767133,0.10691422938116713,-2.164636925165902,0.2633232033857418,0.11615759290796657,-1.3024466680015272,-0.2700137106548226,4.24863399918693,0.32983142169094637,-1.6239333924340822,False,c3,1,"@halfak and I noticed this earlier.
* Log in to a Wikimedia wiki
* Browse to /w/api.php?action=query&meta=userinfo via HTTP (not HTTPS)
* See ""You are centrally logged in. Reload the page to apply your user settings.""
* Reload page
* No change. The login would've happened over HTTPS but this is unencrypted.
* Load page via HTTPS instead
* Now you're shown as logged in",94125,-14,Low,False
-3.6393043151776934,9.422496930812049,1.8669000503579873,-6.170796794532818,-0.6383508045629707,-4.425891231733261,2.4602103326312728,-2.569516102369486,0.09738898572689031,-0.2376281397024922,1.0560734130878884,-0.4701090340669797,0.12731469502510162,0.7154887748270609,0.7732068509109942,-0.9019936929332177,1.4778200637327534,-0.5261018715780827,True,c3,1,"Urgency: low-medium
Impact to donors: receiving strange error message in english, looks unprofessional and losing donations
**Note to @atgo:** This wasn't reported at all in IL, but I don't know if I can rule out the issue in case it was a WPG thing. Feel free to close this task if you think it's no longer relevant.
From 11/14/2014:
Number of donors impacted: At least 10 have contacted us since Friday. It seems the payment failure related to this error are not making it to WP so we can't quantify how many are seeing this and not contacting us
We have received word from a number of French donors who say that after entering their credit card details and clicking Submit, they are sent to this page:
https://ott9.wpstn.com/live/
It looks like it's probably a WP page, but there's not much to go off of. A very tech savvy donor sent us the reply below — I think he can explain this better than I ever could. Two other donors confirmed they were using Firefox and probably had to do with browser security:
I tried to donate to Wikipedia but could not, as my web browser (Firefox) is configured not to accept the RC4 algorithm for SSL connections. The RC4 algorithm is considered insecure nowadays. Apparently, RC4 is all that the web server ott9.wpstn.com supports, as I get the error message that no overlap in supported encryption algorithms was found.
The SSL scan results obtained on https://www.ssllabs.com/ssltest/analyze.html?d=ott9.wpstn.com&hideResults=on support this finding.
Please, can you arrange for the SSL stack on this server to allow more secure symmetric algorithms than RC4, so that people with web browsers configured for higher security can donate?
I don't have Civi IDs or WP order IDs for these donors because they didn't seem to make it that far. Two questions:
1) Is there a reason they're getting a WP error and not one from us?
2) Is there anything we can do based on the donor's suggestion above to change the way we connect through SSL?",91694,-17,Low,False
1.8195321653198655,10.417811380452534,5.66666628339274,-11.913029467148814,-1.1452222781570838,1.8217618089643792,-1.5711393860197163,-1.5371916649198503,0.3298148533386882,1.8041482834869589,0.6081913078738905,-5.230184807857827,1.4788665445371931,-0.6206569955123848,0.9404382867804006,-2.305822730903608,2.6052211764991,4.677299677071057,False,c3,1,"Today I came across an issue that prevents using HTTP on the Russian Wiktionary. At first I had to turn the ""Always use secure connection"" option off. Then I tried deleting all ForceHTTPS cookies and logging in-out several times, but to no avail. Currently I have no such cookies but still unable to switch to HTTP.",91352,-18,Low,True
-7.242067758321937,9.949006056023588,1.7480293777454854,-5.444605591979862,0.5415540329881354,-3.2587117126127074,3.5934868516567358,-4.5528588066143705,-3.0578231294960707,2.12244928547171,0.39751847238288995,4.765695647616329,-0.6400759752034393,1.9396306229841143,0.5438185902446184,-1.4931119994116293,-1.9431082179231864,0.00036701187547194536,False,c3,1,"I'm using MultiHttpClient from the libs directory to do multiple requests in parallel. When requests fail I want to know the reason. So far the only information I have been getting out of it is error code 0 with no further explanation. Docs say that it means serious curl error, but how in earth am I supposed to debug this? This is the serialized response:
a:10:{s:4:""code"";i:0;s:6:""reason"";s:0:"""";s:7:""headers"";a:0:{}s:4:""body"";s:0:"""";s:5:""error"";s:0:"""";i:0;i:0;i:1;s:0:"""";i:2;a:0:{}i:3;s:0:"""";i:4;s:0:"""";}",89758,-20,Low,True
1.3055568334524001,4.650194779149068,5.083709330688084,1.9371033621330511,5.630647651902056,0.6921687800521832,-1.055283256174759,0.606352855953613,0.8308772101505555,-0.945712304459327,0.1640096516685805,1.6873174814869165,1.3319964785370422,1.0875040915541705,-2.08619929366786,-0.6132822872625824,-1.8713276952492763,-0.420524056264318,False,c3,1,"When editing a Wikibase entry, Ajax requests are sent with an `origin` GET parameter to `api.php`.
However, the editing interface runs on the same domain as the repo, and wouldn't need to set the GET parameter.
`api.php` expects that when an `origin` get parameter is sent, there is also an `Origin` HTTP header containing the same URL.
The Wikibase Ajax request does *not* send this `Origin` HTTP header, making `api.php` respond with a 403 status:
```
'origin' parameter does not match Origin header
```
This behavior is generated in `includes/api/ApiMain.php`
Probably the Ajax request has to send the required HTTP headers if it determines that it needs to send the GET parameters.",89622,-20,Low,False
7.025418657129515,7.515981842924269,5.438890577646909,-3.528161991575561,-2.595431072187065,-4.209731300325061,1.4588598680234979,-6.6902219267729715,9.155839681612607,2.1170238969625705,4.012421065570464,4.034803186526397,0.9581624483650453,-0.5432876454991051,1.6963465839415894,-2.0874464520931957,0.543363574518873,0.04976497541043989,False,c3,1,"To protect users, we should redirect authenticated requests from HTTP to HTTPS. Our current TLS termination layer is setting an `x-https` header (TODO: verify name), which we can use to detect HTTP users.",88862,-21,Low,False
6.929633555902193,1.9966862954669544,5.039235917820385,3.5770050725237965,3.1677659093958788,-3.925322542230057,0.9757525705756311,1.0023146021776186,-0.6541030773723584,-0.7791596739962183,3.404955054006956,1.3166358770176292,-3.481545305668603,1.875191751551526,-1.8974524063009826,3.779926632191274,-0.9864404731888878,1.1454332288539215,False,c3,1,"The ZeroPortal extension's browser tests define LoginPage in [[https://github.com/wikimedia/mediawiki-extensions-ZeroPortal/blob/master/tests/browser/features/support/pages/login_page.rb | login_page.rb]]. But there's already a LoginPage object in the shared [[ https://github.com/wikimedia/mediawiki-selenium/blob/master/lib/mediawiki_selenium/support/pages/login_page.rb | mediawiki_selenium ]] gem that ZeroPortal uses.
You could just delete ZeroPortal's local file and see if tests still pass.",85649,-26,Low,True
-11.094941250163284,16.382109918292795,-5.635409056494677,-17.229963412431175,-8.719495195294792,-10.868671823248066,6.795330177501264,-4.7831596269139025,-2.528761379301203,0.68126872104125,2.1413184658831637,4.095010102433317,-0.2784669707100438,1.1862330605635192,-1.086062957609439,1.3842493609074304,-2.648034659084087,2.0216307897561805,False,c3,1,"Currently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",84983,-28,Low,False
-4.310082173048313,8.71605401783506,4.020510477334003,-0.7178899089581814,0.8283289967882477,-1.0821162792648509,-0.9143469997893172,0.17979665510405995,-0.5545556052367344,0.8342768190536178,1.2721968504150722,-0.8433993564015255,1.1652809612919226,1.5105469722198315,-0.9204290358461309,1.7149060116569068,-0.29930732311342045,-0.6244677438543544,False,c3,1,"1. Reset password
2. Log in with it, this yields the ""Create a new password"" screen, courtesy of Special:ResetPassword proxied through SpecialUserLogin
3. Trigger any error or callback or rate limit. That will respond from ResetPassword (in the url) as that's where the form submits to.
It shows exact same form again, with my values still filled. Except now the form looks completely unstyled.",78373,-29,Low,False
3.2013286609731684,-7.3268508590772905,7.126601967319001,11.694091130425589,-3.9746442761395806,-7.961570198857986,-2.2950562151684433,0.12648445671751313,0.3771298890402315,-1.1317455004684507,8.086308886453356,1.206106048653188,-3.8992146653542905,-2.1680390894215047,-0.5520543374282036,0.2581600232682275,1.2524925442312254,0.9761971056033529,False,c3,1,Sentry should have unified login via LDAP ([[ https://github.com/banno/getsentry-ldap-auth | getsentry-ldap-auth ]]) or Oauth ([[ https://github.com/omab/python-social-auth | python-social-auth ]]?).,97133,-10,Lowest,False
-3.509211662230605,1.374212645973918,1.3863572043557397,-1.5206132566438557,0.7175345942970157,-4.803891692853824,-0.04265423291670434,-5.981034502126264,-1.0981606617392434,1.7453401558396155,0.9068085177482876,-0.889645111541331,0.40979776164145454,-0.4526075041949422,-0.7276390849241334,0.7117119216111476,-1.3687517353845176,-0.7720113895547298,False,c3,1,"I logged in with my personal account and visited https://en.wikipedia.org/wiki/Special:MergeAccount . It confirmed
>You can now log in to any wiki site of the Wikimedia Foundation without creating a new account.
> Read more about unified login…
> The accounts named ""Skierpage"" on each of the following sites have been automatically attached to the unified account:
> - [[ https://commons.wikimedia.org/wiki/User:Skierpage | commons.wikimedia.org ]]
> - [[ https://de.wikipedia.org/wiki/User:Skierpage | de.wikipedia.org ]]
> - (20 more links)
But
- no indication if I actually have a user page on those sites, everything is a blue link
- no mention of [[ https://meta.wikimedia.org/wiki/Global_user_page | Global user page]] and whether I have one.
Expected result: SpecialMergeAccount.php's `showStatus()` should be aware of Global user page. Tell me about it, tell me if I have a meta user page already, and for each of these wiki user page links that it's already showing (in `listWikis()`, indicate if I have a user page. Thus I'd see information like
# ""You do/do not have a [[ https://meta.wikimedia.org/wiki/Global_user_page | Global user page]].""
- If not, ""You should [[ https://meta.wikimedia.org/wiki/User:JohnDoe | create a global user page]]""
# ""(After you create it, ) Your global user page will display if someone visits your username on all 800 wikis""
# ""In the list of accounts below, you have a local user page on the starred wikis.""",94251,-14,Lowest,
8.994585514099182,5.404789770144951,6.889752589718004,-7.208579180027264,2.2071341595700984,0.26385909802864593,1.2523785943775119,0.7802331742455103,-2.7302130271735976,0.44879250462160236,1.6200471253807618,0.5352491704892168,1.2051918724202864,-1.3180687071291173,-1.128139857550888,0.7320902549697799,-1.0191129865899862,-0.6015450226304171,False,c3,1,"{P419}
This is with any HTTPS remote URL. It's happy if I set the remote URL to SSH instead.
Workaround:
>>! In T93489#1237736, @valhallasw wrote:
> In the mediawiki-core directory,
> ```
> cd .git/hooks
> wget https://gerrit.wikimedia.org/r/tools/hooks/commit-msg
> chmod 755 commit-msg
> ```
>
> will install the commit-msg hook.
Everything should work afterwards. Note, however, that the password for pushing is not your normal password, but the one listed under https://gerrit.wikimedia.org/r/#/settings/http-password .
",93489,-15,Lowest,False
18.456429997528744,8.293010467101432,5.755327969341632,6.779014513827915,-7.047270675049605,-5.738304754463314,0.9296335080949429,-2.001802705766436,-6.860961105237259,-3.2158453977417762,-2.1038579086142333,4.143526693419674,5.3526611365008625,8.159786347151261,-0.6711306695081216,-0.37772544517709883,0.3429576033536059,0.6974521762806962,True,c3,1,"https://github.com/AgileBits/onepassword-app-extension
Quicker login for 1 password users. ",90033,-19,Lowest,False
0.10445581584233121,10.902081408725508,9.859223309510902,-12.885465712351007,3.4580966341718153,-9.22977464394332,-1.293340114278565,2.0468052363775264,6.216457620992557,1.7748820750308427,-0.8335489517974644,-2.76834652145714,-1.8054096734337302,3.4336444592676987,-1.4714854290616692,4.4227952396629995,3.116823392177153,-7.5573079614613565,False,c3,1,"In Bugzilla, everyone can see CC List of a bug. I don't know why we can't do that in Phabricator.
",89210,-21,Lowest,True
-5.006035280835995,5.0114492874025025,-2.658004293845103,-0.41466027370539316,-0.8359071451207275,0.3866659375073884,-1.1337847072267389,-1.1145187886935033,-0.16040649549894448,0.1639822938842368,1.0418969548288186,-0.8386288749169908,3.8401958048150537,-0.240463112095064,0.33930007325070033,0.8906148220405333,0.6824607998795227,1.3158552416281626,False,c3,1,"My wiki is private and runs on TLS only. Since 1.23 the jobs queue won't run because it makes an HTTP request against the HTTP port, which generates a 301 redirect, that mediawiki ignores. fsockopen can handle SSL/TLS negotiations but there is no code apparently detecting the $wgServer containing https:// and adjusting accordingly. I was able to modify the fsockopen like this to make it work (near line 666 in MediaWiki.php 1.24.0):
```
$sock = fsockopen(
""tls://"" . $info['host'],
isset( $info['port'] ) ? $info['port'] : 443,
$errno,
$errstr,
// If it takes more than 100ms to connect to ourselves there
// is a problem elsewhere.
0.1
);
```
Obviously in a proper design, you would assume port 443 (unless overridden) and TLS from ""https://"" in the $wgServer and prepend tls:// or ssl:// to the hostname for fsockopen.",89065,-21,Lowest,False
-2.837546095296168,4.073146514841255,3.61923185048002,0.8859600209061045,0.8991247058478455,-1.788338950759389,-1.6990418498412119,-3.1784857926867307,2.6525664866967986,2.084132440653578,1.9898932338256867,2.8823974320940877,2.2687975681416535,3.8447096017854836,-0.20978313290949302,3.9453635914875265,0.8092395761004043,-0.4201554062699919,False,c3,1,"The button ""Edit without login"" has display:none; on the editor cta.
Steps to reproduce:
1. Make sure you're in alpha or anonymous editing is enabled in your configuration
2. Go to an editable page
3. Click the edit pencil
Expected: You see a warning and 3 options (Edit without login, login and signup)
Observed: You don't see the edit without login button",88264,-22,Lowest,True
-5.4877523662081495,8.6912612966896,3.567436912283508,-4.4204793329422785,10.463976052151748,-4.817328695638614,2.516896550274148,-1.587057060165817,-0.8931652131559312,0.3488088000400218,0.9671695171679437,5.52330770762832,-0.5172352572654244,-0.7546453563103803,3.0129990321205478,1.5790132103853776,1.7728356511267178,2.2944443493924354,False,c3,1,"Report upstream: https://secure.phabricator.com/T7073
The Phabricator login button seems to be a log out icon. Maybe it isn't, but that's what it looks like and it was a bit confusing.",87552,-23,Lowest,True
-8.851674942451865,12.598170150291658,0.2195622589494377,-4.550772403168206,2.5555532471879907,1.430528745212541,-2.9998130732944075,-2.5694500531080497,-1.4096035936270468,-0.3953643805358844,-2.1190166225426443,2.9460926518228137,0.05740300359008099,0.44471274864967025,-0.6640651149751866,0.19675304092042725,0.42873246848521407,-1.127828685384489,False,c3,1,"Hi,
We have a wiki which has a part which can be accessed without logging in and a part which can only be read (and modified) after you are logged on. When you try to access a page for which you have to be logged on you get the following screen:
Login required Please log in to view other pages.
Return to Main Page.
The text 'log in' after Please is a link so that after you click this and logon you return immediately to the required page. On top of the screen there is also a login-link-button which points to http://ourwiki/index.php?title=Special:UserLogin&returnto=Special%3ABadtitle
We can notify to use the link provided after 'Please' but it would be convenient that the loginlink at the top of the screen responds the same. I have googled around but haven't found a solution (yet) for this (if there is any). So question: Is there a way to solve this?
We use Mediawiki 1.23.7.
Thanx in advance.",78646,-29,Lowest,True